Kubernetes Mimarisi ve Operasyonel Konseptleri

Modern yazılım geliştirme ekosisteminde, konteyner teknolojileri uygulamaları ve bağımlılıklarını izole, taşınabilir birimler halinde paketleyerek devrim yaratmıştır. Ancak, bu konteynerlerin yüzlercesini veya binlercesini üretim ortamında yönetme, ölçeklendirme ve ağ iletişimlerini sağlama ihtiyacı, “orkestrasyon” adı verilen karmaşık bir sorunu ortaya çıkarmıştır. Kubernetes (K8s), bu konteyner orkestrasyonu sorununu çözmek için endüstri standardı haline gelmiş, açık kaynaklı bir platformdur. Bu belgenin amacı, Kubernetes’in temel mimari bileşenlerini, operasyonel prensiplerini ve temel nesnelerini, profesyonel bir DevOps ve Sistem Mühendisi kitlesi için teknik bir derinlikle analiz etmektir. Rapor, sistemin temel mimarisinden başlayarak iş yüklerinin nasıl yönetildiğini, ağ yapısını, yapılandırma ve veri kalıcılığı stratejilerini ve son olarak komut satırı arayüzü (CLI) ile etkileşimi ele alan yapılandırılmış bir yol izleyecektir.

1.0 Kubernetes Temel Mimarisi: Kontrol Düzlemi ve Çalışan Düğümler

Kubernetes’in dağıtık mimarisi, sistemin temel kararlılığını ve ölçeklenebilirliğini sağlayan en kritik özelliğidir. Kümenin “beyin” (Kontrol Düzlemi) ve “kas gücü” (Çalışan Düğümler) olarak iki ana bileşen grubuna ayrılması, merkezi yönetim ve karar alma mekanizmaları ile dağıtık iş yükü yürütme kapasitesini birbirinden mantıksal olarak ayırır. Bu ayrım, bir yandan kümenin genel durumunun tutarlı bir şekilde yönetilmesini sağlarken, diğer yandan uygulamaların binlerce düğüme yayılarak çalışmasına olanak tanır. Bu tasarım, Kubernetes’in hem esnek hem de dayanıklı olmasının temelini oluşturur.

Kontrol Düzlemi (Control Plane) Analizi

Kontrol Düzlemi, Kubernetes kümesinin merkezi otoritesidir. Küme hakkında küresel kararlar alır, kümenin genel durumunu yönetir ve tüm bileşenlerin uyum içinde çalışmasını sağlar. Genellikle yüksek erişilebilirlik için kendi adanmış sunucularında çalıştırılır.

• kube-apiserver: Kontrol Düzlemi’nin “ön yüzü” ve kümenin tek iletişim noktasıdır. Tüm dış (örneğin, kubectl komutları) ve iç (diğer küme bileşenleri) iletişim, API Sunucusu üzerinden geçer. Bu merkezileştirme, güvenlik ve denetim için kritik bir kontrol noktası sağlar. Mimarisi gereği durumsuzdur (stateless); bu tasarım kararı, kube-apiserver‘ın yatay olarak ölçeklenmesini kolaylaştırır ve etcd‘yi kümenin mutlak tekil doğruluk kaynağı haline getirir.
• etcd: Kubernetes’in “hafızası” ve tekil doğruluk kaynağıdır (single source of truth). Kümenin tüm verilerinin (istenilen durum, mevcut durum, yapılandırmalar, Secret’lar vb.) saklandığı, tutarlı ve yüksek düzeyde erişilebilir bir anahtar/değer deposudur. kube-apiserver durumsuz olduğundan, kümenin gerçek durumu etcd içinde yaşar. Bu nedenle, etcd‘nin yedeklenmesi hayati önem taşır; kaybı, tüm kümenin hafızasının kaybı anlamına gelir.
• kube-scheduler: Görevi, yeni oluşturulmuş ancak henüz bir Düğüme atanmamış olan Pod’ları izlemektir. Bir Pod’un hangi Çalışan Düğümde çalışacağına karar verir. Bu kararı verirken kaynak gereksinimleri (CPU, bellek), donanım kısıtlamaları ve diğer politika kısıtlamalarını dikkate alarak en uygun düğümü seçer.
• kube-controller-manager: Kümenin durumunu aktif olarak düzenleyen “kontrol döngülerini” (control loops) çalıştıran bileşendir. Temel işlevi, etcd‘deki “istenilen durumu” gözlemlemek ve sistemin “mevcut durumunu” sürekli olarak bu istenilen duruma getirmek için gerekli eylemleri gerçekleştirmektir. Örneğin, “Düğüm Kontrolörü” (Node Controller) bir Çalışan Düğümün çökmesi durumunda bu durumu tespit ederken, “İş Kontrolörü” (Job Controller) tek seferlik görevleri yürüten Pod’ları yönetir.
• cloud-controller-manager: Bu bileşen, Kubernetes’in altyapıdan bağımsız (infrastructure-agnostic) olmasını sağlayan temel bir tasarım kararıdır. Yalnızca bulut sağlayıcıya özgü (AWS, Azure, GCP vb.) kontrol mantığını çalıştırır. Örneğin, LoadBalancer tipinde bir Servis talep edildiğinde, bu bileşen ilgili bulut sağlayıcının API’sini çağırarak fiziksel bir yük dengeleyici oluşturulmasını tetikler. Bu kasıtlı ayrım, Kubernetes’in çekirdek mantığını altyapı detaylarından ayırarak platformun her ortamda tutarlı bir şekilde çalışmasını sağlar. Şirket içi (on-premise) veya Minikube gibi yerel ortamlarda bu bileşen bulunmaz.

Çalışan Düğümler (Worker Nodes) Analizi

Çalışan Düğümler, uygulamaların fiilen çalıştığı ve konteynerlerin barındırıldığı makinelerdir (fiziksel veya sanal). Her Düğüm, Kontrol Düzlemi tarafından yönetilir ve uygulama Pod’larını çalıştırmak için gerekli hizmetleri içerir.

• kubelet: Her Çalışan Düğümde çalışan birincil ajandır. Kontrol Düzlemi’ndeki API Sunucusu ile iletişim kurarak kendisine atanan Pod tanımlarını (PodSpecs) alır. Bu tanımlara göre Pod’larda belirtilen konteynerlerin çalıştığından ve sağlıklı olduğundan emin olur. Ayrıca, Düğümün sağlık durumunu (nabzını) düzenli olarak Kontrol Düzlemi’ne raporlayarak kümenin genel durum bilgisine katkıda bulunur.
• kube-proxy: Her Düğümde çalışan bir ağ vekilidir (proxy) ve temel görevi Kubernetes Service kavramını uygulamaktır. Düğümlerdeki ağ kurallarını yöneterek, bir Servis’in sanal IP’sine gelen trafiği, o Servis’in arkasındaki doğru Pod’lara (başka bir Düğümde olsalar bile) yönlendirir.
• Konteyner Çalışma Zamanı (Container Runtime): Kubernetes’in kendisi doğrudan konteyner çalıştırmaz. Bunun yerine, konteynerleri fiilen çalıştıran yazılım olan Konteyner Çalışma Zamanı’na talimat verir. kubelet, containerd veya CRI-O gibi standart bir çalışma zamanı aracılığıyla konteynerlerin oluşturulmasını, başlatılmasını ve durdurulmasını yönetir.

Bu temel mimari bileşenlerin nasıl organize olduğunu anladıktan sonra, bir sonraki mantıksal soru, uygulamaların bu mimari üzerinde nasıl soyutlandığı ve çalıştırıldığıdır.

2.0 İş Yükü Yönetimi: Pod’lar ve Deployment’lar

Uygulamaların Kubernetes üzerinde nasıl soyutlandığını ve yaşam döngülerinin nasıl yönetildiğini anlamak, platformu etkin kullanmanın temelidir. Kubernetes, konteynerleri doğrudan yönetmek yerine, onları “Pod” adı verilen atomik bir birim içinde kapsüller. Bu yaklaşım, sıkı sıkıya bağlı konteyner gruplarının birlikte çalışmasını sağlar. Ancak Pod’lar geçici varlıklar olduğundan, onların yaşam döngüsü, ölçeklendirilmesi ve güncellenmesi “Deployment” gibi daha üst düzey kontrolörler aracılığıyla, Kubernetes’in bildirimsel yönetim felsefesine uygun olarak gerçekleştirilir.

Pod Analizi: Kubernetes’in Atomik Birimi

Kubernetes’te konteynerler yerine, onları kapsülleyen Pod’lar yönetilir. Bir Pod, Kubernetes nesne modelinde “oluşturulan en küçük ve en basit birimdir”. Bu tasarım, tek bir konteynerden daha fazlasını temsil eder; birden fazla, işbirliği yapan sürecin tek bir birim gibi davranmasını sağlayan bir soyutlamadır.

Pod kullanmanın temel nedenleri şunlardır:

• Paylaşılan Ağ: Bir Pod içindeki tüm konteynerler aynı ağ isim alanını, yani aynı IP adresini ve port alanını paylaşır. Bu, konteynerlerin birbirleriyle localhost üzerinden basit ve verimli bir şekilde iletişim kurmasını sağlar.
• Paylaşılan Depolama: Pod içindeki konteynerler, tanımlanmış Volumes aracılığıyla ortak depolama alanlarına erişebilir ve veri paylaşabilir.

Bu tasarım, ana uygulama konteynerinin yanında log toplayıcı veya veri senkronizasyonu gibi görevleri yürüten yardımcı konteynerleri barındıran “sidecar” desenini mümkün kılar.

Ancak, Pod’lar “geçici, tek kullanımlık varlıklar” olarak tasarlandığından, bir düğüm arızası veya manuel silme durumunda kalıcı değillerdir. Bu nedenle, onların yaşam döngüsünün, ölçeklenebilirliğini ve dayanıklılığını garanti altına alan daha üst düzey kontrolörler tarafından yönetilmesi gerekir.

Deployment ile Bildirimsel Yaşam Döngüsü Yönetimi

Deployment, özellikle “durumsuz” (stateless) uygulamalar için Pod’ların yaşam döngüsünü yöneten en yaygın kontrolördür. Deployment, Kubernetes’in temel felsefesi olan “bildirimsel” (declarative) yaklaşımı somutlaştırır. Kullanıcı sisteme “ne istediğini” (örneğin, “Bu uygulamadan 3 kopya çalışsın”) bir YAML dosyasında belirtir. Deployment kontrolörü, bu “istenilen duruma” ulaşmak için gerekli adımları atar. Bu süreçte, istenen sayıda Pod’un her zaman çalışmasını sağlayan ReplicaSet adlı daha alt düzey bir kontrolörü yönetir.

Deployment’ın iki temel görevi vardır:

• Ölçeklendirme (Scaling): replicas alanının değeri değiştirilerek uygulama kopyalarının sayısı manuel olarak kolayca artırılabilir veya azaltılabilir. Ayrıca, bir HorizontalPodAutoscaler (HPA) kaynağı kurularak, CPU kullanımı gibi metriklere dayalı olarak Pod sayısının otomatik olarak ölçeklendirilmesi de mümkündür.
• Yaşam Döngüsü Yönetimi (Güncellemeler): Rolling Update stratejisi, uygulama güncellemelerinin kesintisiz (zero-downtime) yapılmasını sağlar. Yeni versiyonu içeren Pod’lar kademeli olarak başlatılırken, eski versiyonu çalıştıran Pod’lar kademeli olarak durdurulur. Bu, güncelleme sırasında servisin sürekli erişilebilir kalmasını garanti eder. Hatalı bir sürüm dağıtıldığında ise Rollback mekanizması, tek bir komutla önceki stabil sürüme güvenli bir şekilde geri dönmeyi kolaylaştırır.

Pod’ların bu geçici doğası ve sürekli değişen IP adresleri, ağ üzerinde güvenilir iletişim için bir zorluk yaratır. Bir sonraki bölümde bu sorunun nasıl çözüldüğü ele alınacaktır.

3.0 Ağ Mimarisi ve Servis Keşfi

Pod’ların geçici IP adreslerine sahip olması, uygulamaların birbirleriyle güvenilir bir şekilde iletişim kurmasını zorlaştırır. Bir Pod yeniden başlatıldığında yeni bir IP adresi alır, bu da ona doğrudan IP üzerinden erişimi imkansız kılar. Kubernetes, bu kritik sorunu Service adı verilen bir soyutlama ile çözer. Service, bir grup Pod’a kararlı bir ağ uç noktası sağlar. Aynı zamanda, kaynakların mantıksal olarak izole edilmesi ve yönetilmesi için Namespace kavramı, küme içi ağ organizasyonunda önemli bir rol oynar.

Service: Kalıcı Adres ve Yük Dengeleme

Service nesnesi, “bir grup Pod üzerinde çalışan bir uygulamayı ağ servisi olarak ortaya çıkaran bir soyutlamadır”. Temelde iki kritik işlevi yerine getirir:

1. Kararlı Adres Sağlama (Servis Keşfi): Bir Service oluşturulduğunda, Kubernetes ona kararlı (değişmeyen) bir sanal IP adresi (ClusterIP) ve küme içi geçerli bir DNS adı atar. Kubernetes’in kendi iç DNS hizmeti sayesinde diğer Pod’lar, sürekli değişen Pod IP’lerini takip etmek yerine my-service.my-namespace.svc.cluster.local gibi sabit bir adres üzerinden hedef uygulamaya güvenilir bir şekilde bağlanır.
2. Yük Dengeleme (Load Balancing): Service, bir “seçici” (selector) kullanarak hangi Pod’ları hedefleyeceğini tanımlar (örneğin, app=backend etiketine sahip tüm Pod’lar). Her düğümde çalışan kube-proxy bileşeni, Servis’in sanal IP’sine gelen trafiği yakalar ve bu seçiciye uyan sağlıklı Pod’lar arasında dağıtarak temel bir yük dengeleme işlevi görür.

Namespace: Mantıksal Küme İzolasyonu

Namespace, tek bir fiziksel Kubernetes kümesini, birden fazla sanal kümeye bölmenin bir yoludur. Kaynakları (Pod, Service, Deployment vb.) mantıksal olarak izole etmek için kullanılır. Örneğin, aynı kümede development, staging ve production ortamlarını birbirinden ayırmak için üç farklı Namespace oluşturulabilir.

Ağ iletişimi açısından, bir Pod kendi Namespace’indeki bir Servis’e kısa adıyla (my-service) erişebilirken, başka bir Namespace’deki bir Servis’e erişmek için tam nitelikli alan adını (FQDN) (my-service.other-namespace.svc.cluster.local) kullanmalıdır. Kubernetes, default (kullanıcılar için varsayılan), kube-system (Kontrol Düzlemi bileşenleri için) ve kube-public gibi önceden tanımlanmış ad alanları ile birlikte gelir.

Servis Türleri Karşılaştırması

Bir Service nesnesinin type özelliği, onun küme içinden mi yoksa dışından mı erişilebilir olacağını belirler.

Servis Tipi	Erişilebilirlik	Analiz ve Kullanım Senaryosu
ClusterIP	Yalnızca Küme İçi	Servis’e yalnızca küme içinden erişilebilen kararlı bir sanal IP atar. Bu varsayılan tiptir. Küme içi bileşenlerin (örneğin, bir frontend’in bir veritabanına) güvenli iletişimi için kullanılır.
NodePort	Küme Dışı (Düğüm IP:Port)	Her Çalışan Düğümün IP’sinde statik bir port üzerinden servise erişim sağlar. Geliştirme veya harici bir yük dengeleyiciyi manuel olarak yapılandırma gibi senaryolar için uygundur.
LoadBalancer	Küme Dışı (Harici IP)	Destekleyen bulut sağlayıcılarda harici bir yük dengeleyici oluşturulmasını tetikler. Üretim ortamında uygulamaları internete yüksek erişilebilirlikli bir şekilde sunmanın standart yoludur. LoadBalancer tipinin, NodePort üzerine inşa edildiğini belirtmek önemlidir; bulut sağlayıcının yük dengeleyicisi, trafiği Düğümlerin NodePort’una yönlendirir.

Uygulamaların ağ üzerinden iletişim kurmasını sağladıktan sonra, bu uygulamaların ihtiyaç duyduğu yapılandırma verilerinin nasıl yönetileceği bir sonraki önemli konudur.

4.0 Yapılandırma ve Hassas Veri Yönetimi

İyi tasarlanmış uygulamalar, yapılandırma verilerini uygulama kodundan, yani konteyner imajından ayırır. Bir veritabanı adresi veya API anahtarı gibi değerlerin doğrudan kod içine gömülmesi, taşınabilirliği ve güvenliği zayıflatır. Kubernetes, bu ayrıştırmayı (decoupling) ConfigMap ve Secret adı verilen iki temel nesne ile sağlar. Bu nesneler, yapılandırma verilerinin çalışma zamanında Pod’lara güvenli ve esnek bir şekilde enjekte edilmesine olanak tanır.

ConfigMap: Çevresel Yapılandırma Yönetimi

ConfigMap, “gizli olmayan” verileri anahtar-değer çiftleri halinde saklayan bir API nesnesidir. Genellikle uygulama ayarları, komut satırı argümanları veya yapılandırma dosyalarının içeriğini tutmak için kullanılır ve 1 MiB boyut sınırına sahiptir.

Bir Pod, ConfigMap verilerini iki temel yöntemle kullanabilir:

1. Ortam Değişkenleri Olarak: ConfigMap’teki bir anahtarın değeri, konteynere bir ortam değişkeni olarak enjekte edilebilir. Bu yöntem basit ve yaygındır.
2. Volume Olarak Mount Etme: ConfigMap, bir birim (volume) olarak Pod’a bağlanabilir. Bu durumda, ConfigMap’teki her anahtar, mount edilen dizin altında bir dosya haline gelir ve dosyanın içeriği o anahtarın değeri olur.

Bu iki yöntem arasındaki kritik fark, güncellemelerin nasıl işlendiğidir. Birim olarak bağlanan ConfigMap’ler güncellendiğinde, bu değişiklikler çalışan Pod’daki dosyalara otomatik olarak yansıtılır. Ancak ortam değişkeni olarak enjekte edilen veriler güncellenmez; değişikliğin geçerli olması için Pod’un yeniden başlatılması gerekir.

Secret: Hassas Veriler için Anlamsal Tanımlama

Secret, parolalar, OAuth token’ları ve SSH anahtarları gibi “az miktarda hassas veriyi” saklamak için tasarlanmış bir nesnedir. Kullanım yöntemleri (ortam değişkeni, volume, imagePullSecrets) ConfigMap ile neredeyse aynıdır.

Ancak, yaygın bir yanılgının aksine, varsayılan olarak Secret verileri şifrelenmez; yalnızca Base64 formatında kodlanır ve bu kodlama kolayca geri çözülebilir.

ConfigMap ve Secret arasındaki asıl fark kriptografik değil, “semantik” (anlamsal) bir ayrımdır. Bir veriyi Secret olarak tanımlamak, Kubernetes’e bu verinin hassas olduğunu belirtir. Bu sayede platform, bu veriye farklı davranır: kubectl get secret komutu varsayılan olarak içeriği gizler ve küme yöneticileri, Secret’lara erişim için daha sıkı Rol Tabanlı Erişim Kontrolü (RBAC) politikaları uygulayabilir. etcd üzerinde “duran verinin şifrelenmesi” (encryption at rest) mümkündür, ancak bu, küme yöneticisi tarafından ayrıca yapılandırılması gereken gelişmiş bir güvenlik önlemidir.

Durumsuz uygulamaların yapılandırması ele alındıktan sonra, veritabanları gibi verinin kalıcı olması gereken durum bilgili (stateful) uygulamaların ihtiyaçlarına geçilebilir.

5.0 Durum Bilgili Uygulamalar için Veri Kalıcılığı

Deployment’lar tarafından yönetilen geçici ve değiştirilebilir Pod’lar, durumsuz (stateless) web sunucuları veya API’ler için idealdir. Ancak veritabanları gibi durum bilgili (stateful) uygulamalar için, verinin Pod’un yaşam döngüsünden bağımsız olarak kalıcı olması gerekir. Bir veritabanı Pod’u çöktüğünde ve yeniden başladığında, verilerine kaldığı yerden devam edebilmelidir. Kubernetes, bu kritik sorunu PersistentVolume (PV) ve PersistentVolumeClaim (PVC) adı verilen iki aşamalı, güçlü bir soyutlama ile çözer.

PV ve PVC Soyutlaması: Rollerin Ayrıştırılması

Bu mimari, Kontrol Düzlemi’ndeki cloud-controller-manager ile aynı temel felsefeyi yansıtır: rollerin ve sorumlulukların ayrıştırılması. Depolama altyapısını sağlayan küme yöneticisi ile depolama talep eden geliştiricinin sorumlulukları net bir şekilde ayrılmıştır.

• PersistentVolume (PV): Küme yöneticisi tarafından oluşturulur ve kümedeki fiziksel bir depolama parçasını (örneğin, bir AWS EBS diski veya NFS paylaşımı) temsil eder. PV, depolamanın nasıl sağlandığını (kapasite, erişim modu, hız vb.) tanımlar. Yönetici, altyapı kaynaklarını PV olarak hazırlar ve kümenin kullanımına sunar.
• PersistentVolumeClaim (PVC): Geliştirici tarafından oluşturulan bir depolama talebidir. Geliştirici, altyapı detaylarını bilmek zorunda değildir. Sadece “Bana 5Gi’lık, aynı anda tek bir Pod tarafından yazılabilen (ReadWriteOnce) bir depolama lazım” gibi soyut bir talepte bulunur.

Bağlanma (Binding) Süreci ve Taşınabilirlik

Bir geliştirici bir PVC oluşturduğunda, Kubernetes kontrol düzlemi bu talebi karşılayabilecek mevcut bir PV arar. Uygun bir PV bulduğunda, bu ikisini birbirine “bağlar” (bind) ve her ikisinin de durumunu “Bound” (Bağlı) olarak değiştirir. Geliştirici, Pod tanımında depolama birimi olarak doğrudan PV’yi değil, yalnızca PVC’nin adını referans gösterir.

Bu soyutlamanın en büyük faydası, uygulama tanımlarını (YAML dosyalarını) altyapıdan tamamen bağımsız ve taşınabilir hale getirmesidir. Geliştiricinin yazdığı Pod tanımı, depolamanın AWS’den mi, Google Cloud’dan mı yoksa şirket içi bir NFS sunucusundan mı geldiğini bilmesine gerek kalmaz; sadece belirttiği talebin karşılanmasını bekler.

Kubernetes’in temel mimari ve nesne modellerini anladıktan sonra, bu bileşenlerle etkileşim kurmak için kullanılan komut satırı arayüzü kubectl‘e geçiş yapabiliriz.

6.0 Küme Etkileşimi ve Hata Ayıklama: kubectl

kubectl, Kubernetes’in teorik kavramlarını pratiğe dökmek ve küme kaynaklarını yönetmek için kullanılan birincil komut satırı arayüzüdür (CLI). Tüm komutlar, Kontrol Düzlemi’ndeki kube-apiserver ile konuşarak gerçekleştirilir. Bu bölüm, komutları rastgele bir liste olarak sunmak yerine, bir uygulamanın çalışmadığı durumlarda sorunu teşhis etmek için kullanılan standart bir triyaj (triage) akışını analiz edecektir.

Sistematik Hata Ayıklama Akışı

Bir uygulamanın beklendiği gibi çalışmadığı durumlarda, sorunun kaynağını bulmak için genellikle aşağıdaki mantıksal akış izlenir:

1. Adım 1: Gözlem (get): İlk adım, kubectl get pods komutu ile Pod’un genel durumunu kontrol etmektir. Pod’un durumu Running (Çalışıyor) yerine CrashLoopBackOff (Sürekli Çöküyor), ImagePullBackOff veya Error gibi bir durumdaysa, sorun olduğunu anlarsınız.
2. Adım 2: Küme Düzeyi Teşhis (describe): get komutunun ötesinde detaylı bilgi almak için kubectl describe pod <pod-adi> komutu kullanılır. Bu komutun çıktısındaki en önemli bölüm, genellikle en altta yer alan Events (Olaylar) kısmıdır. Kubernetes’in Pod’u neden başlatamadığına dair kritik ipuçları burada bulunur. ImagePullBackOff (imaj çekilemedi) gibi küme düzeyindeki sorunlar bu adımda tespit edilir.
3. Adım 3: Uygulama Düzeyi Teşhis (logs): Eğer describe komutu Pod’un başarıyla başlatıldığını ancak bir süre sonra çöktüğünü (CrashLoopBackOff) gösteriyorsa, sorun artık Kubernetes katmanında değil, konteyner içindeki uygulamanın kendisindedir. kubectl logs <pod-adi> komutu, konteynerin standart çıktı (stdout/stderr) loglarını göstererek “Veritabanı bağlantısı başarısız” gibi uygulama-spesifik hataların bulunmasını sağlar.

Temel kubectl Komutları Tablosu

Aşağıdaki tablo, en yaygın kubectl komutlarını ve temel işlevlerini özetlemektedir:

Komut	İşlevi (Amaç)	Örnek Kullanım
kubectl get	Gözlem (Listeleme): Kaynakların (Pod, Service, Node) mevcut durumunu hızlıca listeler.	kubectl get pods --all-namespaces
kubectl describe	Gözlem (Detay): Belirli bir kaynak hakkında detaylı bilgi ve ilişkili ‘Olayları’ (Events) gösterir. Hata ayıklama için kritiktir.	kubectl describe pod <pod-adi>
kubectl apply	Eylem (Bildirimsel): Bir YAML dosyasında tanımlanan “istenilen durumu” kümeye uygular. Kaynakları oluşturur veya günceller.	kubectl apply -f deployment.yaml
kubectl delete	Eylem (İmha): Bir kaynağı (dosyadan veya ada göre) kümeden kaldırır.	kubectl delete -f service.yaml
kubectl logs	Hata Ayıklama (Uygulama): Bir Pod içindeki konteynerin standart çıktı (stdout/stderr) loglarını gösterir.	kubectl logs <pod-adi> -c <konteyner-adi>

Raporun ana teknik bölümlerini tamamladıktan sonra, ele alınan temel kavramları özetleyerek sonuca ulaşabiliriz.

Sonuç

Bu teknik inceleme, Kubernetes’in temel mimari ve operasyonel prensiplerini analiz etmiştir. Rapor boyunca, platformun dağıtık sistemleri yönetmek için sunduğu güçlü soyutlamalar ve otomasyon mekanizmaları detaylandırılmıştır. İncelenen temel direkler, Kubernetes’in modern bulut-native uygulamalar için neden vazgeçilmez bir standart haline geldiğini göstermektedir.

Aşağıdaki temel kavramlar, raporun ana bulgularını özetlemektedir:

1. Mimari: Kontrol Düzlemi’nin (beyin) merkezi karar alma rolü ile Çalışan Düğümlerin (kas gücü) iş yükü yürütme görevi arasındaki işlevsel ayrım, sistemin kararlılığını ve ölçeklenebilirliğini sağlar.
2. İş Yükleri: Pod’lar, birlikte konumlandırılmış konteynerler için atomik birim rolü üstlenirken, Deployment’lar bildirimsel bir yaklaşımla uygulamaların yaşam döngüsünü, ölçeklendirmesini ve güncellemelerini yönetir.
3. Ağ Mimarisi: Service nesnesi, Pod’ların geçici ve dinamik doğasına karşı, kararlı IP adresleri ve küme içi yük dengeleme sağlayarak servis keşfi ve iletişim sorununu çözer.
4. Yapılandırma: ConfigMap ve Secret nesneleri, yapılandırma verilerini uygulama kodundan ayırarak taşınabilirliği ve güvenliği artırır.
5. Veri Kalıcılığı: PersistentVolume (PV) ve PersistentVolumeClaim (PVC) soyutlaması, altyapıdan bağımsız bir şekilde durum bilgili uygulamaların veri kalıcılığı ihtiyacını karşılar.

Bu raporda ele alınan konular Kubernetes’in temellerini oluşturmaktadır. Bu temel üzerine inşa edilecek bir sonraki adımlar, StatefulSet (durum bilgili uygulamalar için gelişmiş bir kontrolör), Ingress (dış trafiği yönetmek için daha gelişmiş bir mekanizma) ve RBAC (Rol Tabanlı Erişim Kontrolü) gibi daha ileri düzey konuları içerebilir.