Kubernetes Master Node Mimarisi ve Bileşenleri

Kubernetes cluster’ı ilk kez kurduğunuzda, “master node” kavramıyla hemen karşılaşırsınız. Peki bu node gerçekten ne yapıyor? Neden tek bir node’un çökmesi tüm cluster’ı felç edebilir? Bu yazıda master node mimarisini derinlemesine inceleyeceğiz, bileşenlerini tek tek ele alacağız ve gerçek dünya senaryolarında nasıl davranacağınızı öğreneceğiz.

Master Node Nedir ve Neden Bu Kadar Kritiktir?

Kubernetes’te master node, tüm cluster’ın beyin merkezi gibi düşünebileceğiniz kontrol düzlemidir (control plane). Worker node’lar iş yapan kaslar gibiyse, master node tüm bu kasları koordine eden sinir sistemidir. Bir pod’un nerede çalışacağına, hangi servislerin hangi endpoint’lere yönlendirileceğine, cluster durumunun nasıl korunacağına dair tüm kararlar burada alınır.

Küçük bir production ortamında bile master node’a bir şey olduğunda ne hissediyorsunuz, bunu bilen herkes master node mimarisini öğrenmeye çok daha motive oluyor. Worker node’lar bir süre kendi başlarına çalışmaya devam eder, zaten çalışan container’lar etkilenmez. Ama yeni pod schedule edemezsiniz, ölçeklendirme yapamaz, güncellemeleri uygulayamazsınız. Cluster “dondurulmuş” bir hale gelir.

Control Plane Bileşenleri

Master node üzerinde birden fazla kritik bileşen çalışır. Bunları tek tek anlamamız gerekiyor çünkü her biri farklı bir sorumluluğu üstlenir ve her biri farklı şekillerde sorun çıkarabilir.

kube-apiserver

API server, tüm Kubernetes iletişiminin geçtiği merkezi noktadır. kubectl komutları buraya gider, internal bileşenler birbirleriyle burada konuşur, external araçlar cluster’a buradan erişir. Temelde RESTful bir API sunar ve her işlem bu üzerinden geçer.

# API server durumunu kontrol etmek
kubectl get componentstatuses

# API server loglarına bakmak (kubeadm kurulumunda)
sudo journalctl -u kubelet -f | grep apiserver

# API server pod'unun logları
kubectl logs -n kube-system kube-apiserver-master-node-01 --tail=100

API server’ın önemli bir özelliği, stateless olmasıdır. Kendi başına hiçbir veri saklamaz, her şeyi etcd’ye yazar. Bu sayede teorik olarak birden fazla API server instance’ı çalıştırabilirsiniz, yani yatay ölçeklendirme mümkündür. HA (High Availability) cluster kurulumlarında bunu kullanırsınız.

etcd

etcd, Kubernetes’in beyni değil, belleğidir. Tüm cluster durumu burada saklanır. Hangi pod’ların çalıştığı, hangi servislerin var olduğu, ConfigMap’ler, Secret’lar, her şey etcd’de tutulur. Bu distributed key-value store, cluster’ın tek gerçek truth kaynağıdır.

# etcd cluster sağlığını kontrol etmek
ETCDCTL_API=3 etcdctl 
  --endpoints=https://127.0.0.1:2379 
  --cacert=/etc/kubernetes/pki/etcd/ca.crt 
  --cert=/etc/kubernetes/pki/etcd/server.crt 
  --key=/etc/kubernetes/pki/etcd/server.key 
  endpoint health

# etcd'deki tüm anahtarları listelemek
ETCDCTL_API=3 etcdctl 
  --endpoints=https://127.0.0.1:2379 
  --cacert=/etc/kubernetes/pki/etcd/ca.crt 
  --cert=/etc/kubernetes/pki/etcd/server.crt 
  --key=/etc/kubernetes/pki/etcd/server.key 
  get / --prefix --keys-only | head -30

etcd’nin çökmesi, master node’un çökmesinden bile kötü sonuçlar doğurabilir. Bu yüzden production ortamlarında etcd için ayrı backup stratejileri oluşturmanız şart. etcd snapshot almak rutin işlerinizden biri olmalı.

# etcd snapshot almak
ETCDCTL_API=3 etcdctl 
  --endpoints=https://127.0.0.1:2379 
  --cacert=/etc/kubernetes/pki/etcd/ca.crt 
  --cert=/etc/kubernetes/pki/etcd/server.crt 
  --key=/etc/kubernetes/pki/etcd/server.key 
  snapshot save /backup/etcd-snapshot-$(date +%Y%m%d-%H%M%S).db

# Snapshot doğrulama
ETCDCTL_API=3 etcdctl snapshot status /backup/etcd-snapshot-latest.db

kube-scheduler

Scheduler, yeni oluşturulan pod’lara “sen şu node’da çalış” kararını veren bileşendir. Bu kararı verirken pek çok faktörü değerlendirir: node’un kaynak kapasitesi, pod’un resource request’leri, affinity/anti-affinity kuralları, taint ve toleration’lar, custom priority class’lar.

Scheduler’ın çalışma mantığını anlamak, pod’larınızın neden beklediğiniz node’larda çalışmadığını anlamanıza yardımcı olur. Scheduler önce bir “filtering” adımı uygular, pod’u çalıştıramayacak node’ları eler. Sonra kalan node’ları “scoring” ile puanlar ve en yüksek puanlı node’u seçer.

# Scheduler loglarını görmek
kubectl logs -n kube-system kube-scheduler-master-node-01 --tail=50

# Bir pod'un neden schedule edilemediğini anlamak
kubectl describe pod <problematic-pod-name>
# Events bölümüne bakın, "FailedScheduling" mesajları olacak

# Node'lardaki mevcut kapasite durumu
kubectl describe nodes | grep -A 5 "Allocated resources"

kube-controller-manager

Controller manager, cluster’ın “desired state” ile “current state” arasındaki farkı kapatan bileşendir. İçinde onlarca controller çalışır: ReplicaSet controller (pod sayısını korur), Node controller (node’ların durumunu takip eder), Job controller, ServiceAccount controller ve daha fazlası.

Bu bileşen, Kubernetes’in self-healing özelliğinin arkasındaki asıl motorudur. Bir pod çöktüğünde onu yeniden ayağa kaldıran, bir node kaybolduğunda pod’larını başka node’lara taşıyan bu controller manager’dır.

# Controller manager loglarına bakmak
kubectl logs -n kube-system kube-controller-manager-master-node-01 --tail=50

# Controller manager konfigürasyonunu görmek
kubectl get pod kube-controller-manager-master-node-01 
  -n kube-system 
  -o yaml | grep -A 30 "command:"

Master Node Üzerindeki Statik Pod’lar

kubeadm ile kurulmuş bir cluster’da, master node bileşenleri “static pod” olarak çalışır. Bu pod’lar normal pod’lardan farklıdır: API server tarafından değil, doğrudan kubelet tarafından yönetilirler. Manifest dosyaları /etc/kubernetes/manifests/ dizininde bulunur.

# Static pod manifest dosyalarını görmek
ls -la /etc/kubernetes/manifests/
# kube-apiserver.yaml
# kube-controller-manager.yaml
# kube-scheduler.yaml
# etcd.yaml

# Bir manifest'i incelemek
cat /etc/kubernetes/manifests/kube-apiserver.yaml

Bu bilgi çok önemli çünkü bu bileşenleri düzenlemeniz gerektiğinde (örneğin özel bir flag ekleyecekseniz) kubectl kullanmak yerine doğrudan bu YAML dosyalarını düzenlersiniz. kubelet değişikliği algılar ve pod’u otomatik olarak yeniden başlatır.

High Availability Master Node Kurulumu

Production ortamı için tek master node kabul edilemez. etcd verisi dahil her şeyin tek bir noktada olması “single point of failure” oluşturur. HA setup için en az 3 master node önerilir, bu sayede etcd quorum’u sağlanır.

HA master node kurulumunda iki temel yaklaşım vardır:

Stacked etcd topology: etcd her master node üzerinde çalışır, control plane bileşenleriyle aynı node’u paylaşır. Daha az kaynak gerektirir ama bir node kaybı hem etcd hem control plane kaybı demektir.

External etcd topology: etcd ayrı node’larda çalışır. Daha dayanıklıdır ama daha fazla donanım gerektirir.

# HA cluster için ilk master'ı başlatmak
kubeadm init 
  --control-plane-endpoint "LOAD_BALANCER_DNS:6443" 
  --upload-certs 
  --pod-network-cidr=192.168.0.0/16

# Çıktıdan elde edilen join komutunu diğer master'lar için kullanmak
kubeadm join LOAD_BALANCER_DNS:6443 
  --token <token> 
  --discovery-token-ca-cert-hash sha256:<hash> 
  --control-plane 
  --certificate-key <certificate-key>

HA kurulumunda master node’ların önüne bir load balancer koymanız gerekir. Bu load balancer sadece API server trafiğini (6443 portu) dağıtır. HAProxy veya Nginx bu iş için yaygın kullanılır. Cloud ortamlarında AWS ELB, GCP Load Balancer gibi seçenekler kullanılır.

Master Node Güvenliği

Master node, saldırganlar için en değerli hedeftir. API server’a yetkisiz erişim, tüm cluster’ın ele geçirilmesi anlamına gelir. Bu yüzden master node güvenliğine özel dikkat göstermek şart.

# API server'a erişim audit logging aktifleştirmek
# /etc/kubernetes/manifests/kube-apiserver.yaml dosyasına eklemek:
# - --audit-log-path=/var/log/kubernetes/audit.log
# - --audit-log-maxage=30
# - --audit-log-maxbackup=3
# - --audit-log-maxsize=100
# - --audit-policy-file=/etc/kubernetes/audit-policy.yaml

# Basit bir audit policy örneği
cat <<EOF > /etc/kubernetes/audit-policy.yaml
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  - level: Metadata
    resources:
    - group: ""
      resources: ["secrets", "configmaps"]
  - level: RequestResponse
    resources:
    - group: ""
      resources: ["pods"]
  - level: None
    resources:
    - group: ""
      resources: ["events"]
EOF

Master node’a SSH erişimi kısıtlanmalı, network policy’ler sıkılaştırılmalı ve gereksiz servisler kapatılmalıdır. RBAC’ı doğru yapılandırmak da master node güvenliğinin ayrılmaz bir parçasıdır.

# Mevcut cluster role binding'leri görmek
kubectl get clusterrolebindings -A

# Bir service account'un yetkilerini kontrol etmek
kubectl auth can-i --list --as=system:serviceaccount:default:my-service-account

# Anonymous erişimi kontrol etmek
kubectl get clusterrolebinding cluster-admin -o yaml

Gerçek Dünya Senaryosu: Master Node Sorun Giderme

Bir sabah işe geldiniz ve monitoring dashboard’unuzda kırmızı alarmlar yanıyor. Cluster’a hiçbir şey deploy edilemiyor. kubectl komutları “Unable to connect to server” hatası veriyor. Panik yapmayın, sistematik ilerleyin.

İlk adım, master node’a SSH ile bağlanmak ve kubelet’in çalışıp çalışmadığını kontrol etmektir.

# Master node'a girdikten sonra
systemctl status kubelet
journalctl -u kubelet -n 50 --no-pager

# Static pod'ların çalışıp çalışmadığını kontrol etmek
crictl ps | grep -E "apiserver|etcd|scheduler|controller"

# API server'a local erişim denemek
curl -k https://localhost:6443/healthz

# etcd sağlık kontrolü
ETCDCTL_API=3 etcdctl 
  --endpoints=https://127.0.0.1:2379 
  --cacert=/etc/kubernetes/pki/etcd/ca.crt 
  --cert=/etc/kubernetes/pki/etcd/server.crt 
  --key=/etc/kubernetes/pki/etcd/server.key 
  endpoint status

Sertifika sorunları master node arızalarının en yaygın nedenlerinden biridir. Kubernetes sertifikaları varsayılan olarak 1 yıl geçerlidir ve süresi dolduğunda her şey durur.

# Sertifika süre kontrolü
kubeadm certs check-expiration

# Tüm sertifikaları yenilemek
kubeadm certs renew all

# Sadece belirli bir sertifikayı yenilemek
kubeadm certs renew apiserver

# Yenileme sonrası static pod'ları yeniden başlatmak için
# manifest dosyalarına küçük bir değişiklik yapıp geri almak yeterli
# ya da kubelet'i yeniden başlatmak
systemctl restart kubelet

Master Node Kaynak Yönetimi

Master node’da çalışan bileşenlerin kaynak kullanımı göz ardı edilmemeli. Özellikle büyük cluster’larda etcd ve API server bellek ihtiyacı ciddi boyutlara ulaşabilir.

etcd için disk performansı kritiktir. etcd, her yazma işleminde fsync yapar ve yavaş disk bu işlemleri ciddi ölçüde yavaşlatır. Master node için SSD kullanımı bir lüks değil, zorunluluktur. etcd’nin disk gecikmesini izlemek için:

# etcd metriklerini izlemek
ETCDCTL_API=3 etcdctl 
  --endpoints=https://127.0.0.1:2379 
  --cacert=/etc/kubernetes/pki/etcd/ca.crt 
  --cert=/etc/kubernetes/pki/etcd/server.crt 
  --key=/etc/kubernetes/pki/etcd/server.key 
  endpoint status --write-out=table

# Disk I/O performansını test etmek (etcd için)
fio --rw=write --ioengine=sync --fdatasync=1 
  --directory=/var/lib/etcd 
  --size=22m 
  --bs=2300 
  --name=etcd-test

# API server kaynak kullanımı
kubectl top pod -n kube-system | grep apiserver
kubectl top pod -n kube-system | grep etcd

API server için önemli parametrelerden biri --max-requests-inflight ve --max-mutating-requests-inflight‘dır. Büyük cluster’larda bu değerleri artırmak gerekebilir ama dikkatli olmak lazım, fazla concurrent request belleği şişirir.

etcd Backup ve Recovery Stratejisi

etcd backup stratejisi olmadan production Kubernetes cluster’ı çalıştırmak, yedeksiz production database’i çalıştırmak gibidir. Daha önce kısa bir backup örneği verdik ama bunu bir cron job haline getirip düzenli yapmak gerekiyor.

#!/bin/bash
# /usr/local/bin/etcd-backup.sh

BACKUP_DIR="/backup/etcd"
DATE=$(date +%Y%m%d-%H%M%S)
BACKUP_FILE="${BACKUP_DIR}/etcd-snapshot-${DATE}.db"
RETENTION_DAYS=7

mkdir -p ${BACKUP_DIR}

ETCDCTL_API=3 etcdctl 
  --endpoints=https://127.0.0.1:2379 
  --cacert=/etc/kubernetes/pki/etcd/ca.crt 
  --cert=/etc/kubernetes/pki/etcd/server.crt 
  --key=/etc/kubernetes/pki/etcd/server.key 
  snapshot save ${BACKUP_FILE}

if [ $? -eq 0 ]; then
  echo "Backup basarili: ${BACKUP_FILE}"
  # Eski backup'ları temizle
  find ${BACKUP_DIR} -name "etcd-snapshot-*.db" 
    -mtime +${RETENTION_DAYS} -delete
else
  echo "HATA: Backup basarisiz!" >&2
  exit 1
fi

Bu script’i crontab’a ekleyerek düzenli çalıştırabilirsiniz:

# Crontab'a eklemek
echo "0 */6 * * * root /usr/local/bin/etcd-backup.sh >> /var/log/etcd-backup.log 2>&1" 
  >> /etc/cron.d/etcd-backup

etcd restore işlemi ise dikkat gerektiren bir süreçtir. Restore öncesi tüm control plane bileşenlerini durdurmak ve etcd data dizinini temizlemek gerekir.

Master Node İzleme

Master node bileşenlerini izlemek için Prometheus ve Grafana en yaygın kullanılan araçlardır. Kubernetes, kube-state-metrics ve metrics-server aracılığıyla zengin metrik sağlar.

İzlemeniz gereken kritik metrikler şunlardır:

etcd_server_leader_changes_seen_total: Bu değerin sık artması etcd stabilite sorununa işaret eder
etcd_disk_wal_fsync_duration_seconds: 10ms üzerindeyse disk yavaş demektir
apiserver_request_duration_seconds: API server yanıt süresi
apiserver_current_inflight_requests: Anlık request sayısı
scheduler_scheduling_duration_seconds: Pod schedule edilme süresi

# kube-state-metrics deploy etmek
kubectl apply -f https://github.com/kubernetes/kube-state-metrics/releases/download/v2.10.0/standard/kube-state-metrics.yaml

# Metrics server kurulumu
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

# Control plane metriklerine erişim
kubectl get --raw /metrics | grep apiserver_request_duration

Alerting kurallarınız arasında mutlaka şunlar olmalı: etcd member sayısı düştüğünde, API server error rate belirli bir eşiği aştığında, sertifikaların sona ermesine 30 günden az kaldığında uyarı almalısınız.

Master Node Bakım Prosedürleri

Master node üzerinde bakım yaparken dikkatli olmak gerekir. HA cluster’da bir master’ı drain edebilirsiniz ama single master ortamında bu mümkün değildir.

# HA cluster'da bir master node'u bakıma almak
kubectl drain master-node-02 
  --ignore-daemonsets 
  --delete-emptydir-data 
  --force

# Bakım tamamlandıktan sonra node'u geri almak
kubectl uncordon master-node-02

# Master node üzerindeki taint'leri kontrol etmek
kubectl describe node master-node-01 | grep Taints
# NoSchedule taint'i olmalı, user workload'ları buraya schedule edilmemeli

# Eğer master node'a iş yükü schedule etmek istiyorsanız
# (genellikle önerilmez)
kubectl taint nodes master-node-01 
  node-role.kubernetes.io/control-plane:NoSchedule-

Kubernetes version upgrade işlemi de master node’dan başlar. kubeadm bu süreci büyük ölçüde otomatize eder ama yine de dikkatli planlama gerektirir.

# Mevcut versiyon bilgisini görmek
kubectl version
kubeadm version

# Upgrade planını görmek
kubeadm upgrade plan

# Master node'u upgrade etmek
apt-get update && apt-get install -y kubeadm=1.29.0-00
kubeadm upgrade apply v1.29.0

# kubelet ve kubectl'i de upgrade etmek
apt-get install -y kubelet=1.29.0-00 kubectl=1.29.0-00
systemctl daemon-reload
systemctl restart kubelet

Sonuç

Master node, Kubernetes cluster’ının kalbidir ve bu kalbin nasıl çalıştığını anlamak her Kubernetes yöneticisi için zorunludur. API server, etcd, scheduler ve controller manager her biri kritik bir rol üstlenir ve bunlardan herhangi birinin sorun yaşaması tüm cluster operasyonlarını etkiler.

Production ortamı için çıkarılacak dersler nettir: Tek master node asla yeterli değildir, HA kurulum zorunludur. etcd backup’ları düzenli alınmalı ve dışarıda saklanmalıdır. Sertifika sona erme tarihleri izlenmelidir. Disk performansı etcd için kritiktir, SSD kullanın. Master node kaynak kullanımı sürekli izlenmelidir.

Kubernetes’in karmaşık görünen yapısı, aslında birbirini dengeleyen ve denetleyen bu bileşenlerin uyumlu çalışmasıyla anlam kazanır. Master node mimarisini kavradığınızda, cluster’da karşılaştığınız sorunlara nereden başlayacağınızı bilirsiniz ve bu, bir sysadmin için en değerli bilgidir: doğru soruyu sormak.

Web Sunucuları

Mail Sunucuları

Veritabanı Sunucuları

DNS ve Alan Adı

Linux Sistem Yönetimi

Linux Güvenlik

Ağ Güvenliği

Windows Server

Konteyner ve Sanallaştırma

Otomasyon ve Scripting

Sunucu İzleme ve Performans

Hata Ayıklama

Wordpress

Sunucu & YAPILANDIRMA

GELİŞTİRİCİ ARAÇLARI

SEO & WEB

GÜvenlik & E POSTA

Kubernetes Mimari Rehberi: Master Node Bileşenleri ve İşleyişi