Örnek sorular
K8s WorkloadsZorluk 1
Kubernetes'te en küçük deploy edilebilir birim nedir, ve sahip bir controller olmadan oluşturulan çıplak bir Pod silinirse ya da Node'u çökerse ne olur?
- aBir container'dır, Kubernetes onu her zaman farklı bir Node'da otomatik olarak yeniden başlatır
- bBir Node'dur, workload'lar herhangi bir sarmalayıcı nesne olmadan doğrudan onun üzerine zamanlanır
- cBir Pod'dur, Kubernetes onu kendiliğinden otomatik olarak yeniden oluşturmaz✓
- dBir namespace'tir, içindeki her Pod bir grup olarak birlikte yeniden oluşturulur
Açıklama:Pod, doğrudan oluşturup zamanlayabileceğin en küçük birimdir. Sahip bir controller olmadan oluşturulan çıplak bir Pod silinirse ya da Node'u çökerse yeniden oluşturulmaz — yalnızca Deployment veya ReplicaSet gibi bir controller istenen sayıyı izler ve eksik Pod'ları yerine koyar. a, çıplak bir Pod'un kendi başına yaptığını değil controller davranışını anlatıyor; b ve d ise zamanlama ve gruplamanın gerçekte nerede yapıldığını yanlış konumlandırıyor.
K8s WorkloadsZorluk 1
Bir Deployment'ın oluşturduğu nesne hiyerarşisinde, çalışan Pod'ların doğrudan sahibi olarak (her Pod'un ownerReferences alanında görüleceği üzere) hangi controller ayarlanır?
- aDeployment'ın oluşturduğu ReplicaSet✓
- bDeployment nesnesinin kendisi, arada hiç ReplicaSet olmadan doğrudan
- cPod'lara trafiği yönlendiren Service
- dPod'un atandığı Node üzerinde çalışan kubelet
Açıklama:Her Pod'un ownerReferences alanı Deployment'a değil ReplicaSet'e işaret eder — Deployment, ReplicaSet'in sahibidir, ReplicaSet de Pod'ların sahibidir; böylece iki seviyeli bir zincir oluşur. b, gerçekte var olan ara ReplicaSet'i atlıyor; c ve d sahiplik zinciriyle ilgisiz, bir Service Pod'ları yalnızca label ile seçer, bir kubelet ise API'de nesnelerin sahibi olmaz.
K8s WorkloadsZorluk 2
Bir Deployment tarafından oluşturulan bir Pod için kubectl get pod web-6cfbf48659-s2t7j -n wl-jr -o yaml çalıştırıldığında metadata altında şu görülüyor:
ownerReferences:
- apiVersion: apps/v1
kind: ReplicaSet
name: web-6cfbf48659
controller: true
Bu, Pod'un nasıl yönetildiği hakkında neyi doğrular?
- aDeployment, herhangi bir ara nesne olmadan bu Pod'u doğrudan oluşturmuş ve sahibidir
- bBu Pod elle oluşturulmuş ve daha sonra yönlendirme için bir Service tarafından sahiplenilmiştir
- cPod'un adı herhangi bir controller ile ilgisizdir ve scheduler tarafından rastgele atanmıştır
- dweb-6cfbf48659 adlı bir ReplicaSet, bu Pod'un sahibi olan ve onu yöneten controller'dır✓
Açıklama:kind: ReplicaSet ve controller: true içeren ownerReferences girdisi, web-6cfbf48659 ReplicaSet'inin bu Pod'un yaşam döngüsünden sorumlu doğrudan sahip olduğunu doğrular. a yanlıştır çünkü alan açıkça Deployment'ı değil bir ReplicaSet'i adlandırıyor; b ve c ise bu çıktının hiç göstermediği senaryolar uyduruyor.
K8s WorkloadsZorluk 2
Bir Deployment olan web'de şu anda spec.replicas: 2 var ve 2 Pod Running durumda. Şunu çalıştırıyorsun:
kubectl scale deployment/web --replicas=4 -n wl-jr
Doğrudan etkisi nedir?
- aweb adında, 4 replika ile paralel çalışan ikinci bir Deployment oluşturulur
- bDeployment'ın replicas alanı 4 olur, ReplicaSet'i 2 ek Pod ekler✓
- cKomut yalnızca alanı günceller, Pod'lar bir sonraki
kubectl apply'da eklenir - dKomut başarısız olur çünkü replicas, bir Deployment oluşturulduktan sonra değiştirilemez
Açıklama:kubectl scale, mevcut Deployment üzerindeki spec.replicas alanını patch'ler; ardından ReplicaSet hemen reconcile olur ve aynı Pod template'inden ek Pod'ları oluşturur, başka bir apply beklemeden. a hiç oluşturulmayan ikinci bir nesne uyduruyor; c yanlıştır çünkü reconcile hemen gerçekleşir, gelecekteki bir apply'da değil; d yanlıştır, replicas değiştirilebilir bir alandır.
K8s WorkloadsZorluk 2
kubectl scale kullanmak yerine bir mühendis Deployment manifest'inde replicas: 2'yi replicas: 4'e değiştirip kubectl apply -f deploy.yaml çalıştırıyor. Ortaya çıkan davranış kubectl scale deployment/web --replicas=4 çalıştırmakla nasıl karşılaştırılır?
- aYalnızca
kubectl scale ReplicaSet'i tetikler, YAML'i düzenleyip yeniden apply etmenin Pod sayısına etkisi yoktur - bYAML'i düzenlemek, image değişmemiş olsa bile mevcut tüm Pod'ların tam bir rolling restart'ını zorlar
- cİkisi de aynı
spec.replicas alanını günceller, bu yüzden ReplicaSet her iki durumda da 4 Pod'a yakınsar✓ - dYAML düzenledikten sonraki
kubectl apply, eski Deployment'ı siler ve sıfırdan yepyeni bir tane oluşturur
Açıklama:Her iki yol da aynı Deployment nesnesindeki aynı spec.replicas alanını patch'ler, dolayısıyla sonuç aynıdır: ReplicaSet 4 Pod'a reconcile olur. a yanlıştır çünkü düzenleyip apply etmek canlı nesneyi gerçekten günceller; b yanlıştır çünkü yalnızca replika sayısı değişti, Pod template'i değil, bu yüzden mevcut Pod'ların restart'ı tetiklenmez; d, apply'ı yanlış tanımlıyor, o nesneyi yeniden oluşturmak yerine mevcut nesneyi günceller.
K8s WorkloadsZorluk 2
Bir Deployment olan web'de replicas: 2 var ve her iki Pod da Running durumda. kubectl delete pod web-6cfbf48659-gp9n7 -n wl-jr çalıştırıyorsun. Birkaç saniye sonra kubectl get pods'a bakıyorsun. Ne gözlemlersin?
- aYine toplam 2 Pod: silinen gitmiş, yeni bir Pod onun yerini almış✓
- bYalnızca 1 Pod kalır, çünkü Deployment
replicas'ı gerçek sayıya indirir - cDeployment başarısız olarak işaretlenir ve kurtarmak için elle
kubectl rollout restart gerekir - dAynı Pod, silinmeden önceki adıyla birebir aynı şekilde yeniden ortaya çıkar
Açıklama:ReplicaSet, gerçek Pod sayısını sürekli olarak istenen replicas değerine doğru reconcile eder; sahip olduğu bir Pod'u silmek, sadece yeni üretilmiş bir adla bir yenisinin oluşturulmasını sağlar ve sayıyı 2'ye geri getirir. b, reconciliation yönünü tersine çeviriyor; c, rutin bir Pod silmeden ortaya çıkmayan bir başarısızlık durumu uyduruyor; d yanlıştır çünkü yerine gelen Pod silinenin adını değil yeni, taze bir ad alır.