Ana içeriğe atla

Sebep/Neden: Pod overlay network’ü için kullanılan Flannel dosya ve ayarları sunucuda kalmakta ve manuel silinmesi gerekmektedir.

Çözüm: Control-plane Kubernetes node’unda “kubectl delete node <NODE_NAME>” ile ilgili sunucu cluster’dan çıkarılır, sonra koparılmak istenen sunucuda “sudo kubeadm reset” komutu ile de kendi üzerindeki Cluster ayarları temizlenir. Sonrasında aşağıdaki işlemler yapılır:

systemctl stop kubelet && systemctl stop containerd
rm -rf /var/lib/cni/
rm -rf /var/lib/kubelet/*
rm -rf /etc/cni/
ifconfig cni0 down && ip link delete cni0
ifconfig flannel.1 down && ip link delete flannel.1
systemctl restart containerd && systemctl restart kubelet

Sebep/Neden: RHEL 8 ve CentOS 8’in piyasaya sürülmesiyle, docker paketi varsayılan paket depolarından kaldırıldı, docker podman ve buildah ile değiştirildi. RedHat, Docker için resmi destek sağlamamaya karar verdi. Bu sebepten dolayı bu paketler docker kurulumuna engel olmaktadır.

Çözüm:

yum remove podman* -y
yum remove buildah* -y

Sebep/Neden: Linux işletim sistemlerinde genelde aktif halde gelen “swap” ve “selinux” kapatılmalıdır.

Çözüm:

sudo swapoff -a
sudo sed -i '/ swap / s/^/#/' /etc/fstab
sudo reboot
kubeadm reset
kubeadm init --ignore-preflight-errors all

Sebep/Neden: Namespace silme işlemi finalizer’lar nedeniyle takılı kalabilir.

Çözüm:

kubectl get namespace "<NAMESPACE>" -o json | tr -d "\n" | sed "s/\"finalizers\": \[[^]]\+\]/\"finalizers\": []/" | kubectl replace --raw /api/v1/namespaces/<NAMESPACE>/finalize -f -

Sebep/Neden: Eğer ilgili kurum HTTPS kullanmıyorsa docker’ın daemon dosyasına aşağıdaki satır eklenir. Docker kullanan tüm node’lar için bu işlem tekrarlanır.

Çözüm (HTTPS kullanmayan kurumlar için):

sudo vi /etc/docker/daemon.json

{
  "insecure-registries": ["hub.docker.com:443", "registry-1.docker.io:443", "quay.io"]
}

sudo systemctl daemon-reload
sudo systemctl restart docker
# Aşağıdaki ile kontrol edilir
docker info

Çözüm (HTTPS kullanan kurumlar için): Eğer ilgili kurum HTTPS kullanıyorsa ilgili kurumdan SSL sertifikasını (“crt”) sunuculara eklemesi gerekmektedir.

# Ubuntu/Debian için
cp ssl.crt /usr/local/share/ca-certificates/
update-ca-certificates
service docker restart

# CentOS 7 için
sudo cp -p ssl.crt /etc/pki/ca-trust/source
sudo cp ssl.crt /etc/pki/ca-trust/source/anchors/myregistrydomain.com.crt
sudo update-ca-trust extract
sudo systemctl daemon-reload
sudo systemctl restart docker

Sebep/Neden: Eğer ilgili kurum Nexus proxy kullanıyorsa docker’lı sunucular bu adrese yönlendirilir.

Çözüm:

sudo vi /etc/docker/daemon.json

{
  "data-root": "/docker-data",
  "insecure-registries": ["nexusdocker.kurumunadresi.com.tr"],
  "registry-mirrors": ["https://nexusdocker.kurumunadresi.com.tr"],
  "exec-opts": ["native.cgroupdriver=systemd"],
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "100m"
  },
  "storage-driver": "overlay2"
}

Sebep/Neden: Node stays on Ready, SchedulingDisabled durumunda kalabilir.

Test:

kubectl apply -f https://k8s.io/examples/admin/dns/dnsutils.yaml
kubectl get pods dnsutils
kubectl exec -i -t dnsutils -- nslookup kubernetes.default

Eğer aşağıdaki gibi sonuç alıyorsak her şey doğru:

Server:    10.0.0.10
Address 1: 10.0.0.10

Name:      kubernetes.default
Address 1: 10.0.0.1

Eğer aşağıdaki gibi sonuç alıyorsak yanlışlık var ve aşağıdaki adımların kontrol edilmesi gerekiyor:

Server: 10.96.0.10
Address 1: 10.96.0.10

nslookup: can't resolve 'kubernetes.default'
command terminated with exit code 1

Resolv.conf dosyasının içine bir göz atın:

kubectl exec -ti dnsutils -- cat /etc/resolv.conf

(Doğru)

nameserver 10.96.0.10
search default.svc.cluster.local svc.cluster.local cluster.local kurum.gov.tr
options ndots:5

(Yanlış)

nameserver 10.96.0.10
search default.svc.cluster.local svc.cluster.local cluster.local
options ndots:5

Çözüm: Bir müşteride /etc/resolv.conf dosyası içine kurumun domain adresi eklenerek çözüldü.

# search kurum.gov.tr eklenir
kubectl rollout restart -n kube-system deployment/coredns

Sebep/Neden: Ubuntu işletim sistemli sunucularda DNS sunucusu ile ilgili yapılan değişiklikler her zaman resolv.conf’a yansımayabiliyor ya da atlanabiliyor, Kubernetes varsayılan olarak kendi iç DNS’inden sonra sunucudaki cat /etc/resolv.conf dosyasına baktığı için bu dosyanın doğru olduğundan emin olunulmalıdır.

Çözüm:

Tüm sunucularda:

sudo rm /etc/resolv.conf
sudo ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf
sudo systemctl restart systemd-resolved
ls -l /etc/resolv.conf
cat /etc/resolv.conf

Sadece master sunucuda:

kubectl -n kube-system rollout restart deployment coredns

Sebep/Neden: Firewall SSL inspection yaparak kendi sertifikasını ekliyor.

Çözüm: docker.io’u firewall üzerinde “SSL inspection exception“‘a eklenecek.

Sebep/Neden: Master’da kube-flannel bir şekilde gerekli klasörü ve dosyaları oluşturamıyor.

Çözüm: (Alternatif çözümler de mevcut: GitHub Issue #54918)

sudo mkdir -p /etc/cni/net.d
sudo vi /etc/cni/net.d/10-flannel.conflist

Aşağıdaki içerik eklenir:

{
  "name": "cbr0",
  "cniVersion": "0.3.1",
  "plugins": [
    {
      "type": "flannel",
      "delegate": {
        "isDefaultGateway": true
      }
    },
    {
      "type": "portmap",
      "capabilities": {
        "portMappings": true
      }
    }
  ]
}

sudo chmod -Rf 777 /etc/cni /etc/cni/*
sudo chown -Rf apinizer:apinizer /etc/cni /etc/cni/*
sudo systemctl daemon-reload
sudo systemctl restart kubelet

# Hala imaj çekemeyen pod var mı kontrolü:
kubectl get pods -n kube-system
kubectl describe pod <podAdi> -n kube-system

Sebep/Neden: Unable to connect to the server: x509: certificate has expired or is not yet valid.

Çözüm: Bu işlemler tüm master sunucularda yapılmalıdır.

sudo kubeadm certs check-expiration
sudo kubeadm certs renew all

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

# Tüm master/control-plane node'lar
sudo reboot

# Daha fazla bilgi için:
# https://serverfault.com/questions/1065444/how-can-i-find-which-kubernetes-certificate-has-expired
# https://www.oak-tree.tech/blog/k8s-cert-yearly-renewwal

Sebep/Neden: Yukarıdaki problem aşağıdaki sebeplerin herhangi birinden dolayı ortaya çıkabiliyor:

  • Disk eklenmesi durumunda swap açılabildiği için tekrar kapatılması gerekiyor olabilir.
  • Kullanıcı yetki sahibi olmayabilir.
  • Master sunucuda olmadığımızdan olabilir.

Çözüm:

sudo swapoff -a
sudo vi /etc/fstab  # swap satırı kapatılacak ya da silinecek
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
sudo reboot  # isteğe bağlı

Sebep/Neden: Bu problemin çeşitli nedenleri olmakla birlikte hatada /etc/kubernetes/bootstrap-kubelet.conf gibi herhangi bir .conf dosyasının bulunamadığını söylüyorsa aşağıdaki işlemler uygulanarak tüm config’ler baştan oluşturulabilir.

Çözüm (Master Node): Mevcut config’ler ve sertifikalar yedek alınarak işlemler yapılır.

cd /etc/kubernetes/pki/
sudo mkdir /tmp/backup
sudo mkdir /tmp/backup2
sudo mv {apiserver.crt,apiserver-etcd-client.key,apiserver-kubelet-client.crt,front-proxy-ca.crt,front-proxy-client.crt,front-proxy-client.key,front-proxy-ca.key,apiserver-kubelet-client.key,apiserver.key,apiserver-etcd-client.crt} /tmp/backup/
sudo kubeadm init phase certs all --apiserver-advertise-address <MASTER_NODE_IP>

cd /etc/kubernetes/
sudo mv {admin.conf,controller-manager.conf,kubelet.conf,scheduler.conf} /tmp/backup2
sudo kubeadm init phase kubeconfig all
sudo systemctl restart docker && sudo systemctl restart containerd && sudo systemctl restart kubelet

Çözüm (Worker Node): Worker Node’larda da /etc/kubernetes/bootstrap-kubelet.conf dosyası bulunamama hatası meydana gelirse, node’u cluster’dan çıkarıp tekrar eklemek sorunu çözecektir.

Master node üzerinde çalıştırılacak komutlar:

# Önce problemli worker node cluster'dan çıkarılır
kubectl delete node <WORKER_NODE_NAME>

# Ardından yeni bir join token oluşturulur
sudo kubeadm token create --print-join-command

Worker node üzerinde çalıştırılacak komutlar:

# Kubernetes yapılandırması sıfırlanır
sudo kubeadm reset

# Master'dan alınan join komutunu çalıştırılır
sudo kubeadm join <MASTER_IP>:<PORT> --token <TOKEN> --discovery-token-ca-cert-hash sha256:<HASH>

Sebep/Neden: Yukarıdaki problem Private registry’den image çekerken güvenilir bir sertifikaya sahip olmadığınızda ortaya çıkan bir sorundur.

Çözüm: Çözümü -skip-verify parametresi ile sağlıyoruz. Örnek olarak “k8s.io” namespace içine dahil eden komut:

ctr --namespace k8s.io images pull xxx.harbor.com/apinizercloud/managerxxxx -skip-verify

Sebep/Neden: Kubernetes, podları dengeli bir şekilde dağıtmaz çünkü varsayılan olarak podlar, belirli bir strateji veya sınırlama olmadan, mevcut kaynaklara göre en uygun görülen düğümlere yerleştirilir.

Çözüm: Pod Topology Spread Constraints kullanarak podların dengeli bir şekilde nasıl dağıtılacağını gösteren YAML dosyasını, ikinci spec bölümünden sonra ekleyiniz.

spec:
  topologySpreadConstraints:
    - maxSkew: 1
      topologyKey: kubernetes.io/hostname
      whenUnsatisfiable: ScheduleAnyway
      labelSelector:
        matchExpressions:
          - key: node-role.kubernetes.io/control-plane
            operator: DoesNotExist
Uyarı: Kontrol plane etiketi kullanarak podların bu düğümlere yerleşmesini engellemek istiyorsanız, kontrol plane düğümlerinin doğru şekilde etiketlendiğinden emin olun.

Kontrol: Aşağıdaki komut ile node üzerinde node-role.kubernetes.io/control-plane etiketinin olup olmadığını kontrol edebilirsiniz.

kubectl get nodes --show-labels

Sebep/Neden: Kubernetes’te bir düğüm beklenmedik şekilde kapandığında (Non-Graceful Shutdown), Kubernetes Master bu durumu algılayarak gerekli işlemleri yapar. Ancak bu algılama süreci, sistemin zaman aşımı parametrelerine bağlı olduğu için gecikebilir.

Çözüm: Bu süreyi ayarlamak için dikkate alınması gereken başlıca parametreler şunlardır:

1. Node Status Update Frequency

kubelet --node-status-update-frequency=5s
  • Node Status Update Frequency parametresi bir düğümde çalışan Kubelet tarafından Kubernetes API sunucusuna düğümün durumunun ne sıklıkla güncelleneceğini belirler, varsayılan olarak 10s değerindedir.
  • Kubelet’in düğüm durumu güncellemelerini daha sık yapması için bu değeri varsayılan değerden daha düşük girebiliriz, bu da Kubernetes’in kesintileri daha hızlı algılamasına olanak tanır.

2. Node Monitor Grace Period

kube-apiserver --node-monitor-grace-period=20s
  • Node Monitor Grace Period parametresi, API sunucusunun bir düğümü “NotReady” durumuna geçirmeden önce bekleyeceği maksimum süreyi belirler, varsayılan olarak 40s değerindedir.
  • API sunucusunun düğümü “NotReady” olarak işaretlemesi daha kısa sürede veya daha geç sürede gerçekleşmesi için bu default değer değiştirilebilir.

3. Pod Eviction Timeout

kube-controller-manager --pod-eviction-timeout=2m
  • Pod Eviction Timeout bir düğüm “NotReady” durumuna geçtikten sonra, düğümdeki pod’ların başka düğümlere yeniden yerleştirilmesi (eviction) için beklenilecek maksimum süreyi tanımlar, varsayılan olarak 5 dakika değerindedir.
  • Düğüm üzerindeki pod’lar, daha hızlı bir şekilde diğer düğümlere taşınması için varsayılan değer değiştirilebilir.

Sebep/Neden: Kubernetes cluster’da hali hazırda çalışan bir worker node’un klonu cluster’a dahil edildiğinde, bazı yapılandırmalar ve kimlik bilgileri eski node ile çakışabilmektedir. Bu çakışmalar şunları içerir:

  • Duplicate machine-id değerleri
  • Eski Kubernetes yapılandırma kalıntıları
  • CNI ve overlay network yapılandırma çakışmaları

Çözüm:

1. Kubeadm reset. Klonlanmış worker node’un mevcut cluster yapılandırmasını tamamen sıfırlanır:

sudo kubeadm reset
sudo rm -rf $HOME/.kube

2. Kubernetes’in Oluşturduğu Overlay Network Temizlenir. CNI ve diğer ağ bileşenleri temizlenir:

rm -rf /var/lib/cni/
rm -rf /var/lib/kubelet/*
rm -rf /etc/cni/
ifconfig cni0 down && ip link delete cni0
ifconfig flannel.1 down && ip link delete flannel.1
systemctl restart containerd && systemctl restart kubelet

3. Klonlanan makinenin machine-id’si resetlenir. İşletim sistemine göre machine-id’yi yeniden oluşturulur:

# RHEL için machine-id değiştirme komutu
rm -f /etc/machine-id
systemd-machine-id-setup

# Ubuntu için machine-id değiştirme komutu
rm -f /etc/machine-id /var/lib/dbus/machine-id
systemd-machine-id-setup
cat /etc/machine-id > /var/lib/dbus/machine-id

4. Cluster’a Yeniden Katılma. Master node üzerinden join komutu alınır ve klonlanan node’da çalıştırılır:

kubeadm token create --print-join-command
Bu işlemler mevcut çalışma ortamında kesintilere sebep olabileceği bilerek yapılmalıdır.

Sebep/Neden: Kubernetes cluster’da hali hazırda çalışan bir worker node’un hostname’i değiştirildiğinde, bazı yapılandırmalar ve kimlik bilgileri eski hostname ile çakışabilmektedir. Bu yüzden bu işlemi yaparken cluster’dan hostname’i değiştirilecek worker node çıkartılıp hostname bilgisi değiştikten sonra eklenmelidir.

Çözüm:

1. Drain ve Delete Node. Cluster’daki master node’a bağlanılır:

kubectl get nodes
kubectl drain <NODES_OLD_HOSTNAME> --ignore-daemonsets --delete-emptydir-data
kubectl delete node <NODES_OLD_HOSTNAME>

2. Hostname’in Değişeceği Worker Node’a Bağlanılır. Hostname değiştirildikten sonra CNI ve diğer ağ bileşenleri temizlenir:

sudo kubeadm reset
sudo hostnamectl set-hostname <NODES_NEW_HOSTNAME>
sudo reboot

hostname
# /etc/hosts üzerinde 127.0.0.1 ip'sine karşılık eski hostname duruyorsa bu kısım da yeni hostname ile değiştirilmelidir.
sudo vi /etc/hosts

rm -rf /var/lib/cni/
rm -rf /var/lib/kubelet/*
rm -rf /etc/cni/

systemctl stop kubelet && systemctl stop containerd

ifconfig cni0 down && ip link delete cni0
ifconfig flannel.1 down && ip link delete flannel.1

systemctl restart containerd && systemctl restart kubelet

3. Cluster’a Yeniden Katılma. Master node üzerinden join komutu alınır ve klonlanan node’da çalıştırılır:

kubeadm token create --print-join-command

Sebep/Neden: Linux kernel, altta çalışan dosya sisteminde (ext4, xfs vb.) bir hata tespit ettiğinde veri bütünlüğünü korumak amacıyla ilgili disk bölümü otomatik olarak read-only moda alır. Kubernetes, bir node’da disk hatası veya başka kritik sistem sorunları tespit ettiğinde, otomatik olarak o node’u pod almaz hale getirmek için bir taint ekler: node.kubernetes.io/unschedulable:NoSchedule

Çözüm:

1. Sunucu reboot edilir

sudo reboot

Node’un disk veya sistem hatası varsa reboot sonrası bazı sorunlar düzeltilebilir.

2. Node üzerindeki taint kaldırılır

kubectl taint nodes <node-name> node.kubernetes.io/unschedulable:NoSchedule-

3. Node hâlâ pod kabul etmiyorsa uncordon uygulanır

kubectl uncordon <node-name>

Uncordon komutu, node’u schedulable hale getirir ve unschedulable taint’inin arka planda kaldırılmasını garanti eder.

Sebep/Neden: Sunucu paket güncellemesiyle birlikte Docker sürümünü upgrade yapılınca karşılaşılan bir hatadır. Kubernetes 1.18, Docker sürümünü desteklemediği için kubelet ile Docker arasındaki iletişimde uyumsuzluk oluşmasından kaynaklanır.

Çözüm: Docker sürümü Kubernetes 1.18 ile uyumlu olan 18-19-20 versiyonlarıyla downgrade edilerek sorun çözülür.

# İmajın varlığı ve inspect'in çalıştığı kontrol edilir
docker inspect k8s.gcr.io/kube-scheduler:v1.18.20

# Docker versiyonu kontrol edilir
docker --version

# Mevcut docker paketleri kaldırılır
sudo apt remove -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

# Uygun docker versiyonlarını listelenir
apt-cache madison docker-ce | grep 19.03

# Docker 19.03 sürümünü kurulur
sudo apt install -y docker-ce=5:19.03.15~3-0~ubuntu-focal \
    docker-ce-cli=5:19.03.15~3-0~ubuntu-focal \
    containerd.io

# Versiyon kontrol edilir
docker --version

# Yanlış güncelleme yapılmasını engellemek için paketler hold komutu ile sabitlenir
sudo apt-mark hold docker-ce docker-ce-cli containerd.io

# Docker ve kubelet servisleri restart edilir
sudo systemctl restart docker.service
sudo systemctl restart kubelet.service

Sebep/Neden: net.bridge.bridge-nf-call-iptables ayarının eksik olması. Kubernetes’in iptables modunda çalışan kube-proxy bileşeni, Service trafiğini yönlendirmek için Linux köprülerini kullanır. net.bridge.bridge-nf-call-iptables ayarının 0 olması, köprü trafiğinin iptables üzerinden yönlendirilmesine engel olur. Bu da Service ClusterIP’den pod IP’lerine yapılan yönlendirmelerde karışıklıklara yol açar. Kube-proxy bu durumda genellikle şu uyarıyı verir: “Missing br-netfilter module or unset sysctl br-nf-call-iptables…”

Çözüm: sysctl ayarını düzelterek Service yönlendirmesini etkinleştirmeniz gerekmektedir. Tüm Kubernetes Düğümleri Üzerinde Uygulanmalıdır.

1) Ayarı Yapılandırma Dosyasına Eklemek (veya Kontrol Etmek): Aşağıdaki ayarın 1 olarak yapıldığından emin olun. Yapılandırma dosyasını şu komutla açabilirsiniz:

sudo vi /etc/sysctl.d/k8s.conf

Dosyaya aşağıdaki satırı ekleyin (ya da var ise 1 olarak düzenleyin):

net.bridge.bridge-nf-call-iptables = 1

2) Ayarları Anında Yüklemek: Dosyadaki değişiklikleri sisteme yüklemek için şu komutu çalıştırın:

sudo sysctl --system

3) Ayarları Doğrulamak: Yapılandırma doğrulaması yapmak için şu komutu kullanın:

sudo sysctl net.bridge.bridge-nf-call-iptables

Çıktı 1 olarak dönmelidir.

4) Kube-proxy’yi Yeniden Başlatmak: Kube-proxy’nin yeni ayarları alabilmesi için aşağıdaki komutla pod’u yeniden başlatın:

kubectl delete pod -n kube-system -l k8s-app=kube-proxy

Bu adımlar uygulandığında, Manager Pod’dan Worker Pod’a ClusterIP üzerinden yapılan bağlantılarda oluşan timeout sorunları çözülecektir.