Ana içeriğe geç

Kubernetes Docker Containerd Sorunlari

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​

Node'u cluster'dan çıkarma

Control-plane Kubernetes node'unda ilgili sunucuyu cluster'dan çıkarın:

kubectl delete node <NODE_NAME>
Kubernetes ayarlarını temizleme

Koparılmak istenen sunucuda Kubernetes ayarlarını temizleyin:

sudo kubeadm reset
CNI ve overlay network temizleme

CNI ve overlay network bileşenlerini temizleyin:

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

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:

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

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​

Swap'i kapatma

Swap'i kapatın ve kalıcı hale getirin:

sudo swapoff -a
sudo sed -i '/ swap / s/^/#/' /etc/fstab
Sistem yeniden başlatma

Sistem yeniden başlatın:

sudo reboot
Kubernetes kurulumu

Kubernetes'i yeniden kurun:

kubeadm reset
kubeadm init --ignore-preflight-errors all

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:

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

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

daemon.json dosyasını düzenleme

Docker daemon yapılandırma dosyasını düzenleyin:

sudo vi /etc/docker/daemon.json

Aşağıdaki satırı ekleyin:

"insecure-registries" : ["hub.docker.com:443", "registry-1.docker.io:443", "quay.io"]
Docker'ı yeniden başlatma

Docker servisini yeniden başlatın:

sudo systemctl daemon-reload
sudo systemctl restart docker
docker info

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:

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

Nexus proxy kullanılıyorsa​

Sebep/Neden​

Kurum Nexus docker-proxy kullanıyorsa node'larda registry yapılandırması gerekir.

Çözüm​

Containerd mirror tanımı, imaj çekme testi ve deployment imaj path güncellemesi için Nexus Kullanımı sayfasına bakın. Docker runtime kullanıyorsanız aynı sayfadaki Docker sekmesini uygulayın.

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

Sebep/Neden​

Node 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

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

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)

$ 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

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 master/control-plane nodes
sudo reboot -i

#further readings:

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

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ı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 &#60;MASTER_NODE_IP&#62;
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 &#60;WORKER_NODE_NAME&#62;

# 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 &#60;MASTER_IP&#62;:&#60;PORT&#62; --token &#60;TOKEN&#62; --discovery-token-ca-cert-hash sha256:&#60;HASH&#62;

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:

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

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

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

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
  • 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
  • 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
  • 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:

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

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 &#60;NODES_OLD_HOSTNAME&#62; --ignore-daemonsets --delete-emptydir-data
kubectl delete node &#60;NODES_OLD_HOSTNAME&#62;

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 &#60;NODES_NEW_HOSTNAME&#62;
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

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

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.

ImageStatus 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.

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

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

Çö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.

En son tarihinde güncellendi