EKS 1.32/1.33 Yükseltme Kabusu: Her Şeyi Kırıp Geçen Bir Güncelleme ve Kurtarma Rehberi
Bulut tabanlı konteyner orkestrasyonu söz konusu olduğunda, Amazon EKS (Elastic Kubernetes Service) birçok kuruluş için vazgeçilmez bir hizmettir. Ancak, bu güçlü platformun sürüm yükseltmeleri, dikkatli planlanmadığında ciddi sorunlara yol açabilir. Bu makalede, EKS 1.32 veya 1.33 sürümüne yapılan bir yükseltme denemesi sırasında yaşadığımız felaketi, sistemlerimizin nasıl tamamen çöktüğünü ve bu karmaşık durumu adım adım nasıl çözdüğümüzü detaylarıyla anlatacağız. Amacımız, benzer durumlarla karşılaşabilecek diğer DevOps mühendislerine ve sistem yöneticilerine ışık tutmak, potansiyel tuzakları göstermek ve sağlam bir kurtarma stratejisi sunmaktır.
EKS Yükseltmelerinin Önemi ve Riskleri
Kubernetes ekosistemi sürekli gelişiyor ve her yeni sürümle birlikte önemli iyileştirmeler, güvenlik yamaları ve yeni özellikler geliyor. Ancak bu yenilikler, mevcut sistemlerinizle uyumluluk sorunları yaratma potansiyeli de taşır.
Neden Yükseltme Yapmalıyız?
EKS kümelerinizi güncel tutmak, sadece yeni özelliklerden faydalanmakla kalmaz, aynı zamanda güvenlik açıklarını kapatmak, performans iyileştirmeleri elde etmek ve AWS’nin sunduğu en son hizmet entegrasyonlarından yararlanmak için kritik öneme sahiptir. Eski sürümlerin destek süresi dolduğunda, güvenlik yamaları almayı durdurur ve potansiyel risklere açık hale gelir.
Yükseltme Sürecindeki Potansiyel Tuzaklar
Yükseltmeler genellikle kontrol düzlemi ve çalışan düğümlerin ayrı ayrı güncellenmesini gerektirir. Bu süreçte API değişiklikleri, bağımlılık uyumsuzlukları, CNI (Container Network Interface) veya CoreDNS gibi temel eklentilerin eski kalması gibi birçok sorunla karşılaşılabilir. Yanlış bir adım, tüm kümenizin işlevsiz hale gelmesine neden olabilir.
EKS Versiyon Politikası ve Destek Süreleri
AWS, EKS için belirli bir sürüm destek politikası izler. Her Kubernetes minor sürümü için genellikle 12-14 ay destek sağlanır. Bu sürenin sonunda, kümenizi desteklenen bir sürüme yükseltmeniz istenir. Bu durum, yükseltmeleri ertelemenin uzun vadede daha büyük sorunlara yol açabileceği anlamına gelir.
Felaketin Başlangıcı: EKS 1.32/1.33 Yükseltme Denemesi
Her şey, mevcut EKS kümemizi bir önceki kararlı sürümden 1.32 veya 1.33’e yükseltme kararıyla başladı. Planlama aşamasında her ne kadar dikkatli olmaya çalışsak da, gözden kaçan bazı detaylar felakete davetiye çıkardı.
Planlama ve Hazırlık Aşaması
Yükseltme öncesinde, mevcut tüm uygulamaların ve eklentilerin yeni Kubernetes sürümüyle uyumlu olup olmadığını kontrol etmek için kapsamlı bir araştırma yaptık. kubectl deprecations komutuyla deprecated API’leri kontrol ettik, bağımlılıkları listeledik ve bir geri alma planı hazırladık. Test ortamında denemeler yaptık, ancak ne yazık ki test ortamımız üretim ortamının karmaşıklığını tam olarak yansıtmıyordu.
Yükseltme Adımları ve İlk Belirtiler
AWS konsolu veya eksctl aracılığıyla kontrol düzlemi yükseltmesini başlattık. Kontrol düzlemi yükseltmesi sorunsuz görünüyordu. Ancak çalışan düğümleri güncellemeye başladığımızda, ilk sorunlar ortaya çıktı. Yeni düğümler sağlıklı bir şekilde katılamıyor, mevcut düğümlerden bazıları NotReady durumuna geçiyordu.
Sistem Genelinde Yaşanan Kesintiler ve Hatalar
Kısa süre içinde, küme üzerindeki tüm uygulamalar erişilemez hale geldi. kubectl get pods komutu birçok podun CrashLoopBackOff veya Pending durumunda olduğunu gösteriyordu. CoreDNS podları sağlıklı değildi, bu da DNS çözümlemesinin tamamen durduğu anlamına geliyordu. Uygulama logları API sunucusuna erişim hataları, hizmet keşif sorunları ve ağ bağlantısı hatalarıyla doluydu. Kısacası, her şey durmuştu.
Kök Neden Analizi: Neler Ters Gitti?
Panik anında hızlı ve doğru bir kök neden analizi yapmak çok önemlidir. Bizim durumumuzda, birden fazla faktörün bir araya gelmesi felakete yol açmıştı.
Kubernetes API Değişiklikleri ve Uyumluluk Sorunları
En büyük sorunlardan biri, Kubernetes’in yeni sürümlerinde deprecated olan API versiyonlarının artık tamamen kaldırılmış olmasıydı. Özellikle apiVersion: apps/v1beta2 gibi eski API’ler kullanan Helm chart’larımız veya doğrudan dağıtım dosyalarımız, yükseltme sonrası API sunucusu tarafından reddediliyordu. Bu durum, birçok temel uygulamanın ve eklentinin başlatılamamasına neden oldu.
Kontrol Düzlemi ve Çalışan Düğümler Arasındaki Uyumsuzluk
Kontrol düzlemi 1.32/1.33’e yükseltildikten sonra, eski sürümde kalan çalışan düğümler ile yeni kontrol düzlemi arasında versiyon uyumsuzluğu oluştu. Bu uyumsuzluk, kubelet’in API sunucusuyla doğru şekilde iletişim kurmasını engelledi. Yeni düğümlerin image’ları da doğru bir şekilde güncellenmemişti, bu da onların da kümeye katılamamasına yol açtı.
CNI, CoreDNS ve Diğer Eklentilerin Durumu
EKS’nin temel eklentileri olan AWS VPC CNI ve CoreDNS, Kubernetes sürümüne göre belirli versiyonlarda olmalıdır. Bizim durumumuzda, bu eklentilerin otomatik yükseltmesi başarısız olmuş veya eski versiyonları yeni kontrol düzlemiyle uyumsuz hale gelmişti. Özellikle CNI’nin düzgün çalışmaması, pod’ların IP adresi alamamasına ve ağ iletişiminin tamamen kesilmesine neden oldu.
AWS EKS’e Özgü Sorunlar
AWS EKS’in kendisi, yükseltme sırasında belirli zorluklar sunabilir. Örneğin, EKS kontrol düzlemi yükseltmesi tamamlandıktan sonra, çalışan düğümlerin de manuel olarak veya bir araç (eksctl, Terraform) ile güncellenmesi gerekir. Bu süreçte, düğüm başlatma şablonları, AMI’ler ve güvenlik grupları gibi AWS kaynaklarının doğru yapılandırıldığından emin olmak hayati önem taşır.
Kurtarma Operasyonu: Adım Adım Çözüm Yolları
Felaketin boyutunu anladıktan sonra, sakin kalıp adım adım bir kurtarma planı uygulamaya başladık.
Acil Durum Müdahalesi ve Geri Alma Stratejileri
İlk olarak, üretim trafiğini geçici olarak başka bir ortama yönlendirme veya statik bir hata sayfası gösterme gibi acil durum önlemleri aldık. Yükseltme öncesi bir anlık görüntü (snapshot) veya yedekleme varsa, geri alma en hızlı çözüm olabilirdi. Ancak bizim durumumuzda, kısmi bir yükseltme olduğu için geri alma da karmaşıktı. Kontrol düzlemini eski sürüme döndürme seçeneği EKS’te bulunmadığından, ileriye dönük bir çözüm bulmak zorundaydık.
EKS Kontrol Düzlemi Onarımı
EKS kontrol düzlemi, AWS tarafından yönetildiği için doğrudan müdahale edemeyiz. Ancak, AWS konsolu veya aws eks update-cluster-version komutu ile kontrol düzleminin durumunu kontrol edip, gerekirse aynı sürüme tekrar yükseltme denemesi yaparak iç tutarlılığını sağlamaya çalıştık.
Çalışan Düğümlerin Yeniden Sağlanması ve Güncellenmesi
En kritik adımlardan biri, çalışan düğümleri doğru Kubernetes sürümüyle uyumlu hale getirmekti.
1. Yeni Düğüm Grupları Oluşturma: Mevcut düğüm gruplarını tamamen silmek yerine, yeni bir düğüm grubu oluşturarak işe başladık. Bu yeni düğüm grubu, EKS kontrol düzlemi sürümüyle uyumlu en son AMI’yi ve kubelet sürümünü kullanacak şekilde yapılandırıldı.
2. Uyumlu AMI Seçimi: AWS EKS optimize edilmiş AMI’lerinden, hedef Kubernetes sürümüne (1.32 veya 1.33) uygun olanı seçtik.
3. Sağlık Kontrolü: Yeni düğümlerin kümeye sağlıklı bir şekilde katılıp katılmadığını kubectl get nodes ile kontrol ettik.
4. Eski Düğümleri Temizleme: Yeni düğümler sağlıklı bir şekilde çalışmaya başladıktan sonra, eski ve sorunlu düğüm gruplarını kademeli olarak boşalttık (kubectl drain) ve sildik.
# Yeni düğüm grubu oluşturma (eksctl örneği)
eksctl create nodegroup \
--cluster= \
--name= \
--node-type= \
--nodes= \
--nodes-min= \
--nodes-max= \
--ami-family=AmazonLinux2 \
--node-ami-id= # Opsiyonel, eksctl genellikle en yeniyi seçer
--version= # EKS kontrol düzlemi versiyonu ile aynı olmalı
# Eski düğümleri boşaltma ve silme
kubectl drain --ignore-daemonsets --delete-emptydir-data
eksctl delete nodegroup --cluster= --name=Eklentilerin ve Bağımlılıkların Düzeltilmesi
* API Uyumsuzlukları: Helm chart'larımızdaki ve YAML dosyalarımızdaki deprecated API versiyonlarını (apiVersion: apps/v1beta2 gibi) apps/v1 gibi güncel versiyonlarla değiştirdik. Bu, uygulamaların tekrar dağıtılabilmesini sağladı.
* CNI Yükseltmesi: AWS VPC CNI eklentisini, EKS kontrol düzlemi sürümüne uygun en son sürüme güncelledik.
# CNI sürümünü kontrol etme
kubectl describe daemonset aws-node -n kube-system | grep Image
# CNI'yi güncelleme (AWS CLI örneği)
aws eks update-addon --cluster-name --addon-name vpc-cni --addon-version --resolve-conflicts OVERWRITE* CoreDNS Yükseltmesi: CoreDNS eklentisini de EKS kontrol düzlemi sürümüne uygun en son sürüme güncelledik.
# CoreDNS sürümünü kontrol etme
kubectl describe deployment coredns -n kube-system | grep Image
# CoreDNS'i güncelleme (AWS CLI örneği)
aws eks update-addon --cluster-name --addon-name coredns --addon-version --resolve-conflicts OVERWRITE* kube-proxy Yükseltmesi: kube-proxy'nin de güncel olduğundan emin olduk.
# kube-proxy sürümünü kontrol etme
kubectl describe daemonset kube-proxy -n kube-system | grep Image
# kube-proxy'yi güncelleme (AWS CLI örneği)
aws eks update-addon --cluster-name --addon-name kube-proxy --addon-version --resolve-conflicts OVERWRITEGüvenlik Grupları ve Ağ Konfigürasyonlarının Kontrolü
Düğüm gruplarının ve kontrol düzleminin güvenlik gruplarının doğru portlarda (özellikle 443 ve 10250) iletişime izin verdiğinden emin olduk. Bazen yeni düğüm grupları yanlış güvenlik grubu kurallarıyla başlatılabilir.
Gelecek İçin Dersler ve En İyi Uygulamalar
Bu acı deneyimden çok değerli dersler çıkardık. Gelecekte benzer felaketleri önlemek için aşağıdaki en iyi uygulamaları benimsemeye karar verdik:
Kapsamlı Test ve Doğrulama Süreçleri
* Üretim Benzeri Test Ortamı: Test ortamının üretim ortamının birebir kopyası olmasını sağladık. Bu, tüm bağımlılıkları ve karmaşıklıkları kapsayacak şekilde kritik öneme sahiptir.
* Küçük Adımlarla Yükseltme: Mümkünse, birden fazla minor sürüm atlamak yerine, her minor sürüme tek tek yükseltme yapmayı tercih ettik.
* API Değişikliklerini Önceden Kontrol: kubectl convert veya kube-no-trouble gibi araçları kullanarak API değişikliklerini önceden tespit edip düzeltmek.
Otomasyon ve Geri Alma Mekanizmaları
* Altyapıyı Kod Olarak Yönetme (IaC): Terraform veya CloudFormation kullanarak EKS kümelerini ve düğüm gruplarını yönetmek, tutarlılığı sağlar ve geri alma süreçlerini kolaylaştırır.
* Otomatik Geri Alma: Yükseltme sırasında belirlenen eşiklerin aşılması durumunda otomatik olarak geri alma yapabilen mekanizmalar tasarlamak.
* Düğüm Grubu Dönüşümlü Yükseltmeler: Eski düğüm gruplarını silmeden önce yeni düğüm gruplarını tam olarak devreye alıp test etmek.
Belgeleme ve Bilgi Paylaşımı
Yaşanan sorunları, çözüm adımlarını ve çıkarılan dersleri detaylı bir şekilde belgelemek, ekip içindeki bilgi birikimini artırır ve gelecekteki yükseltmelerde rehberlik eder.
Sürekli İzleme ve Uyarı Sistemleri
Yükseltme süreci boyunca ve sonrasında, küme sağlığını, pod durumlarını, ağ trafiğini ve uygulama performansını sürekli olarak izlemek için kapsamlı bir izleme ve uyarı sistemi kurmak. Prometheus, Grafana, CloudWatch gibi araçlar bu konuda yardımcı olabilir.
Sonuç
EKS 1.32 veya 1.33 yükseltmesi sırasında yaşadığımız bu kabus, bize bulut altyapısı yönetiminde dikkatli planlama, detaylı test ve sağlam bir geri alma stratejisinin ne kadar kritik olduğunu bir kez daha gösterdi. Kubernetes'in dinamik yapısı, sürekli öğrenmeyi ve adaptasyonu zorunlu kılıyor. Bu deneyimden çıkardığımız dersler, gelecekteki yükseltmelerimizi daha güvenli ve sorunsuz hale getirmemize yardımcı olacak. Umarım bu rehber, benzer zorluklarla karşılaşan diğer mühendislere yol gösterir ve onların da "her şeyi kıran" yükseltmelerden başarıyla kurtulmalarına yardımcı olur.
SSS (Sık Sorulan Sorular)
EKS yükseltmeleri neden bu kadar riskli?
Kubernetes, hızla gelişen bir platformdur ve her yeni sürümde API'lerde, bağımlılıklarda ve temel bileşenlerde önemli değişiklikler olabilir. Bu değişiklikler, mevcut uygulamalarınız ve eklentilerinizle uyumsuzluklara yol açarak küme genelinde kesintilere neden olabilir. Ayrıca, kontrol düzlemi ve çalışan düğümlerin farklı zamanlarda güncellenmesi de versiyon uyumsuzlukları yaratabilir.
Hangi araçları kullanarak bu tür sorunları önleyebiliriz?
Öncelikle, eksctl veya Terraform gibi IaC (Infrastructure as Code) araçları kullanarak kümelerinizi yönetmek tutarlılık sağlar. kubectl deprecations komutuyla deprecated API'leri önceden kontrol edebilirsiniz. Helm chart'larınızı ve YAML dosyalarınızı güncel tutmak önemlidir. Ayrıca, kapsamlı bir test ortamı ve sürekli izleme araçları (Prometheus, Grafana, CloudWatch) sorunları erken tespit etmenize yardımcı olur.
Yükseltme sırasında geri alma mümkün müdür?
EKS kontrol düzlemi yükseltmeleri için doğrudan bir "geri alma" seçeneği bulunmamaktadır. Ancak, çalışan düğümler için yeni bir düğüm grubu oluşturup eski düğümleri boşaltarak ve silerek bir nevi "ileri sarma" ile kurtarma yapabilirsiniz. Uygulama katmanında ise, dağıtım öncesi alınan yedekler veya anlık görüntüler sayesinde geri alma mümkün olabilir. En iyi strateji, yükseltme öncesinde kapsamlı bir yedekleme ve geri alma planı oluşturmaktır.
Bu tür sorunları nasıl önleyebiliriz?
Kapsamlı bir test ortamında yükseltmeyi denemek, API değişikliklerini önceden kontrol etmek, tüm eklentilerin (CNI, CoreDNS, kube-proxy) yeni sürümle uyumlu olduğundan emin olmak ve AWS tarafından sağlanan EKS optimize edilmiş AMI'lerini kullanmak önemlidir. Ayrıca, düğüm gruplarını dönüşümlü olarak yükseltmek (önce yeni bir grup oluşturup eskiyi silmek) kesinti riskini azaltır.