Kubernetes Init Containers Nedir?

Her ne kadar pod başına bir container önerilse de bazı durumlar için bir podun içerisinde birden fazla container olabilir.

En basit örneği ile, istio kurduğunuzda ( namespace labellarını ekledikten sonra ) podlarınızın içerisindeki container sayısının bir arttığını görürsünüz bunun sebebi pod içine envoy proxy koymasıdır.

İyi, güzel, hoş da bu init ne?

Init containerları da aynı normal containerlar gibidir. En önemli farkı, init containerı başarıyla bitmeden bir sonraki ( bizim ana istediğimiz ) containerlar başlayamaz. Eğer init containerı hata alırsa, hata gidene kadar pod onu restart eder. ( restartPolicy belirtilmediyse ) Ayrıca init containerları  lifecycle, livenessProbe, readinessProbe ve startupProbe 'u desteklemez.

apiVersion: v1
kind: Pod
metadata:
  name: kubernetesturkey
  labels:
    app: kubernetesturkey
spec:
  containers:
  - name: k8sturkey-container
    image: busybox:1.28
    command: ['sh', '-c', 'echo Hello World! && sleep 3600']
  initContainers:
  - name: init-myservice
    image: busybox:1.28
    command: ['sh', '-c', "until nslookup kubernetesturkey.com; do echo waiting for myservice; sleep 2; done"]

Gelin adım adım kubectl apply sonrasını inceleyelim;

1- Kubelet; network ve storage hazır olana kadar podu bekletir,

2- Init containerları yukardan aşağıya olucak şekilde çalıştırır, ( bir sonraki containerın başlayabilmesi için bir önceki init containerının exit 0 almış olması gerekiyor. )

Not: Pod, init containerları çalışırken ready durumuna geçmez ve servisten trafik almaz, dolayısıyla portu kapalıdır.

3- Bütün init containerları bittikten sonra pod çalışmaya başlar ve diğer container/containerlarını kaldırır.

Not: Eğer pod bir şekilde restart ederse bütün init containerların baştan çalışması gerekiyor.

Kullanım Alanı

Benim aklıma gelen bazı potansiyel kullanım alanları;

-> Dns servisimizin ayakta olup/olmadığını anlamak, değilse pod'u bekletmek.

-> Db, redis, rabbit gibi statefull servislerimizin ayakta ve erişilebilir olduklarını kontrol etmek

-> Gerekli bazı dosyaların ftp'den çekilmesi

-> Mount vb gibi işlemler

-> Versiyon güncellemesi öncesi, migration betiklerinin çalıştırılarak migration sürecinin otomatikleştirilmesi. ( Orn db'de versiyon tutup, bir bash betiği bu versiyonu kendi versiyonu ile karşılaştırıp, eğer kendisininkinden eskiyse, alter, insert vb gibi komutları çalıştırması olabilir.)

BONUS

CKA sınavında bununla ilgili bir soru vardı 🙂