Örnek sorular
K8s Config SecretsZorluk 1
Bir ConfigMap, Pod'un container'ına iki yaygın yolla sunulabilir. Onu ortam değişkeni olarak (envFrom/valueFrom.configMapKeyRef) kullanmak ile volume olarak mount etmek arasındaki temel yapısal fark nedir?
- aOrtam değişkenleri yalnızca sayısal değerlerde çalışır, volume'lar yalnızca metin değerlerinde çalışır
- bEnv var'lar değerleri process ortamına enjekte eder; volume ise her key'i dosya olarak sunar✓
- cEnv var'lar ayrı bir Secret nesnesi gerektirir, volume'lar ayrı bir ConfigMap nesnesi gerektirir
- dOrtam değişkenleri namespace'e özeldir, volume mount'lar cluster kapsamındadır
Açıklama:envFrom/valueFrom.configMapKeyRef, ConfigMap'teki her key'i container'ın process ortamında bir ortam değişkeni olarak ayarlar. Aynı ConfigMap'i volume olarak mount etmek ise her key'in bir dosya haline geldiği, değerin de dosya içeriği olduğu bir dizin oluşturur. İkisi de aynı ConfigMap verisini referans alır, sadece farklı bir mekanizmayla ulaştırılır.
K8s Config SecretsZorluk 2
Çalışan bir Pod'daki container, ConfigMap app-config'ten envFrom.configMapRef ile ayarlanan APP_MODE ortam değişkenini okuyor. app-config'i kubectl patch ile güncelleyip APP_MODE'u debug'dan production'a değiştiriyorsun, iki dakika bekliyorsun, sonra container'a exec olup $APP_MODE'u yazdırıyorsun. Ne görürsün?
- a
production, çünkü kubelet ConfigMap değişikliklerinde container'ları her zaman yeniden başlatır - bBoş bir değer, çünkü kaynak ConfigMap değiştiğinde container'ın ortamı temizlenir
- cHâlâ
debug — env var'lar container başlarken bir kez okunur, ConfigMap değişikliklerinde yeniden enjekte edilmez✓ - d
production, çünkü ortam değişkenleri her process syscall'ında ConfigMap'ten yeniden okunur
Açıklama:ConfigMap'ten gelen ortam değişkenleri yalnızca container process'i başlarken bir kez çözümlenir. Kubernetes'in hâlihazırda çalışan bir process'in ortamına yeni değerleri iletecek bir mekanizması yoktur, bu yüzden ne kadar beklersen bekle container debug yazdırmaya devam eder. Yeni değerin alınması için Pod'un yeniden oluşturulması (örn. rollout restart) gerekir.
K8s Config SecretsZorluk 2
Aynı kurulum, ama bu kez aynı ConfigMap key'i subPath kullanmadan /etc/config/APP_MODE yolunda volume dosyası olarak da mount edilmiş. ConfigMap'i patch'leyip kubelet'in sync periyodu için yaklaşık bir dakika bekledikten sonra kubectl exec pod -- cat /etc/config/APP_MODE çalıştırıyorsun. Ne olur?
- aDosya sonunda yeni değeri gösterir, kubelet'in bir sonraki periyodik senkronizasyonunda✓
- bPod manuel olarak silinip yeniden oluşturulana kadar komut dosya-bulunamadı hatasıyla başarısız olur
- cDosya, env var'ların davranışıyla aynı şekilde, eski değeri sonsuza kadar korur
- dDosya yalnızca container process'i onu yenilemek için açıkça bir Kubernetes API çağrısı yaparsa güncellenir
Açıklama:Volume olarak mount edilmiş (subPath KULLANILMAYAN) ConfigMap verisi kubelet tarafından periyodik olarak senkronize edilir, bu yüzden dosya içeriği hiçbir Pod yeniden başlatması olmadan güncellenen ConfigMap'i sonunda yansıtır — genelde sync periyodu içinde (yaklaşık bir dakika). Bu, hiçbir zaman Pod yeniden oluşturulmadan güncellenmeyen env var'larla temel pratik karşıtlığı oluşturur.
K8s Config SecretsZorluk 3
volumeMounts:
- name: cfgvol
mountPath: /etc/config/app_mode.txt
subPath: APP_MODE
volumes:
- name: cfgvol
configMap:
name: app-config
Akabinde
app-config ConfigMap'i güncellenip
APP_MODE'un değeri değiştiriliyor. Birkaç dakika bekleyip container içinde
/etc/config/app_mode.txt'i kontrol ediyorsun. Ne gözlemlersin?
- aDosya silinir, çünkü kaynak ConfigMap her değiştiğinde
subPath mount'ları kaldırılır - bDosya,
subPath olmayan bir mount ile aynı senkronizasyon döngüsünde güncellenir - cMount salt-okunur moda geçer ve sonraki okumalar izin hatasıyla başarısız olur
- dDosya orijinal içeriğini korur —
subPath volume mount'ları ConfigMap güncellemelerini almaz✓
Açıklama:Bir volume subPath ile mount edildiğinde, kubelet tüm-dizin mount'larında kullandığı symlink'li ..data dizini yerine o tek dosya yolunu doğrudan bind-mount eder. Normal ConfigMap volume güncellemelerinin yayılmasını sağlayan tam olarak bu symlink değişimidir, bu yüzden subPath mount'u Pod yeniden oluşturulana kadar güncellenmiş değeri asla görmez.
K8s Config SecretsZorluk 1
Bir Secret'ın data alanı, base64 ile kodlanmış string'ler olarak değerleri saklar. Bu base64 kodlaması aslında ne sağlar?
- aGüçlü şifreleme, öyle ki
kubectl get secret -o yaml çalıştıran kimse değeri okuyamaz - bDeğerin sabit bir programa göre otomatik olarak rotasyonu
- cİkili/metin verisinin bir manifestte güvenle temsili, gizlilik değil✓
- detcd depolama boyutunu azaltmak için değerin sıkıştırılması
Açıklama:Base64 bir kodlamadır, şifreleme şeması değildir. İkili ya da özel karakter içeren verinin metin tabanlı bir manifestte güvenle temsil edilebilmesi için vardır. kubectl get secret -o yaml çalıştırıp base64'ü çözebilen (base64 -d) herkes düz metin değeri okuyabilir; gerçek gizlilik RBAC'a, etcd'de rest halinde şifrelemeye ya da harici bir secret deposuna bağlıdır.
K8s Config SecretsZorluk 1
apiVersion: v1
kind: Secret
metadata:
name: app-secret
type: Opaque
stringData:
DB_PASSWORD: "s3cr3t"
Bu manifest apply edildikten sonra,
kubectl get secret app-secret -o yaml çıktısında
data alanının altında
DB_PASSWORD için ne görürsün?
- aDüz metin
s3cr3t string'i, çünkü stringData kodlamayı atlar - bSecret'ın
data alanında tutulan base64 ile kodlanmış bir string✓ - cHiçbir şey, çünkü aynı Secret'ta
stringData ve data birlikte var olamaz - dBir hata, çünkü
type: Opaque stringData alanını desteklemez
Açıklama:stringData, yalnızca yazma amaçlı bir kolaylık alanıdır: apply sırasında API sunucusu girdilerini data'ya birleştirir ve bu sırada base64 ile kodlar. Bu yüzden nesneyi sonradan okuduğunda her zaman data altında kodlanmış hali görürsün, orijinal stringData alanını asla.