> ## Documentation Index
> Fetch the complete documentation index at: https://docs.apinizer.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Kubernetes, Docker ve Containerd Olası Sorunları ve Çözümleri

> Kubernetes, Docker ve Containerd kurulumları ve kullanımları sırasında karşılaşılabilecek yaygın sorunları ve çözümlerini sağlar. Cluster yönetimi, sertifika sorunları, DNS problemleri, node durumları ve network yapılandırmaları gibi konularda pratik çözümler sunar.

<AccordionGroup>
  <Accordion title="Bir Kubernetes Cluster'ından çıkarılan sunucunun bir başka Kubernetes Cluster'ına eklenmesi sırasında doğru overlay network IP'sini alamaması">
    <p><strong>Sebep/Neden:</strong> Pod overlay network'ü için kullanılan Flannel dosya ve ayarları sunucuda kalmakta ve manuel silinmesi gerekmektedir.</p>

    <p><strong>Çözüm:</strong> 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:</p>

    ```bash theme={null}
    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
    ```
  </Accordion>

  <Accordion title="CentOS 8.3.x sunucularına Docker kurulurken alınan hata">
    <p><strong>Sebep/Neden:</strong> 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.</p>

    <p><strong>Çözüm:</strong></p>

    ```bash theme={null}
    yum remove podman* -y
    yum remove buildah* -y
    ```
  </Accordion>

  <Accordion title={'kubeadm error: "kubelet isn\'t running or healthy and connection refused"'}>
    <p><strong>Sebep/Neden:</strong> Linux işletim sistemlerinde genelde aktif halde gelen "swap" ve "selinux" kapatılmalıdır.</p>

    <p><strong>Çözüm:</strong></p>

    ```bash theme={null}
    sudo swapoff -a
    sudo sed -i '/ swap / s/^/#/' /etc/fstab
    sudo reboot
    kubeadm reset
    kubeadm init --ignore-preflight-errors all
    ```
  </Accordion>

  <Accordion title="Deleting namespace stuck at &#x22;Terminating&#x22; state">
    <p><strong>Sebep/Neden:</strong> Namespace silme işlemi finalizer'lar nedeniyle takılı kalabilir.</p>

    <p><strong>Çözüm:</strong></p>

    ```bash theme={null}
    kubectl get namespace "<NAMESPACE>" -o json | tr -d "\n" | sed "s/\"finalizers\": \[[^]]\+\]/\"finalizers\": []/" | kubectl replace --raw /api/v1/namespaces/<NAMESPACE>/finalize -f -
    ```
  </Accordion>

  <Accordion title="Docker pull sırasında &#x22;x509 certificate&#x22; sorunu">
    <p><strong>Sebep/Neden:</strong> 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.</p>

    <p><strong>Çözüm (HTTPS kullanmayan kurumlar için):</strong></p>

    ```bash theme={null}
    sudo vi /etc/docker/daemon.json
    ```

    ```json theme={null}
    {
      "insecure-registries": ["hub.docker.com:443", "registry-1.docker.io:443", "quay.io"]
    }
    ```

    ```bash theme={null}
    sudo systemctl daemon-reload
    sudo systemctl restart docker
    # Aşağıdaki ile kontrol edilir
    docker info
    ```

    <p><strong>Çözüm (HTTPS kullanan kurumlar için):</strong> Eğer ilgili kurum HTTPS kullanıyorsa ilgili kurumdan SSL sertifikasını ("crt") sunuculara eklemesi gerekmektedir.</p>

    ```bash theme={null}
    # 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
    ```
  </Accordion>

  <Accordion title="Nexus proxy kullanılıyorsa">
    <p><strong>Sebep/Neden:</strong> Eğer ilgili kurum Nexus proxy kullanıyorsa docker'lı sunucular bu adrese yönlendirilir.</p>

    <p><strong>Çözüm:</strong></p>

    ```bash theme={null}
    sudo vi /etc/docker/daemon.json
    ```

    ```json theme={null}
    {
      "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"
    }
    ```
  </Accordion>

  <Accordion title="Kubernetes DNS Problemi (connection timed out; no servers could be reached)">
    <p><strong>Sebep/Neden:</strong> Node stays on Ready, SchedulingDisabled durumunda kalabilir.</p>

    <p><strong>Test:</strong></p>

    ```bash theme={null}
    kubectl apply -f https://k8s.io/examples/admin/dns/dnsutils.yaml
    kubectl get pods dnsutils
    kubectl exec -i -t dnsutils -- nslookup kubernetes.default
    ```

    <p><strong>Eğer aşağıdaki gibi sonuç alıyorsak her şey doğru:</strong></p>

    ```bash theme={null}
    Server:    10.0.0.10
    Address 1: 10.0.0.10

    Name:      kubernetes.default
    Address 1: 10.0.0.1
    ```

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

    ```bash theme={null}
    Server: 10.96.0.10
    Address 1: 10.96.0.10

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

    <p><strong>Resolv.conf dosyasının içine bir göz atın:</strong></p>

    ```bash theme={null}
    kubectl exec -ti dnsutils -- cat /etc/resolv.conf
    ```

    <p><strong>(Doğru)</strong></p>

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

    <p><strong>(Yanlış)</strong></p>

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

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

    ```bash theme={null}
    # search kurum.gov.tr eklenir
    kubectl rollout restart -n kube-system deployment/coredns
    ```
  </Accordion>

  <Accordion title="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">
    <p><strong>Sebep/Neden:</strong> 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.</p>

    <p><strong>Çözüm:</strong></p>

    <p><strong>Tüm sunucularda:</strong></p>

    ```bash theme={null}
    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
    ```

    <p><strong>Sadece master sunucuda:</strong></p>

    ```bash theme={null}
    kubectl -n kube-system rollout restart deployment coredns
    ```
  </Accordion>

  <Accordion title="docker: Error response from daemon: Get &#x22;https://registry-1.docker.io/v2/&#x22;: x509: certificate signed by unknown authority">
    <p><strong>Sebep/Neden:</strong> Firewall SSL inspection yaparak kendi sertifikasını ekliyor.</p>

    <p><strong>Çözüm:</strong> docker.io'u firewall üzerinde "SSL inspection exception"'a eklenecek.</p>
  </Accordion>

  <Accordion title="Node NotReady'de kalıyor ve Unable to update cni config: no networks found in /etc/cni/net.d">
    <p><strong>Sebep/Neden:</strong> Master'da kube-flannel bir şekilde gerekli klasörü ve dosyaları oluşturamıyor.</p>

    <p><strong>Çözüm:</strong> (Alternatif çözümler de mevcut: <a href="https://github.com/kubernetes/kubernetes/issues/54918">GitHub Issue #54918</a>)</p>

    ```bash theme={null}
    sudo mkdir -p /etc/cni/net.d
    sudo vi /etc/cni/net.d/10-flannel.conflist
    ```

    <p>Aşağıdaki içerik eklenir:</p>

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

    ```bash theme={null}
    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
    ```
  </Accordion>

  <Accordion title="Client certificates generated by kubeadm expire after 1 year - &#x22;internal server error. Error Detail: operation: [list] for kind: [pod] with name: [null] in namespace: [prod] failed&#x22;">
    <p><strong>Sebep/Neden:</strong> Unable to connect to the server: x509: certificate has expired or is not yet valid.</p>

    <p><strong>Çözüm:</strong> Bu işlemler tüm master sunucularda yapılmalıdır.</p>

    ```bash theme={null}
    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
    ```
  </Accordion>

  <Accordion title="&#x22;The connection to the server x.x.x.:6443 was refused - did you specify the right host or port?&#x22; hatası">
    <p><strong>Sebep/Neden:</strong> Yukarıdaki problem aşağıdaki sebeplerin herhangi birinden dolayı ortaya çıkabiliyor:</p>

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

    <p><strong>Çözüm:</strong></p>

    ```bash theme={null}
    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ı
    ```
  </Accordion>

  <Accordion title="kubelet.service: Main process exited, code=exited, status=255">
    <p><strong>Sebep/Neden:</strong> 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.</p>

    <p><strong>Çözüm (Master Node):</strong> Mevcut config'ler ve sertifikalar yedek alınarak işlemler yapılır.</p>

    ```bash theme={null}
    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
    ```

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

    <p><strong>Master node üzerinde çalıştırılacak komutlar:</strong></p>

    ```bash theme={null}
    # Ö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
    ```

    <p><strong>Worker node üzerinde çalıştırılacak komutlar:</strong></p>

    ```bash theme={null}
    # 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>
    ```
  </Accordion>

  <Accordion title="ctr: failed to verify certificate: x509: certificate is not valid">
    <p><strong>Sebep/Neden:</strong> Yukarıdaki problem Private registry'den image çekerken güvenilir bir sertifikaya sahip olmadığınızda ortaya çıkan bir sorundur.</p>

    <p><strong>Çözüm:</strong> Çözümü -skip-verify parametresi ile sağlıyoruz. Örnek olarak "k8s.io" namespace içine dahil eden komut:</p>

    ```bash theme={null}
    ctr --namespace k8s.io images pull xxx.harbor.com/apinizercloud/managerxxxx -skip-verify
    ```
  </Accordion>

  <Accordion title="Podların dengeli bir şekilde dağıtılamaması">
    <p><strong>Sebep/Neden:</strong> 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.</p>

    <p><strong>Çözüm:</strong> 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.</p>

    ```yaml theme={null}
    spec:
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: kubernetes.io/hostname
          whenUnsatisfiable: ScheduleAnyway
          labelSelector:
            matchExpressions:
              - key: node-role.kubernetes.io/control-plane
                operator: DoesNotExist
    ```

    <Warning>
      <strong>Uyarı:</strong> Kontrol plane etiketi kullanarak podların bu düğümlere <strong>yerleşmesini engellemek</strong> istiyorsanız, kontrol plane düğümlerinin doğru şekilde etiketlendiğinden emin olun.
    </Warning>

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

    ```bash theme={null}
    kubectl get nodes --show-labels
    ```
  </Accordion>

  <Accordion title="Kubernetes'te Non-Graceful Node Shutdown (K8s node'unun beklenmedik şekilde kapanması)">
    <p><strong>Sebep/Neden:</strong> Kubernetes'te bir düğüm beklenmedik şekilde kapandığında (<strong>Non-Graceful Shutdown</strong>), 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.</p>

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

    <p><strong>1. Node Status Update Frequency</strong></p>

    ```bash theme={null}
    kubelet --node-status-update-frequency=5s
    ```

    <ul>
      <li>Node Status Update Frequency parametresi bir düğümde çalışan <strong>Kubelet</strong> tarafından Kubernetes API sunucusuna düğümün durumunun ne sıklıkla güncelleneceğini belirler, <strong>varsayılan olarak 10s</strong> değerindedir.</li>
      <li>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.</li>
    </ul>

    <p><strong>2. Node Monitor Grace Period</strong></p>

    ```bash theme={null}
    kube-apiserver --node-monitor-grace-period=20s
    ```

    <ul>
      <li>Node Monitor Grace Period parametresi, API sunucusunun bir düğümü "NotReady" durumuna geçirmeden önce bekleyeceği maksimum süreyi belirler, <strong>varsayılan olarak 40s</strong> değerindedir.</li>
      <li>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.</li>
    </ul>

    <p><strong>3. Pod Eviction Timeout</strong></p>

    ```bash theme={null}
    kube-controller-manager --pod-eviction-timeout=2m
    ```

    <ul>
      <li>Pod Eviction Timeout bir düğüm "NotReady" durumuna geçtikten sonra, düğümdeki pod'ların başka düğümlere yeniden yerleştirilmesi (<strong>eviction</strong>) için beklenilecek maksimum süreyi tanımlar, <strong>varsayılan olarak 5 dakika</strong> değerindedir.</li>
      <li>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.</li>
    </ul>
  </Accordion>

  <Accordion title="Kubernetes'te Klonlanmış Worker Node'un Cluster'a Dahil Ederken Olası Çakışmaları Önlemek">
    <p><strong>Sebep/Neden:</strong> 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:</p>

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

    <p><strong>Çözüm:</strong></p>

    <p><strong>1. Kubeadm reset.</strong> Klonlanmış worker node'un mevcut cluster yapılandırmasını tamamen sıfırlanır:</p>

    ```bash theme={null}
    sudo kubeadm reset
    sudo rm -rf $HOME/.kube
    ```

    <p><strong>2. Kubernetes'in Oluşturduğu Overlay Network Temizlenir.</strong> CNI ve diğer ağ bileşenleri temizlenir:</p>

    ```bash theme={null}
    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
    ```

    <p><strong>3. Klonlanan makinenin machine-id'si resetlenir.</strong> İşletim sistemine göre machine-id'yi yeniden oluşturulur:</p>

    ```bash theme={null}
    # 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
    ```

    <p><strong>4. Cluster'a Yeniden Katılma.</strong> Master node üzerinden join komutu alınır ve klonlanan node'da çalıştırılır:</p>

    ```bash theme={null}
    kubeadm token create --print-join-command
    ```
  </Accordion>

  <Accordion title="Kubernetes'te Mevcut Cluster'daki Worker Node'un Hostname'i Değişecekse">
    <Warning>
      Bu işlemler mevcut çalışma ortamında kesintilere sebep olabileceği bilerek yapılmalıdır.
    </Warning>

    <p><strong>Sebep/Neden:</strong> 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.</p>

    <p><strong>Çözüm:</strong></p>

    <p><strong>1. Drain ve Delete Node.</strong> Cluster'daki master node'a bağlanılır:</p>

    ```bash theme={null}
    kubectl get nodes
    kubectl drain <NODES_OLD_HOSTNAME> --ignore-daemonsets --delete-emptydir-data
    kubectl delete node <NODES_OLD_HOSTNAME>
    ```

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

    ```bash theme={null}
    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
    ```

    <p><strong>3. Cluster'a Yeniden Katılma.</strong> Master node üzerinden join komutu alınır ve klonlanan node'da çalıştırılır:</p>

    ```bash theme={null}
    kubeadm token create --print-join-command
    ```
  </Accordion>

  <Accordion title="Read-Only Disk Nedeniyle Node Üzerinde Sorun">
    <p><strong>Sebep/Neden:</strong> 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: <code>node.kubernetes.io/unschedulable:NoSchedule</code></p>

    <p><strong>Çözüm:</strong></p>

    <p><strong>1. Sunucu reboot edilir</strong></p>

    ```bash theme={null}
    sudo reboot
    ```

    <p>Node'un disk veya sistem hatası varsa reboot sonrası bazı sorunlar düzeltilebilir.</p>

    <p><strong>2. Node üzerindeki taint kaldırılır</strong></p>

    ```bash theme={null}
    kubectl taint nodes <node-name> node.kubernetes.io/unschedulable:NoSchedule-
    ```

    <p><strong>3. Node hâlâ pod kabul etmiyorsa uncordon uygulanır</strong></p>

    ```bash theme={null}
    kubectl uncordon <node-name>
    ```

    <p>Uncordon komutu, node'u schedulable hale getirir ve unschedulable taint'inin arka planda kaldırılmasını garanti eder.</p>
  </Accordion>

  <Accordion title="ImageStatus failed: Id or size of image &#x22;k8s.gcr.io/kube-scheduler:v1.18.20&#x22; is not set">
    <p><strong>Sebep/Neden:</strong> Sunucu paket güncellemesiyle birlikte <strong>Docker</strong> 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.</p>

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

    ```bash theme={null}
    # İ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
    ```
  </Accordion>

  <Accordion title="Manager Pod'dan Worker Pod'a ClusterIP (Service) Üzerinden Aralıklı Timeout Hatası">
    <p><strong>Sebep/Neden:</strong> <code>net.bridge.bridge-nf-call-iptables</code> ayarının eksik olması. Kubernetes'in <code>iptables</code> modunda çalışan <code>kube-proxy</code> bileşeni, Service trafiğini yönlendirmek için Linux köprülerini kullanır. <code>net.bridge.bridge-nf-call-iptables</code> 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..."</p>

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

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

    ```bash theme={null}
    sudo vi /etc/sysctl.d/k8s.conf
    ```

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

    ```bash theme={null}
    net.bridge.bridge-nf-call-iptables = 1
    ```

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

    ```bash theme={null}
    sudo sysctl --system
    ```

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

    ```bash theme={null}
    sudo sysctl net.bridge.bridge-nf-call-iptables
    ```

    <p>Çıktı 1 olarak dönmelidir.</p>

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

    ```bash theme={null}
    kubectl delete pod -n kube-system -l k8s-app=kube-proxy
    ```

    <p>Bu adımlar uygulandığında, Manager Pod'dan Worker Pod'a ClusterIP üzerinden yapılan bağlantılarda oluşan timeout sorunları çözülecektir.</p>
  </Accordion>
</AccordionGroup>