Kubernetes Native Sidecar Containers: Panduan Praktis

Selama bertahun-tahun sidecar hanyalah sebuah pola, bukan fitur. Anda menambahkan container kedua ke sebuah Pod — pengirim log, proxy service mesh, eksportir metrik — lalu berharap ia berperilaku baik. Kubernetes tidak punya konsep sidecar, jadi container kedua itu diperlakukan persis seperti aplikasi utama Anda. Perlakuan setara itulah sumber masalahnya, dan itulah yang akhirnya dihilangkan oleh fitur native sidecar.

Saya pernah mengalami kedua mode kegagalan klasik di produksi: proxy yang belum siap saat aplikasi melakukan panggilan keluar pertamanya, dan Job batch yang berjalan selamanya karena sidecar logging-nya tidak pernah berhenti. Native sidecar container mengatasi keduanya dengan memberi container tambahan siklus hidup yang teratur, alih-alih berpura-pura mereka hanyalah container aplikasi biasa.

Mengapa pola sidecar lama menyakitkan

Pola ad-hoc tidak punya urutan maupun kesadaran siklus hidup. Semua container dalam sebuah Pod mulai kira-kira secara paralel dan diperlakukan setara, yang menghasilkan tiga masalah berulang.

• Balapan startup: container utama bisa mulai sebelum proxy mesh atau agen autentikasi siap, sehingga permintaan awal gagal sampai sidecar menyusul. Tim menutupinya dengan loop retry dan skrip init.
• Job yang tidak pernah selesai: sebuah Job dianggap selesai ketika container-nya berhenti, tetapi sidecar logging atau proxy dirancang berjalan selamanya. Tugas utama selesai, sidecar tetap berjalan, dan Job menggantung tanpa henti — masalah nyata untuk beban kerja batch dan AI/ML.
• Shutdown berantakan: saat terminasi tidak ada jaminan aplikasi berhenti sebelum proxy. Jika proxy mati lebih dulu, permintaan yang sedang berjalan dan baris log terakhir hilang selama jendela graceful shutdown.

Cara kerja fitur native

Wawasan di balik KEP-753 adalah bahwa sidecar sebenarnya init container yang istimewa. Init container sudah punya urutan startup sekuensial yang jelas, jadi membangun sidecar di atasnya memberi urutan secara gratis. Anda menambahkan satu field — restartPolicy bernilai Always — ke sebuah entri di daftar initContainers Pod, dan container itu menjadi sidecar.

Satu field itu mengubah tiga perilaku. Kubelet menandai init container sebagai started lalu lanjut ke berikutnya alih-alih menunggunya keluar, sehingga container aplikasi Anda mulai hanya setelah sidecar aktif. Sidecar kemudian tetap berjalan sepanjang umur Pod dan di-restart sendiri jika crash. Saat terminasi, kubelet menghentikan container utama lebih dulu, lalu mematikan sidecar dalam urutan terbalik dari deklarasinya.

Contoh YAML

Berikut sebuah Deployment dengan sidecar log-shipper. Ia berada di bawah initContainers, tetapi restartPolicy Always membuatnya tetap berjalan berdampingan dengan aplikasi. Sebuah startupProbe membuat kubelet menahan container utama sampai shipper benar-benar siap, bukan sekadar dibuat.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: registry.example.com/web:1.6.0
          ports:
            - containerPort: 8080
          volumeMounts:
            - name: logs
              mountPath: /var/log/app
      initContainers:
        # restartPolicy: Always turns this init container into a
        # native sidecar: it starts before "web", stays running for
        # the whole Pod lifetime, and shuts down after "web" exits.
        - name: log-shipper
          image: registry.example.com/log-shipper:2.1.0
          restartPolicy: Always
          startupProbe:
            httpGet:
              path: /healthz
              port: 3000
          volumeMounts:
            - name: logs
              mountPath: /var/log/app
      volumes:
        - name: logs
          emptyDir: {}

Blok yang sama bekerja pada sebuah Job. Karena sidecar adalah init container dengan restartPolicy Always, terminasi Pod kini hanya bergantung pada container utama — ketika tugas batch selesai, Job selesai dan sidecar dimatikan otomatis. Tidak ada lagi Job yang macet dalam keadaan running menunggu sidecar yang tidak pernah keluar.

Probe, sumber daya, dan sinyal shutdown

Native sidecar mendukung probe startup, readiness, dan liveness, yang tidak dimiliki init container biasa. readinessProbe sebuah sidecar memengaruhi status ready Pod, sehingga proxy mesh yang tidak sehat membuat Pod tetap di luar endpoint sebuah Service. Permintaan sumber daya dijumlahkan dengan container aplikasi alih-alih dibandingkan, dan penanganan skor OOM disejajarkan dengan container utama sehingga sidecar tidak dibunuh lebih dulu saat tekanan memori.

Hack lama versus native sidecar

Perbedaannya bukan sekadar kosmetik. Pendekatan native memindahkan urutan, siklus hidup, dan shutdown dari solusi tingkat aplikasi ke dalam kubelet, tempat yang semestinya. Tabel ini merangkum apa yang sebenarnya berubah.

Linimasa kematangan dan kapan mengadopsi

Fitur ini punya jalur graduasi yang jelas. Ia hadir sebagai alpha di Kubernetes v1.28 pada Agustus 2023 di balik feature gate SidecarContainers, naik ke beta dan aktif secara default di v1.29, lalu graduasi menjadi stabil di v1.33 yang rilis pada 23 April 2025. Sejak v1.29 Anda dapat memakainya tanpa menyentuh feature gate di sebagian besar cluster.

Saran saya: jika cluster Anda pada v1.29 atau lebih baru, pindahkan proxy mesh, pengirim log, dan agen metrik ke native sidecar sekarang — Anda mendapat urutan yang benar dan shutdown bersih dengan perubahan satu baris. Untuk Job batch dan AI/ML keuntungannya lebih besar lagi, karena menghapus kelas bug Job-tidak-pernah-selesai sepenuhnya. Mulailah dengan satu beban kerja non-kritis, pastikan Pod menjadi ready hanya setelah sidecar aktif, lalu perluas dari sana.