Kubernetes Nedir – Başlangıç Rehberi

Docker ile bir uygulamayı konteynere koyup tek bir sunucuda çalıştırmayı öğrendiğinizde ortaya yeni bir soru çıkar: peki ya bu uygulamayı on farklı sunucuda, aynı anda düzinelerce kopyayla, biri çökünce diğeri devreye girecek şekilde çalıştırmanız gerekirse? Tek başına Docker bu noktada yetersiz kalır. İşte Kubernetes tam olarak bu boşluğu doldurmak için doğdu. Kubernetes (kısaca "k8s"), çok sayıda konteyneri bir sunucu kümesi üzerinde otomatik olarak dağıtan, ölçekleyen, izleyen ve kendini onaran bir konteyner orkestrasyon sistemidir.

Bu rehberde Kubernetes'i sıfırdan, gösterişli terimlere boğulmadan anlatacağız. Önce orkestrasyonun neden gerekli olduğunu, ardından pod, deployment, service ve namespace gibi temel yapı taşlarını örneklerle göreceğiz. Sonra ölçekleme ve kendini iyileştirme mekaniğine, Docker ile Kubernetes'in gerçekte nasıl bir ilişkisi olduğuna değinecek ve en dürüst soruyu yanıtlayacağız: küçük bir proje için Kubernetes gerçekten gerekli mi, yoksa çoğu zaman fazla mı kaçar? Konteyner mantığına yeniyseniz önce Docker başlangıç rehberimizi okumanızı öneririz; bu yazı onun bittiği yerden başlar.

Orkestrasyon Problemi: Neden Sadece Docker Yetmiyor#

Docker, tek bir uygulamayı tek bir makinede çalıştırmak için mükemmeldir. docker run yazarsınız, konteyner ayağa kalkar, iş biter. Sorun, uygulamanız büyümeye başladığında ortaya çıkar. Diyelim ki e-ticaret siteniz kara cuma trafiğine hazırlanıyor ve tek konteyner yükü kaldıramıyor. Yapmanız gereken şey aynı uygulamanın on kopyasını çalıştırmak. Peki bu on kopya hangi sunuculara dağılacak? Biri gecenin ortasında çökerse yerine yenisini kim başlatacak? Gelen trafik bu on kopyaya nasıl eşit dağıtılacak? Yeni bir sürüm yayınlarken siteyi hiç kesintiye uğratmadan güncellemeyi kim yönetecek?

Bu soruların her birini elle yanıtlamaya kalkarsanız, kısa sürede bir sürü kabuk betiği, cron görevi ve "umarım çökmez" diye dua ettiğiniz kırılgan bir yapıyla baş başa kalırsınız. Orkestrasyon dediğimiz şey tam olarak budur: konteynerlerin hangi sunucuda, kaç kopya halinde, nasıl bir ağ üzerinden ve hangi koşullarda yeniden başlatılarak çalışacağını bir sisteme devretmek.

Kubernetes'in yaklaşımı bildiğimiz betik yazma alışkanlığından temelde farklıdır. Ona "şu konteyneri başlat, sonra şunu yap" gibi adım adım komutlar vermezsiniz. Bunun yerine istenen son durumu tarif edersiniz: "Bu uygulamadan her zaman üç kopya ayakta olsun, şu portu dinlesin, şu kadar bellek kullansın." Kubernetes bu tarifi alır ve gerçekliği sürekli bu tarife yaklaştırmaya çalışır. Buna deklaratif model denir. Bir kopya çökerse Kubernetes farkı görür ("üç istemiştim, iki var") ve eksiği kendiliğinden tamamlar. Bu, bir sistem yöneticisinin gece uykusunu kurtaran en önemli fikirdir.

Küme Mimarisi: Control Plane ve Node'lar#

Kubernetes bir tek makine değil, birlikte çalışan sunuculardan oluşan bir küme (cluster) üzerinde çalışır. Bu kümedeki sunucular iki role ayrılır. Birincisi, kümenin beynini oluşturan control plane (kontrol düzlemi). İkincisi, uygulamalarınızın gerçekten çalıştığı worker node'lar (işçi düğümleri).

Control plane, kümenin "yönetici" katmanıdır. İçinde birkaç önemli bileşen barınır: tüm isteklerin geçtiği API sunucusu, kümenin tüm durumunu saklayan etcd adında bir anahtar-değer veritabanı, yeni konteynerleri hangi node'a yerleştireceğine karar veren scheduler ve istenen durumla gerçek durumu karşılaştırıp fark kapatan controller-manager. Siz Kubernetes'e bir komut gönderdiğinizde aslında API sunucusuyla konuşursunuz; gerisini bu bileşenler halleder.

Worker node'lar ise asıl işi yapan makinelerdir. Her node üzerinde kubelet adında bir ajan çalışır; bu ajan control plane'den "şu konteyneri çalıştır" talimatını alır ve node üzerindeki konteyner çalışma zamanına (containerd gibi) ileterek konteyneri başlatır. Node'lar tek bir VDS sunucu olabileceği gibi, onlarca fiziksel makineden de oluşabilir. Kubernetes'in güzelliği, siz "üç kopya çalışsın" dediğinizde bu kopyaların hangi node'a düştüğünü umursamak zorunda kalmamanızdır; scheduler en uygun yerleştirmeyi kendisi bulur.

Kubernetes'in Temel Nesneleri#

Kubernetes'te her şeyi birer "nesne" olarak tanımlarsınız ve bu nesneleri genellikle YAML dosyalarıyla tarif edersiniz. Başlangıç için dört nesneyi anlamanız yeterli: pod, deployment, service ve namespace.

Pod#

Pod, Kubernetes'in çalıştırdığı en küçük birimdir. İlk sürpriz şudur: Kubernetes konteynerleri doğrudan çalıştırmaz, onları bir pod'un içine koyar. Çoğu zaman bir pod'da tek bir konteyner bulunur, ama bazı özel durumlarda birbirine sıkı sıkıya bağlı birkaç konteyner aynı pod'u paylaşabilir (örneğin bir uygulama ile onun günlüklerini toplayan yardımcı bir konteyner). Aynı pod'daki konteynerler aynı ağ adresini ve depolama alanını paylaşır.

Pod'lar hakkında bilmeniz gereken en kritik şey geçici (ephemeral) olmalarıdır. Bir pod ölürse geri gelmez; yerine yepyeni bir pod, yeni bir kimlikle oluşturulur. Bu yüzden pod'ları asla elle tek tek oluşturup onlara güvenmezsiniz. Pod'ları doğrudan yönetmek yerine, birazdan göreceğimiz deployment gibi üst seviye nesnelere bırakırsınız.

Deployment#

Deployment, pod'ları sizin adınıza yöneten nesnedir ve günlük hayatta en çok kullanacağınız yapıdır. Ona "bu imajdan üç kopya (replica) istiyorum" dersiniz; deployment bu üç pod'un her zaman ayakta olmasını garanti eder. Biri çökerse yenisini oluşturur, bir node kapanırsa pod'ları sağlam node'lara taşır.

Deployment'ın en değerli özelliği kademeli güncellemedir (rolling update). Uygulamanızın yeni sürümünü yayınlamak istediğinizde imaj etiketini değiştirirsiniz; Kubernetes eski pod'ları birer birer kapatıp yenilerini açar. Böylece kullanıcılar hiç kesinti yaşamaz. Bir sorun çıkarsa kubectl rollout undo ile tek komutla eski sürüme geri dönebilirsiniz.

Service#

Pod'lar geçici olduğu ve her yeniden oluşturulduğunda IP adresleri değiştiği için, onlara sabit bir adresle ulaşmak gerekir. İşte Service bu sorunu çözer. Service, arkasındaki pod grubuna sabit bir dahili ad ve IP verir; gelen isteği bu pod'lara otomatik olarak dağıtır (yük dengeleme). Yani frontend uygulamanız backend'e "backend adlı service" üzerinden ulaşır, arka planda kaç pod olduğunu veya IP'lerinin ne olduğunu hiç bilmesine gerek kalmaz.

Service'in birkaç türü vardır. ClusterIP yalnızca küme içinden erişilebilen dahili bir adres verir (varsayılan). NodePort her node üzerinde belirli bir portu dışarı açar. LoadBalancer ise bulut sağlayıcının yük dengeleyicisiyle entegre olarak dış dünyaya açık bir adres sunar. Dışarıya HTTP/HTTPS trafiği açmak için genellikle bir de Ingress katmanı kullanılır; bu, tıpkı bir Nginx ters proxy gibi gelen alan adlarını doğru service'lere yönlendirir.

Namespace#

Namespace, bir kümeyi mantıksal bölmelere ayırmanıza yarar. Aynı küme içinde uretim, test ve gelistirme diye ayrı namespace'ler oluşturabilir, her birine ayrı kaynak limitleri ve erişim yetkileri tanımlayabilirsiniz. Küçük projelerde tek namespace (default) yeterlidir; ama birden fazla ekip ya da ortam aynı kümeyi paylaştığında namespace'ler karmaşayı önler.

Basit Bir Örnek: Deployment ve Service#

Teoriyi somuta indirmek için basit bir web uygulamasını Kubernetes'te çalıştıralım. Aşağıdaki YAML dosyası, üç kopya Nginx çalıştıran bir deployment tanımlar:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-uygulama
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: nginx
          image: nginx:1.27-alpine
          ports:
            - containerPort: 80
          resources:
            requests:
              memory: "64Mi"
              cpu: "50m"
            limits:
              memory: "128Mi"
              cpu: "250m"

Burada replicas: 3 ile üç kopya istediğimizi, selector ve labels ile hangi pod'ların bu deployment'a ait olduğunu, resources ile de her pod'un ne kadar bellek ve işlemci kullanabileceğini belirtiyoruz. Bu limitler önemlidir: onlar olmadan tek bir hatalı pod, node'un tüm belleğini yiyip diğer uygulamaları çökertebilir.

Şimdi bu üç pod'a sabit bir adresle ulaşmak için bir service tanımlayalım:

apiVersion: v1
kind: Service
metadata:
  name: web-service
spec:
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 80
  type: ClusterIP

Service, selector: app: web sayesinde yukarıdaki deployment'ın ürettiği pod'ları otomatik bulur ve gelen 80 portu trafiğini bu üç pod'a dağıtır. Bu iki dosyayı kümeye uygulamak için kubectl komut satırı aracını kullanırsınız:

# Nesneleri kümeye uygula
kubectl apply -f deployment.yaml
kubectl apply -f service.yaml

# Çalışan pod'ları listele
kubectl get pods

# Deployment'ın durumunu gör
kubectl get deployment web-uygulama

# Bir pod'un günlüklerini oku
kubectl logs <pod-adi>

kubectl get pods çıktısında üç pod'un Running durumunda olduğunu görürsünüz. Şimdi ilginç kısım: bir pod'u elle silin (kubectl delete pod <pod-adi>) ve tekrar listeleyin. Kubernetes eksik kopyayı saniyeler içinde yeniden oluşturmuş olacak, çünkü deployment "her zaman üç tane olsun" talimatını sürdürür. İşte deklaratif modelin gücü budur.

Ölçekleme ve Kendini İyileştirme#

Kubernetes'i cazip kılan iki yetenek ölçekleme ve kendini iyileştirmedir. İkisi de aynı temel fikirden, yani "gerçek durumu istenen duruma yaklaştırma" prensibinden doğar.

Ölçekleme en basit haliyle replica sayısını değiştirmektir. Trafiğin arttığını fark ettiğinizde tek komutla kopya sayısını yükseltirsiniz:

kubectl scale deployment web-uygulama --replicas=10

Bu komuttan sonra Kubernetes yedi yeni pod'u uygun node'lara yerleştirir ve service otomatik olarak yeni pod'ları da yük dağıtımına katar. Daha da ileri gidip ölçeklemeyi otomatikleştirebilirsiniz. Horizontal Pod Autoscaler (HPA), CPU veya bellek kullanımını izleyerek kopya sayısını kendiliğinden artırıp azaltır. Örneğin ortalama CPU kullanımı yüzde 70'i geçtiğinde otomatik yeni pod açması, gece trafiği düşünce kopyaları azaltması için yapılandırabilirsiniz. Bu, kara cuma gibi ani yük dalgalarında elle müdahale gerektirmeden ölçeklenmenizi sağlar.

Kendini iyileştirme (self-healing) ise Kubernetes'in sessiz kahramanıdır. Sistem, tanımladığınız istenen durumu sürekli izler ve şu üç durumu otomatik ele alır: Bir pod çökerse yeniden başlatır. Bir node tamamen kapanırsa, o node'daki pod'ları başka sağlam node'lara taşır. Bir konteyner sağlıksız hale gelirse (ölmemiş ama takılmış), onu yeniden başlatır. Bu son senaryo için liveness ve readiness kontrolleri tanımlarsınız: Kubernetes belirli aralıklarla konteynerinize "yaşıyor musun?" ve "istek almaya hazır mısın?" diye sorar. Cevap gelmezse müdahale eder.

livenessProbe:
  httpGet:
    path: /saglik
    port: 80
  initialDelaySeconds: 10
  periodSeconds: 15

Bu yetenekler, gecenin üçünde çalan bir alarmla uyanıp elle sunucu yeniden başlatma çağını sona erdirir. Yine de "Kubernetes her şeyi halleder" yanılgısına düşmeyin: yanlış yapılandırılmış bir sağlık kontrolü veya eksik kaynak limiti, kendini iyileştirmeyi bir sonsuz yeniden başlatma döngüsüne çevirebilir. Bu yüzden düzenli yedekleme ve izleme her zaman gereklidir.

Docker ile Kubernetes İlişkisi#

Yeni başlayanların en çok karıştırdığı konu budur: "Kubernetes, Docker'ın yerini mi alıyor?" Kısa yanıt: hayır, ikisi rakip değil, tamamlayıcıdır. Aralarındaki farkı şöyle özetleyebiliriz.

Docker bir uygulamayı imaj haline getirir ve tek makinede çalıştırır. Kubernetes ise bu imajları alıp bir küme üzerinde dağıtır, ölçekler ve yönetir. Yani genellikle önce Docker ile imajınızı üretir (docker build), onu bir kayıt deposuna (registry) gönderir, sonra Kubernetes'e "bu imajdan şu kadar kopya çalıştır" dersiniz. Kubernetes YAML dosyalarındaki image: nginx:1.27-alpine satırı, tam olarak Docker imajlarına referans verir.

Bir teknik ayrıntı da netleştirelim: Kubernetes uzun süre konteynerleri çalıştırmak için Docker'ın çalışma zamanını kullandı, ama 2022'de bu bağımlılık kaldırıldı ve yerini containerd ve CRI-O gibi daha yalın çalışma zamanları aldı. Bu değişiklik "Docker öldü" başlıklarına yol açtı ama uygulamada sizin için değişen bir şey yok: Docker ile ürettiğiniz imajlar standart bir formatta (OCI) olduğu için Kubernetes'te sorunsuz çalışmaya devam eder. Docker'ı imaj üretmek için kullanmayı sürdürürsünüz; Kubernetes de bu imajları containerd ile çalıştırır. Kısacası Docker'ı öğrenmeden Kubernetes'e geçmek, yürümeyi öğrenmeden koşmaya çalışmak gibidir.

Küçük Bir Projeye Kubernetes Gerçekten Gerekli mi?#

Şimdi dürüst konuşalım, çünkü bu bölüm sizi çok zaman ve paradan kurtarabilir. Kubernetes muhteşem bir teknolojidir, ama çoğu proje için gereğinden fazladır. Sektörde "her şeyi Kubernetes'e taşıma" modası yüzünden, tek bir WordPress sitesi ya da küçük bir API için koca bir küme kuran ve sonra bakım yükü altında ezilen birçok ekip gördüm.

Şu durumlarda Kubernetes muhtemelen gereksiz karmaşıklıktır:

• Tek bir web siteniz veya bloğunuz var; bir hosting paketi ya da tek bir VDS sunucu fazlasıyla yeter.
• Uygulamanız tek sunucuya rahatça sığıyor ve trafik dalgalanması yaşamıyorsunuz.
• Ekipte konteyner ve Linux deneyimi sınırlı; Kubernetes'in öğrenme eğrisi işi yavaşlatır.
• Küçük bir ekip veya tek kişisiniz; kümenin kendi bakımı, güncellemesi ve güvenliği başlı başına bir iştir.

Şu durumlarda ise Kubernetes gerçekten değer katar:

• Onlarca mikroservisiniz var ve bunları bağımsız ölçeklemek istiyorsunuz.
• Trafiğiniz gün içinde ciddi biçimde dalgalanıyor ve otomatik ölçekleme size para kazandırıyor.
• Kesintisiz çalışma (yüksek erişilebilirlik) kritik ve bir sunucu çöktüğünde otomatik devralma şart.
• CI/CD hattınız olgun ve günde birçok kez, sıfır kesintiyle dağıtım yapıyorsunuz.

Aradaki tatlı nokta ise hafif Kubernetes dağıtımlarıdır. Kubernetes'in tam sürümü kaynak açlığı çeker ve kurulumu karmaşıktır; ama öğrenmek ya da küçük ölçekli üretim için tasarlanmış hafif alternatifler vardır. Bunların en popüleri k3s'tir: tam uyumlu, tek ikili dosyayla gelen, gereksiz bileşenleri çıkarılmış bir Kubernetes dağıtımıdır. Tek bir VDS sunucu üzerine dakikalar içinde kurabilirsiniz:

# k3s'i tek komutla kur
curl -sfL https://get.k3s.io | sh -

# Kümenin çalıştığını doğrula
sudo k3s kubectl get nodes

k3s, Kubernetes kavramlarını (pod, deployment, service, kubectl) birebir aynı şekilde öğrenmenizi sağlar ama tek bir küçük sunucuda bile rahatça döner. Kubernetes'i merak ediyorsanız ama devasa bir bulut faturasıyla başlamak istemiyorsanız, öğrenme yolculuğunuza k3s ile başlamak en akıllıca seçimdir. Kendi sunucunuzda hazır açık kaynak uygulamaları denemek isterseniz App Center çözümlerimize de göz atabilirsiniz.

Sıkça Sorulan Sorular#

Kubernetes ile Docker aynı şey mi?#

Hayır, ikisi farklı katmanlarda çalışan tamamlayıcı araçlardır. Docker konteyner imajları oluşturup tek bir makinede çalıştırmaya odaklanır. Kubernetes ise bu imajları bir sunucu kümesi üzerinde dağıtan, ölçekleyen ve yöneten bir orkestrasyon sistemidir. Genellikle imajı Docker ile üretir, dağıtımını Kubernetes ile yaparsınız.

Kubernetes öğrenmek için önce Docker bilmem gerekir mi?#

Kesinlikle evet demek doğru olur. Kubernetes'in çalıştırdığı her şey konteynerdir ve konteyner mantığını, imaj kavramını, port ve volume yönetimini Docker üzerinden öğrenmek çok daha kolaydır. Docker temellerini atmadan Kubernetes'e başlamak, çoğu kavramın havada kalmasına neden olur. Önce Docker, sonra Kubernetes en sağlıklı sıralamadır.

Pod ile konteyner arasındaki fark nedir?#

Konteyner, çalışan tek bir uygulama örneğidir; pod ise Kubernetes'in çalıştırdığı en küçük birimdir ve içinde bir veya birkaç konteyner barındırır. Çoğu zaman bir pod'da tek konteyner bulunur. Aynı pod'daki konteynerler ağ adresini ve depolamayı paylaşır. Kubernetes konteynerleri doğrudan değil, hep bir pod içinde çalıştırır.

Kubernetes küçük bir web sitesi için gerekli mi?#

Genellikle hayır. Tek bir web sitesi ya da bloğu çalıştırmak için Kubernetes fazlasıyla karmaşık kalır; kümenin bakımı, güncellemesi ve güvenliği başlı başına yük getirir. Bu tür projeler için bir hosting paketi veya tek bir VDS sunucu daha az bakımla iş görür. Kubernetes asıl değerini çok sayıda servis, otomatik ölçekleme ve yüksek erişilebilirlik gerektiren projelerde gösterir.

Kubernetes'i öğrenmeye tek sunucuda başlayabilir miyim?#

Evet, hem de bu en pratik yoldur. k3s veya minikube gibi hafif dağıtımlar tek bir sunucuya (hatta kişisel bilgisayarınıza) dakikalar içinde kurulur ve tüm temel kavramları gerçek Kubernetes'le birebir aynı şekilde öğrenmenizi sağlar. Böylece pahalı çok sunuculu bir kümeye ihtiyaç duymadan pod, deployment ve service'lerle pratik yapabilirsiniz.

kubectl nedir ve ne işe yarar?#

kubectl, Kubernetes kümesiyle konuşmak için kullandığınız komut satırı aracıdır. YAML dosyalarını kümeye uygulamak (kubectl apply), çalışan nesneleri listelemek (kubectl get), günlükleri okumak (kubectl logs) ve replica sayısını değiştirmek (kubectl scale) gibi neredeyse tüm işlemleri onunla yaparsınız. Arka planda control plane'in API sunucusuyla iletişim kurar.

Kapanış#

Kubernetes, tek başına Docker'ın çözemediği "çok sayıda konteyneri, çok sayıda sunucuda, kesintisiz ve otomatik yönet" problemini çözen güçlü bir orkestrasyon sistemidir. Pod, deployment, service ve namespace gibi birkaç temel kavramı ve deklaratif modeli kavradığınızda, kendini iyileştirme ve otomatik ölçekleme gibi yeteneklerin neden bu kadar değerli olduğunu görürsünüz. Ama en önemli ders şu: Kubernetes her problem için değil, ölçek ve karmaşıklık gerçekten arttığında doğru araçtır; küçük projeler için k3s gibi hafif bir başlangıç çoğu zaman daha akıllıcadır.

Öğrendiklerinizi denemek için ihtiyacınız olan tek şey root erişimine sahip kendi sunucunuzdur. k3s ile ilk kümenizi kurup pod ve deployment'larla pratik yapmak için VDS sunucu çözümlerimize göz atabilir, ölçeklenen uygulamalarınızı yönetmek için sunucu yönetimi hizmetimizi değerlendirebilir, üzerine taşıyacağınız verilerin güvenliği için de yedekleme seçeneklerini gözden geçirebilirsiniz. Konteyner temellerini pekiştirmek isterseniz Docker başlangıç rehberi her zaman iyi bir dönüş noktasıdır.