Kubernetes Kontrol Düzlemi Sertifika Süresi Dolması: Runbook

Kubernetes’te sertifika süresi dolması, “kademeli bozulma” değil; çoğu zaman bir anda herkesin duvara çarptığı bir incident’tır: kubectl çalışmaz, controller’lar API’ye konuşamaz, node’lar statü güncelleyemez ve sistem sanki “tamamen çökmüş” gibi görünür.

Bu yazı; özellikle kubeadm ile kurulu (self-managed) cluster’larda sertifika süresi dolması senaryosu için pratik bir runbook’tur. Managed Kubernetes (EKS/AKS/GKE) için yaklaşım farklıdır.

Belirti seti (hızlı tanı)

En sık görülen hatalar:

• x509: certificate has expired or is not yet valid
• Unable to connect to the server: x509: certificate signed by unknown authority
• Unauthorized (sertifika yenilenmiş ama kubeconfig eskimiş)

Incident triage’da iki soruyu hızlı cevaplayın:

1. Hata istemci tarafında mı (kubeconfig / local) yoksa cluster tarafında mı?
2. Hata tek bileşeni mi etkiliyor yoksa kontrol düzlemi genelinde mi?

Kapsam: Bu runbook hangi kurulumlar için?

• Kubeadm ile kurulan cluster’lar
• Control-plane node’lara SSH erişiminiz var
• Etcd erişimi aynı node üzerinde veya ayrı ama yönetilebilir

Eğer managed Kubernetes kullanıyorsanız: sertifika yenileme genelde provider yönetimindedir; bu runbook’u “kubeconfig / client cert” kısmı için kullanın.

Adım 0 — Değişiklik yönetimi (incident modunda bile)

Bu incident’ta panikle yapılan iki hata çok pahalıdır:

• “Bir şeyler denedim” deyip farklı node’larda farklı işlemler yapmak (tutarsızlık)
• Aynı anda birden fazla node’da sertifika yenilemek (split-brain riskini büyütür)

Bu yüzden:

• Tek bir Incident Commander + tek bir operator
• Yapılan her komut karar günlüğüne not

Adım 1 — Sertifika durumunu kontrol et (kubeadm)

Control-plane node’da:

sudo kubeadm certs check-expiration

Çıktıda EXPIRES alanı geçmişteyse, problem büyük olasılıkla budur.
Eğer sadece belirli sertifikalar bitmişse bile, yenilemeyi “parça parça” değil, kontrollü yapın.

Adım 2 — Sertifikaları yenile

Kubeadm için en pratik yol:

sudo kubeadm certs renew all

Bazı kurulumlarda admin kubeconfig de yenilenir. Yine de son adımda kubeconfig’i doğrulayın.

Adım 3 — Kontrol düzlemi bileşenlerini güvenli şekilde yeniden başlat

Kubeadm çoğu kurulumda control-plane bileşenlerini static pod olarak yönetir. Genelde kubelet, manifest değişimini algılayıp pod’ları yeniden yaratır; ama sertifika yenileme sonrası pratikte şu adım işe yarar:

sudo systemctl restart kubelet

Sonra:

sudo crictl ps | rg -n \"kube-apiserver|kube-controller-manager|kube-scheduler\"
sudo crictl logs $(sudo crictl ps -q --name kube-apiserver) | tail -n 40

Amaç: API server’ın sağlıklı ayağa kalktığını doğrulamak.

Adım 4 — Kubeconfig’i doğrula (istemci tarafı)

Eğer kubectl tarafında hâlâ x509 görüyorsanız:

• Kullanılan kubeconfig’in güncel olup olmadığını kontrol edin
• Admin config’i yeniden alın / kopyalayın

Control-plane node’da tipik yol:

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
kubectl get nodes

Adım 5 — Etcd ve controller’ların toparlandığını doğrula

Bu incident’ta “kubectl çalıştı” diye bitirmeyin. Şunları kontrol edin:

• Node’lar Ready mı?
• kube-system pod’larında crashloop var mı?
• Controller’lar yeni event üretiyor mu?

kubectl get nodes -o wide
kubectl -n kube-system get pods
kubectl get events --sort-by=.lastTimestamp | tail -n 30

Önleyici kontroller (bu incident bir daha yaşanmasın)

En etkili önlem: sertifika bitmeden alarm üretmek.

• kubeadm certs check-expiration çıktısını günlük job ile toplayın
• EXPIRES < 30 gün → uyarı, < 7 gün → kritik
• Zaman senkronizasyonunu (NTP) kontrol düzlemi için “kritik servis” olarak izleyin

Son söz

Kontrol düzlemi sertifikası bittiğinde amaç “kubeadm komutunu bulmak” değil; kontrollü, tek elden, doğrulamayla ilerleyen bir toparlama yürütmektir. İyi bir runbook + erken uyarı ile bu incident, saatler süren bir kesinti yerine 15–30 dakikalık planlı bir bakım gibi yönetilebilir.