Posisi Kubernetes

Kubernetes adalah platform orkestrasi yang menjadi standar industri untuk menjalankan container di banyak mesin. Topik ini memetakan konsep Docker sepanjang jalur ini ke istilah Kubernetes, lalu membaca satu manifest deployment sederhana milik aplikasi catatan baris demi baris. Setelah membacanya, tiga nama penting pada platform itu tidak lagi terdengar asing, dan hubungannya dengan container serta docker run dapat disebutkan dengan tepat.

Cluster, node, dan control plane#

Kubernetes, yang sering disingkat k8s, mengelola container pada sebuah cluster, yaitu sekumpulan mesin yang dikelola seolah-olah satu komputer. Proyek ini berakar pada pengalaman Google menjalankan container dalam skala besar, lalu dirilis sebagai proyek open source dan kini dikembangkan di bawah naungan CNCF, yayasan yang memayungi banyak proyek infrastruktur terbuka. Setiap mesin anggota disebut node, baik mesin fisik maupun virtual. Pengaturan dilakukan oleh control plane, kelompok proses yang menyimpan keadaan yang diinginkan dan terus menyamakan keadaan nyata dengannya. Model kerjanya deklaratif, yaitu keadaan yang diinginkan dituliskan dalam berkas yang disebut manifest, kemudian control plane mencari jalan menuju keadaan tersebut.

Perbedaan model ini dengan docker run bersifat mendasar. Perintah docker run berjalan sekali dan menghasilkan satu container, sedangkan manifest berfungsi sebagai pernyataan yang terus ditegakkan. Apabila container yang dinyatakan mati atau mesinnya hilang, control plane menganggap keadaan nyata menyimpang dan membuat ulang bagian yang kurang tanpa menunggu perintah. Sifat inilah yang menjadikan manifest sebagai catatan tunggal tentang apa yang seharusnya berjalan.

Padanan konsep Docker#

Tabel berikut memetakan konsep yang telah dibahas jalur ini ke padanannya di Kubernetes. Pemetaannya sengaja dibuat kasar, karena tiap pasangan tidak identik, tetapi cukup untuk membaca dokumentasi Kubernetes tanpa tersesat.

Padanan yang paling perlu dicermati adalah pod. Satu pod biasanya memuat satu container, sehingga dalam praktik keduanya sering dipakai secara bergantian, tetapi unit yang dijadwalkan Kubernetes tetap pod, bukan container. Dua container yang ditempatkan dalam satu pod berbagi alamat IP dan penyimpanan yang sama, misalnya aplikasi catatan yang didampingi container kecil pengirim log, pola pendampingan yang lazim disebut sidecar. Pemisahan ini menyederhanakan keputusan penjadwalan, karena seluruh isi pod selalu berpindah dan hidup bersama.

Deployment dan service masing-masing menjawab kelemahan docker run yang telah dirinci pada modul ini. Deployment mengambil alih peran kombinasi kebijakan restart dan docker run berulang, yaitu menjaga jumlah replika dan mengganti yang gagal. Service mengambil alih DNS antar container pada jaringan kustom. Alamat service tetap sama meskipun pod di belakangnya berganti alamat IP, sehingga aplikasi web tidak pernah menyimpan alamat yang sudah tidak berlaku.

Manifest deployment aplikasi catatan#

Manifest berikut mendeklarasikan tiga replika aplikasi catatan yang ditarik dari registry, gudang penyimpanan dan pendistribusian image. Bentuk manifest berbeda untuk tiap jenis objek, dan objek yang paling sering dipakai untuk aplikasi web adalah Deployment.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: catatan-web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: catatan
  template:
    metadata:
      labels:
        app: catatan
    spec:
      containers:
        - name: web
          image: budi/catatan:1.0.0
          ports:
            - containerPort: 8000
          env:
            - name: DATABASE_URL
              value: postgres://catatan:rahasia-db@db:5432/catatan

Tiap kunci pada manifest di atas memegang satu peran berikut.

• apiVersion dan kind menyatakan jenis objek yang dideklarasikan, yaitu Deployment dari kelompok API apps/v1.
• metadata.name memberi nama catatan-web pada objek, sehingga objek ini dapat dirujuk dengan nama itu.
• spec.replicas menetapkan tiga replika, dan control plane menganggap angka itu sebagai keadaan yang harus selalu terpenuhi.
• selector dan template.metadata.labels menghubungkan deployment dengan pod miliknya melalui label app: catatan.
• spec.containers mendefinisikan isi pod, mulai dari nama container, image dari registry, port yang dibuka, hingga variabel lingkungan DATABASE_URL.

Apabila manifest ini dikirim ke control plane, deployment akan membuat tiga pod yang menjalankan image budi/catatan:1.0.0. Control plane membuat ulang container yang gagal secara otomatis, dan node yang mati menyebabkan pod miliknya dijadwalkan ulang ke tempat lain. Saat image baru dirilis, cukup mengubah baris image pada manifest, dan deployment menjalankan rolling update, penggantian replika lama satu per satu sehingga layanan tidak pernah kosong.

Panjang manifest ini memang terasa berlebihan dibandingkan service yang setara pada compose.yaml, dan perbedaannya memiliki alasan. Compose mengatur beberapa container pada satu host, sehingga banyak nilai dapat disepakati secara bawaan, sedangkan manifest Kubernetes menyatakan keadaan lengkap pada banyak mesin, termasuk cara pod dikenali dan diganti. Semakin besar cakupan yang dinyatakan, semakin panjang berkasnya.

Ringkasan#

• Kubernetes mewujudkan keadaan yang dideklarasikan dalam manifest, sedangkan docker run mengeksekusi satu perintah sekali jalan.
• Container dijadwalkan di dalam pod, deployment menjaga jumlah replika dan pembaruan bergulir, sedangkan service memberi alamat dan nama yang stabil.
• Node adalah mesin anggota cluster, dan control plane terus menyamakan keadaan nyata dengan keadaan yang dideklarasikan.

Referensi#

• Pods — Kubernetes Docs — Menjelaskan pod sebagai unit terkecil yang dapat memuat satu atau lebih container.
• Deployments — Kubernetes Docs — Mendokumentasikan replika, label selector, dan pembaruan bergulir pada deployment.
• Concepts — Kubernetes Docs — Ikhtisar konsep cluster, node, dan control plane yang dipetakan di topik ini.