Bir Kubernetes cluster'ı kurmak bir günlük iş, üretime hazır hale getirmek farklı bir iş. Aşağıdaki liste, kendi işlettiğimiz cluster'larda ve devraldığımız kurulumlarda en sık eksik bulduğumuz maddelerden çıktı. Sırayla gidilmesi gerekmiyor ama hiçbiri atlanmamalı.
1. Control plane ve etcd
- Control plane yedekli mi, en az üç düğüm var mı
- Control plane'ler farklı fiziksel makinelerde mi
- Önünde load balancer var mı, tek adres arkasında mı
- etcd yedeği alınıyor mu
- etcd yedeği uygulama yedeğinden ayrı mı
- etcd yedeğinden geri dönüş denendi mi
- Sertifika son kullanma tarihleri takvimde mi
Dördüncü ve beşinci madde en kritik ikili. Uygulama verisi geri gelse bile cluster durumu gelmezse kurtarma yarım kalıyor; nedenini etcd yedekleme ve kurtarma yazısında ölçümlerle anlattık. Topolojinin tamamı yüksek erişilebilir Kubernetes sayfasında.
2. Kaynak yönetimi
- Her container'a kaynak isteği ve limiti tanımlı mı
- Namespace bazında kota tanımlı mı
- Gecikmeye duyarlı iş yükleri ayrı node havuzunda mı
- Node'larda sistem bileşenleri için ayrılmış kaynak var mı
- Otomatik ölçeklemenin üst sınırı tanımlı mı
- Ölçeklemenin devreye girme süresi ölçüldü mü
Limitsiz bir container, bir hata durumunda aynı node'daki diğer iş yüklerinin belleğini tüketebiliyor. Limitler performans ayarı değil, komşu koruma tedbiri. Ölçekleme tarafı auto-scaling ve self-healing sayfasında.
3. Sağlık kontrolleri
- Her uygulamada hazır olma kontrolü tanımlı mı
- Canlılık kontrolü tanımlı mı ve doğru şeyi ölçüyor mu
- Başlangıç kontrolü yavaş açılan uygulamalar için tanımlı mı
- Aynı anda kaç kopyanın kapanabileceği sınırlandı mı
- Kapanma sırasında bağlantıların düzgün sonlandırılması sağlandı mı
Yanlış tanımlanmış bir canlılık kontrolü, sağlıklı bir uygulamayı sürekli yeniden başlatarak kendi kesintisini üretiyor. Bu, sağlıklı görünen bir cluster'da saatlerce fark edilmeden dönebiliyor.
4. Ağ ve erişim
- Namespace'ler arası trafik varsayılan olarak kapalı mı
- Yalnızca ihtiyaç duyulan yollar açık mı
- Dışarı açılan servisler bilinçli olarak mı açılmış
- Yönetim erişiminde çok faktörlü doğrulama var mı
- Rol bazlı yetkilendirme en az yetki ilkesine göre mi
- Servis hesaplarının yetkileri daraltıldı mı
Varsayılan kurulumda pod'lar birbirini serbestçe görüyor. Bunu daraltmanın üretimi durdurmadan nasıl yapıldığını mikro segmentasyon yazımızda anlattık.
5. İmaj ve tedarik zinciri
- İmajlar özel bir kayıt defterinde mi tutuluyor
- Etiket olarak
latestkullanılıyor mu - İmajlar dağıtımdan önce taranıyor mu
- Hangi bulgunun dağıtımı durduracağı tanımlı mı
- Temel imajlar düzenli güncelleniyor mu
- Üretime yalnızca kendi ürettiğiniz imajlar mı giriyor
İkinci madde sanıldığından daha önemli: bugün çektiğiniz
latest ile bir ay sonra çektiğiniz aynı şey olmayabiliyor, yani
üretimde neyin çalıştığından emin olamıyorsunuz. Ayrıntı
container registry
sayfasında ve
imaj tarama
yazımızda.
6. İzleme ve log
- Cluster metrikleri toplanıyor mu
- Uygulama metrikleri toplanıyor mu
- Log'lar container dışına, merkezî bir yere akıyor mu
- Alarm eşikleri tanımlı mı ve gürültü üretmiyor mu
- Alarm kime gidiyor, nöbet sırası belli mi
- Sertifika ve disk doluluk alarmları var mı
Üçüncü madde sonradan en çok pişman olunan eksik: container silindiğinde içindeki dosyalar da gidiyor, arıza sonrası inceleyecek kayıt kalmıyor. İzleme kapsamı Monitoring as a Service sayfasında.
7. Sürüm ve bakım
- Cluster sürümü destek kapsamında mı
- Yükseltme takvimi belirlendi mi
- Yükseltme sırası yazılı mı (önce control plane, sonra node'lar)
- Yükseltme öncesi test ortamında denendi mi
- Kullanımdan kaldırılan API sürümleri tarandı mı
- Bakım penceresi tanımlı mı
Beşinci madde yükseltmelerde en sık takılan yer: kullanımdan kaldırılmış bir API sürümü kullanan bir manifest, yükseltme sonrası sessizce çalışmayı bırakıyor. Adım adım nasıl yürüttüğümüzü sürüm yükseltme yazımızda anlattık.
8. Kurtarma
- Cluster'ın tamamının kaybı senaryosu için plan var mı
- Uygulama verisi ayrıca yedekleniyor mu
- Kalıcı disklerin yedeği alınıyor mu
- Kurtarma denemesi yapıldı mı, süresi ölçüldü mü
- Kurtarma adımları yazılı mı, tek kişinin kafasında mı
Son madde teknik değil ama en kritik olanı. Kurtarma bilgisi tek kişide duruyorsa, o kişinin izinde olduğu bir gecede cluster'ın kaderi de izinde oluyor. Kurtarma topolojisi felaket kurtarma topolojisi sayfasında.
Cluster yönetimini bize bırakmak isterseniz kapsam Kubernetes cluster yönetimi sayfasında. Diğer kontrol listesi için KVKK bulut uyum listesine, tüm kaynaklar için kaynaklar sayfasına bakabilirsiniz.