Sebagai praktisi DevOps yang berpengalaman dengan Kubernetes Native dan Managed (EKS), saya akan menjelaskan tiga ciri utama Kubernetes dan perbedaan antara Kubernetes Native dan Managed dari sudut pandang operasional.
1. Manajemen Keadaan yang Diinginkan (Desired State Management
Salah satu ciri utama Kubernetes adalah kemampuannya untuk mengelola klaster menggunakan konsep inti yang disebut "keadaan yang diinginkan" (desired state). Sesuai dengan istilahnya, keadaan yang diinginkan mengacu pada proses mendefinisikan secara eksplisit bagaimana aplikasi dan sumber daya dalam klaster harus beroperasi. Kubernetes kemudian memastikan bahwa keadaan saat ini selalu sesuai dengan keadaan yang telah ditentukan.
Konsep ini merupakan salah satu prinsip inti Kubernetes dalam mengelola dan memelihara aplikasi serta infrastruktur secara otomatis. Sebagai contoh, jika salah satu proses yang sedang berjalan tiba-tiba berhenti, Kubernetes akan secara otomatis memulai ulang proses tersebut tanpa memerlukan intervensi pengguna. Dengan demikian, Kubernetes mampu menjaga keadaan yang diinginkan tetap konsisten, memberikan kemampuan yang sangat baik dalam menangani gangguan atau kegagalan.
Saya pernah menjadi administrator Solaris pada sistem Unix. Saat terjadi gangguan, saya sering menerima telepon dari tim pemantauan, bahkan di tengah malam, untuk masuk ke konsol dan secara manual menjalankan ulang proses yang bermasalah. Namun, kini Kubernetes mengambil alih tugas tersebut. Waktu tidur saya di malam hari menjadi jauh lebih nyenyak.
Manajemen keadaan yang diinginkan adalah konsep yang sering digunakan dalam budaya DevOps dan lingkungan cloud-native. Dengan pendekatan ini, efisiensi dan keandalan dalam pengelolaan sistem dapat meningkat secara drastis, karena proses-proses yang sebelumnya membutuhkan intervensi manual kini dapat ditangani secara otomatis oleh Kubernetes.
Mari kita cari tahu dengan sebuah contoh. Jalankan 'Deployment' NGINX seperti yang ditunjukkan di bawah ini. Deployment adalah sumber daya Kubernetes untuk mengelola dan men-deploy instance aplikasi. Perintah kubectl digunakan di bawah ini. Kami akan membahas penggunaan secara detail, termasuk cara menggunakan perintah kubectl, di seri mendatang. Untuk saat ini, ada baiknya jika kita fokus pada konsep inti saja.
Perintah tersebut akan menjalankan pod NGINX. Anda dapat memeriksa status terkini pod dengan menggunakan perintah k get pod
. Pod adalah unit terkecil yang digunakan dalam Kubernetes untuk proses deployment, yang dapat berisi satu atau lebih container. Pod berfungsi sebagai host logis untuk container, di mana container dalam pod yang sama akan berbagi namespace jaringan, alamat IP, rentang port, serta penyimpanan yang sama
Kita akan membuat situasi gangguan secara sengaja. Untuk memantau perubahan status secara real-time, bagi jendela terminal menjadi dua. Pada jendela atas, hapus pod, dan pada jendela bawah, pantau perubahan status pod secara real-time menggunakan opsi -w
(watch). Perintah untuk menghapus pod adalah k delete pod
.
Pada jendela bawah, Anda dapat melihat bahwa pod yang dihapus secara otomatis dibuat kembali.
Pod dengan nama ‘nginx-748c667d99-d6bb5’ sedang dalam proses terminasi dan pod baru dengan nama ‘nginx-748c667d99-jmb7z’ sedang berjalan (Running). Kubernetes telah mengonfirmasi bahwa pod sebelumnya telah dihentikan dan secara otomatis menjalankan pod baru. Dengan kata lain, Kubernetes mendeteksi bahwa proses telah berhenti dan secara otomatis mengembalikan ke ‘status yang diinginkan’ semula. Sebagai catatan, nama ‘nginx-748c667d99-d6bb5’ dihasilkan oleh Kubernetes Deployment Resource yang secara otomatis menambahkan nilai hash acak ke nama deployment nginx.
BACA JUGA : Catatan Teknis Jennifer: Panduan Praktis Menguasai Kubernetes
Kita telah menjalankan pod dengan perintah kubectl create deployment
pada awalnya. Dengan demikian, Kubernetes Deployment mendefinisikan ‘status yang diinginkan’ sebagai keadaan di mana pod sedang berjalan. Oleh karena itu, meskipun kita menghapus pod secara sengaja (atau karena gangguan sistem yang tidak terduga), Kubernetes akan secara otomatis menjaga agar status yang diinginkan, yaitu satu pod yang sedang berjalan, tetap terjaga dengan memulai kembali pod. Di dalamnya, Deployment Resource menggunakan pengontrol bernama ReplicaSet Controller untuk selalu menjaga agar tetap dalam status yang diinginkan. Jika jumlah pod dideklarasikan sebanyak 3, maka akan selalu ada 3 pod yang dijaga melalui ReplicaSet Controller. Dengan cara yang serupa, Kubernetes menggunakan berbagai pengontrol untuk selalu mempertahankan status yang diinginkan. Penanggung jawab mendefinisikan terlebih dahulu ‘status yang diinginkan’, dan Kubernetes secara otomatis menjaga status tersebut dengan menggunakan berbagai sumber daya ‘pengontrol’. Ini memungkinkan pemulihan otomatis (self-healing) dan memfasilitasi komunikasi yang lancar antara pengembang dan operator.
2. Pengelolaan Sumber Daya Menggunakan Kode
Semua sumber daya Kubernetes dikelola dengan kode. Misalnya, ketika menginstal aplikasi, pada lingkungan VM sebelumnya, kita menggunakan perintah yum
seperti di bawah ini.
Kami berusaha untuk mencapai hasil yang diinginkan dengan menjalankan langkah-langkah secara bertahap menggunakan perintah. Khususnya, perintah tertentu harus dijalankan secara berurutan agar berfungsi dengan baik. Namun, seiring berjalannya waktu, status sistem berubah, membuatnya sangat sulit untuk melacak dan mengelola perubahan. Seringkali, pengelolaan dilakukan secara manual, tetapi tidak ada jaminan bahwa status sistem saat ini sesuai dengan dokumen manual yang ada (up-to-date).
Lingkungan Kubernetes juga dapat menggunakan perintah kubectl create deployment
seperti pada contoh sebelumnya, tetapi hampir semua sumber daya dibuat dengan menggunakan file kode seperti di bawah ini.
Mengelola sumber daya Kubernetes dengan menggunakan kode, bukan perintah, berarti menggunakan pendekatan manajemen yang deklaratif. Kubernetes adalah platform yang secara kuat mengadopsi pendekatan deklaratif, di mana ‘bentuk deklaratif’ mengacu pada metode yang secara eksplisit mendefinisikan status akhir dan mengarahkan sistem untuk mencapai status tersebut. Dalam pendekatan deklaratif, kita tidak secara langsung menyebutkan proses atau langkah-langkah untuk melakukan tugas, melainkan mendefinisikan status akhir yang diinginkan, sehingga sistem diarahkan untuk mencapai hasil tersebut.
Dengan mendefinisikan sumber daya menggunakan kode, kita dapat secara jelas menentukan sumber daya apa yang diperlukan dan pengaturan apa yang harus ada. Ini memastikan bahwa sumber daya di dalam kluster dibuat dan dikonfigurasi secara konsisten, serta mencegah kesalahan konfigurasi yang tidak terduga atau konflik, sehingga meningkatkan stabilitas sistem. Sebelum menerapkan sumber daya secara nyata, kita dapat mengimplementasikannya dalam kode dan melakukan tinjauan bersama rekan (PR Review) untuk mencegah gangguan yang mungkin terjadi selama proses kerja. Selain itu, penggunaan kode yang sama sangat berguna untuk mereproduksi infrastruktur. Dengan menjalankan kode yang sama di lingkungan mana pun, sumber daya yang sama akan dikerahkan, sehingga menjaga konsistensi lingkungan di berbagai tahap seperti pengembangan, pengujian, dan produksi. Selain itu, melalui sistem kontrol versi (misalnya, Git), kita dapat melacak dan mengelola perubahan. Ini memudahkan untuk melacak riwayat perubahan dan berkolaborasi dengan rekan kerja, serta mengoordinasikan perubahan yang dilakukan.
Berbeda dengan pengembang, operator mungkin merasa keberatan untuk menggunakan kode. Namun, kode yang digunakan dalam Kubernetes tidak rumit seperti bahasa pemrograman umum, sehingga tidak terlalu membebani untuk dipelajari. Jika Anda hanya memahami sintaks dasar file YAML, Anda tidak akan mengalami kesulitan dalam penggunaannya. Selain itu, dengan menggunakan alat seperti VSCode, Anda dapat memanfaatkan fitur auto-complete dan pemeriksaan sintaks otomatis, yang membuatnya lebih nyaman.
3. Konfigurasi Ketersediaan Tinggi (Pet vs Cattle)
Pertama, mari kita memahami konsep Hewan Peliharaan dan Sapi (Pet vs Cattle). Hewan peliharaan dan sapi adalah metafora untuk dua pendekatan dalam pengelolaan infrastruktur.
Hewan peliharaan memerlukan perhatian dan pengelolaan yang individual dan khusus. Setiap hewan peliharaan diberikan nama dan mendapatkan perhatian khusus. Di sisi lain, sapi tidak memiliki nama yang unik; mereka digunakan dengan label atau nomor umum. Dalam contoh sebelumnya, nama pod (nginx-748c667d99-d6bb5) menggunakan nilai hash acak. Pendekatan ini membutuhkan kemampuan untuk dikelola secara besar-besaran dan memberikan kemampuan untuk diubah dan fleksibilitas.
Kubernetes, yang merupakan alat orkestra berbasis kontainer, mengadopsi pendekatan pengelolaan Sapi (Cattle). Kubernetes mengelola aplikasi yang terkontainerisasi dengan cara yang terstandarisasi, mengotomatisasi infrastruktur, dan membangunnya agar dapat diskalakan. Dengan demikian, Kubernetes dapat secara efisien melakukan tugas seperti penyebaran aplikasi, penskalaan, pembaruan bergulir, dan pemulihan otomatis.
Sebagai contoh, ketika Kubernetes menghubungkan aplikasi (web server) dengan aplikasi (database server), ia menggunakan sumber daya layanan (Service) dengan metode nama domain, bukan metode IP yang digunakan dalam lingkungan VM sebelumnya. Metode IP yang sebelumnya digunakan mengandalkan nilai tetap (Static); jika server database berubah, alamat IP-nya juga berubah, sehingga alamat IP yang ditetapkan dalam variabel lingkungan web server juga harus diubah. Namun, Kubernetes menggunakan metode nama domain yang dinamis (Dynamic), sehingga jika alamat IP berubah, koneksi akan otomatis diarahkan ke alamat IP yang baru.
Dengan cara yang serupa, Kubernetes mengasumsikan bahwa gangguan dapat terjadi kapan saja dan menyediakan berbagai fitur seperti load balancer, penjadwalan lanjutan, dan Readiness/Liveness Probe untuk memastikan pemulihan otomatis dan kelangsungan layanan bahkan jika terjadi gangguan.
Berikut adalah contoh sumber daya layanan (Service) Kubernetes.
Ketika menghubungkan antar pod, digunakan layanan yang bernama nginx. Layanan ini secara otomatis menghasilkan 'endpoints' dan akan memperbarui IP yang terpetakan ke layanan tersebut jika alamat IP pod berubah. Oleh karena itu, meskipun alamat IP berubah, nama layanan tetap tidak berubah, sehingga layanan nginx yang ada dapat terus digunakan untuk koneksi antar pod dengan nama yang sama.
4. Perbandingan Solusi Kubernetes Native vs Managed
Di lingkungan on-premise, penggunaan Kubernetes dapat dilakukan dengan menggunakan Kubernetes native versi resmi atau solusi dari vendor seperti OpenShift dan Tanzu. Untuk lingkungan cloud, biasanya digunakan Kubernetes terkelola yang disediakan oleh masing-masing CSP (Cloud Service Provider), seperti EKS (Amazon Elastic Kubernetes Service), AKS (Azure Kubernetes Service), dan GKE (Google Kubernetes Engine).
Native Kubernetes juga sering disebut sebagai Vanilla Kubernetes. Istilah "Vanilla Kubernetes" merujuk pada versi resmi Kubernetes yang dirilis secara resmi. "Vanilla" berarti sesuatu yang umum atau dalam keadaan aslinya, dan dalam konteks ini, istilah tersebut digunakan untuk membedakan versi resmi Kubernetes. Kubernetes sendiri adalah proyek open-source yang dikelola oleh CNCF (Cloud Native Computing Foundation). CNCF bertanggung jawab atas pengembangan dan pemeliharaan Kubernetes, serta menyediakan versi resmi dari Kubernetes. Menyebut versi resmi ini sebagai Vanilla Kubernetes mengindikasikan bahwa versi ini mencakup komponen inti dan fitur dasar Kubernetes, serta mencerminkan keadaan asli seperti yang disediakan oleh CNCF.
Perbedaan utama antara Native Kubernetes dan Managed Kubernetes terletak pada aspek pengelolaan. Native Kubernetes mengharuskan pengguna untuk melakukan instalasi, upgrade, dan pengelolaan control plane secara mandiri. Sebaliknya, Managed Kubernetes menyediakan panduan instalasi dan secara langsung mengelola control plane untuk pengguna. Selain itu, Managed Kubernetes biasanya terintegrasi dengan sumber daya lain milik penyedia layanan, sehingga konfigurasi penyimpanan (storage) dan jaringan (network) dalam lingkungan Kubernetes menjadi lebih mudah dibandingkan dengan lingkungan Native Kubernetes. Integrasi ini memberikan efisiensi dan kemudahan dalam mengelola infrastruktur Kubernetes.
Namun, dari sudut pandang deployment aplikasi dan pengoperasian layanan secara stabil, kedua layanan ini—Native Kubernetes dan Managed Kubernetes—tidak memiliki perbedaan yang signifikan. Keduanya berbasis sistem Kubernetes, sehingga pemahaman mendalam tentang Kubernetes tetap diperlukan. Selain itu, kemampuan untuk mengintegrasikan berbagai perangkat lunak open-source lainnya, seperti Helm, ArgoCD, dan Ingress, sangat penting untuk memastikan sistem berjalan dengan optimal. Menurut pendapat pribadi, sekitar 80% hingga 90% tugas harian yang dilakukan dalam kedua layanan ini adalah serupa. Menggunakan layanan Managed Kubernetes tidak secara otomatis mengurangi beban kerja atau secara drastis menurunkan tingkat kesulitan. Pemahaman dan keterampilan teknis tetap menjadi kunci keberhasilan dalam mengelola lingkungan Kubernetes, terlepas dari jenis layanan yang digunakan.
Sebagai contoh sederhana, dalam Native Kubernetes, Anda dapat melihat berbagai pod yang berjalan di dalam namespace kube-system
. Namespace ini digunakan untuk komponen internal Kubernetes, seperti kube-apiserver
, kube-scheduler
, kube-controller-manager
, dan lainnya yang diperlukan untuk menjalankan cluster Kubernetes.
Misalnya, dalam Native Kubernetes, Anda dapat menemukan berbagai pod yang membentuk control plane, seperti etcd, controller manager, scheduler, dan api-server, di dalam namespace kube-system
. Pod-pod ini merupakan komponen inti yang bertanggung jawab untuk mengelola dan mengoordinasikan operasi cluster Kubernetes.
Namun, dalam EKS (Amazon Elastic Kubernetes Service), control plane dikelola langsung oleh AWS, sehingga Anda tidak dapat melihat pod seperti etcd, controller manager, scheduler, atau api-server. Saat memeriksa daftar pod yang berjalan di cluster, daftar tersebut cenderung lebih sederhana, karena hanya mencakup pod aplikasi pengguna dan beberapa komponen tambahan yang dikelola di tingkat node worker.
Namun, selain pengelolaan control plane, tugas lainnya—seperti mengelola berbagai open-source tools—tetap sama, baik dalam Native Kubernetes maupun Managed Kubernetes. Untuk operasional Kubernetes, penggunaan berbagai proyek open-source sangat penting. Daftar lengkap proyek-proyek open-source yang mendukung ekosistem Kubernetes dapat ditemukan di situs CNCF (Cloud Native Computing Foundation). CNCF menyediakan panduan dan sumber daya untuk membantu mengintegrasikan alat-alat ini ke dalam lingkungan Kubernetes Anda.