Hari ini kita akan membahas sesuatu yang hampir semua orang pernah dengar tapi tidak bisa menjelaskannya, yaitu Kubernetes. Hal ini membingungkan karena ia menyelesaikan masalah yang tidak disadari orang sebelum mereka mengalami. Semua orang tahu itu penting, tapi kalau ditanya apa fungsinya, Anda hanya akan mendapat tata-tata. Ini bukan pengganti docker atau sistem operasi cloud meskipun orang sering menebak demikian. Kebingungan itu wajar karena Kubernetes memecahkan masalah yang tidak Anda sadari ada sebelum Anda menghadapinya. Ini adalah alat yang menjadi penting saat Anda memiliki lebih dari sekelintir kontainer untuk dikelola. Di akhir episode ini, Anda akan paham apa itu Kubernetes, bagaimana hubungannya dengan kontainer, dan mengapa Azure Kubernetes Service membuatnya praktis bagi tim yang tidak ingin membangun semuanya dari awal. Siapkan kopi Anda dan mari kita mulai. Masalah sebelum ada kontainer.

Mari ke masalahnya. Bayangkan sebuah perusahaan perangkat menang sepuluhnya ngalah. Anda punya beberapa aplikasi untuk dijalankan, jadi Anda membeli server, menginstal sistem operasi, dan menerapkan semuanya secara manual. Setiap aplikasi mendapat mesin sendiri dan Anda tidak bisa berbagi sumber daya antara mereka. Jika satu aplikasi butuh banyak memori dan yang lain hampir tidak butuh apa-apa, keduanya tetap mendapat server sendiri. Pemurusannya sangat besar. Server mungkin hanya berjalan pada kapasitas 20%, tapi Anda tidak bisa menggabungkannya karena aplikasi akan berboot dependensi. Anda berakhir dengan ruangan penuh server. Masing-masing hampir tidak bekerja, mengonsumsi daya dan peninginan, serta semuanya butuh perawatan terus-menerus. Satu aplikasi butuh Python 3T7, yang lain butuh Python 3T4. Satu butuh pustaka lama, yang lain butuh yang terbaru. Anda tidak bisa menjalankannya di mesin yang sama tanpa merusak sesuatu, jadi Anda membeli lebih banyak server dan membayar perangkat keras yang lebih sering langgur.

Mesin virtual sedikit membantu dengan membiarkan Anda membagi server fisik menjadi bagian yang lebih kecil, masing-masing menjalankan OS sendiri. Tetapi setiap VM terasa berat dengan OS penuh yang memakan ruang disk dan memoris, termemoris penuh yang memakan ruang disk dan mulai. Dan Anda harus menginfigurasi masing-masing secara terpisah yang merupakan pekerjaan. Anda tetap harus mengelola semua sistem operasi tersebut, menambal, merbarui, dan mengamankannya. Tim membutuhkan sesuatu yang lebih ringan dan portable, cara untuk mengemas aplikasi dengan semua kebutuhan menjalankannya tanpa beban mesin virtual penuh dan bisa dipindahkan dengan mudah antar mesin. Di situlah peran kontainer. Apa sebenarnya kontainer itu? Kontainer adalah paket kecil yang mencakup aplikasi Anda dan semua yang dibutuhkannya untuk berjalanan. Itu berarti kode, runtime, pustaka, dan file konfigurasi semuanya dibundal menjadi satu unit.

Bayangkan itu seperti kemas untuk perangkat lunak. Kontainer pengiriman bisa dimuat ke truk, kereta, atau kapal. Dan kontainer sendiri tetap sama. Kontainer perangkat lunak Anda bekerja dengan cara. Anda membangunnya sekali, dan ia berjalan sama di laptop, server uji, maupun lingkungan produksi Anda. Perbedaan utama antara kontainer dan mesin virtual adalah seberapa efisien baik. Mesin virtual menjalankan sistem operasinya sendiri secara penuh sehingga setiap VM memiliki kernel, file sistem, dan segalanya sendiri. Sebuah kontainer berbagi sistem operasiosnya. Ia hanyalah sebuah proses dengan pandangan dunia yang terisolasi. Itu berarti kontainer bisa dimulai dalam hitungan detik, bukan menit. Kontainer menggunakan lebih stick memory, dan Anda bisa memuat lebih banyak kontainer di satu mesin. Docker mempopularkan kontainer dengan memberi pengembang cara mudah untuk membangun dan menjalankannya dengan satu perintah.

Tiba-tiba, masalah berjalan di komputer saya mulai menghilang. Jika aplikasi Anda berjalan di kontainer di laptop Anda, ia akan berjalan dengan cara yang sama di server. Lingkungannya konsisten dimanapun. Namun kontainer menyelesaikan satu masalah dan menciptakan masalah. Dengan segelintir kontainer, pengelolaan manual bisa berjalan dengan. Anda bisa memulai menghentikan dan melacaknya sendiri. Namun apa yang terjadi ketika Anda memiliki ratusan? Anda perlu memutuskan server mana yang menjalankan kontainer apa memulai ulang yang gagal, menghubungkannya, dan meningkatkan skalanya saat trafik melonjak. Itu adalah tantangan baru, dan disitulah Kubernetes berperan. Masalah orkestrasi. Jadi, Anda berhasil menjalankan kontainer, mengemas aplikasi Anda, menjalankan secara konsisten dimanapun, dan semuanya terasat. Namun untuk sementara, dengan 10 atau 20 kontainer Anda bisa mengolah semuanya secara aman.

Anda tahu server mana yang menjalankan kontainer apa bisa memulai ulang jika ada yang rusak, dan memperbarui beberapa hal di sana-sini, dan masih bisa dikolok. Namun kemudian aplikasi Anda berkembang. Anda beralih ke layan mikro. Jadi, alis satu aplikasi besar, Anda memiliki dua aplikasi yang lebih kecil. Masing-masing membutuhkan beberapa salinan agar Anda, dan sekarang Anda menangani 200 kontainer.

Anda harus memutuskan server mana yang menjalankan setiap kontainer, memulai ulang kontainer saat gagal, dan menghubungkannya agar bisa berkomunikasi. Anda juga perlu meningkatkan skala saat trafik melonjak. Mungkin saat ada diskon atau peluncuran produk, dan menurunkannya saat kondisi tenang. Dan Anda perlu merilis pembaruan tanpa henti, yang berarti mengganti kontainer lama dengan yang baru satu persatu, dengan hati-hati, tanpa merusak apapun. Ini adalah masalah orkestrasi, dan itulah tepatnya yang dibangun untuk diselesaikan oleh Kubernetes. Kubernetes adalah platform sumber terbuka yang mengotomatiskan penerapan, penskalaan, dan pengelolaan aplikasi dalam kontainer. Anggap saja ini sebagai sistem operasi untuk pusat datang. Sama seperti Windows atau Linux yang mengelola sumber daya pada satu komputer, seperti CPU, memori, dan disk Kubernetes mengelola sumber daya di seluruh server Anda.

Ia memperlakukan semua mesin Anda sebagai satu kumpulan besar di komputasi. Anda memberitahunya apa yang ingin dijalankan, dan ia mencari tahu di mana menempatkannya, cara menempatkannya, cara menjaganya, tanpa berjalan. Konsep inti, pot, node, dan kluster. Mari kita lihat kerja Kubernetes yang sebenarnya. Unit terkecil di Kubernetes disebut pot. Semua pot membunguh satu lebih kontainer. Kontainer di dalam pot yang sama berbagi penyimpanan dan jaringan, sehingga mereka dapat berkomunikasi satu sama lain melalui lokal. Anda dapat menganggap pot sebagai unit tunggal penerapan. Anda tidak menerapkan kontainer secara langsung di Kubernetes. Anda menerapkan pot. Pot tidak berjalan sendiri, mereka berjalan dengan node. Node adalah server, baik fisik maupun virtual, yang menjadi bagian dari kluster Kubernetes Anda. Setiap node menjalankan perangkat lunak yang diperlukan untuk menjalankan pot, ditambah beberapa hal yang nanti.

Kluster adalah kumpulan semua node, yang dikelola sebagai satu sistem terpadu. Secara sederhana, pot adalah aplikasi Anda. Node adalah tempatnya berjalan, dan kluster adalah keseluruhan lingkungannya. Pot bersifat sementara. Mereka dapat dibuat, dihancurkan, atau dipindahkan kapan saja. Semua disengaja. Jika node gagal, Kubernetes memindahkan pot ke node lain. Untuk penskala naik, ia membuat pot baru. Dan ketika pot rusak, ia akan diganti secara otomatis. Keseluruhan sistem memperlakukan pot sebagai sesuatu yang sementara. Namun jika pot datang dan pergi, Anda memerlukan cara untuk berkomunikasi. Alian berbicara dengan pot, secara langsung Anda berbicara dengan layanan servis. Layanan menyediakan alamat jaringan stabil yang mengarahkan lalu lintas ke pot yang tepat, bahkan saat pot berubah. Bayang ke sebuah hotel. Nomor hotel tersebut adalah layanannya. Kamar berganti tamu sepanjang waktu, tetapi nomor teleponnya tepsam.

Anda menepon resepsionis yang mereka meneruskan panggilan Anda ke kamar. Itulah tepatnya yang dilakukan layanan di Kubernetes. Layanan memberi Anda alamat tetap yang selalu mengarah ke pot manapun yang sedang menjalankan aplikasi Anda. Kontrol plane, otak dari kluster. Jadi Anda memiliki pot, node, dan kluster. Pertanyaan adalah siapa yang memutuskan apa yang berjalan di mana? Itu adalah tugas dari kontrol plane. Setiap kluster Kubernetes memilikinya, dan itu adalah otak dari seluruh operasi. Semua keputusan terjadi di sini. Kontrol plane memiliki beberapa pot. Yang pertama adalah API server yang bertindak sebagai pintu depan kluster Anda. Setiap perintah yang Anda kirim ke Kubernetes, baik dari baris perintah, dashboard, atau skrip otomatis, akan melalui API server. API server mengautentikasi permintaan Anda, memeriksa apakah Anda diizinkan melakukannya, lalu meneruskannya ke tempat yang tepat.

Tidak ada yang terjadi di Kubernetes tanpa terlebih dahulu melalui API server. Berikutnya adalah scheduler yang memutuskan node mana yang menjalankan setiap pot. Saat Anda berkata, saya ingin aplikasi ini berjalan, scheduler melihat semua node yang tersedia, memeriksa sumber daya, seperti CPU, memori, dan ruang disk, lalu memilih yang terbaik. Ini seperti manajer hotel yang memberikan kamar berdasarkan kebutuhan setiap tak. Tamu dengan banyak bagasi mendapat kamar yang lebih besar, sementara aplikasi ringan mendapat node yang lebih kecil dengan kapasitas tersisa. Lalu ada controller manager. Komponen ini mengawasi kluster dan memastikan status aktual sesuai dengan apa yang Anda deklarasikan. Anda mengatakan ingin tiga salinan aplikasi web Anda berjalan. Controller manager memeriksa apakah benar ada tiga salinan yang sedang berjalan. Jika salah satu rusak, ia akan menyadarinya dan memulai penggantinya.

Jika seseorang tidak sengaja menghapus pot, ia akan membuat yang baik. Ini yang menjaga kluster Anda tetap konsisten. Dan terakhir, ada ETCD, yaitu basis data kluster. ETCD menyimpan segalanya, seperti apa yang berjalan, di mana ia berjalan, dan bagaimana konfigurasi. Ini adalah sumber kebenaran utama untuk seluruh kluster. Jika API server adalah pintu depan, maka ETCD adalah lemari arsip di kantor belakang tempat semua catatan disimpan. Indahan desain ini adalah Anda mendeskripsikan apa yang diinginkan dan Kubernetes mencari cara untuk mewujudkannya. Anda tidak memberitahu cara melakukannya. Anda memberitahu seperti apa hasil akhirnya. Itulah model deklaratif dan itu adalah ide inti dibalik semua yang dilakukan Kubernetes. Workload deployment, layanan, dan penskalaan. Jadi, mari kita bicara tentang cara Anda menjalankan aplikasi di Kubernetes. Anda tidak akan melaput secara langsung. Sebaliknya, Anda akan menggunakan objek tingkat tinggi yang disebut deployment.

Bayangkan deployment sebagai manager yang memberitahu Kubernetes berapa banyak salinan pod yang harus berjalan, image container mana yang digunakan, dan cara memperbaruinya saat versi baru dirilis. Ini adalah cara standar untuk menjalankan aplikasi statler. Saat Anda memperbarui deployment, misalnya Anda meluncurkan versi baru aplikasi, Kubernetes akan melakukan bambar guling update. Ini mengganti pod satu persatu memastikan setidaknya satu salinan selalu berjalan. Itu berarti tidak ada waktu henti dan tidak ada gangguan mendadak bagi penggunaan. Dan jika terjadi kesalahan pada versi baru, Anda dapat kembali ke versi sebelumnya dengan satu perintah. Itu adalah jaring pengaman yang sangat kuat. Namun, pod Anda tetap harus bisa dijangkau. Disitulah peran layanan servis. Sebuah layanan menyediakan alamat jaringan stabil yang merotekan lalu lintas ke pod yang tepat. Layanan juga dapat mengekspos pod tersebut ke bagian lain dari aplikasi Anda atau ke dunia luar.

Layanan bisa bersifat internal, hanya dapat diakses dalam kluster atau eksternal dengan alamat IP publik yang dapat dijangkau dari internet. Nah, inilah hal tentang peskalaan. Kubernetes dapat secara otomatis memperbesar dan memperkecil aplikasi Anda berdasarkan permintaan. Anda menetapkan target, katakanlah penggunaan CPU 70%, dan Kubernetes menambah pod saat penggunaan melampaui ambang batas itu dan menghapusnya saat turun. Aplikasi Anda berskala naik saat ada lonjakan, lalu lintas dan berskala turun saat situasi tenang. Tidak diperlukan intervensi monop. Namun, semua kekuatan ini serta dengan kompleksitas. Menjalankan kluster Kubernetes sendiri berarti Anda bertanggung jawab atas kontrol plan, pembaruan, patch keamanan, dan cadangan. Anda butuh keahlian mendalam untuk menangani kegagalan luar konfigurasi jaringan dan penskalaan kluster. Banyak tim menghabiskan lebih banyak waktu mengelola kluster daripada membangun aplikasi.

Dan disitulah peran Kubernetes terkelola manajer. Kubernetes yang dikelola sendiri versus terkelola. Jadi, mari bicara tentang realitas menjalankan Kubernetes sendiri. Saat Anda menyiapkan kluster sendiri, Anda bertanggung jawab atas segalanya, control plan, pembaruan, patch keamanan, dan cadangan ATCD. Jika server API mati, itu masalah Anda. Jika kerentanan keamanan ditemukan pada versi yang Anda jalankan, Anda harus menambalnya. Jika ATCD rusak, Anda harus memulihkannya dari cadangan. Semua ini memerlukan keahlian mendalam. Anda perlu memahami bagaimana Node gagal, bagaimana jaringan bekerja di tingkat kluster, dan cara mengekalakan sesuatu tanpa rusaknya. Inilah hal yang mengicutkan banyak tim. Banyak organisasi menghabiskan lebih banyak waktu mengelola kluster Kubernetes daripada membangun aplikasi yang berjalan di atasnya. Mereka terus-menerus bergulat dengan pembaruan, memecahkan masalah jaringan, dan menangani kegagalan Node.

Kluster tersebut menjadi pekerjaan perlangsung. Bukan itu alasan Anda mengadopsi Kubernetes sejak awal. Disinilah layanan Kubernetes terkewal berperan. Layanan seperti Azure Kubernetes Service atau AKS menangani kontrol plan untuk Anda. Azure mengelola server API, HCD, scheduler, dan controller manager. Anda tidak perlu khawatir tentang menambalnya atau menjaganya agar tepat. Anda hanya membayar untuk Node pekerja, yaitu mesin virtual yang benar-benar menjalankan beban kerja. Plannya sendiri gratis. Hal ini mengubah situasinya secara drastis. Hal yang menghabiskan waktu untuk pemeliharaan kluster, tim Anda bisa fokus pada hal yang lebih penting, yaitu aplikasi yang sedang Anda bangun. Bagi sebagian besar tim, terutama mereka yang baru memulai Kubernetes terkelola adalah pilihan itu. Anda mendapatkan semua keunggulan Kubernetes tanpa beban operasional yang rumit. AKS membuat Kubernetes menjadi mudah di Azure.

Jadi apa sebenarnya AKS itu? Ini adalah layanan Kubernetes terkelola di Azure yang memberi Anda kluster berfitur lengkap tanpa harus membangunnya dari awal. Control plan-nya gratis seperti yang disebutkan sebelumnya jadi Anda hanya membayar mesin virtual yang menjalankan beban kerjaan. Anda bisa mulai dengan skala kecil, membayar dengan biaya yang murah, dan mengingkatkan skala saat kebutuhan pertama. Azure menangani semua pekerjaan berat. Pembaruan, penambalan, dan pemantauan kesehatan untuk control plan semuanya sudah diurus. Anda tidak memerlukan tim khusus ahli Kubernetes hanya agar semuanya tetap berjalan. Dan karena AKS adalah bagian dari ekosistem Azure, layanan ini terintegrasi dengan alat yang mungkin sudah Anda gunakan. Azure Active Directory untuk autentikasi, Azure Monitor untuk log dan metrik, serta Azure Policy untuk tata kelola. Semuanya bekerja bersama secara langsung, tanpa perlu menyambungkan komponen interface.

Menyiapkan pipeline CI per CD dengan GitHub Actions atau Azure DevOps hanya butuh beberapa menit. Kirim perubahan ke repository Anda, dan sistem akan otomatis membangun image kontainer baru, mengirimnya ke Azure Container Registry, lalu memperbarui deployment Anda di AKS tanpa langkah manual, tanpa perlu SSH ke server. Semuanya otomatis. Bagi pemula, tersedia mode otomatis AKS yang gerancang untuk tim yang tidak ingin mengambil setiap keputusan konfigurasi kluster. Mode ini menyediakan pengaturan bawaan siap pakai untuk penskalaan jaringan keamanan dan pembaru. Anda tidak harus menjadi ahli Kubernetes untuk memulai. Cukup deskripsikan aplikasi Anda dan AKS akan menangani sisanya. Satu perintah untuk membuat kluster, satu file manifest untuk menjalankan aplikasi Anda. Keterampilan yang Anda pelajari di AKS dapat diterapkan di lingkungan Kubernetes manapun karena dasarnya adalah Kubernetes-an.

Anda tidak mempelajari sistem tertutup, Anda mempelajari sistem aslinya dengan Azure yang menangani kompleksitas operasionalnya. Jadi sekarang Anda sudah memahami. Kontainer mengemas aplikasi Anda agar berjalan konsisten di mana saja. Dan Kubernetes mengatur kontainer tersebut dalam skala besar, menangani deployment, penskalaan, dan pemulihan secara otomatis. AKS membuat orkestrasi tersebut lebih mudah dikelola dengan menangani kontrol plane dan berintegrasi dengan alat Azure yang sudah Anda kenal. Poin utamanya adalah Kubernetes bukan hanya untuk perusahaan teknologi besar dengan tim teknik yang masif. Dengan layanan terkelola seperti AKS, teknologi ini dapat diakses oleh tim. Tugas Anda minggu ini sederhana. Buat akun Azure gratis, jalankan kluster AKS dan terapkan aplikasi sederhana. Hanya butuh beberapa menit dan Anda akan melihat sejauh mana platform ini berkembang. Siap untuk mendalami.

Episode berikutnya, membahas cara membuat citra kontainer pertama Anda dan mengirimnya ke Azure Container Registry. Perlangganan adalah di platform podcast favorit Anda. Dan bagikan ini kepada seseorang yang baru memulai perjalanan ke Kubernetes mereka.