Kubernetes Pod Oluşturmanın Temelleri: Basit Sözdizimi Rehberi

Kubernetes ortamında uygulamalarınızı başarıyla dağıtmak için Pod’ların temel sözdizimini anlamak kritik öneme sahiptir. Bu rehberde, bir Pod’u sıfırdan nasıl oluşturacağınızı, yaşam döngüsünü nasıl yöneteceğinizi ve gerçek dünya senaryolarında nasıl kullanacağınızı adım adım keşfedeceksiniz.

Modern uygulama geliştirme ve dağıtım süreçleri, özellikle bulut tabanlı mimarilerde, karmaşıklığı beraberinde getirir. Uygulamalar artık tek parça devasa yapılar (monolitler) olmaktan çıkarak, mikro hizmetlere ayrılmış, bağımsız ve ölçeklenebilir bileşenler haline gelmiştir. Bu dönüşümde, konteyner teknolojileri ve konteyner orkestrasyon araçları kilit rol oynar. İşte tam bu noktada Kubernetes devreye girer. Ancak Kubernetes dünyasına adım attığınızda karşılaşacağınız en temel yapı taşı nedir? Yanıt: Pod.

Pod, Kubernetes’in dağıtılabilir en küçük birimidir ve bir uygulamanın veya uygulamanın bir kısmının çalıştırılacağı ortamı tanımlar. Kulağa basit gelse de, Pod’ların nasıl oluşturulduğunu, yapılandırıldığını ve yönetildiğini tam olarak kavramak, Kubernetes kümenizde stabil, verimli ve güvenli uygulamalar çalıştırmanın ilk ve en önemli adımıdır. Birçok geliştirici ve operasyon mühendisi, Kubernetes’in sağladığı soyutlamalara kapılarak Pod’ların altında yatan dinamikleri göz ardı edebilir. Ancak bu, potansiyel performans sorunlarına, hata ayıklama zorluklarına ve hatta güvenlik açıklarına yol açabilir.

Bu makale, Pod oluşturmanın temel sözdizimini derinlemesine inceleyerek, başlangıç seviyesindeki kullanıcılardan daha deneyimli profesyonellere kadar herkes için sağlam bir temel sunmayı amaçlamaktadır. Konuyu sıfırdan ele alarak, YAML dosyalarının gizemini çözmekten, Pod yaşam döngüsünü anlamaya, kaynakları optimize etmeye ve gerçek dünya senaryolarında karşılaşabileceğiniz sorunlara pratik çözümler sunmaya kadar geniş bir yelpazeyi kapsayacaktır. Böylece, hem teorik bilgiyi pekiştirecek hem de pratik uygulamalarla Kubernetes yetkinliğinizi bir üst seviyeye taşıyacaksınız. Kubernetes’in sunduğu tüm avantajlardan yararlanmak ve uygulamalarınızı bulut yerlisi paradigmaya uygun şekilde yönetmek için Pod’ların dilini akıcı bir şekilde konuşmaya başlamak şarttır.

Kubernetes ve Pod Nedir? Temel Kavramlara Hızlı Bir Bakış

Kubernetes, Google tarafından açık kaynak olarak geliştirilen ve konteynerli uygulamaları otomatik dağıtmak, ölçeklendirmek ve yönetmek için kullanılan güçlü bir konteyner orkestrasyon sistemidir. Docker gibi konteyner teknolojileri, uygulamaları izole edilmiş ve taşınabilir birimler halinde paketlememizi sağlarken, Kubernetes bu konteynerleri binlerce sunucu üzerinde koordineli bir şekilde çalıştırmamızı, kaynakları verimli kullanmamızı ve yüksek erişilebilirlik sağlamamızı mümkün kılar. Peki, bu büyük orkestrasyonun en temel enstrümanı nedir? Cevap Pod’dur.

Bir Pod, Kubernetes’in dağıtabileceği en küçük, en temel birimdir. Bir veya daha fazla konteyner (genellikle Docker konteynerleri) barındırır ve bu konteynerler için paylaşılan kaynakları (depolama birimi, ağ kimliği ve IP adresi gibi) sağlar. Neden doğrudan konteynerleri değil de Pod’ları kullanıyoruz diye düşünebilirsiniz. Bunun temel nedeni, bazı uygulamaların sıkı bir şekilde birlikte çalışan, ortak bir yaşam döngüsünü paylaşan ve aynı ağ ve depolama kaynaklarına ihtiyaç duyan birden fazla işlemden oluşmasıdır. Pod, bu tür birlikte çalışan konteynerleri mantıksal bir birim altında gruplandırarak, onların bir bütün olarak yönetilmesini kolaylaştırır.

Örneğin, bir web sunucusu uygulamasını düşünün. Bu uygulamanın ana konteynerinin yanı sıra, aynı Pod içinde çalışan bir günlük toplama aracı (sidecar konteyner) veya bir yapılandırma eşitleyici gibi yardımcı bir konteyner de bulunabilir. Bu iki konteyner aynı Pod içinde yer aldığında, aynı ağ arayüzünü paylaşır (localhost üzerinden birbirleriyle iletişim kurabilirler) ve paylaşılan bir depolama birimini kullanabilirler. Bu, onların bir “mantıksal ana bilgisayar” üzerinde çalışıyormuş gibi davranmalarını sağlar. Pod’lar genellikle geçicidir (ephemeral), yani öldüklerinde veya yeniden oluşturulduklarında içindeki veriler kaybolur. Bu nedenle, kalıcı verilere ihtiyaç duyan uygulamalar için Pod’lar genellikle kalıcı depolama birimleri (Persistent Volumes) ile birlikte kullanılır.

Pod’lar aynı zamanda yaşam döngüleri açısından da önemlidir. Kubernetes, Pod’ların sağlığını izler ve arızalanan Pod’ları otomatik olarak yeniden başlatır veya değiştirir. Bu sayede uygulamalarınızın kesintisiz çalışması sağlanır. Konteyner orkestrasyonunun temelini oluşturan Pod’lar, aynı zamanda daha yüksek seviyeli soyutlamaların (Deployment’lar, StatefulSet’ler vb.) da yapı taşıdır. Bu soyutlamalar, birden fazla Pod’u yönetmeyi ve uygulamaların ölçeklendirilmesini basitleştirir. Dolayısıyla, Kubernetes ekosistemini tam olarak anlamak ve verimli bir şekilde kullanmak için Pod’ların mimarisine ve davranışlarına hakim olmak şarttır.

Basit Bir Pod Nasıl Oluşturulur? Adım Adım YAML Rehberi

Kubernetes’te bir Pod oluşturmanın en yaygın ve önerilen yolu, Pod’un istenen durumunu (desired state) açıklayan bir YAML manifest dosyası yazmaktır. YAML (Yet Another Markup Language), insan tarafından okunabilir ve genellikle yapılandırma dosyaları için kullanılır. Bu bölümde, temel bir Pod’u adım adım nasıl oluşturacağımızı, bir Nginx web sunucusu örneği üzerinden göstereceğiz. Bu sayede, Pod manifestlerinin olmazsa olmaz alanlarını ve bunların ne anlama geldiğini net bir şekilde anlayacaksınız.

1. Adım: YAML Manifest Dosyasını Oluşturun

Öncelikle, Pod’umuz için bir YAML dosyası oluşturmamız gerekiyor. Bu dosyayı örneğin nginx-pod.yaml olarak adlandırabiliriz. Dosyanın içeriği aşağıdaki gibi olacaktır:

apiVersion: v1
kind: Pod
metadata:
  name: benim-nginx-pod
  labels:
    app: webserver
    env: dev
spec:
  containers:
  - name: nginx-konteyner
    image: nginx:latest
    ports:
    - containerPort: 80
    

Bu YAML dosyasındaki her bir alanı inceleyelim:

• apiVersion: v1: Kubernetes API sürümünü belirtir. Pod'lar için genellikle v1 kullanılır. Bu, Kubernetes kümesinin nesneleri nasıl işleyeceğini anlamasına yardımcı olur.
• kind: Pod: Oluşturmak istediğimiz Kubernetes nesnesinin türünü belirtir. Bu durumda bir Pod oluşturmak istiyoruz.
• metadata: Nesne hakkında meta bilgileri içerir.
  • name: benim-nginx-pod: Pod'umuz için benzersiz bir isim tanımlar. Bu isim, Pod'u yönetmek (getirme, silme vb.) için kullanılır.
  • labels: Pod'a anahtar-değer çiftleri şeklinde etiketler ekler. Bu etiketler, Pod'ları gruplandırmak, seçmek ve organize etmek için kritik öneme sahiptir. Örneğin, bu etiketler sayesinde web sunucusu görevindeki tüm Pod'ları veya geliştirme ortamındaki tüm Pod'ları kolayca filtreleyebiliriz.
• spec: Pod'un davranışını ve içeriğini açıklayan Pod spesifikasyonunu içerir.
  • containers: Pod içinde çalışacak konteynerlerin listesini belirtir. Bir Pod birden fazla konteyner içerebilir, ancak çoğu zaman tek bir ana konteyner kullanılır.
    • - name: nginx-konteyner: Konteynerin adını belirtir. Pod içindeki diğer konteynerlerden ayırt etmek için benzersiz olmalıdır.
    • image: nginx:latest: Konteynerin hangi Docker imajından oluşturulacağını belirtir. Bu örnekte, Docker Hub'dan en son Nginx imajını çekilecektir.
    • ports: Konteynerin dış dünyaya açacağı portları tanımlar. Bu, Kubernetes'in ağ yapılandırması için bir ipucu sağlar.
      • - containerPort: 80: Konteynerin içindeki uygulamanın dinlediği portu belirtir.

2. Adım: Pod'u Kubernetes Kümenize Dağıtın

YAML dosyasını oluşturduktan sonra, onu Kubernetes kümenize dağıtmak için kubectl apply komutunu kullanırız. kubectl, Kubernetes kümeleriyle etkileşim kurmak için kullanılan komut satırı aracıdır. Terminalinizde aşağıdaki komutu çalıştırın:

kubectl apply -f nginx-pod.yaml
    

Bu komut, nginx-pod.yaml dosyasında tanımlanan Pod'u Kubernetes kümenize gönderir ve Kubernetes bu Pod'u oluşturmak için gerekli işlemleri başlatır. Başarılı olursa, terminalinizde "pod/benim-nginx-pod created" gibi bir çıktı göreceksiniz.

3. Adım: Pod'un Durumunu Kontrol Edin

Pod'unuzun başarıyla oluşturulup çalışır durumda olup olmadığını kontrol etmek için aşağıdaki komutu kullanabilirsiniz:

kubectl get pods
    

Bu komut, kümenizdeki tüm Pod'ların bir listesini ve durumlarını gösterir. benim-nginx-pod isimli Pod'unuzun Running (Çalışıyor) durumunda olduğunu görmelisiniz. Eğer Pending (Beklemede) veya başka bir durumda ise, bir sorun olduğunu gösterir ve daha fazla araştırma yapmanız gerekebilir. Pod'unuzun daha detaylı bilgilerini incelemek için:

kubectl describe pod benim-nginx-pod
    

Bu komut, Pod'un olaylarını (events), konteyner bilgilerini, IP adresini ve daha birçok detayı içeren kapsamlı bir çıktı sunar. Böylece, Pod'un neden bir durumda takılı kaldığını veya neden başlatılamadığını anlamak için önemli ipuçları elde edebilirsiniz.

Bu üç adımı tamamladığınızda, Kubernetes kümenizde ilk Pod'unuzu başarıyla oluşturmuş ve temel yönetimini gerçekleştirmiş olacaksınız. Bu basit yapı, daha karmaşık Kubernetes nesnelerini ve dağıtım stratejilerini anlamanın temelini oluşturur.

Pod Yaşam Döngüsü ve Durumları: Uygulamanızın Sağlığını Nasıl Takip Edersiniz?

Bir Pod'un oluşturulmasından yok edilmesine kadar geçen süreye Pod yaşam döngüsü denir. Bu döngü içinde Pod, farklı fazlardan ve konteynerleri de farklı durumlardan geçer. Uygulamalarınızın Kubernetes kümesinde istikrarlı bir şekilde çalıştığından emin olmak ve olası sorunları hızlıca tespit etmek için bu fazları ve durumları anlamak hayati öneme sahiptir. Pod'un sağlık durumunu izlemek ve yönetmek, güvenilir bir dağıtım stratejisinin temelini oluşturur.

Pod Fazları (Phases)

Bir Pod, yaşam döngüsü boyunca aşağıdaki fazlardan birinde bulunur:

• Pending (Beklemede): Pod, Kubernetes API tarafından kabul edilmiştir, ancak bir veya daha fazla konteyner imajı henüz oluşturulmamış veya çalıştırılamamıştır. Bu durum genellikle kaynak yetersizliği (CPU, bellek), imaj çekme sorunları veya bir düğümün Pod'u zamanlayamaması nedeniyle oluşur.
• Running (Çalışıyor): Pod, bir düğüme atanmış ve içindeki tüm konteynerler oluşturulmuştur. En az bir konteyner çalışıyor veya başlatılıyor. Bu, genellikle istediğimiz durumdur.
• Succeeded (Başarılı): Pod içindeki tüm konteynerler başarıyla sonlandırılmış ve yeniden başlatılmayacaktır. Bu faz, tek seferlik görevleri veya batch işlerini tamamlayan Pod'lar için geçerlidir.
• Failed (Başarısız): Pod içindeki tüm konteynerler sonlandırılmış ve en az bir konteyner bir hata durumuyla sonlanmıştır. Bu da, yeniden başlatılmayacakları anlamına gelir.
• Unknown (Bilinmiyor): Kümenin Pod'un durumunu belirleyemediği bir durumdur. Genellikle düğümle iletişim kurulamaması gibi bir iletişim hatasından kaynaklanır.

Konteyner Durumları (Container States)

Bir Pod içindeki konteynerler de kendi içlerinde farklı durumlar yaşar:

• Waiting (Beklemede): Konteyner çalışmıyor ve bir eylemi bekliyor. Örneğin, bir imajın çekilmesini veya bir Init Konteynerinin tamamlanmasını bekleyebilir.
• Running (Çalışıyor): Konteyner başarıyla başlatıldı ve çalışıyor.
• Terminated (Sonlandırıldı): Konteyner çalışmayı durdurdu. Neden sonlandığına (başarılı veya hata ile) bağlı olarak bir çıkış kodu (exit code) ve sonlanma nedeni (reason) vardır.

Sağlık Kontrolleri: Liveness ve Readiness Probes

Kubernetes, uygulamaların sağlığını aktif olarak izlemek için iki tür sağlık kontrolü (probe) sunar:

1. Liveness Probe (Canlılık Kontrolü): Konteynerin hala çalışır durumda olduğunu ve uygulamanın donmadığını kontrol eder. Eğer liveness probe başarısız olursa, Kubernetes konteyneri yeniden başlatır. Bu, uygulamanın kendini kurtarmasına olanak tanır.

   
           livenessProbe:
             httpGet:
               path: /healthz
               port: 8080
             initialDelaySeconds: 15
             periodSeconds: 20
               

2. Readiness Probe (Hazırlık Kontrolü): Konteynerin dışarıdan gelen trafiği kabul etmeye hazır olup olmadığını kontrol eder. Eğer readiness probe başarısız olursa, Kubernetes bu Pod'u Service'ten kaldırır, böylece trafiği bu Pod'a yönlendirmez. Uygulama hazır olduğunda, Pod tekrar Service'e eklenir. Bu, dağıtım sırasında sıfır kesinti (zero-downtime) sağlamak için önemlidir.

   
           readinessProbe:
             httpGet:
               path: /ready
               port: 8080
             initialDelaySeconds: 5
             periodSeconds: 5
               

Bu sağlık kontrolleri, uygulamalarınızın sadece "çalışıyor" değil, aynı zamanda "sağlıklı" ve "hizmet vermeye hazır" olmasını sağlar. Doğru yapılandırıldıklarında, otomatik kendi kendine iyileştirme mekanizmaları sunarlar.

Sorun Giderme ve Loglama

Bir Pod'un durumuyla ilgili sorunları teşhis etmek için kullanabileceğiniz bazı temel kubectl komutları vardır:

• kubectl describe pod : Pod'un tüm detaylarını, olaylarını ve durumunu gösterir. Özellikle Events bölümü, Pod'un neden bir hata durumuna geçtiğini veya neden başlayamadığını anlamak için çok değerlidir.
• kubectl logs : Pod içindeki konteynerin standart çıktı (stdout) ve standart hata (stderr) loglarını gösterir. Uygulamanızın ne yaptığını, hangi hataları verdiğini görmek için olmazsa olmaz bir araçtır. Birden fazla konteynerli bir Pod için -c parametresiyle belirli bir konteynerin loglarını görüntüleyebilirsiniz.
• kubectl exec -it -- /bin/bash: Çalışan bir konteyner içine interaktif bir shell (kabuk) açar. Bu, konteyner içinde dosya sistemini incelemek, yapılandırmaları kontrol etmek veya küçük testler yapmak için harikadır.

Bu araçları etkili bir şekilde kullanarak, Pod yaşam döngüsünü ve durumlarını aktif olarak takip edebilir, böylece uygulamalarınızın kesintisiz ve verimli bir şekilde çalışmasını sağlayabilirsiniz. Uygulama sağlığının doğru bir şekilde anlaşılması, Kubernetes'te başarılı bir operasyon için temeldir.

Gerçek Dünya Senaryosu: Bir Web Uygulamasını Pod'da Çalıştırmak

Teorik bilgileri pekiştirmek ve Pod'ların gerçek dünyadaki kullanım senaryolarını anlamak için basit bir web uygulamasını Kubernetes Pod'unda nasıl çalıştıracağımıza dair bir vaka incelemesi yapalım. Senaryomuz, Node.js ile yazılmış küçük bir web uygulamasını barındıracak bir Pod oluşturmak ve bu uygulamayı çalıştırmak olacak. Bu örnek, ortam değişkenleri ve temel kaynak yönetimi gibi daha önce bahsettiğimiz bazı kavramları da pekiştirecektir.

Senaryo: Basit Bir Node.js Uygulaması

Bir Node.js uygulamamız olduğunu varsayalım. Bu uygulama, HTTP isteklerini dinleyen ve basit bir JSON yanıtı döndüren temel bir Express.js sunucusu olabilir. Uygulamanın çalışacağı portu ve diğer bazı yapılandırmaları ortam değişkenleri aracılığıyla alması gerektiğini düşünelim.

Öncelikle, uygulamanın bir Docker imajına paketlenmiş olması gerekir. Basit bir Dockerfile şöyle görünebilir:

# Dockerfile
FROM node:18-alpine
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
EXPOSE 3000
CMD ["node", "server.js"]
    

Bu imajın my-nodejs-app:1.0.0 olarak Docker Hub'a yüklendiğini varsayalım.

Pod Manifest Dosyası Oluşturma: nodejs-app-pod.yaml

Şimdi bu Node.js uygulamasını çalıştıracak Pod manifestini oluşturalım. Bu manifestte, uygulamanın çalışacağı portu ve uygulamanın alması gereken bir mesajı ortam değişkenleri olarak tanımlayacağız. Ayrıca, Pod'un kaynak isteğini (request) de belirteceğiz.

apiVersion: v1
kind: Pod
metadata:
  name: nodejs-web-app-pod
  labels:
    app: nodejs-app
    tier: frontend
spec:
  containers:
  - name: nodejs-konteyner
    image: my-nodejs-app:1.0.0 # Kendi Docker imajınızın adı
    ports:
    - containerPort: 3000
    env:
    - name: NODE_ENV
      value: production
    - name: GREETING_MESSAGE
      value: "Merhaba Kubernetes Dünyası!"
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"
    livenessProbe:
      httpGet:
        path: /health
        port: 3000
      initialDelaySeconds: 5
      periodSeconds: 10
    readinessProbe:
      httpGet:
        path: /ready
        port: 3000
      initialDelaySeconds: 5
      periodSeconds: 5
    

Bu manifestteki önemli eklemeler şunlardır:

• env: Uygulamanın içine enjekte edilecek ortam değişkenlerini tanımlar. Burada NODE_ENV ve GREETING_MESSAGE değişkenlerini belirttik. Uygulamanız bu değişkenlere erişerek farklı davranışlar sergileyebilir.
• resources: Pod'un kaynak isteklerini (requests) ve limitlerini (limits) tanımlar.
  • requests: Kubernetes zamanlayıcısının bu Pod'u yerleştireceği düğümde garanti altına alması gereken minimum kaynak miktarıdır. Bu, Pod'un çalışması için gereken "asgari" kaynakları ifade eder.
  • limits: Pod'un kullanabileceği maksimum kaynak miktarıdır. Eğer bir Pod bu limiti aşarsa, Kubernetes tarafından kısıtlanabilir veya sonlandırılabilir. Bu, bir Pod'un kümedeki diğer Pod'ların kaynaklarını tüketmesini engeller.
• livenessProbe ve readinessProbe: Daha önce bahsettiğimiz sağlık kontrolleri. Uygulamanın /health ve /ready endpoint'lerini kullanarak sağlığını denetlemesini sağlar.

Pod'u Dağıtma ve Kontrol Etme

Dosyayı kaydettikten sonra, Pod'u dağıtmak için kubectl apply -f nodejs-app-pod.yaml komutunu kullanın. Ardından kubectl get pods ve kubectl describe pod nodejs-web-app-pod komutlarıyla Pod'un durumunu kontrol edebilirsiniz. Eğer her şey yolundaysa, Pod'unuz Running durumunda olacaktır.

Pod'unuzun loglarını izleyerek uygulamanın gerçekten çalıştığından emin olabilirsiniz:

kubectl logs nodejs-web-app-pod
    

Eğer uygulamanız basitçe "Merhaba Kubernetes Dünyası!" mesajını gösteriyorsa, ortam değişkenlerinin başarıyla enjekte edildiğini ve uygulamanızın çalıştığını görmelisiniz.

Bu gerçek dünya senaryosu, Pod'ların sadece bir konteyneri çalıştırmakla kalmayıp, aynı zamanda uygulamanın ihtiyaç duyduğu ortamı (ortam değişkenleri, kaynaklar) nasıl sağladığını ve yaşam döngüsünü nasıl yönettiğini göstermektedir. Bu sayede, daha karmaşık mikro hizmet mimarilerini oluşturmak için sağlam bir temel oluşturabilirsiniz.

Gelişmiş Pod Yapılandırmaları ve İpuçları: Kaynak Yönetimi ve Ağ

Temel Pod oluşturma ve yönetme bilgisine sahip olduktan sonra, Pod'larınızın performansını, güvenliğini ve kararlılığını artıracak daha gelişmiş yapılandırmaları keşfedelim. Özellikle kaynak yönetimi ve ağ ayarları, büyük ölçekli ve kritik uygulamalar için hayati öneme sahiptir. Bu bölümde, Pod'larınızdan en iyi verimi almanıza yardımcı olacak bazı ipuçlarına ve yapılandırma örneklerine değineceğiz.

Kaynak İstekleri ve Limitleri (Resource Requests & Limits)

Daha önce Node.js örneğinde kısaca değindiğimiz kaynak istekleri ve limitleri, kümenizin sağlığı ve Pod'larınızın öngörülebilir performansı için kritik bir öneme sahiptir. Doğru yapılandırıldığında:

• Kaynak İstekleri (requests): Pod'unuzun çalışması için garanti edilen minimum kaynak miktarıdır (CPU ve bellek). Kubernetes zamanlayıcısı, bir Pod'u bir düğüme yerleştirirken bu istekleri dikkate alır. Eğer düğümde istenen kaynaklar yoksa, Pod Pending durumunda kalabilir.
  • CPU: "m" (millicores) birimiyle ifade edilir. 250m, 0.25 CPU çekirdeği anlamına gelir.
  • Bellek: "Mi" (mebibytes) veya "Gi" (gibibytes) birimiyle ifade edilir. 64Mi, 64 mebibytes bellek anlamına gelir.
• Kaynak Limitleri (limits): Pod'unuzun kullanabileceği maksimum kaynak miktarıdır.
  • CPU limiti aşılırsa, konteyner kısıtlanır (throttling).
  • Bellek limiti aşılırsa, konteyner sonlandırılır (OOMKilled - Out Of Memory Killed).

resources:
  requests:
    memory: "128Mi"
    cpu: "500m"
  limits:
    memory: "256Mi"
    cpu: "1000m" # veya "1" (1 CPU çekirdeği)
    

Bu ayarlar, hem uygulamanızın performansını garanti altına alır hem de kümedeki kaynakların adil bir şekilde dağıtılmasını sağlar. Yanlış kaynak limitleri, performans düşüşlerine veya uygulamanızın beklenmedik şekilde çökmesine yol açabilir.

Service Account: Pod Güvenliği

Her Pod, varsayılan olarak bir Service Account'a atanır. Bu Service Account, Pod içindeki süreçlerin Kubernetes API ile nasıl etkileşim kurabileceğini tanımlar. Uygulamanızın Kubernetes API ile etkileşime girmesi gerekiyorsa (örneğin, diğer Pod'ları keşfetmek veya bir ConfigMap'i okumak için), uygun RBAC (Role-Based Access Control) izinlerine sahip özel bir Service Account oluşturmanız ve Pod'unuza atamanız gerekir. Bu, güvenlik açısından "en az ayrıcalık" ilkesini uygulamak için önemlidir.

spec:
  serviceAccountName: benim-ozel-service-hesabim
  containers:
  - name: ...
    

Node Selector ve Affinity/Anti-Affinity: Pod Zamanlama Kontrolü

Bazen Pod'larınızın belirli özelliklere sahip düğümlerde (node) çalışmasını isteyebilirsiniz. Örneğin, GPU'lu düğümlerde makine öğrenimi Pod'ları veya belirli bir bölgedeki düğümlerde veritabanı Pod'ları. Kubernetes, Pod zamanlamasını kontrol etmek için çeşitli mekanizmalar sunar:

• Node Selector: Basit ve doğrudan bir yaklaşımdır. Pod'unuzu belirli etiketlere sahip düğümlerde çalıştırır.

  
  spec:
    nodeSelector:
      disktype: ssd
    containers:
    - name: ...
              

• Node Affinity/Anti-Affinity: Daha esnek ve gelişmiş zamanlama kuralları tanımlamanızı sağlar. "Tercih ettiğim düğümler" (preferredDuringSchedulingIgnoredDuringExecution) veya "kesinlikle bu düğümlerde çalış" (requiredDuringSchedulingIgnoredDuringExecution) gibi kurallar belirleyebilirsiniz. Anti-affinity ise Pod'ların belirli koşulları sağlayan düğümlerde çalışmamasını veya belirli diğer Pod'larla aynı düğümde olmamasını sağlar. Bu, yüksek erişilebilirlik ve performans için önemlidir.

Mobil Uyumlu HTML Örneği (CSS Media Query)

Makale içinde interaktif veya bilgi kutuları gibi öğeler kullandığınızda, bunların farklı ekran boyutlarında düzgün görünmesi önemlidir. Aşağıdaki CSS örneği, bu makalede kullandığımız .pod-info-card sınıfı için mobil uyumluluğu nasıl sağlayabileceğinizi gösterir:

Bu CSS medya sorguları, sayfanın görüntülenen genişliğine bağlı olarak farklı stiller uygulayarak, içeriğin her cihazda okunabilir ve estetik kalmasını sağlar. Mobil uyumluluk, günümüz web standartlarında vazgeçilmez bir özelliktir.

Bu gelişmiş yapılandırmalar, Pod'larınızın daha verimli, güvenli ve esnek olmasını sağlar. Kubernetes'in sunduğu tüm bu yetenekleri kullanarak, uygulamalarınız için sağlam ve optimize edilmiş bir temel oluşturabilirsiniz.

Sıkça Sorulan Sorular (SSS)

Bu makalede Pod oluşturmanın temellerini ve bazı gelişmiş yapılandırmalarını ele aldık. Ancak Kubernetes'e yeni başlayanların aklına takılan bazı genel sorular olabilir. İşte Pod'larla ilgili en sık karşılaşılan sorulardan bazıları:

1. Pod'lar neden geçici (ephemeral) yapılardır?

Pod'lar, modern, bulut yerlisi uygulama geliştirme paradigmalarına uygun olarak tasarlanmıştır. Bu paradigma, uygulamaların durum bilgisi içermeyen (stateless) ve atılabilir (disposable) olmasını teşvik eder. Bir Pod öldüğünde (örneğin bir hata nedeniyle veya bir düğüm çökmesiyle), Kubernetes tarafından otomatik olarak yeniden oluşturulur. Ancak bu yeniden oluşturma, yeni bir IP adresi ve temiz bir dosya sistemi ile tamamen yeni bir Pod anlamına gelir. Bu geçicilik, ölçeklenebilirliği ve otomatik kendi kendine iyileşmeyi kolaylaştırır. Kalıcı verilere ihtiyaç duyan uygulamalar için Pod'lar genellikle Persistent Volume (Kalıcı Depolama Birimi) ile birlikte kullanılır, böylece Pod'lar değişse bile veriler korunur.

2. Bir Pod içindeki kapsayıcılar nasıl iletişim kurar?

Bir Pod içindeki tüm kapsayıcılar aynı ağ ad alanını (network namespace) paylaşır. Bu, onların localhost üzerinden birbirleriyle iletişim kurabileceği anlamına gelir. Her kapsayıcı, Pod'un paylaştığı IP adresini ve port alanını kullanabilir. Örneğin, bir web sunucusu kapsayıcısı 8080 portunu dinlerken, aynı Pod içindeki bir sidecar kapsayıcısı da 8081 portunu dinleyebilir ve web sunucusu localhost:8081 üzerinden bu sidecar ile iletişim kurabilir. Bu yakınlık ve paylaşılan ağ, sıkı bir şekilde birlikte çalışan süreçler için idealdir.

3. Pod'lar ve Deployment'lar arasındaki fark nedir?

Pod, Kubernetes'in dağıtabileceği en küçük birimdir ve tek bir uygulama örneğini temsil eder. Deployment ise, Pod'ları yönetmek için kullanılan daha üst düzey bir soyutlamadır. Bir Deployment, bir uygulama için kaç adet özdeş Pod kopyasının (replica) çalışması gerektiğini, Pod'ların nasıl güncelleneceğini (örneğin sıfır kesinti ile yuvarlanan güncellemeler - rolling updates) ve eğer bir Pod arızalanırsa nasıl otomatik olarak yeniden oluşturulacağını tanımlar. Yani, doğrudan Pod oluşturmak yerine, genellikle bir Deployment oluşturarak Pod'larınızın kararlı ve yönetilebilir olmasını sağlarsınız. Deployment'lar, uygulamanızın ölçeklenmesini ve yüksek erişilebilirliğini sağlamanın anahtarıdır.

4. Pod'um neden Pending durumunda kalıyor?

Bir Pod'un Pending durumunda kalmasının birkaç yaygın nedeni vardır:

• Kaynak Yetersizliği: Pod'un istediği CPU veya bellek kaynaklarına sahip uygun bir düğüm kümede bulunmuyor olabilir. kubectl describe pod komutu ile olayları kontrol edin.
• İmaj Çekme Sorunları: Konteyner imajı mevcut değil, imaj adı yanlış yazılmış, imaj deposuna erişim izni yok veya imajın çekilmesi çok uzun sürüyor olabilir.
• Düğüm Problemleri: Bir düğümün disk alanı dolu olabilir, ağ bağlantısı kesilmiş olabilir veya Kubelet (düğümdeki Kubernetes aracısı) düzgün çalışmıyor olabilir.
• Ağ Yapılandırma Sorunları: CNI (Container Network Interface) eklentisinde bir sorun olabilir.

Bu sorunları teşhis etmek için genellikle kubectl describe pod ve kubectl logs komutları size yol gösterecektir.

5. Pod'uma nasıl harici erişim sağlarım?

Pod'lar varsayılan olarak küme içinde kendilerine atanmış bir IP adresine sahiptir ve dışarıdan doğrudan erişilemezler (güvenlik ve esneklik nedenleriyle). Bir Pod'a veya Pod grubuna dışarıdan erişim sağlamak için Kubernetes Service (Hizmet) nesnelerini kullanırsınız. En yaygın Service türleri şunlardır:

• ClusterIP: Küme içinde bir Pod grubuna (label selector ile belirlenen) dahili bir IP adresi atar. Küme içindeki diğer Pod'lar bu IP üzerinden erişebilir.
• NodePort: ClusterIP'ye ek olarak, her düğümde belirli bir portu açar ve bu porttan gelen trafiği Service'e yönlendirir. Böylece, : üzerinden dışarıdan erişilebilir.
• LoadBalancer: Genellikle bulut sağlayıcıları tarafından desteklenir (AWS ELB, GCP Load Balancer vb.). Uygulamanız için harici bir yük dengeleyici provision eder ve gelen trafiği Service'e yönlendirir.
• Ingress: Uygulama katmanında (HTTP/HTTPS) trafik yönlendirmesi için kullanılır. Birden fazla Service'e tek bir dış IP adresi üzerinden karmaşık yönlendirme kuralları uygulamanızı sağlar.

Uygulamanızın türüne ve ihtiyaçlarına göre uygun Service tipini seçerek Pod'larınıza dışarıdan erişim sağlayabilirsiniz.