Kubernetes Mimarisi: Adım Adım Ustalık (Bölüm 1)

Günümüzün hızla değişen dijital dünyasında, uygulamaları hızlı, esnek ve ölçeklenebilir bir şekilde dağıtmak ve yönetmek, her işletme için kritik bir öneme sahiptir. Peki, şirketinizin sürekli büyüyen, kompleks mikroservis tabanlı uygulamalarını nasıl etkin bir şekilde yönetebilirsiniz? Geliştiricilerin yeni özellikler eklemesi, operasyon ekiplerinin ise kararlı ve yüksek performanslı bir çalışma ortamı sağlaması beklendiğinde, bu görev adeta bir labirente dönüşebilir. İşte tam bu noktada, konteyner orkestrasyonunun altın standardı olan Kubernetes devreye giriyor.

Kubernetes, dağıtık sistemleri yönetmek için tasarlanmış açık kaynaklı bir platformdur. Ancak bu güçlü aracı tam anlamıyla kullanabilmek için, temel mimarisini kavramak elzemdir. Mimariye hakim olmak, sorun gidermeden optimizasyona, güvenlikten maliyet yönetimine kadar her alanda size büyük avantajlar sağlar. Bu makale serimizin ilk bölümünde, Kubernetes’in kalbine inecek, temel bileşenlerini ve bu bileşenlerin nasıl bir araya gelerek kusursuz bir uyum içinde çalıştığını adım adım keşfedeceğiz. Hazır olun, çünkü Kubernetes mimarisini anlamak, modern yazılım geliştirme ve operasyonlar dünyasında bir sonraki seviyeye geçişinizin anahtarı olacak!

Kubernetes Evrenine İlk Adım: Temel Kavramları Nasıl Anlamalıyız?

Kubernetes’e dalmadan önce, bu platformun temelini oluşturan birkaç anahtar kavramı netleştirmemiz gerekiyor. Zira bu kavramlar, Kubernetes’in neden bu kadar önemli olduğunu ve neler başarabileceğini anlamanın ilk adımıdır. Günümüzün modern uygulamaları genellikle tek parça (“monolitik”) yapılar yerine, küçük, bağımsız ve birbirleriyle iletişim kuran mikroservisler şeklinde tasarlanır. Bu mikroservislerin her biri genellikle kendi konteyneri içinde çalışır.

Peki, konteyner nedir? Konteynerler, bir uygulamanın kodunu, çalışma zamanı ortamını, sistem araçlarını, kütüphanelerini ve bağımlılıklarını izole edilmiş bir paket halinde bir araya getiren hafif, taşınabilir ve kendi kendine yeten yazılım birimleridir. Docker gibi araçlar sayesinde popülerleşen konteynerler, geliştirme ortamından test ortamına ve oradan da üretim ortamına kadar her yerde aynı şekilde çalışabilme garantisi sunar. Bu, “bir kez yaz, her yerde çalıştır” felsefesinin somutlaşmış halidir. Böylece, “benim makinemde çalışıyordu ama sunucuda çalışmıyor” gibi klasik geliştirme sorunları büyük ölçüde ortadan kalkar.

Konteynerler harika olsa da, yüzlerce, hatta binlerce konteyneri manuel olarak yönetmek tam bir kabusa dönüşebilir. Uygulamalar ölçeklenmeli, arızalı konteynerler yeniden başlatılmalı, güncellemeler sorunsuz bir şekilde dağıtılmalı ve ağ iletişimi düzenlenmelidir. İşte bu noktada “orkestrasyon” kavramı devreye girer. Konteyner orkestrasyonu, konteynerize edilmiş uygulamaların dağıtımını, yönetimini, ölçeklendirilmesini ve otomasyonunu sağlayan bir dizi süreç ve araç anlamına gelir. Kubernetes, piyasadaki en popüler ve güçlü konteyner orkestrasyon platformudur.

Kubernetes’i bu kadar çekici kılan bir diğer önemli özellik ise “bildirimsel” (declarative) yaklaşımıdır. Geleneksel “emirsel” (imperative) yaklaşımda, sistemin belirli bir duruma nasıl ulaşacağını adım adım belirtmeniz gerekir (örneğin, “üç sunucu başlat, bu uygulamayı bunlara yükle”). Bildirimsel yaklaşımda ise, sistemin *istenen son durumunu* tanımlarsınız (örneğin, “bu uygulama her zaman üç örneğiyle çalışıyor olmalı”), ve Kubernetes bu duruma ulaşmak için gereken tüm adımları kendiliğinden atar. Bir konteyner çökerse, Kubernetes onu otomatik olarak yeniden başlatır. Bir sunucu kaynak sıkıntısı yaşarsa, Kubernetes uygulamayı başka bir sunucuya taşır. Bu otomasyon düzeyi, operasyonel yükü önemli ölçüde azaltır ve sistemin daha dayanıklı olmasını sağlar.

Kubernetes Mimarisi Temelleri: Kontrol Düzlemi ve Çalışan Düğümler Nasıl İşler?

Kubernetes, mimari olarak iki ana bileşenden oluşur: Kontrol Düzlemi (Control Plane) ve Çalışan Düğümler (Worker Nodes). Bu iki bileşen, bir orkestranın şefi ve müzisyenleri gibi birlikte çalışarak dağıtık uygulamalarınızı yönetir ve çalıştırır. Kontrol düzlemi, Kubernetes kümesinin beynidir ve tüm yönetimsel kararları alır, çalışan düğümler ise gerçek iş yüklerini barındırır ve çalıştırır. Bu ayrım, kümenin hem ölçeklenebilir hem de dayanıklı olmasını sağlar.

Kontrol Düzlemi (Control Plane) Bileşenleri Nelerdir?

Kontrol düzlemi, Kubernetes kümesinin kalbinde yer alır ve tüm kararları ve orkestrasyon görevlerini yerine getirir. Genellikle birincil (“master”) düğüm olarak adlandırılan bir veya daha fazla sunucuda çalışır. Yüksek erişilebilirlik (High Availability) senaryolarında, birden fazla kontrol düzlemi düğümü kurularak tek hata noktası (Single Point of Failure) ortadan kaldırılır. Bu sayede, kontrol düzlemi bileşenlerinden biri çevrimdışı kalsa bile küme çalışmaya devam edebilir. Kontrol düzlemi, birçok farklı bileşenden oluşur ve her birinin kendine özgü bir rolü vardır:

1. Kube-APIServer: Bu, Kubernetes kümesinin ön kapısıdır ve tüm yönetimsel iletişimlerin gerçekleştiği RESTful API’yi sunar. kubectl komut satırı aracı, diğer kontrol düzlemi bileşenleri ve hatta çalışan düğümler, API Sunucusu ile iletişim kurarak kümedeki değişiklikleri uygular veya kümenin durumunu sorgular. Güvenlik ve kimlik doğrulama süreçleri de burada işlenir, bu da yetkisiz erişimi engeller. API sunucusu, kümenin bildirimsel doğasının merkezinde yer alır; yani kullanıcılar ve diğer bileşenler, kümenin “nasıl” bir duruma geleceğini değil, “hangi” durumda olmasını istediklerini API sunucusu aracılığıyla belirtirler.
2. etcd: Kubernetes kümesinin tüm konfigürasyon verilerini, küme durumunu ve meta verilerini depolayan dağıtılmış, yüksek erişilebilir bir anahtar-değer deposudur. etcd, kümenin “tek doğru kaynağı” (single source of truth) olarak işlev görür. Kontrol düzlemindeki tüm diğer bileşenler, etcd’den bilgi okur ve etcd’ye veri yazar. Bu bileşenin istikrarlı ve güvenilir çalışması, tüm kümenin sağlığı için kritik öneme sahiptir. Verilerin tutarlılığı ve yedekliliği, etcd’nin temel özelliklerindendir.
3. Kube-Scheduler: Bu bileşen, yeni oluşturulan veya atanmamış Pod’ları (uygulama iş yüklerini barındıran en küçük Kubernetes birimi) uygun bir çalışan düğüme atamaktan sorumludur. Zamanlayıcı, kaynak gereksinimleri (CPU, bellek), düğüm kısıtlamaları (örneğin, belirli bir donanıma sahip düğümler), Pod’lar arası affinite/anti-affininity kuralları, veri yerelliği, düğüm sağlık durumu gibi birçok faktörü göz önünde bulundurarak en uygun düğümü seçer. Adeta bir nakliye yöneticisi gibi, her Pod’a doğru evi bulur.
4. Kube-Controller-Manager: Aslında bu, farklı türde kontrolörlerin (denetleyicilerin) topluluğudur. Her kontrolör, kümenin mevcut durumunu etcd’den okur ve istenen duruma ulaşmak için gerekli değişiklikleri yapar. Örneğin:
   • Node Controller: Düğümlerin durumunu izler ve bir düğüm çevrimdışı kalırsa ilgili Pod’ları başka düğümlere taşır.
   • Replication Controller: Bir uygulama için belirli sayıda Pod kopyasının her zaman çalışır durumda olmasını sağlar.
   • Endpoints Controller: Servislerin (ağ trafiğini Pod’lara yönlendiren soyutlamalar) IP adreslerini ve portlarını günceller.
   • ServiceAccount Controller: Yeni ServiceAccount’lar için API erişim token’ları oluşturur.

   Kontrolör yöneticisi, Kubernetes’in “bildirimsel” modelini gerçekleştiren temel bileşenlerden biridir. Sürekli olarak kümenin mevcut durumunu izleyerek ve istenen durumuyla karşılaştırarak farkları gidermeye çalışır.

5. Cloud-Controller-Manager (İsteğe Bağlı): Eğer kümeniz bir bulut ortamında (AWS, Azure, GCP gibi) çalışıyorsa, bu bileşen bulut sağlayıcısına özgü API’lerle entegrasyonu sağlar. Örneğin, bulut sağlayıcısından yük dengeleyici (Load Balancer) sağlamak veya bulut depolama birimlerini yönetmek gibi görevleri üstlenir. Bu, Kubernetes’in bulut sağlayıcısından bağımsız olmasını ve bulut özelliklerini yerel olarak kullanabilmesini sağlar.

Çalışan Düğümler (Worker Nodes) Nasıl İşler ve Uygulamaları Nasıl Barındırır?

Çalışan düğümler, Kubernetes kümesindeki gerçek iş yüklerinin (yani Pod’ların) çalıştığı makinelerdir. Her çalışan düğüm, fiziksel bir sunucu, sanal makine (VM) veya bulut sağlayıcısı üzerindeki bir örnek olabilir. Kontrol düzlemi, çalışan düğümlere “ne yapmaları gerektiğini” söylerken, çalışan düğümler bu talimatları uygulayarak uygulamalarınızı barındırır ve yürütür. Her çalışan düğümde aşağıdaki temel bileşenler bulunur:

1. Kubelet: Her çalışan düğümde çalışan bir aracıdır. Kubelet’in ana görevi, API Sunucusu’ndan gelen Pod tanımlarını dinlemek ve bu Pod’ların düğümde çalıştırılmasını sağlamaktır. Bir Pod’u başlatma, durdurma, yeniden başlatma, konteyner sağlık kontrollerini (liveness ve readiness probları) gerçekleştirme ve Pod durumunu API Sunucusu’na raporlama gibi görevleri yerine getirir. Düğüm ve Pod’lar arasındaki bağlantı noktasıdır.
2. Kube-Proxy: Her çalışan düğümde çalışan bir ağ proxy’sidir. Kube-Proxy, Kubernetes Servisleri için ağ kurallarını yönetir ve ağ trafiğini Servislerden doğru Pod’lara yönlendirir. Çeşitli modlarda (iptables, ipvs) çalışabilir ve Pod’lar ile dış dünya arasındaki ağ iletişimini kolaylaştırır. Bir uygulamanın birden fazla Pod’u olsa bile, Servis sayesinde tek bir kararlı IP adresi ve port üzerinden erişilebilir olmasını sağlar.
3. Konteyner Çalışma Zamanı (Container Runtime): Bu bileşen, konteynerleri çalıştıran yazılımdır. En bilinen örneği Docker olsa da, Kubernetes, Container Runtime Interface (CRI) sayesinde containerd, CRI-O gibi farklı konteyner çalışma zamanlarını da destekler. Bu, Kubernetes’in konteyner teknolojisi seçiminde esnek olmasını sağlar ve gelecekteki konteyner teknolojilerine uyum sağlamasına olanak tanır. Konteyner çalışma zamanı, temel olarak Pod’lar içindeki konteyner görüntülerini çeker, başlatır ve sonlandırır.

Bir gerçek dünya senaryosunu ele alalım: Bir e-ticaret uygulamasının kullanıcı sayısı aniden arttığında, kontrol düzlemi yeni Pod’lar oluşturma kararı alır. Kube-scheduler bu yeni Pod’ları, kaynakları en uygun olan çalışan düğümlere atar. Her bir atanmış düğümdeki Kubelet, API sunucusundan bu yeni Pod’ların talimatlarını alır ve ilgili konteyner çalışma zamanı (örneğin containerd) aracılığıyla Pod’ları başlatır. Kube-proxy ise, bu yeni Pod’ların ağ trafiğini doğru şekilde alabilmeleri için düğümün ağ kurallarını günceller. Böylece, kullanıcılar kesintisiz bir deneyim yaşamaya devam ederken uygulama otomatik olarak ölçeklenmiş olur. İşte bu, Kubernetes’in mimarisinin sağladığı gücün ve otomasyonun bir örneğidir.

Kubernetes Ağ Yapısı: Podlar ve Servisler Arasında İletişim Nasıl Sağlanır?

Kubernetes’in kalbinde yatan en karmaşık ama bir o kadar da güçlü yönlerinden biri, ağ yapısıdır. Dağıtık bir sistemde çalışan yüzlerce konteynerin birbiriyle ve dış dünyayla güvenli ve verimli bir şekilde iletişim kurması gerekmektedir. Kubernetes, bu iletişimi basitleştirmek ve standartlaştırmak için kendine özgü bir ağ modeli benimser. Bu modelin temel amacı, geliştiricilerin ağ topolojisi hakkında derinlemesine bilgi sahibi olmadan uygulamalarını kolayca dağıtabilmelerini sağlamaktır.

Kubernetes ağ modelinin temel prensipleri şunlardır:

1. Her Pod’un Kendi IP Adresi Vardır: Kümedeki her Pod, kendi benzersiz IP adresine sahiptir. Bu, aynı düğümde veya farklı düğümlerdeki Pod’ların birbirleriyle IP adresi üzerinden iletişim kurabileceği anlamına gelir. Bu model, sanal makinelerdeki gibi bir doğrudan iletişim sağlar ve port eşleştirmesi (port mapping) karmaşıklığını ortadan kaldırır. Pod IP’leri dahili olarak küme içinde yönlendirilebilir.
2. Düğümler Arası Pod İletişimi: Farklı çalışan düğümlerdeki Pod’lar, aralarında ağ adresi dönüştürmesi (NAT) olmadan doğrudan iletişim kurabilir. Bu, bir Pod’un başka bir Pod’un IP adresini kullanarak ona doğrudan bağlanabileceği anlamına gelir. Bu iletişim, genellikle Container Network Interface (CNI) uyumlu bir ağ eklentisi (örneğin Calico, Flannel, Cilium) tarafından sağlanır. CNI eklentisi, düğümler arasında Pod ağlarının nasıl köprülenip yönlendirileceğini belirler.
3. Düğümlerin Pod IP’lerine Erişim Sağlaması: Her düğüm, üzerinde çalışan tüm Pod’lara ve kümedeki tüm diğer Pod’lara ulaşabilir. Bu, denetim düzlemi bileşenlerinin (örneğin Kubelet’in) Pod’larla doğrudan iletişim kurabilmesini sağlar.

Bu prensipler, Kubernetes ağının temelini oluştururken, uygulamaların dış dünyayla ve birbirleriyle tutarlı bir şekilde etkileşime girmesi için Servis (Service) soyutlaması kullanılır. Servisler, bir grup Pod’a kararlı bir ağ kimliği ve erişim noktası sağlar. Bir Pod’un IP adresi değişebilir (örneğin yeniden başlatıldığında), ancak Servis’in IP adresi ve DNS adı sabittir. Bu, istemcilerin belirli bir Pod yerine bir Servis’e bağlanarak uygulamanın tüm örneklerine ulaşabilmesini sağlar.

Kubernetes, farklı erişim ihtiyaçlarını karşılamak için çeşitli Servis tipleri sunar:

• ClusterIP: Varsayılan Servis tipidir. Sadece küme içinden erişilebilen, kararlı bir dahili IP adresi (ClusterIP) sağlar. Bu, mikroservisler arasında dahili iletişimi sağlamak için idealdir. Örneğin, bir “ürün servisi” ile bir “veritabanı servisi” arasında iletişim kurulurken kullanılabilir.
• NodePort: ClusterIP Servis’in işlevselliğine ek olarak, kümedeki her düğümde belirli bir portu (NodePort) açar. Bu port üzerinden dışarıdan erişim sağlanabilir. Dışarıdan gelen trafik, bu NodePort üzerinden ilgili Pod’lara yönlendirilir. Genellikle, geliştirme veya test ortamlarında veya bir bulut sağlayıcısının yük dengeleyicisine (Load Balancer) alternatif olarak kullanılır.
• LoadBalancer: Sadece bulut sağlayıcılarında (AWS, Azure, GCP gibi) kullanılabilen bir Servis tipidir. Harici bir yük dengeleyiciyi otomatik olarak sağlar ve trafiği Servis’in Pod’larına dağıtır. Bu, internete açık uygulamalar için standart bir erişim yöntemidir ve ölçeklenebilirlik ile yüksek erişilebilirlik sunar.
• ExternalName: Harici bir hizmeti (örneğin, küme dışındaki bir veritabanı) küme içinde bir DNS adı ile eşleştirmek için kullanılır. Herhangi bir proxy veya port açma işlemi yapmaz, sadece DNS CNAME kaydı döndürür.

Vaka Analizi: Bir e-ticaret uygulamasında “ürünler” ve “ödeme” olmak üzere iki farklı mikroservisiniz olduğunu düşünelim. “Ürünler” servisi, ürün bilgilerini sunar ve birden fazla Pod üzerinde çalışır. “Ödeme” servisi ise kullanıcıdan ödeme alır. “Ödeme” servisinin “ürünler” servisine erişmesi gerektiğinde, doğrudan Pod IP’lerini kullanmak yerine bir ClusterIP Servisi oluşturulur. “Ödeme” servisi, “ürünler” Servisi’nin adı üzerinden iletişim kurar ve Kubernetes, bu isteği otomatik olarak mevcut “ürünler” Pod’larından birine yönlendirir. Eğer “ürünler” Pod’larından biri çökerse veya yeni Pod’lar eklenirse, Servis IP’si değişmediği için “ödeme” servisi bu değişikliklerden etkilenmez.

Uygulamalı Bir Bakış: Basit Bir Pod ve Servis Tanımlaması Nasıl Yapılır?

Kubernetes’in gücünü ve bildirimsel yapısını en iyi anlamanın yolu, pratik örnekler üzerinden gitmektir. Uygulamaları Kubernetes’e dağıtmak için YAML (YAML Ain’t Markup Language) formatında manifest dosyaları yazarız. Bu dosyalar, Kubernetes’e istediğimiz kaynakların (Pod, Servis, Deployment vb.) neye benzemesi gerektiğini söyler. İşte temel bir Pod ve Servis tanımlaması örneği:

Öncelikle, bir Nginx web sunucusunu çalıştıracak basit bir Pod tanımlayalım. Bu Pod, tek bir konteyner içerecek ve Nginx imajını kullanacak.

# pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: my-nginx-pod
  labels:
    app: nginx
spec:
  containers:
  - name: nginx-container
    image: nginx:latest
    ports:
    - containerPort: 80

Bu YAML dosyasını satır satır inceleyelim:

• apiVersion: v1: Bu, kullandığımız Kubernetes API versiyonunu belirtir. v1, Pod'lar gibi temel kaynaklar için standart API versiyonudur.
• kind: Pod: Oluşturmak istediğimiz Kubernetes kaynağının tipini belirtir. Burada bir Pod oluşturmak istediğimizi söylüyoruz.
• metadata:: Kaynak hakkında bilgi sağlayan meta verileri içerir.
  • name: my-nginx-pod: Pod'a verdiğimiz benzersiz isim.
  • labels:: Pod'a etiketler atarız. Bu etiketler, diğer Kubernetes kaynaklarının (örneğin Servisler veya Deployments) bu Pod'u bulması için kullanılır. Burada app: nginx etiketini veriyoruz.
• spec:: Kaynağın istenen durumunu (specifikasyonunu) tanımlar.
  • containers:: Bu Pod içinde çalışacak konteynerlerin listesidir. Bir Pod birden fazla konteyner içerebilir.
    • - name: nginx-container: Konteynerin adı.
    • image: nginx:latest: Konteynerin çalıştırılacağı Docker imajı. Burada Nginx'in en son versiyonunu kullanıyoruz.
    • ports:: Konteynerin dinleyeceği portları belirtir.
      • - containerPort: 80: Nginx'in varsayılan olarak dinlediği 80 numaralı portu açıyoruz.

Şimdi bu Pod'a dışarıdan erişim sağlamak için bir Servis tanımlayalım. Bu Servis, app: nginx etiketine sahip tüm Pod'lara trafik yönlendirecek.

# service.yaml
apiVersion: v1
kind: Service
metadata:
  name: my-nginx-service
spec:
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: ClusterIP

Servis YAML dosyasını inceleyelim:

• apiVersion: v1 ve kind: Service: Bu bir Servis kaynağı olduğunu belirtir.
• metadata: name: my-nginx-service: Servisimize verdiğimiz isim.
• spec:: Servis'in istenen durumunu tanımlar.
  • selector: app: nginx: Bu, Servis'in hangi Pod'ları hedef alacağını belirler. app: nginx etiketine sahip tüm Pod'lar bu Servis'in üyeleri olacaktır.
  • ports:: Servis'in dinleyeceği portları tanımlar.
    • - protocol: TCP: Ağ protokolü (TCP veya UDP).
    • port: 80: Servis'in kendi dinleyeceği port. Küme içindeki diğer Pod'lar bu Servis'e my-nginx-service:80 üzerinden erişebilir.
    • targetPort: 80: Servis'ten gelen trafiğin hedef Pod'un hangi portuna yönlendirileceğini belirtir. Bu örnekte, Nginx konteynerinin 80 numaralı portuna yönlendirilecek.
  • type: ClusterIP: Bu Servis'in tipini belirtir. ClusterIP, küme içi erişim için varsayılan tiptir.

Bu dosyaları oluşturduktan sonra, bunları Kubernetes kümenize dağıtmak için kubectl komutunu kullanabilirsiniz:

kubectl apply -f pod.yaml
kubectl apply -f service.yaml

Uygulamanızın dağıtılıp dağıtılmadığını kontrol etmek için:

kubectl get pod my-nginx-pod
kubectl get service my-nginx-service

Bu komutlar, Pod'unuzun ve Servis'inizin durumunu ve IP adreslerini gösterecektir. Bu basit örnek, Kubernetes'in deklaratif yapısını ve Pod'lar ile Servisler arasındaki ilişkiyi anlamanız için iyi bir başlangıç noktasıdır.

Kubernetes Mimarisi İçin İleri Düzey İpuçları ve En İyi Uygulamalar Nelerdir?

Kubernetes mimarisinin temelini anladıktan sonra, performansı artırmak, güvenliği sağlamak ve kaynakları daha verimli kullanmak için bazı ileri düzey ipuçları ve en iyi uygulamalar mevcuttur. Bu pratik bilgiler, karmaşık ortamları yönetirken size yol gösterecektir.

1. Kontrol Düzlemi için Yüksek Erişilebilirlik (High Availability): Üretim ortamlarında, tek bir kontrol düzlemi düğümüne bağımlılık büyük bir risk oluşturur. Kontrol düzlemini yüksek erişilebilir hale getirmek için birden fazla etcd, API Sunucusu, zamanlayıcı ve kontrolör yöneticisi replikası çalıştırmak önemlidir. Bu, bir bileşenin arızalanması durumunda kümenin çalışmaya devam etmesini sağlar. Genellikle 3 veya 5 etcd örneği ile konfigüre edilir.
2. Kaynak İstekleri ve Limitleri (Resource Requests & Limits): Pod tanımlamalarında konteynerler için CPU ve bellek kaynak istekleri (requests) ve limitleri (limits) belirtmek kritik öneme sahiptir. İstekler, zamanlayıcının Pod'u hangi düğüme yerleştireceğine karar verirken kullandığı minimum garantili kaynakları tanımlar. Limitler ise bir konteynerin kullanabileceği maksimum kaynak miktarını belirleyerek, tek bir Pod'un tüm düğüm kaynaklarını tüketmesini engeller. Bu, kümenin kararlılığını ve kaynak kullanım verimliliğini artırır.
3. Liveness ve Readiness Probları: Uygulamalarınızın sağlıklı çalıştığından emin olmak için Liveness (canlılık) ve Readiness (hazırlık) problarını kullanın.
   • Liveness Probe: Konteynerin çalışır durumda olup olmadığını kontrol eder. Eğer prob başarısız olursa, Kubernetes konteyneri yeniden başlatır. Bu, takılmış veya yanıt vermeyen uygulamaların otomatik olarak kurtarılmasını sağlar.
   • Readiness Probe: Bir konteynerin gelen trafiği kabul etmeye hazır olup olmadığını kontrol eder. Eğer prob başarısız olursa, Kubernetes Servis'in bu Pod'a trafik yönlendirmesini durdurur. Bu, uygulamanın başlatma aşamasında veya geçici olarak kullanılamadığı durumlarda kesintisiz hizmet sunmasını sağlar.
4. Güvenlik Yaklaşımları:
   • RBAC (Role-Based Access Control): Kubernetes kümesine kimin ne yapabileceğini kontrol etmek için RBAC'ı kullanın. En az ayrıcalık (least privilege) ilkesini benimseyerek, kullanıcılara ve hizmet hesaplarına yalnızca ihtiyaç duydukları izinleri verin.
   • Ağ Politikaları (Network Policies): Pod'lar arasındaki ve Pod'lar ile dış dünya arasındaki ağ iletişimini kısıtlamak için ağ politikalarını uygulayın. Bu, yetkisiz iletişimi engelleyerek güvenlik duruşunuzu güçlendirir.
   • Pod Güvenlik Standartları (Pod Security Standards): Pod'ların güvenlik ayarlarını (örneğin root kullanıcısı olarak çalışma, host path erişimi gibi) sınırlamak için Pod Güvenlik Standartları'nı kullanın veya ilgili politikaları (örneğin Gatekeeper, Kyverno) uygulayın.
5. Otomasyon ve Sürekli Teslimat (CI/CD): Kubernetes ile çalışırken, uygulama dağıtım ve yönetim süreçlerini otomatikleştirmek için CI/CD pipeline'larını entegre edin. Helm gibi paket yöneticileri, Kubernetes uygulamalarını yönetmeyi basitleştirir. GitOps prensiplerini benimseyerek, kümenizin istenen durumunu Git deposunda tutmak, değişikliklerin izlenebilirliğini ve geri alınabilirliğini artırır.

Bu ileri düzey ipuçları, Kubernetes kümenizi daha güvenli, verimli ve yönetilebilir hale getirmenize yardımcı olacaktır. Unutmayın, Kubernetes dinamik bir ortamdır ve en iyi uygulamaları sürekli olarak gözden geçirmek ve uygulamak önemlidir.

Sonuç: Kubernetes Mimarisine Hakim Olmak Neden Önemli?

Bu makalede, "Mastering Kubernetes Step by Step" serimizin ilk bölümünde, Kubernetes mimarisinin temel taşlarını derinlemesine inceledik. Kontrol düzlemi bileşenlerinden (API Sunucusu, etcd, Zamanlayıcı, Kontrolör Yöneticisi) çalışan düğümlere (Kubelet, Kube-Proxy, Konteyner Çalışma Zamanı) kadar her bir parçanın nasıl bir uyum içinde çalıştığını keşfettik. Ayrıca, Pod'lar ve Servisler aracılığıyla ağ iletişiminin nasıl sağlandığını ve pratik YAML örnekleriyle basit bir uygulama dağıtımının nasıl yapılacağını öğrendik. Son olarak, performans, güvenlik ve verimlilik için ileri düzey ipuçlarına ve en iyi uygulamalara değindik.

Kubernetes mimarisini anlamak, bu karmaşık ancak bir o kadar da güçlü platformu etkili bir şekilde kullanmanın anahtarıdır. Bu bilgi, uygulamalarınızı daha ölçeklenebilir, dayanıklı ve yönetilebilir hale getirmenize olanak tanır. Sorun giderme becerilerinizi geliştirir, kaynak kullanımınızı optimize eder ve dağıtık sistemlerin geleceği olan mikroservis tabanlı uygulamaları güvenle dağıtmanızı sağlar. Unutmayın, bu sadece bir başlangıç. Kubernetes evreni oldukça geniş ve keşfedilmeyi bekleyen birçok heyecan verici konu var. Serimizin bir sonraki bölümünde görüşmek üzere!

Sıkça Sorulan Sorular

1. Kubernetes sadece Docker ile mi çalışır?
   Hayır, Kubernetes sadece Docker ile çalışmaz. Aslında, Konteyner Çalışma Zamanı Arayüzü (CRI) sayesinde containerd, CRI-O gibi çeşitli OCI (Open Container Initiative) uyumlu konteyner çalışma zamanlarını destekler. Docker, konteyner teknolojisinin popülerleşmesinde büyük rol oynamış olsa da, Kubernetes'in esnek mimarisi farklı çalışma zamanlarıyla uyumlu çalışmasına olanak tanır.
2. Minikube nedir? Gerçek bir Kubernetes mi?
   Minikube, geliştiricilerin yerel makinelerinde tek düğümlü bir Kubernetes kümesi kurmalarını sağlayan bir araçtır. Evet, Minikube aslında tam teşekküllü bir Kubernetes kümesidir, ancak yalnızca tek bir düğüm üzerinde çalıştığı için üretim ortamları için uygun değildir. Öğrenme, test etme ve uygulama geliştirmek için harika bir ortam sağlar.
3. Kubernetes karmaşık mı, öğrenmesi ne kadar sürer?
   Kubernetes, başlangıçta karmaşık gelebilir, çünkü birçok yeni kavram ve bileşen içerir. Ancak temel prensipleri ve mimariyi kavradığınızda öğrenme süreci hızlanır. Deneyim ve sürekli pratikle, birkaç haftadan birkaç aya kadar değişen sürelerde temel düzeyde uzmanlaşmak mümkündür. Önemli olan, adım adım ilerlemek ve bolca pratik yapmaktır.
4. Kubernetes'i kullanmaya nereden başlamalıyım?
   Başlamak için en iyi yol, temel konteyner kavramlarını (Docker gibi) anlamak ve ardından Minikube veya Kind gibi yerel araçlarla tek düğümlü bir küme kurarak pratik yapmaktır. Bu makaledeki mimari kavramları iyice öğrenmek, YAML dosyaları ile Pod'lar ve Servisler oluşturmak, kubectl komutlarını öğrenmek sağlam bir başlangıç sağlayacaktır.
5. Control Plane ve Worker Node arasındaki temel fark nedir?
   Control Plane (Kontrol Düzlemi), Kubernetes kümesinin beyni ve yönetim merkezidir. Kümenin genel durumunu yönetir, kararlar alır (örneğin Pod'ları zamanlamak) ve kümenin istenen durumunu korumaya çalışır. Worker Nodes (Çalışan Düğümler) ise gerçek iş yüklerinin, yani uygulamalarınızın çalıştığı makinelerdir. Control Plane'den gelen talimatları yerine getirirler ve Pod'ları barındırırlar. Kısaca, Control Plane "ne yapılacağını" söyler, Worker Nodes ise "nasıl yapılacağını" uygulayarak "ne yapılması gerektiğini" gerçekleştirir.