KAL
Menu

Pod Multi-Container

Pola Pod dengan beberapa container: sidecar, volume bersama, dan jaringan yang dipakai bersama.

Daftar isi

Pod dapat memuat lebih dari satu container yang berjalan sebagai satu kesatuan, dan pola penyusunan beberapa container ini menjadi dasar banyak desain aplikasi di Kubernetes. Topik ini membahas kapan penambahan container kedua tepat dilakukan, pola sidecar beserta manifest lengkapnya, peran volume bersama dan jaringan localhost, serta pola penolong lain seperti init container. Struktur manifestnya dibaca ulang secara terprogram sehingga pembagian peran antarcontainer dapat diverifikasi.

Kapan Pod memerlukan beberapa container#

Penambahan container kedua di dalam Pod bergantung pada satu prinsip, yaitu keterikatan fungsi. Container penolong layak digabung apabila kebutuhannya melekat langsung pada container utama, misalnya membaca berkas yang dihasilkan container utama, melayani trafik milik container utama, atau menyegarkan konfigurasinya. Container semacam ini berbagi siklus hidup, sehingga dibuat dan dihentikan bersama container utamanya.

Memahami kebutuhan bersama ini membantu saat menentukan jumlah container. Permintaan sumber daya dihitung per container, tetapi penjadwalannya mencakup seluruh Pod, sehingga penambahan container penolong menambah kebutuhan total Pod pada Node. Komunikasi antarcontainer juga tidak memerlukan konfigurasi jaringan tambahan karena seluruhnya berbagi lingkup jaringan Pod. Dua sifat tersebut membuat penggabungan menguntungkan bagi fungsi yang rapat, dan menjadi beban bagi fungsi yang longgar.

Pembagian sebaliknya berlaku untuk komponen yang mandiri. Web server dan database menuntut pola penskalaan serta kebutuhan sumber daya yang berbeda, sehingga keduanya ditempatkan pada Pod yang terpisah. Menggabungkan keduanya dalam satu Pod menyebabkan database ikut dimulai ulang setiap kali web server diperbarui, dan Pod tidak dapat diskalakan secara terpisah. Prinsip akhirnya sederhana, yaitu satu Pod hanya menampung komponen yang harus naik dan turun bersama.

Pola sidecar#

Pola sidecar adalah pola multi-container yang paling umum. Sidecar adalah container penolong yang menambah atau memperluas fungsi container utama di dalam Pod yang sama dan berjalan selama Pod hidup. Tugas yang lazim diserahkan ke sidecar meliputi pengarsipan log, pengiriman log ke sistem terpusat, penerapan proksi lokal, dan penyegaran konfigurasi.

Contoh pada topik ini menyandingkan container web berbasis nginx dengan sidecar pengarsip log berbasis busybox. Container web menulis log akses ke volume bersama, sedangkan sidecar membaca volume yang sama dan mengemas isinya menjadi arsip tar terkompresi setiap enam puluh detik ke volume arsip terpisah. Manifest pod-sidecar.yaml berikut mendeklarasikan susunan tersebut.

yaml pod-sidecar.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: web-dengan-arsip
  labels:
    app: web
spec:
  containers:
    - name: web
      image: nginx:1.27
      ports:
        - containerPort: 80
      volumeMounts:
        - name: log-bersama
          mountPath: /var/log/nginx
    - name: pengarsip
      image: busybox:1.36
      command:
        - sh
        - -c
        - while true; do tar czf /arsip/log-$(date +%H%M).tar.gz /log; sleep 60; done
      volumeMounts:
        - name: log-bersama
          mountPath: /log
        - name: arsip
          mountPath: /arsip
  volumes:
    - name: log-bersama
      emptyDir: {}
    - name: arsip
      emptyDir: {}

Kunci spec.volumes mendeklarasikan dua volume efemeral bertipe emptyDir, yaitu log-bersama dan arsip. Container web memasang log-bersama pada /var/log/nginx, sedangkan sidecar memasang volume yang sama pada /log dan volume arsip pada /arsip. Nama volume menjadi penghubung antara deklarasi di tingkat Pod dan pemasangan di tingkat container, sehingga nama yang tidak cocok membuat pemasangan gagal.

Volume bersama dan jaringan localhost#

Berbagi volume memungkinkan kedua container bertukar berkas tanpa melewati jaringan. Karakteristik ini menjadi fondasi pola sidecar, karena container utama dan sidecar dapat bekerja pada berkas yang sama secara serentak. Volume emptyDir hidup selama Pod hidup, sehingga isi arsip ikut hilang apabila Pod dihapus. Arsip yang harus dipertahankan lebih lama disimpan pada volume bertahan, misalnya PersistentVolume.

Jaringan Pod juga digunakan bersama. Kedua container menerima satu alamat IP yang sama dan dapat saling memanggil melalui localhost, sehingga sidecar dapat meneruskan trafik ke container utama tanpa alamat tambahan. Konsekuensinya, ruang port dibagi bersama. Dua container dalam satu Pod tidak boleh mendengarkan port yang sama.

Struktur manifest multi-container dapat dibaca ulang untuk memastikan setiap container memperoleh pemasangan yang benar. Skrip Python berikut mem-parse pod-sidecar.yaml, kemudian mencetak setiap container beserta port dan volumeMounts-nya.

python baca-multi-container.py 
"""Membaca pod-sidecar.yaml dan menampilkan container beserta volumeMounts-nya."""
import yaml

with open("pod-sidecar.yaml") as berkas:
    manifest = yaml.safe_load(berkas)

print(f"pod       : {manifest['metadata']['name']}")
print(f"container : {len(manifest['spec']['containers'])}")
print()
for container in manifest["spec"]["containers"]:
    print(f"[{container['name']}] image {container['image']}")
    for port in container.get("ports", []):
        print(f"  port         : {port['containerPort']}")
    for mount in container.get("volumeMounts", []):
        print(f"  volumeMounts : {mount['name']} -> {mount['mountPath']}")
text Keluaran 
pod       : web-dengan-arsip
container : 2

[web] image nginx:1.27
  port         : 80
  volumeMounts : log-bersama -> /var/log/nginx
[pengarsip] image busybox:1.36
  volumeMounts : log-bersama -> /log
  volumeMounts : arsip -> /arsip

Keluaran tersebut menegaskan pembagian perannya. Container web mengekspos port 80 dan hanya memasang volume log-bersama, sedangkan pengarsip tidak mengekspos port apa pun dan memasang dua volume sekaligus. Tidak ada mountPath yang tumpang tindih, sehingga kedua container dapat berjalan tanpa berkas kerjanya saling mengganggu.

Init container dan pola penolong lain#

Selain sidecar, Kubernetes menyediakan init container, yaitu container yang berjalan sampai selesai sebelum container aplikasi dimulai. Tugas yang lazim diberikan meliputi menunggu ketersediaan dependensi dan menyiapkan berkas awal. Init container berhenti setelah tugasnya tuntas, berbeda dengan sidecar yang berjalan terus selama Pod hidup.

Pemilihan antara keduanya mengikuti durasi tugasnya. Tugas yang harus tuntas sebelum aplikasi dijalankan masuk ke init container, sedangkan tugas yang harus berjalan terus masuk ke sidecar. Keduanya dapat digabung dalam satu Pod, misalnya penyiapan berkas konfigurasi oleh init container diikuti pengarsipan log oleh sidecar setelahnya.

Dua pola penolong lain mengikuti kerangka yang sama. Pola ambassador menempatkan proksi lokal yang meneruskan panggilan container utama menuju layanan eksternal, sehingga container utama hanya berkomunikasi dengan localhost. Pola adapter menyunting keluaran container utama, misalnya mengubah format log menjadi format yang diminta sistem pemantauan. Ketiganya berbagi satu prinsip: fungsi penolong ditempatkan di dalam Pod karena terikat erat pada fungsi utamanya.

Ringkasan#

  • Container kedua layak dimasukkan ke Pod hanya apabila fungsinya melekat erat pada container utama dan harus naik turun bersama.
  • Pola sidecar menambahkan container penolong yang berjalan terus, dengan pertukaran berkas melalui volume bersama dan panggilan antarcontainer melalui localhost.
  • Volume dideklarasikan di tingkat Pod dan dapat dipasang ke container mana pun, sedangkan ruang port dibagi bersama sehingga penggunaan port yang sama memicu error.
  • Init container berjalan sampai selesai sebelum aplikasi dimulai, dan pola ambassador serta adapter memperluas kerangka penolong yang sama.

Referensi#