Bir Kubernetes Cluster’ından Çıkarılan Sunucunun Başka Cluster’a Eklenmesi Sırasında Overlay Network IP Sorunu
Sorun
Pod overlay network’ü için kullanılan Flannel dosya ve ayarları sunucuda kalmakta ve manuel silinmesi gerekmektedir.Çözüm
1
Node'u cluster'dan çıkarma
Control-plane Kubernetes node’unda ilgili sunucuyu cluster’dan çıkarın:
2
Kubernetes ayarlarını temizleme
Koparılmak istenen sunucuda Kubernetes ayarlarını temizleyin:
3
CNI ve overlay network temizleme
CNI ve overlay network bileşenlerini temizleyin:
CentOS 8.3.x Sunucularına Docker Kurulumu Sırasında Hata
Sorun
RHEL 8 ve CentOS 8’in piyasaya sürülmesiyle, Docker paketi varsayılan paket depolarından kaldırıldı ve 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
Engelleyici paketleri kaldırın:kubeadm Error: “kubelet isn’t running or healthy and connection refused”
Sorun
Linux işletim sistemlerinde genelde aktif halde gelen “swap” ve “selinux” kapatılmalıdır.Çözüm
1
Swap'i kapatma
Swap’i kapatın ve kalıcı hale getirin:
2
Sistem yeniden başlatma
Sistem yeniden başlatın:
3
Kubernetes kurulumu
Kubernetes’i yeniden kurun:
Namespace “Terminating” Durumunda Takılı Kalma
Sorun
Namespace silme işlemi “Terminating” durumunda takılı kalır.Çözüm
Finalizer’ları kaldırarak namespace’i zorla silin:Docker Pull Sırasında “x509 Certificate” Sorunu
Sorun (HTTP Kullanılıyorsa)
Eğer ilgili kurum HTTPS kullanmıyorsa Docker’ın daemon dosyasına insecure-registries eklenir. Docker kullanan tüm node’lar için bu işlem tekrarlanır.Çözüm (HTTP Kullanılıyorsa)
1
daemon.json dosyasını düzenleme
Docker daemon yapılandırma dosyasını düzenleyin:Aşağıdaki satırı ekleyin:
2
Docker'ı yeniden başlatma
Docker servisini yeniden başlatın:
Sorun (HTTPS Kullanılıyorsa)
Eğer ilgili kurum HTTPS kullanıyorsa ilgili kurumdan SSL sertifikasını (“crt”) sunuculara eklemesi gerekmektedir.Çözüm (HTTPS Kullanılıyorsa)
Ubuntu/Debian için:Nexus proxy kullanılıyorsa
Sebep/Neden
Eğer ilgili kurum Nexus proxy kullanıyorsa docker’lı sunucular bu adrese yönlendirilir.Çözüm
Kubernetes DNS Problemi (connection timed out; no servers could be reached)
Sebep/Neden
Node stays on Ready,SchedulingDisabledTest
Çözüm
Bir müşteride /etc/resolv.conf dosyası içine kurumun domain adresi eklenerek çözüldü. search kurum.gov.trKubernetes 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/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: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/Neden
Firewall ssl inspection yaparak kendi sertifikasını ekliyor.Çözüm
docker.io’u firewall üzerinde “ssl inspection exception“‘a eklenecek.Node NotReady’de kalıyor ve “Unable to update cni config: no networks found in /etc/cni/net.d”
Sebep/Neden
Master’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)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- https://serverfault.com/questions/1065444/how-can-i-find-which-kubernetes-certificate-has-expired
- https://www.oak-tree.tech/blog/k8s-cert-yearly-renewwal
”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
kubelet.service: Main process exited, code=exited, status=255
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şturulabilinir.Çözüm
#Mevcut config’ler ve sertifikalar yedek alınarak işlemler yapılırWorker 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:
Worker node üzerinde çalıştırılacak komutlar
ctr: failed to verify certificate: x509: certificate is not valid
Sebep/Neden
Yukarı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: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.node-role.kubernetes.io/control-plane etiketinin olup olmadığını kontrol edebilirsiniz.
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- 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.
- 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.
- 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.
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: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: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:Çözüm
1. Sunucu reboot edilirImageStatus failed: Id or size of image “k8s.gcr.io/kube-scheduler:v1.18.20” is not set
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.Manager Pod’dan Worker Pod’a ClusterIP (Service) Üzerinden Aralıklı Timeout Hatası
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…”

