Bileşen IP Değişiminde Etkiler ve Müdahale

Altyapı bileşenlerinde IP veya hostname değişikliği, Apinizer'ın bağlantı noktalarını, sertifikaları ve cluster keşfini etkileyebilir. Bu sayfa, hangi bileşende değişiklik yapıldığında neyin kırıldığını, Apinizer Worker'ların çalışmaya devam edip etmeyeceğini ve müdahale sırasını tek yerde toplar.

uyarı

IP veya hostname değişikliğine başlamadan önce mümkünse bakım penceresi planlayın. Replica set ve Elasticsearch cluster işlemlerinde hata toleransına ((n-1)/2) dikkat edin.

Etki Özeti

Apinizer Worker sütunu, mevcut Worker pod'larının API trafiğini işlemeye devam edip etmediğini gösterir. Worker çalışıyor olsa bile Manager erişimi, log yazımı veya yeni yayın (re-publish) etkilenebilir.

Bileşen / Senaryo	Ne bozulur	Apinizer Worker	Müdahale bölümü
Kubernetes Control Plane IP	API server erişimi, kubeconfig, apiserver sertifikaları	Çalışır	Control Plane IP değişimi
Kubernetes → Virtual IP geçişi	Control-plane erişimi, join endpoint, HA yapılandırması	Çalışmaz	Virtual IP geçişi
Kubernetes Worker node IP	Node `NotReady`, NodePort / erişim adresi	Etkilenen node'da durur	Worker node IP değişimi
MongoDB node IP	Replica set üyeliği, Apinizer MongoDB bağlantısı	Çalışmaz	MongoDB IP değişimi
MongoDB hostname	Replica set kimliği, auth çakışması	Çalışmaz	MongoDB hostname değişimi
Elasticsearch node IP	Cluster discovery, log yazımı, Kibana erişimi	Çalışır	Elasticsearch IP değişimi
Apinizer erişim ve bağlantıları	Manager / Gateway erişimi, log konnektörü, secret URI	Çalışır	Apinizer tarafında güncelleme

Önerilen Müdahale Sırası

Yedek — Kritik yapılandırma dosyaları (mv ile taşıyın; silme işlemini doğrulamadan sonra yapın)
Veri katmanı — MongoDB, ardından Elasticsearch (Apinizer logları bu katmanlara bağlıdır)
Kubernetes — Control-plane, gerekirse VIP geçişi, worker node'lar
Apinizer — MongoDB secret / URI, Elasticsearch Connection, Gateway Access URL
Doğrulama — Doğrulama kontrol listesi

Kubernetes Control Plane IP Değişimi

Control-plane sunucusunun IP adresi değiştiğinde Kubernetes yapılandırma dosyaları ve apiserver sertifikaları güncellenmelidir. Çalışan Apinizer Worker pod'ları API trafiğini işlemeye devam eder; API server kesintisi sırasında yeni schedule veya pod restart yapılamaz.

Yapılandırma dosyaları

Aşağıdaki dosyalarda IP adreslerini yeni değerle güncelleyin:

/etc/kubernetes/admin.conf
/etc/kubernetes/controller-manager.conf
/etc/kubernetes/kubelet.conf
/etc/kubernetes/scheduler.conf
/etc/kubernetes/manifests/etcd.yaml
/etc/kubernetes/manifests/kube-apiserver.yaml

Sertifika yenileme

Mevcut apiserver sertifikalarını silmek yerine yedekleyin, ardından yeniden oluşturun:

cd /etc/kubernetes/pki
sudo mkdir -p /etc/kubernetes/pki.backup
sudo mv apiserver.crt apiserver.key apiserver-kubelet-client.crt apiserver-kubelet-client.key /etc/kubernetes/pki.backup/

sudo kubeadm init phase certs apiserver-kubelet-client
sudo kubeadm init phase certs apiserver

sudo systemctl restart kubelet

bilgi

Sertifika oluşturma aşamasında görülen bazı uyarılar göz ardı edilebilir. Sorun devam ederse Kubernetes Sertifika Kontrolü ve Yenileme sayfasına bakın.

Kubeconfig güncelleme

Mevcut kullanıcının cluster erişimi için güncel config dosyasını kopyalayın:

sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

Cluster erişimi ve node durumunu doğruladıktan sonra yedekleri silin:

sudo rm -rf /etc/kubernetes/pki.backup

Kubernetes Virtual IP Geçişi

Birden fazla control-plane node olan ortamlarda control-plane erişimini Virtual IP (VIP) veya load balancer arkasına almak için küme yeniden yapılandırılır. Bu senaryo, tek bir control-plane IP değişiminden farklıdır; HA geçişi içindir. İşlem süresince Apinizer Worker'lar çalışmaz.

Örnek ortam: control-plane-1, control-plane-2, control-plane-3, worker-1, worker-2 — küme control-plane-1 üzerinde kubeadm init ile başlatılmıştır.

Load balancer üzerinde Virtual IP tanımlayın; tüm control-plane erişimi bu VIP üzerinden 6443 portuna yönlendirilmelidir.

uyarı

Load balancer kullanılmıyorsa Keepalived ve HAProxy ile sanal IP oluşturma adımları için Kubernetes Kurulumu — Yüksek Erişilebilirlik sayfasına bakın.

Node'ları kümeden çıkarma

Aşağıdaki komut control-plane-1 hariç diğer control-plane node'larda (control-plane-2, control-plane-3) ve worker node'larda (worker-1, worker-2) çalıştırılır:

sudo kubeadm reset

control-plane-1 üzerinden diğer control-plane ve worker node'lar kümeden silinir:

kubectl delete node control-plane-2
kubectl delete node control-plane-3
kubectl delete node worker-1
kubectl delete node worker-2

bilgi

Bu senaryoda yalnızca control-plane-1 kümede kalır. Diğer control-plane ve worker node'lar VIP üzerinden yeniden join edilir.

Control-plane-1 sunucusunda yapılacaklar

Servisleri durdurma

sudo systemctl stop kubelet
sudo systemctl stop containerd

Dosya yedekleme

Silmek yerine taşıyın. Yeniden kullanılmayacak sertifikaları da yedek dizinine alın:

sudo mv -f /etc/kubernetes /etc/kubernetes.backup
sudo mv -f /var/lib/kubelet /var/lib/kubelet.backup
sudo mv -f ~/.kube/config ~/.kube/config.backup

sudo mkdir -p /etc/kubernetes/pki
sudo cp -r /etc/kubernetes.backup/pki /etc/kubernetes

sudo mkdir -p /etc/kubernetes.backup/removed-certs/etcd
sudo mv /etc/kubernetes/pki/apiserver.* /etc/kubernetes.backup/removed-certs/
sudo mv /etc/kubernetes/pki/etcd/peer.* /etc/kubernetes.backup/removed-certs/etcd/

Containerd başlatma

sudo systemctl start containerd

Kubeadm init ile Virtual IP yapılandırması

sudo kubeadm init --pod-network-cidr "10.244.0.0/16" --control-plane-endpoint <VIRTUAL_IP> --upload-certs --ignore-preflight-errors=DirAvailable--var-lib-etcd

uyarı

Kubeadm join komutlarını not edin; worker ve ek control-plane node'lar için kullanılacaktır.

Worker node'larda yapılacaklar

Servisleri durdurma

sudo systemctl stop kubelet
sudo systemctl stop containerd

Dosya yedekleme

sudo mv -f /etc/kubernetes /etc/kubernetes.backup
sudo mv -f /var/lib/kubelet /var/lib/kubelet.backup

Servisleri başlatma

sudo systemctl start containerd
sudo systemctl start kubelet

Worker join

control-plane-1'de alınan kubeadm worker join komutunu worker node'larda çalıştırın.

Diğer control-plane node'larda yapılacaklar

control-plane-2 ve control-plane-3 sunucularında kubeadm control-plane join komutunu çalıştırmanız yeterlidir.

Küme durumu kontrolü

kubectl cluster-info
kubectl get node -o wide

Yedek dosyaların silinmesi

Doğrulama başarılı olduktan sonra tüm etkilenen node'larda yedekleri topluca silin:

sudo rm -rf /etc/kubernetes.backup
sudo rm -rf /var/lib/kubelet.backup
sudo rm -f ~/.kube/config.backup

Kubernetes Worker Node IP Değişimi

Worker node IP değiştiğinde node genellikle NotReady durumuna düşer ve NodePort / dış erişim adresleri etkilenir. Yalnızca IP'si değişen node üzerindeki Apinizer Worker'lar durur; diğer node'lardaki Worker'lar çalışmaya devam eder.

Ne bozulur

Node kaydı eski IP ile kalabilir
NodePort üzerinden Manager veya Gateway erişimi (http://<WORKER_IP>:32080 vb.) kesilir
Apinizer Gateway Runtime Erişim URL tanımı node IP'sine bağlıysa istemci erişimi bozulur

Müdahale

Worker node'da IP değişikliğini işletim sistemi seviyesinde tamamlayın (/etc/netplan, nmcli vb.)
Gerekirse node'u kümeden çıkarıp yeniden ekleyin:

# Control-plane node üzerinde
kubectl delete node <WORKER_NODE_NAME>
sudo kubeadm token create --print-join-command

# Worker node üzerinde
sudo kubeadm reset
sudo kubeadm join <CONTROL_PLANE_OR_VIP_IP>:6443 --token <TOKEN> --discovery-token-ca-cert-hash sha256:<HASH>

Load balancer veya DNS kullanıyorsanız backend pool / kayıtları güncelleyin
Apinizer tarafında güncelleme bölümündeki Gateway Access URL ve erişim adreslerini kontrol edin

MongoDB IP Değişimi

MongoDB replica set üyelerinin host alanı IP adresine bağlıdır. IP değişince Apinizer Manager, Worker ve Cache pod'ları MongoDB'ye bağlanamaz; Worker'lar çalışmaz.

uyarı

İşleme başlamadan önce MongoDB yedeği alın. Replica set hata toleransına ((n-1)/2) dikkat edin.

sudo mongodump --host localhost --port=25080 --username=apinizer --password=<PASSWORD> -d apinizerdb --authenticationDatabase=admin --gzip --archive=/home/apinizer/mongodump/apinizer-backup-<DATE>.archive

Replica set güncelleme

MongoDB'ye bağlanın:

mongosh mongodb://<NEW_MONGO_IP>:25080 --authenticationDatabase "admin" -u "apinizer" -p

Değişen üyenin host bilgisini güncelleyin (members dizinindeki indeks, değişen node'a göre ayarlanmalıdır):

cfg = rs.conf()
cfg.members[0].host = "<NEW_MONGO_IP>:25080"
rs.reconfig(cfg, { force: true })

Tüm replica set üyelerinin durumunu kontrol edin:

rs.status()

Apinizer bağlantısı

MongoDB IP değişikliğinden sonra Apinizer tarafında güncelleme bölümündeki mongo secret ve URI adımlarını uygulayın.

MongoDB Hostname Değişimi

Hostname değişikliği IP değişiminden farklıdır; replica set kimliği hostname üzerinden tanımlanır. Node'u doğrudan yeniden adlandırmak çakışmalara yol açabilir. Worker'lar replica set kimliği bozulduğu için çalışmaz.

MongoDB yedeği alın

Primary node'a bağlanın ve yedek alın. Replica set hata toleransına ((n-1)/2) dikkat edin.

mongosh mongodb://localhost:25080 --authenticationDatabase "admin" -u "apinizer" -p
sudo mongodump --host localhost --port=25080 --username=apinizer --password=<PASSWORD> -d apinizerdb --authenticationDatabase=admin --gzip --archive=/home/apinizer/mongodump/apinizer-backup-<DATE>.archive

Node'u replica set'ten çıkarın

mongosh mongodb://localhost:25080 --authenticationDatabase "admin" -u "apinizer" -p
rs.status()

# Primary ise önce rs.stepDown() ile secondary'e geçin
rs.remove("<OLD_HOSTNAME>")

Hostname değiştirin

İlgili sunucuda:

sudo systemctl stop mongod
sudo hostnamectl set-hostname <NEW_HOSTNAME>
sudo reboot

/etc/hosts dosyasında eski hostname kaydı varsa güncelleyin.

Node'u replica set'e geri ekleyin

sudo systemctl start mongod

# Primary node üzerinden
rs.add("<NEW_HOSTNAME>")
rs.status()

Elasticsearch IP Değişimi

Elasticsearch node IP değiştiğinde cluster discovery ve transport katmanı etkilenir. Apinizer API trafik logları Elasticsearch konnektörü üzerinden bu cluster'a yazılır. Worker'lar API trafiğini işlemeye devam eder; log yazımı bozulur.

Ne bozulur

Node cluster'dan düşebilir (discovery.seed_hosts, network.host)
Apinizer Elasticsearch Connection host listesi eski IP'yi gösterir
Kibana / log arama erişimi kesilir

elasticsearch.yml güncelleme

İlgili node'da elasticsearch.yml dosyasında IP'ye bağlı alanları güncelleyin:

node.name: "<NEW_NODE_IP>"
network.host: "<NEW_NODE_IP>"
cluster.initial_master_nodes: ["<NEW_NODE_IP>"]
discovery.seed_hosts: ["<NEW_NODE_IP>"]

Çok node'lu cluster'da tüm master/data node IP'lerini discovery.seed_hosts ve cluster.initial_master_nodes listelerinde tutarlı şekilde güncelleyin.

sudo systemctl restart elasticsearch

Cluster sağlığını kontrol edin:

curl -u elastic:<PASSWORD> -k "https://<NEW_NODE_IP>:9200/_cluster/health?pretty"

Apinizer Elasticsearch Connection

Management Console → Bağlantı Yönetimi → Elasticsearch konnektöründe Host & Port alanlarını yeni IP ile güncelleyin. Detay için Elasticsearch Bağlantı Yönetimi sayfasına bakın.

Apinizer Tarafında Güncelleme

Altyapı bileşenlerinde IP değişikliği tamamlandıktan sonra Apinizer'ın bu bileşenlere bağlandığı noktalar güncellenmelidir. Worker pod'ları ayaktaysa API trafiği devam eder; secret, konnektör veya erişim URL'si eski kaldığında Manager, log ve istemci erişimi bozulur.

MongoDB bağlantı secret'ı (Kubernetes)

Manager, Worker ve Cache deployment'ları MongoDB secret'ını kullanır. Secret'taki connection string yeni IP'leri içermelidir. Secret'ı YAML dosyası oluşturmadan doğrudan kubectl ile güncelleyin; kubectl değerleri otomatik olarak base64 kodlar:

kubectl create secret generic mongo-db-credentials \
  -n <NAMESPACE> \
  --from-literal=dbUrl="mongodb://<MONGO_USER>:<MONGO_PASSWORD>@<MONGO1_IP>:25080,<MONGO2_IP>:25080,<MONGO3_IP>:25080/?authSource=admin&replicaSet=apinizer-replicaset" \
  --from-literal=dbName="<MONGO_DBNAME>" \
  --dry-run=client -o yaml | kubectl apply -f -

Secret, ilgili her namespace'te güncellenmelidir. Ardından pod'ları yeniden başlatın:

kubectl rollout restart deployment/<MANAGER_DEPLOYMENT> -n <MANAGER_NAMESPACE>
kubectl rollout restart deployment/<WORKER_DEPLOYMENT> -n <WORKER_NAMESPACE>
kubectl rollout restart deployment/<CACHE_DEPLOYMENT> -n <CACHE_NAMESPACE>

not

Secret adı (mongo-db-credentials) modülün mongo.secretName değeriyle aynı olmalıdır; anahtar adları dbUrl ve dbName sabittir. Kurulum sırasında secret oluşturma adımları için Kubernetes Kurulumu sayfasına bakın.

Gateway Runtime Erişim URL

Management Console → Sunucu Yönetimi → Gateway Runtime'ları → ilgili ortam → Erişim URL Adresi alanını yeni load balancer DNS veya node IP / NodePort yapılandırmasına göre güncelleyin.

Değişiklikten sonra ortamı yeniden yayımlayın (re-publish). Detay için Gateway Runtime'ları sayfasına bakın.

Manager erişim adresi

Manager NodePort veya Ingress adresi değiştiyse kullanıcıların erişim URL'sini güncelleyin (örn. http://<NEW_WORKER_IP>:32080).

Elasticsearch konnektörü

API trafik logları Elasticsearch'e yazılıyorsa konnektör host listesini güncelleyin ve bağlantı testini çalıştırın.

hostAliases (opsiyonel)

Backend DNS çözümlemesi IP tabanlı yapılıyorsa deployment manifest'lerindeki hostAliases bloğunu yeni IP ile güncelleyin.

Doğrulama Kontrol Listesi

Kontrol	Komut / işlem	Beklenen
Kubernetes node'ları	`kubectl get node -o wide`	Tüm node'lar `Ready`
Cluster erişimi	`kubectl cluster-info`	API server yeni IP/VIP ile erişilebilir
MongoDB replica set	`rs.status()`	Tüm üyeler `PRIMARY` / `SECONDARY`, sağlıklı
Elasticsearch	`GET _cluster/health`	`status: green` veya `yellow` (kabul edilebilir)
Manager pod	`kubectl get pods -n <MANAGER_NS>`	Pod `Running` / `Ready`
Worker pod	`kubectl get pods -n <WORKER_NS>`	Pod `Running` / `Ready`
Manager UI	Tarayıcıdan Manager URL	Giriş ekranı açılır
Gateway erişimi	Gateway Access URL üzerinden health/version	Yanıt alınır
Log yazımı	Kibana veya ES index kontrolü	Yeni log kayıtları geliyor

Etki Özeti​

Önerilen Müdahale Sırası​

Kubernetes Control Plane IP Değişimi​

Yapılandırma dosyaları​

Sertifika yenileme​

Kubeconfig güncelleme​

Kubernetes Virtual IP Geçişi​

Node'ları kümeden çıkarma​

Control-plane-1 sunucusunda yapılacaklar​

Worker node'larda yapılacaklar​

Diğer control-plane node'larda yapılacaklar​

Küme durumu kontrolü​

Yedek dosyaların silinmesi​

Kubernetes Worker Node IP Değişimi​

Ne bozulur​

Müdahale​

MongoDB IP Değişimi​

Replica set güncelleme​

Apinizer bağlantısı​

MongoDB Hostname Değişimi​

Elasticsearch IP Değişimi​

Ne bozulur​

elasticsearch.yml güncelleme​

Apinizer Elasticsearch Connection​

Apinizer Tarafında Güncelleme​

MongoDB bağlantı secret'ı (Kubernetes)​

Gateway Runtime Erişim URL​

Manager erişim adresi​

Elasticsearch konnektörü​

hostAliases (opsiyonel)​

Doğrulama Kontrol Listesi​

İlgili Dokümanlar​

Etki Özeti

Önerilen Müdahale Sırası

Kubernetes Control Plane IP Değişimi

Yapılandırma dosyaları

Sertifika yenileme

Kubeconfig güncelleme

Kubernetes Virtual IP Geçişi

Node'ları kümeden çıkarma

Control-plane-1 sunucusunda yapılacaklar

Worker node'larda yapılacaklar

Diğer control-plane node'larda yapılacaklar

Küme durumu kontrolü

Yedek dosyaların silinmesi

Kubernetes Worker Node IP Değişimi

Ne bozulur

Müdahale

MongoDB IP Değişimi

Replica set güncelleme

Apinizer bağlantısı

MongoDB Hostname Değişimi

Elasticsearch IP Değişimi

Ne bozulur

elasticsearch.yml güncelleme

Apinizer Elasticsearch Connection

Apinizer Tarafında Güncelleme

MongoDB bağlantı secret'ı (Kubernetes)

Gateway Runtime Erişim URL

Manager erişim adresi

Elasticsearch konnektörü

hostAliases (opsiyonel)

Doğrulama Kontrol Listesi

İlgili Dokümanlar