Kubernetes: Sıfırdan İleri Seviye Uygulamalı Rehber (DevOps)

Kubernetes’e Giriş: Tanımı ve Önemi

Modern yazılım geliştirme dünyasında uygulamalar, artık tek parça hâlinde çalışan yapılardan çok, küçük ve bağımsız servislerden oluşan mikroservis mimarilerine dönüşmüş durumda. Bu dönüşüm, uygulamaların daha esnek, ölçeklenebilir ve yönetilebilir olmasını sağlarken, aynı zamanda altyapı yönetimini de oldukça karmaşık hale getiriyor. İşte tam bu noktada Kubernetes devreye giriyor.

Kubernetes Nedir?

Kubernetes (kısaca K8s), konteynerleştirilmiş uygulamaların dağıtımını, yönetimini, ölçeklenmesini ve otomatikleştirilmesini sağlayan açık kaynaklı bir konteyner orkestrasyon platformudur. Google tarafından geliştirilen ve bugün Cloud Native Computing Foundation (CNCF) tarafından yönetilen Kubernetes, altyapı bağımsız uygulama çalıştırma standardı haline gelmiştir.

Kubernetes’in Önemi

1. Otomasyon Sağlar: Kubernetes, uygulamaların başlatılmasını, yeniden başlatılmasını, güncellenmesini ve ölçeklenmesini otomatik hale getirir. Bu sayede manuel müdahale ihtiyacı azalır.

2. Yüksek Erişilebilirlik Sunar: Uygulama bileşenleri birden fazla sunucuda yedekli çalıştırılabilir. Bir sunucu arızalansa bile hizmet kesintisiz devam eder.

3. Kaynak Verimliliği Sağlar: Kubernetes, donanım kaynaklarını daha verimli kullanır. Gereksiz kaynak tüketiminin önüne geçerek maliyetleri düşürür.

4. Platform Bağımsızlığı Sunar: Uygulamalar, ister şirket içi veri merkezinde, ister bulut ortamında, isterse hibrit altyapılarda aynı şekilde çalıştırılabilir.

5. Mikroservis Mimarisine Uyumlu Çalışır: Kubernetes, mikroservis yapılarını destekleyen, modüler ve yönetilebilir bir sistem sunar.

6. Sürekli Entegrasyon ve Teslimat (CI/CD) ile Uyumlu: Yazılım geliştirme süreçlerinin otomasyonu için ideal bir zemin oluşturur.

Kubernetes Kimin İçin Gereklidir?

• Geliştiriciler için: Uygulamaların güvenli ve ölçeklenebilir şekilde dağıtılmasını sağlar.

• Sistem yöneticileri için: Karmaşık altyapıların sadeleştirilmesini ve merkezi yönetimini mümkün kılar.

• DevOps ekipleri için: Süreçlerin otomasyonu, gözlemlenebilirlik ve iş birliği kolaylığı sunar.

• Şirketler için: Daha kısa ürün geliştirme döngüsü, daha hızlı hata çözümü ve daha sağlam altyapı ile rekabet avantajı sağlar.

Master Node ve Worker Node: Kubernetes Mimarisinin Temel Taşları

Kubernetes’in güçlü ve ölçeklenebilir yapısı, dağıtık bir mimari üzerine kuruludur. Bu mimaride, görev ve sorumluluklar iki temel bileşen grubu arasında paylaşılır: Master Node (Yönetici Düğüm) ve Worker Node (Çalışan Düğüm).

Master Node (Yönetici Düğüm)

Master Node, Kubernetes kümesinin beyni olarak görev yapar. Tüm sistemin durumunu izler, kararlar alır ve bu kararları Worker Node’lara ileterek uygulamaların doğru şekilde çalışmasını sağlar. Master Node üzerindeki temel bileşenler şunlardır:

• API Server: Kullanıcılar, komut satırı araçları (kubectl) ve diğer servisler Kubernetes kümesiyle bu arayüz üzerinden iletişim kurar. Tüm dış iletişimin giriş kapısıdır.

• Scheduler: Yeni oluşturulacak Pod’ların hangi Worker Node üzerinde çalışacağını belirler. Kaynak kullanımı, erişilebilirlik ve politikaları dikkate alır.

• Controller Manager: Sistemdeki kaynakları sürekli denetler ve olması gereken durumla fiili durumu eşleştirir. Örneğin bir Pod çökerse, yeniden oluşturulmasını sağlar.

• etcd: Kubernetes’in dağıtık anahtar-değer veri deposudur. Tüm küme durum bilgisi burada saklanır (örneğin Pod’lar, ConfigMap’ler, servis tanımları).

• Cloud Controller Manager (isteğe bağlı): Bulut ortamına özel işlemler için kullanılır (örneğin, Load Balancer tanımlama).

Worker Node (Çalışan Düğüm)

Worker Node’lar, Kubernetes tarafından yönetilen uygulamaların fiilen çalıştığı sunuculardır. Bu düğümler üzerinde konteynerler barındırılır ve çalıştırılır. Temel bileşenleri şunlardır:

• Kubelet: Master Node ile iletişim kurar ve Pod’ların node üzerinde tanımlandığı şekilde çalışmasını sağlar. Her Worker Node’da bulunur.

• Container Runtime: Konteynerleri çalıştıran altyapıdır. En yaygın örnekleri Docker, containerd ve CRI-O’dur.

• kube-proxy: Ağ iletişimini yönetir. Servisler arası trafik yönlendirmelerini ve yük dengelemeyi sağlar.

İşleyişin Özeti

1. Kullanıcı veya bir CI/CD süreci, Kubernetes API'sine bir Pod oluşturma isteği gönderir.

2. API Server bu isteği alır, Scheduler uygun bir Worker Node seçer.

3. Controller Manager, durumu izler ve Pod’un çalıştığından emin olur.

4. Kubelet, seçilen Worker Node üzerinde konteyneri başlatır.

5. kube-proxy, uygulama trafiğini yöneterek ağ bağlantılarını düzenler.

Master Node (Kontrol Düzlemi)

Kubernetes mimarisinde Master Node, sistemin yönetim ve kontrol katmanıdır. Kontrol düzlemi olarak da adlandırılan bu yapı, Kubernetes kümesinin tüm karar alma süreçlerinden ve kümenin genel durumundan sorumludur. Uygulamaların nerede, nasıl ve ne zaman çalıştırılacağını belirler; Worker Node’lara bu doğrultuda talimat verir.

Master Node’un Temel Bileşenleri

1. API Server (kube-apiserver)

Kubernetes sisteminin dış dünya ile olan tüm etkileşimleri API Server üzerinden gerçekleşir. Kullanıcı isteklerini alır, doğrular, yetkilendirir ve etcd veritabanına iletir. kubectl gibi araçların yanı sıra diğer dahili bileşenler de API Server ile iletişim kurar. Sistemin merkezî iletişim noktasıdır.

2. etcd

Kubernetes’in dağıtık yapıdaki anahtar-değer veritabanıdır. Kümenin tüm yapılandırmaları ve çalışma durumu burada tutulur. Yüksek güvenlikli ve yedekli bir yapıda çalışması önerilir. Sistemin hafızası olarak görev yapar.

3. Scheduler (kube-scheduler)

Yeni oluşturulan Pod’ların hangi Worker Node üzerinde çalıştırılacağını belirler. Node’ların mevcut kaynak kullanımı, etiketleri, kısıtlamaları ve politikaları dikkate alarak en uygun yerleşimi yapar. Planlama yapar; doğrudan çalıştırma işlemi gerçekleştirmez.

4. Controller Manager (kube-controller-manager)

Sistemin hedeflenen durumu ile mevcut durumu karşılaştırır ve gerekirse müdahale eder. Pod’ların yeniden başlatılması, Node durumlarının kontrolü, ReplicaSet yönetimi gibi görevleri yerine getirir. Birden fazla kontrol döngüsü burada çalışır.

5. Cloud Controller Manager (isteğe bağlı)

Kubernetes’in bir bulut sağlayıcısı ile entegre çalışmasını sağlar. Örneğin, bulut üzerinde yük dengeleyici oluşturma, disk bağlama veya sanal IP yönetimi gibi işlemleri yürütür. Bulut ortamlarında kullanılır.

Kontrol Düzleminin Rolü

• Kubernetes kümesinin yönetimsel merkezidir.

• Kaynak tahsisi, durum izleme, yeniden başlatma, ölçeklendirme ve benzeri kararları verir.

• Yüksek erişilebilirlik sağlamak için birden fazla Master Node ile yapılandırılabilir.

• Worker Node’ların işlemlerini düzenler, ancak kendisi uygulama çalıştırmaz.

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

Kubernetes kümesinde uygulamaların gerçek anlamda çalıştığı altyapıdır. Her bir Worker Node, bir veya daha fazla uygulama konteynerini çalıştırmakla sorumludur. Master Node’dan gelen talimatlar doğrultusunda, Pod’ları oluşturur, yönetir ve izler. Kümeye yeni bir Worker Node eklendiğinde sistem yatayda ölçeklenmiş olur, böylece daha fazla uygulama yükü taşınabilir.

Worker Node Bileşenleri

1. Kubelet

Node üzerindeki Pod’ların çalışmasını sağlayan ana bileşendir. API Server ile iletişim kurarak bu Node’da hangi Pod’ların çalıştırılması gerektiğini öğrenir ve bu Pod’ların istenilen durumda olup olmadığını düzenli olarak kontrol eder. Pod’ların yaşam döngüsünü yönetir.

2. Kube-proxy

Ağ iletişimini düzenleyen bileşendir. Kubernetes hizmetlerine (Services) gelen trafiği doğru Pod’lara yönlendirir. NAT (Network Address Translation) veya IP tabanlı kurallar kullanarak dış dünyadan gelen isteklerin doğru hedefe ulaşmasını sağlar.

3. Container Runtime

Pod içerisindeki konteynerleri oluşturan ve çalıştıran yazılımdır. En yaygın kullanılan container runtime’lar Docker, containerd ve CRI-O’dur. Kubernetes, CRI (Container Runtime Interface) aracılığıyla farklı runtime’ları destekler.

Worker Node’un Görevleri

• Master Node’dan gelen planlamaları alır ve uygulamaları (Pod’ları) çalıştırır.

• Çalıştırdığı Pod’ların sağlık durumunu izler ve raporlar.

• Uygulamalar arasındaki ağ trafiğini yönlendirir.

• Yerel kaynakları (CPU, bellek, disk) en verimli şekilde kullanmaya çalışır.

• Gerektiğinde yük dengeleme veya otomatik yeniden başlatma işlemlerini gerçekleştirir.

Worker Node’un Önemi

Worker Node’lar, Kubernetes kümesinin üretim katmanıdır. Uygulamaların, mikroservislerin, arka plan görevlerinin ve iş yüklerinin tamamı bu düğümler üzerinde çalışır. Yeterli sayıda ve dengeli yapılandırılmış Worker Node’lar, yüksek erişilebilirlik ve sistem performansı için kritik öneme sahiptir.

Kubernetes Mimarisi

Kubernetes, konteyner tabanlı uygulamaların otomatik olarak dağıtılması, yönetilmesi, ölçeklendirilmesi ve izlenmesi için geliştirilmiş açık kaynaklı bir platformdur. Sistemin mimarisi, kontrol düzlemi (Control Plane) ve çalışan düğümler (Worker Nodes) olmak üzere iki temel bileşen grubuna ayrılır. Bu yapı, yatayda kolayca ölçeklenebilir ve dağıtık sistemleri yüksek güvenilirlikle yönetebilir.

1. Kontrol Düzlemi (Control Plane)

Kubernetes’in yönetim katmanıdır. Tüm sistemin durumu buradan izlenir ve kontrol edilir. Karar verme, iş yükü dağıtımı, sistem denetimi gibi temel görevleri üstlenir.

• API Server: Kullanıcı ve sistem bileşenlerinin Kubernetes ile iletişimini sağlar.

• etcd: Kümenin tüm konfigürasyon bilgilerini saklayan dağıtık veritabanıdır.

• Scheduler: Pod’ların hangi Node’da çalıştırılacağını belirler.

• Controller Manager: Pod’ların, ReplicaSet’lerin ve diğer kaynakların hedef durumda kalmasını sağlar.

• Cloud Controller Manager: Bulut sağlayıcıya özel kaynakların yönetimini üstlenir (isteğe bağlı).

2. Worker Node (Çalışan Düğümler)

Uygulamaların (Pod’ların) çalıştığı fiziksel ya da sanal sunuculardır. Master Node’dan gelen görevleri yerine getirir.

• Kubelet: Pod’ları başlatır, izler ve raporlar.

• Kube-proxy: Ağ yönlendirmelerini ve servis iletişimini sağlar.

• Container Runtime: Konteynerleri çalıştıran motor (ör. containerd, CRI-O).

3. Kubernetes Nesneleri (Objects)

Kubernetes mimarisinin çalışabilmesi için çeşitli nesneler tanımlanır. Bu nesneler YAML veya JSON formatında tanımlanarak API Server’a gönderilir.

• Pod: Kubernetes’in en küçük dağıtım birimi. Bir veya daha fazla konteyner içerir.

• Service: Pod’lara ulaşımı sağlayan soyut bir katmandır.

• Deployment: Uygulama dağıtım süreçlerini ve güncellemeleri yönetir.

• ReplicaSet: Belirli sayıda Pod’un her zaman çalışmasını sağlar.

• Namespace: Kaynakları mantıksal olarak ayırmak için kullanılır.

4. Yardımcı Bileşenler ve Özellikler

• ConfigMap ve Secret: Uygulama yapılandırmaları ve hassas bilgiler için kullanılır.

• Ingress: Dış dünyadan gelen HTTP(S) trafiğini içerideki servislerle buluşturur.

• Volumes: Pod’lara kalıcı veya geçici veri depolama sağlar.

• Helm: Kubernetes için paket yöneticisidir, karmaşık uygulamaları kolayca dağıtır.

Ölçeklenebilirlik ve Yüksek Erişilebilirlik

• Kubernetes yatayda kolayca ölçeklenebilir.

• Birden fazla Master ve Worker Node ile yüksek erişilebilirlik (HA) sağlanabilir.

• Otomatik iyileşme ve yeniden başlatma mekanizmaları ile sistem kesintilere karşı dayanıklıdır.

Windows Docker Desktop Kurulumu

1. Gereksinimler:

• Windows 10 veya üzeri (64-bit): Home veya Pro sürümü önerilir.

• Donanım Sanallaştırma (Virtualization): BIOS ayarlarınızdan etkinleştirilmiş olmalı. (Genellikle varsayılan olarak aktiftir.)

2. Docker Desktop'ı İndirin:

• Docker'ın resmi web sitesine gidin: https://www.docker.com/products/docker-desktop/

• "Docker Desktop for Windows" butonuna tıklayarak kurulum dosyasını (.exe) indirin.

3. Kurulumu Başlatın:

• İndirdiğiniz .exe dosyasına çift tıklayarak kurulum sihirbazını başlatın.

• Karşınıza çıkan ekranda genellikle varsayılan ayarları kabul ederek "Next" butonuna tıklayın.

• "Use WSL 2 based engine (recommended)" seçeneğinin işaretli olduğundan emin olun (daha iyi performans için). Eğer işaretli değilse işaretleyin.

• Kurulumun tamamlanmasını bekleyin.

4. Yeniden Başlatma:

• Kurulum tamamlandıktan sonra sisteminizi yeniden başlatmanız istenecektir. "Close and restart" veya benzeri bir butona tıklayarak bilgisayarınızı yeniden başlatın.

5. Docker'ı Kontrol Edin:

• Yeniden başlatma işleminden sonra, Başlat menüsünde "Docker Desktop" uygulamasını bulun ve çalıştırın.

• Sağ alt köşedeki sistem tepsisinde Docker ikonu belirecektir. Bu, Docker'ın çalıştığı anlamına gelir.

• Komut istemcisini (CMD) veya PowerShell'i açın ve aşağıdaki komutu çalıştırın:

  docker --version

  
  

  Bu komut, Docker'ın kurulu sürümünü göstermelidir. Herhangi bir hata mesajı almıyorsanız, kurulum başarıyla tamamlanmıştır.

Tebrikler! Docker Desktop başarıyla kuruldu ve kullanıma hazır. Artık Docker imajlarını çekebilir, konteynerler oluşturabilir ve çalıştırabilirsiniz.

Ek Not: Kurulum sırasında herhangi bir sorun yaşarsanız, Docker'ın resmi dokümantasyonunu veya online kaynakları kontrol edebilirsiniz.

Docker Desktop Kurulumu

Docker Desktop, geliştiricilerin konteyner tabanlı uygulamaları yerel olarak oluşturup test etmelerine olanak tanıyan bir araçtır. Windows, macOS ve Linux sistemlerinde kullanılabilir. Kubernetes gibi orkestrasyon sistemlerini yerel ortamda çalıştırmak isteyenler için ideal bir başlangıç ortamıdır.

1. Sistem Gereksinimleri

Windows için:

• Windows 10 Pro, Enterprise veya Education (Build 15063 veya daha yeni)

• Hyper-V ve Containers özelliklerinin etkinleştirilmiş olması

• BIOS'ta sanallaştırma (Virtualization) desteği açık olmalı

macOS için:

• macOS 11 (Big Sur) veya daha yeni sürümler

• Apple Silicon (M1/M2) veya Intel tabanlı işlemci desteklenir

Linux için:

• Docker Engine tercih edilir (Docker Desktop sınırlı desteklidir)

2. Docker Desktop İndirme ve Kurulum

Windows & macOS:

1. Docker’ın resmi sitesi üzerinden işletim sisteminize uygun Docker Desktop sürümünü indirin.

2. İndirdikten sonra kurulum dosyasını çalıştırın.

3. Kurulum sihirbazını takip ederek gerekli izinleri verin.

4. Kurulum tamamlandıktan sonra sistem yeniden başlatılabilir.

5. Docker Desktop açıldığında sistem simgesinde balina simgesi görünmelidir.

6. İlk açılışta kullanıcı girişi veya Docker Hub hesabı isteyebilir.

Linux:

Linux kullanıcıları genellikle Docker Engine kurar. Ancak bazı özel durumlarda (örneğin Ubuntu WSL ile) Docker Desktop kullanılabilir.

1. Terminal üzerinden kurulum için aşağıdaki komutları çalıştırabilirsiniz:

sudo apt update

sudo apt install docker.io

sudo systemctl start docker

sudo systemctl enable docker

1. Docker'ın doğru kurulduğunu test edin:

docker run hello-world

3. Docker Desktop Ayarları (İsteğe Bağlı)

• Kubernetes Desteği:
  Docker Desktop, tek tıkla yerel Kubernetes kümesini etkinleştirme imkanı sunar. Ayarlar → Kubernetes sekmesinden “Enable Kubernetes” seçeneğini işaretleyerek kurulumu başlatabilirsiniz.

• Kaynak Kullanımı:
  Ayarlar → Resources sekmesinden CPU, RAM ve Disk sınırlarını belirleyebilirsiniz.

• WSL2 Entegrasyonu (Windows):
  WSL2 altyapısı üzerinden çalıştırılabilir. Daha performanslı ve daha az kaynak tüketir. Ayarlardan WSL2 entegrasyonu etkinleştirilebilir.

4. Doğrulama ve Test

Kurulum sonrası Docker Desktop’un doğru çalıştığını test etmek için terminal veya PowerShell'de şu komutu çalıştırın:

docker --version

docker run hello-world

Bu komut, basit bir test konteyneri indirir ve çalıştırır. Çıktı başarılıysa Docker kurulumu tamamlanmıştır.

Docker Desktop üzerinde Kubernetes

Docker Desktop, yerel geliştirme ortamlarında konteyner tabanlı uygulamaları çalıştırmanın yanı sıra, Kubernetes gibi orkestrasyon sistemlerini de kolayca kullanabilmenize olanak tanır. Docker Desktop’un Kubernetes desteği sayesinde, yerel bilgisayarınızda tam işlevsel bir Kubernetes kümesi oluşturabilir ve yönetebilirsiniz.

1. Docker Desktop’ta Kubernetes’i Etkinleştirme

Docker Desktop, varsayılan olarak Kubernetes’i etkinleştirilen bir platform değildir. Ancak, birkaç adımda Kubernetes’i kolayca başlatabilirsiniz.

Adım 1: Docker Desktop’u Açın

Docker Desktop yüklü ve çalışır durumda olduğunda, simgesini sağ alt köşede veya menüde görebilirsiniz. Docker Desktop’un açık olduğundan emin olun.

Adım 2: Kubernetes Sekmesine Geçin

1. Docker Desktop’un üst menüsünden Preferences (Windows) veya Settings (macOS) seçeneğine tıklayın.

2. Kubernetes sekmesine gidin.

3. Enable Kubernetes seçeneğini işaretleyin. Bu, Docker Desktop'un yerel Kubernetes kümesini kurmasını sağlar.

Adım 3: Kubernetes’in Yüklenmesini Bekleyin

Kubernetes’i etkinleştirdikten sonra, Docker Desktop otomatik olarak gerekli bileşenleri indirir ve kurar. Bu işlem birkaç dakika sürebilir. Kurulum tamamlandığında, Docker Desktop üzerinde Kubernetes kümesinin çalıştığını görebilirsiniz.

Adım 4: Küme Durumunu Kontrol Etme

Kurulumdan sonra, Kubernetes kümesinin doğru çalışıp çalışmadığını terminal üzerinden şu komutla kontrol edebilirsiniz:

kubectl cluster-info

Eğer her şey doğru şekilde kurulmuşsa, Kubernetes kümesinin URL’leri ve bilgileri terminalde gösterilecektir.

2. Docker Desktop Kubernetes ile Çalışma

Kubernetes’i Docker Desktop üzerinden etkinleştirdikten sonra, kubectl komut satırı aracını kullanarak küme ile etkileşime geçebilirsiniz. Kubernetes komutları Docker Desktop üzerinde çalışan yerel kümeyi yönetmek için aynıdır.

Adım 1: Kubernetes’e Bağlantıyı Sağlayın

Docker Desktop, kubectl aracını önceden yükler ve doğru şekilde yapılandırır. Bu sayede, terminal veya komut satırı üzerinden Kubernetes komutlarını çalıştırabilirsiniz.

Örneğin, mevcut Pod’ları görmek için şu komutu kullanabilirsiniz:

kubectl get pods

Adım 2: Pod ve Hizmetler Oluşturma

Kubernetes’i Docker Desktop üzerinde kullanırken, uygulamaları Pod’lar içinde çalıştırabilirsiniz. Pod ve hizmet oluşturmak için YAML dosyaları oluşturabilir ve bunları kubectl komutlarıyla uygulayabilirsiniz.

Örnek bir Pod oluşturma:

kubectl run my-app --image=nginx --restart=Never

Bu komut, nginx imajını kullanarak yeni bir Pod başlatır.

Adım 3: Kubernetes Dashboard Erişimi

Kubernetes Dashboard, Kubernetes kümenizi görsel olarak yönetmek için bir araçtır. Docker Desktop üzerinde Kubernetes Dashboard’u açmak için şu komutu kullanabilirsiniz:

kubectl proxy

Bu komut çalıştıktan sonra, web tarayıcınızda aşağıdaki URL'yi ziyaret edebilirsiniz:

http://localhost:8001/ui

Kubernetes Dashboard, küme üzerindeki kaynakları görsel olarak yönetmenize olanak tanır.

3. Kaynak Yönetimi ve İzleme

Docker Desktop üzerinde Kubernetes kullanırken, kaynak kullanımı ve sistem durumu önemlidir. Docker Desktop, CPU, RAM ve disk kaynaklarını ayarlayabileceğiniz bir yapı sunar. Ayrıca, Kubernetes’i etkinleştirdiğinizde, her Pod ve Container için kaynak sınırlarını belirleyebilirsiniz.

Adım 1: Kaynak Ayarları

Docker Desktop’ta Kubernetes için kaynak ayarlarını yapmak için:

1. Docker Desktop’un Preferences veya Settings bölümüne gidin.

2. Resources sekmesinden Kubernetes için kullanılacak CPU, RAM ve disk miktarlarını belirleyebilirsiniz.

Adım 2: Pod Durumunu İzlemek

Kubernetes Pod’larınızın durumunu izlemek için şu komutu kullanabilirsiniz:

kubectl get pods

Pod’larınızın durumunu öğrenmek için detaylı rapor almak için şu komutu kullanabilirsiniz:

kubectl describe pod [pod_adı]

4. Kubernetes ve Docker Desktop Entegrasyonu

Docker Desktop ile Kubernetes kullanmak, konteyner yönetimini ve orkestrasyonunu yerel olarak test etmenize olanak tanır. Ayrıca, Docker’ın konteyner görüntülerini (images) Docker Hub’a yükleyebilir ve Kubernetes’e entegre bir şekilde bu görüntüleri kullanabilirsiniz.

Adım 1: Docker İmajlarını Kubernetes ile Kullanma

Docker üzerinde geliştirdiğiniz bir konteyneri Kubernetes üzerinde çalıştırmak için, önce Docker imajını oluşturmanız gerekmektedir. Örnek:

docker build -t my-app .

Daha sonra, bu imajı Kubernetes üzerinde bir Pod olarak çalıştırabilirsiniz.

Adım 2: Helm ile Uygulama Yönetimi

Helm, Kubernetes uygulamalarını paketlemek ve yönetmek için kullanılan bir araçtır. Docker Desktop üzerindeki Kubernetes kümesinde Helm’i kullanarak uygulama dağıtımını daha kolay hale getirebilirsiniz.

Chocolatey (kısaca choco), Windows işletim sistemi için geliştirilmiş paket yönetim sistemidir. Linux'taki apt, yum veya dnf gibi araçlara benzer şekilde çalışır ve yazılımların komut satırından kolayca yüklenmesini, güncellenmesini ve kaldırılmasını sağlar.

Chocolatey Nedir?

Chocolatey, NuGet teknolojisi üzerine kurulmuş açık kaynaklı bir Windows paket yöneticisidir.
Geliştiriciler, sistem yöneticileri ve DevOps mühendisleri için Windows ortamında yazılım kurulumlarını otomatikleştirir ve standartlaştırır.

Neden Chocolatey Kullanılır?

• Hızlı kurulum: Tek komutla yazılım kurma, kaldırma, güncelleme işlemleri yapılabilir.

• Otomasyon uyumluluğu: CI/CD, PowerShell scriptleri veya yapılandırma yönetim araçlarıyla (örneğin Ansible, Puppet) entegre çalışabilir.

• Depo yönetimi: Kendi özel kurumsal yazılım deposunu oluşturma ve yönetme imkanı sunar.

• Sessiz kurulum (silent install): Kullanıcı etkileşimi olmadan yazılımlar kurulabilir.

Avantajları Nelerdir?

• ✅ Zamandan tasarruf: GUI ile uğraşmadan toplu yazılım yükleme yapılabilir.

• ✅ Script tabanlı yönetim: Sistem kurulumları otomatik hale getirilebilir.

• ✅ Sürekli güncel: Yaygın yazılımlar (Google Chrome, Git, Node.js, Visual Studio Code vb.) için binlerce paket mevcuttur.

• ✅ Kurumsal destek: Chocolatey for Business sürümü, güvenlik, denetim ve lisanslama gibi kurumsal ihtiyaçlara hitap eder.

• ✅ Geri alınabilirlik: Yüklenen paketler versiyon bazlı izlenebilir ve gerektiğinde geri alınabilir.

Temel Kullanım Örnekleri

Chocolatey kurulumu:

Set-ExecutionPolicy Bypass -Scope Process -Force; `

[System.Net.ServicePointManager]::SecurityProtocol = `

[System.Net.ServicePointManager]::SecurityProtocol -bor 3072; `

iex ((New-Object System.Net.WebClient).DownloadString('https://community.chocolatey.org/install.ps1'))

Yazılım kurmak:

choco install git -y

Yazılım güncellemek:

choco upgrade git

Kurulu paketleri listelemek:

choco list --local-only

Özetle, Chocolatey, Windows ortamında yazılım yönetimini otomasyon odaklı, hızlı ve tekrarlanabilir hale getirerek hem bireysel kullanıcılar hem de kurumsal BT ekipleri için büyük kolaylık sağlar.

1. Kubectl Komutları Temelleri

kubectl Yapılandırması

Kubernetes kümesiyle etkileşime geçebilmek için kubectl’in doğru yapılandırılmış olması gerekmektedir. kubectl genellikle kubeconfig dosyasını kullanarak küme ile iletişim kurar.

Küme Durumunu Kontrol Etme:

kubectl cluster-info

Bu komut, mevcut Kubernetes kümenizin URL'lerini gösterir.

2. Temel Kubectl Komutları

Pod’ları Listeleme

Bir Kubernetes kümesindeki pod'ları görmek için:

kubectl get pods

Yalnızca belirli bir namespace içindeki pod’ları listelemek için:

kubectl get pods -n [namespace_adı]

Pod Detaylarını Görüntüleme

Pod’un detaylı bilgilerini almak için:

kubectl describe pod [pod_adı]

Bu komut, belirli bir pod ile ilgili ayrıntılı bilgileri (loglar, olaylar, kaynak kullanımı vb.) gösterir.

Yeni Bir Pod Oluşturma

Yeni bir pod oluşturmak için:

kubectl run [pod_adı] --image=[docker_image_adı]

Örneğin, basit bir nginx pod'u oluşturmak için:

kubectl run nginx --image=nginx

Pod Silme

Bir pod’u silmek için:

kubectl delete pod [pod_adı]

Pod Loglarını Görüntüleme

Bir pod’un loglarını görmek için:

kubectl logs [pod_adı]

Eğer pod birden fazla konteyner içeriyorsa, belirli bir konteynerin loglarını görmek için:

kubectl logs [pod_adı] -c [container_adı]

3. Kubernetes Kaynakları ile Çalışma

Servis Oluşturma

Kubernetes servisleri, pod’lara erişimi sağlayan ağ kaynaklarıdır. Yeni bir servis oluşturmak için:

kubectl expose pod [pod_adı] --port=[port] --target-port=[target_port]

Deployment Yönetimi

Deployment, bir uygulamanın sürekli olarak çalışmasını sağlar. Yeni bir deployment oluşturmak için:

kubectl create deployment [deployment_adı] --image=[docker_image_adı]

Deployment’ı güncellemek için:

kubectl set image deployment/[deployment_adı] [container_adı]=[yeni_image]

Deployment'ı silmek için:

kubectl delete deployment [deployment_adı]

Service Bilgilerini Görüntüleme

Bir servis hakkında detaylı bilgi almak için:

kubectl get svc [service_adı]

Namespace Kullanımı

Kubernetes'te kaynakları organize etmek için namespace kullanılır. Mevcut namespace’leri görmek için:

kubectl get namespaces

Yeni bir namespace oluşturmak için:

kubectl create namespace [namespace_adı]

Bir namespace içinde işlem yapmak için, ilgili komutları şu şekilde yazabilirsiniz:

kubectl get pods -n [namespace_adı]

4. Kubectl ile Etkileşim ve Kaynak Yönetimi

Kubernetes Config Dosyasını Belirleme

Birden fazla kubeconfig dosyası kullanıyorsanız, hangi dosyayı kullanacağınızı belirlemek için:

kubectl --kubeconfig=[config_dosya_adı] get pods

Kubectl Konteyner Başlatma

Bir pod’daki bir konteyneri başlatmak için:

kubectl exec -it [pod_adı] -- [komut]

Örneğin, bir pod üzerinde interaktif bash shell açmak için:

kubectl exec -it [pod_adı] -- /bin/bash

Kaynakları Güncelleme

Kubernetes kaynaklarını güncellemek için, YAML dosyaları kullanabilir veya doğrudan kubectl komutları ile yapılabilir. Örneğin, pod’ları güncellemek için:

kubectl apply -f [dosya_adı].yaml

Kubernetes Events İzleme

Kubernetes olaylarını (events) izlemek için:

kubectl get events

5. Kubectl ile İleri Seviye İşlemler

Kubernetes Tünelleme (Port Forwarding)

Bir Kubernetes pod'una dışarıdan erişmek için port yönlendirmesi yapabilirsiniz:

kubectl port-forward pod/[pod_adı] [local_port]:[pod_port]

YAML ile Kaynak Oluşturma

YAML dosyası kullanarak Kubernetes kaynaklarını oluşturabilirsiniz. Örnek olarak, bir deployment dosyası (deployment.yaml) kullanarak:

kubectl apply -f deployment.yaml

Pod Etiketleme

Pod’lara etiket eklemek için:

kubectl label pods [pod_adı] [etiket_adı]=[değer]

1. Pod

Bir Pod, Kubernetes’teki en küçük dağıtım birimidir ve bir veya daha fazla konteyneri barındırır. Pod'lar, aynı ağ altında olan konteynerlerin grup halidir ve bu konteynerler, birbiriyle iletişim kurabilir. Pod’lar genellikle bir uygulamanın parçası olarak çalışır ve aynı anda birden fazla konteyner çalıştırabilir.

• Özellikler:

  • Aynı pod içinde bulunan konteynerler, aynı IP adresi, port numaraları ve depolama alanına sahip olabilirler.

  • Pod'lar geçici olup, genellikle kısa ömürlüdür. Pod’lar ölür ve yeniden başlatılabilir.

2. Node

Bir Node, Kubernetes kümesindeki fiziksel veya sanal bir makinedir. Node’lar, pod’ları çalıştırmak için gerekli olan kaynakları sağlar ve Kubernetes kümesinin işlevselliğini destekler. Her node’da, pod'ları çalıştıran kubelet, pod'ların ağ bağlantılarını yöneten kube-proxy gibi bileşenler bulunur.

• Özellikler:

  • Kubernetes kümesinde her node, bir kontrol düzlemi (master node) tarafından yönetilir.

  • Node’lar, CPU, RAM ve disk gibi kaynakları sağlayarak pod'ların çalışma ortamını oluşturur.

3. Service

Service, Kubernetes’te bir grup pod'a kalıcı bir IP adresi ve DNS ismi sağlayan soyut bir kaynaktır. Pod'lar genellikle dinamik olarak değişir (yeniden başlatılabilir, ölçeklenebilir), ancak Service, pod’lar arasında sabit bir erişim noktası sağlar.

• Özellikler:

  • ClusterIP: Sadece küme içindeki diğer bileşenler tarafından erişilebilen bir IP adresi atar.

  • NodePort: Dışarıdan erişilebilen bir port üzerinden pod’lara yönlendirme yapılmasını sağlar.

  • LoadBalancer: Dışarıdan bir yük dengeleme IP'si alır.

4. Scheduler

Scheduler, Kubernetes'in bir kontrol bileşenidir ve yeni pod'ları kümedeki uygun node'lara yerleştirmekle sorumludur. Scheduler, kaynak kullanımı, node'lar arasındaki dengeler ve diğer kriterler göz önünde bulundurularak hangi node üzerinde çalışacaklarını belirler.

• Özellikler:

  • Yük dengelemesi sağlar.

  • Pod'ları uygun node’lara yerleştirirken, node’un kaynak kapasitesine (CPU, bellek vb.) dikkat eder.

5. ReplicaSet

Bir ReplicaSet, Kubernetes’in ölçeklendirme ve yüksek erişilebilirlik sağlamak için kullandığı bir bileşendir. ReplicaSet, belirli bir sayıda aynı pod örneğini çalıştırır ve bu sayıyı sürekli olarak kontrol eder. Eğer bir pod kaybolursa veya başarısız olursa, ReplicaSet yeni bir pod başlatır.

• Özellikler:

  • Uygulamanın yüksek erişilebilirliğini sağlar.

  • Belirli bir sayıda pod örneğinin sürekli çalışmasını garanti eder.

6. ConfigMap

ConfigMap, uygulamalarınızın yapılandırma verilerini Kubernetes ortamında dışarıdan almanızı sağlayan bir bileşendir. ConfigMap, genellikle uygulama yapılandırma ayarları, ortam değişkenleri veya konfigürasyon dosyalarını tutar.

• Özellikler:

  • Pod’lar, ConfigMap ile dışarıdan yapılandırma verisi alabilir.

  • Bu yapılandırmalar, uygulama yeniden başlatılmadan değiştirilebilir.

7. Secret

Secret, genellikle gizli ve hassas bilgileri (şifreler, API anahtarları, vb.) depolamak için kullanılır. Kubernetes'teki secret'lar, verilerin şifrelenmiş bir biçimde saklanmasını sağlar. Bu sayede uygulamanızda güvenli bir şekilde şifreleme işlemi gerçekleştirebilirsiniz.

• Özellikler:

  • Secret, şifreli verilerin güvenli bir şekilde depolanmasını sağlar.

  • Uygulama tarafından erişilerek gerekli gizli veriler kullanılır.

8. Ingress

Ingress, dış dünyadan (genellikle internet üzerinden) Kubernetes içindeki hizmetlere (servisler) erişimi yöneten bir bileşendir. Ingress, HTTP ve HTTPS trafiğini yönlendirme, SSL/TLS şifrelemesi gibi özellikler sunar. Ingress Controller, bu trafiği kümedeki doğru pod’lara yönlendirir.

• Özellikler:

  • Ingress, dış erişimi kolaylaştırır ve güvenlik sağlar.

  • Yük dengeleme, SSL sonlandırma ve URL yönlendirmeleri yapabilir.

9. Namespace

Namespace, Kubernetes'te kaynakları mantıksal olarak izole etmek için kullanılan bir yapıdır. Aynı küme içinde farklı projeleri, uygulamaları veya takımları birbirinden ayırmak için kullanılır. Namespace’ler, kaynak yönetimini daha düzenli ve izole bir şekilde yapmanıza yardımcı olur.

• Özellikler:

  • Birden fazla uygulama veya proje aynı küme içinde yönetilebilir.

  • Kaynaklar, namespace’ler aracılığıyla ayrı ayrı yönetilebilir.

Pod, Kubernetes’teki en temel ve küçük dağıtım birimidir. Bir veya birden fazla konteynerin bir arada çalıştığı bir yapıdır ve Kubernetes’in tüm yönetim işlemleri pod’lar üzerinden yapılır. Pod, aynı anda birden fazla konteyneri çalıştırabilir, bu konteynerlerin birbirleriyle iletişim kurmasını sağlar ve genellikle bir uygulamanın veya hizmetin bir parçası olarak çalışır.

Pod’un Temel Özellikleri

1. Konteyner Gruplama:

   • Pod, aynı anda bir veya daha fazla konteyneri barındırabilir. Bu konteynerler, birbiriyle yakın ilişkiler içinde çalışacak şekilde tasarlanır.

   • Örneğin, bir uygulama ve ona bağlı bir önbellek servisi aynı pod içinde çalışabilir.

2. Aynı IP Adresi:

   • Pod içinde bulunan tüm konteynerler aynı IP adresini paylaşır. Bu sayede, bu konteynerler birbirleriyle doğrudan iletişim kurabilir. Konteynerler arasındaki iletişim için localhost (127.0.0.1) kullanılır.

   • Bu, konteynerlerin dışarıdan aynı ağda yer alıyormuş gibi çalışmasını sağlar.

3. Paylaşılan Depolama Alanı:

   • Pod içerisindeki konteynerler, aynı depolama alanını paylaşabilir. Bu, veri paylaşımı ve veri tutarlılığı sağlamak için kullanılır.

   • Pod, bu paylaşılan depolama alanını konteynerler arasında paylaşarak veri sürekliliği sağlar.

4. Yaşam Döngüsü:

   • Pod’lar genellikle kısa ömürlüdür. Bir pod, başlatıldığında belirli bir süre çalışır ve ölür. Pod’lar genellikle tek bir görev veya uygulama parçasını temsil eder.

   • Eğer bir pod hata verir veya başarısız olursa, Kubernetes yönetim düzlemi otomatik olarak yeni bir pod oluşturur (bu, özellikle ReplicaSet gibi başka bileşenlerle entegre olarak çalışır).

5. Küme İçinde Dağıtım ve Yönetim:

   • Pod’lar, Kubernetes kümesinin üzerinde çalıştırılan uygulamaların en küçük birimidir. Kubernetes, pod'ların ölçeklendirilmesi, yönetilmesi, sağlıklı olup olmadığına dair izlemesi ve yüksek erişilebilirlik sağlaması gibi işlemleri gerçekleştirir.

Pod’ların İçindeki Konteynerler

Bir pod, tek bir konteyner veya birden fazla konteyner içerebilir. Pod içindeki konteynerler genellikle birbirleriyle yakın bir ilişki içindedir ve aşağıdaki nedenlerle bir pod içinde bir arada çalışır:

• Aynı Amaç için Çalışan Konteynerler:

  • Örneğin, bir web uygulaması konteyneri ile bir veritabanı konteyneri aynı pod’da yer alabilir. Bu, her iki konteynerin de aynı ağ üzerinden birbirine hızlı ve güvenli bir şekilde erişebilmesini sağlar.

• Bağımsızlık Olmayan Konteynerler:

  • Konteynerler, her biri bağımsız bir uygulama birimi olarak çalışmak yerine, belirli bir işin parçası olarak bir arada çalışır.

Pod’ların Yaşam Döngüsü

Pod’ların yaşam döngüsü, Kubernetes’in uygulamaları yönetmesinde önemli bir rol oynar. Pod’un ömrü genellikle üç aşamadan oluşur:

1. Başlatma (Pending):

   • Pod oluşturulduğunda ve küme üzerinde bir node’a yerleştirilene kadar geçen süreçtir. Pod, henüz başlatılmamış olabilir ve konteynerleri başlatmak için kaynak tahsisi yapılır.

2. Çalışma (Running):

   • Pod’un konteynerleri çalışmaya başladığında, pod durumu “Running” olarak değişir. Bu aşamada, pod’lar ağ üzerinde iletişim kurabilir ve işlem yapabilir.

3. Tamamlanmış (Succeeded) / Başarısız (Failed):

   • Pod’un konteynerleri başarılı bir şekilde işini tamamladıysa, pod durumu “Succeeded” olarak değişir. Eğer pod veya konteyner hata verirse, durum “Failed” olur.

4. Silme (Terminated):

   • Pod sonlandırıldığında, Kubernetes pod’u siler. Eğer pod’un sağlığı bozulmuşsa, Kubernetes yeni bir pod oluşturabilir.

Pod Yönetimi ve Ölçeklendirme

Kubernetes, Deployment, ReplicaSet gibi bileşenler aracılığıyla pod’ları yönetir ve ölçeklendirir. Bir uygulama için belirli sayıda pod çalıştırmak istiyorsanız, bu bileşenler kullanılarak pod sayısı dinamik bir şekilde ayarlanabilir. Kubernetes’in otomatik ölçeklendirme özellikleri, pod’ların sayısını gerektiğinde artırır veya azaltır.

Pod’un Kullanım Alanları

1. Tek Konteynerli Podlar:

   • Küçük uygulamalar veya test ortamlarında, tek bir konteyner barındıran pod’lar kullanılabilir.

   • Örneğin, basit bir API servisi bir pod içinde tek bir konteyner olarak çalışabilir.

2. Çok Konteynerli Podlar:

   • Birden fazla konteynerin aynı anda çalışması gerektiğinde, pod içinde birden fazla konteyner kullanılabilir.

   • Örneğin, bir web uygulaması konteyneri ve bu web uygulamasının önbellek yönetimini yapan bir konteyner aynı pod içinde yer alabilir.

Pod İle İlgili Bazı Önemli Kavramlar:

• Pod Template: Pod’ları tanımlarken, bir pod şablonu oluşturabilirsiniz. Bu şablon, pod’ların yapılandırılmasında kullanılan temel bilgileri içerir.

• Pod Spec: Pod’un çalışma zamanındaki yapılandırmasıdır. Hangi konteynerlerin çalışacağı, hangi kaynakların sağlanacağı ve diğer yapılandırma detayları burada belirtilir.

Pod Kubernetes’in temel birimlerinden biridir ve bir veya daha fazla konteynerin aynı anda çalıştığı bir yapıdır. Pod'lar, Kubernetes tarafından uygulamaların yönetimi için kullanılan en küçük dağıtım birimleri olarak kabul edilir. İşte Pod'un temel özellikleri:

1. Aynı IP Adresi Paylaşımı

• Pod içinde bulunan tüm konteynerler aynı IP adresini paylaşır. Bu sayede, konteynerler birbirleriyle doğrudan iletişim kurabilir ve localhost üzerinden birbirlerine ulaşabilir.

• Aynı IP adresi paylaşımı, konteynerler arasındaki iletişimi hızlandırır ve basitleştirir.

2. Paylaşılan Depolama

• Pod içindeki konteynerler, aynı paylaşılan depolama alanına sahip olabilir. Bu özellik, veri paylaşımını ve tutarlılığını sağlar.

• Konteynerler, pod içerisindeki depolama alanını kullanarak veri üzerinde işlem yapabilir ve birbirleriyle veri paylaşabilir.

3. Yaşam Döngüsü

• Pod'lar genellikle kısa ömürlüdür ve belirli bir görev veya uygulama parçasını çalıştırmak için kullanılır.

• Bir pod’un yaşam döngüsü, başlatılmasından sonlandırılmasına kadar geçen süreçte Kubernetes tarafından yönetilir. Pod, başarısız olduğunda otomatik olarak yeniden başlatılabilir veya yeni bir pod oluşturulabilir.

4. Konteyner Gruplama

• Bir pod, bir veya birden fazla konteyneri bir arada barındırabilir. Bu konteynerler, genellikle aynı uygulama ya da servis için çalışır ve birbirleriyle etkileşim içindedir.

• Örneğin, bir web uygulaması konteyneri ve ona bağlı bir veritabanı konteyneri aynı pod içinde çalışabilir. Bu sayede, konteynerler arasında doğrudan iletişim sağlanır.

5. Aynı Node Üzerinde Çalışma

• Bir pod içindeki tüm konteynerler, aynı node (sunucu) üzerinde çalışır. Kubernetes, pod’ları cluster içindeki uygun node’lara yerleştirir ve bu node üzerinde konteynerleri başlatır.

• Bu, konteynerlerin aynı fiziksel kaynakları (CPU, RAM vb.) paylaşarak daha verimli çalışmasını sağlar.

6. Bütünsel Konteyner Yönetimi

• Pod, birden fazla konteynerin birlikte çalışmasını sağlayan bir yapıdır, ancak kendi başına bir yönetim birimi olarak da işlev görür. Kubernetes, pod düzeyinde işlemleri yönetir.

• Eğer bir pod içindeki bir konteyner başarısız olursa, Kubernetes bu durumu tespit eder ve pod içerisindeki diğer konteynerler çalışmaya devam eder.

7. Daha Kolay Konfigürasyon ve Dağıtım

• Pod'lar, konteynerlerin yapılandırılmasında kullanılan şablonlar ile tanımlanabilir. Bu şablonlar, hangi konteynerlerin çalışacağını, hangi kaynakların sağlanacağını ve diğer parametreleri belirler.

• Kubernetes, pod şablonları üzerinden bu yapılandırmalarla otomatik olarak dağıtım yapar.

8. Pod İçe Alınması (Pod Scheduling)

• Kubernetes, her pod için uygun node’u seçerken, pod’un gereksinimlerini (CPU, RAM, vb.) göz önünde bulundurur ve kaynakları verimli bir şekilde yönetir.

• Bu sayede, pod'lar doğru bir node üzerine yerleştirilerek hem verimlilik hem de yüksek erişilebilirlik sağlanır.

9. ReplicaSet ve Ölçeklenebilirlik

• Pod’lar, ReplicaSet gibi bileşenlerle birlikte çalışarak, belirli bir sayıda pod’un aynı anda çalışmasını sağlar. Bu, uygulamaların ölçeklenebilirliğini artırır.

• Kubernetes, ihtiyaç duyulduğunda yeni pod’lar oluşturur veya mevcut pod’ları ölçeklendirir.

10. Pod İçindeki Konteynerlerin Koordinasyonu

• Pod içindeki konteynerler, genellikle birbirlerini tamamlayan işlevlere sahiptir ve aynı görev için birlikte çalışır. Konteynerler arasındaki iletişim localhost üzerinden yapılır, bu da hızlı ve güvenli bir iletişim sağlar.

• Örneğin, bir pod içindeki bir web sunucusu konteyneri, aynı pod içindeki bir veritabanı konteynerine doğrudan erişebilir.

11. Aynı Zamanlı Çalışma ve Çökme Durumunda Yönetim

• Bir pod içindeki konteynerlerden biri başarısız olursa, Kubernetes tarafından belirlenen sağlık denetimleri ile bu durum tespit edilerek pod’daki diğer konteynerler çalışmaya devam edebilir.

• Pod’un tüm konteynerleri çalışmayı durdurursa, Kubernetes yeni bir pod oluşturur.

12. Yüksek Erişilebilirlik

• Kubernetes, pod'ların yüksek erişilebilirlik sağlamak için ölçeklendirme ve yük dengeleme mekanizmalarını kullanır.

• Eğer bir pod arızalanırsa, sistem otomatik olarak yeni bir pod oluşturur veya diğer sağlıklı pod’ları kullanarak hizmeti devam ettirir.

Pod'lar Kubernetes’te en temel dağıtım birimleri olduğundan, farklı kullanım senaryolarında oldukça faydalıdır. Pod’lar, uygulamaların dağıtımı ve yönetimi için esnek bir yapı sunar. İşte Pod'ların kullanım senaryolarına dair örnekler:

1. Tek Konteynerli Uygulamalar

• Senaryo:

  • Basit bir mikroservis veya tek bir uygulama bileşeni çalıştırmak için kullanılan senaryolardır.

• Açıklama:

  • Kubernetes, genellikle çok konteynerli pod’lar kullanılsa da, tek konteynerli pod’lar da kullanılabilir. Tek bir uygulama veya servis, pod içinde bir konteyner olarak çalışabilir.

  • Örneğin, bir web sunucusu veya bir veritabanı tek başına bir pod içinde çalıştırılabilir.

• Örnek: Bir API sunucusunun bir pod içinde sadece bir konteyner olarak çalışması.

2. Çok Konteynerli Pod’lar (Sidecar Pattern)

• Senaryo:

  • Bir ana konteyner ve ona bağlı destekleyici hizmetleri çalıştırmak için kullanılan senaryodur.

• Açıklama:

  • Sidecar tasarımı, bir ana konteynerle birlikte çalışan yardımcı konteynerleri ifade eder. Sidecar, ana konteynerin yanında çalışarak ona yardımcı olacak görevleri yerine getirir.

  • Örneğin, bir web uygulaması konteyneri ve ona bağlı bir log toplama veya proxy konteyneri aynı pod içinde yer alabilir.

• Örnek: Web uygulaması konteyneri ile ona bağlı log toplama işlemini yapan bir konteyner aynı pod içinde çalışabilir.

3. Veritabanı ve Web Uygulaması Entegrasyonu

• Senaryo:

  • Bir web uygulaması ve veritabanı arasındaki sıkı entegrasyonu sağlamak amacıyla aynı pod’da çalışan konteynerlerdir.

• Açıklama:

  • Web uygulaması konteyneri ile veritabanı konteyneri, aynı pod içinde yer alarak hızlı ve güvenli bir şekilde veri alışverişi yapabilir.

  • Bu senaryoda, her iki konteyner de aynı IP adresini paylaşır, bu da onları birbirleriyle iletişimde tutar.

• Örnek: Bir web sunucusu ve ona bağlı MySQL veritabanı aynı pod içinde çalıştırılabilir.

4. Uygulama ve Ön Bellek (Caching) Sistemleri

• Senaryo:

  • Bir uygulama ile önbellek sistemi (cache) arasındaki hızlı veri paylaşımı için aynı pod içinde çalışan konteynerler.

• Açıklama:

  • Uygulama ve önbellek (cache) gibi yüksek hızda veri erişimi gerektiren bileşenler, aynı pod içinde çalıştırılarak hızlı ve düşük gecikmeli veri iletişimi sağlanabilir.

  • Redis veya Memcached gibi önbellek sistemleri, uygulama ile aynı pod içinde bulunabilir.

• Örnek: Bir web uygulaması ile ona bağlı Redis önbelleği aynı pod içinde yer alabilir.

5. Yüksek Erişilebilirlik ve Replikasyon

• Senaryo:

  • Uygulamanın yüksek erişilebilirliğini sağlamak amacıyla birden fazla pod’un aynı işlevi gerçekleştirdiği senaryolardır.

• Açıklama:

  • Kubernetes, pod’ları ReplicaSet veya Deployment gibi bileşenler kullanarak yönetir. Bu sayede, bir pod başarısız olduğunda, yeni pod’lar otomatik olarak oluşturulur.

  • Aynı işlevi gerçekleştiren birden fazla pod, kullanıcılara kesintisiz hizmet sunar.

• Örnek: Bir web sunucusu uygulaması, yüksek erişilebilirlik için birden fazla pod üzerinden çalıştırılabilir.

6. DaemonSet ile Dağıtım

• Senaryo:

  • Küme üzerindeki tüm node’larda aynı işlemi gerçekleştiren bir uygulama için kullanılan senaryodur.

• Açıklama:

  • DaemonSet kullanarak, belirli bir uygulama veya hizmet, kümeye eklenen her node üzerinde bir pod olarak çalıştırılabilir.

  • Örneğin, bir log toplama servisi veya monitoring agent (izleme aracı) küme üzerindeki her node’da bir pod olarak çalıştırılabilir.

• Örnek: Prometheus veya Fluentd gibi izleme ve log toplama araçları, her node üzerinde çalıştırılacak şekilde yapılandırılabilir.

7. Geçici İşlemler (Batch Jobs)

• Senaryo:

  • Arka planda çalışan, belirli bir görevi yerine getiren ve tamamlandıktan sonra sonlandırılan pod’lar.

• Açıklama:

  • Pod’lar, arka planda belirli bir görevi (batch job) yerine getirebilir ve işlemi tamamladıktan sonra sonlandırılabilir.

  • CronJobs kullanılarak zamanlanmış görevler veya batch işlemleri yönetilebilir.

• Örnek: Her gün belirli bir saatte veri yedekleme işlemi yapan bir pod.

8. CI/CD Pipelines (Sürekli Entegrasyon/Sürekli Dağıtım)

• Senaryo:

  • Sürekli entegrasyon ve sürekli dağıtım (CI/CD) süreçlerinde kullanılan pod’lar.

• Açıklama:

  • CI/CD süreçlerinde, build ve test işlemleri belirli pod’lar içinde çalıştırılabilir. Bu pod’lar, uygulama geliştirme sürecini otomatikleştirmek için kullanılır.

  • Jenkins, GitLab CI veya Tekton gibi araçlar, CI/CD pipeline’larını yönetmek için Kubernetes üzerinde pod’lar oluşturabilir.

• Örnek: Bir CI/CD pipeline’ı, bir pod içinde uygulama derlemesi ve testleri gerçekleştirebilir.

9. Ağ Geçidi ve Proxy (Ingress)

• Senaryo:

  • Pod, dış dünyadan gelen talepleri yönlendiren bir proxy veya ağ geçidi olarak çalışabilir.

• Açıklama:

  • Ingress Controller veya API Gateway, pod içinde çalışan bir proxy veya yönlendirici işlevi görebilir. Dış dünyadan gelen talepler, ilgili servislere yönlendirilir.

  • Bu yapı, mikroservis tabanlı mimarilerde yönlendirme ve erişim yönetimini sağlar.

• Örnek: NGINX veya Traefik gibi proxy’ler, Kubernetes üzerinde çalışan pod’lar aracılığıyla yönlendirme işlemleri yapabilir.

10. Stateful Uygulamalar

• Senaryo:

  • Veritabanları veya dosya sistemleri gibi durum bilgisi tutan uygulamalar.

• Açıklama:

  • Stateful uygulamalar, pod’lar aracılığıyla verilerin tutarlılığı sağlanabilir. Bu uygulamalar, StatefulSet kullanarak yönetilir.

  • PostgreSQL, MongoDB gibi veritabanları veya dosya sistemleri, verinin sürekli ve tutarlı olmasını sağlayan pod’lar içinde çalışabilir.

• Örnek: MySQL veya Cassandra gibi veritabanları, aynı pod içinde çalışacak şekilde yapılandırılabilir.

Kubernetes üzerinde Pod’lar, uygulama konteynerlerinin çalıştığı temel yapı taşlarıdır. Bu rehber, Kubernetes Pod’ları ile uygulamalı bir şekilde çalışmanıza yardımcı olacak adımları ve komutları içeriyor. Hem temel hem de ileri düzey uygulamalarla, Pod yönetimi, yapılandırmaları ve uygulamaları hakkında bilgi sahibi olacaksınız.

1. Kubernetes Pod Nedir?

Bir Pod, bir veya daha fazla konteynerin Kubernetes'te en küçük birimi olarak çalışan gruptur. Pod'lar genellikle bir uygulama konteynerini barındırır, ancak birden fazla konteyner de aynı Pod içinde yer alabilir. Pod’lar, konteynerler için ağ ve depolama kaynakları sunar ve konteynerler arasında aynı ağ içinde iletişim kurulmasını sağlar.

2. Pod Kurulumu: İlk Adımlar

Pod Tanımı ve Yaratılması

İlk olarak, Kubernetes’te bir Pod oluşturmak için bir YAML dosyasına ihtiyacımız var. Bu dosya, pod'u tanımlayan konfigürasyonu içerir.

1. Pod Tanımlaması:

Aşağıdaki gibi basit bir Pod tanımı oluşturun:

apiVersion: v1

kind: Pod

metadata:

  name: my-first-pod

spec:

  containers:

  - name: my-nginx

    image: nginx:latest

    ports:

    - containerPort: 80

Bu dosyayı my-first-pod.yaml olarak kaydedin.

1. Pod'u Uygulama:

Kubernetes'e bu Pod'u eklemek için aşağıdaki komutu kullanın:

kubectl apply -f my-first-pod.yaml

1. Pod Durumunu Kontrol Etme:

Pod’un başarılı bir şekilde oluşturulup oluşturulmadığını görmek için:

kubectl get pods

Eğer Pod'un durumu Running ise, her şey yolunda demektir.

3. Pod’a Giriş Yapmak

Pod içindeki konteynerlere bağlanarak, uygulamanın içindeki işlemleri izlemek veya yönetmek mümkündür.

Pod’a SSH Bağlantısı:

kubectl exec -it my-first-pod -- /bin/bash

Bu komut, my-first-pod pod’una bağlanır ve içindeki konteynerin bash terminaline giriş yapmanızı sağlar.

4. Pod’un Güncellenmesi ve Yeniden Başlatılması

Pod'lar, Kubernetes tarafından sürekli olarak yönetilen kaynaklar olduğundan, belirli değişiklikleri uygulamak için onları güncelleyebiliriz.

Pod Güncellemesi (YAML Dosyası Üzerinden)

Örneğin, pod’daki nginx konteynerinin versiyonunu değiştirmek için YAML dosyasını güncelleyebiliriz.

1. YAML Dosyasını Güncelleme:

nginx:latest imajını nginx:1.19 olarak güncelleyin.

apiVersion: v1

kind: Pod

metadata:

  name: my-first-pod

spec:

  containers:

  - name: my-nginx

    image: nginx:1.19

    ports:

    - containerPort: 80

1. YAML Dosyasını Uygulama:

kubectl apply -f my-first-pod.yaml

1. Pod’un Güncellenip Güncellenmediğini Kontrol Etme:

kubectl get pods

Eğer pod başarılı bir şekilde güncellenmişse, yeni pod versiyonuyla çalıştığınızı görmelisiniz.

5. Pod Silme ve Yeniden Oluşturma

Eğer bir Pod’u silmek ve yeniden oluşturmak isterseniz, aşağıdaki adımları takip edebilirsiniz.

Pod Silme:

kubectl delete pod my-first-pod

Bu komut, my-first-pod adlı Pod’u siler. Ancak, silinen Pod bir "ReplicaSet" veya "Deployment" altında ise, Kubernetes otomatik olarak yeni bir pod oluşturacaktır.

Pod’u Yeniden Oluşturma:

Pod'unuzu yeniden oluşturmak için aynı YAML dosyasını kullanarak yeniden apply edebilirsiniz:

kubectl apply -f my-first-pod.yaml

6. Pod’a Port Yönlendirme

Kubernetes üzerinde bir Pod’un içinde çalışan uygulamayı dışarıdan erişilebilir hale getirmek için port-forwarding kullanılabilir.

Port Forwarding Kullanarak Erişim:

Örneğin, nginx pod’unu dışarıya 8080 portu üzerinden açmak için şu komutu kullanabilirsiniz:

kubectl port-forward pod/my-first-pod 8080:80

Bu komut, yerel makinenizdeki 8080 portunu, Pod içindeki 80 portuna yönlendirir.

7. Pod’lar ile İleri Düzey Yönetim

Pod ReplicaSet Kullanımı:

Bir Pod’un yüksek erişilebilirliğe sahip olmasını sağlamak için, ReplicaSet kullanılır. ReplicaSet, belirli bir sayıda Pod’u otomatik olarak çalıştırmak için kullanılır.

Bir ReplicaSet tanımlaması şu şekilde olabilir:

apiVersion: apps/v1

kind: ReplicaSet

metadata:

  name: nginx-replicaset

spec:

  replicas: 3

  selector:

    matchLabels:

      app: nginx

  template:

    metadata:

      labels:

        app: nginx

    spec:

      containers:

      - name: nginx

        image: nginx:latest

        ports:

        - containerPort: 80

Bu ReplicaSet, 3 Pod’un çalışmasını sağlar. Bunu şu komutla uygulayabilirsiniz:

kubectl apply -f nginx-replicaset.yaml

Pod’u Başka Bir Node’a Taşıma

Bir Pod’u manuel olarak başka bir Node’a taşımanın tek yolu, Pod'u silip yeniden başlatmaktır. Pod bir ReplicaSet veya Deployment altındaysa, Kubernetes otomatik olarak Pod’u başka bir Node’a yerleştirir.

8. Pod Sağlık Kontrolleri (Health Checks)

Kubernetes, Pod’ların durumunu izlerken readiness ve liveness health check’lerini kullanır.

Pod için Liveness ve Readiness Health Check Tanımlama

Pod içindeki uygulamanın sağlıklı olup olmadığını izlemek için aşağıdaki gibi bir sağlık kontrolü ekleyebilirsiniz:

apiVersion: v1

kind: Pod

metadata:

  name: my-pod

spec:

  containers:

  - name: my-nginx

    image: nginx:latest

    ports:

    - containerPort: 80

    livenessProbe:

      httpGet:

        path: /healthz

        port: 80

      initialDelaySeconds: 5

      periodSeconds: 5

    readinessProbe:

      httpGet:

        path: /readiness

        port: 80

      initialDelaySeconds: 3

      periodSeconds: 3

Bu tanımda, Pod içindeki Nginx konteyneri için liveness ve readiness health check’leri yapılır. Liveness Probe, konteynerin hala sağlıklı olup olmadığını, Readiness Probe ise pod’un trafiği kabul etmeye hazır olup olmadığını kontrol eder.

dry-run modu, Kubernetes gibi altyapılarda kaynakları uygulamadan önce doğrulama yapmak için son derece faydalıdır. Gerçek değişiklikler yapılmadan önce kaynaklar hakkında bilgi edinmenizi sağlar, böylece yanlış yapılandırmalar veya hata yapma riskini azaltır. İşte dry-run modunun sağladığı başlıca avantajlar:

1. Hataları Önceden Görme

Dry-run, Kubernetes kaynakları (pod, deployment, servis vb.) oluşturulmadan önce hataların önceden tespit edilmesini sağlar. Özellikle karmaşık YAML dosyalarında veya geniş çaplı değişikliklerde, yanlış yapılandırmaları görmek ve düzeltmek için mükemmel bir araçtır.

Örneğin, yanlış bir etiket, yanlış bir image veya hatalı bir port yapılandırması varsa, bu tür hatalar kaynakları gerçekten oluşturmadan önce görülebilir.

2. Değişikliklerin Etkisini Anlama

Kubernetes kaynakları karmaşık olabilir ve bazen çok sayıda bileşenin etkileşime girdiği durumlar ortaya çıkabilir. Dry-run, kaynakları gerçekten uygulamadan önce bu değişikliklerin Kubernetes cluster'ında nasıl etki yaratacağını görmenizi sağlar.

• Örneğin, bir deployment veya replicaset kaynağını oluşturduğunuzda, dry-run ile bu kaynağın neler yapacağı, yeni pod'ların hangi node'lara yerleşeceği, etkileşimli kaynakların nasıl yapılandırılacağı gibi bilgileri önceden öğrenebilirsiniz.

3. YAML Yapısının Doğrulanması

Dry-run, özellikle YAML dosyasındaki yapılandırmaların doğruluğunu kontrol etmek için kullanışlıdır. Syntax hataları, eksik alanlar, yanlış indentasyonlar gibi sorunlar doğrudan fark edilebilir. Bu, prodüksiyon ortamına zarar vermeden doğru yapılandırma sağlamak adına önemli bir adımdır.

4. Cluster Durumunu Etkilemeden Test Etme

Kubernetes'te yapılan değişiklikler bazen cluster'da geçici veya uzun vadeli etkiler yaratabilir. Özellikle büyük ölçekli ortamlarda, yanlış bir değişiklik tüm sistemin çalışmasını etkileyebilir. Dry-run modu, bu tür testleri cluster'ı etkilemeden yapmanıza imkan tanır.

Bu sayede testler sırasında herhangi bir kaynak ya da altyapı bileşeni zarar görmeden, yalnızca simülasyon üzerinden doğru sonuçlar alınabilir.

5. CI/CD ve Otomasyon Süreçlerinde Kullanım

Continuous Integration (CI) ve Continuous Deployment (CD) süreçlerinde, kod değişikliklerini otomatik olarak Kubernetes'e uygulamadan önce dry-run kullanmak, sistemde yapılacak değişikliklerin doğruluğunu hızlı bir şekilde test etmek için yaygın bir yöntemdir. Bu, otomasyon süreçlerinin güvenli ve hatasız bir şekilde ilerlemesini sağlar.

Örneğin, bir CI/CD pipeline'ı kurduysanız, her güncelleme öncesinde dry-run kullanarak YAML dosyalarının doğru olduğundan emin olabilirsiniz.

6. Ekip Çalışmasında Güvenlik ve Doğrulama

Dry-run, ekiplerin birlikte çalışırken uygulamalardan önce yapılandırmaları doğrulamalarına olanak tanır. Bu, özellikle birden fazla kişinin aynı Kubernetes cluster'ında çalıştığı durumlarda faydalıdır. Yanlış bir yapılandırma ekibin diğer üyelerinin iş akışlarını bozabilir, ancak dry-run ile bu tür sorunlar daha hızlıca fark edilebilir.

7. Sunucu ve İstemci Tarafı Doğrulama

Dry-run'ı, hem istemci tarafında (client) hem de sunucu tarafında (server) kullanabilirsiniz. Sunucu tarafındaki dry-run, Kubernetes API sunucusunun potansiyel hataları kontrol etmesini sağlar. İstemci tarafındaki dry-run ise yalnızca komutun istemci tarafında doğru şekilde çalışıp çalışmadığını simüle eder.

Bu iki farklı doğrulama türü, hem istemci hem de sunucu tarafındaki hataları önceden görmek için güçlü bir yöntemdir.

Özetle Dry-Run Kullanmanın Avantajları:

1. Hata tespiti: Kaynakları uygulamadan önce yapılandırma hatalarını görme.

2. Kaynak etkisinin anlaşılması: Değişikliklerin etkisini anlamak, sistemdeki potansiyel sorunları önceden fark etmek.

3. YAML doğrulaması: YAML dosyasının doğru yapıda olup olmadığını kontrol etmek.

4. Cluster'ı etkilemeden test yapma: Değişiklikleri gerçek cluster üzerinde test etmeden önce simülasyon yapmak.

5. CI/CD süreçlerinde güvenlik: Otomatik testlerle kod değişikliklerini güvenle doğrulamak.

6. Ekip işbirliği: Ekiplerin doğru yapılandırmaları test etmesini sağlamak.

7. İstemci ve sunucu doğrulaması: Hem istemci hem de sunucu tarafında hataların tespit edilmesi.

Node, Kubernetes’te bir çalıştırma birimi olup, bir veya daha fazla pod’un barındırıldığı fiziksel veya sanal bir makinadır. Kubernetes, pod'ları dağıtmak ve yönetmek için birden çok node kullanır. Bir node, Kubernetes kümesinin temel yapı taşlarından biridir ve her node üzerinde çeşitli bileşenler çalışır.

Node’ın Temel Özellikleri

1. Fiziksel veya Sanal Makine

   • Node, bir fiziksel makine (sunucu) ya da bir sanal makine (VM) olabilir. Kubernetes, bu node'ları bir arada kullanarak uygulama dağıtımlarını ve yönetim süreçlerini dağıtık şekilde gerçekleştirir.

2. Pod’ları Barındırma

   • Her node, bir veya birden fazla pod'u çalıştırabilir. Pod'lar, Kubernetes’teki en temel çalışma birimleridir ve her bir pod bir veya birden fazla konteyner içerir.

3. Çeşitli Kubernetes Bileşenleri

   • Her node, bazı önemli Kubernetes bileşenlerine sahiptir. Bu bileşenler, node üzerinde uygulama çalıştırmak ve küme ile iletişim kurmak için gereklidir.

4. Çalışan Düğüm (Worker Node)

   • Worker Node (Çalışan Düğüm), küme içinde uygulama ve servislerin çalıştığı node türüdür. Her node, Kubernetes yönetim düzlemi ile iletişim kurar ve üzerinde çalıştırdığı pod’ların durumlarını izler.

Node’ların İçerdiği Bileşenler

1. Kubelet

   • Kubelet, bir node üzerinde çalışan ve pod’ların yaşam döngüsünü yöneten bir bileşendir. Kubelet, her pod için gerekli konteynerleri başlatır, izler ve sonlandırır. Kubelet, her node’un içindeki pod’ların durumu hakkında Kubernetes yönetim düzlemine (master node) bilgi verir.

2. Kube-Proxy

   • Kube-Proxy, her node üzerinde çalışan bir ağ bileşenidir. Pod’lar arasında ağ trafiğini yönlendirir ve ayrıca dışarıdan gelen isteklerin doğru pod’a ulaşmasını sağlar. Kubernetes servisi aracılığıyla, bu bileşen pod’lar arasındaki bağlantıyı sağlamak için gerekli ağ yapılandırmalarını yapar.

3. Container Runtime

   • Container Runtime (Konteyner Çalıştırıcısı), konteynerleri çalıştıran yazılımdır. Kubernetes, Docker gibi popüler konteyner çalışma ortamlarını kullanabilir, ancak containerd gibi alternatif çalışma ortamları da tercih edilebilir. Container runtime, konteynerleri oluşturur ve yönetir.

Node Türleri

1. Master Node (Kontrol Düzlemi)

   • Master Node, Kubernetes kümesinin merkezi kontrol noktasıdır. Yönetim düzlemi olarak da bilinir. Cluster’in yönetimi, planlaması ve dağıtımı bu node üzerinden yapılır. Master node’da aşağıdaki bileşenler bulunur:

     • API Server: Kullanıcıların ve diğer bileşenlerin küme ile etkileşime girmesini sağlayan arayüzdür.

     • Controller Manager: Kümeyi yöneten, durumu izleyen ve gerekli düzenlemeleri yapan bileşendir.

     • Scheduler: Yeni pod’ları hangi node’a dağıtacağına karar verir.

     • etcd: Kubernetes’in yapılandırma verilerini saklayan dağıtık veritabanıdır.

2. Worker Node (Çalışan Düğümler)

   • Worker Node'lar, uygulama pod’larını çalıştıran düğümlerdir. Kubernetes üzerinde uygulama dağıtımı ve yönetimi için asıl işlevi yerine getirirler. Bir worker node’un temel görevleri, pod’ları çalıştırmak ve bu pod’ların düzgün çalıştığını kontrol etmektir.

Node’ın Çalışma Prensibi

1. Pod ve Container Barındırma

   • Kubernetes, pod’ları dağıtarak uygulamanın her bir bileşenini uygun node’larda çalıştırır. Her node, bir veya birden fazla pod'u çalıştırmak için yeterli kaynağa (CPU, bellek, vb.) sahip olmalıdır. Node’lar, pod’ların çalışması için gerekli olan kaynakları sağlamakla sorumludur.

2. Kubelet İletişimi

   • Kubelet, her node’daki pod’ların yaşam döngüsünü yönetir. Master node ile sürekli iletişim halinde olur ve pod’ların durumunu kontrol eder. Eğer bir pod’un durumu bozulursa, kubelet yeni pod oluşturulmasını sağlar.

3. Kube-Proxy ile Ağ İletişimi

   • Her node, Kube-Proxy bileşenini kullanarak pod’lar arasında ağ bağlantısı sağlar. Kube-Proxy, gelen istekleri doğru pod’a yönlendirir ve dış dünyadan gelen ağ isteklerini doğru pod’lara iletir.

Node Ölçeklendirme

• Otomatik Ölçekleme (Auto-Scaling)

  • Kubernetes, node’ların sayısını dinamik olarak artırabilir veya azaltabilir. Yüksek trafiği karşılamak için yeni node’lar eklemek veya düşük talep durumunda mevcut node’ları kaldırmak mümkündür. Bu, Cluster Autoscaler veya Horizontal Pod Autoscaler gibi araçlarla yapılabilir.

• Kaynak Yönetimi

  • Kubernetes, node’lar üzerindeki kaynakları etkin şekilde yönetir. Örneğin, belirli bir node’da CPU veya bellek kullanım oranı yüksekse, Kubernetes pod’ları başka bir node’a yeniden yerleştirebilir.

Node Durumu ve İzleme

• Node Durumu

  • Node’lar, sağlıklı olup olmadıklarını belirten durum bilgilerini Kubernetes API’sine bildirir. Bir node'un durumu “Ready”, “NotReady” veya “Unknown” olabilir.

• Node İzleme ve Yönetim

  • Kubernetes, node’lar üzerindeki yükü izlemek için Prometheus gibi izleme araçları kullanabilir. Node’un durumunu ve performansını izlemek, olası arızaları tespit etmek ve yüksek erişilebilirlik sağlamak için önemlidir.

Node ve Kubernetes Kümesi

• Küme Yöneticisi (Cluster Manager)

  • Kubernetes yöneticisi, node’ların sağlık durumunu ve kaynak kullanımını izler. Gerekli olduğunda node’lar arasındaki yük dağılımını düzenler. Cluster manager, node'ları izler, kaybolan veya başarısız olan node’ları tespit eder ve bunlar için yeni pod’lar başlatır.

Node’a Erişim

• Kubernetes CLI ve Node Erişimi

  • Kubernetes yöneticisi, node’lara erişim için kubectl komut satırı aracını kullanır. kubectl get nodes komutu, kümeye bağlı node’ları listeler. Ayrıca, kubectl describe node <node-name> komutu ile bir node’un durumu ve özellikleri hakkında detaylı bilgi alınabilir.

Master Node (Kontrol Düzlemi), Kubernetes kümesinin yönetim ve kontrol merkezidir. Küme üzerindeki tüm işlemleri ve pod'ların dağıtımını yöneten, küme yöneticisinin etkileşimde olduğu ana bileşendir. Master Node, Kubernetes kümesinin çalışma düzeyindeki önemli bileşenlerin tamamına sahip olup, tüm node’lar ve pod’larla etkileşimde bulunarak küme üzerinde sorunsuz bir şekilde uygulama yönetimi ve dağıtımı sağlar.

Master Node'un Temel Bileşenleri

Master Node, aşağıdaki temel bileşenleri içerir:

1. API Server (kube-apiserver)

   • API Server, Kubernetes ile etkileşime giren her bileşenin arayüzüdür. Kubernetes’in en önemli bileşenidir ve kullanıcı taleplerini, küme yönetimi işlevlerini ve veri akışını yönetir. API Server, tüm taleplerin doğru bileşenlere yönlendirilmesini sağlar.

   • API Server, RESTful API aracılığıyla çalışan bir arayüz sağlar. Kullanıcılar ve diğer Kubernetes bileşenleri (kubectl komutları, dashboard, uygulama yönetimi) API Server ile etkileşime girer.

   • Küme üzerindeki tüm işlemler (pod oluşturma, silme, güncelleme) API Server üzerinden yapılır.

2. Controller Manager (kube-controller-manager)

   • Controller Manager, Kubernetes kümesindeki farklı denetleyicileri yöneten bir bileşendir. Her denetleyici, küme üzerinde belirli bir işlevi yerine getirir ve mevcut durumu hedeflenen duruma getirmeye çalışır.

   • Örneğin:

     • Node Controller: Node’ların durumunu izler ve node başarısız olduğunda gerekli aksiyonları alır.

     • Replication Controller: Pod sayısını izler ve belirli bir sayıya ulaşmalarını sağlar.

     • Deployment Controller: Yeni pod’ları dağıtmak ve mevcut pod’ları güncellemekle sorumludur.

     • Namespace Controller: Kubernetes namespaces’leri ile ilgili işlemleri yönetir.

   • Controller Manager, küme içinde her bir denetleyici için sürekli olarak mevcut durumu gözlemler ve gerekirse düzeltici işlemler yapar.

3. Scheduler (kube-scheduler)

   • Scheduler, yeni oluşturulan pod’ların hangi node üzerinde çalıştırılacağına karar veren bileşendir. Pod’lar ilk başta herhangi bir node üzerinde çalışmaz ve bu nedenle Scheduler, pod'ları uygun node'lara yerleştirmek için çeşitli faktörleri dikkate alır.

   • Bu faktörler arasında:

     • Node’un kaynak durumu (CPU, bellek vb.)

     • Node üzerinde çalışan mevcut pod’ların durumu

     • Pod’ların gereksinimleri (belirli bir node üzerinde çalışmaları gereken pod’lar)

     • Node etiketleri ve taahhütler (örneğin, belirli bir iş yükü için belirli bir node tipi)

   • Scheduler, optimal kaynak kullanımını sağlamak için kümedeki node’ları izler ve pod’ları uygun node’lara yönlendirir.

4. etcd

   • etcd, Kubernetes’in dağıtık veritabanıdır ve tüm küme yapılandırma bilgilerini, metadata'yı ve durumu saklar. etcd, verilerin tutarlılığını sağlamak için bir "key-value" veritabanı olarak çalışır.

   • Etcd, küme durumu, pod bilgileri, yapılandırmalar ve ayarların merkezi saklanma alanıdır. Kümedeki herhangi bir değişiklik, önce etcd veritabanına yazılır ve bu veritabanı üzerinden tüm sistemin tutarlı bir durumu sağlanır.

   • etcd, yüksek erişilebilirlik sağlamak için genellikle birden fazla kopyaya sahip olacak şekilde dağıtılır.

Master Node’un Rolü ve Önemi

1. Küme Yönetimi

   • Master Node, Kubernetes kümesinin merkezi kontrol noktasını oluşturur. Tüm küme bileşenleri, uygulama dağıtımı, pod yönetimi ve kaynak tahsisi gibi işlemleri Master Node üzerinden yönetir.

2. Uygulama Dağıtımı ve Yöneticisi

   • Master Node, pod’ların ve container’ların dağıtımını yöneten bileşenlere (Scheduler, Controller Manager) sahip olduğundan, uygulamaların doğru bir şekilde yönetilmesi, ölçeklenmesi ve güncellenmesi gibi işlevleri yerine getirir.

3. Veri ve Durum Yönetimi

   • Kubernetes’in etcd veritabanı, tüm küme durumunu saklar. Master Node, bu merkezi veritabanı aracılığıyla küme üzerindeki tüm işlemleri izler ve kontrol eder.

4. Küme Güvenliği ve İzleme

   • Master Node, Kubernetes API’sini ve kontrol düzlemi bileşenlerini güvenli bir şekilde yönetir. Ayrıca, Kubernetes’in Role-Based Access Control (RBAC) özelliği ile kullanıcıların erişim haklarını denetler.

   • Kümeye erişimi denetler ve her kullanıcının ve sistem bileşeninin doğru haklarla işlem yapmasını sağlar.

5. Cluster Health (Küme Sağlığı)

   • Master Node, küme sağlığını izler ve yönetir. Kubelet'ler, pod'lar ve diğer bileşenlerin sağlık durumunu izleyerek herhangi bir sorun oluştuğunda aksiyon alır. Bu, node'ların veya pod'ların düzgün çalışmaması durumunda, Master Node'un müdahale etmesini sağlar.

6. Küme Ölçekleme ve Planlama

   • Master Node, Horizontal Pod Autoscaler gibi özelliklerle pod sayısını artırma veya azaltma kararları alır. Ayrıca, Cluster Autoscaler gibi araçlar kullanılarak yeni node'lar eklenebilir veya mevcut node'lar kaldırılabilir.

Master Node’un Yönetimi

1. Master Node Yedekliliği

   • Kubernetes, yüksek erişilebilirlik için Master Node’un yedekli bir şekilde yapılandırılmasına olanak sağlar. Bu, Master Node’un birden fazla örneğinin kümede çalıştırılması ile gerçekleştirilir. Bu sayede, bir Master Node’un başarısız olması durumunda, diğer node küme yönetimine devam edebilir.

2. Master Node Güncellemeleri

   • Master Node, tüm küme yapılandırmalarını içerdiği için kritik bir bileşendir. Master Node üzerinde yapılan güncellemeler, dikkatli bir şekilde yönetilmelidir. Kubernetes, Rolling Update yöntemleri ile, Master Node ve bileşenleri üzerinde güncellemeleri gerçekleştirebilir.

3. Master Node’a Erişim

   • Kullanıcılar, Master Node ile kubectl komutları, web tabanlı dashboard veya diğer API aracılığıyla etkileşime girer. Master Node, kullanıcıların pod oluşturma, silme, güncelleme gibi işlemleri yapmasını sağlar. Ayrıca, Master Node üzerinden kubectl komutları çalıştırarak, node'lar arasındaki etkileşimleri gözlemleyebilirsiniz.

Worker Node (Çalışan Düğüm), Kubernetes kümesindeki uygulama yüklerinin çalıştırıldığı ve pod'ların gerçek anlamda barındırıldığı düğümlerdir. Master Node, küme yönetimini yaparken, Worker Node’lar bu yönetimi uygulamaya koyar ve pod'ları çalıştırarak uygulama düzeyindeki iş yüklerini yerine getirir. Worker Node’lar, Kubernetes'in temel işlevlerinden olan uygulama dağıtımı ve yönetimi için kritik öneme sahiptir.

Worker Node’un Temel Bileşenleri

Worker Node, aşağıdaki bileşenlerden oluşur:

1. Kubelet

   • Kubelet, Kubernetes’in her Worker Node üzerindeki yönetim aracıdır. Kubelet, Master Node’dan aldığı komutları uygulayarak pod'ları yönetir ve her pod’un durumunu kontrol eder.

   • Kubelet, pod'ları başlatmak, durdurmak ve yönetmek için her zaman çalışır. Ayrıca pod'ların çalıştığından emin olmak için sağlık denetimleri yapar.

   • Kubelet, pod içindeki konteynerlerin durumunu izler, günlükleri toplar ve Master Node'a rapor eder.

   • Kubelet, aynı zamanda PodSpec ve kube-apiserver aracılığıyla konfigürasyonları alır ve pod’ların doğru bir şekilde çalışmasını sağlar.

2. Container Runtime (Kapsayıcı Çalıştırma Ortamı)

   • Container Runtime, Worker Node'da pod'ların içindeki konteynerleri çalıştıran yazılımdır. Kubernetes, farklı container runtime’ları destekler. Bunlar arasında Docker, containerd ve CRI-O gibi popüler seçenekler bulunmaktadır.

   • Container runtime, konteynerlerin başlatılması, durdurulması ve yaşam döngülerinin yönetilmesi gibi işlemleri yapar.

3. Kube Proxy

   • Kube Proxy, her Worker Node’da çalışan ve ağ trafiğini yönlendiren bir bileşendir. Kube Proxy, pod'lar arasındaki ağ iletişimini sağlar.

   • Kubernetes, her pod için bir IP adresi atar. Kube Proxy, bu IP adreslerinin doğru bir şekilde yönlendirilmesini ve dış dünya ile iletişim kurulmasını sağlar.

   • Kube Proxy, aynı zamanda Service nesneleriyle de etkileşime girerek, pod’lara gelen istekleri doğru pod'a yönlendirir. Bu, yük dengelemesi gibi işlevlere de olanak tanır.

4. CNI (Container Network Interface)

   • CNI, Kubernetes’in pod’lar arasında ağ bağlantısı kurmasını sağlayan bir bileşendir. CNI, pod’lar arasında iletişim kurabilmek için ağ altyapısı sağlar.

   • Kubernetes, CNI plugin’leri kullanarak, ağ yapılandırmasını yönetir. Bu sayede, her pod’un kendi IP adresi olması sağlanır ve pod’lar birbirleriyle iletişim kurabilir.

Worker Node’un Rolü ve Önemi

1. Uygulama Yüklerini Çalıştırma

   • Worker Node, kümedeki pod'ları çalıştırır. Pod’lar, uygulama bileşenlerinin container’lar içinde çalıştığı ve birbirleriyle iletişim kurduğu birimlerdir. Master Node, pod'ları Worker Node’lara yerleştirirken, Worker Node bu pod'ları çalıştırır ve onları yönetir.

2. Kaynak Sağlama

   • Worker Node’lar, üzerinde çalışacak pod'lar için gerekli kaynakları (CPU, bellek, disk alanı vb.) sağlar. Pod’lar, bu kaynakları kullanarak uygulama iş yüklerini yerine getirir. Worker Node’lar, kaynak yönetimini doğru bir şekilde yapmak için kubectl komutları ile izlenebilir.

   • Resource Limits (kaynak sınırları) ve Requests (kaynak talepleri), Worker Node üzerinde çalışan pod’ların kaynak kullanımlarını yönetmek için kullanılır.

3. Sağlık ve Durum İzleme

   • Worker Node, kubelet aracılığıyla pod'ların sağlık durumunu izler. Eğer bir pod'un durumu bozulursa veya konteyner ölürse, kubelet bu durumu Master Node'a bildirir ve gerekirse yeniden başlatma işlemi yapılır.

   • Pod'ların sağlıklı olmasını sağlamak için, Kubernetes sağlık kontrolleri (liveness ve readiness probe’ları) kullanır. Worker Node üzerindeki kubelet, bu kontrolleri gerçekleştirir.

4. Pod Ölçeklendirmesi

   • Worker Node’lar, Horizontal Pod Autoscaler (HPA) gibi araçlarla pod sayısının dinamik olarak artırılmasına veya azaltılmasına olanak sağlar. Bu sayede, uygulamanın yüküne göre kaynak kullanımı optimize edilir.

   • Ölçeklendirme sırasında, Master Node, uygun Worker Node’lara yeni pod’lar atar.

5. Ağ Yönlendirmesi ve Yük Dengelemesi

   • Worker Node, kube proxy ile pod'lar arasındaki ağ trafiğini yönlendirir. Eğer bir Service oluşturulmuşsa, kube proxy, bu servise gelen trafiği doğru pod'a yönlendirir. Bu da yük dengelemesi işlemlerini gerçekleştirir.

   • Kube Proxy, ayrıca ClusterIP, NodePort, ve LoadBalancer gibi servis türlerini yöneterek, ağ trafiğini doğru şekilde yönlendirebilir.

6. Güncellemeler ve Dağıtımlar

   • Worker Node’lar, Master Node’un verdiği komutlarla güncellemeleri ve dağıtımları uygular. Örneğin, Deployment objeleri aracılığıyla pod’lar güncellenebilir ve Worker Node, bu güncellemeyi uygulayarak yeni pod'ları başlatabilir.

   • Worker Node’lar, pod’ların güncellenmesi gerektiğinde eski sürümlerini durdurur ve yeni sürümleri çalıştırmaya başlar.

Worker Node’un Yönetimi

1. Node Durumu ve İzleme

   • Worker Node'ların sağlığı ve performansı, kubectl get nodes komutları ile izlenebilir. Bu komut, her node’un durumunu (Ready, NotReady, SchedulingDisabled) gösterir.

   • Node durumunun izlenmesi, küme üzerinde kaynakları etkili bir şekilde yönetmek ve olası sorunları tespit etmek için önemlidir.

2. Node Etiketleme ve Tolerans

   • Worker Node'lar, etiketleme ve tolerans (taints and tolerations) gibi özellikler ile belirli pod’lara atama yapılmasını sağlar. Bu sayede, belirli bir uygulamanın yalnızca belirli bir node üzerinde çalışması sağlanabilir.

   • Etiketler, node’ları gruplamak ve pod’ların bu gruplara yönlendirilmesini sağlamak için kullanılır.

3. Yük Dengeleme

   • Worker Node’lar, yük dengeleme işlemlerinde önemli bir rol oynar. Kubernetes, pod’lar arasındaki trafiği dengelemek için Ingress Controller ve LoadBalancer gibi araçları kullanır. Worker Node, bu dengeleme işlemlerini doğru bir şekilde yönetir.

4. Node Yedekliliği ve Ölçekleme

   • Kubernetes, worker node’ların yedekliliğini sağlamak için birden fazla Worker Node kullanabilir. Bu sayede, bir Worker Node arızalandığında diğer node'lar devreye girer ve hizmet kesintisi engellenir.

   • Ayrıca, küme gereksinimlerine göre yeni Worker Node’lar eklenebilir veya mevcut node’lar kaldırılabilir.

Kubernetes'teki Node'lar, uygulama yüklerini çalıştıran ve küme içerisindeki işlemlerin yapılmasını sağlayan temel birimlerdir. Her bir Node, kendi başına bir sunucu olabilir ve uygulamaların çalıştığı pod'ları barındırır. Kubernetes, bu Node'ları yönetmek ve iş yüklerini verimli bir şekilde dağıtmak için çeşitli bileşenler kullanır. Node'ların çalışma mantığını anlamak, Kubernetes kümesinin nasıl işlediğini kavramak için oldukça önemlidir.

Node'ların Çalışma Mantığı

Kubernetes, her Node üzerinde belirli bileşenler çalıştırır. Bu bileşenler, Node'ların işlevlerini yerine getirmesini sağlar. Bu bileşenler ve Node'ların genel işleyişi, Kubernetes'in yüksek erişilebilirlik, ölçeklenebilirlik ve güvenilirlik özelliklerini sağlar.

1. Node Bileşenleri

Her bir Node, belirli bileşenlerden oluşur:

• Kubelet: Her Node üzerinde çalışan ve Kubernetes ile iletişim kuran bir bileşendir. Kubelet, Master Node'dan gelen komutları yerine getirir ve pod'ların durumunu kontrol eder. Kubelet, her pod’un durumunu izler, sağlıklı olup olmadıklarını kontrol eder ve pod'ların yaşam döngüsünü yönetir.

• Kube Proxy: Her Node’da çalışan ve ağ trafiğini yönlendiren bir bileşendir. Kube Proxy, pod'lar arasındaki iletişimi yönetir ve ağ üzerinden gelen istekleri doğru pod'lara yönlendirir. Kube Proxy ayrıca, Service nesneleri aracılığıyla dış dünyadan gelen trafiği pod'lara yönlendirebilir.

• Container Runtime (Kapsayıcı Çalıştırma Ortamı): Pod’lar içinde konteynerleri çalıştıran yazılımdır. Docker, containerd, ve CRI-O gibi farklı container runtime seçenekleri Kubernetes ile uyumlu çalışabilir. Container runtime, konteynerleri başlatmak, durdurmak ve yönetmek için kullanılır.

• CNI (Container Network Interface): Pod'lar arasındaki ağ bağlantısını yönetir. CNI, her pod’un kendine ait bir IP adresine sahip olmasını ve bu pod'ların birbirleriyle iletişim kurmasını sağlar.

2. Node'un Rolü ve İşleyişi

Node’lar, Kubernetes'in temel işlevlerini yerine getiren birimlerdir. Bu işlevler aşağıdaki gibi sıralanabilir:

a. Pod'ların Çalıştırılması ve Yönetilmesi

Node'lar, pod'ları çalıştırmak için temel işlevleri yerine getirir. Pod’lar, uygulama konteynerlerini çalıştıran en küçük birimlerdir ve bir veya birden fazla konteyneri içerir. Kubernetes, her pod’u doğru Node'a yerleştirmek için Scheduler bileşenini kullanır. Bu, uygulama yüklerinin doğru Node üzerinde çalışmasını sağlar.

• Pod Yeri Seçimi: Master Node, her pod’un hangi Node’da çalışacağını belirlemek için Kube Scheduler kullanır. Scheduler, Node'ların kaynak kullanımına, etiketlerine, toleranslarına ve diğer faktörlere göre karar verir. Eğer bir Node fazla yük altındaysa veya yeterli kaynak yoksa, Scheduler başka bir Node’a pod yerleştirmeyi tercih eder.

b. Ağ Trafiği Yönetimi

Node'lar, ağ trafiğinin doğru bir şekilde yönlendirilmesinde önemli bir rol oynar. Her Node, kube proxy aracılığıyla gelen ağ trafiğini pod'lara yönlendirir. Kubernetes Service nesneleri, pod'lara gelen dış trafiği doğru şekilde dağıtmak için kullanılır. Kube Proxy, bu servislerin trafiğini yönlendiren bir aracı olarak çalışır.

• Pod'lar Arası İletişim: Kube Proxy, her pod’un IP adresini doğru şekilde yönlendirir, böylece bir pod diğer pod’a ağ üzerinden erişebilir. Ayrıca, Network Policies ile güvenlik duvarı kuralları tanımlanarak pod'lar arasında trafiği kontrol edebilir.

c. Kaynak Yönetimi ve Takibi

Node'lar, üzerinde çalıştırdığı pod’lar için gerekli kaynakları (CPU, bellek, disk alanı vb.) sağlar. Kubernetes, bu kaynakları verimli bir şekilde yönetmek için Resource Requests ve Resource Limits kullanır.

• Kaynak Dağıtımı: Bir pod, Node üzerinde başlatıldığında, belirli bir miktar CPU ve bellek kaynağı talep edebilir. Kubernetes, bu talepleri yönetir ve kaynakların eşit bir şekilde dağıtılmasını sağlar. Bu kaynak talepleri ve sınırları, pod’ların sağlıklı bir şekilde çalışabilmesi için önemlidir.

• Kaynak İzleme: Kubernetes, her pod’un kullandığı kaynakları izler ve gerektiğinde pod’ları yeniden yerleştirebilir veya pod’lar arasında kaynakları yeniden dağıtabilir.

d. Sağlık Kontrolleri ve Durum İzleme

Her Node, üzerinde çalışan pod’ların sağlığını izler. Kubelet, pod’ların sağlık durumlarını kontrol eden ve durumu izleyen bir bileşendir. Kubernetes, pod'ların düzgün çalışıp çalışmadığını izlemek için Liveness Probes ve Readiness Probes kullanır.

• Liveness Probe: Pod’un çalışmaya devam edip etmediğini kontrol eder. Eğer pod’un sağlığı bozulmuşsa, kubelet pod’u yeniden başlatır.

• Readiness Probe: Pod’un dış dünyaya hizmet verip vermediğini kontrol eder. Pod bir hizmeti sunmaya başlamadan önce bu kontrol yapılır ve sadece geçerli olduğunda istek alır.

e. Pod Yeniden Başlatma ve Yedekleme

Node'da bir problem meydana geldiğinde (örneğin, pod'un çökmesi veya Node'un arızalanması), Kubernetes, pod'u yeniden başlatma işlemini başlatabilir. Kubelet, bir pod’un durumunu izler ve pod bir şekilde başarısız olduğunda yeniden başlatılmasını sağlar. Ayrıca, pod'lar otomatik olarak farklı Node'lara taşınabilir.

• Pod Yeniden Başlatma: Pod başarısız olduğunda, ReplicaSets ve Deployments kullanılarak, yeni bir pod oluşturulabilir ve eski pod’un yerini alması sağlanabilir. Kubernetes, bu işlemi otomatik olarak yapar.

f. Node İzleme ve Sağlık Durumu

Node'lar, kubelet aracılığıyla izlenebilir. Her bir Node’un durumu, kubectl get nodes komutuyla kontrol edilebilir. Node’lar, “Ready”, “NotReady” gibi durumlar ile gösterilir. Ayrıca, taints ve tolerations kullanılarak belirli pod'ların yalnızca belirli Node'larda çalışması sağlanabilir.

• Node Durumu İzleme: Node’un sağlık durumu ve durumu düzenli olarak izlenir. Eğer bir Node arızalanırsa, Master Node, bu Node’daki pod’ları başka bir Node'a taşır.

g. Node Ölçekleme

Kubernetes, Node'ları ihtiyaca göre ölçeklendirebilir. Eğer bir Node üzerinde yeterli kaynak yoksa, Kubernetes, yeni bir Node eklemeyi tercih edebilir. Ayrıca, Node'lar manuel veya otomatik olarak yük altında daha fazla pod barındıracak şekilde ölçeklenebilir.

• Horizontal Node Scaling (HNS): Kubernetes, yeni Node'lar eklemek veya mevcut Node'ları kaldırmak için otomatik olarak Node'ları ölçeklendirebilir. Bu, küme boyutunu dinamik olarak yönetmek için kullanılır.

Kubernetes üzerinde Node'lar ile çalışmak, doğru kurulum, izleme ve yönetim becerileri gerektirir. Bu rehberde, Node'larla ilgili önemli komutları ve adımları uygulamalı olarak göstereceğiz. Amaç, bir Kubernetes Node’unu tanımak ve üzerinde temel yönetim işlemleri yapmak.

1. Kubernetes Cluster Kurulumu (Docker Desktop üzerinde)

Kubernetes'i Docker Desktop ile kurarak yerel bir geliştirme ortamı oluşturabilirsiniz. Bu, Node’larla çalışmaya başlamadan önce gerekli ortamı hazırlamanız için ilk adımdır.

Docker Desktop Kurulumu

1. Docker Desktop'ı indirip kurun (Docker’ın resmi sitesinden edinebilirsiniz).

2. Kurulumdan sonra, Docker Desktop'ı başlatın ve Kubernetes seçeneğini etkinleştirin.

3. Kubernetes’in başarılı bir şekilde kurulup kurulmadığını kontrol etmek için terminale şu komutu yazın:

   kubectl version --short

   
   

   Bu komut, Kubernetes'in yerel kurulumunu doğrulayacaktır.

2. Kubernetes Cluster'ı Başlatma

Kubernetes’i Docker Desktop üzerinde çalıştırıyorsanız, kubectl komutlarıyla cluster’ı yönetebilirsiniz. Docker Desktop, Kubernetes kümenizi otomatik olarak başlatır.

Cluster Durumunu Kontrol Etme

Kubernetes kümesinin durumunu kontrol etmek için şu komutu kullanın:

kubectl cluster-info

Bu komut, Kubernetes cluster’ınızın temel bilgilerini verir.

3. Node'ları İnceleme

Cluster’daki tüm Node’ları görmek için şu komutu kullanabilirsiniz:

kubectl get nodes

Bu komut, kümedeki her bir Node hakkında bilgi verir (örneğin, Node adı, durum, rol, yaş vb.).

Node Durumunu Görüntüleme

Bir Node’un detaylı bilgilerini görmek için:

kubectl describe node <node-name>

Bu komut, Node'un kaynak kullanım durumu, etiketleri, pod'lar ve diğer sistem detaylarını gösterir.

4. Node’lara Etiket Ekleme

Node etiketleri, kaynakları gruplamak ve pod’ların doğru Node’a yerleştirilmesi için kullanılır. Node’a etiket eklemek için:

kubectl label nodes <node-name> <key>=<value>

Örnek:

kubectl label nodes node-1 environment=production

Bu etiket, node-1’e bir "production" etiketini ekler.

Node Etiketlerini Listeleme

Node’larda tanımlı etiketleri listelemek için:

kubectl get nodes --show-labels

Bu komut, tüm Node’ların etiketlerini gösterir.

5. Pod’ları Node’a Yerleştirme

Node üzerinde bir pod çalıştırmak için Node Affinity kullanabilirsiniz. Pod’ların belirli Node’larda çalışması gerektiğinde, pod’ların yerleşimini kontrol etmek için nodeAffinity özelliğini kullanırız.

Node Affinity Kullanımı

Aşağıdaki gibi bir pod tanımı oluşturun ve Node'a yerleştirilmesi gereken pod'u belirtin:

apiVersion: v1

kind: Pod

metadata:

  name: mypod

spec:

  affinity:

    nodeAffinity:

      requiredDuringSchedulingIgnoredDuringExecution:

        nodeSelectorTerms:

        - matchExpressions:

          - key: environment

            operator: In

            values:

            - production

  containers:

  - name: mycontainer

    image: nginx

Bu tanım, yalnızca "environment=production" etiketi olan Node’lar üzerinde çalışacak bir pod yaratır.

Pod'un Durumunu Kontrol Etme

Pod’un durumunu kontrol etmek için:

kubectl get pods

Pod'un daha detaylı bilgilerini görmek için:

kubectl describe pod <pod-name>

6. Node Durumunu İzleme ve Güncelleme

Kubernetes kümesinde, her Node'un durumu sürekli olarak izlenebilir. Eğer bir Node’da bir sorun oluşursa (örneğin, pod'lar çalışmıyorsa veya kaynaklar tükenmişse), Node’un durumu NotReady olarak değişir.

Node’u Etkin Olmaktan Kaldırma

Bir Node’u kümeden geçici olarak çıkarmak için:

kubectl cordon <node-name>

Bu komut, Node’u yeni pod'lar için "kapanmış" hale getirir ancak mevcut pod'lar çalışmaya devam eder.

Node’u Çıkarmayı İptal Etme

Bir Node’u tekrar kullanıma almak için:

kubectl uncordon <node-name>

Node’u Kümeden Kaldırma

Bir Node’u kümeden kaldırmak için:

kubectl drain <node-name> --ignore-daemonsets

Bu komut, tüm pod’ları başka bir Node’a taşır ve Node’u kümeden çıkarır. DaemonSet'ler bu işlemden etkilenmez.

Node Durumunu İzleme

Node’ların durumlarını ve sağlık kontrollerini izlemek için:

kubectl get nodes -o wide

7. Node'u Yeniden Başlatma

Eğer bir Node’un düzgün çalışmadığını fark ederseniz, Node’u yeniden başlatmak gerekebilir. Bu işlem genellikle aşağıdaki gibi yapılır:

Node’u Yeniden Başlatma

Kubernetes’te Node’u doğrudan yeniden başlatmak için Docker veya VM üzerinde yeniden başlatma işlemini yapmanız gerekebilir.

sudo reboot

Yeniden başlatmanın ardından, Node’un durumunu tekrar kontrol edin:

kubectl get nodes

8. Node Ölçekleme

Kubernetes kümesinde Node sayısını artırmak veya azaltmak mümkündür. Bu işlem için Horizontal Pod Autoscaling veya Cluster Autoscaler kullanılabilir.

Cluster Autoscaler

Kubernetes cluster autoscaler, kümedeki Node sayısını otomatik olarak artırıp azaltan bir bileşendir. Autoscaler, belirli pod’lar çalıştırılacak kaynak olmadığında Node ekler veya pod’lar boşaldığında Node’ları kaldırır.

Kubernetes Service Nedir?

Kubernetes Service, Kubernetes ortamındaki Pod'lar arasında iletişimi sağlamak ve dış dünya ile etkileşim kurmak için kullanılan bir kaynak türüdür. Pod’lar, genellikle geçici (ephemeral) yapılar olup, IP adresleri değişebilir ve yeniden başlatıldıklarında kaybolabilir. Bu nedenle, Pod'lar arasındaki veya dış dünya ile olan iletişimi sürdürülebilir kılmak için Kubernetes Service kullanılır.

Service, belirli bir işlevi yerine getiren bir grup Pod’u tanımlar ve bu Pod’lar için sabit bir erişim noktası sağlar. Service, aynı zamanda yük dengelemesi yaparak, istemcilerin uygulama bileşenlerine doğru şekilde yönlendirilmesini sağlar. Kubernetes’in temel servis türleri arasında ClusterIP, NodePort, LoadBalancer ve ExternalName yer alır.

Kubernetes Service Temel Özellikleri

• Sabir IP ve DNS Adresi: Service, Pod’lar için bir sabit IP adresi ve DNS adı sağlar. Bu sayede, Pod’lar arası iletişimde IP değişimlerinden etkilenmezsiniz.

• Yük Dengeleme: Kubernetes Service, bir grup Pod'a gelen trafiği dengeler ve bu sayede yüksek erişilebilirlik sağlar.

• Protokol Destekleri: Hem TCP hem de UDP gibi ağ protokollerini destekler.

Kubernetes Service Türleri

Kubernetes, farklı kullanım senaryolarına göre farklı servis türleri sunar. Bunlar:

1. ClusterIP (Varsayılan Service Türü)

• ClusterIP, Kubernetes içinde yerel ağda yalnızca erişilebilen bir servistir.

• Dış dünyaya erişim sağlamaz; sadece Kubernetes cluster’ı içinde çalışan uygulamalar arasında iletişimi sağlar.

• Bu servis türü, uygulama bileşenlerinin birbirine bağlanması için ideal olup, yalnızca cluster içindeki Pod’lara erişim sağlar.

Örnek Kullanım: Aşağıdaki YAML dosyası, bir ClusterIP servisi tanımlar.

apiVersion: v1

kind: Service

metadata:

  name: my-service

spec:

  selector:

    app: my-app

  ports:

    - protocol: TCP

      port: 80

      targetPort: 8080

  type: ClusterIP

Bu servis, my-app etiketine sahip Pod’ları hedefler ve 8080 portuna gelen trafiği 80 portuna yönlendirir.

2. NodePort

• NodePort, Kubernetes cluster’ı içindeki her bir node üzerinde, belirli bir port üzerinden dış dünyaya erişim sağlar.

• Dışarıdan, Kubernetes cluster’ındaki herhangi bir node IP adresi ve belirlenen NodePort üzerinden uygulamaya ulaşılabilir.

• Her node, aynı NodePort üzerinden servis ile iletişim kurmaya olanak tanır.

Örnek Kullanım: Aşağıdaki YAML dosyası, bir NodePort servisi tanımlar.

apiVersion: v1

kind: Service

metadata:

  name: my-service

spec:

  selector:

    app: my-app

  ports:

    - protocol: TCP

      port: 80

      targetPort: 8080

      nodePort: 30001

  type: NodePort

Bu örnekte, NodePort servisi 30001 portunu dış dünyaya açar. Bu, her bir node’un 30001 portu üzerinden erişilebilen bir servistir.

3. LoadBalancer

• LoadBalancer, bulut sağlayıcılarıyla entegrasyon gerektiren bir servistir. Genellikle dış trafik için kullanılır ve cloud ortamlarında otomatik olarak bir load balancer oluşturur.

• Bu servis türü, dış dünya ile bağlantıyı yönlendiren ve yük dengelemesi yapan bir IP adresi sağlar.

• Eğer bir bulut ortamında (örneğin AWS veya Google Cloud) çalışıyorsanız, bu tür servis, yük dengeleyicisini otomatik olarak yapılandırarak dış trafiği Kubernetes cluster'ınıza yönlendirir.

Örnek Kullanım: Aşağıdaki YAML dosyası, bir LoadBalancer servisi tanımlar.

apiVersion: v1

kind: Service

metadata:

  name: my-service

spec:

  selector:

    app: my-app

  ports:

    - protocol: TCP

      port: 80

      targetPort: 8080

  type: LoadBalancer

Bu servis türü, bulut sağlayıcınız tarafından bir dış IP adresi tahsis edilmesini ve bu IP adresinin servis trafiğini Kubernetes cluster'ına yönlendirmesini sağlar.

4. ExternalName

• ExternalName servisi, Kubernetes cluster’ındaki uygulamaların dışındaki bir hizmete erişim sağlar.

• Bu servis türü, genellikle dış sistemlere yönlendirme yapmak için kullanılır.

• Kubernetes içinde, dış hizmetlere yönlendirme yaparak DNS çözümlemesi sağlar.

Örnek Kullanım:

apiVersion: v1

kind: Service

metadata:

  name: my-external-service

spec:

  type: ExternalName

  externalName: example.com

Bu servis, example.com adresine yönlendirilen bir dış DNS sorgusu sağlar.

Service Çalışma Prensibi

Kubernetes Service, her zaman bir selector kullanarak ilgili Pod’lara yönlendirme yapar. Selector, Kubernetes'in bir gruptaki Pod'ları tanımlamasına olanak tanır. Bu şekilde, uygulama bileşenlerinin doğru şekilde yönlendirilmesi sağlanır.

Service ve Endpoints

Kubernetes, bir Service ile ilişkili Endpoints kaydeder. Endpoints, bir Service’e yönlendirilen gerçek Pod'ları temsil eder. Pod'lar, belirtilen portlar üzerinden trafiği alır. Kubernetes, Service’e yönlendiren bir IP adresi verir ve bu IP adresi üzerinden Pod’lara trafiği iletmek için Endpoints kullanılır.

Yük Dengeleme

Kubernetes Service, gelen trafiği tüm hedef Pod’lar arasında dengeler. Bu, round-robin yöntemini kullanarak yapılır. Yük dengelemesi, her Pod’a eşit miktarda trafik gönderilmesini sağlar.

Service Kullanım Senaryoları

1. Monolitik Uygulama Mimarisinde Yönlendirme: Kubernetes üzerinde, monolitik uygulamalar arasındaki trafiği yönlendiren bir Service kullanabilirsiniz.

2. Mikroservis Mimarisinde Servisler Arası İletişim: Bir mikroservis uygulamasında, her servisin farklı Pod’lar içinde çalıştığı ve bunlar arasında iletişim kuran bir Service yapılandırması oluşturulabilir.

3. Dış Trafik Yönetimi: NodePort veya LoadBalancer türünde bir Service kullanarak dış dünyadan gelen trafiği Kubernetes cluster’ına yönlendirebilirsiniz.

4. Pod'lar Arası İletişim: Pod'lar arasında sabit bir IP adresi ve DNS adı sağlayarak, birbirleriyle güvenli bir şekilde iletişim kurmalarını sağlayabilirsiniz.

Kubernetes Service Neden Kullanılır?

Kubernetes Service, bir Kubernetes cluster'ındaki Pod'lar arasındaki iletişimi ve dış dünyaya olan erişimi yönetmek için kritik bir bileşendir. Pod’lar genellikle geçici yapılar olup, IP adresleri sürekli değişebilir. Bu durumda, Pod’lar arasında sabit bir iletişim sağlayabilmek için Service kullanmak gereklidir. Service, Kubernetes ekosisteminde yüksek erişilebilirlik, esneklik ve güvenlik gibi temel ihtiyaçları karşılamak için kullanılır.

Aşağıda, Service kullanımının nedenlerini daha ayrıntılı bir şekilde inceleyeceğiz:

1. Dinamik IP Adreslerinin Yönetimi

• Kubernetes'teki Pod'lar geçici ve dinamik yapılardır. Pod’lar her yeniden başlatıldığında veya yeniden dağıtıldığında, IP adresleri değişir. Bu durum, Pod'lar arasında iletişimi zorlaştırabilir.

• Service, bu durumu çözmek için sabit bir IP adresi ve DNS adı sağlar. Bu sayede, uygulama bileşenleri ve diğer hizmetler sabit bir noktadan iletişim kurabilir. Pod’ların IP adresi değişse bile, Service ile sağlanan sabit IP veya DNS adı üzerinden iletişim sürdürülebilir.

2. Yük Dengeleme (Load Balancing)

• Kubernetes, bir grup Pod’a gelen trafiği yük dengeleme yoluyla eşit bir şekilde dağıtır. Bu, gelen trafiğin tüm Pod'lar arasında dengeli bir şekilde paylaşılmasını sağlar ve yüksek erişilebilirlik ile performansı iyileştirir.

• Service, yük dengelemesi sağlar ve dış dünyadan gelen talepleri uygun Pod'lara yönlendirir. Örneğin, bir mikroservis mimarisinde, bir servis adına gelen tüm trafiği ilgili Pod'lara eşit olarak dağıtır.

3. Uygulamalar Arası İletişim

• Kubernetes ortamındaki uygulamalar genellikle mikroservis mimarisi ile geliştirilmiştir ve her mikroservis farklı bir Pod içinde çalışır. Bu Pod'lar arasında dışa bağımlı ya da içsel iletişim için Service kullanılır.

• Service, bir grup Pod’u aynı port üzerinden tek bir erişim noktasıyla temsil eder. Bu, farklı uygulamalar ve mikroservisler arasında iletişimin daha kolay, güvenli ve yönetilebilir olmasını sağlar.

4. Sabit Erişim Noktası Sağlama

• Pod'lar geçici olduğundan ve IP adresleri değişebileceğinden, bu Pod’lara doğrudan erişmek genellikle zordur. Service, her zaman sabit bir erişim noktası sağlar. Böylece dış dünyadan ya da cluster içindeki diğer bileşenlerden Pod’lara erişim kesintisiz bir şekilde sağlanır.

  Örnek: Eğer bir web uygulaması çalıştırıyorsanız, uygulama için bir Service oluşturabilir ve kullanıcıların her zaman aynı URL üzerinden bu uygulamaya erişmesini sağlayabilirsiniz.

5. Yüksek Erişilebilirlik (High Availability)

• Kubernetes cluster’ında birçok Pod olabilir ve bazı Pod'lar başarısız olduğunda, Service bu başarısız Pod’ları otomatik olarak devre dışı bırakır ve trafik sağlıklı Pod’lara yönlendirilir.

• Bu özellik, Kubernetes'i yüksek erişilebilir ve dayanıklı hale getirir. Pod’lar yeniden başlatıldığında ya da ölçeklendirilmiş olduğunda, Service her zaman çalışan Pod’ları hedef alır ve dışarıdan gelen trafiği doğru şekilde yönlendirir.

6. Kolay Yönetim ve Yönlendirme

• Kubernetes Service, yalnızca ağ düzeyinde çalışmakla kalmaz, aynı zamanda içsel yönlendirme ve ağ yapılandırmalarını da basitleştirir.

• Kubernetes Service ile, belirli bir grup Pod’u kolayca tanımlayabilir ve bunlara belirli bir port üzerinden erişim sağlayabilirsiniz. Böylece, mikroservislerinizi yönetmek çok daha basit hale gelir.

7. Dış Dünya ile İletişim

• Kubernetes içinde, dış dünyadan gelen trafiği yönlendirmek için NodePort veya LoadBalancer gibi servis türleri kullanılır.

• Örneğin, LoadBalancer türündeki bir Service, bulut sağlayıcılarıyla entegrasyon sağlayarak bir dış IP adresi tahsis eder ve bu dış IP üzerinden gelen trafiği ilgili Pod’lara yönlendirir. Bu, dış dünyadan gelen trafiği Kubernetes cluster’ına doğru şekilde yönlendirmek için kritik bir özellik sağlar.

8. Güvenlik ve Erişim Kontrolü

• Kubernetes Service, ağ trafiği üzerinde kontrol sağlar. İstemcilerin hangi Pod’lara erişebileceğini belirlemek için NetworkPolicy kullanılarak güvenlik önlemleri alınabilir.

• Ayrıca, Service, genellikle DNS ile bağlantılı olduğundan, güvenlik politikaları ve erişim kontrol listeleri (ACL’ler) üzerinden yönlendirme yapmak mümkündür.

9. Pod’ların Ölçeklenmesi ile Uyumlu Çalışma

• Kubernetes, Pod’ları dinamik olarak ölçeklendirebilir. Örneğin, bir Pod fazla yük altında kalırsa, Kubernetes onu yeniden başlatabilir veya çoğaltabilir.

• Service, Pod’lar arasında bu değişimlere uyum sağlayarak trafiği her zaman doğru Pod’lara yönlendirir. Böylece uygulamanızın doğru şekilde çalışmaya devam etmesi sağlanır.

10. Service Discovery

• Kubernetes, service discovery sağlar. Yani, uygulama bileşenlerinin birbirini bulmasını ve iletişim kurmasını sağlar.

• Her Service, cluster içindeki diğer Pod’lara karşı DNS adı sağlar. Pod’lar ve servisler birbirlerine bu isimle ulaşabilir. Örneğin, my-service.default.svc.cluster.local gibi bir DNS adı kullanılarak Service’e ulaşılabilir.

Kubernetes Service Kullanım Senaryoları

1. Mikroservisler Arası İletişim:

   • Bir mikroservis uygulamasında, her servisin bir Service ile tanımlandığı ve diğer mikroservislerin bu Service üzerinden birbirine bağlandığı senaryolarda kullanılır.

2. Dış Dünya ile Entegre Uygulamalar:

   • Web uygulamaları gibi dış dünyaya açılan uygulamalarda, NodePort veya LoadBalancer türündeki servisler dış erişimi sağlar.

3. Yük Dengelemesi ve Trafik Yönetimi:

   • Kullanıcı trafiğini, pod’lar arasında eşit olarak dağıtarak, daha hızlı ve dengeli bir kullanıcı deneyimi sağlamak için kullanılır.

4. Yüksek Erişilebilirlik ve Failover:

   • Failover (yedeğe geçiş) senaryolarında, başarısız Pod’lar devre dışı bırakılır ve trafik sağlıklı Pod’lara yönlendirilir.

Kubernetes Service Türleri

Kubernetes, farklı iletişim ihtiyaçlarına göre çeşitli Service türleri sunar. Her biri, belirli kullanım senaryolarına göre yapılandırılabilir ve farklı erişim modelleri sunar. Bu türlerin her biri, bir Kubernetes cluster'ında ağ trafiğini yönlendirmek, yük dengelemesi yapmak ve servis keşfi sağlamak için kullanılır. İşte Kubernetes’te en yaygın kullanılan Service türleri:

1. ClusterIP (Varsayılan Service Türü)

ClusterIP, Kubernetes’in varsayılan servis türüdür ve yalnızca cluster içindeki Pod’lar arasında erişim sağlar. Bu tür, dış dünyadan erişim sağlamaz.

Özellikler:

• Cluster içi erişim: ClusterIP, yalnızca cluster içindeki Pod’lar tarafından erişilebilir.

• Sabit IP: ClusterIP türündeki bir Service, Kubernetes içindeki diğer Pod’lar ve hizmetler tarafından sabit bir IP üzerinden erişilebilir.

• DNS adı: Kubernetes, her Service için otomatik olarak bir DNS adı verir. ClusterIP türündeki bir servis, my-service.default.svc.cluster.local gibi bir DNS adıyla erişilebilir.

Kullanım Senaryosu:

• Bu tür, sadece cluster içindeki uygulamalar için, dış dünya ile bağlantı kurmadan bir hizmet sağlayan servisler için idealdir. Örneğin, bir mikroservis grubunun birbirine bağlı olduğu ve dış dünyaya açılmadığı durumlarda kullanılabilir.

Örnek:

apiVersion: v1

kind: Service

metadata:

  name: my-service

spec:

  selector:

    app: my-app

  ports:

    - protocol: TCP

      port: 8080

  type: ClusterIP

2. NodePort

NodePort, cluster dışındaki istemcilerin de Kubernetes cluster’ındaki servislerine erişebilmesini sağlayan bir servis türüdür. Bu türde, bir Node üzerindeki belirli bir port, dış dünyadan gelen trafiği ClusterIP servisine yönlendirir.

Özellikler:

• Dış erişim: NodePort türündeki bir Service, dış dünyadan gelen talepleri Node IP adresi üzerinden belirli bir port ile kabul eder.

• Port aralığı: Kubernetes, NodePort için 30000-32767 arasında bir port aralığı kullanır. Bu aralık içindeki herhangi bir port, dış dünyadan gelen talepler için kullanılabilir.

• Cluster içi ve dışı erişim: Hem cluster içinden hem de dışarıdan erişim sağlanabilir.

Kullanım Senaryosu:

• NodePort, genellikle test ve geliştirme ortamlarında kullanılır. Ancak, yüksek trafiği yöneten ve güvenlik önlemleri gerektiren prodüksiyon ortamlarında genellikle tavsiye edilmez.

Örnek:

apiVersion: v1

kind: Service

metadata:

  name: my-service

spec:

  selector:

    app: my-app

  ports:

    - protocol: TCP

      port: 80

      nodePort: 30001

  type: NodePort

Bu örnekte, NodePort üzerinden 30001 portu dış dünyadan gelen talepleri alır ve bunları ilgili ClusterIP servisine yönlendirir.

3. LoadBalancer

LoadBalancer, bulut ortamlarında kullanılan ve dış dünyadan gelen trafiği bir veya birden fazla Pod’a yönlendiren bir Service türüdür. Bu tür, bulut sağlayıcılarının (AWS, Azure, Google Cloud, vb.) load balancer hizmetlerini kullanarak otomatik olarak dış erişim noktası sağlar.

Özellikler:

• Dış erişim: LoadBalancer türündeki bir Service, dış dünyadan gelen talepleri bir dış IP üzerinden kabul eder.

• Otomatik yük dengeleme: LoadBalancer, gelen trafiği otomatik olarak arka planda çalışan Pod'lara dengeler.

• Bulut ortamı entegrasyonu: Bu tür, bulut sağlayıcıları ile doğrudan entegre çalışır ve bir yük dengeleleyici oluşturur.

Kullanım Senaryosu:

• Üretim ortamlarında, özellikle yüksek erişilebilirlik ve trafik dengelemesi gerektiren durumlarda kullanılır. Genellikle web uygulamaları, API servisleri ve dış dünyaya açık hizmetler için idealdir.

Örnek:

apiVersion: v1

kind: Service

metadata:

  name: my-service

spec:

  selector:

    app: my-app

  ports:

    - protocol: TCP

      port: 80

      targetPort: 8080

  type: LoadBalancer

Bu servis, bulut sağlayıcıları tarafından dış erişim sağlayan bir IP ile erişilebilen bir load balancer oluşturur.

4. ExternalName

ExternalName türündeki servis, dış bir kaynağa (genellikle bir dış DNS kaydı) yönlendirme yapar. Bu servis, Kubernetes cluster dışındaki bir kaynağa (örneğin, bir veritabanı veya başka bir web servisi) yönlendirme sağlamak için kullanılır.

Özellikler:

• Dış DNS adı: ExternalName türü, Kubernetes dışındaki bir DNS kaydına yönlendirme yapar.

• Cluster içi DNS ile entegre: Dış bir kaynağa erişim sağlamak için Kubernetes içindeki DNS çözümleme kullanılabilir.

Kullanım Senaryosu:

• Genellikle dış kaynaklara (örn. harici API’ler veya veritabanları) erişim sağlayan servisler için kullanılır.

Örnek:

apiVersion: v1

kind: Service

metadata:

  name: my-external-service

spec:

  type: ExternalName

  externalName: example.com

Bu servis, example.com adresine yönlendirme yapacak şekilde yapılandırılmıştır.

5. Headless Service

Headless Service, Kubernetes'teki bir servis türüdür ancak bu servis, IP adresi ve DNS adı gibi yönlendirme bilgilerinden faydalanmaz. Genellikle, servis keşfi veya doğrudan Pod’lara yönlendirme için kullanılır.

Özellikler:

• Yönlendirme yok: Headless Service, DNS isteklerine doğrudan Pod’lar üzerinden yanıt verir, bu da genellikle StatefulSet’ler ve servis keşfi için kullanılır.

• DNS sorguları: Her Pod’a doğrudan erişim sağlayabilir ve bu Pod’lara erişim, DNS çözümlemesi aracılığıyla yapılır.

Kullanım Senaryosu:

• StatefulSet kullanarak, her Pod’a doğrudan erişim sağlamak istendiğinde kullanılır. Genellikle veritabanı cluster’ları gibi durum tutan uygulamalarda tercih edilir.

Örnek:

apiVersion: v1

kind: Service

metadata:

  name: my-headless-service

spec:

  clusterIP: None

  selector:

    app: my-app

  ports:

    - protocol: TCP

      port: 8080

Bu örnekte, clusterIP: None ayarı, başlıklı bir servis oluşturur ve her bir Pod’a ayrı ayrı DNS kaydı verir.

Kubernetes Service Type: ClusterIP

Kubernetes'teki ClusterIP servisi, Kubernetes ortamında bir servisin yalnızca cluster içindeki Pod'lar tarafından erişilmesini sağlayan varsayılan servis türüdür. Bu servis türü, dış dünyadan gelen trafiği engeller ve yalnızca Kubernetes cluster'ı içindeki diğer bileşenlerin servise erişebilmesini sağlar.

ClusterIP Servisinin Temel Özellikleri

1. Cluster içi erişim:

   • ClusterIP, dış dünyadan hiçbir erişim sağlamaz. Sadece Kubernetes cluster içindeki uygulamalara, hizmetlere veya Pod’lara erişim imkanı verir.

   • Bu özellik, özellikle güvenlik açısından önemlidir çünkü servis yalnızca iç ağda kullanılabilir.

2. Sabit IP Adresi:

   • ClusterIP türündeki bir servis, Kubernetes cluster'ındaki her bir servise sabit bir IP adresi atanır.

   • Bu IP adresi, servise yönlendirilmek istenen trafiği, doğru Pod’a iletmek için kullanılır.

3. DNS Adı Desteği:

   • Kubernetes, servisler için otomatik olarak bir DNS adı sağlar. ClusterIP servisi de bu DNS adı üzerinden erişilebilir.

   • Servisin DNS adı genellikle servis_adı.namespace.svc.cluster.local şeklinde olur. Bu, Kubernetes cluster’ı içinde DNS çözümlemesi yapılmasını sağlar.

4. Yük Dengeleme:

   • ClusterIP servisi, yük dengeleme (load balancing) işlevi de sunar. Eğer bir servis birden fazla Pod’a yönlendirme yapıyorsa, Kubernetes bu trafiği dengeli bir şekilde dağıtarak her Pod’a iletir.

   • Yük dengelemesi, gelen isteklerin eşit şekilde dağılmasını sağlar, böylece yüksek erişilebilirlik ve performans artışı elde edilir.

ClusterIP Servisinin Kullanım Senaryoları

ClusterIP, yalnızca iç erişim gereksinimi olan servisler için kullanılır. İşte bazı kullanım senaryoları:

1. Mikroservis Mimarileri:

   • Mikroservislerin birbirleriyle iletişim kurduğu durumlarda, bu servisler ClusterIP türüyle yapılandırılabilir.

   • Örneğin, bir mikroservis A, başka bir mikroservis B ile iletişim kurmak istiyorsa, her iki mikroservis de aynı cluster içinde ve birbirine ClusterIP üzerinden erişebilir.

2. Veritabanları ve Depolama Hizmetleri:

   • Veritabanı servisleri ve diğer depolama çözümleri de genellikle yalnızca Kubernetes cluster’ındaki diğer bileşenler tarafından erişilecek şekilde yapılandırılır.

   • Bu tür servisler genellikle ClusterIP olarak tanımlanır çünkü dış dünyadan erişim gerektirmez.

3. İç Hizmetler ve API'ler:

   • Dışa kapalı iç API servisleri veya diğer hizmetler için ClusterIP tercih edilir. Bu tür servisler, yalnızca belirli bir ağ içindeki uygulamalar tarafından erişilebilir.

4. Yalnızca Cluster içi Web Uygulamaları:

   • Web uygulamaları, yalnızca cluster içindeki kullanıcılar için sağlanacaksa, bu uygulamalara erişim ClusterIP üzerinden yapılabilir. Dış dünyaya erişim gerekmiyorsa bu tür bir yapılandırma kullanılır.

ClusterIP Servisinin Yapılandırılması

ClusterIP türündeki bir servisin nasıl oluşturulacağına dair bir örnek YAML dosyası aşağıda verilmiştir:

apiVersion: v1

kind: Service

metadata:

  name: my-clusterip-service

spec:

  selector:

    app: my-app # Servisin hangi Pod'lara yönlendireceği

  ports:

    - protocol: TCP

      port: 8080  # Servisin dinleyeceği port

      targetPort: 80  # Hedef Pod'daki port

  type: ClusterIP  # Service türü

Açıklamalar:

• metadata.name: Servisin adı, bu ad üzerinden erişim sağlanır.

• spec.selector: Servis, belirli bir etiket (label) ile eşleşen Pod'lara yönlendirme yapar.

• spec.ports: Servisin dinlediği portlar ve bu portların Pod'daki hedef portları belirtilir.

• type: ClusterIP: Servisin türünü belirtir, bu durumda sadece cluster içi erişime izin verir.

ClusterIP’nin Avantajları

1. Basit ve Verimli:

   • ClusterIP, Kubernetes ortamında en yaygın kullanılan servis türüdür çünkü basit ve hızlı bir şekilde iç erişim sağlamak için yeterlidir.

   • Yalnızca cluster içindeki servislerin kullanılacağı senaryolarda bu servis türü son derece verimlidir.

2. Güvenlik:

   • Dış dünyadan erişim izni verilmediği için, yalnızca güvenli ve izole bir şekilde çalışan uygulamalar arasında iletişim sağlar.

   • Bu da, özellikle iç hizmetlerin dışarıya açık olmaması gereken durumlarda büyük bir güvenlik avantajı sunar.

3. Yük Dengeleme ve Yüksek Erişilebilirlik:

   • ClusterIP servisi, Kubernetes'in yük dengeleme özelliğini kullanarak gelen trafiği eşit şekilde Pod'lara yönlendirir.

   • Bu, uygulamanın yüksek erişilebilirlik ve hata toleransı sağlamasına yardımcı olur.

4. Otomatik DNS Çözümlemesi:

   • Kubernetes, ClusterIP türündeki servisler için otomatik olarak DNS adları sağlar. Bu, servislerin birbirini bulmasını ve doğrudan IP adresi kullanmadan erişmesini kolaylaştırır.

ClusterIP’nin Sınırlamaları

1. Dış Erişim Sağlamaz:

   • ClusterIP türündeki bir servis, dış dünyadan gelen trafiği kabul etmez. Yalnızca Kubernetes cluster içindeki bileşenlere erişim sağlar. Bu nedenle, dış dünyaya açık bir servis gereksinimi olan uygulamalar için uygun değildir.

2. Fazla Esneklik Sunmaz:

   • ClusterIP, dış erişim gereksinimlerini karşılamadığı için, dış dünyadan erişim sağlamak isteyen uygulamalar için ek yapılandırmalar (örneğin, NodePort veya LoadBalancer) gerekir.

Kubernetes Service Type: NodePort

NodePort servisi, Kubernetes'teki bir diğer servis türüdür ve bir servis için dış erişim sağlamanın bir yoludur. NodePort, servisleri dış dünyaya açan bir türdür ve belirli bir portu kullanarak, Kubernetes cluster’ındaki her bir node üzerinde servise dışarıdan erişim sağlar. Bu, genellikle küçük ve basit Kubernetes ortamlarında veya yerel geliştirme sırasında kullanılır.

NodePort Servisinin Temel Özellikleri

1. Dış Erişim Sağlar:

   • NodePort türündeki servisler, Kubernetes cluster’ı dışındaki istemcilerin, belirli bir IP adresi ve port üzerinden erişebileceği şekilde yapılandırılabilir. Bu, uygulamanın dış dünyaya açılmasını sağlar.

   • Bu servis türü, her bir node üzerinde belirli bir portu açarak dış erişimi mümkün kılar.

2. Dinamik Port Aralığı:

   • NodePort servisleri, genellikle 30000 ile 32767 arasındaki portlar üzerinden çalışır (varsayılan olarak bu aralık kullanılır, ancak Kubernetes yöneticisi tarafından değiştirilebilir).

   • Bu port, Kubernetes node'ları üzerinde servis için belirlenen porttur ve dışarıdan bu port üzerinden servise erişilebilir.

3. Her Node'da Erişim:

   • NodePort, sadece Kubernetes cluster içindeki node’lar üzerinde değil, dışarıdan gelen trafiği tüm node'lar üzerinde aynı port üzerinden alır.

   • Bu, küme içindeki herhangi bir node’un IP adresini kullanarak servise erişim sağlayabilmenizi sağlar.

4. Yük Dengeleme:

   • NodePort servisi, yük dengeleme sağlar. Gelen trafik, servise yönlendirilmeden önce Kubernetes tarafından, belirli bir node’daki Pod’lara otomatik olarak dağıtılır.

   • Birden fazla node olduğunda, her node üzerinde aynı port üzerinden servis çalıştığı için trafiğin dağılımı düzgün şekilde yapılır.

5. Cluster İçindeki DNS:

   • NodePort servisi de tıpkı diğer servis türleri gibi Kubernetes DNS çözümlemesiyle erişilebilir. Bununla birlikte, dışarıdan erişim için node IP adresine ve belirli bir port numarasına ihtiyaç duyulacaktır.

NodePort Servisinin Kullanım Senaryoları

1. Dışa Açık Uygulamalar:

   • Dış dünyaya açılması gereken, fakat basit bir yapılandırmaya sahip olan uygulamalar için NodePort kullanımı yaygındır. Özellikle yerel geliştirme ortamlarında veya küçük Kubernetes kümelerinde dış erişim sağlamak için kullanılır.

2. Hızlı Prototipleme ve Testler:

   • Hızlıca dışa açık servisler oluşturulmak istendiğinde NodePort servisleri tercih edilebilir. Bu, özellikle mikroservis mimarileri veya deneme projeleri için idealdir.

3. Hibrid Bulut ve On-Premise Çözümler:

   • Eğer Kubernetes cluster'ı hem bulut ortamında hem de on-premise ortamında barındırılıyorsa, NodePort servisi kullanılarak farklı ağlardan erişim sağlanabilir. Cluster içindeki herhangi bir node, dış dünya ile iletişimde kullanılabilir.

4. Küçük Projelerde ve Yerel Geliştirme Ortamlarında:

   • Kubernetes'i öğrenmek veya küçük projelerde denemeler yapmak için NodePort, uygun fiyatlı ve basit bir seçenek olabilir. Birçok kişi, yerel geliştiricilerin Kubernetes üzerinde dış erişimi test etmek için bu servisi kullanır.

NodePort Servisinin Yapılandırılması

NodePort türündeki bir servisin nasıl oluşturulacağına dair bir örnek YAML dosyası aşağıda verilmiştir:

apiVersion: v1

kind: Service

metadata:

  name: my-nodeport-service

spec:

  selector:

    app: my-app # Hedef Pod etiketini seçer

  ports:

    - protocol: TCP

      port: 8080  # Cluster içindeki servis portu

      targetPort: 80  # Pod'daki hedef port

      nodePort: 30001  # Dış erişim için kullanılacak port (30000-32767 arasında olmalı)

  type: NodePort  # Servis tipi NodePort

Açıklamalar:

• metadata.name: Servisin adı. Bu ad üzerinden servis cluster içinde erişilebilir.

• spec.selector: Servisin hangi Pod’lara yönlendirme yapacağı belirlenir.

• spec.ports:

  • port: Servisin cluster içinde dinlediği port.

  • targetPort: Pod’daki hedef port.

  • nodePort: Dış erişim için atanacak port numarası. Bu port üzerinden cluster’daki herhangi bir node IP’sine bağlanarak servise erişilebilir.

• type: NodePort: Servisin türünü belirtir. Bu, dış erişimi sağlayan NodePort türüdür.

NodePort Servisinin Avantajları

1. Dış Erişim Sağlama:

   • NodePort servisi, Kubernetes cluster dışındaki kullanıcıların servise erişebilmesini sağlar. Bu, web uygulamaları veya dışa açılacak herhangi bir servis için kullanışlıdır.

2. Yük Dengeleme:

   • Birden fazla node varsa, NodePort trafiği her node üzerinde aynı port üzerinden kabul eder ve pod’lar arasında yük dengelemesi yapar.

3. Basit Yapılandırma:

   • NodePort, hızlı bir şekilde dış erişim sağlamak için basit bir yapılandırma sunar. Diğer servis türlerine göre yapılandırması oldukça basittir ve kullanımı kolaydır.

4. Erişim Kolaylığı:

   • NodePort servisi sayesinde, dış dünyadan tek bir port üzerinden tüm node’lar erişilebilir. Bu da, herhangi bir node’daki servisin, dış dünyadan erişilebilir olmasını sağlar.

NodePort Servisinin Dezavantajları

1. Sınırlı Port Aralığı:

   • NodePort, yalnızca 30000 ile 32767 arasındaki portlarda çalışır. Bu port aralığı sınırlı olduğundan, çok sayıda dış erişim gereksinimi olan servise sahip büyük Kubernetes kümelerinde bu sınırlama problem oluşturabilir.

2. Yönetim Zorluğu:

   • Birden fazla node varsa, her node üzerinde dış erişim sağlayan bir port açıldığı için, büyük ortamlarda port yönetimi karmaşık hale gelebilir. Özellikle port çakışmaları yaşanabilir.

3. Daha Az Güvenlik:

   • NodePort, dış dünyadan doğrudan erişim sağlar. Bu da, dışarıdan gelen trafiği daha az kontrol edilebilir hale getirir ve güvenlik risklerini artırabilir. Bu nedenle daha güvenli bir dış erişim çözümü gerektiren durumlarda kullanılmaz.

Alternatif Servis Türleri

• LoadBalancer: Dış erişim için daha güvenli ve ölçeklenebilir bir çözüm sağlar. Kubernetes tarafından desteklenen bulut ortamlarında kullanılır ve trafik yönlendirmesi için bir dengeleyici sağlar.

• ClusterIP: Yalnızca iç erişim gereksinimi olan servisler için uygundur.

Kubernetes Service Type: LoadBalancer

Kubernetes’te LoadBalancer servisi, dış erişim için kullanılan ve yük dengelemesi sağlayan bir servistir. LoadBalancer, özellikle bulut ortamlarında yaygın olarak kullanılan bir servis türüdür. Bu servis, gelen trafiği birden fazla backend pod’una otomatik olarak yönlendirir, böylece uygulamanın yüksek erişilebilirliğini ve ölçeklenebilirliğini sağlar.

LoadBalancer Servisinin Temel Özellikleri

1. Yük Dengeleme (Load Balancing):

   • LoadBalancer servisi, gelen istekleri küme içindeki birden fazla pod’a yönlendirerek yük dengelemesi yapar. Bu, trafiğin düzgün bir şekilde dağıtılmasını sağlar.

   • Trafik, Kubernetes’in iç yük dengeleme mekanizması veya dışarıdaki donanım/bulut tabanlı yük dengeleyicilerle yönlendirilir.

2. Dış Erişim:

   • LoadBalancer, servisin dış dünyadan erişilebilmesi için kullanılır. Bu servise ait bir IP adresi veya DNS adı, dış dünyadan gelen trafiği kabul edebilir.

   • Bulut sağlayıcıları, LoadBalancer servisi için genellikle bir dış IP adresi sağlar. Bu IP üzerinden servise erişilebilir.

3. Dinamik IP Adresi Atama:

   • LoadBalancer türündeki servis oluşturulduğunda, Kubernetes bir dış IP adresi atar ve bu adres üzerinden uygulama dışarıya açılır.

   • Genellikle bu dış IP adresi, bulut ortamlarında otomatik olarak atanır, ancak bazı ortamlarda manuel olarak da yapılandırılabilir.

4. Kubernetes Yük Dengeleyici Kullanımı:

   • Kubernetes yük dengeleyicisi, dış dünyadan gelen istekleri servis sağlayıcının içinde dağıtır. Bu yük dengeleme, servis türü NodePort, ClusterIP veya başka bir servise yönlendirilmeden önce yapılır.

5. Ölçeklenebilirlik:

   • LoadBalancer servisleri, arka plandaki pod’ların sayısının arttırılması ile kolayca ölçeklendirilebilir. Kubernetes, servis üzerindeki trafiği yeni pod’lara otomatik olarak yönlendirir.

6. Hizmet Sürekliliği (High Availability):

   • Kubernetes, LoadBalancer servisini kullanarak, uygulamaların yüksek erişilebilirliğini sağlar. Eğer bir pod veya node arızalanırsa, yük dengeleme sağlanarak trafik başka bir pod'a yönlendirilir.

LoadBalancer Servisinin Kullanım Senaryoları

1. Üretim Ortamları:

   • Yüksek erişilebilirlik ve kesintisiz hizmet gerektiren üretim ortamlarında LoadBalancer servisi kullanılır. Web uygulamaları, mikroservisler ve çok sayıda kullanıcıya hizmet veren API’ler için LoadBalancer servisi yaygın olarak tercih edilir.

2. Bulut Ortamlarında:

   • Bulut ortamlarında (AWS, Azure, Google Cloud, vs.) LoadBalancer servisi, genellikle bir bulut sağlayıcısının yük dengeleme hizmetini kullanarak dış erişim sağlar. Bu, bulut tabanlı bir uygulamanın internet üzerinden erişilebilir olmasını sağlar.

3. Karmaşık ve Yüksek Trafikli Uygulamalar:

   • Eğer uygulama yüksek trafiği veya küme içindeki pod’ları düzenli olarak ölçeklendirecekse, LoadBalancer servisi trafiği düzgün şekilde yönlendirmek için ideal bir çözümdür.

4. Çok Katmanlı Uygulamalar:

   • Mikroservis mimarileri ve çok katmanlı uygulamalarda, her bir servis türü için LoadBalancer servisi kullanılabilir. Örneğin, frontend ve backend servisleri farklı LoadBalancer servisleri ile dış dünyaya açılabilir.

LoadBalancer Servisinin Yapılandırılması

Aşağıda, LoadBalancer servisi için örnek bir YAML dosyası verilmiştir. Bu dosya, Kubernetes üzerinde bir LoadBalancer servisi oluşturmak için kullanılabilir.

apiVersion: v1

kind: Service

metadata:

  name: my-loadbalancer-service

spec:

  selector:

    app: my-app # Hedef Pod etiketini seçer

  ports:

    - protocol: TCP

      port: 80   # Cluster içindeki servis portu

      targetPort: 8080  # Pod'daki hedef port

  type: LoadBalancer  # Servis tipi LoadBalancer

Açıklamalar:

• metadata.name: Servisin adı. Bu ad üzerinden servis küme içinde erişilebilir.

• spec.selector: Servisin hangi pod'lara yönlendirme yapacağı belirlenir. Burada, app: my-app etiketiyle eşleşen pod’lar hedeflenir.

• spec.ports:

  • port: Servisin Kubernetes cluster’ındaki portu.

  • targetPort: Pod'daki hedef port. Bu, servisin trafiğini yönlendireceği pod’un portudur.

• type: LoadBalancer: Servisin türü. Bu özellik, trafiği dışa yönlendirmek için LoadBalancer kullanıldığını belirtir.

LoadBalancer Servisinin Avantajları

1. Dış Erişim ve Yük Dengeleme:

   • LoadBalancer, dış dünyadan gelen trafiği tek bir IP adresi veya DNS adı üzerinden yönlendirmeyi sağlar. Ayrıca, gelen trafiği birden fazla backend pod’larına yönlendirerek yük dengelemesi sağlar.

2. Yüksek Erişilebilirlik (HA):

   • Uygulama pod’ları arasında yük dengelemesi ve otomatik trafik yönlendirme sağlayarak yüksek erişilebilirlik sunar. Bir pod arızalandığında, trafik otomatik olarak sağlıklı pod’lara yönlendirilir.

3. Bulut Uyumlu:

   • Bulut ortamlarında (AWS, Google Cloud, Azure, vb.), LoadBalancer servisi, bulut sağlayıcısının yük dengeleme hizmetleriyle entegre olabilir. Bu, harici yük dengeleleyicilerin sağladığı faydalardan yararlanmayı mümkün kılar.

4. Otomatik IP Yönetimi:

   • Kubernetes, LoadBalancer servisi için bir dış IP adresi atar. Bu IP adresi üzerinden servise erişim sağlanabilir. Bu süreç otomatik olarak gerçekleştirilir, böylece manuel IP yönetimine gerek kalmaz.

5. Yüksek Ölçeklenebilirlik:

   • Pod sayısı arttıkça, LoadBalancer otomatik olarak trafiği yeni pod'lara yönlendirir. Bu, uygulamanın yükü taşırken yüksek verimlilik sağlar.

LoadBalancer Servisinin Dezavantajları

1. Bulut Bağımlılığı:

   • LoadBalancer servisi genellikle bulut ortamlarında çalışır. Bulut dışı ortamlar veya on-premise (yerel) ortamlar için LoadBalancer servisi genellikle desteklenmez. Eğer bulut altyapısı yoksa, alternatif yük dengeleme çözümleri kullanmak gerekebilir.

2. Maliyet:

   • Bulut sağlayıcıları, LoadBalancer servisini kullandığınızda genellikle ek ücretler talep eder. Bu, maliyetlerin artmasına neden olabilir, özellikle büyük ölçekli uygulamalarda.

3. Yavaş IP Dağıtımı:

   • Dış IP adresi genellikle bulut sağlayıcısı tarafından atanır ve bu süreç birkaç dakika sürebilir. Bu, servisin dış dünyaya açılmadan önce biraz zaman almasına neden olabilir.

Alternatif Servis Türleri

• NodePort: Dış erişim için başka bir seçenektir. Her bir node üzerinden belirli bir port üzerinden erişim sağlanabilir, ancak LoadBalancer kadar ölçeklenebilir değildir.

• ClusterIP: Yalnızca iç erişim gereksinimi olan servisler için kullanılır. Dış dünyadan erişim sağlanmaz.

Kubernetes Service Type: ExternalName

Kubernetes'teki ExternalName servisi, diğer servis türlerinden farklı olarak, dış dünyada bulunan ve DNS üzerinden erişilebilen bir servise yönlendirme sağlar. Bu servis türü, Kubernetes kümesindeki uygulamalardan dış sistemlere veya kaynaklara erişim sağlamak için kullanılır. ExternalName, genellikle Kubernetes dışında, harici bir kaynağa erişim gerektiğinde tercih edilir.

ExternalName Servisinin Temel Özellikleri

1. DNS Tabanlı Yönlendirme:

   • ExternalName servisi, Kubernetes içerisindeki bir servisi doğrudan bir DNS adı üzerinden başka bir dış kaynağa yönlendirir. Bu, Kubernetes kümesindeki pod’ların dış bir servise DNS üzerinden erişmesini sağlar.

   • Örneğin, dış bir web servisi veya veritabanı ile iletişim kurmak için ExternalName servisi kullanılabilir.

2. Dış Kaynağa Erişim:

   • ExternalName, sadece dış sistemlere erişim sağlar. Bu dış sistemler, Kubernetes kümesinin dışında bulunan bir veritabanı, API veya başka bir hizmet olabilir.

   • Kubernetes içindeki pod’lar, bu servisi kullanarak dış hizmetlere doğrudan bağlantı kurabilir.

3. DNS Yeniden Yönlendirme:

   • Kubernetes, ExternalName türündeki servisin belirttiği DNS adını kullanır. Servisin DNS ismi, küme dışındaki hizmete yönlendirilir.

   • Kubernetes, hizmete erişim sağlamak için yönlendirme yapmaz; yalnızca DNS ile çözümleme işlemi yapar.

4. Servis İsimleri:

   • ExternalName servisi, dış hizmetin DNS adı ile eşleşir ve Kubernetes'teki servisin ismiyle de aynı şekilde erişilir. Yani, Kubernetes’teki uygulama bu servise, verdiği isimle erişebilir.

5. Daha Az Yönetim Gereksinimi:

   • ExternalName servisi, küme dışındaki bir servise yönlendirme yaptığı için, Kubernetes kümesinin dışındaki hizmetleri veya uygulamaları entegre etmek için karmaşık yapılandırmalara gerek duymaz.

ExternalName Servisinin Kullanım Senaryoları

1. Dış Veritabanlarına Erişim:

   • Kubernetes içinde çalışan bir uygulama, dış bir veritabanına (örneğin, Amazon RDS, MySQL, PostgreSQL gibi) erişim sağlamak için ExternalName servisi kullanılabilir. Veritabanının DNS adı Kubernetes servisine yönlendirilir.

2. Bulut Servislerine Bağlantı:

   • Bir bulut hizmeti veya API'sine (örneğin, bir API sağlayıcısının hizmeti) bağlantı kurmak gerektiğinde ExternalName servisi kullanılabilir. Bu, dış sistemlere kolayca erişim sağlamayı mümkün kılar.

3. Özelleştirilmiş Hizmetler:

   • Eğer bir uygulama dış bir servise özel bir yapılandırma ile bağlanıyorsa, ExternalName kullanarak bu bağlantı daha esnek hale getirilebilir. Örneğin, aynı DNS adını kullanarak birden fazla ortam (geliştirme, test, üretim) ile entegrasyon yapılabilir.

4. Geçici Servis Bağlantıları:

   • ExternalName, genellikle kısa vadeli, geçici bağlantılar için kullanılır. Eğer Kubernetes içindeki bir uygulamanın yalnızca belirli bir süre dış bir kaynağa bağlanması gerekiyorsa, ExternalName bu tür senaryolar için idealdir.

ExternalName Servisinin Yapılandırılması

Aşağıda, Kubernetes üzerinde ExternalName türünde bir servis oluşturmak için örnek bir YAML dosyası verilmiştir.

apiVersion: v1

kind: Service

metadata:

  name: my-external-service

spec:

  type: ExternalName

  externalName: example.com

Açıklamalar:

• apiVersion: Kubernetes API sürümünü belirtir. Bu örnekte v1 kullanılır.

• kind: Kubernetes nesnesinin türünü belirtir. Burada bir Service (servis) nesnesi oluşturulmaktadır.

• metadata.name: Servisin adıdır. Bu ad üzerinden servis küme içinde erişilebilir.

• spec.type: Servisin türünü belirtir. Burada tür ExternalName olarak ayarlanır.

• spec.externalName: Dış kaynağın DNS adı belirtilir. Kubernetes, bu DNS adını kullanarak dış hizmete yönlendirme yapar.

ExternalName Servisinin Avantajları

1. Basit ve Düşük Maliyetli:

   • ExternalName, karmaşık yapılandırmalar gerektirmediği ve yalnızca DNS yönlendirmesi sağladığı için, diğer servis türlerine göre daha basit ve düşük maliyetli bir çözümdür.

2. Küme Dışındaki Kaynaklara Kolay Erişim:

   • Kubernetes kümesindeki uygulamalar, ExternalName servisi aracılığıyla dış hizmetlere kolayca erişebilirler. Bunun için ek yapılandırmalara gerek yoktur.

3. Minimal Konfigürasyon:

   • Kubernetes’teki diğer servis türlerinden farklı olarak, ExternalName servisi yalnızca DNS yönlendirmesi sağlar. Yani dış kaynaklar ile iletişim kurarken karmaşık servis ağına ihtiyaç duyulmaz.

4. Uygulama Bağımsızlığı:

   • Dış bir kaynağa bağlanırken, Kubernetes’teki uygulama dış kaynakla doğrudan ilişki kurmaz. Bunun yerine, ExternalName kullanarak bu ilişki soyutlanır. Bu, uygulamanın dış değişikliklerden etkilenmemesini sağlar.

5. DNS Tabanlı Yönlendirme:

   • DNS adı üzerinden yönlendirme sağlanması, uygulamaların dış servislere erişimlerini daha güvenilir ve taşınabilir hale getirir. DNS adı, hem Kubernetes içindeki uygulamalara hem de başka sistemlere yönlendirme yapabilen esnek bir yapı sağlar.

ExternalName Servisinin Dezavantajları

1. Sadece DNS Yönlendirmesi:

   • ExternalName servisi yalnızca DNS adı üzerinden yönlendirme sağlar. Bu nedenle, daha karmaşık yönlendirme ve yük dengeleme işlemleri için uygun bir çözüm değildir.

2. Dış Bağımlılık:

   • Eğer dış sistem (DNS kaynağı) çalışmazsa veya yönlendirme hatalıysa, Kubernetes içindeki uygulama bu dış kaynağa erişemez. Bu, uygulamanın dış kaynaklara bağımlı olmasına neden olur.

3. Ölçeklenebilirlik Sorunları:

   • ExternalName servisi, dış bir kaynağa yönelik tek bir DNS adı sağlar. Bu, büyük ölçekli uygulamalar için sınırlı olabilir. Daha fazla trafik veya ölçekleme gereksinimi için alternatif çözümler düşünülmelidir.

Service Type: Headless Service

Kubernetes'teki Service objeleri, bir dizi Pod'a kararlı bir ağ adresi ve erişim yöntemi sağlar. Normal bir Service (ClusterIP gibi) tek bir sanal IP adresi atar ve trafiği bu IP üzerinden seçilen Pod'lara yük dengelemesi yaparak yönlendirir.

Peki Headless Service Nedir?

Headless Service, adından da anlaşılacağı gibi, bir IP adresi atamayan özel bir Service türüdür. Bunun yerine:

• DNS Kayıtları Oluşturur: Headless Service, seçtiği her bir Pod için doğrudan DNS kayıtları oluşturur.

• Yük Dengeleme Yapmaz: Trafik, tek bir sanal IP üzerinden değil, doğrudan Pod'ların kendi IP adreslerine yönlendirilir.

spec.clusterIP: None

Bir Service'i Headless yapmak için, spec bölümünde clusterIP alanını None olarak belirtmeniz yeterlidir.

YAML

apiVersion: v1

kind: Service

metadata:

  name: my-headless-service

spec:

  selector:

    app: my-app

  clusterIP: None

  ports:

    - protocol: TCP

      port: 80

      targetPort: 8080

Ne Zaman Kullanılır?

Headless Service'ler genellikle aşağıdaki senaryolarda faydalıdır:

• Stateful Uygulamalar (örneğin, veritabanları): Her bir veritabanı örneğinin benzersiz bir ağ kimliğine ve doğrudan erişilebilirliğine ihtiyaç duyulduğunda.

• Özel Yük Dengeleme: Uygulamanızın kendi yük dengeleme mekanizmasını uygulamak istediğinizde.

• Keşif (Discovery): Client'ların, servis tarafından yönetilen bireysel Pod'ları doğrudan keşfetmesi gerektiğinde.

• Partitioning ve Sharding: Uygulamanızın veriyi farklı Pod'lara bölerek (sharding) çalıştığı durumlarda, client'ların belirli bir shard'a doğrudan bağlanması gerekebilir.

Avantajları:

• Doğrudan Pod Erişimi: Uygulamaların, servis arkasındaki bireysel Pod'lara doğrudan bağlanmasını sağlar.

• Özelleştirilmiş Kontrol: Yük dengeleme ve bağlantı yönetimi üzerinde daha fazla kontrol imkanı sunar.

Özet:

Headless Service, Kubernetes'te IP adresi atanmayan ve bunun yerine her bir Pod için DNS kayıtları oluşturan bir Service türüdür. Özellikle stateful uygulamalar, özel yük dengeleme ve doğrudan Pod keşfi gibi senaryolarda kullanışlıdır. spec.clusterIP: None tanımı ile kolayca oluşturulabilir.

1. ClusterIP Servisi ile Uygulama Erişimi

Amaç: ClusterIP türündeki servisi kullanarak bir pod'un sadece küme içindeki diğer uygulamalar tarafından erişilmesini sağlayacağız.

Adımlar:

1. Bir Pod oluşturun (nginx örneği):

   apiVersion: v1

   kind: Pod

   metadata:

     name: nginx

   spec:

     containers:

     - name: nginx

       image: nginx:latest

       ports:

       - containerPort: 80

   
   

   Yukarıdaki YAML dosyasını nginx-pod.yaml olarak kaydedin ve oluşturun:

   bash

   KopyalaDüzenlekubectl apply -f nginx-pod.yaml

   
   

2. ClusterIP Servisi Oluşturun: ClusterIP servisi ile nginx pod'una erişimi sadece küme içindeki diğer pod'lar sağlayacak.

   apiVersion: v1

   kind: Service

   metadata:

     name: nginx-service

   spec:

     selector:

       app: nginx

     ports:

       - protocol: TCP

         port: 80

         targetPort: 80

     type: ClusterIP

   
   

   Bu dosyayı nginx-service.yaml olarak kaydedin ve uygulayın:

   kubectl apply -f nginx-service.yaml

   
   

3. ClusterIP Servisi ile Erişimi Test Etme:

   kubectl get svc nginx-service

   
   

   Şimdi, küme içindeki diğer pod’lardan nginx-service servisine DNS üzerinden erişebilirsiniz.

4. Test için başka bir Pod oluşturun:

   apiVersion: v1

   kind: Pod

   metadata:

     name: test-pod

   spec:

     containers:

     - name: busybox

       image: busybox

       command: ["sleep", "3600"]

   
   

   Bu dosyayı test-pod.yaml olarak kaydedin ve oluşturun:

   kubectl apply -f test-pod.yaml

   
   

5. Test Pod’undan nginx servisini erişin:

   kubectl exec -it test-pod -- wget -qO- nginx-service

   
   

2. NodePort Servisi ile Dış Erişim

Amaç: Kubernetes kümesindeki bir uygulamaya dışarıdan erişebilmek için NodePort servis türünü kullanacağız.

Adımlar:

1. nginx Pod’u oluşturun (yeniden): (Eğer önceden oluşturduysanız, bu adımı atlayabilirsiniz)

   apiVersion: v1

   kind: Pod

   metadata:

     name: nginx

   spec:

     containers:

     - name: nginx

       image: nginx:latest

       ports:

       - containerPort: 80

   
   

   kubectl apply -f nginx-pod.yaml

   
   

2. NodePort Servisi Oluşturun:

   apiVersion: v1

   kind: Service

   metadata:

     name: nginx-nodeport

   spec:

     selector:

       app: nginx

     ports:

       - protocol: TCP

         port: 80

         targetPort: 80

         nodePort: 30080

     type: NodePort

   
   

   kubectl apply -f nginx-nodeport.yaml

   
   

3. NodePort Servisini Kontrol Edin:

   kubectl get svc nginx-nodeport

   
   

   Dışarıdan erişim için, kümenizin herhangi bir node'un IP adresini ve nodePort numarasını kullanarak uygulamaya erişebilirsiniz:

   http://<Node_IP>:30080

   
   

3. LoadBalancer Servisi ile Yük Dengeleme

Amaç: LoadBalancer türündeki servisi kullanarak Kubernetes içindeki bir uygulamaya dışarıdan erişim sağlayacak ve yük dengeleme yapacağız.

Adımlar:

1. nginx Pod’u yeniden oluşturun:

   apiVersion: v1

   kind: Pod

   metadata:

     name: nginx

   spec:

     containers:

     - name: nginx

       image: nginx:latest

       ports:

       - containerPort: 80

   
   

   kubectl apply -f nginx-pod.yaml

   
   

2. LoadBalancer Servisini Oluşturun:

   apiVersion: v1

   kind: Service

   metadata:

     name: nginx-loadbalancer

   spec:

     selector:

       app: nginx

     ports:

       - protocol: TCP

         port: 80

         targetPort: 80

     type: LoadBalancer

   
   

   kubectl apply -f nginx-loadbalancer.yaml

   
   

3. LoadBalancer IP Adresini Kontrol Edin: Eğer bir bulut sağlayıcısı (AWS, GCP, Azure vb.) kullanıyorsanız, LoadBalancer otomatik olarak bir dış IP alacaktır:

   kubectl get svc nginx-loadbalancer

   
   

4. Erişim Sağlama: Şimdi dış IP’yi alarak uygulamaya dışarıdan erişebilirsiniz. Eğer IP'yi aldıysanız:

   http://<LoadBalancer_IP>:80

   
   

4. ExternalName Servisi ile Dış Kaynağa Yönlendirme

Amaç: Kubernetes içerisindeki uygulamanın dış dünyadaki bir kaynağa (örneğin, harici bir API) yönlendirilmesini sağlayacağız.

Adımlar:

1. ExternalName Servisini Oluşturun:

   apiVersion: v1

   kind: Service

   metadata:

     name: external-api

   spec:

     type: ExternalName

     externalName: example.com

   
   

   Bu servisi oluşturduktan sonra, example.com adresine yönlendirilmiş olacaktır.

   kubectl apply -f externalname-service.yaml

   
   

2. Servisi Kontrol Edin:

   kubectl get svc external-api

   
   

   Bu, dış dünyadaki kaynağa DNS üzerinden erişiminizi sağlar.

5. Service Discovery ve DNS Kullanımı

Amaç: Kubernetes içindeki servislerin birbirine nasıl DNS adıyla erişebileceğini göreceğiz.

Adımlar:

1. Birden fazla Pod ve Servis oluşturun: Örnek olarak, nginx ve redis pod’larını içeren iki farklı servis oluşturacağız.

2. Nginx Servisini Oluşturun: (Yukarıdaki örneklerden birini tekrar edebilirsiniz.)

3. Redis Servisini Oluşturun: Redis için bir pod oluşturun ve ardından servisi ekleyin.

4. Nginx Servisinden Redis'e Bağlantı Testi: Nginx'in Redis servisine nasıl bağlandığını kontrol edin:

   kubectl exec -it nginx-pod -- wget -qO- redis-service

Deployment Nedir?

Kubernetes'teki Deployment, uygulamalarınızın sürdürülebilirliğini, yönetimini ve ölçeklenmesini sağlamak için kullanılan yüksek seviyeli bir kaynak türüdür. Kubernetes uygulamalarını başlatmak, güncellemek ve yönetmek için kullanılan Deployment, çoğu zaman uygulamanın çalışma yaşam döngüsünü kontrol etmek için kullanılır. Deployment, istenilen sayıda pod'un çalışmasını sağlar, bu pod'ları izler, yeniden başlatır ve günceller.

Kubernetes'teki Deployment'lar, Pod'lar üzerinde yüksek düzeyde kontrol sağlar. Deployment, uygulamanızın pod'larını stateless (durumsuz) bir şekilde yönetir ve otomatik olarak uygulama güncellemeleri ile roll-back işlemleri yapabilir.

Deployment'ın Temel Özellikleri:

1. Otomatik Ölçekleme: Deployment, uygulamanızın çalıştırılacak pod sayısını yönetir. Örneğin, pod'ların sayısını artırmak veya azaltmak için Deployment'ı değiştirebilirsiniz. Kubernetes, pod'ları otomatik olarak başlatır ve durdurur.

2. Güncelleme ve Rollback: Kubernetes Deployment'ları, uygulama güncellemelerini sorunsuz bir şekilde yönetebilir. Uygulamanın yeni sürümünü dağıttığınızda, eski sürüme geri dönmek gerektiğinde roll-back işlemi yapabilirsiniz.

3. Yüksek Erişilebilirlik: Deployment, tüm pod'ların düzgün çalışmasını sağlar. Bir pod arızalanırsa, Kubernetes otomatik olarak başka bir pod başlatır.

4. Replica Set ile Entegrasyon: Deployment, ReplicaSet'leri yönetir. ReplicaSet, belirli bir sayıda pod'un her zaman çalışmasını sağlar. Deployment, ReplicaSet'i yöneterek uygulamanın ölçeklenebilirliğini kontrol eder.

5. Canary ve Blue/Green Güncellemeleri: Deployment, yeni sürümleri dikkatlice dağıtmanızı sağlayacak stratejiler uygulamanıza olanak tanır. Canary veya Blue/Green güncelleme stratejileri ile kademeli bir dağıtım yapabilirsiniz.

6. İzleme ve Güncelleme Stratejileri: Deployment, güncellemelerin doğru bir şekilde yapıldığından emin olmak için Rolling Update veya Recreate gibi farklı stratejilerle yapılandırılabilir. Rolling Update, bir sürümdeki pod'ları yavaşça değiştirirken, Recreate, tüm pod'ları aynı anda değiştirir.

Deployment'ın Yapısı

Bir Deployment nesnesi, genellikle şu bileşenleri içerir:

• Replicas: Uygulamanın kaç pod instance'ına sahip olması gerektiğini belirler. Örneğin, 3 replica isteniyorsa, Kubernetes her zaman 3 pod çalıştırır.

• Pod Template: Deployment, pod'ları tanımlayan bir şablon içerir. Pod şablonu, her pod'un içereceği container'lar ve container'ların yapılandırmalarını belirler.

• Selector: Deployment, hangi pod'ların bu Deployment'a ait olduğunu belirlemek için selector kullanır. Genellikle label selector kullanılır.

• Strategy: Uygulama güncelleme stratejisini belirler. Rolling Update (güncellemeleri kademeli olarak yapar) veya Recreate (tüm pod'ları aynı anda yeniden başlatır) gibi stratejiler seçilebilir.

Deployment'ın Avantajları

1. Yüksek Erişilebilirlik ve Dayanıklılık: Deployment, arızalanan pod'ları otomatik olarak yeniden başlatarak uygulamanızın her zaman çalışır durumda olmasını sağlar.

2. Yükseltme ve Geri Dönüş Kolaylığı: Deployment ile, yeni sürüme geçmek çok daha basittir. Eğer yeni sürümde bir sorun oluşursa, kolayca eski sürüme geri dönebilirsiniz.

3. Kolay Ölçeklenebilirlik: Pod sayısını artırmak veya azaltmak, yalnızca Deployment'ı güncelleyerek yapılabilir. Bu, uygulamanın taleplerine göre dinamik olarak ölçeklenmesini sağlar.

4. Güncelleme ve Rollback Stratejileri: Rolling Update ve Recreate gibi stratejilerle, uygulama kesintisiz güncellenebilir. Ayrıca, sorun oluştuğunda sürüme geri dönmek çok kolaydır.

Deployment'ın Kullanım Senaryoları

• Stateless Uygulamalar: Deployment, özellikle veritabanı gibi durum bilgisini (state) tutmayan uygulamalar için idealdir. Web sunucuları, API servisleri gibi uygulamalar genellikle stateless olur ve Kubernetes'teki Deployment ile kolayca yönetilebilir.

• Uygulama Güncellemeleri ve Rollback: Yeni bir sürüm geldiğinde, eski sürümü kesintisiz bir şekilde yeni sürümle değiştirmek için Rolling Update stratejisi kullanılabilir. Eğer yeni sürümde bir sorun oluşursa, uygulamanın önceki sürümüne hızlıca dönüş yapılabilir.

• Yük Dengeleme ve Yüksek Erişilebilirlik: Deployment, uygulamanızın her zaman çalışır durumda kalmasını sağlar. Bir pod'un arızalanması durumunda, otomatik olarak yeni bir pod başlatılır.

Deployment Kullanarak Uygulama Güncelleme

Rolling Update Stratejisi ile, pod'lar sırayla güncellenir. Bu, uygulamanın kesintisiz çalışmasını sağlar.

Örneğin, bir nginx uygulaması için deployment'ı güncellemek:

1. Deployment Oluşturma:

   apiVersion: apps/v1

   kind: Deployment

   metadata:

     name: nginx-deployment

   spec:

     replicas: 3

     selector:

       matchLabels:

         app: nginx

     template:

       metadata:

         labels:

           app: nginx

       spec:

         containers:

         - name: nginx

           image: nginx:1.14

           ports:

           - containerPort: 80

   
   

   Bu dosyayı nginx-deployment.yaml olarak kaydedin ve uygulayın:

   kubectl apply -f nginx-deployment.yaml

   
   

2. Deployment Güncelleme: Örneğin, nginx'in sürümünü değiştirelim:

   kubectl set image deployment/nginx-deployment nginx=nginx:1.16

   
   

3. Rolling Update'ı İzleyin: Güncellemenin nasıl yapıldığını izlemek için:

   kubectl rollout status deployment/nginx-deployment

   
   

4. Rollback: Güncelleme sonrası sorun oluşursa, eski sürüme geri dönebilirsiniz:

   kubectl rollout undo deployment/nginx-deployment

   
   

Deployment Yönetimi

Deployment'larınızı aşağıdaki komutlarla yönetebilirsiniz:

• Deployment Listesi:

  kubectl get deployments

  
  

• Deployment Bilgisi:

  kubectl describe deployment <deployment-name>

  
  

• Deployment Silme:

  kubectl delete deployment <deployment-name>

Rolling Update: Otomatik Güncelleme

Rolling Update, Kubernetes'teki uygulama güncellemelerinin sorunsuz ve kesintisiz bir şekilde yapılmasını sağlayan bir stratejidir. Bu güncelleme yöntemi, mevcut pod'ların sırasıyla güncellenmesi ve yeni sürümdeki pod'ların birer birer devreye alınmasıyla uygulanır. Bu yaklaşım, kesintisiz hizmet sağlamak amacıyla tasarlanmış olup, kullanıcıların uygulamaya erişimini etkilemeden güncellemeyi gerçekleştirir.

Rolling Update, genellikle Deployment kaynaklarıyla birlikte kullanılır. Bir uygulamanın yeni sürümü yayına alındığında, eski sürümdeki pod'lar kademeli olarak kaldırılır ve yeni sürümdeki pod'lar otomatik olarak devreye girer. Bu süreç sırasında, tüm pod'lar bir anda değişmez; bunun yerine, güncellenen pod sayısı dikkatlice kontrol edilir ve belirli bir sınırda tutulur.

Rolling Update’in Temel Özellikleri

1. Kesintisiz Hizmet: Rolling Update stratejisi, uygulama hizmetlerini sürekli aktif tutmayı sağlar. Eski pod'lar yavaşça güncellenirken, yeni pod'lar çalışmaya başlar ve kullanıcılar uygulamayı kesintisiz kullanabilir.

2. Otomatik Pod Güncelleme: Kubernetes, yeni sürümdeki pod'ları otomatik olarak başlatır ve eski sürümdeki pod'ları kaldırır. Bu süreç, tüm pod'lar güncellenene kadar devam eder.

3. Güncelleme Sırasını Kontrol Etme: Kubernetes, güncelleme sırasında bir seferde yalnızca belirli sayıda pod'u günceller. Bu sayede, güncelleme işlemi sırasında herhangi bir aksaklık olması durumunda sorunlar hızlıca tespit edilebilir.

4. Kademeli Güncellemeler: Rolling Update, bir pod güncellenmeden önce diğer pod’ların çalışmaya devam etmesini sağlar. Bu, özellikle yüksek trafik alan uygulamalarda önemli bir avantajdır.

5. Geri Dönüş (Rollback): Eğer güncelleme sırasında bir problem yaşanırsa, Kubernetes otomatik olarak önceki sürüme dönüş yapabilir. Bu özellik, herhangi bir hata durumunda hızla eski sürüme geçişi sağlar.

Rolling Update Nasıl Çalışır?

Rolling Update, bir uygulamanın güncel sürümünü uygulamaya alırken eski sürümün yerine yeni sürümün yavaşça devreye girmesini sağlar. İşlem şu adımlarla gerçekleştirilir:

1. Başlangıç Durumu: Uygulamanın eski sürümündeki pod'lar çalışırken, Kubernetes bir güncelleme talebi aldığında yeni sürümdeki pod'ları başlatmaya başlar.

2. Yeni Pod’ların Başlatılması: İlk adımda Kubernetes, belirtilen yeni sürümdeki pod'ları başlatır. Yeni pod'lar çalışırken, eski pod'lar hala aktif kalır ve hizmet sunmaya devam eder.

3. Eski Pod’ların Kapatılması: Yeni pod’lar başlatıldıktan sonra, Kubernetes eski sürümdeki pod’ları yavaşça kaldırmaya başlar. Bu, her bir pod’un devreye alınmasından sonra sırasıyla yapılır.

4. Tam Güncelleme: Süreç tamamlandığında, eski sürümdeki pod'lar tamamen kaldırılmış ve tüm pod'lar yeni sürüme geçirilmiş olur. Bu noktada, uygulama tamamen güncellenmiş ve çalışmaya devam etmektedir.

Rolling Update Parametreleri

Rolling Update sırasında güncelleme işleminin nasıl yapılacağına dair bazı parametrelerle detaylı kontrol sağlanabilir:

1. maxSurge: Bu parametre, güncelleme sırasında aynı anda başlatılacak pod sayısını kontrol eder. Varsayılan olarak, bu değer 25% olarak ayarlanmıştır, yani yeni sürümdeki pod’ların sayısı eski sürümdeki pod’ların sayısının %25’ini geçemez. Bu, güncelleme sırasında sistemin kapasitesinin aşılmasını engeller.

   Örnek:

   spec:

     strategy:

       rollingUpdate:

         maxSurge: 1

   
   

2. maxUnavailable: Bu parametre, güncelleme sırasında kaç pod'un kullanılamaz olabileceğini belirtir. Varsayılan değer olarak %25'tir, yani pod'ların %25'inin güncellenirken kullanılabilir olmaması kabul edilir. Bu değeri düşük tutarak, yüksek erişilebilirlik sağlanabilir.

   Örnek:

   spec:

     strategy:

       rollingUpdate:

         maxUnavailable: 1

   
   

3. minReadySeconds: Yeni pod’ların başarılı bir şekilde çalışmaya başlaması ve trafiğe yönlendirilmeden önce geçmesi gereken süreyi belirler. Bu, pod’un tamamen hazır olup olmadığını kontrol etmek için kullanılır.

   Örnek:

   spec:

     minReadySeconds: 30

   
   

Rolling Update ile Güncelleme Örneği

Aşağıda, bir nginx uygulaması için Rolling Update kullanarak nasıl güncelleme yapılacağına dair adımlar verilmiştir.

1. Deployment Tanımlaması: İlk olarak, bir nginx uygulaması için Deployment oluşturuyoruz:

   apiVersion: apps/v1

   kind: Deployment

   metadata:

     name: nginx-deployment

   spec:

     replicas: 3

     selector:

       matchLabels:

         app: nginx

     template:

       metadata:

         labels:

           app: nginx

       spec:

         containers:

         - name: nginx

           image: nginx:1.14

           ports:

           - containerPort: 80

   
   

   Bu YAML dosyasını kaydettikten sonra, aşağıdaki komutla uygulayabiliriz:

   kubectl apply -f nginx-deployment.yaml

   
   

2. Deployment Güncelleme: Yeni bir sürüm için nginx'i güncellemek istiyorsak, aşağıdaki komutla güncellemeyi başlatabiliriz:

   kubectl set image deployment/nginx-deployment nginx=nginx:1.16

   
   

3. Güncellemenin Durumunu Kontrol Etme: Güncellenen Deployment'ın durumunu takip edebiliriz:

   kubectl rollout status deployment/nginx-deployment

   
   

4. Rollback (Geri Dönüş): Eğer güncelleme sırasında bir hata oluşursa ve önceki sürüme geri dönmek isterseniz, aşağıdaki komutla rollback işlemi yapabilirsiniz:

   kubectl rollout undo deployment/nginx-deployment

   
   

Rolling Update ve Güncelleme Stratejileri

Kubernetes'teki Deployment'lar, güncelleme stratejilerini değiştirebilmenizi sağlar. Bu stratejilerden bazıları şunlardır:

1. Rolling Update: Yavaş ve güvenli bir güncelleme sağlar. Uygulamanın kesintisiz çalışmasını sağlar.

2. Recreate: Tüm pod'ları aynı anda kapatır ve yeni pod'ları başlatır. Bu yöntem, genellikle kesinti toleransı olmayan uygulamalar için uygundur.

Güncelleme stratejisini seçmek, uygulamanızın ihtiyaçlarına göre belirlenir. Rolling Update genellikle daha güvenli ve kesintisiz bir güncelleme sağlar.

Yüksek Erişilebilirlik ve Ölçeklenebilirlik: Kubernetes’in Temel Avantajları

Kubernetes, modern uygulama altyapılarının gereksinimlerini karşılamak için tasarlanmış bir platformdur. İki önemli özellik, yüksek erişilebilirlik (high availability, HA) ve ölçeklenebilirlik (scalability), Kubernetes’in öne çıkan özellikleridir. Bu iki özellik, uygulamaların güvenilir, performanslı ve sorunsuz bir şekilde çalışmasını sağlar.

Yüksek Erişilebilirlik (High Availability - HA)

Yüksek erişilebilirlik, bir sistemin veya uygulamanın, kesintilerden bağımsız olarak sürekli çalışabilmesini ifade eder. Yüksek erişilebilirlik, sistemin herhangi bir parçasında meydana gelen arıza durumlarında bile hizmetin devamlılığını sağlamak için gereklidir. Kubernetes, bu yüksek erişilebilirliği desteklemek için bir dizi özellik ve araç sunar.

Kubernetes'te Yüksek Erişilebilirlik Nasıl Sağlanır?

1. Pod ve Node Replikasyonu: Kubernetes, uygulamanızın her bir bileşeninin birden fazla kopyasını (pod) çalıştırarak yüksek erişilebilirlik sağlar. Pod’lar, ReplicaSet aracılığıyla birden fazla örneğe sahip olabilir. Bu sayede, bir pod başarısız olsa bile diğer pod’lar devreye girerek uygulamanın çalışmaya devam etmesini sağlar.

   Örnek:

   apiVersion: apps/v1

   kind: Deployment

   metadata:

     name: my-app

   spec:

     replicas: 3  # Uygulamanın 3 farklı pod'u olacak

     selector:

       matchLabels:

         app: my-app

     template:

       metadata:

         labels:

           app: my-app

       spec:

         containers:

         - name: my-app

           image: my-app-image:v1

   
   

2. Node Tolerans ve Affinity: Kubernetes, pod’ları belirli Node’lara dağıtarak yüksek erişilebilirlik sağlar. Eğer bir node çökerse, Kubernetes otomatik olarak pod’ları başka node’lara taşır ve yeni pod’lar başlatır.

3. Service ve Load Balancer: Kubernetes Service kullanarak, uygulamanıza yönlendirilen trafiği LoadBalancer aracılığıyla birden fazla pod arasında dağıtabilirsiniz. Böylece, yük dengelenir ve uygulamanızın her zaman erişilebilir olması sağlanır.

   • ClusterIP (iç erişim) ve LoadBalancer (dış erişim) gibi service türleri ile trafiğin doğru bir şekilde yönlendirilmesi sağlanır.

4. StatefulSet ve Persistent Volumes: Veritabanları ve diğer kalıcı veriye sahip uygulamalar için StatefulSet kullanılır. StatefulSet, her pod’a benzersiz bir kimlik (örneğin, veri depolama için bir volume) atar ve bu sayede verinin kaybolması engellenir. Kubernetes, pod'ların herhangi birinin başarısız olması durumunda hızlıca geri yükleme yapar.

5. Pod Anti-Affinity ve Affinity: Kubernetes, pod’ların farklı node’larda çalışmasını sağlayarak, node seviyesinde olabilecek arızalar nedeniyle uygulamanın tamamen kesilmesini engeller. Pod affinity ve anti-affinity kuralları, pod’ların uygun node'lara yerleştirilmesi için kullanılır.

Ölçeklenebilirlik (Scalability)

Ölçeklenebilirlik, bir uygulamanın artan kullanıcı sayısı, veri miktarı veya işlem gücü ihtiyacı doğrultusunda daha fazla kaynak kullanarak kapasitesinin artırılmasıdır. Kubernetes, yatay ölçekleme (horizontal scaling) ve dikey ölçekleme (vertical scaling) imkânları sunar.

Kubernetes'te Ölçeklenebilirlik Nasıl Sağlanır?

1. Yatay Ölçekleme (Horizontal Scaling): Kubernetes, uygulama bileşenlerinin sayısını arttırarak, horizontal pod scaling ile yatayda ölçeklenebilir. Bu özellik, yük arttıkça ek pod’ların dinamik bir şekilde devreye girmesini sağlar.

   • Horizontal Pod Autoscaler (HPA): Bu özellik, pod sayısını otomatik olarak artırıp azaltarak uygulamanın kapasitesini dinamik bir şekilde yönetir. Yük arttığında daha fazla pod başlatılır, yük düştüğünde ise gereksiz pod’lar durdurulur.

   Örnek:

   kubectl autoscale deployment my-app --cpu-percent=50 --min=1 --max=10

   
   

   Bu komut, my-app uygulamasının CPU kullanımına göre pod sayısını otomatik olarak ölçeklendirir. CPU kullanımı %50’yi geçerse, pod sayısı artırılır; %50’nin altına düşerse, pod sayısı düşürülür.

2. Dikey Ölçekleme (Vertical Scaling): Dikey ölçekleme, bir pod içindeki container’ın kaynaklarını (CPU, RAM) artırmak anlamına gelir. Kubernetes'te bu kaynaklar, pod tanımında belirtilir. Pod sayısı artırılmadan, her bir pod'un kaynakları (CPU, bellek) artırılarak daha fazla işlem kapasitesi sağlanabilir.

   Örnek:

   resources:

     requests:

       memory: "64Mi"

       cpu: "250m"

     limits:

       memory: "128Mi"

       cpu: "500m"

   
   

   Bu şekilde, pod’un kullanabileceği maksimum bellek ve CPU limiti belirlenebilir. Ancak, yatay ölçekleme genellikle daha yaygın olarak kullanılır çünkü daha esnektir.

3. Cluster Autoscaler: Kubernetes, yalnızca pod’ların sayısını değil, aynı zamanda Node sayısını da otomatik olarak ölçeklendirebilir. Cluster Autoscaler, node’ları ekleyip çıkararak kapasiteyi dinamik olarak artırır. Örneğin, eğer mevcut node’larda pod’lar için yeterli kaynak yoksa, Cluster Autoscaler yeni bir node ekler.

4. Kubernetes API ve Custom Metrics: Kubernetes, yalnızca CPU ve bellek gibi temel metriklere değil, özel metriklere de dayalı olarak ölçekleme yapılmasını sağlar. Kubernetes API üzerinden özel metrikler kullanılarak, yükün ve performansın izlenmesi ve buna göre pod sayısının ayarlanması mümkündür.

Yüksek Erişilebilirlik ve Ölçeklenebilirlik Arasındaki İlişki

Yüksek erişilebilirlik ve ölçeklenebilirlik arasındaki ilişki oldukça önemlidir. Yüksek erişilebilirlik, uygulamanın her durumda çalışmasını sağlarken, ölçeklenebilirlik uygulamanın büyüyen kullanıcı yükünü kaldırabilmesini sağlar.

• Yüksek Erişilebilirlik: Pod’lar, node’lar ve hizmetler arasındaki hata toleransı, uygulamanın kesintisiz çalışmasını sağlar. Eğer bir node veya pod başarısız olursa, Kubernetes başka bir pod veya node başlatarak kesintiyi minimize eder.

• Ölçeklenebilirlik: Yük artışıyla birlikte, Kubernetes'in yatay veya dikey ölçekleme mekanizmaları devreye girerek uygulamanın kapasitesini artırır.

Bir arada kullanıldığında, Kubernetes uygulamanızın yalnızca sürekli ve kesintisiz çalışmasını sağlamakla kalmaz, aynı zamanda büyüyen iş yükünü verimli bir şekilde yönetir.

Geri Alma (Rollback) - Kubernetes'de Uygulama Yönetimi

Geri Alma (Rollback), Kubernetes'teki bir uygulamanın önceki bir sürümüne dönmek için kullanılan bir işlemdir. Bu özellik, bir güncelleme sonrası uygulamanın düzgün çalışmaması, hata vermesi veya beklenen performansı göstermemesi durumlarında oldukça kullanışlıdır. Kubernetes, Deployment nesneleri aracılığıyla uygulama sürümlerinin takibini yapar ve gerektiğinde önceki sürüme dönüş yapabilmek için kolayca geri alma işlemi yapılabilir.

Kubernetes’te geri alma, yalnızca uygulamanın sağlıklı sürümünü korumakla kalmaz, aynı zamanda kullanıcı deneyimini de korur ve kesintilerin minimum seviyeye indirilmesini sağlar.

Rollback Nasıl Çalışır?

Deployment nesnesi, Kubernetes'teki en önemli sürüm yönetim aracıdır. Her güncelleme, Deployment nesnesinin bir ReplicaSet oluşturmasına ve eski ReplicaSet'lerin, yani önceki sürümlerin, kaydını tutmasına olanak tanır. Bu sayede, her yeni güncelleme ile birlikte eski sürümlere dönüş yapmak mümkündür. Kubernetes, her güncellemeyi bir ReplicaSet olarak kaydeder ve bu sayede sistem eski sürüme geri dönebilir.

Rollback İşlemi:

Kubernetes'te geri alma işlemi, genellikle kubectl rollout undo komutu ile yapılır. Bu komut, belirli bir Deployment veya StatefulSet üzerindeki güncellemeleri geri alarak, önceki sürümün aktive edilmesini sağlar.

Rollback İşlemine Genel Bakış:

1. Deployment Nesnesi ve Güncellemeler:

   • Bir uygulamanın yeni sürümü, genellikle bir Deployment nesnesi aracılığıyla uygulanır. Bu güncelleme esnasında, Kubernetes, eski sürümü ve yeni sürümü birbirinden ayırarak izler.

   • ReplicaSet nesneleri, uygulamanın her sürümüne dair bir kaydın tutulmasını sağlar.

2. Rollback İşlemi:

   • Geri alma, genellikle bir uygulamanın sürümü beklenmedik şekilde başarısız olduğunda yapılır.

   • Kubernetes, önceki sürüme geri dönmek için ReplicaSet'leri ve Deployment nesnesini kullanır.

Rollback Komutları:

1. Son Güncellemeye Geri Dönme:

   • Son yapılan güncellemeye geri dönmek için aşağıdaki komut kullanılır:

   kubectl rollout undo deployment <deployment-adı>

   
   

   Bu komut, belirtilen Deployment’ın en son uygulanan sürümüne geri dönmesini sağlar.

2. Özel Bir Sürüm Numarasına Geri Dönme:

   • Kubernetes, her güncellemeyi bir sürüm numarasıyla etiketler. Belirli bir sürüme geri dönmek için --to-revision parametresi kullanılabilir:

   kubectl rollout undo deployment <deployment-adı> --to-revision=<sürüm-numarası>

   
   

   Bu komut, belirtilen sürüm numarasına geri dönmenizi sağlar.

3. Geri Alma Durumunu Görüntüleme:

   • Geri alma işlemi sonrasında, yapılan değişikliklerin durumunu görmek için aşağıdaki komut kullanılabilir:

   kubectl rollout status deployment <deployment-adı>

   
   

   Bu komut, Deployment'ın geçerli durumunu ve son güncellemesinin sonucunu gösterir.

Rollback İle İlgili İleri Düzey Konular

1. Rollback ve Eşzamanlı Güncellemeler:

   • Kubernetes, güncellemeler sırasında, uygulamanın kesintisiz çalışabilmesi için Rolling Update stratejisini kullanır. Bu strateji, yeni sürüm yüklenirken mevcut pod’ların bir kısmını çalışır durumda tutar. Eğer yeni sürümde bir hata oluşursa, Kubernetes, eski sürümü yükleyerek sorunu çözer.

2. Yedeklemeler ve Rollback:

   • Kubernetes, tüm sürüm geçmişini etkin olarak saklar. Bu sayede, herhangi bir sürümün stabil olup olmadığı kolayca test edilebilir ve her durumda önceki sürüme dönülmesi mümkün olur.

   • Ancak, bazı durumlarda persistent storage (kalıcı depolama) veya veritabanı veri yönetimi söz konusu olduğunda, verilerin de yedeklenmesi gerekebilir. Çünkü yalnızca pod’lar geri alındığında, veri kaybı yaşanabilir. Bu tür durumlarda, veritabanı ve kalıcı volume yönetimi daha dikkatli yapılmalıdır.

3. Rollback ve ConfigMap/Secret Yönetimi:

   • Kubernetes’te, uygulama yapılandırmalarını içeren ConfigMap ve Secret nesneleri de güncellenebilir. Eğer bir yapılandırma hatalıysa, kubectl rollout undo komutu, yalnızca pod’ları değil, yapılandırma ayarlarını da geri alabilir.

   • ConfigMap ve Secret’ler için rollback işlemi yapılmadan önce, bu yapıların doğru şekilde güncellenmesi ve sürüm kontrolü yapılmalıdır.

4. Geri Alma Sınırlamaları:

   • Kubernetes, yalnızca pod’ların ve replicaSet’lerin önceki sürümlerine geri dönüş yapmayı sağlar. Ancak, kalıcı depolama çözümleri ve dış kaynaklar (veritabanları, API servisleri) üzerinde geri alma işlemleri Kubernetes tarafından doğrudan yönetilmez. Bu tür verilerin dış sistemlerde de yedeklenmesi ve yönetilmesi gerekir.

   • Geri alma işlemi sırasında, bazı uygulamalara veya veritabanlarına zarar verebilecek veri tutarsızlıkları oluşabilir. Bu nedenle rollback işlemi sırasında dikkatli olunmalı ve uygulamanın bütünsel yapısı göz önünde bulundurulmalıdır.

Rollback Kullanım Senaryoları:

1. Uygulama Hata Yaptığında:

   • Yeni sürümde bir hata meydana geldiğinde, Kubernetes otomatik olarak eski sürüme geçebilir. Örneğin, bir pod'un beklenen şekilde çalışmaması durumunda, geri alma işlemi devreye girer.

2. Kritik Bir Hata Durumunda:

   • Eğer uygulamanın genel işleyişinde bir aksaklık varsa, uygulamanın önceki sürümüne dönmek, hizmetin devamlılığını sağlamak için önemlidir.

3. Test ve Staging Ortamlarında:

   • Üretim ortamına geçmeden önce yapılan testlerde, yeni sürümün başarısız olması durumunda, staging ortamında önceki sürüme geri dönülerek testlerin sürdürülebilirliği sağlanabilir.

Kubernetes Deployment Güncelleme Stratejileri

Kubernetes, uygulamaları yönetmek için esnek ve güçlü bir platform sunar. Bu esneklik, uygulama güncellemelerini sorunsuz bir şekilde gerçekleştirebilmek için bir dizi güncelleme stratejisi sunar. Güncelleme stratejileri, bir uygulamanın yeni sürümünü mevcut sürümle değiştirmek için kullanılan yöntemlerdir. Kubernetes, uygulama güncellemelerini kontrol etmek, geçişi düzgün yapmak ve hizmetin sürekliliğini sağlamak için çeşitli stratejiler uygular.

Bu yazıda, Kubernetes Deployment Güncelleme Stratejilerini detaylı şekilde inceleyeceğiz.

Deployment Güncelleme Stratejilerinin Genel Özellikleri

Kubernetes'teki Deployment nesnesi, bir uygulamanın nasıl ve ne zaman güncelleneceğini yönetir. Bu, aşağıdaki hedeflere ulaşılmasına yardımcı olur:

1. Yüksek Erişilebilirlik: Uygulamanın eski sürümünü çalıştırırken, yeni sürümün devreye alınmasını sağlar.

2. Sürekli Entegrasyon: Yeni sürüm güncellemeleri sırasında hizmet kesintisi yaşanmadan uygulamaların güncellenmesini sağlar.

3. Rollback (Geri Alma): Güncelleme sırasında sorun çıkarsa, hızlı bir şekilde eski sürüme dönülmesini sağlar.

Kubernetes, Rolling Update ve Recreate gibi stratejilerle, güncellemelerin kesintisiz ve güvenli bir şekilde yapılmasını sağlar.

1. Rolling Update Stratejisi

Rolling Update, Kubernetes’in varsayılan güncelleme stratejisidir. Bu strateji, yeni sürümün adım adım devreye alınmasını sağlar. Eski sürümdeki pod’lar birer birer güncellenir ve yenileri eklenir. Bu yöntem, uygulamanın sürekli çalışmasını ve kullanıcıların kesintiye uğramadan hizmet almasını sağlar.

Rolling Update Nasıl Çalışır?

• Yeni Pod’lar: Güncelleme başladığında, yeni sürümdeki pod’lar oluşturulur.

• Eski Pod’lar: Eski sürümdeki pod’lar yavaşça silinir. Yani, tüm pod’lar bir anda kapatılmaz.

• Yavaş İlerleme: Güncelleme, genellikle bir pod güncellenip çalışmaya başladıktan sonra bir sonraki pod’a geçerek yapılır.

• Konfigürasyon: Güncellemeler sırasında ReplicaSet oluşturularak, eski ve yeni sürümler arasında geçiş yapılır.

Rolling Update Avantajları:

• Kesintisiz Hizmet: Uygulama kullanıcıları, güncelleme işlemi sırasında kesintiye uğramaz. Çünkü yeni sürümdeki pod’lar birer birer devreye alınır.

• Hızlı Güncelleme: Kısa sürede güncelleme yapılabilir, çünkü tüm pod’lar aynı anda değiştirilmiyor.

Rolling Update Konfigürasyonu:

Rolling Update'in davranışı, maxSurge (yeni pod’ların fazladan oluşturulabileceği sayıyı) ve maxUnavailable (güncelleme sırasında ne kadar pod’un kullanılmaz olabileceği) parametreleri ile kontrol edilebilir.

Örnek YAML dosyasındaki Rolling Update konfigürasyonu:

spec:

  strategy:

    type: RollingUpdate

    rollingUpdate:

      maxSurge: 1

      maxUnavailable: 1

• maxSurge: Bu parametre, yeni pod’ların bir seferde ne kadar fazladan oluşturulabileceğini belirtir. Bu sayede güncelleme sırasında sistemin kapasitesinin artması sağlanır.

• maxUnavailable: Bu parametre, güncelleme sırasında en fazla kaç pod’un çalışamaz durumda olabileceğini belirtir. Genellikle bu değer 1 olarak ayarlanır, böylece bir pod çalışamazsa diğeri devrede kalır.

2. Recreate Stratejisi

Recreate güncelleme stratejisi, eski pod’ların tamamen silinip yeni pod’ların oluşturulmasını sağlar. Bu strateji, bir defada tüm pod’ları durdurur ve ardından yeni sürümle başlar. Yani, eski ve yeni sürüm aynı anda çalışmaz.

Recreate Nasıl Çalışır?

• Eski Pod’lar Silinir: İlk adımda eski sürümdeki tüm pod’lar silinir.

• Yeni Pod’lar Oluşturulur: Eski pod’lar tamamen silindikten sonra, yeni sürümdeki pod’lar oluşturulur ve başlatılır.

Recreate Avantajları:

• Basit ve Net: Güncelleme işlemine başlamak için eski sürüm tamamen durdurulur, bu da bazı durumlarda daha basit ve net bir yaklaşım olabilir.

• Uygulama İhtiyaçları: Bazı uygulamalar, eski sürüm ile yeni sürüm arasında veri tutarsızlıkları oluşmaması için, tüm pod’ların aynı anda kapatılmasını gerektirebilir.

Recreate Dezavantajları:

• Kesinti Olur: Eski pod’lar silinmeden yeni pod’lar başlatılmadığı için, uygulama bir süre boyunca kesintiye uğrar. Bu, yüksek erişilebilirlik gereksinimlerine sahip uygulamalar için uygun değildir.

Recreate Konfigürasyonu:

Recreate stratejisi, Deployment nesnesinin strategy.type parametresi ile belirlenir:

spec:

  strategy:

    type: Recreate

3. Blue-Green Deployment

Blue-Green Deployment, genellikle üretim ortamlarında kullanılan başka bir güncelleme stratejisidir. Bu strateji, güncelleme işlemi sırasında iki farklı ortam (Blue ve Green) kullanır.

Nasıl Çalışır?

• Blue Ortamı: İlk başta aktif olan sürüm, Blue ortamında çalışır.

• Green Ortamı: Yeni sürüm, Green ortamında hazırlanır.

• Geçiş: Yeni sürüm test edildikten ve doğrulandıktan sonra, trafik Blue ortamından Green ortamına yönlendirilir.

Avantajları:

• Kesintisiz Geçiş: Kullanıcılar yeni sürüme kesintisiz geçiş yapabilirler, çünkü her iki sürüm paralel olarak çalışır.

• Kolay Geri Alma: Eğer yeni sürümde bir problem çıkarsa, kolayca Blue ortamına geri dönülebilir.

Dezavantajları:

• Yüksek Kaynak Kullanımı: Her iki ortamın paralel olarak çalışması, kaynak kullanımı açısından maliyetli olabilir.

4. Canary Deployment

Canary Deployment, yeni sürümü küçük bir kullanıcı grubuna dağıtarak test etmeye olanak tanır. Bu strateji, yeni sürümün yalnızca küçük bir kısmını test etmek için kullanılır ve sorunsuz bir şekilde çalıştığı onaylandığında daha geniş bir dağıtım yapılır.

Nasıl Çalışır?

• Küçük Bir Yüzde: Yeni sürüm önce yalnızca küçük bir kullanıcı yüzdesine dağıtılır.

• Test ve İzleme: Yeni sürüm izlenir, hatalar ve performans sorunları kontrol edilir.

• Bütün Kullanıcılar: Test başarılı olduğunda, yeni sürüm tüm kullanıcılar için devreye alınır.

Avantajları:

• Düşük Risk: Yalnızca küçük bir kullanıcı grubuna dağıtıldığından, yeni sürümdeki hatalar daha az kişiyi etkiler.

• Hızlı Geri Alma: Eğer sorun varsa, yalnızca küçük bir kullanıcı kitlesi etkilenir ve hızlıca geri alınabilir.

Dezavantajları:

• Ekstra Konfigürasyon Gereksinimi: Canary Deployment, trafik yönlendirmesi ve izleme gibi ek yapılandırmalar gerektirir.

Deployment Yaml Analizi

Kubernetes, uygulama güncellemelerini ve yönetimini kolaylaştırmak için Deployment nesnesini kullanır. Bir Deployment, belirli bir pod setini yönetir ve bu pod’ların istenilen sayıda kopyasının çalışmasını sağlar. Deployment YAML dosyası, uygulamanızın nasıl dağıtılacağını ve yönetileceğini belirler.

YAML dosyasında, belirli alanlar ve parametreler kullanılarak Kubernetes’e, hangi uygulamanın nasıl dağıtılacağı hakkında bilgi verilir. Bu yazıda, Kubernetes Deployment YAML dosyasını ve ana bileşenlerini detaylı bir şekilde inceleyeceğiz.

Bir Deployment YAML Dosyasının Yapısı

Aşağıda basit bir Deployment YAML dosyasının örneğini bulabilirsiniz:

apiVersion: apps/v1

kind: Deployment

metadata:

  name: my-deployment

  labels:

    app: my-app

spec:

  replicas: 3

  selector:

    matchLabels:

      app: my-app

  template:

    metadata:

      labels:

        app: my-app

    spec:

      containers:

        - name: my-container

          image: nginx:1.19.0

          ports:

            - containerPort: 80

YAML Dosyasının Bileşenleri

1. apiVersion

• Açıklama: Kubernetes API'sinin hangi sürümünü kullanacağını belirtir.

• Değer: Buradaki apps/v1, Kubernetes 1.9 ve sonrası için uygun olan versiyonu belirtir.

• Önem: API versiyonu, özelliklerin uyumluluğu için önemlidir. Yanlış versiyon kullanımı hatalara neden olabilir.

2. kind

• Açıklama: Bu alanda oluşturulacak nesnenin türü belirtilir. Bu örnekte Deployment kullanılıyor.

• Değer: Deployment, Kubernetes’e hangi tür nesne yaratılacağını söyler.

• Önem: Deployment nesnesi, pod'ları ve onların yaşam döngülerini yönetir.

3. metadata

• Açıklama: Deployment nesnesinin tanımlayıcı bilgilerini içerir.

• Bileşenleri:

  • name: Deployment nesnesinin adı. Bu, Kubernetes kümesinde bu Deployment’ı tanımlamak için kullanılır.

  • labels: Deployment’a ait etiketler. Etiketler, kaynakları gruplayabilmek ve filtrelemek için kullanılır.

• Önem: Metadata, nesneleri tanımlamak ve organize etmek için çok önemlidir.

4. spec

• Açıklama: Deployment’ın özelliklerini ve nasıl çalışması gerektiğini belirler.

• Bileşenleri:

  • replicas: Dağıtılacak pod sayısını belirtir. Bu örnekte 3 pod’un olması isteniyor.

  • selector: Hangi pod’ların bu Deployment’a dahil olacağını belirler. Buradaki matchLabels pod’ları app: my-app etiketine göre seçer.

  • template: Pod şablonunun tanımı. Bu, oluşturulacak pod’ların içeriğini tanımlar ve pod’ların nasıl oluşturulacağına dair bilgileri içerir.

5. template

• Açıklama: Pod şablonunun detaylarını içerir. Bu bölüm, spec altında tanımlanmış olup, pod’ların içeriği ile ilgili bilgiler verir.

• Bileşenleri:

  • metadata: Pod’a ait etiketler burada tanımlanır. Bu etiketler, selector ile uyumlu olmalıdır.

  • spec: Pod’un çalışma şekli hakkında bilgileri içerir. Örneğin, hangi konteynerin çalıştırılacağı ve konteynerin yapılandırma detayları burada yer alır.

    • containers: Bu alanda, pod içinde çalışacak konteynerlerin listesi yer alır.

      • name: Konteynerin adı.

      • image: Konteynerin çalıştıracağı Docker imajı. Bu örnekte nginx:1.19.0 imajı kullanılmakta.

      • ports: Konteynerin dışa açacağı portları belirtir. Burada 80 numaralı portu kullanıyoruz.

Kubernetes Deployment YAML Dosyasının Anlamlı Parçaları

1. replicas: 3

• Açıklama: Bu satır, Kubernetes’e uygulamanın 3 kopyasını çalıştırma talimatı verir. Bu, uygulamanın yüksek erişilebilirliğini sağlar. Eğer bir pod başarısız olursa, Kubernetes başka bir pod başlatır.

• Önem: Yüksek erişilebilirlik için önemli bir parametredir. replicas değerini artırarak daha fazla pod oluşturabilir ve uygulamanın dayanıklılığını artırabilirsiniz.

2. selector ve matchLabels

• Açıklama: selector alanı, hangi pod’ların bu Deployment tarafından yönetileceğini belirtir. matchLabels ile, etiketlere göre seçim yapılır. Bu, Kubernetes’e hangi pod’ların bu Deployment ile ilişkilendirileceğini bildirir.

• Önem: selector, Deployment ile pod’lar arasındaki ilişkiyi sağlar. Bu, yalnızca belirtilen etiketlere sahip pod’ların güncellenmesini sağlar.

3. template ve containers

• Açıklama: template, pod şablonudur ve yeni pod’ların nasıl oluşturulacağına dair bilgileri içerir. containers listesi, her bir pod’da çalıştırılacak konteynerleri belirtir. Burada nginx imajı belirtilmiştir.

• Önem: Pod’ların yapılandırılmasında kritik bir rol oynar. Pod içinde çalıştırılacak konteynerler ve bu konteynerlere ait ayarlar burada yapılır.

4. ports

• Açıklama: Konteynerin dış dünyaya hangi portları açacağını belirtir. Bu örnekte, 80 numaralı HTTP portu dışa açılmıştır.

• Önem: Pod’ların dışarıya açılması gereken portları doğru şekilde ayarlamak, uygulamanın doğru çalışabilmesi için önemlidir.

YAML Dosyasındaki Diğer Yaygın Parametreler

strategy

• Açıklama: Güncelleme stratejisini belirtir. Varsayılan olarak RollingUpdate kullanılır, ancak Recreate gibi diğer stratejiler de seçilebilir.

  strategy:

    type: RollingUpdate

    rollingUpdate:

      maxSurge: 1

      maxUnavailable: 1

  
  

env (Environment Variables)

• Açıklama: Konteyner içinde kullanılacak ortam değişkenlerini belirtir.

  containers:

    - name: my-container

      image: nginx:1.19.0

      env:

        - name: ENV_VAR_NAME

          value: "value"

  
  

resources

• Açıklama: Konteyner için kaynak limitleri ve talepleri tanımlar (CPU, RAM).

  containers:

    - name: my-container

      image: nginx:1.19.0

      resources:

        requests:

          memory: "64Mi"

          cpu: "250m"

        limits:

          memory: "128Mi"

          cpu: "500m"

Kubernetes ReplicaSet

Kubernetes'teki ReplicaSet, belirli bir sayıda Pod kopyasının (replica) her zaman çalışır durumda olmasını sağlayan bir kontrolcüdür. Temel amacı, uygulamanızın istenen sayıda örneğinin sürekli olarak ayakta kalmasını garantilemektir.

Nasıl Çalışır?

1. İstenen Kopya Sayısı (Replicas): Bir ReplicaSet oluştururken, kaç adet Pod kopyasının çalışır durumda olması gerektiğini tanımlarsınız (spec.replicas).

2. Seçici (Selector): ReplicaSet, hangi Pod'ları yöneteceğini belirlemek için bir seçici (label selector) kullanır (spec.selector). Bu seçici, belirli etiketlere (labels) sahip olan Pod'ları hedefler.

3. Pod Şablonu (Pod Template): ReplicaSet, yeni Pod'lar oluşturmak için bir şablon tanımlar (spec.template). Bu şablon, Pod'un container'larını, etiketlerini ve diğer özelliklerini içerir.

ReplicaSet'in Görevleri:

• İstenen Durumu Korumak: ReplicaSet, her zaman tanımladığınız sayıda Pod kopyasının çalıştığından emin olur.

• Pod Oluşturma: Eğer çalışan Pod sayısı istenen sayıdan azsa, yeni Pod'lar oluşturur.

• Pod Silme: Eğer çalışan Pod sayısı istenen sayıdan fazlaysa, fazla Pod'ları siler.

• Sağlık Kontrolleri (Dolaylı): ReplicaSet doğrudan sağlık kontrolü yapmaz. Ancak, Pod'lar başarısız olursa (örneğin, bir container çökerse), ReplicaSet bu başarısız Pod'u tespit eder ve yerine yeni bir tane oluşturur.

Neden ReplicaSet Kullanmalıyız?

• Yüksek Erişilebilirlik (High Availability): Uygulamanızın birden fazla kopyası çalıştığı için, bir veya birden fazla Pod arızalansa bile uygulamanız çalışmaya devam eder.

• Ölçeklenebilirlik (Scalability): Uygulamanızın yükü arttığında, spec.replicas değerini artırarak kolayca Pod sayısını çoğaltabilirsiniz (yatay ölçeklenme).

• Kendi Kendini İyileştirme (Self-Healing): Başarısız olan Pod'lar otomatik olarak yeniden başlatılır veya yerlerine yenileri oluşturulur.

Örnek Bir ReplicaSet Tanımı:

YAML

apiVersion: apps/v1

kind: ReplicaSet

metadata:

  name: my-app-replicaset

spec:

  replicas: 3

  selector:

    matchLabels:

      app: my-app

  template:

    metadata:

      labels:

        app: my-app

    spec:

      containers:

      - name: my-app-container

        image: my-registry/my-app:v1.0

        ports:

        - containerPort: 8080

Bu örnekte, my-app-replicaset adında bir ReplicaSet tanımlanmıştır. Bu ReplicaSet, app: my-app etiketiyle eşleşen 3 adet Pod kopyasını sürekli olarak çalışır durumda tutmaya çalışacaktır. Yeni Pod'lar oluştururken, template bölümündeki tanımı kullanacaktır.

Özet:

ReplicaSet, Kubernetes'te istenen sayıda Pod kopyasının her zaman çalışır durumda olmasını sağlayan temel bir kontrolcüdür. Yüksek erişilebilirlik, ölçeklenebilirlik ve kendi kendini iyileştirme gibi avantajlar sunar. Genellikle Deployment gibi daha üst seviye kontrolcüler tarafından yönetilir.

ReplicaSet’in Temel Özellikleri

ReplicaSet, Kubernetes platformunda çalışan pod’ların belirli bir sayısının sürekli olarak aktif ve sağlıklı olmasını garanti eden bir bileşendir. ReplicaSet, genellikle Deployment ile birlikte çalışarak pod'ları yönetirken, kendi başına da kullanılabilir. İşte ReplicaSet'in temel özellikleri:

1. Pod Sayısını Kontrol Etme (Replicas)

ReplicaSet'in en önemli işlevi, belirli bir sayıda pod’un her zaman çalışmasını sağlamaktır. Bu, özellikle yüksek erişilebilirlik ve kesintisiz hizmet için kritiktir.

• Replicas: ReplicaSet, replicas parametresi ile belirtilen sayıda pod’un her zaman çalışmasını sağlar. Örneğin, bir ReplicaSet 3 replica pod başlatmak için yapılandırıldığında, ReplicaSet her zaman 3 aktif pod’u korumaya çalışacaktır. Eğer bir pod herhangi bir sebepten dolayı kapanır veya başarısız olursa, ReplicaSet hemen yeni bir pod başlatarak bu sayıyı 3'e çıkarır.

Örnek:

spec:

  replicas: 3

Bu ayar, ReplicaSet'in 3 pod çalıştırmasını sağlar.

2. Yüksek Erişilebilirlik ve Kesintisiz Hizmet

ReplicaSet, bir uygulamanın birden fazla örneğini (replicas) çalıştırarak yüksek erişilebilirlik sağlar. Eğer bir pod arızalanırsa, başka bir pod devreye girerek hizmetin devam etmesini sağlar.

• Yüksek Erişilebilirlik: Pod’lar dağıtık bir şekilde çalıştığından, bir pod’un arızalanması veya kapanması, diğer pod'lar sayesinde hizmetin kesintiye uğramadan devam etmesini sağlar.

Örnek:

• Bir web uygulaması, 3 pod’dan oluşuyorsa, her biri farklı sunucularda çalışıyorsa ve bir pod başarısız olursa, diğer 2 pod hala çalışmaya devam eder.

3. Pod Seçici (Selector)

ReplicaSet, hangi pod’ları yöneteceğini belirlemek için selector kullanır. Selector, genellikle pod’lara ait etiketler ile tanımlanır ve ReplicaSet, bu etiketlere uyan pod’ları seçer.

• Pod Seçimi: ReplicaSet'in yalnızca belirli pod’ları yönetmesi gerektiği durumlarda etiketler çok kullanışlıdır. ReplicaSet, belirtilen etiketlere sahip pod'ları seçer ve bu pod’ları yönetir.

Örnek:

spec:

  selector:

    matchLabels:

      app: my-app

Bu örnekte, ReplicaSet, app: my-app etiketine sahip tüm pod'ları yönetecektir.

4. Pod Şablonu (Template)

ReplicaSet, yeni pod'lar oluştururken bir template (şablon) kullanır. Pod şablonu, pod’ların içeriğini (hangi container'lar çalışacak, hangi portlar açılacak, hangi imaj kullanılacak vb.) tanımlar.

• Pod Şablonu: ReplicaSet, her yeni pod oluşturduğunda bu şablonu kullanarak pod’un içeriğini belirler. Pod şablonu, spec.template altında tanımlanır.

Örnek:

spec:

  template:

    metadata:

      labels:

        app: my-app

    spec:

      containers:

      - name: my-container

        image: nginx:latest

        ports:

        - containerPort: 80

Bu şablon, her yeni pod’un içinde nginx container'ı çalıştıracaktır ve 80 numaralı portu açacaktır.

5. Otomatik Pod Yeniden Başlatma (Self-Healing)

ReplicaSet, belirli bir sayıda pod'un çalışmasını garanti eder. Eğer bir pod beklenmedik şekilde kapanır veya başarısız olursa, ReplicaSet hemen yeni bir pod başlatarak eski pod’un yerine geçmesini sağlar.

• Self-Healing (Kendini Onarma): ReplicaSet, her zaman belirtilen sayıda pod’un çalışmasını garanti eder. Eğer bir pod arızalanırsa, ReplicaSet yeni bir pod başlatarak sistemin çalışmaya devam etmesini sağlar.

Örnek:

• Eğer bir pod'un container'ı çökerse, ReplicaSet otomatik olarak yeni bir container başlatarak pod’un yerine geçmesini sağlar.

6. Yük Dengeleme (Load Balancing) ve Dağıtım

ReplicaSet, pod’ların sayısını kontrol etmekle birlikte, yük dengelemesi yapılabilmesi için bir Service ile birlikte kullanılabilir. Service, ReplicaSet’in sağladığı pod'lara yönlendirme yapar ve bu sayede gelen trafiği eşit bir şekilde dağıtarak, yüksek verimli bir hizmet sunulmasını sağlar.

• Yük Dengeleme: Service ve ReplicaSet birlikte çalışarak, trafiği tüm pod'lar arasında eşit bir şekilde dağıtır.

Örnek: Bir ReplicaSet’in 3 pod’u varsa, bir Service bu 3 pod’a gelen istekleri dengeler ve her bir pod’a eşit olarak dağıtarak performansı artırır.

7. Sürüm Güncellemeleri (Rolling Updates)

ReplicaSet, genellikle Deployment ile birlikte çalışarak, pod güncellemelerinin doğru bir şekilde yönetilmesini sağlar. Bir pod yeni bir sürüme güncellendiğinde, ReplicaSet eski pod’ları sırayla kaldırarak yerine yeni pod’ları başlatır (Rolling Update). Bu sayede sistemin kesintisiz bir şekilde çalışması sağlanır.

• Rolling Update: Bir ReplicaSet güncellenmeye başladığında, önce eski pod’lar kaldırılır, sonra yeni pod’lar başlatılır. Bu süreçte, sistemin her zaman minimum düzeyde çalışmaya devam etmesi sağlanır.

8. ReplicaSet ve Deployment’ın Birlikte Çalışması

ReplicaSet, genellikle Deployment ile birlikte kullanılır. Deployment, pod güncellemelerini yönetirken, ReplicaSet yalnızca pod’ların sayısını ve sağlığını denetler. Deployment, ReplicaSet oluşturur ve pod’ların sürümünü yönetirken, ReplicaSet yalnızca pod’ları başlatır ve çalıştırır.

• Deployment ile Yönetim: Deployment, ReplicaSet'in sürümlerini yönetir, pod'ları günceller ve gerektiğinde rollback işlemleri yapar.

ReplicaSet ve Deployment İlişkisi

Kubernetes'teki ReplicaSet ve Deployment birbirinden farklı bileşenlerdir, ancak çoğu zaman birlikte çalışarak pod yönetimini daha verimli ve etkili bir şekilde gerçekleştirirler. Deployment, ReplicaSet'in bir üst seviyesi olarak işlev görür ve pod güncellemeleri, sürüm yönetimi ve geri alma (rollback) işlemleri gibi daha gelişmiş özellikler sağlar.

1. ReplicaSet Nedir?

ReplicaSet, belirli bir sayıda pod’un her zaman çalışmasını garanti eder. Yani, ReplicaSet, istediğiniz kadar pod’un çalıştığından emin olur ve bir pod başarısız olduğunda hemen yenisini başlatır.

• Amaç: Pod’ların sayısının belirli bir seviyede kalmasını sağlamak.

• Yönetim: ReplicaSet doğrudan pod'ları yönetir, ancak pod'lar üzerinde güncelleme yapmak için manuel müdahale gereklidir.

2. Deployment Nedir?

Deployment, ReplicaSet’in yönetimini üstlenen daha üst seviyeli bir bileşendir. Deployment, pod güncellemeleri ve sürüm kontrolü gibi daha sofistike işlemleri otomatikleştirir ve kullanıcının müdahalesine gerek kalmadan sürdürülebilir bir uygulama yönetimi sağlar.

• Amaç: Pod güncellemelerini yönetmek, sürüm yükseltme ve geri alma işlemleri yapmak, pod'ları birden fazla ReplicaSet aracılığıyla yönetmek.

• Yönetim: Deployment, ReplicaSet'i oluşturur ve yönetir. Ayrıca, ReplicaSet'i güncellemek, sürüm yükseltmek veya geri almak gibi işlemleri otomatikleştirir.

ReplicaSet ve Deployment İlişkisi

1. Deployment, ReplicaSet Oluşturur

Deployment, kullanıcı tarafından oluşturulduğunda otomatik olarak bir ReplicaSet oluşturur. ReplicaSet, Deployment’ın iç kısmında bulunan pod şablonuna dayalı olarak pod’ları başlatır ve çalıştırır. Bu, pod’ların belirli bir sayıda sürekli olarak çalışmasını sağlar.

• Deployment ve ReplicaSet İlişkisi: Deployment, ReplicaSet’i yönetir. Deployment aracılığıyla yapılan pod güncellemeleri, yeni ReplicaSet’lerin oluşturulmasına ve eski ReplicaSet’lerin kaldırılmasına yol açar.

• Örnek: Bir Deployment oluşturduğunuzda, Kubernetes, belirttiğiniz ReplicaSet sayısına göre pod'ları başlatır.

2. Deployment Sürüm Yönetimi (Rolling Update)

Deployment, pod güncellemelerini (rolling updates) yönetmek için kullanılır. Yeni bir sürüm oluşturulduğunda, Deployment eski pod’ları yavaşça kaldırır ve yeni pod’ları başlatır. Bu işlem sırasında, sistemin kesintiye uğramaması sağlanır.

• Rolling Update: Yeni sürümün pod'ları yavaşça devreye alınırken, eski pod'lar birer birer kaldırılır. Bu, kullanıcıların uygulamayı kesintisiz bir şekilde kullanmalarına olanak tanır.

• ReplicaSet ile İlişkisi: Deployment her zaman mevcut ReplicaSet’i günceller, yeni bir sürüm gerektiğinde ise yeni bir ReplicaSet oluşturur. Her iki ReplicaSet bir süre paralel olarak çalışır ve sistemin sürekliliğini sağlar.

3. Rollback (Geri Alma)

Deployment, eğer yeni sürümde bir hata oluşursa, önceki sürüme geri dönme (rollback) özelliği sunar. Yani, eğer güncelleme sırasında bir sorun çıkarsa, eski ReplicaSet geri yüklenir.

• Rollback İşlemi: Bir sürüm güncellemesi sırasında sorun çıkarsa, Deployment eski ReplicaSet'e geri döner ve eski pod'lar tekrar devreye alınır.

• ReplicaSet ile İlişkisi: ReplicaSet, yalnızca mevcut sürümün pod'larını yönetir. Rollback işlemi, Deployment tarafından kontrol edilir ve eski ReplicaSet yeniden aktif hale getirilir.

4. Deployment, ReplicaSet’i Yönettiği İçin Kullanıcı Müdahalesi Gerektirmez

Deployment, ReplicaSet’i kendi içinde yönetir. Kullanıcılar, yalnızca Deployment üzerinden pod güncellemelerini yapar ve ReplicaSet hakkında düşünmek zorunda kalmazlar. Kubernetes, ReplicaSet’leri otomatik olarak yönetir.

• Özellik: ReplicaSet, genellikle Deployment ile yönetildiği için kullanıcıların manuel olarak ReplicaSet oluşturmasına gerek yoktur.

• Güncellemeler: Deployment güncellendiğinde, ReplicaSet de otomatik olarak güncellenir.

5. Deployment İle ReplicaSet Arasındaki Farklar

• Yönetim: Deployment, ReplicaSet’i yönetirken, ReplicaSet yalnızca belirli sayıda pod’un çalışmasını garanti eder.

• Güncelleme ve Sürüm Yönetimi: Deployment, pod’ların sürümünü ve güncellemelerini kontrol eder. ReplicaSet, yalnızca pod sayısını denetler ve yedeklemeleri yapar.

• Yedeklilik: Deployment, ReplicaSet ile yedekliliği garanti eder. Eğer ReplicaSet başarısız olursa, Deployment yeni bir ReplicaSet oluşturur.

Örnek: Deployment ve ReplicaSet Kullanımı

Aşağıdaki örnek, Deployment ve ReplicaSet’in nasıl işbirliği yaptığına dair bir yapı sunmaktadır.

Deployment Yaml Örneği:

apiVersion: apps/v1

kind: Deployment

metadata:

  name: my-deployment

spec:

  replicas: 3  # 3 pod çalışacak

  selector:

    matchLabels:

      app: my-app

  template:

    metadata:

      labels:

        app: my-app

    spec:

      containers:

        - name: my-container

          image: nginx:latest

          ports:

            - containerPort: 80

Bu örnekte:

• Deployment oluşturuluyor ve 3 pod’un çalışması isteniyor.

• Deployment, içsel olarak bir ReplicaSet oluşturacak ve bu ReplicaSet 3 pod çalıştıracaktır.

• Yeni bir güncelleme yapıldığında, Deployment ReplicaSet'i günceller ve yeni pod’ları devreye alır.

Rolling Update İle Yeni Bir Sürüm:

spec:

  strategy:

    type: RollingUpdate

    rollingUpdate:

      maxSurge: 1  # Yeni pod ekleme sırasında bir ekstra pod başlatılabilir

      maxUnavailable: 1  # Güncellenen pod'ların sayısı en fazla 1 olabilir

Bu yapı, Rolling Update stratejisiyle Deployment'ın pod'ları güncellemesini sağlar. Yeni bir sürüm yayınlandığında, birer birer eski pod’lar kaldırılır ve yeni pod’lar başlatılır.

ReplicaSet ve Deployment Arasındaki Farklar

Kubernetes’te ReplicaSet ve Deployment birbirine benzer özellikler sunsa da, her biri farklı amaçlara hizmet eder ve kullanımı farklıdır. Bu iki bileşen arasındaki farkları anlamak, Kubernetes’te pod yönetimini daha verimli bir şekilde yapmanızı sağlar. İşte ReplicaSet ve Deployment arasındaki temel farklar:

1. Temel Amaç ve Kullanım

• ReplicaSet:

  • Temel Amaç: Belirli bir sayıda pod’un her zaman çalışmasını garanti etmek. Yani, ReplicaSet pod'ları çalıştırmak için kullanılır ve belirttiğiniz sayıda pod’un sürekli olarak çalışıp çalışmadığını kontrol eder.

  • Kullanım: Pod'ların ölçeklendirilmesi ve yedeklenmesi için kullanılır. Eğer bir pod başarısız olursa, ReplicaSet yeni bir pod başlatır.

• Deployment:

  • Temel Amaç: Pod güncellemeleri, sürüm yönetimi ve geri alma (rollback) işlemlerini otomatikleştirmek. Deployment, ReplicaSet oluşturur ve yönetir, ancak daha geniş işlevsellik sunar, örneğin güncellemeleri ve geri almaları yönetir.

  • Kullanım: Uygulama sürümlerini yönetmek, güncellemeleri otomatikleştirmek ve pod'ların istenilen sayıda çalışmasını sağlamak için kullanılır. Deployment, ReplicaSet’leri otomatik olarak oluşturur ve günceller.

2. Güncelleme ve Sürüm Yönetimi

• ReplicaSet:

  • Güncelleme: ReplicaSet, pod'ları manuel olarak güncellemeyi gerektirir. Yani, yeni bir sürüm veya pod şablonu kullanmak için ReplicaSet’i elle güncellemeniz gerekir.

  • Sürüm Yönetimi: ReplicaSet sürüm yönetimi sunmaz. Yeni bir pod sürümü gerektiğinde, manuel müdahale gereklidir.

• Deployment:

  • Güncelleme: Deployment, rolling update stratejisini kullanarak pod’ları otomatik olarak günceller. Yeni bir sürüm oluşturulduğunda, eski pod'lar birer birer kaldırılır ve yeni pod'lar devreye alınır.

  • Sürüm Yönetimi: Deployment, sürüm kontrolü sunar. Yeni bir sürüm geldiğinde eski sürümle karşılaştırma yapabilir ve gerektiğinde rollback (geri alma) işlemi yapabilirsiniz.

3. Rolling Update ve Rollback

• ReplicaSet:

  • Rolling Update: ReplicaSet’in kendisi rolling update yapmaz. Yeni sürüme geçmek için manuel olarak ReplicaSet’i yeniden yapılandırmanız gerekir.

  • Rollback: ReplicaSet’te rollback özelliği yoktur. Eğer bir güncelleme yapılırsa ve hata meydana gelirse, eski pod'ları tekrar çalıştırmak için manuel müdahale gereklidir.

• Deployment:

  • Rolling Update: Deployment, pod’ları rolling update yöntemiyle günceller. Yani, bir sürümdeki hata düzeltme işlemi veya yeni sürümün dağıtımı sırasında hizmet kesintisini önler.

  • Rollback: Deployment, rollback işlemi sağlar. Eğer yeni sürümde bir hata oluşursa, önceki sürüme geri dönülebilir.

4. Yönetim ve Kullanıcı Etkileşimi

• ReplicaSet:

  • Yönetim: Kullanıcılar, ReplicaSet’i manuel olarak yönetir. Bir ReplicaSet'in güncellenmesi gerektiğinde, kullanıcının yeni bir ReplicaSet oluşturması veya mevcut ReplicaSet’i düzenlemesi gerekir.

  • Kullanıcı Etkileşimi: Genellikle doğrudan ReplicaSet ile etkileşime girilmez. Kullanıcılar, ReplicaSet’i güncellemek için Deployment kullanır.

• Deployment:

  • Yönetim: Deployment, ReplicaSet’leri otomatik olarak yönetir. Kullanıcı, Deployment üzerinden pod güncellemelerini yapabilir ve Kubernetes geri kalan tüm ReplicaSet yönetimini üstlenir.

  • Kullanıcı Etkileşimi: Kullanıcılar Deployment ile etkileşim kurar ve genellikle pod güncellemelerini Deployment aracılığıyla yapar.

5. Pod Ölçeklendirme

• ReplicaSet:

  • Pod Ölçeklendirme: ReplicaSet’in amacı, belirli bir sayıda pod'un çalışmasını sağlamaktır. ReplicaSet'i ölçeklendirmek için, pod sayısını manuel olarak ayarlamanız gerekir. Bu, replicas parametresi ile yapılır.

• Deployment:

  • Pod Ölçeklendirme: Deployment da pod ölçeklendirme işlemlerini destekler. Deployment üzerinden pod sayısı arttırılabilir veya azaltılabilir. Bu işlem, daha esnek ve gelişmiş bir yönetim sağlar.

6. Kullanım Senaryoları

• ReplicaSet:

  • Kullanım Senaryosu: Yalnızca belirli bir sayıda pod’un çalışmasını sağlamak istiyorsanız, ReplicaSet kullanabilirsiniz. Ancak, pod güncellemeleri ve sürüm yönetimi gibi işlemler için daha fazla yönetim gereklidir.

  • Örnek: Bir uygulamanın belirli sayıda çalışan pod'a sahip olmasını sağlamak için kullanılabilir.

• Deployment:

  • Kullanım Senaryosu: Uygulamanızın sürüm yönetimini, güncellemelerini ve rollback işlemlerini otomatikleştirmek istiyorsanız, Deployment kullanmalısınız. Deployment, ReplicaSet'in yönetilmesi ve güncellenmesi için daha iyi bir çözüm sunar.

  • Örnek: Bir mikroservisin güncellenmesini ve sürüm yönetimini kolayca yapmak için Deployment kullanılır.

7. Esneklik ve Genişletilebilirlik

• ReplicaSet:

  • Esneklik: ReplicaSet, yalnızca pod’ların sayısını garanti eder. Ancak, güncelleme, rollback ve sürüm yönetimi gibi gelişmiş işlevsellik sunmaz.

  • Genişletilebilirlik: ReplicaSet, temel düzeyde ölçeklendirme ve yedeklilik sağlar, ancak gelişmiş yönetim ve sürdürülebilirlik sağlamak için başka araçlara ihtiyaç vardır.

• Deployment:

  • Esneklik: Deployment, pod güncellemelerini ve sürüm yönetimini otomatikleştirerek daha esnek bir yapı sunar. Ayrıca, dağıtım sırasında herhangi bir sorun meydana geldiğinde rollback işlemleri yapılabilir.

  • Genişletilebilirlik: Deployment, ReplicaSet ve pod yönetimini çok daha verimli hale getirir. Kubernetes ile tam uyumlu olarak, ölçeklendirme, sürüm yönetimi ve otomatik güncelleme gibi özellikleri genişletilebilir.

ReplicaSet Yaml Analizi

Kubernetes'te bir ReplicaSet, belirli bir sayıda pod'un her zaman çalıştığından emin olmak için kullanılan bir bileşendir. ReplicaSet tanımı YAML (YAML Ain't Markup Language) formatında yapılır ve YAML dosyası, Kubernetes API'ye gönderildiğinde pod'ların oluşturulmasını sağlar. Şimdi, bir ReplicaSet YAML dosyasını inceleyerek temel bileşenleri ve nasıl çalıştığını detaylı bir şekilde analiz edelim.

Örnek ReplicaSet Yaml Dosyası

apiVersion: apps/v1

kind: ReplicaSet

metadata:

  name: nginx-replicaset

  labels:

    app: nginx

spec:

  replicas: 3

  selector:

    matchLabels:

      app: nginx

  template:

    metadata:

      labels:

        app: nginx

    spec:

      containers:

        - name: nginx

          image: nginx:latest

          ports:

            - containerPort: 80

1. apiVersion

• Açıklama: apiVersion alanı, Kubernetes API'sinde kullanılan kaynak türünün sürümünü belirtir. Bu, Kubernetes'in hangi sürümünde hangi API özelliklerinin kullanılacağını belirler.

• Örnek: apps/v1 ifadesi, ReplicaSet'in apps API grubunda ve v1 sürümünde olduğunu belirtir. Bu, ReplicaSet'in yönetileceği API sürümüdür.

2. kind

• Açıklama: kind alanı, bu YAML dosyasının türünü belirtir. Burada, ReplicaSet türü kullanılmaktadır.

• Örnek: ReplicaSet, bu YAML dosyasının bir ReplicaSet kaynağını tanımladığını gösterir.

3. metadata

• Açıklama: metadata bölümü, ReplicaSet hakkında temel bilgileri içerir. Bu bilgiler, ReplicaSet'in adını, etiketlerini ve diğer özelliklerini içerir.

• Örnek:

  • name: ReplicaSet'in adı. Bu örnekte nginx-replicaset olarak belirlenmiş.

  • labels: ReplicaSet'e ait etiketler. Bu etiketler, ReplicaSet'i başka kaynaklarla ilişkilendirmek için kullanılabilir. Örnekte, app: nginx etiketi belirtilmiştir.

4. spec

• Açıklama: spec bölümü, ReplicaSet'in nasıl çalışacağını ve yönetileceğini belirleyen tüm detayları içerir. Bu bölüm, ReplicaSet’in içsel davranışını tanımlar.

  • replicas: ReplicaSet’in istediği pod sayısını belirtir. Burada, replicas: 3 ifadesi, Kubernetes’in 3 pod'u aynı anda çalıştırmasını sağlar. Eğer pod'lar başarısız olursa, ReplicaSet otomatik olarak yeni pod'lar başlatır.

  • selector: ReplicaSet’in hangi pod’ları yöneteceğini belirtir. Selector, pod'ları etiketlere göre filtreler. ReplicaSet, bu etiketlere sahip pod'ları izleyecek ve gerekli sayıyı sağlayacak şekilde onları yeniden başlatacaktır.

  • template: Pod template (şablon) alanıdır ve ReplicaSet’in oluşturacağı pod’ların iç yapısını tanımlar. Burada, pod'ların adını, etiketlerini ve container yapılandırmalarını içerir.

5. selector

• Açıklama: selector alanı, ReplicaSet’in hangi pod'ları yöneteceğini belirler. Bu, pod’ların etiketlerini filtreleyerek belirli pod'ları seçmeyi sağlar. matchLabels kullanılarak pod'lar seçilebilir.

• Örnek:

  • matchLabels kullanılarak, app: nginx etiketine sahip pod’lar seçilir. Bu, ReplicaSet’in yalnızca app: nginx etiketine sahip pod'ları izleyeceği anlamına gelir.

6. template

• Açıklama: template alanı, ReplicaSet tarafından oluşturulacak pod’ların şablonudur. Burada, pod'ların etiketleri, container’ları ve ilgili ayarları tanımlanır.

  • metadata: Pod'a ait etiketler burada tanımlanır. ReplicaSet’in selector alanı ile uyumlu olması gerekir. Bu örnekte, app: nginx etiketi, ReplicaSet’in pod'ları doğru bir şekilde yönetmesini sağlar.

  • spec: Pod'un çalışacağı ortamı tanımlar. Pod’un container’ları, çalıştıracağı image, port bilgisi gibi detaylar burada yer alır.

7. containers

• Açıklama: containers bölümü, pod içinde çalışacak container’ları tanımlar. Her bir container, uygulamanın çalıştırıldığı ortamı belirtir. Bu bölümde bir container’ın adı, kullandığı image ve expose edilen portlar gibi bilgiler bulunur.

• Örnek:

  • name: nginx: Container’a verilen isim.

  • image: nginx:latest: Kullanılacak container image'ı. Burada, nginx:latest Docker hub’ından çekilecek olan son sürüm Nginx container'ıdır.

  • ports: Container’ın dışarıya açtığı portlar. Bu örnekte, container 80 numaralı portu dışarıya açmaktadır.

YAML Dosyasının Genel Akışı

1. ReplicaSet Tanımı: kind: ReplicaSet ile ReplicaSet türü belirtiliyor.

2. Yapılandırma Detayları: apiVersion: apps/v1 ile hangi API sürümünün kullanılacağı belirleniyor.

3. Meta Bilgiler: metadata içinde ReplicaSet’e ait isim ve etiketler yer alıyor.

4. Pod Yönetimi: spec altında, ReplicaSet'in pod'ları yönetmesi için gerekli bilgiler yer alıyor. Burada, replicas, selector ve template gibi alanlar kullanılarak pod'ların çalışma düzeni belirtiliyor.

5. Container Yapılandırması: template.spec.containers altında, her bir container’ın adı, image’ı ve port bilgisi belirleniyor.

ConfigMap Nedir?

ConfigMap, Kubernetes’te yapılandırma verilerini uygulamalardan bağımsız olarak saklamak ve yönetmek için kullanılan bir kaynak türüdür. ConfigMap sayesinde uygulamaların çalışması için gereken konfigürasyon verileri (örneğin: yapılandırma dosyaları, çevresel değişkenler, komut satırı argümanları vb.) Kubernetes kaynakları ile birlikte merkezi bir şekilde yönetilebilir.

? Temel Tanım:

ConfigMap, anahtar-değer (key-value) çiftleri şeklinde verileri depolar. Uygulamalar bu verilere çevresel değişken, dosya veya argüman olarak erişebilir. Böylece, kod ve yapılandırma birbirinden ayrılmış olur.

Bu prensip, yazılım dünyasında yaygın olarak bilinen "Twelve-Factor App" yaklaşımının "Yapılandırmaları Koddan Ayırın (Store config in the environment)" maddesine uygundur.

✅ ConfigMap Ne İçin Kullanılır?

1. Çevresel değişkenlerin merkezi olarak yönetilmesi

2. Aynı yapılandırmanın birden çok pod’da yeniden kullanılması

3. Farklı ortamlar (development, staging, production) için ayrı yapılandırmalar tanımlama

4. Yapılandırma verilerini değiştirmek için pod’u yeniden derlemeden sadece ConfigMap’i güncelleme

⚙️ ConfigMap Kullanım Biçimleri

1. Çevresel Değişken Olarak Kullanma:

env:

  - name: APP_MODE

    valueFrom:

      configMapKeyRef:

        name: my-config

        key: mode

2. Dosya Olarak Mount Etme (Volume üzerinden):

volumeMounts:

  - name: config-volume

    mountPath: /etc/config

volumes:

  - name: config-volume

    configMap:

      name: my-config

3. Komut Argümanı Olarak Kullanma:

args: ["--mode=$(APP_MODE)"]

? ConfigMap İçeriği Örneği:

YAML ile tanımlı bir örnek:

apiVersion: v1

kind: ConfigMap

metadata:

  name: my-config

data:

  mode: production

  log_level: debug

  welcome_message: "Merhaba Kubernetes!"

Bu ConfigMap içinde üç adet key-value çifti saklanır:

• mode = production

• log_level = debug

• welcome_message = Merhaba Kubernetes!

? ConfigMap Güncellemesi

Bir ConfigMap güncellendiğinde, bu güncelleme pod içinde anında yansımaz (varsayılan olarak). Güncellemeyi almak için:

• Pod’u yeniden başlatmak gerekir (manuel ya da rolling update)

• Veya bir sidecar/reloader çözümü kullanmak gerekir (örnek: Reloader)

? ConfigMap ve Gizli Veriler

ConfigMap, gizli veriler (şifre, API anahtarı vb.) için kullanılmaz. Bu tür veriler için Secret kaynağı kullanılmalıdır. Çünkü ConfigMap, base64 encode etmez, içeriği düz metindir ve kolayca erişilebilir.

? Avantajları:

• Uygulamaları yeniden yapılandırmadan ayarlarda değişiklik yapılabilir

• Tek yapılandırma birden fazla uygulamada kullanılabilir

• Kodda değişiklik yapmadan ortam ayarlarını değiştirmek mümkündür

• Versiyon kontrol sistemlerine YAML olarak eklenebilir

⚠️ Dikkat Edilmesi Gerekenler:

• ConfigMap verileri şifreli değildir.

• Çok büyük veriler (örneğin büyük dosyalar veya binary içerikler) için uygun değildir.

• ConfigMap'in kullanılabilmesi için uygulamanın bu yapıya uygun şekilde geliştirilmiş olması gerekir.

Yapılandırma Verilerini Yönetme

Neden Yapılandırma Yönetimi Gerekir?

Modern uygulamalar farklı ortamlarda (development, test, staging, production) çalıştırılır. Her ortam, kendine özgü ayar ve yapılandırma gerektirir. Bu yapılandırmaları uygulama kodunun içine yerleştirmek:

• Ortam bağımlılığına neden olur

• Kodun tekrar kullanılabilirliğini azaltır

• Güncellemeleri zorlaştırır

• Güvenlik açıklarına yol açar

Bu nedenle uygulama kodu ile yapılandırma verileri birbirinden ayrılmalıdır. Kubernetes, bu ayrımı doğal olarak destekler.

Kubernetes'te Yapılandırma Yönetiminin Temel Araçları

1. ConfigMap

• Anahtar-değer çiftleri şeklinde yapılandırma verisi içerir.

• Şifreli değildir; genellikle gizli olmayan veriler için kullanılır.

• Uygulamalara environment variable, volume veya argüman olarak aktarılabilir.

2. Secret

• Şifre, token, API anahtarı gibi hassas bilgilerin saklanması için kullanılır.

• Base64 formatında saklanır.

• RBAC politikaları ile erişimi sınırlandırılabilir.

Yapılandırma Nasıl Kullanılır?

1. Environment Variables (Çevresel Değişkenler) ile

Pod tanımında aşağıdaki gibi kullanılabilir:

env:

  - name: APP_MODE

    valueFrom:

      configMapKeyRef:

        name: app-config

        key: mode

2. Volume Olarak Mount Etme

volumes:

  - name: config-volume

    configMap:

      name: app-config

volumeMounts:

  - name: config-volume

    mountPath: /etc/config

Uygulama, bu dizin altındaki dosyalarla yapılandırma verilerine erişebilir.

3. Komut Satırı Argümanları ile

args: ["--mode=$(APP_MODE)"]

Bu yöntemle yapılandırma değeri doğrudan başlatma parametresi olarak verilir.

Yapılandırma Güncellemeleri

ConfigMap veya Secret güncellendiğinde pod'ların bu değişiklikleri alması için çeşitli stratejiler uygulanabilir:

1. Pod’u Manuel Yeniden Başlatmak

ConfigMap güncellendikten sonra pod yeniden başlatılarak yapılandırma uygulanır.

2. Deployment Üzerinden Rolling Update

Bir etiket (örn. config-checksum) değiştirilerek Kubernetes pod’ları otomatik olarak sırasıyla yeniden başlatır.

3. Uygulama Tarafından Dinamik Okuma

Bazı uygulamalar (örneğin Spring Boot), yapılandırma dosyalarını düzenli olarak okuyup değişiklikleri algılayabilir.

Ortam Bazlı Yapılandırma

Farklı ortamlar için farklı yapılandırmalar kullanmak yaygın bir yöntemdir:

• Farklı ConfigMap nesneleri oluşturmak (örneğin app-config-dev, app-config-prod)

• Ortama özel namespace kullanmak

• Helm gibi şablonlama araçlarıyla değerleri dışarıdan vermek

En İyi Uygulamalar

• ConfigMap ve Secret dosyalarını versiyon kontrolü altında tutun (gizli bilgileri hariç)

• Secret'ları sadece ihtiyaç duyan servis hesaplarına açın

• ConfigMap içinde tek bir büyük yapı yerine anlamlı gruplara bölün

• Ortamlar arasında yapılandırmaları standardize edin

• YAML dosyalarını ayrı dizinlerde ve okunabilir yapıda yönetin

Esneklik ve Taşınabilirlik

Kubernetes’in modern uygulama geliştirmeye sağladığı en büyük katkılardan biri.

1. Esneklik (Flexibility)

Kubernetes, uygulamaların dağıtım ve çalıştırma süreçlerinde büyük esneklik sağlar. Bu esneklik, geliştirici ekiplerin hem uygulamaları kolayca yönetmesini hem de hızla değişiklik yapabilmesini mümkün kılar.

Öne Çıkan Esneklik Özellikleri:

a. İstenen Durum Yönetimi (Desired State)

Kubernetes, uygulamanın nasıl çalışması gerektiğini tanımlamanıza olanak tanır. Bir pod çökerse veya silinirse, Kubernetes otomatik olarak onu tekrar oluşturur.

b. Otomatik Yeniden Başlatma ve Yeniden Planlama

• Pod başarısız olursa yeniden başlatılır.

• Node arızalanırsa pod’lar başka bir node üzerinde yeniden planlanır.

c. Yüksek Erişilebilirlik

Deployment yapıları, ReplicaSet'ler ile desteklenerek uygulamanın her zaman çalışır durumda kalması sağlanır.

d. Otomatik Ölçekleme

CPU veya bellek kullanımına göre pod sayısı otomatik olarak arttırılıp azaltılabilir. (Horizontal Pod Autoscaler)

e. Güncelleme Esnekliği

• Rolling update ile kesintisiz sürüm geçişleri yapılabilir.

• Geri alma (rollback) mekanizması ile hatalı dağıtımlar hızlıca eski haline getirilebilir.

f. Kaynak Tabanlı Konfigürasyonlar

Uygulamanın ihtiyaç duyduğu her bileşen YAML dosyalarında tanımlanır. Bu sayede yapılandırmalar versiyonlanabilir ve kolayca yönetilebilir.

2. Taşınabilirlik (Portability)

Taşınabilirlik, Kubernetes’in en güçlü yönlerinden biridir. Uygulamalarınızı farklı altyapılar arasında taşımanız mümkündür.

Neden Taşınabilir?

a. Bulut Sağlayıcı Bağımsızlığı

Aynı Kubernetes yapılandırması;

• AWS

• Google Cloud (GKE)

• Microsoft Azure (AKS)

• IBM Cloud

• On-premise veri merkezleri

• Minikube veya Docker Desktop gibi yerel ortamlar

gibi farklı ortamlarda sorunsuz çalıştırılabilir.

b. Platformdan Bağımsız Konfigürasyon

Kubernetes’in deklaratif yapıdaki YAML dosyaları platform bağımsızdır. Bir ortamdan diğerine geçerken sadece birkaç küçük ayarlama gerekebilir (örn. storage class, load balancer tipi).

c. Mikroservis Mimarisi ile Uyum

Kubernetes, mikroservis tabanlı sistemlerin taşınabilirliğini kolaylaştırır. Her bileşen izole çalışır, bağımsız ölçeklenir ve farklı ortamlarda sorunsuz taşınabilir.

d. CI/CD Entegrasyonu

CI/CD süreçleriyle entegre Kubernetes yapıları, otomatik deploy ve test işlemleriyle her ortamda aynı sonucu verir.

Senaryo: Geliştirme Ortamından Üretime

1. Geliştirici yerel ortamında (Docker Desktop + Kubernetes) uygulamasını test eder.

2. Aynı YAML dosyaları staging ortamında uygulanır.

3. Hiçbir değişiklik yapmadan üretim ortamına alınır.

4. Hangi bulut sağlayıcısı olursa olsun aynı mantıkla çalışır.

En İyi Uygulamalar

• YAML dosyalarını yeniden kullanılabilir şablonlar şeklinde tasarlayın (örneğin Helm ile)

• Ortam değişkenlerini dışsallaştırarak yapılandırma bağımsızlığı sağlayın

• CI/CD süreciyle taşınabilirliği destekleyin

• Bulut sağlayıcıya özgü kaynakları izole edin veya soyutlayın

Dinamik Güncelleme (Dynamic Updates) Nedir?

Dinamik güncelleme, Kubernetes ortamında çalışan bir uygulamanın çalışma süresi (runtime) sırasında, yeniden başlatmaya gerek kalmadan konfigürasyon veya yapılandırma değerlerinin güncellenebilmesini sağlar.

Bu kavram, özellikle modern mikroservis mimarilerinde hızlı, kesintisiz ve güvenli güncellemeler yapılabilmesi açısından kritik öneme sahiptir.

Dinamik Güncellemenin Sağladığı Avantajlar

• Kesintisiz hizmet: Uygulama yeniden başlatılmadan yeni yapılandırmalar alınabilir.

• Hızlı müdahale: Konfigürasyonlarda değişiklik gerektiğinde anında uygulanabilir.

• Çeviklik: Geliştirme ve operasyon ekiplerinin hızlı iterasyon yapmasına olanak sağlar.

• Kaynak verimliliği: Pod yeniden yaratma, ölçekleme, servis kesintisi gibi maliyetler minimize edilir.

Kubernetes'te Dinamik Güncelleme Nerelerde Kullanılır?

1. ConfigMap ile Konfigürasyon Güncelleme

ConfigMap objeleri, uygulama yapılandırmalarını dışsallaştırmak için kullanılır. Aşağıdaki senaryolarda dinamik güncellemeye imkan tanır:

a. Volume Mount ile

ConfigMap, bir dosya sistemi olarak pod içinde mount edilir. Bu dosya sisteminde yapılan değişiklikler konteynerde otomatik olarak güncellenir.

⚠️ Ancak, uygulamanın bu dosyaları dinamik olarak yeniden okuması gerekir. Örneğin, bazı uygulamalar yapılandırma dosyasını belleğe alır ve yeniden okuma yapmaz.

b. Environment Variable ile

ConfigMap verisi environment değişkeni olarak geçirilirse, güncellemeler sadece pod yeniden başlatıldığında alınır. Bu durumda dinamik güncelleme mümkün değildir.

2. Secret ile Hassas Bilgi Güncelleme

Secret kaynakları da aynı ConfigMap gibi volume olarak mount edilebilir. Secret değerleri değiştirildiğinde, mount edilen dosyada otomatik olarak güncellenir.

• Uygulama bu dosyaları izleyebiliyorsa, şifre gibi bilgileri yeniden alabilir.

• Secret değişiklikleri, rolling update veya pod restart ile de aktarılabilir.

3. Sidecar Container ile İzleme ve Yeniden Yükleme

Bazı mimarilerde, yapılandırma değişikliklerini izlemek için ek bir "sidecar" konteyner kullanılır. Bu konteyner:

• ConfigMap/Secret dosyalarını izler.

• Ana uygulamaya "yeniden yükle" sinyali gönderir (örn. SIGHUP).

• Ana uygulama bu sinyal ile konfigürasyonunu yeniden okur.

Örneğin: Nginx, SIGHUP sinyali ile konfigürasyon dosyasını yeniden yükleyebilir.

Uygulamalı Senaryo: Dinamik Log Seviyesi Değişikliği

1. Bir mikroservis uygulaması, log_level değerini bir ConfigMap dosyasından okur.

2. ConfigMap bir volume olarak mount edilmiştir.

3. Uygulama, bu dosyayı düzenli olarak kontrol eder.

4. Log seviyesi info iken, ConfigMap içeriği değiştirilir: log_level: debug

5. Dosya sistemi otomatik olarak güncellenir.

6. Uygulama bunu algılar ve debug seviyesinde loglama yapmaya başlar.

7. Pod yeniden başlatılmaz, kesinti yaşanmaz.

Sınırlamalar ve Dikkat Edilmesi Gerekenler

• Uygulamanın dinamik yükleme desteği olması gerekir (örn. dosya izleme, sinyal işleme).

• Volume mount edilen ConfigMap’lerde değişiklikler genellikle birkaç saniye içinde uygulanır (default: 1-2 saniye).

• Environment variable ile geçirilen konfigürasyonlar yeniden başlatma gerektirir.

• Her uygulama veya dil bu özelliği desteklemeyebilir.

ConfigMap’in Kullanım Senaryoları

ConfigMap, Kubernetes ortamında uygulama yapılandırma verilerini dışsallaştırmak için kullanılan bir nesnedir. Koddan bağımsız bir şekilde yapılandırma yönetimi sağlar. Mikroservis mimarilerinde yapılandırmaları merkezi ve dinamik bir şekilde yönetmek için kritik bir araçtır.

Aşağıda ConfigMap'in kullanım alanlarını farklı senaryolarla detaylı şekilde inceleyelim:

1. Environment Değişkeni Olarak Kullanım

? Senaryo:

Bir mikroservis uygulamasında, log seviyesi, port numarası veya dış API adresi gibi yapılandırmaların container içine environment değişkeni olarak geçirilmesi gerekir.

✅ Nasıl Kullanılır?

env:

  - name: LOG_LEVEL

    valueFrom:

      configMapKeyRef:

        name: app-config

        key: log_level

? Avantaj:

• Basit ve hızlı konfigürasyon aktarımı.

• Kod değişmeden konfigürasyon güncellenebilir.

⚠️ Sınırlama:

• Güncelleme sonrası pod yeniden başlatılmadan yeni değer etkin olmaz.

2. Volume Mount ile Dosya Sistemi Olarak Kullanım

? Senaryo:

Uygulamanız, geleneksel .ini, .properties, .conf gibi dosya bazlı konfigürasyonlar kullanıyor. ConfigMap ile bu dosyalar pod içinde dosya sistemi olarak mount edilebilir.

✅ Nasıl Kullanılır?

volumeMounts:

  - name: config-volume

    mountPath: /etc/config

volumes:

  - name: config-volume

    configMap:

      name: app-config

? Avantaj:

• Dosyaya erişen uygulamalar kolayca yapılandırmaları okuyabilir.

• Güncellenebilir yapı sağlar (özellikle watch eden uygulamalarda).

⚠️ Sınırlama:

• Uygulamanın bu dosyaları dinamik olarak yeniden okuma yeteneği olmalı.

3. Pod Başlatma Komutları veya Argümanlarında Kullanım

? Senaryo:

Bazı uygulamalar, başlatılırken komut satırı argümanlarına ihtiyaç duyar. Bu argümanlar ConfigMap’ten çekilebilir.

✅ Örnek:

args:

  - "--config=$(CONFIG_PATH)"

env:

  - name: CONFIG_PATH

    valueFrom:

      configMapKeyRef:

        name: app-config

        key: config_path

? Avantaj:

• Başlangıç davranışı esnek şekilde yönetilebilir.

• CI/CD pipeline’larında uygulama parametrelerini değiştirmek kolaylaşır.

4. Ortak Konfigürasyonların Paylaşımı

? Senaryo:

Aynı namespace altında çalışan birçok pod, aynı konfigürasyonları kullanıyor (örneğin; ortak bir servis URL’si, redis sunucusu adresi).

✅ Avantaj:

• Merkezi bir yapılandırma kaynağı oluşturulabilir.

• Tüm pod’lar bu ConfigMap’e referans verebilir.

• Tek bir noktadan güncelleme ile birçok uygulama etkilenebilir.

5. CI/CD ve Uygulama Versiyonları Arası Geçişlerde Kullanım

? Senaryo:

Farklı ortamlarda (dev, staging, prod) çalışan aynı uygulamanın, farklı yapılandırma değerlerine ihtiyacı vardır.

✅ Uygulama:

• Her ortam için farklı ConfigMap tanımlanır.

• Ortama göre hangi ConfigMap kullanılacağı belirtilir (örneğin: config-dev, config-prod).

? Avantaj:

• Kod tekrarına gerek kalmadan yapılandırma ortam bazlı yönetilir.

• CI/CD pipeline’larında config set’leri kolayca entegre edilebilir.

6. Dinamik Güncelleme Senaryoları

? Senaryo:

Uygulama çalışırken konfigürasyon değişikliği yapılması gerekiyor (örn. log seviyesi).

✅ Yöntem:

• ConfigMap volume mount edilir.

• Uygulama dosya değişikliklerini izler ve gerektiğinde reload eder.

Örnek: Nginx, Prometheus, Spring Boot uygulamaları bu tarz dinamik reload özelliklerine sahiptir.

7. Uygulama Özelleştirmeleri ve Özellik Bayrakları (Feature Flags)

? Senaryo:

Yeni bir özelliği yalnızca belirli ortamda veya kullanıcıda aktif etmek istiyorsunuz. ConfigMap içinde özellik bayrakları (flags) tutularak uygulama davranışı koşullandırılabilir.

? Avantaj:

• A/B testleri ve kademeli geçişler yapılabilir.

• Mikroservis davranışları dinamik olarak kontrol edilebilir.

1. ConfigMap Nedir?

ConfigMap, uygulamalara yapılandırma verilerini dışarıdan sağlamak amacıyla kullanılan bir Kubernetes nesnesidir. Pod’lara environment değişkeni, dosya veya komut satırı argümanı olarak entegre edilebilir.

2. Örnek ConfigMap YAML Tanımı

apiVersion: v1

kind: ConfigMap

metadata:

  name: app-config

  namespace: default

data:

  LOG_LEVEL: "debug"

  MAX_CONNECTIONS: "200"

  FEATURE_FLAG: "true"

3. Bölüm Bazlı İnceleme

apiVersion

apiVersion: v1

• Bu nesne v1 API versiyonuna aittir. ConfigMap nesnesi için daima v1 kullanılır.

kind

kind: ConfigMap

• Oluşturulan nesnenin türünü belirtir. Bu örnekte ConfigMap.

metadata

metadata:

  name: app-config

  namespace: default

• name: ConfigMap’in adıdır. Diğer kaynaklarda bu adla referans verilir.

• namespace: Bu ConfigMap’in ait olduğu isim alanıdır. Belirtilmezse varsayılan olarak default kullanılır.

data

data:

  LOG_LEVEL: "debug"

  MAX_CONNECTIONS: "200"

  FEATURE_FLAG: "true"

• data bölümü, anahtar-değer çiftlerinden oluşur.

• Anahtarlar string, değerler de string formatındadır.

• Birden fazla yapılandırma parametresi tek bir ConfigMap içinde tanımlanabilir.

4. Alternatif Yapılandırma Biçimi: Dosya İçeriği

apiVersion: v1

kind: ConfigMap

metadata:

  name: nginx-config

data:

  nginx.conf: |

    server {

      listen 80;

      location / {

        root /usr/share/nginx/html;

        index index.html;

      }

    }

• | işareti çok satırlı verileri ifade eder.

• Dosya biçimindeki içerikler genellikle volume olarak mount edilir.

5. ConfigMap Kullanım Biçimleri

a) Environment Değişkeni Olarak

env:

  - name: LOG_LEVEL

    valueFrom:

      configMapKeyRef:

        name: app-config

        key: LOG_LEVEL

b) Tüm Anahtarları Environment Değişkeni Olarak

envFrom:

  - configMapRef:

      name: app-config

c) Dosya Olarak Volume Şeklinde Kullanım

volumes:

  - name: config-volume

    configMap:

      name: app-config

volumeMounts:

  - mountPath: /etc/config

    name: config-volume

• /etc/config/LOG_LEVEL gibi dosyalar otomatik olarak oluşturulur.

6. Kısıtlamalar ve Kurallar

ÖzellikAçıklamaMaksimum boyutTek bir ConfigMap 1 MiB’tan büyük olamazSadece düz metin desteklerBinary veri içeremez (Secret kullanılır)Key ismi kurallarıASCII karakterlerle sınırlıdır, özel karakterler içeremezPod yeniden başlatımıDeğişikliklerin çoğu, pod yeniden başlatılmadan etkinleşmez

7. Uygulamalı Senaryo

Spring Boot gibi uygulamalarda application.properties dosyası şöyle tanımlanabilir:

apiVersion: v1

kind: ConfigMap

metadata:

  name: spring-config

data:

  application.properties: |

    server.port=8080

    logging.level.root=INFO

    spring.datasource.url=jdbc:mysql://mysql:3306/appdb

Bu yapılandırma, pod’a volume olarak aktarılır ve Spring Boot tarafından otomatik okunur.

Ortam Değişkeni Olarak ConfigMap Enjekte Etme

Kubernetes, uygulamalara dış yapılandırma bilgilerini sağlamak için ConfigMap nesnelerini kullanır. Bu yapılandırma verilerini pod’lara environment variable (ortam değişkeni) olarak enjekte edebilmek, uygulama ayarlarını kolayca değiştirmeye ve yapılandırma dosyalarını dışarıda tutmaya olanak sağlar.

Aşağıda, bir ConfigMap nesnesini ortam değişkeni olarak Kubernetes pod’larına nasıl enjekte edebileceğinizi detaylı şekilde anlatacağım.

1. ConfigMap’i Oluşturma

İlk adım olarak, bir ConfigMap nesnesi oluşturmamız gerekecek. Bu örnekte, uygulamanın log seviyesini ve bağlantı sayısını yapılandırmak için bir ConfigMap oluşturacağız.

ConfigMap YAML Dosyası:

apiVersion: v1

kind: ConfigMap

metadata:

  name: app-config

data:

  LOG_LEVEL: "debug"

  MAX_CONNECTIONS: "200"

Yukarıdaki ConfigMap nesnesi iki anahtar-değer çifti içeriyor:

• LOG_LEVEL: Uygulamanın log seviyesini belirtir.

• MAX_CONNECTIONS: Maksimum bağlantı sayısını belirtir.

ConfigMap’i Kubernetes’te oluşturma:

kubectl apply -f app-config.yaml

Bu komut, Kubernetes kümesinde app-config adıyla bir ConfigMap oluşturur.

2. ConfigMap’i Pod’a Ortam Değişkeni Olarak Enjekte Etme

Şimdi oluşturduğumuz ConfigMap'i, bir pod’un ortam değişkenlerine enjekte edelim. Bunun için, pod tanımındaki env kısmında ConfigMap referansını kullanacağız.

Pod YAML Dosyası:

apiVersion: v1

kind: Pod

metadata:

  name: app-pod

spec:

  containers:

    - name: app-container

      image: your-app-image

      env:

        - name: LOG_LEVEL

          valueFrom:

            configMapKeyRef:

              name: app-config

              key: LOG_LEVEL

        - name: MAX_CONNECTIONS

          valueFrom:

            configMapKeyRef:

              name: app-config

              key: MAX_CONNECTIONS

YAML Dosyasındaki Açıklamalar:

• env: Pod içindeki container’lar için ortam değişkenlerini belirtir.

• valueFrom: Değerin dış bir kaynaktan alınacağını belirtir. Bu durumda, ConfigMap'ten alınacaktır.

• configMapKeyRef: ConfigMap’in adı (app-config) ve içerdiği anahtar (LOG_LEVEL ve MAX_CONNECTIONS) belirtilir.

Yukarıdaki YAML dosyasında, app-pod isimli pod içinde LOG_LEVEL ve MAX_CONNECTIONS ortam değişkenleri, app-config isimli ConfigMap'ten alınacaktır.

Pod’u Uygulamak:

kubectl apply -f app-pod.yaml

Bu komut, belirttiğimiz ConfigMap'i pod’a enjekte edecektir.

3. Ortam Değişkenlerinin Kontrolü

Pod çalışmaya başladıktan sonra, ortam değişkenlerinin doğru bir şekilde enjekte edildiğinden emin olmak için pod’u kontrol edebiliriz.

Pod’un içinde çalışan container’ın ortam değişkenlerini görmek için aşağıdaki komutu kullanabilirsiniz:

kubectl exec -it app-pod -- printenv

Bu komut, pod’daki container’a erişip tüm ortam değişkenlerini listeleyecektir. Eğer doğru şekilde yapılandırılmışsa, LOG_LEVEL ve MAX_CONNECTIONS değerlerini burada görmelisiniz.

Örneğin:

LOG_LEVEL=debug

MAX_CONNECTIONS=200

4. ConfigMap Değiştirme ve Yeniden Yükleme

ConfigMap verileri, pod başlatıldığında yüklenir. Eğer ConfigMap verilerini değiştirdiyseniz, değişikliklerin pod’a yansıması için pod’un yeniden başlatılması gerekir.

ConfigMap’i Güncelleme:

kubectl edit configmap app-config

Bu komut, app-config ConfigMap’ini düzenlemenize olanak tanır. Burada, örneğin LOG_LEVEL’i "info" olarak değiştirebilirsiniz.

Pod’u Yeniden Başlatma:

ConfigMap değişikliklerini uygulamak için pod’u yeniden başlatmamız gerekecek. Bunun için şu komutu kullanabilirsiniz:

kubectl delete pod app-pod

Bu komut, pod’u siler ve Kubernetes yeni bir pod yaratır. Yeni pod, güncellenmiş ConfigMap ile başlatılır.

5. ConfigMap’i Tüm Pod’lara Ortam Değişkeni Olarak Enjekte Etme (Deployment Kullanımı)

Birden fazla pod çalıştırıyorsanız, aynı yapılandırmayı birden fazla pod’a uygulamak için bir Deployment kullanabilirsiniz. Deployment içerisinde de aynı ortam değişkenlerini ConfigMap'ten alarak enjekte edebilirsiniz.

Deployment YAML Örneği:

apiVersion: apps/v1

kind: Deployment

metadata:

  name: app-deployment

spec:

  replicas: 3

  selector:

    matchLabels:

      app: app

  template:

    metadata:

      labels:

        app: app

    spec:

      containers:

        - name: app-container

          image: your-app-image

          env:

            - name: LOG_LEVEL

              valueFrom:

                configMapKeyRef:

                  name: app-config

                  key: LOG_LEVEL

            - name: MAX_CONNECTIONS

              valueFrom:

                configMapKeyRef:

                  name: app-config

                  key: MAX_CONNECTIONS

Bu YAML dosyası, app-deployment adlı bir Deployment tanımlar. Bu deployment, 3 replica (yani 3 pod) oluşturur ve her pod’a aynı ConfigMap’i ortam değişkeni olarak enjekte eder.

Deployment Uygulama Komutu:

kubectl apply -f app-deployment.yaml

1. ConfigMap’i Dosya Olarak Oluşturma

İlk adım olarak, Kubernetes'te ConfigMap’i oluşturmanız gerekir. Dosya verisi, ConfigMap'in data bölümünde bir anahtar-değer çifti olarak saklanır. Bu veriler daha sonra pod içinde bir dosya olarak yer alır.

ConfigMap YAML Dosyası (Dosya İçeriği):

Örneğin, bir konfigürasyon dosyası olan app-config.conf'i ConfigMap aracılığıyla pod’a enjekte edelim.

apiVersion: v1

kind: ConfigMap

metadata:

  name: app-config

data:

  app-config.conf: |

    # Application Configuration

    LOG_LEVEL=debug

    MAX_CONNECTIONS=200

    DATABASE_URL=mysql://db.example.com:3306

Bu örnekte, app-config.conf adlı bir dosya içinde 3 satır yapılandırma bilgisi bulunuyor. Dosya içeriği ConfigMap içinde data anahtarında saklanır. | karakteri, dosya içeriğinin çok satırlı olduğunu belirtir.

ConfigMap’i Kubernetes’te oluşturma:

kubectl apply -f app-config.yaml

Bu komut, app-config adında bir ConfigMap oluşturur ve içindeki veriyi Kubernetes kümesine yükler.

2. ConfigMap’i Pod’a Dosya Olarak Enjekte Etme

ConfigMap dosyasını pod'a enjekte etmek için, pod tanımında volumes ve volumeMounts özelliklerini kullanarak dosya olarak bağlama işlemi yapılır. Bu işlem, pod’a ConfigMap'in içeriğini bir dosya olarak enjekte eder.

Pod YAML Dosyası:

apiVersion: v1

kind: Pod

metadata:

  name: app-pod

spec:

  containers:

    - name: app-container

      image: your-app-image

      volumeMounts:

        - name: config-volume

          mountPath: /etc/app/config

          subPath: app-config.conf

  volumes:

    - name: config-volume

      configMap:

        name: app-config

YAML Dosyasındaki Açıklamalar:

• volumeMounts: Pod’un container’ındaki dosya sistemine hangi ConfigMap’i nasıl bağlayacağımızı belirtir. Burada, config-volume adında bir volume bağlanır ve bu volume /etc/app/config dizinine yerleştirilir.

  • subPath: ConfigMap içinde yalnızca belirli bir dosyanın bağlanmasını sağlar. Burada app-config.conf dosyasını /etc/app/config dizinine bağlıyoruz.

• volumes: Pod’un içindeki volume'leri belirtir. Bu volume’ler ConfigMap kaynaklıdır.

  • configMap: Bu volume’un ConfigMap'ten kaynaklanacağını belirtir. name ile hangi ConfigMap’in kullanılacağı belirtilir.

Pod’u Uygulamak:

kubectl apply -f app-pod.yaml

Bu komut, app-config ConfigMap’ini app-pod isimli pod’a bir dosya olarak bağlar.

3. Dosyaya Erişim ve Kontrol

Pod çalıştıktan sonra, ConfigMap'ten enjekte edilen dosyaya pod içerisinden erişilebilir. Dosyanın doğru şekilde bağlanıp bağlanmadığını kontrol etmek için pod’un içerisine erişip dosyayı kontrol edebiliriz.

Pod İçindeki Dosyayı Kontrol Etme:

Pod içerisine giriş yaparak, dosyanın doğru bir şekilde bağlandığını kontrol edebiliriz.

kubectl exec -it app-pod -- cat /etc/app/config/app-config.conf

Bu komut, app-pod pod’undaki /etc/app/config/app-config.conf dosyasının içeriğini ekrana yazdıracaktır. Eğer dosya başarıyla bağlanmışsa, aşağıdaki gibi bir çıktı görmelisiniz:

# Application Configuration

LOG_LEVEL=debug

MAX_CONNECTIONS=200

DATABASE_URL=mysql://db.example.com:3306

4. ConfigMap’i Güncelleme ve Yeniden Yükleme

ConfigMap’teki verileri değiştirdiğinizde, pod’lar bu değişiklikleri otomatik olarak almaz. ConfigMap değişikliklerinin pod’lara yansıması için pod’ların yeniden başlatılması gerekir.

ConfigMap’i Güncelleme:

ConfigMap içeriğini değiştirmek için şu komutu kullanabilirsiniz:

kubectl edit configmap app-config

Bu komut, app-config ConfigMap'ini düzenlemenize olanak tanır. Örneğin, LOG_LEVEL değerini "info" olarak değiştirebilirsiniz.

Pod’u Yeniden Başlatma:

ConfigMap güncellemesi yapıldıktan sonra, değişikliklerin pod’lara yansıması için pod’u yeniden başlatmamız gerekir. Aşağıdaki komut, pod’u siler ve Kubernetes yeni bir pod oluşturur:

kubectl delete pod app-pod

Yeniden başlatılan pod, yeni ConfigMap içeriğini alacaktır.

5. ConfigMap’i Dosya Olarak Enjekte Etme Senaryoları

ConfigMap’in dosya olarak enjekte edilmesi, aşağıdaki senaryolarda yaygın olarak kullanılır:

1. Yapılandırma Dosyaları:

   • Uygulama yapılandırma dosyalarını (JSON, YAML, XML, vb.) Kubernetes ConfigMap ile dışarıdan yönetebilirsiniz.

2. Sertifikalar ve Anahtarlar:

   • SSL sertifikaları veya API anahtarları gibi hassas veriler için, ConfigMap'i dosya olarak kullanmak, bu verilerin container içerisinde daha güvenli bir şekilde yönetilmesini sağlar.

3. Uygulama Ayar Dosyaları:

   • Uygulamanın çalışma zamanında ihtiyacı olan yapılandırma dosyalarını (örneğin, .env dosyası) dışarıdan temin edebilir ve pod’lara enjekte edebilirsiniz.

SECRET terimi, genellikle bilgisayar bilimlerinde ve yazılım geliştirmede güvenlik ve gizlilikle ilgili önemli bir kavram olarak kullanılır. Aşağıda, "SECRET" teriminin ne olduğu ve çeşitli kullanım alanlarını detaylı olarak ele alacağız.

1. Gizli Bilgiler (Secrets) ve Güvenlik

"Secret" terimi, bir sistemdeki gizli, özel veya korunması gereken bilgileri ifade eder. Bu bilgiler genellikle bir uygulamanın veya servisin doğru çalışabilmesi için gereken ama başkalarının erişmemesi gereken verilerdir. Genellikle "secrets" terimi şunları kapsar:

• API Anahtarları: Uygulamaların dış servislerle iletişim kurabilmesi için kullanılan benzersiz anahtarlar.

• Veritabanı Parolaları: Veritabanına bağlanmak için kullanılan parolalar veya erişim bilgileri.

• Şifreler: Kullanıcıların veya sistemlerin kimlik doğrulaması için kullanılan şifreler.

• Özel Sertifikalar: TLS/SSL gibi şifreleme sertifikaları, şifreli veri iletimi için kullanılır.

• Tokenlar: Kullanıcı kimlik doğrulama süreçlerinde kullanılan belirteçler.

Bu tür bilgiler, yalnızca yetkili kişilerin erişebilmesi ve kullanabilmesi için özel olarak korunmalıdır. Eğer yanlış kişilerin eline geçerse, sistemin güvenliği ciddi şekilde tehlikeye girebilir.

2. Secret Management (Gizli Bilgi Yönetimi)

Gizli bilgilerin yönetilmesi, yazılım geliştirme süreçlerinde ve IT altyapılarında çok kritik bir yer tutar. Bu gizli bilgilerin yönetimi ve güvenli bir şekilde saklanması için kullanılan araçlar ve yöntemler Secret Management olarak adlandırılır. Bu sistemler genellikle şu özelliklere sahiptir:

• Şifreleme: Gizli bilgilerin şifrelenmesi, bu bilgilerin yalnızca doğru kişilere erişmesini sağlar.

• Erişim Kontrolleri: Kimlerin hangi bilgilere erişebileceğini belirleyen erişim kontrol mekanizmaları. Bu genellikle kullanıcı kimlik doğrulaması ve yetkilendirme ile sağlanır.

• Denetim Kaydı: Gizli bilgilere yapılan her erişim kaydedilir, böylece kim, ne zaman ve hangi bilgilere eriştiği takip edilebilir.

• Süreli Erişimler: Bazı gizli bilgilere belirli bir süre boyunca erişim izni verilir, ardından erişim otomatik olarak iptal edilir.