Menulis Kubernetes Manifest: Dari Pemula hingga Mahir
Kubernetes telah menjadi platform orkestrasi kontainer de facto, dan pemahaman yang mendalam tentang cara menulis Kubernetes Manifest adalah kunci untuk menggunakan kekuatan penuhnya. Artikel ini akan memandu Anda dari dasar-dasar hingga konsep lanjutan, memastikan Anda memiliki keterampilan yang diperlukan untuk mendefinisikan dan mengelola aplikasi Anda secara efektif di Kubernetes.
Daftar Isi
- Pendahuluan: Mengapa Kubernetes Manifest Penting?
- Dasar-Dasar Kubernetes Manifest
- Jenis Resource Kubernetes Umum
- Teknik Deployment Tingkat Lanjut
- Konfigurasi Tingkat Lanjut
- Otomatisasi dan Templating
- Praktik Terbaik dalam Menulis Kubernetes Manifest
- Troubleshooting Umum
- Kesimpulan: Kekuatan Manifest Kubernetes
- Sumber Daya Tambahan
1. Pendahuluan: Mengapa Kubernetes Manifest Penting?
Kubernetes Manifest, yang sering ditulis dalam YAML, adalah jantung dan jiwa dari deployment Kubernetes Anda. Mereka adalah file deklaratif yang menentukan keadaan yang diinginkan dari aplikasi Anda: Pod mana yang harus berjalan, berapa banyak replika yang dibutuhkan, bagaimana aplikasi harus diekspos, dan banyak lagi. Tanpa manifest yang terdefinisi dengan baik, mengelola dan menskalakan aplikasi di Kubernetes akan menjadi sangat sulit.
Berikut adalah beberapa alasan mengapa Kubernetes Manifest sangat penting:
- Deklaratif vs. Imperatif: Manifest bersifat deklaratif, artinya Anda menentukan apa yang ingin Anda capai, bukan bagaimana cara mencapainya. Kubernetes kemudian mengambil alih untuk mewujudkan keadaan yang diinginkan.
- Reproducibility: Manifest memungkinkan Anda untuk mereproduksi lingkungan yang sama di berbagai kluster. Cukup terapkan manifest, dan Kubernetes akan menangani sisanya.
- Version Control: Manifest disimpan sebagai file teks, yang memungkinkan Anda untuk melacak perubahan menggunakan sistem kontrol versi seperti Git.
- Automation: Manifest dapat diotomatisasi dengan alat CI/CD, memungkinkan Anda untuk mengotomatiskan proses deployment Anda.
- Scalability dan Management: Manifest memungkinkan Anda untuk mendefinisikan aturan penskalaan, kebijakan pembaruan, dan parameter konfigurasi, menyederhanakan manajemen aplikasi Anda.
2. Dasar-Dasar Kubernetes Manifest
Bagian ini mencakup dasar-dasar membuat dan menerapkan Kubernetes Manifest.
2.1 Struktur Dasar YAML
Kubernetes Manifest ditulis dalam YAML (YAML Ain’t Markup Language), format serialisasi data yang mudah dibaca manusia. Berikut adalah beberapa konsep dasar YAML yang perlu Anda ketahui:
- Indentation: Indentasi digunakan untuk menunjukkan hierarki. Gunakan spasi (biasanya dua) untuk indentasi; jangan gunakan tab.
- Key-Value Pairs: Data direpresentasikan sebagai pasangan kunci-nilai.
- Lists: Daftar ditunjukkan dengan tanda hubung (`-`).
- Comments: Komentar dimulai dengan tanda pagar (`#`).
Contoh YAML sederhana:
name: My Application
version: 1.0
dependencies:
- library1
- library2
# This is a comment
2.2 Memahami `apiVersion`, `kind`, dan `metadata`
Setiap Kubernetes Manifest membutuhkan tiga bidang tingkat atas berikut:
- `apiVersion`: Versi API Kubernetes yang digunakan untuk membuat resource ini. Ini penting karena API Kubernetes berevolusi dari waktu ke waktu. Anda dapat menemukan versi API yang benar di dokumentasi Kubernetes.
- `kind`: Jenis resource Kubernetes yang ingin Anda buat (misalnya, `Pod`, `Deployment`, `Service`).
- `metadata`: Data tentang resource, seperti nama, namespace, dan label.
Contoh:
apiVersion: v1
kind: Pod
metadata:
name: my-pod
labels:
app: my-app
2.3 Contoh Manifest Sederhana: Membuat Pod
Berikut adalah contoh Kubernetes Manifest untuk membuat Pod sederhana yang menjalankan container Nginx:
apiVersion: v1
kind: Pod
metadata:
name: nginx-pod
labels:
app: nginx
spec:
containers:
- name: nginx-container
image: nginx:latest
ports:
- containerPort: 80
Dalam manifest ini:
- `apiVersion: v1` menentukan bahwa kita menggunakan versi `v1` dari Core API.
- `kind: Pod` menentukan bahwa kita membuat Pod.
- `metadata.name: nginx-pod` memberi nama Pod `nginx-pod`.
- `metadata.labels` menambahkan label ke Pod, yang dapat digunakan untuk pemilihan dan organisasi.
- `spec.containers` menentukan daftar container yang akan dijalankan di dalam Pod. Dalam hal ini, kita hanya memiliki satu container, `nginx-container`.
- `image: nginx:latest` menentukan gambar Docker yang akan digunakan untuk container, yaitu gambar `nginx` terbaru.
- `ports` mengekspos port 80 dari container.
2.4 Menggunakan `kubectl` untuk Menerapkan Manifest
`kubectl` adalah alat baris perintah Kubernetes yang memungkinkan Anda untuk berinteraksi dengan kluster Kubernetes Anda. Untuk menerapkan manifest, gunakan perintah `kubectl apply -f
Misalnya, untuk menerapkan manifest di atas, simpan ke file bernama `nginx-pod.yaml` dan jalankan:
kubectl apply -f nginx-pod.yaml
Untuk melihat Pod, jalankan:
kubectl get pods
Untuk menghapus Pod, jalankan:
kubectl delete -f nginx-pod.yaml
3. Jenis Resource Kubernetes Umum
Kubernetes memiliki berbagai jenis resource yang dapat Anda gunakan untuk mendefinisikan aplikasi Anda. Berikut adalah beberapa yang paling umum:
3.1 Pod: Unit Penyebaran Terkecil
Seperti yang telah kita lihat, Pod adalah unit penyebaran terkecil di Kubernetes. Pod dapat berisi satu atau lebih container, yang berbagi sumber daya jaringan dan penyimpanan.
3.2 Deployment: Mengelola Pod Replika
Deployment mengelola replika Pod, memastikan jumlah replika yang diinginkan selalu berjalan. Deployment juga menyediakan fitur seperti rolling update dan rollback.
Contoh Deployment:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx-container
image: nginx:latest
ports:
- containerPort: 80
Dalam manifest ini:
- `apiVersion: apps/v1` menentukan bahwa kita menggunakan versi `v1` dari API `apps`.
- `kind: Deployment` menentukan bahwa kita membuat Deployment.
- `replicas: 3` menentukan bahwa kita ingin menjalankan tiga replika Pod.
- `selector.matchLabels` menentukan label yang harus cocok dengan Pod yang dikelola oleh Deployment.
- `template` mendefinisikan template Pod yang akan dibuat oleh Deployment.
3.3 Service: Mengekspos Aplikasi Anda
Service menyediakan cara yang stabil untuk mengakses Pod Anda. Service menetapkan alamat IP dan nama DNS ke sekumpulan Pod, dan menyeimbangkan lalu lintas di antara Pod tersebut.
Contoh Service:
apiVersion: v1
kind: Service
metadata:
name: nginx-service
spec:
selector:
app: nginx
ports:
- protocol: TCP
port: 80
targetPort: 80
type: LoadBalancer
Dalam manifest ini:
- `selector` menentukan Pod mana yang akan dipilih oleh Service berdasarkan label.
- `ports` menentukan port yang akan diekspos oleh Service.
- `targetPort` menentukan port pada container yang akan diteruskan lalu lintas.
- `type: LoadBalancer` mengekspos Service secara eksternal menggunakan load balancer cloud provider. Opsi lain termasuk `ClusterIP` (hanya dapat diakses di dalam kluster) dan `NodePort` (dapat diakses melalui port di setiap node).
3.4 ConfigMap: Mengelola Konfigurasi
ConfigMap memungkinkan Anda untuk memisahkan konfigurasi dari kode aplikasi Anda. ConfigMap menyimpan data konfigurasi dalam pasangan kunci-nilai, yang dapat diakses oleh Pod Anda.
Contoh ConfigMap:
apiVersion: v1
kind: ConfigMap
metadata:
name: my-config
data:
database_url: "jdbc:mysql://localhost:3306/mydb"
log_level: "INFO"
Anda kemudian dapat me-mount ConfigMap sebagai volume ke dalam Pod Anda, atau menggunakan variabel lingkungan untuk mengakses nilai.
3.5 Secret: Mengelola Data Sensitif
Secret mirip dengan ConfigMap, tetapi dirancang untuk menyimpan data sensitif seperti kata sandi, token API, dan kunci SSH. Secret dienkripsi saat tidak digunakan dan dapat diakses oleh Pod Anda dengan cara yang sama seperti ConfigMap.
Contoh Secret:
apiVersion: v1
kind: Secret
metadata:
name: my-secret
type: Opaque
data:
database_password: $(echo -n "mysecretpassword" | base64)
Dalam contoh ini, kata sandi di-base64 untuk disamarkan. Penting untuk menggunakan solusi yang lebih aman untuk mengelola Secret di lingkungan produksi, seperti HashiCorp Vault atau penyedia cloud-native secret management.
4. Teknik Deployment Tingkat Lanjut
Setelah Anda memahami dasar-dasar Deployment, Anda dapat menggunakan teknik yang lebih canggih untuk meningkatkan ketersediaan dan meminimalkan downtime.
4.1 Rolling Updates: Tanpa Downtime Deployment
Rolling update adalah strategi deployment yang secara bertahap memperbarui replika Pod Anda ke versi baru. Kubernetes membuat Pod baru dengan versi baru dan secara bertahap menghapus Pod lama, memastikan aplikasi Anda tetap tersedia sepanjang proses pembaruan.
Rolling update adalah strategi default untuk Deployment Kubernetes.
Contoh konfigurasi rolling update dalam Deployment:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx-container
image: nginx:1.21 # Update the image version
ports:
- containerPort: 80
Dalam contoh ini:
- `strategy.type: RollingUpdate` menentukan bahwa kita menggunakan strategi rolling update.
- `rollingUpdate.maxSurge: 1` menentukan jumlah maksimum Pod yang dapat dibuat di atas jumlah replika yang diinginkan selama pembaruan.
- `rollingUpdate.maxUnavailable: 0` menentukan jumlah maksimum Pod yang dapat tidak tersedia selama pembaruan.
4.2 Rollback: Memulihkan ke Versi Sebelumnya
Jika rolling update gagal, Anda dapat melakukan rollback ke versi sebelumnya dari Deployment Anda. Kubernetes menyimpan riwayat revisi Deployment Anda, sehingga mudah untuk melakukan rollback.
Untuk melakukan rollback, gunakan perintah `kubectl rollout undo deployment/
kubectl rollout undo deployment/nginx-deployment
Anda dapat menentukan revisi tertentu untuk di-rollback dengan menambahkan `–to-revision=
kubectl rollout undo deployment/nginx-deployment --to-revision=2
4.3 Canary Deployments: Menguji Versi Baru dengan Sebagian Traffic
Canary deployment adalah strategi yang memungkinkan Anda untuk menguji versi baru aplikasi Anda dengan sebagian kecil lalu lintas pengguna sebelum meluncurkannya ke semua orang. Hal ini memungkinkan Anda untuk mengidentifikasi dan memperbaiki masalah sebelum mereka memengaruhi basis pengguna yang besar.
Untuk melakukan canary deployment, Anda dapat membuat Deployment kedua dengan versi baru aplikasi Anda dan merutekan sebagian lalu lintas ke Deployment baru ini menggunakan Service.
Contoh sederhana:
- Buat Deployment utama: Deployment ini menjalankan versi stabil aplikasi Anda.
- Buat Deployment canary: Deployment ini menjalankan versi baru aplikasi Anda dengan jumlah replika yang lebih sedikit.
- Konfigurasikan Service: Service merutekan sebagian lalu lintas ke Deployment canary. Ini dapat dilakukan menggunakan label dan selector Service. Misalnya, Anda dapat memberi label Pod canary dengan `version: canary` dan mengonfigurasi Service untuk merutekan 10% lalu lintas ke Pod dengan label ini.
4.4 Blue/Green Deployments: Deployment Paralel dengan Peralihan Instan
Blue/green deployment melibatkan menjalankan dua versi identik dari aplikasi Anda secara paralel: lingkungan “biru” (versi saat ini) dan lingkungan “hijau” (versi baru). Setelah lingkungan hijau diverifikasi dan siap, Anda mengalihkan lalu lintas dari lingkungan biru ke lingkungan hijau.
Strategi ini menyediakan rollback instan: Jika ada masalah dengan lingkungan hijau, Anda dapat dengan cepat mengalihkan lalu lintas kembali ke lingkungan biru.
Untuk melakukan blue/green deployment, Anda dapat menggunakan dua Deployment terpisah dan mengalihkan lalu lintas menggunakan Service atau load balancer eksternal.
5. Konfigurasi Tingkat Lanjut
Bagian ini mencakup konfigurasi tingkat lanjut untuk meningkatkan keandalan dan efisiensi aplikasi Anda.
5.1 Liveness dan Readiness Probes: Memastikan Aplikasi Sehat
Liveness probe memeriksa apakah container Anda berjalan dengan baik. Jika liveness probe gagal, Kubernetes akan memulai ulang container.
Readiness probe memeriksa apakah container siap untuk melayani lalu lintas. Jika readiness probe gagal, Kubernetes akan berhenti mengirimkan lalu lintas ke container.
Contoh konfigurasi liveness dan readiness probe:
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: my-container
image: my-image
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 3
periodSeconds: 10
readinessProbe:
httpGet:
path: /readyz
port: 8080
initialDelaySeconds: 5
periodSeconds: 10
Dalam contoh ini:
- `livenessProbe.httpGet` menentukan bahwa liveness probe melakukan permintaan HTTP ke jalur `/healthz` di port 8080.
- `initialDelaySeconds: 3` menentukan bahwa probe akan mulai diperiksa 3 detik setelah container dimulai.
- `periodSeconds: 10` menentukan bahwa probe akan diperiksa setiap 10 detik.
- `readinessProbe` dikonfigurasi serupa, tetapi menggunakan jalur `/readyz`.
5.2 Permintaan dan Batas Sumber Daya: Manajemen Sumber Daya Efisien
Anda dapat menentukan permintaan dan batas sumber daya untuk container Anda untuk memastikan bahwa mereka memiliki sumber daya yang cukup untuk berjalan dengan baik, dan mencegah mereka menggunakan terlalu banyak sumber daya.
- Requests: Jumlah minimum sumber daya (CPU dan memori) yang dijamin akan dialokasikan untuk container.
- Limits: Jumlah maksimum sumber daya yang dapat digunakan oleh container. Jika container mencoba menggunakan lebih banyak sumber daya daripada batasnya, Kubernetes dapat membatasi atau bahkan menghentikannya.
Contoh konfigurasi permintaan dan batas sumber daya:
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: my-container
image: my-image
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 500m
memory: 256Mi
Dalam contoh ini:
- `requests.cpu: 100m` menentukan bahwa container meminta 100 milicore CPU.
- `requests.memory: 128Mi` menentukan bahwa container meminta 128 MB memori.
- `limits.cpu: 500m` menentukan bahwa container dibatasi hingga 500 milicore CPU.
- `limits.memory: 256Mi` menentukan bahwa container dibatasi hingga 256 MB memori.
5.3 Node Affinity dan Taints: Penjadwalan Lanjutan
Node affinity memungkinkan Anda untuk mengontrol node mana yang akan dijalankan oleh Pod Anda berdasarkan label node.
Taints adalah kebalikan dari affinity; mereka memungkinkan Anda untuk menolak Pod untuk dijalankan pada node tertentu kecuali mereka memiliki toleransi yang cocok.
Contoh konfigurasi node affinity:
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: node-type
operator: In
values:
- worker
Dalam contoh ini, Pod hanya akan dijadwalkan pada node yang memiliki label `node-type: worker`.
Contoh konfigurasi toleransi untuk taint:
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
tolerations:
- key: "node.kubernetes.io/unreachable"
operator: "Exists"
effect: "NoExecute"
Ini memungkinkan pod untuk terus berjalan bahkan jika node menjadi tidak terjangkau.
5.4 Init Containers: Inisialisasi Sebelum Aplikasi
Init containers adalah container khusus yang berjalan sebelum container aplikasi utama. Mereka dapat digunakan untuk menginisialisasi lingkungan, mengunduh file konfigurasi, atau melakukan tugas persiapan lainnya.
Contoh konfigurasi init container:
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
initContainers:
- name: init-myservice
image: busybox:1.28
command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2; done;']
containers:
- name: my-container
image: my-image
Dalam contoh ini, init container menunggu hingga Service `myservice` tersedia sebelum container aplikasi utama dimulai.
6. Otomatisasi dan Templating
Menulis dan mengelola Kubernetes Manifest secara manual bisa menjadi rumit, terutama untuk aplikasi yang kompleks. Alat otomasi dan templating dapat membantu menyederhanakan proses ini.
6.1 Helm: Package Manager untuk Kubernetes
Helm adalah package manager untuk Kubernetes. Helm memungkinkan Anda untuk mengemas, mengonfigurasi, dan menerapkan aplikasi Kubernetes sebagai “chart”. Chart adalah kumpulan file manifest Kubernetes yang disatukan.
Helm menyediakan fitur berikut:
- Templating: Helm menggunakan templating untuk memungkinkan Anda untuk mengkustomisasi manifest Kubernetes Anda menggunakan variabel.
- Version Control: Helm melacak versi chart Anda, sehingga mudah untuk melakukan rollback ke versi sebelumnya.
- Sharing: Helm memungkinkan Anda untuk berbagi chart Anda dengan orang lain.
6.2 Kustomize: Mengkustomisasi Manifest YAML
Kustomize adalah alat yang memungkinkan Anda untuk mengkustomisasi manifest YAML Kubernetes tanpa menggunakan templating. Kustomize menggunakan overlay untuk menerapkan perubahan ke manifest dasar.
Kustomize merupakan fitur bawaan dari `kubectl` mulai dari versi 1.14.
Kustomize menyediakan fitur berikut:
- Overlay: Kustomize menggunakan overlay untuk menerapkan perubahan ke manifest dasar. Ini memungkinkan Anda untuk mengkustomisasi manifest tanpa memodifikasi manifest dasar.
- Composition: Kustomize memungkinkan Anda untuk menggabungkan beberapa overlay untuk membuat konfigurasi yang kompleks.
6.3 Jsonnet: Bahasa Konfigurasi Data
Jsonnet adalah bahasa konfigurasi data yang kuat yang dapat digunakan untuk membuat manifest Kubernetes. Jsonnet memungkinkan Anda untuk menulis konfigurasi yang kompleks dan dinamis dengan cara yang mudah dibaca dan dikelola.
Jsonnet menyediakan fitur berikut:
- Functions: Jsonnet mendukung fungsi, yang memungkinkan Anda untuk membuat konfigurasi yang reusable.
- Variables: Jsonnet mendukung variabel, yang memungkinkan Anda untuk mengkustomisasi konfigurasi Anda.
- Imports: Jsonnet mendukung impor, yang memungkinkan Anda untuk memecah konfigurasi Anda menjadi beberapa file.
7. Praktik Terbaik dalam Menulis Kubernetes Manifest
Mengikuti praktik terbaik saat menulis Kubernetes Manifest dapat membantu Anda untuk menghindari masalah umum dan memastikan bahwa aplikasi Anda berjalan dengan baik.
7.1 Versi Kontrol Manifest Anda
Selalu simpan Kubernetes Manifest Anda dalam sistem kontrol versi seperti Git. Ini memungkinkan Anda untuk melacak perubahan, melakukan rollback ke versi sebelumnya, dan berkolaborasi dengan orang lain.
7.2 Validasi Manifest Sebelum Penerapan
Validasi manifest Anda sebelum menerapkannya ke kluster Kubernetes Anda. Ini dapat membantu Anda untuk mengidentifikasi kesalahan sintaks dan kesalahan konfigurasi lainnya.
Anda dapat menggunakan alat seperti `kubectl apply –dry-run=client -f
7.3 Dokumentasikan Manifest Anda
Dokumentasikan manifest Anda dengan jelas dan ringkas. Ini akan membantu orang lain untuk memahami dan mengelola aplikasi Anda.
Gunakan komentar untuk menjelaskan tujuan dari setiap bagian dari manifest Anda.
7.4 Pertimbangan Keamanan
Perhatikan keamanan saat menulis Kubernetes Manifest. Hindari menyimpan data sensitif di manifest Anda. Gunakan Secret untuk menyimpan kata sandi, token API, dan kunci SSH.
Terapkan kebijakan RBAC (Role-Based Access Control) untuk membatasi akses ke sumber daya Kubernetes Anda.
8. Troubleshooting Umum
Berikut adalah beberapa masalah umum yang mungkin Anda temui saat menulis Kubernetes Manifest dan cara mengatasinya.
8.1 Kesalahan Sintaks YAML
Kesalahan sintaks YAML adalah salah satu kesalahan paling umum saat menulis Kubernetes Manifest. Pastikan bahwa manifest Anda valid dan diformat dengan benar.
Gunakan alat validasi YAML untuk mengidentifikasi kesalahan sintaks.
8.2 Masalah Konektivitas Jaringan
Masalah konektivitas jaringan dapat mencegah Pod Anda untuk berkomunikasi satu sama lain atau dengan layanan eksternal.
Pastikan bahwa layanan Anda dikonfigurasi dengan benar dan bahwa firewall tidak memblokir lalu lintas.
8.3 Sumber Daya Tidak Cukup
Jika Pod Anda tidak memiliki sumber daya yang cukup (CPU atau memori), mereka mungkin gagal dimulai atau mogok.
Tingkatkan permintaan dan batas sumber daya untuk Pod Anda.
9. Kesimpulan: Kekuatan Manifest Kubernetes
Menulis Kubernetes Manifest yang efektif adalah keterampilan penting bagi siapa pun yang bekerja dengan Kubernetes. Dengan memahami dasar-dasar, menjelajahi teknik tingkat lanjut, dan mengikuti praktik terbaik, Anda dapat mengelola dan menskalakan aplikasi Anda secara efisien di Kubernetes. Dari definisi dasar Pod hingga strategi deployment yang kompleks, manifest Kubernetes adalah kunci untuk membuka kekuatan penuh platform orkestrasi kontainer ini.
10. Sumber Daya Tambahan
“`
