Docker, Containerd ve Kubernetes kurulumları ve kullanımları sırasında bazen sorunlarla karşılaşılabilinir. Bu durumlardan sık karşılaşılanlar için bu sayfadaki örnekleri inceleyebilirsiniz.



Problem

Bir Kubernetes Cluster'ından çıkarılan sunucunun bir başka Kubernetes Cluster'ına eklenmesi sırasında doğru overlay network ip'sini alamaması

Sebep/NedenPod 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 clusterdan çı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


Problem

Centos 8.3.x sunucularına docker kurulurken alınan hata

Sebep/NedenRHEL 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 olmakta.
Çözümyum remove podman* -y
yum remove buildah* -y

Problem

kubeadm error: "kubelet isn’t running or healthy and connection refused"

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

Problem

deleting namespace stuck at "Terminating" state

Sebep/Neden

deleting namespace stuck at "Terminating" state

Çözüm

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

Problem

Docker pull sırasında "x509 certificate" sorunu

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

$ 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
Sebep/NedenEğer ilgili kurum https kullanıyorsa ilgili kurumdan ssl sertifikasını ("crt") sunuculara eklemesi gerekmektedir.
Çözüm

cp ssl.crt /usr/local/share/ca-certificates/
update-ca-certificates
service docker restart


#Centos 7
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

Problem

Nexus proxy kullanılıyorsa

Sebep/NedenEğ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"

}

Problem

Kubernetes DNS Problemi (connection timed out; no servers could be reached)

Sebep/NedenNode stays on Ready,SchedulingDisabled
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

kubectl rollout restart -n kube-system deployment/coredns

Çözüm

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

search kurum.gov.tr

Problem

Kubernetes Clusterlarının bulunduğu Ubuntu sunucularda, DNS ayarlarında yapılan değişikliklerin /etc/resolv.conf dosyasına yansımaması sebebiyle HOST isimlerinin çözülemesi

Sebep/NedenUbuntu 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

Problem

docker: Error response from daemon: Get https://registry-1.docker.io/v2/: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "kurumSertifikasıAdı-CA").

Sebep/NedenFirewall ssl inspection yaparak kendi sertifikasını ekliyor.
Çözümdocker.io'u firewall üzerinde "ssl inspection exception"'a eklenecek.

Problem

Node NotReady'de kalıyor ve "Unable to update cni config: no networks found in /etc/cni/net.d"

Sebep/NedenMaster'da kube-flannel bir şekilde gerekli klasörü ve dosyaları oluşturamıyor.
Çözüm

(Alternatif çözümler de mevcut: https://github.com/kubernetes/kubernetes/issues/54918)

$ sudo mkdir -p /etc/cni/net.d

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

#aşağıdaki eklenir.

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

----------

{"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

describe pod podAdi -n kube-system

Problem

Client certificates generated by kubeadm expire after 1 year - "internal server error. Error Detail: operation: [list] for kind: [pod] with name: [null] in namespace: [prod] failed"

Sebep/Neden

Unable to connect to the server: x509: certificate has expired or is not yet 

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

sudo kubeadm alpha certs check-expiration
sudo kubeadm alpha 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

#all the nodes
sudo reboot -i

#further readings:
https://serverfault.com/questions/1065444/how-can-i-find-which-kubernetes-certificate-has-expired)
https://www.oak-tree.tech/blog/k8s-cert-yearly-renewwal
Problem

"The connection to the server x.x.x.:6443 was refused - did you specify the right host or port?" hatası

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ı)

Problem

kubelet.service: Main process exited, code=exited, status=255

Sebep/NedenBu 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şturulabilinir.
Çözüm

#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

---

# 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>

Problem

ctr:  failed to verify certificate: x509: certificate is not valid

Sebep/NedenYukarıdaki problem Private registry'den image çekerken güvenilir bir sertifikaya sahip olmadığınızda ortaya çıkan bir sorun
Çö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

Problem

Podların dengeli bir şekilde dağıtılamaması

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
YML


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
CODE
Problem

Kubernetes'te Non-Graceful Node Shutdown(K8s node'unun beklenmedik şekilde kapanması)

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 
CODE
  •  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 girebiriz, 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
CODE
  • Node Monitör 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
CODE
  • 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.
Problem

Kubernetes'te Klonlanmış Worker Node'un Cluster'a Dahil Ederken Olası Çakışmaları Önlemek

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
CODE

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
CODE

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
CODE

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
CODE
Problem

Kubernetes'te Mevcut Cluster'daki Worker Node'un Hostname'i Değişecekse

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. (Bu işlemler mevcut çalışma ortamında kesintilere sebep olabileceği bilerek yapılmalıdır)

Çözüm

1. Drain ve Delete Node.

Clusterdaki 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>
CODE

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
CODE

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
CODE
Problem

Read-Only Disk Nedeniyle Node Üzerinde Sorun

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
CODE

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-
CODE

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

kubectl uncordon <node-name>
CODE

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

Problem

ImageStatus failed: Id or size of image "k8s.gcr.io/kube-scheduler:v1.18.20" is not set

Sebep/NedenSunucu 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 inspectin ç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ı listelelenir
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
BASH