Bulut & Altyapı

Yeni başlayanlar için Kubernetes: hangi sorunu çözer

Kubernetes'e ihtiyacınız var mı? Bu rehberde Pod, Service ve Deployment kavramlarını basitçe öğrenin ve bu karmaşık aracın projeniz için ne zaman uygun olmadığını anlayın.

Bulut & Altyapı

Kubernetes Nedir ve Neden Bu Kadar Çok Duyuyoruz?

Birkaç yıldır yazılım geliştirme ve altyapı dünyasında çalışıyorsanız, mutlaka Kubernetes adını duymuşsunuzdur. Birçok kişi ona "bulut işletim sistemi" der ve diğerleri sadece konteynerleri yönetmek için bir araç olduğunu bilir. Ama asıl soru şu: Kubernetes tam olarak hangi sorunu çözüyor?

Kısa cevap şudur: Kubernetes, konteynerli uygulamaların büyük ölçekte otomatik yönetimi sorununu çözer. Birkaç Docker konteyneriniz olduğunda, bunları çalıştırmak basittir. Ancak birbiriyle iletişim kurması gereken, birinin arızasını telafi etmesi gereken ve trafik yoğunluğu zamanlarında ölçeklenmesi gereken onlarca veya yüzlerce konteyneriniz olduğunda, manuel yönetim imkansız hale gelir. İşte Kubernetes tam olarak burada devreye girer.

Bu makalede, basit bir dille ve pratik örneklerle Kubernetes'in ana kavramlarını, yani Pod, Service ve Deployment'ı inceleyeceğiz ve sonunda gerçekten Kubernetes'e ihtiyacınız olup olmadığı sorusuna cevap vereceğiz.

Ana Sorun: Konteynerler Tek Başına Yeterli Değil

Docker ile basit bir e-ticaret web sitesi kurduğunuzu varsayalım. Nginx web sunucusu için bir konteyner, Node.js uygulaması için bir tane ve MySQL için bir tane. Site trafiği artana kadar her şey iyi çalışıyor. Şimdi ne yapmalısınız?

Manuel olarak şunları yapmanız gerekir:

  • Uygulama konteynerinin yeni bir örneğini çalıştırın.
  • Nginx ayarlarını değiştirerek trafiği iki örnek arasında bölün.
  • Her iki örneğin de aynı veritabanına bağlandığından emin olun.
  • Örneklerden biri çökerse, bunu fark edin ve yeniden çalıştırın.

Bu işlem küçük ölçekte mümkündür, ancak hizmet sayısı 10 veya 20'ye ulaştığında pratik olarak yönetilemez hale gelir. Kubernetes bu süreci otomatikleştirir: siz "Bu uygulamanın 3 örneğini istiyorum" dersiniz ve Kubernetes geri kalanını kendisi yapar.

Temel Kavramlar: Pod Nedir?

Pod, Kubernetes'teki en küçük yürütme birimidir. Yaygın inanışın aksine, Pod bir konteynere eşdeğer değildir; Pod, ortak kaynaklara sahip bir veya daha fazla konteyner içerebilir. Pratikte, çoğu zaman her Pod'un yalnızca bir ana konteyneri vardır.

Bir Pod tanımına basit bir örnek:

apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
  - name: app
    image: nginx:latest
    ports:
    - containerPort: 80

Bu YAML dosyası, Nginx imajını kullanan my-app adında bir Pod tanımlar. Ancak önemli olan nokta, Pod'ların genellikle doğrudan oluşturulmamasıdır. Neden? Çünkü bir Pod çökerse, Kubernetes onu otomatik olarak geri getirmez. Pod'ların yaşam döngüsünü yönetmek için Deployment'a ihtiyacınız vardır.

Deployment: Pod'ların Gerçek Yöneticisi

Deployment, uygulamanızın istenen durumunu tanımlayan bir Kubernetes kaynağıdır. Siz "Bu uygulamanın 3 kopyasını istiyorum" dersiniz ve Deployment, Pod'ları oluşturmaktan, güncellemekten ve onarmaktan sorumludur.

Deployment örneği:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: app
        image: myapp:v1.2
        ports:
        - containerPort: 8080

Bu tanımla Kubernetes, app: my-app etiketine sahip 3 Pod'u her zaman aktif tutar. Pod'lardan biri çökerse, Deployment otomatik olarak yeni bir Pod oluşturur. Uygulamanızın yeni bir sürümünü yayınlamak isterseniz, Deployment'daki imajı değiştirmeniz yeterlidir ve Kubernetes kademeli olarak (Rolling Update) eski Pod'ları yenileriyle değiştirir.

Service: Değişken Pod'lar için Sabit Adres

Kubernetes'teki Pod'lar geçicidir. Her an bir Pod silinebilir ve farklı bir IP'ye sahip yeni bir Pod ile değiştirilebilir. Uygulamanız başka bir hizmetle iletişim kurmak istiyorsa, belirli bir Pod'un IP'sine bağımlı olamaz. Service'in rolü burada ortaya çıkar.

Service, bir Deployment'daki Pod'lar arasında trafiği dağıtan sabit bir adres (genellikle dahili bir DNS adı) sağlar. Örnek:

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

Bu tanımla diğer hizmetler, Pod'ların IP'leri hakkında endişelenmeden my-app-service adıyla uygulamanıza erişebilir. ClusterIP türü, hizmetin yalnızca küme içinden erişilebilir olduğu anlamına gelir. Hizmetin dışarıdan erişilebilir olmasını istiyorsanız, NodePort veya LoadBalancer kullanırsınız.

Kubernetes Ne Zaman Fazladır?

Artık ana kavramlara aşina olduğunuza göre, şu soruya dürüstçe cevap vermeliyiz: Projeniz gerçekten Kubernetes'e ihtiyaç duyuyor mu? Çoğu durumda cevap "hayır"dır.

Kubernetes güçlü bir araçtır, ancak gizli maliyetleri vardır:

  • Operasyonel karmaşıklık: Bir Kubernetes kümesi kurmak ve bakımını yapmak, ağ, güvenlik ve kaynak yönetimi konusunda derin bilgi gerektirir.
  • Donanım kaynakları: Kubernetes'in kendisi kontrol bileşenleri (Control Plane) için önemli kaynaklara ihtiyaç duyar. Küçük bir proje için bu kaynaklar boşa harcanır.
  • Öğrenme eğrisi: Ingress, ConfigMap, Secret ve RBAC gibi kavramları öğrenmek zaman alır.

Henüz Kubernetes'e İhtiyacınız Olmadığını Gösteren İşaretler

Aşağıdaki durumlara sahipseniz, Kubernetes muhtemelen sizin için fazladır:

  • Uygulamanız yalnızca bir veya iki hizmete sahip.
  • Trafiğiniz öngörülebilir ve keskin dalgalanmalar yok.
  • Ekibiniz yalnızca bir veya iki kişiden oluşuyor ve yeni araçlar öğrenmek için yeterli zaman yok.
  • Programınız stateful (örneğin veritabanı) ve yerel depolamaya bağımlı.

Bu durumlarda, geliştirme ortamı için Docker Compose ve üretim için basit bir VPS veya bulut hizmeti gibi daha basit çözümler tamamen yeterlidir. Hatta çok daha az karmaşıklığa sahip Docker Swarm gibi yönetilen hizmetleri de kullanabilirsiniz.

Kubernetes'e Ne Zaman Geçmelisiniz?

Kubernetes'i şu durumlarda düşünmelisiniz:

  • Hizmet sayınız 5-10'u aştı ve manuel yönetim zorlaştı.
  • Trafiğe göre otomatik ölçeklendirme ihtiyacınız var.
  • Yeni sürümleri hizmet kesintisi olmadan yayınlamak istiyorsunuz.
  • Ekibiniz, bir kişinin altyapıya odaklanabileceği kadar büyük.

Bu aşamada Kubernetes'e geçiş mantıklıdır. Ancak tavsiyem, önce yerel sisteminizde küçük bir kümeyle (örneğin Minikube veya kind ile) pratik yapmanız ve ardından gerçek bir küme kurmaya geçmenizdir.

Kubernetes'e Başlarken Yapılan Yaygın Hatalar

Kubernetes ile geçirdiğim yıllar boyunca, yeni başlayan ekiplerin sıklıkla yaptığı birkaç yaygın hatayı defalarca gördüm:

Birinci Hata: İmaj Etiketi için latest Kullanmak

Deployment'da image: nginx:latest kullanmak klasik bir hatadır. Sorun şu ki, Kubernetes yeni bir Pod oluşturduğunda, önceki sürümle uyumlu olmayan daha yeni bir imaj sürümünü çekebilir. Her zaman nginx:1.25.3 gibi belirli etiketler kullanın.

İkinci Hata: Resource Limits'i Göz Ardı Etmek

Pod'lar için kaynak sınırları (CPU ve Memory) belirlemezseniz, bir Pod düğümün tüm kaynaklarını tüketebilir ve diğer Pod'ları çalışamaz hale getirebilir. Her zaman resources.requests ve resources.limits tanımlayın:

resources:
  requests:
    memory: "256Mi"
    cpu: "250m"
  limits:
    memory: "512Mi"
    cpu: "500m"

Üçüncü Hata: Hassas Bilgileri ConfigMap'te Saklamak

ConfigMap, hassas olmayan ayarlar içindir. Parolalar ve API anahtarları için Secret kullanmalısınız. ConfigMap'ler düz metin olarak saklanır ve kümeye erişimi olan herkes bunları okuyabilir.

Sorun Giderme İpuçları: Pod'unuz Pending Durumunda Kaldığında

Yeni başlayanların karşılaştığı en yaygın sorunlardan biri, sonsuza kadar Pending durumunda kalan Pod'lardır. Bu genellikle Kubernetes'in Pod'u çalıştırmak için yeterli kaynak bulamadığı anlamına gelir. Kontrol etmek için:

kubectl describe pod my-app-pod

Bu komutun çıktısında Events bölümünü inceleyin. 0/3 nodes are available: insufficient cpu gibi bir mesaj görürseniz, düğüm kaynaklarını artırmanız veya Pod sınırlarını azaltmanız gerekir.

Bir diğer yaygın sorun, Pod'ların CrashLoopBackOff durumunda olmasıdır. Bu, Pod'un başlamaya çalıştığı ancak hemen çöktüğü anlamına gelir. Günlükleri görmek için:

kubectl logs my-app-pod --previous

Bu komut, Pod'un önceki çalıştırmasının günlüklerini gösterir ve genellikle hatanın nedenini belirler.

Özet: Kubernetes Bir Araçtır, Amaç Değil

Kubernetes, büyük ölçekte konteynerli uygulamaları yönetmek için son derece güçlü bir araçtır. Pod, Service ve Deployment kavramları bu sistemin temelini oluşturur ve Kubernetes ile çalışmak isteyen herkes için bunları anlamak şarttır.

Ancak en önemli nokta, Kubernetes'i "moda" olduğu için değil, gerçek bir sorunu çözmek için seçmenizdir. Projeniz küçükse ve ekibiniz sınırlıysa, daha basit araçlar işinizi daha iyi yapar. Ve Kubernetes'e geçmeye karar verirseniz, küçük bir kümeyle başlayın, temel kavramları iyi öğrenin ve altyapınızı kademeli olarak genişletin.

Kubernetes'i üzerinde çalıştırabileceğiniz bir altyapı arıyorsanız, ServerNet'in bulut hizmetleri başlamak için uygun bir seçenek olabilir — ancak her zaman önce ihtiyacınızı netleştirin ve ardından uygun aracı seçin.

ServerNet Destek

ServerNet mühendislik ve yayın ekibi — altyapı, ağ ve web barındırma uzmanları.

İletişim
Paylaş:

Yorumlar 0

Henüz yorum yok — ilk siz olun!

Yorum bırakın