Kubernetes ‘e Giriş : Dağıtık Sistemler için Kapsamlı Başlangıç Kılavuzu

Modern yazılım geliştirme, konteyner teknolojileri sayesinde köklü bir değişim geçirmiştir. Konteynerler, uygulamaları ve bağımlılıklarını izole, taşınabilir birimler halinde paketlemeyi sağlar. Ancak, bu konteynerlerin yüzlerce veya binlerce kopyasını üretim ortamında yönetmek, ölçeklendirmek, ağ iletişimlerini sağlamak ve hatalara karşı dayanıklılık kazandırmak, “orkestrasyon” olarak bilinen karmaşık bir sorunu ortaya çıkarmıştır. Kubernetes (genellikle “K8s” olarak kısaltılır), bu konteyner orkestrasyonu sorununu çözmek için endüstri standardı haline gelmiş, açık kaynaklı bir platformdur.

Bu kılavuz, Kubernetes öğrenme yolculuğunuzun başında olduğunuzu varsayarak, platformun temel direklerini ana başlıklar halinde sunmak üzere tasarlanmıştır. Yüzeysel bir özet yerine, bu bileşenlerin neden var olduğunu, birbirleriyle nasıl etkileşime girdiğini ve dağıtık bir sistemi yönetmek için hangi sorunları çözdüğünü analiz edecektir. Kılavuz, teorik mimariden başlayarak, uygulamaların nasıl çalıştırılacağına, ağ ve depolama gibi kritik kavramlara ve son olarak kümenizi yönetmek için kullanacağınız pratik komutlara kadar uzanan yapılandırılmış bir yol izleyecektir.

Bölüm 1: Kubernetes Mimarisi: Beyin ve Kas Gücü

Bir Kubernetes kümesi, birbiriyle koordineli çalışan iki ana bileşen grubundan oluşur: kararları veren “Kontrol Düzlemi” (Beyin) ve asıl işi yapan “Çalışan Düğümler” (Kas Gücü). Bu mimari, sistemin hem merkezi olarak yönetilmesini hem de iş yüklerinin dağıtık bir şekilde çalıştırılmasını sağlar.¹

Kontrol Merkezi (Control Plane): Kümenin Beyni

Kontrol Düzlemi, küme hakkında küresel kararlar alır (örneğin, uygulamaların zamanlanması) ve kümenin genel durumunu yönetir. Bir Kontrol Düzlemi genellikle kendi adanmış sunucularında çalışır, ancak Minikube gibi öğrenme ortamlarında bir çalışan düğümle aynı makinede bulunabilir.¹

Kontrol Düzlemi’nin ana bileşenleri şunlardır ¹:

1. kube-apiserver (API Sunucusu):

• Kontrol düzleminin “ön yüzü” ve beynin “ağzıdır”. Kubernetes API’sini sunan tek bileşendir.
• Tüm dış (örneğin, sizin kubectl komutlarınız) ve iç (diğer bileşenler) iletişim, API Sunucusu üzerinden geçer.
• Yatay olarak ölçeklenecek şekilde tasarlanmıştır; yani, yüksek erişilebilirlik için birden fazla kopya çalıştırılabilir.¹

2. etcd (Veri Deposu):

• Kubernetes’in “hafızasıdır”. 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.
• API Sunucusu durumsuzdur (stateless); kümenin gerçek durumu etcd içinde yaşar. Bu nedenle etcd, kümenin tekil doğruluk kaynağıdır (single source of truth) ve yedeklenmesi kritik öneme sahiptir.¹ etcd’nin kaybı, tüm kümenin hafızasının kaybıdır.

3. kube-scheduler (Zamanlayıcı):

• Görevi, yeni oluşturulan 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ı, veri yerelliği ve diğer politikaları dikkate alır.¹

4. kube-controller-manager (Kontrolör Yöneticisi):

• Kümenin durumunu aktif olarak düzenleyen “kontrol döngülerini” (control loops) çalıştıran bileşendir.
• Temel işlevi basittir: etcd’deki “istenilen durumu” (desired state) gözlemler ve sistemin “mevcut durumunu” (current state) sürekli olarak istenilen duruma getirmek için eylemler gerçekleştirir.
• Örneğin, “Düğüm Kontrolörü” bir Düğümün çöküp çökmediğini izler; “İş Kontrolörü” tek seferlik görevleri yürüten Pod’ları yönetir.¹

5. cloud-controller-manager (Bulut Kontrolör Yöneticisi):

• Bu bileşen, Kubernetes’in altyapıdan bağımsız (infrastructure-agnostic) olmasını sağlayan kilit 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, Bölüm 3’te görülecek olan LoadBalancer tipinde bir Servis talep ettiğinizde, bu bileşen bulut sağlayıcınızın API’sine giderek fiziksel bir yük dengeleyici oluşturur.
• kube-controller-manager ile cloud-controller-manager arasındaki bu kasıtlı ayrım, Kubernetes’in çekirdek mantığını bulut sağlayıcı detaylarından ayırır. Bu sayede Kubernetes, halka açık bir bulutta veya Minikube ² gibi yerel bir geliştirme ortamında (kendi tesislerinizde çalışırken cloud-controller-manager bulunmaz) aynı tutarlılıkla çalışabilir.¹

Çalışan Düğümler (Worker Nodes): Kas Gücü

Düğümler (Node), uygulamalarınızın fiilen çalıştığı 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.¹

Çalışan Düğüm bileşenleri şunlardır ¹:

1. kubelet:

• Her Düğümde çalışan birincil ajandır. Kontrol Düzlemi’ndeki API Sunucusu ile Düğüm arasındaki ana iletişim kanalıdır.
• API Sunucusu’ndan kendisine atanan Pod tanımlarını (PodSpecs) alır ve bu Pod’larda tanımlanan konteynerlerin çalıştığından ve sağlıklı olduğundan emin olur.
• Düğümün “sağlık durumunu” (nabzını) düzenli olarak Kontrol Düzlemi’ne bildirir.

2. kube-proxy:

• Her Düğümde çalışan bir ağ vekilidir (proxy). Kubernetes Service (Bölüm 3) kavramını uygulamaktan sorumludur.
• Düğümlerdeki ağ kurallarını (genellikle işletim sisteminin paket filtreleme katmanını kullanarak) yönetir. Temel görevi, bir Servis’in sanal IP’sine gelen trafiği, o Servis’in arkasındaki doğru Pod’lara (belki de başka bir Düğümdeki) yönlendirmektir.¹

3. Konteyner Çalışma Ortamı (Container Runtime):

• Bu, konteynerleri fiilen çalıştıran yazılımdır. Kubernetes’in kendisi konteyner çalıştırmaz; kubelet aracılığıyla Konteyner Çalışma Zamanı’na (örn. containerd veya CRI-O) talimat verir.¹

Bölüm 2: Kubernetes İş Yükleri: Pod’lar ve Deployment’lar

Mimariyi anladıktan sonraki soru, “Uygulamamı bu kümede nasıl çalıştırırım?” olur. Cevap, Kubernetes’in iki temel iş yükü nesnesi olan Pod ve Deployment’ta yatar.

Pod Analizi: Kubernetes’in Atomik Birimi

Kubernetes dünyasında, konteynerleri doğrudan çalıştırmazsınız. Bunun yerine, konteynerleri kapsülleyen bir yapı olan Pod’u yönetirsiniz.

Bir Pod, Kubernetes nesne modelindeki “oluşturduğunuz veya dağıttığınız en küçük ve en basit birimdir”.³

Peki, neden doğrudan konteynerler yerine Pod’ları kullanıyoruz? Pod, basit bir konteyner sarmalayıcıdan (wrapper) daha fazlasıdır; birden fazla, işbirliği yapan sürecin (konteyner olarak) tek bir birim gibi davranmasını sağlayan bir soyutlamadır. Bir Pod içindeki tüm konteynerler, aşağıdaki kaynakları paylaşır ³:

1. Paylaşılan Ağ: Pod’daki tüm konteynerler aynı ağ isim alanını (network namespace), yani aynı IP adresini ve port alanını paylaşır. Bir konteyner localhost:8080 portunu dinliyorsa, aynı Pod’daki diğer bir konteyner ona localhost:8080 üzerinden erişebilir.
2. Paylaşılan Depolama: Pod içindeki konteynerler, Volumes (Bölüm 5’te detaylanacak) olarak tanımlanan depolama alanlarını paylaşabilir.³

Bu tasarım, “sidecar” deseni olarak bilinen güçlü bir modeli mümkün kılar. Örneğin, bir Pod’unuzda ana uygulamanızı (örn. bir web sunucusu) çalıştıran bir konteyner ve aynı Pod içinde, ana uygulamanın loglarını toplayıp merkezi bir sisteme gönderen bir “sidecar” (yardımcı) konteyner olabilir. Bu iki konteyner, localhost ve paylaşılan bir disk alanı üzerinden sıkı bir şekilde entegre çalışır. Pod, bu “atomik” birimi temsil eder.

Ancak, Pod’ların kritik bir özelliği vardır: “geçici, tek kullanımlık varlıklar” (ephemeral, disposable entities) olarak tasarlanmışlardır.³ Bir Düğüm çöktüğünde veya Pod’u manuel olarak sildiğinizde, o Pod yok olur. Bu nedenle, Pod’ları nadiren doğrudan oluşturursunuz. Bunun yerine, onların yaşam döngüsünü yöneten daha üst düzey kontrolörler kullanırsınız.³

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

Deployment, Pod’ların yaşam döngüsünü yöneten en yaygın kontrolördür ve “durumsuz” (stateless) uygulamalar (örn. web sunucuları, API’ler) için idealdir.

Deployment, Pod’lar ve ReplicaSet’ler (belirli bir Pod şablonunun istenen sayıda kopyasının her zaman çalışmasını sağlayan bir alt kontrolör) için “bildirimsel güncellemeler” (declarative updates) sağlar.⁴

“Bildirimsel” yaklaşım, Kubernetes’in temel felsefesidir. Siz sisteme nasıl yapılacağını (imperative) söylemezsiniz; sadece ne istediğinizi (declarative) söylersiniz. Deployment YAML dosyanızda “Bu uygulamadan 3 kopya (replica) istiyorum” dersiniz. Deployment kontrolörü (Bölüm 1’deki kube-controller-manager’ın ¹ bir parçası), mevcut durumu (örn. 0 kopya) istenen duruma (3 kopya) getirmek için gereken adımları (3 Pod oluşturmak) atar.

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

1. Ölçeklendirme (Scaling):

• Manuel Ölçeklendirme: Deployment tanımındaki replicas sayısını 3’ten 10’a çıkarabilirsiniz. Kontrolör, 7 yeni Pod’u otomatik olarak zamanlar (schedule eder).⁴
• Otomatik Ölçeklendirme (Autoscaling): Bir HorizontalPodAutoscaler (HPA) kaynağı kurarak, Deployment’ınızın CPU kullanımı gibi metriklere göre Pod sayısını otomatik olarak artırmasını veya azaltmasını sağlayabilirsiniz.⁴

2. Yaşam Döngüsü Yönetimi (Güncellemeler):

• Rolling Updates: Deployment’taki Pod şablonunu (örn. konteyner image versiyonunu v1.0’dan v1.1’e) güncellediğinizde, Deployment kontrolörü akıllı bir güncelleme yapar. Tüm eski Pod’ları bir anda durdurmak yerine, yeni v1.1 Pod’larını kademeli olarak başlatır ve eski v1.0 Pod’larını kademeli olarak durdurur. Bu, uygulamanızın güncelleme sırasında kesintisiz (zero-downtime) hizmet vermesini sağlar.⁴
• Rollbacks (Geri Dönüşler): Deployment, eski ReplicaSet’lerin “geçmişini” tutar. Eğer yeni v1.1 sürümünün hatalı olduğunu fark ederseniz, tek bir komutla önceki stabil sürüme güvenli bir şekilde geri dönebilirsiniz.⁴

Bölüm 3: Ağ Mimarisi: Servis Keşfi ve İletişim

Bölüm 2’de Pod’ların “geçici” olduğunu ve sürekli olarak oluşturulup yok edildiğini öğrendik.³ Bir Pod öldüğünde ve yeniden yaratıldığında (belki de farklı bir Düğümde), yeni bir IP adresi alır. Bu durum, kritik bir soruyu gündeme getirir: Eğer Pod IP’leri sürekli değişiyorsa, uygulamalar (örn. bir frontend Pod’u) birbirlerini (örn. bir backend Pod’unu) ağ üzerinde nasıl güvenilir bir şekilde bulabilir?

Service (Servis): Kalıcı Adres Sorunu

Bu sorunun çözümü Service (Servis) adı verilen bir Kubernetes soyutlamasıdır. Service, “bir grup Pod üzerinde çalışan bir uygulamayı ağ servisi olarak ortaya çıkaran bir soyutlamadır”.⁵

Service iki temel işlevi yerine getirir:

1. Kararlı Adres Sağlama (Servis Keşfi):

• Bir Service oluşturduğunuzda, Kubernetes ona kararlı (değişmeyen) bir sanal IP adresi (ClusterIP) ve küme içinde geçerli bir DNS adı atar.⁵
• Kubernetes’in kendi iç DNS hizmeti ⁵, my-service.my-ns (benim-servisim.benim-ad-alanım) gibi bir DNS kaydı oluşturur.
• Artık diğer Pod’lar, sürekli değişen Pod IP’lerini takip etmek yerine, bu kararlı DNS adına bağlanır.⁷

2. Yük Dengeleme (Load Balancing):

• Service, bir “seçici” (selector) kullanarak hangi Pod’ların bu servise ait olduğunu tanımlar (örn. app=backend etiketine sahip tüm Pod’lar).
• Bölüm 1’de bahsedilen kube-proxy ¹, her Düğümde çalışarak Servis’in sanal IP’sine gelen trafiği yakalar ve o an “sağlıklı” olan ve seçiciye uyan Pod’lar arasında dağıtır (yük dengelemesi yapar).⁷

Namespace (Ad Alanı): Küme İçinde Sanal Kümeler

Namespace (Ad Alanı), “kaynak adları için bir kapsam sağlayan” bir mekanizmadır.⁵ Tek bir fiziksel Kubernetes kümesini, birden fazla sanal kümeye bölmenin bir yoludur.

Namespace’ler, kaynakları mantıksal olarak izole etmek için kullanılır. Örneğin, aynı kümede “development”, “staging” ve “production” ortamlarını ayırmak için üç farklı Namespace kullanabilirsiniz.⁵

Ağ iletişimi açısından Namespace’ler, Servis keşfini de etkiler ⁵:

• Pod’lar, kendi Namespace’lerindeki Servis’leri kısa adıyla (örn. my-service) bulabilirler.
• Başka bir Namespace’deki bir Servis’e erişmek için ise tam nitelikli alan adını (FQDN) kullanmaları gerekir (örn. my-service.other-namespace.svc.cluster.local).

Kubernetes, default (kullanıcılar için varsayılan alan), kube-system (Kontrol Düzlemi bileşenlerinin çalıştığı alan) ve kube-public (herkes tarafından okunabilir kaynaklar için) gibi önceden tanımlanmış Ad Alanları ile birlikte gelir.⁵

Servis Türleri Analizi: ClusterIP, NodePort ve LoadBalancer

Bir Service oluştururken, onun “tipini” (type) belirtirsiniz. Bu tip, Servis’in kümenin içinden mi yoksa dışından mı erişilebilir olacağını belirler. Bu servis tipleri, genellikle birbirinin üzerine inşa edilen hiyerarşik katmanlar olarak düşünülebilir.

Tablo 1: Servis Türleri Karşılaştırması ⁶

Servis Tipi	Erişilebilirlik	Açıklama	Kullanım Senaryosu
ClusterIP	Yalnızca Küme İçi	Servise yalnızca küme içinden erişilebilen kararlı bir sanal IP atar. Bu, herhangi bir tip belirtmezseniz kullanılan varsayılan türdür.6	Küme içindeki uygulamaların birbirleriyle konuşması (örn. bir frontend Pod’unun bir veritabanı Servis’ine bağlanması).7
NodePort	Küme Dışı (Düğüm IP:Port)	Her Çalışan Düğümün IP’sinde statik bir port (örn. 30000-32767 aralığında) üzerinden servisi erişilebilir kılar. Otomatik olarak bir ClusterIP servisi de oluşturur.6	Geliştirme veya test amaçlı hızlı erişim. Minikube 2 gibi ortamlarda veya harici bir yük dengeleyiciyi manuel olarak yapılandırırken kullanılır.6
LoadBalancer	Küme Dışı (Harici IP)	(Yalnızca destekleyen bulut ortamlarda) harici bir yük dengeleyici (örn. AWS ELB, Google Cloud LB) oluşturulmasını tetikler. Bu LB’ye ait kararlı bir dış IP adresi atanır.6	Üretim ortamında, uygulamaları internete veya dış dünyaya “düzgün” ve yüksek erişilebilirlikli bir şekilde açmanın standart yoludur.8

LoadBalancer tipi, NodePort’un üzerine inşa edilir. Bulut sağlayıcının oluşturduğu harici yük dengeleyici, gelen trafiği kümedeki Düğümlerin NodePort’una yönlendirir. NodePort servisi de bu trafiği alıp ilgili ClusterIP üzerinden Pod’lara iletir.⁶

Bölüm 4: Yapılandırma ve Hassas Veri Yönetimi

İyi bir uygulama tasarımı, yapılandırma (konfigürasyon) verilerini uygulama kodundan (konteyner imajı) ayırmayı gerektirir.⁹ Bir veritabanı bağlantı adresi veya bir API anahtarı, konteyner imajının içine “hard-coded” (sabit kodlanmış) olmamalıdır. Kubernetes, bu ayrıştırmayı (decoupling) iki temel nesne ile sağlar: ConfigMap ve Secret.

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

Bir ConfigMap, “gizli olmayan” (non-confidential) verileri anahtar-değer çiftleri halinde saklayan bir API nesnesidir.⁹ Genellikle uygulama ayarları, ortam değişkenleri veya yapılandırma dosyalarının içeriğini tutmak için kullanılır.

ConfigMap’ler genellikle kubectl create configmap komutuyla ¹¹ veya bir YAML dosyasıyla oluşturulur ve 1 MiB boyut sınırına sahiptir.⁹

Bir Pod, ConfigMap’teki verileri temel olarak iki yöntemle kullanabilir ⁹:

1. Ortam Değişkenleri (Environment Variables) Olarak: Pod tanımında, ConfigMap’teki bir anahtarın değeri (key), konteynere bir ortam değişkeni olarak enjekte edilebilir (env.valueFrom.configMapKeyRef).
2. Volume (Birim) Olarak Mount Etme: ConfigMap, bir birim (volume) olarak Pod’a “mount” edilebilir. Bu durumda, ConfigMap’teki her anahtar (key), mount edilen dizin (örn. /etc/config) altında bir dosya haline gelir ve dosyanın içeriği o anahtarın değeri (value) olur.

Bu iki yöntem arasında kritik bir fark vardır: Bir birim olarak mount edilen ConfigMap’ler, Pod çalışırken güncellenirse, bu değişiklikler Pod’daki dosyalara otomatik olarak yansıtılır (kubelet’in senkronizasyon periyoduna bağlı olarak). Ancak, ortam değişkeni olarak enjekte edilen ConfigMap verileri güncellenmez; değişikliğin geçerli olması için Pod’un yeniden başlatılması gerekir.⁹

Secret: Parolalar ve Token’lar için Güvenli Depolama

Secret (Sır), “az miktarda hassas veri” (parolalar, OAuth token’ları, SSH anahtarları vb.) saklamak için tasarlanmıştır.¹²

Kullanım yöntemleri ConfigMap ile neredeyse aynıdır: Secret’lar da ortam değişkenleri (secretKeyRef) olarak veya bir birim (volume) olarak mount edilen dosyalar şeklinde Pod’lara enjekte edilebilir. Ayrıca, özel (private) Docker registry’lerinden imaj çekmek için gereken kimlik bilgilerini tutan imagePullSecrets olarak da kullanılırlar.¹²

Yeni başlayanlar arasında yaygın bir yanılgı, “Secret” adının bu verilerin şifrelendiği (encrypted) anlamına geldiğini düşünmektir. Bu, varsayılan olarak doğru değildir. Bir Secret oluşturduğunuzda ¹³, admin gibi bir dize YWRtaW4= şeklinde Base64 formatına kodlanır (encoded), ancak bu şifrelenmez ve kolayca geri çözülebilir.¹³

ConfigMap ⁹ ve Secret arasındaki asıl fark, kriptografik değil, semantiktir (anlamsal). Bir veriyi Secret olarak tanımlamak, Kubernetes’e bu verinin “hassas” olduğunu belirtir. Bu sayede Kubernetes, bu veriye farklı davranır:

• kubectl get secret komutu varsayılan olarak içeriği göstermez.
• Küme yöneticileri, Secret’lara erişim için daha sıkı Rol Tabanlı Erişim Kontrolü (RBAC) politikaları uygulayabilir.

etcd’de “duran verinin şifrelenmesi” (encryption at rest) mümkündür, ancak bu, varsayılan bir davranış değil, küme yöneticisi tarafından ayrıca yapılandırılması gereken gelişmiş bir güvenlik önlemidir.

Bölüm 5: Durum Bilgili (Stateful) Uygulamalar için Veri Kalıcılığı

Bölüm 2’deki Deployment’lar, Pod’ların geçici ve değiştirilebilir olduğu “durumsuz” (stateless) uygulamalar için mükemmeldir. Ancak bir veritabanı çalıştırıyorsanız, verilerinizin Pod’un yaşam döngüsünden bağımsız olarak kalıcı (persistent) olması gerekir. Bir veritabanı Pod’u çöktüğünde ve yeniden başladığında, verilerine kaldığı yerden devam edebilmelidir.

Kubernetes, bu sorunu PersistentVolume (PV) ve PersistentVolumeClaim (PVC) adı verilen iki aşamalı güçlü bir soyutlama ile çözer.¹⁴

Bu mimari, Bölüm 1’deki cloud-controller-manager ¹ ile aynı felsefeyi paylaşır: Rollerin ve sorumlulukların ayrıştırılması.

1. PersistentVolume (PV):

• Kim: Küme Yöneticisi (Admin).
• Ne: Kümedeki fiziksel bir depolama parçasıdır. Bu, bir NFS paylaşımı, bir hostPath (Düğümün yerel diski) veya bir bulut sağlayıcının diski (örn. AWS EBS) olabilir.¹⁴
• Amaç: Depolamanın nasıl sağlandığını (tedarik) tanımlar. Yönetici, 100GiB’lik hızlı bir SSD diski bir PV olarak oluşturur ve “Available” (Mevcut) duruma getirir.

2. PersistentVolumeClaim (PVC):

• Kim: Geliştirici / Kullanıcı (Pod’u çalıştıran).
• Ne: Bir depolama talebidir.¹⁴
• Amaç: Geliştirici, depolamanın nasıl sağlandığını bilmek zorunda değildir. Sadece ne istediğini (talep) bilir. Geliştirici, “Bana 5Gi’lık, aynı anda tek bir Pod tarafından yazılabilen (ReadWriteOnce) bir depolama lazım” diyen bir PVC oluşturur.

Bağlanma (Binding) Süreci¹⁴:

Bir geliştirici bir PVC oluşturduğunda, Kubernetes kontrol düzlemi (bir kontrolör 1) bu PVC’nin taleplerini (örn. 5Gi, ReadWriteOnce) karşılayabilecek “Available” durumdaki bir PV arar. Uygun bir PV bulunduğunda, bu ikisini birbirine bağlar (bind). Her ikisinin de durumu “Bound” (Bağlı) olur.

Geliştirici, Pod tanımında (örn. bir veritabanı Pod’u) bir birim (volume) olarak doğrudan PV’yi değil, sadece PVC’nin adını referans gösterir.

Bu soyutlama, uygulama tanımlarını (YAML dosyaları) altyapıdan tamamen bağımsız ve taşınabilir hale getirir. Bir geliştiricinin yazdığı veritabanı Pod tanımı, depolamanın AWS’den mi, Google Cloud’dan mı yoksa yerel bir NFS sunucusundan mı geldiğini bilmez; sadece “data-pvc” adlı talebinin karşılanmasını bekler.

Bölüm 6: Küme ile Etkileşim: kubectl Komut Satırı Rehberi

Şimdiye kadar Kubernetes’in temel teorik bileşenlerini (Mimari, İş Yükleri, Ağ, Depolama) inceledik. kubectl, bu bileşenleri yönetmek, oluşturmak, gözlemlemek ve silmek için kullanılan birincil komut satırı arayüzüdür (CLI). kubectl, Bölüm 1’de bahsedilen kube-apiserver ¹ ile konuşarak tüm bu işlemleri gerçekleştirir.

Yeni başlayanlar için kubectl komutları ezberlenmesi gereken rastgele bir liste gibi görünebilir, ancak aslında bir sorunu teşhis etmede kullanılan standart bir triyaj (triage) akışını temsil ederler.

Bir uygulamanın çalışmadığını fark ettiğinizde genellikle şu akışı izlersiniz:

1. Adım 1: Gözlem (get)

• Komut: kubectl get pods ¹⁵
• Amaç: Pod’un genel durumunu (Status) kontrol etmek. “Running” (Çalışıyor) yerine “CrashLoopBackOff” (Sürekli Çöküyor) veya “Error” (Hata) gibi bir durum görüyorsunuz.

2. Adım 2: Küme Düzeyi Teşhis (describe)

• Komut: kubectl describe pod <pod-adi> ¹⁵
• Amaç: get komutunun göstermediği detayları almak. describe komutu, Pod hakkında kapsamlı bilgi ve en önemlisi, en altta bir Events (Olaylar) bölümü gösterir. Kubernetes’in Pod’u neden başlatamadığını burada görürsünüz. Örneğin, ¹⁵‘teki gibi ImagePullBackOff (imaj çekilemedi) veya ErrImagePull (imaj çekme hatası) gibi küme düzeyindeki sorunlar burada ortaya çıkar.

3. Adım 3: Uygulama Düzeyi Teşhis (logs)

• Komut: kubectl logs <pod-adi> ¹⁵
• Amaç: Eğer describe komutu Pod’un başarılı bir şekilde başlatıldığını ancak çalıştıktan sonra çöktüğünü gösteriyorsa (örn. “CrashLoopBackOff”), sorun artık Kubernetes’te değil, konteynerin içindeki uygulamanın kendisindedir. logs komutu, konteynerin standart çıktı (stdout/stderr) loglarını gösterir. “Veritabanı bağlantısı başarısız” veya “Yapılandırma dosyası okunamadı” gibi uygulama-spesifik hataları burada bulursunuz.

Aşağıdaki tablo, bu temel hata ayıklama komutlarını ve en yaygın “eylem” komutlarını özetlemektedir.

Tablo 2: Temel kubectl Komutları ve Kullanım Senaryoları ¹⁵

Komut	İşlevi (Amaç)	Örnek Kullanım
kubectl get	Gözlem (Listeleme): Kaynakların (Pod, Service, Node vb.) mevcut durumunu hızlıca listeler.	kubectl get pods (Tüm Pod’ları listele) kubectl get nodes (Tüm Düğümleri listele) kubectl get services (Tüm Servisleri listele) kubectl get all (Yaygın tüm kaynakları listele)
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 hello-minikube
kubectl apply	Eylem (Bildirimsel): Bir YAML veya JSON dosyasında tanımlanan “istenilen durumu” (desired state) kümeye uygular. Kaynakları oluşturur veya günceller.	kubectl apply -f nginx-pod.yaml
kubectl delete	Eylem (İmha): Bir kaynağı (dosyadan veya ada göre) kümeden kaldırır.	kubectl delete service/hello-minikube kubectl delete -f nginx-pod.yaml
kubectl logs	Hata Ayıklama (Uygulama): Bir Pod içindeki konteynerin standart çıktı (stdout) loglarını gösterir.	kubectl logs hello-minikube

Bölüm 7: Pratik Kılavuz: Minikube ile Yerel Geliştirme

Bu son bölüm, önceki altı bölümdeki tüm teorik kavramları (Mimari, Deployment, Pod, Service, kubectl) bir araya getiren, adım adım ilerleyen pratik bir “Merhaba Dünya” senaryosu sunar.

Minikube, Kubernetes öğrenmek ve yerel geliştirme yapmak için tasarlanmış, tek bir Düğüm üzerinde tam bir Kubernetes kümesini (Kontrol Düzlemi + Çalışan Düğüm bileşenleri) çalıştıran bir araçtır.²

Adım 1: Ön Koşullar ve Kurulum

Minikube’u çalıştırmak için 2+ CPU, en az 2GB boş bellek, 20GB boş disk alanı ve Docker veya benzeri bir konteyner/sanal makine yöneticisine ihtiyacınız vardır.²

Kurulum, işletim sisteminize göre değişiklik gösterir. Örneğin, Linux’ta curl ve install komutları kullanılırken, Windows’ta winget install Kubernetes.minikube komutu kullanılabilir.²

Adım 2: Kümeyi Başlatma

Terminalinizi açın ve aşağıdaki komutu çalıştırın ²:

minikube start

Bu tek komut, arka planda seçtiğiniz sürücüyü (örn. Docker) kullanarak bir konteyner veya VM başlatır. Ardından, Bölüm 1’de ¹ açıklanan tüm Kontrol Düzlemi (API Server, etcd, Scheduler) ve Düğüm (Kubelet, Kube-Proxy) bileşenlerini bu tekil “Düğüm” üzerinde kurar ve çalıştırır.

Adım 3: Küme ile Etkileşim (kubectl)

Minikube kümenizin durumunu kontrol edin. Minikube, kendi kubectl kopyasını içerir, ancak yerel kubectl’inizi de kullanabilirsiniz.²

kubectl get nodes

Çıktı, minikube adında, rolü control-plane olan ve durumu Ready (Hazır) olan tek bir Düğüm göstermelidir.¹⁵ Ayrıca, minikube dashboard ² komutuyla Kubernetes’in web tabanlı arayüzünü açabilirsiniz.

Adım 4: İlk Uygulamayı Dağıtma (Deployment)

Şimdi, Bölüm 2’de ⁴ öğrendiğimiz Deployment kavramını kullanarak basit bir web sunucusu dağıtalım:

kubectl create deployment hello-minikube --image=kicbase/echo-server:1.0

Bu komut, hello-minikube adında bir Deployment kaynağı oluşturur. Deployment kontrolörü ¹ bu talebi görür ve belirtilen imajı kullanan bir Pod ³ oluşturulmasını tetikler.

Adım 5: Uygulamayı Erişime Açma (Service)

Deployment’ımız (ve yönettiği Pod) şu anda çalışıyor, ancak sadece küme içinden (ClusterIP ile) erişilebilir durumda. Uygulamayı dışarıdan erişilebilir hale getirmek için Bölüm 3’te ⁶ öğrendiğimiz NodePort tipinde bir Service oluşturalım ²:

kubectl expose deployment hello-minikube --type=NodePort --port=8080


Bu komut, hello-minikube Deployment’ı tarafından yönetilen Pod’lara (varsayılan olarak 8080 portuna) trafiği yönlendirecek bir NodePort Servisi oluşturur.

Adım 6: Uygulamaya Erişme

Servis’inize erişmenin en kolay yolu, Minikube’un sizin için doğru portu ve IP’yi bulup tarayıcınızda açmasını sağlamaktır ²:

minikube service hello-minikube


Bu komut tarayıcınızı açacak ve çalışan echo-server uygulamasından bir yanıt göreceksiniz. Alternatif olarak, kubectl port-forward ² kullanarak servisi localhost’unuza da yönlendirebilirsiniz.

Sonuç

Bu kılavuz, Kubernetes öğrenme yolculuğunuzda temel bir temel oluşturmak için yedi ana başlığı ele aldı:

1. Mimari: Kontrol Düzlemi (Beyin) ve Çalışan Düğümlerin (Kas Gücü) nasıl organize olduğu.¹
2. İş Yükleri: Uygulamaların en küçük birimi olan Pod’lar ³ ve onların yaşam döngüsünü yöneten Deployment’lar.⁴
3. Ağ Mimarisi: Service kullanarak geçici Pod’lara kararlı adresler sağlama ⁵ ve ClusterIP, NodePort, LoadBalancer ⁶ arasındaki farklar.
4. Yapılandırma: Kodu yapılandırmadan ayırmak için ConfigMap ⁹ ve Secret ¹² kullanımı.
5. Veri Kalıcılığı: PV (tedarik) ve PVC (talep) ¹⁴ soyutlamasıyla durum bilgili (stateful) uygulamaları destekleme.
6. kubectl Rehberi: get, describe, logs ¹⁵ gibi komutlarla standart bir hata ayıklama akışı.
7. Pratik Kılavuz: Minikube ² ile tüm bu teorik kavramları bir araya getiren pratik bir uygulama.

Bu kılavuz, Kubernetes’in geniş ekosistemine bir “giriş seviyesi” bakışı sunmaktadır. Bu temeller üzerine inşa edeceğiniz bir sonraki adımlar, StatefulSet’ler (veritabanları gibi durum bilgili uygulamalar için gelişmiş bir Deployment) ¹⁷, Ingress (Servisleri dış dünyaya açmanın daha gelişmiş bir yolu) ve RBAC (küme içi güvenlik ve yetkilendirme) ¹⁷ gibi daha karmaşık konuları içerecektir.

Alıntı Kaynakları

1. Cluster Architecture | Kubernetes, erişim tarihi Kasım 15, 2025, https://kubernetes.io/docs/concepts/architecture/
2. minikube start | minikube, erişim tarihi Kasım 15, 2025, https://minikube.sigs.k8s.io/docs/start/
3. Pods | Kubernetes, erişim tarihi Kasım 15, 2025, https://kubernetes.io/docs/concepts/workloads/pods/
4. Deployments | Kubernetes, erişim tarihi Kasım 15, 2025, https://kubernetes.io/docs/concepts/workloads/controllers/deployment/
5. Service | Kubernetes, erişim tarihi Kasım 15, 2025, https://kubernetes.io/docs/concepts/services-networking/service/
6. Kubernetes Service – What It is, Types & Examples – Spacelift, erişim tarihi Kasım 15, 2025, https://spacelift.io/blog/kubernetes-service
7. What is a Service in Kubernetes?, erişim tarihi Kasım 15, 2025, https://medium.com/@haroldfinch01/what-is-a-service-in-kubernetes-7262ed127105
8. ClusterIP, NodePort, and LoadBalancer: Kubernetes Service Types …, erişim tarihi Kasım 15, 2025, https://www.baeldung.com/ops/kubernetes-service-types
9. ConfigMaps | Kubernetes, erişim tarihi Kasım 15, 2025, https://kubernetes.io/docs/concepts/configuration/configmap/
10. Configure a Pod to Use a ConfigMap – Kubernetes, erişim tarihi Kasım 15, 2025, https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/
11. Kubernetes ConfigMap ve Secret Nedir? – Kerteriz Blog, erişim tarihi Kasım 15, 2025, https://kerteriz.net/kubernetes-configmap-ve-secret-nedir/
12. Secrets | Kubernetes, erişim tarihi Kasım 15, 2025, https://kubernetes.io/docs/concepts/configuration/secret/
13. Managing Secrets using Configuration File – Kubernetes, erişim tarihi Kasım 15, 2025, https://kubernetes.io/docs/tasks/configmap-secret/managing-secret-using-config-file/
14. Persistent Volumes | Kubernetes, erişim tarihi Kasım 15, 2025, https://kubernetes.io/docs/concepts/storage/persistent-volumes/
15. Kubernetes Uygulamalı Rehberi: Minikube ve Kubectl ile İlk Adımlar …, erişim tarihi Kasım 15, 2025, https://medium.com/@mmehmetisik/kubernetes-uygulamal%C4%B1-rehberi-minikube-ve-kubectl-ile-i%CC%87lk-ad%C4%B1mlar-fa65aaf156e0
16. kubectl Quick Reference | Kubernetes, erişim tarihi Kasım 15, 2025, https://kubernetes.io/docs/reference/kubectl/quick-reference/
17. Every Kubernetes Object Explained in Just 5 minutes!, erişim tarihi Kasım 15, 2025, https://www.youtube.com/watch?v=WguJCFc5oyc