Istio ile service mesh nasıl kurulur: istioctl ve sidecar adımları

Service mesh ve Istio ne işe yarar?

Mikro hizmetler arttıkça servisler arası iletişimin kendisi bir yönetim konusu olur: hangi servis hangisini çağırıyor, çağrı yavaşlarsa ne olacak, trafiğin hangi bölümü yeni sürüme gidecek, servisler arası bağlantı şifreli mi? Bu işleri her uygulamanın kodunda ayrı ayrı çözmek, farklı dillerde ve ekiplerde tutarsızlık doğurur.

Service mesh, bu ağ davranışlarını uygulamanın dışına, altyapı katmanına taşır. Istio bunun en bilinen uygulamalarından biridir. Klasik modelde her pod'un yanına bir vekil (sidecar proxy) yerleştirilir; uygulamanın giriş ve çıkış trafiği bu vekilden geçer. Vekillerin davranışını ise merkezi bir kontrol düzlemi yönetir. Böylece trafik yönlendirme, yeniden deneme, zaman aşımı, devre kesici, kimlik doğrulama ve gözlemlenebilirlik uygulama kodu değişmeden yapılandırılabilir.

Kuruluma başlamadan önce gerekenler

Kurulum için çalışan bir Kubernetes kümesine ve o kümeye erişimi olan kubectl'e ihtiyacınız vardır. Istio'nun komut satırı aracı istioctl'ü resmî sürümden edinip PATH'inize ekleyin. Istio ve Kubernetes sürümleri birbiriyle uyumlu olmalıdır; hangi Istio sürümünün hangi Kubernetes sürümlerini desteklediğini kurulumdan önce resmî belgeden kontrol edin.

Küme tarafında şunları gözden geçirin: • Yetki: Kontrol düzlemi bileşenleri küme genelinde kaynak oluşturur; kurulumu yönetici yetkisiyle yapmanız gerekir • Kaynak: Her sidecar pod başına ek işlemci ve bellek tüketir; kaynak limitlerini ve kümenin kapasitesini baştan hesaba katın • Kapsam: Önce bir deneme ad alanında ya da ayrı bir test kümesinde başlayın; üretimdeki tüm uygulamaları tek hamlede mesh'e almayın

Kurulum, geri alınabilir bir işlemdir (kaldırma komutu vardır), ama sidecar eklenen pod'lar yeniden başlatılır. Bu nedenle üretim kümesinde deneme, bakım penceresi gerektirir.

Adım adım kurulum: istioctl ile

En basit kurulum, istioctl'ün varsayılan profiliyle yapılır:

istioctl install

Resmî belgeye göre varsayılan profil, üretim ortamı kurmak için iyi bir başlangıç noktasıdır. Özellikleri geniş biçimde denemek istiyorsanız daha kapsamlı demo profilini seçebilirsiniz:

istioctl install --set profile=demo

Demo profili değerlendirme amaçlıdır; üretim için varsayılan profil ya da kendi yapılandırmanız daha uygundur. Kurulum bittiğinde kontrol düzlemi istio-system ad alanında çalışır. Pod'ların hazır olduğunu şu komutla izleyin:

kubectl get pods -n istio-system

Yapılandırmanın tutarlılığını denetlemek için istioctl analyze komutu kullanışlıdır; ad alanındaki Istio kaynaklarında ve etiketlerde yaygın hataları bildirir. Her adımdan sonra çıktıyı okuyup bir sonraki adıma geçin; hazır olmayan bir kontrol düzlemi üzerine sidecar enjekte etmek pod'ların başlamamasına neden olur.

Sidecar enjeksiyonu: namespace etiketi ve pod'ları yeniden başlatma

Otomatik enjeksiyon, ad alanı seviyesinde bir etiketle açılır:

kubectl label namespace default istio-injection=enabled --overwrite kubectl get namespace -L istio-injection

Dikkat edilecek en sık yanlış anlama: etiket yalnızca yeni oluşturulan pod'lar için geçerlidir. Çalışmakta olan pod'lar değişmez; sidecar'ın eklenmesi için onları yeniden başlatmanız gerekir. Örneğin bir Deployment için:

kubectl rollout restart deployment/<deployment-adı>

Enjeksiyonun gerçekleştiğini doğrulamak için pod'un hazır sayısına bakın. Enjekte edilmiş bir pod 2/2 gösterir, enjekte edilmemiş pod 1/1 gösterir; çünkü uygulama kapsayıcısının yanına istio-proxy kapsayıcısı eklenmiştir:

kubectl get pod -l app=<uygulama> kubectl describe pod -l app=<uygulama>

Revizyon tabanlı kurulumlarda (aynı kümede birden çok kontrol düzlemi sürümü) istio-injection yerine istio.io/rev etiketi kullanılır. Her ikisi birden varsa istio-injection önceliklidir. Belirli bir pod'u enjeksiyondan çıkarmak için pod üzerine sidecar.istio.io/inject etiketini "false" değeriyle koyun. Tüm ad alanı için kapatmak isterseniz etiketi kaldırıp pod'ları silin.

Çalıştığını nasıl doğrularsınız? Ve ilk kontrol listesi

Enjeksiyondan sonra mesh'in gerçekten devrede olup olmadığını şu noktalardan kontrol edin: pod hazır sayısı, istio-proxy kapsayıcısının varlığı ve uygulama trafiğinin hâlâ çalışması. Uygulamanın çalışmaya devam etmesi çoğu zaman en önemli ilk testtir; sidecar, başlangıçta uygulamanın ağ erişimini etkileyebilir.

Kontrol listesi: • Kontrol düzlemi pod'ları hazır mı • Hedef ad alanı etiketli mi ve etiket doğru anahtarı kullanıyor mu • Pod'lar etiket eklendikten sonra yeniden oluşturuldu mu • Her pod'da uygulama ve istio-proxy kapsayıcıları hazır mı • Servislerin port adları ve protokolleri doğru tanımlı mı (yanlış tanımlı portlar trafik yönetimi kurallarının çalışmamasına yol açar) • Karşılıklı TLS (mTLS) etkinse DestinationRule'larda uygun TLS modunu belirttiniz mi; belirtmediğinizde bazı yapılandırmalar hata döndürebilir

Elle enjeksiyon istediğiniz durumlar için istioctl kube-inject komutuyla üretilen manifest doğrudan uygulanabilir. Bu yöntem CI hattında manifest üretimi için yararlıdır, ancak otomatik enjeksiyon güncellemeleri kolaylaştırdığı için genellikle tercih edilir.

Kaldırmak gerektiğinde istioctl uninstall --purge komutu küme genelindeki kaynaklar dahil tüm Istio kaynaklarını siler; istio-system ad alanı varsayılan olarak silinmez, ayrıca kaldırılması gerekir.

Kurulumda sık yapılan hatalar

Etiket eklendi ama pod'lar yeniden başlatılmadığı için sidecar yok. Bu en sık karşılaşılan durumdur ve "enjeksiyon çalışmıyor" şikâyetlerinin çoğunun nedenidir.

Aynı ad alanında hem istio-injection hem revizyon etiketi var ve beklenmedik bir sürüm kullanılıyor. Hangisinin öncelikli olduğunu bilmek, yükseltme sırasında yaşanan şaşkınlığı önler.

Tüm üretim ad alanları tek seferde mesh'e alınıyor. Önce bir ad alanıyla başlayıp servis servis genişletmek, olası bir sorunun etkisini sınırlar.

Sidecar kaynak talepleri unutuluyor. Küçük bir kümede çok sayıda sidecar, pod'ların zamanlanamamasına yol açabilir.

Kurulumdan sonra yalnızca "çalışıyor" bakılıyor, trafik davranışı doğrulanmıyor. Basit bir uçtan uca isteği hem enjeksiyondan önce hem sonra deneyip aynı yanıtı aldığınızı kontrol edin.

Kurulum tamamlandığında sıradaki konular, trafiğin sürümler arasında bölünmesi (canary) ve zaman aşımı, yeniden deneme ile devre kesici gibi dayanıklılık kurallarıdır.

Bu beceriyi Mindset programlarında nerede çalışırsınız?

Istio ile Service Mesh Uygulamaları eğitimi, Kubernetes üzerinde mikro hizmet işleten platform, DevOps ve site güvenilirliği ekiplerine yöneliktir. Çözdüğü sorun, servisler arası trafiği uygulama koduna dokunmadan yönetmek ve gözlemlemek.

Modül başlıkları sırayla mimariyi, kurulum ve sidecar enjeksiyonunu, trafik yönetimini, canary senaryolarını, dayanıklılık desenlerini, güvenlik ve mTLS'i, gözlemlenebilirliği ve ambient mod ile yükseltme konularını kapsar. Kurulum sayfasındaki adımları bu sırayla kendi test kümenizde tekrarlayarak ekip içinde ortak bir pratik oluşturabilirsiniz.