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

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

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.