Kubernetes'i Çalıştırması Gerekenlere Yönelik Rehber

Kubernetes öğreticileri sana bir pod dağıtmayı öğretir. Saat 3'te bir node'un sessizce Ready durumundan çıktığı ve on-call telefonunun durmadığı durumda ne yapacağını kimse öğretmez. Bu, ikinci kısım hakkındadır.

Kaynak istekleri ve limitleri isteğe bağlı değildir

Konteynerlerinizde resources.requests ve resources.limits'i atlarsanız, scheduler tahmin ediyor demektir ve kubelet, bir node'da bellek azaldığında hangisini sileceğini bilemez. İstekleri, konteyner'in normal yük altında gerçekten kullandığı şeylere, umduğu şeylere değil, ayarlayın. Bellek limitlerini isteklere yakın ayarlayın, çünkü OOM-killed pod'lar temiz bir şekilde yeniden başlar, ancak CPU limitleri gürültülü komşularla savaşmadığı sürece genel olarak daha gevşek veya olmamalıdır; çünkü hard limit altında CPU throttling, hata ayıklaması acı verici olan gecikme ani artışlarına neden olur. kubectl top pods -n your-namespace komutunu düzenli olarak çalıştırın ve bildirdiğiniz şeylerle karşılaştırın. Uyumsuzluklar, tucaydan fazla servisi olan kümelerde hızlı bir şekilde birikir.

etcd bütün kümedir, buna göre davranın

Kubernetes'in bildiği her şey etcd'de yaşar. Bunu kaybetseniz, küme state'inizi kaybedersiniz, sadece bazı metaveri değil. etcdctl snapshot save /backup/etcd-snapshot.db komutunu plana göre çalıştırın ve bunu bir yardımcı kümede en az bir kez gerçekten restore etmeyi test edin. Gece yardımlarının üç ay boyunca bozuk olduğu ortaya çıktığı için, kimse onları doğrulamadığı için takımlar gördüm. Yönetilen bir kontrol düzlemindeyseniz (EKS, GKE, AKS), etcd'yi doğrudan yönetmezsiniz, ancak bir olay sırasında değil, daha önce sağlayıcınızın backup ve restore hikayesini bilmelisiniz.

Liveness ve readiness probe'ları bazen katılmaz

Yaygın bir hata, liveness ve readiness probe'ları için aynı endpoint'i kullanmaktır. Liveness cevapla