Sidecar, Adapter ve Ambassador Kalıpları

Neden önemli

Gerçek uygulamalar ana sürecin yanında log ajanları, metrik dışa aktarıcılar, yapılandırma yeniden yazıcılar ve bağlantı vekilleri ister. CKAD bunları paylaşımlı birim ve localhost ağıyla tek podda kapsayıcılar olarak kurup kuramadığını ölçer, çünkü üretim Kubernetes gerçekte böyledir: gözlemlenebilirlik istekleriyle temas edince ayakta kalan yalnız tek kapsayıcılı pod azdır.

Kavramlar

Sidecar ana kapsayıcıyı genişletir: aynı yaşam ilgisi, fazla görev. Kuralsal şekil emptyDir birimi paylaşır: uygulama logları paylaşılan yola yazar, sidecar kuyruktan okuyup stdout verir veya ileriye taşır. Kapsayıcılardan hiçbiri ötekinin imajını bilmez ve biri eşini öldürmeden yeniden başlayabilir.

Adapter çıktıyı standartlaştırır. Eski uygulama kendi log biçimini yazar; adapter kapsayıcı paylaşılan birimi okuyup küme araçlarının zaten işlediği biçimi yeniden yayar. Uygulamaya dokunulmaz; mesele budur: kodu her zaman değiştiremezsin ve sınav bu kısıtı sever.

Ambassador erişimi standartlaştırır. Uygulama gerçek arka uç yerine localhost:vekil ile konuşur; ambassador kapsayıcı yeniden deneme, kimlik başlığı veya uç nokta değişimi üstlenir. Sınamalar uygulamayı sahte vekile yöneltir; üretim vekil yapılandırmasını değiştirir. Aynı pod, aynı localhost, farklı hedef davranışı.

Üçü de bilerek tek podu paylaşır: paylaşımlı birimler, paylaşımlı ağ ad alanı, zamanlamada ortak kader. Yardımcı farklı yaşam veya ölçek isterse pod arkadaşı olmaktan çıkar, kendi deploymenti olur.

Uygulamalı örnek

Uygulama ham satır yazar, sidecar JSON benzeri önekli satır taşır:

apiVersion: v1
kind: Pod
metadata:
  name: pattern-demo
spec:
  containers:
  - name: app
    image: busybox
    command: ["sh", "-c", "while true; do echo event >> /shared/out.log; sleep 5; done"]
    volumeMounts:
    - { name: shared, mountPath: /shared }
  - name: shipper
    image: busybox
    command: ["sh", "-c", "tail -F /shared/out.log | sed 's/^/[ship] /'"]
    volumeMounts:
    - { name: shared, mountPath: /shared }
  volumes:
  - { name: shared, emptyDir: {} }

kubectl logs pattern-demo -c shipper önekli akışı gösterir. Taşıyıcı imajını veya komutunu değiştir, uygulama fark etmez: kalıbın çalışması budur.

Sınav notları

Log soruları neredeyse hep sidecar veya sade stdout disiplini ister: önce görev uygulama imajına dokunmaya izin veriyor mu bak. kubectl logs <pod> -c <ad> artı --previous çöken eşleri kapsar. Ve paylaşımlı birimler iki tarafta da eşleşen bağlama yolu ister; oradaki yazım hatası birbirini güvenle görmezden gelen iki kapsayıcı üretir.