Aracılığıyla paylaş

AKS kümesinde barındırılan bir uygulamaya bağlantı sorunlarını giderme

  • Makale

Microsoft Azure Kubernetes Service (AKS) kümesine bağlantı sorunları farklı anlamlara gelebilir. Bazı durumlarda, API sunucusuna bağlantının etkilendiği anlamına gelebilir (örneğin, kubectl kullanılarak). Diğer durumlarda, yaygın bağlantı sorunlarının AKS kümesinde barındırılan bir uygulamayı etkilediği anlamına gelebilir. Bu makalede AKS kümesi bağlantı sorunlarının nasıl giderılacağı açıklanır.

Not

AKS API sunucusuna bağlanmaya çalıştığınızda sık karşılaşılan sorunları gidermek için bkz. API sunucusuyla ilgili küme bağlantısı sorunlarının temel sorunlarını giderme.

Önkoşullar

  • İstemci URL'si (cURL) aracı veya benzer bir komut satırı aracı.

  • Paketleri işlemek için apt-get komut satırı aracı.

  • Kubernetes kubectl aracı veya kümeye bağlanmak için benzer bir araç. Azure CLI kullanarak kubectl yüklemek için az aks install-cli komutunu çalıştırın.

Dikkate alınması gereken faktörler

Bu bölüm, AKS kümesinde barındırılan uygulamaya bağlanmaya çalışırken sorun yaşıyorsanız atılması gereken sorun giderme adımlarını kapsar.

Herhangi bir ağ senaryosunda, yöneticiler sorun giderme sırasında aşağıdaki önemli faktörleri dikkate almalıdır:

  • İsteğin kaynağı ve hedefi nedir?

  • Kaynak ile hedef arasındaki atlamalar nelerdir?

  • İstek-yanıt akışı nedir?

  • Hangi atlamaların en üstünde aşağıdaki öğeler gibi ek güvenlik katmanları vardır:

    • Güvenlik duvarı
    • Ağ güvenlik grubu (NSG)
    • Ağ ilkesi

Her bileşeni denetlediğinizde HTTP yanıt kodlarını alın ve analiz edin. Bu kodlar sorunun niteliğini tanımlamak için yararlıdır ve özellikle uygulamanın HTTP isteklerine yanıt verdiği senaryolarda yararlıdır.

Diğer sorun giderme adımları kesin sonuç sağlamazsa istemciden ve sunucudan paket yakalamaları alın. Paket yakalamaları, istemci ile sunucu arasında HTTP olmayan trafik söz konusu olduğunda da yararlıdır. AKS ortamı için paket yakalamaları toplama hakkında daha fazla bilgi için veri toplama kılavuzundaki aşağıdaki makalelere bakın:

HTTP yanıt kodlarını almayı ve paket yakalamalarını almayı bilmek, ağ bağlantısı sorununu gidermeyi kolaylaştırır.

AKS'de uygulamalar için temel ağ akışı

Genel olarak, AKS kümesinde barındırılan uygulamalara erişmek için istek akışı aşağıdaki gibidir:

İstemci >> DNS adı >> AKS yük dengeleyici IP adresi >> AKS düğümleri >> Podları

Ek bileşenlerin dahil olabileceği başka olası durumlar da vardır. Örneğin:

  • Uygulama ağ geçidi, Azure Load Balancer yerine Application Gateway Giriş Denetleyicisi (AGIC) aracılığıyla kullanılır.
  • Yük dengeleyicinin üzerinde Azure Front Door ve API Management kullanılabilir.
  • İşlem bir iç yük dengeleyici kullanır.
  • Bağlantı podda ve istenen URL'de bitmeyebilir. Bu, pod'un veritabanı veya aynı kümedeki başka bir hizmet gibi başka bir varlığa bağlanıp bağlanamadığına bağlı olabilir.

Uygulamanın istek akışını anlamak önemlidir.

AKS kümesindeki uygulamalara yönelik temel bir istek akışı, aşağıdaki diyagramda gösterilen akışa benzer.

Azure Kubernetes Service (A K S) kümesindeki uygulamalara yönelik temel istek akışının diyagramı.

İçten dışa sorun giderme

Bağlantı sorunlarını giderme işlemi birçok denetim içerebilir, ancak iç yaklaşım sorunun kaynağını bulmanıza ve performans sorununu belirlemenize yardımcı olabilir. Bu yaklaşımda, uygulamanın pod'un IP adresinde yanıt verip vermediğini denetleyarak poddan başlarsınız. Ardından, son istemciye kadar her bileşeni sırayla denetleyin.

1. Adım: Pod'un çalışıp çalışmadığını ve pod içindeki uygulamanın veya kapsayıcının doğru yanıt verip vermediğini denetleyin

Podun çalışıp çalışmadığını belirlemek için aşağıdaki kubectl get komutlarından birini çalıştırın:

# List pods in the specified namespace.
kubectl get pods -n <namespace-name>

# List pods in all namespaces.
kubectl get pods -A

Pod çalışmıyorsa ne olur? Bu durumda kubectl describe komutunu kullanarak pod olaylarını denetleyin:

kubectl describe pod <pod-name> -n <namespace-name>

Pod bir Ready veya Running durumunda değilse veya birçok kez yeniden başlatıldıysa çıkışı denetleyin kubectl describe . Olaylar, podu başlatmanızı engelleyen sorunları ortaya çıkaracaktır. Veya pod başlatıldıysa pod içindeki uygulama başarısız olmuş ve pod yeniden başlatılmasına neden olmuş olabilir. Uygun bir durumda olduğundan emin olmak için pod sorunlarını uygun şekilde giderin.

Pod çalışıyorsa, podların günlüklerini ve içindeki kapsayıcıları denetlemek de yararlı olabilir. Aşağıdaki kubectl günlükleri komutlarını çalıştırın:

kubectl logs <pod-name> -n <namespace-name>

# Check logs for an individual container in a multicontainer pod.
kubectl logs <pod-name> -n <namespace-name> -c <container-name>

# Dump pod logs (stdout) for a previous container instance.
kubectl logs <pod-name> --previous                      

# Dump pod container logs (stdout, multicontainer case) for a previous container instance.
kubectl logs <pod-name> -c <container-name> --previous

Pod çalışıyor mu? Bu durumda, kümede bir test podu başlatarak bağlantıyı test edin. Test podundan uygulamanın pod IP adresine doğrudan erişebilir ve uygulamanın doğru yanıt verip vermediğini de kontrol edebilirsiniz. kubectl run, apt-getve cURL komutlarını aşağıdaki gibi çalıştırın:

# Start a test pod in the cluster:
kubectl run -it --rm aks-ssh --image=debian:stable

# After the test pod is running, you will gain access to the pod.
# Then you can run the following commands:
apt-get update -y && apt-get install dnsutils -y && apt-get install curl -y

# After the packages are installed, test the connectivity to the application pod:
curl -Iv http://<pod-ip-address>:<port>

Diğer protokolleri dinleyen uygulamalar için, test podunun içine ilgili araçları yükleyebilir ve ardından uygulama podunun bağlantısını de kontrol edebilirsiniz.

Pod sorunlarını gidermeye yönelik diğer komutlar için bkz . Çalışan podlarda hata ayıklama.

2. Adım: Uygulamanın hizmetten erişilebilir olup olmadığını denetleyin

Pod içindeki uygulamanın çalıştığı senaryolar için, temel olarak pod'un nasıl kullanıma sunulduğuyla ilgili sorunları gidermeye odaklanabilirsiniz.

Pod bir hizmet olarak kullanıma sunuldu mu? Bu durumda hizmet olaylarını denetleyin. Ayrıca hizmet açıklamasında pod IP adresinin ve uygulama bağlantı noktasının uç nokta olarak kullanılabilir olup olmadığını denetleyin:

# Check the service details.
kubectl get svc -n <namespace-name>

# Describe the service.
kubectl describe svc <service-name> -n <namespace-name>

Aşağıdaki örnekte olduğu gibi pod'un IP adresinin hizmette bir uç nokta olarak bulunup bulunmadığını denetleyin:

$ kubectl get pods -o wide  # Check the pod's IP address.
NAME            READY   STATUS        RESTARTS   AGE   IP            NODE                                
my-pod          1/1     Running       0          12m   10.244.0.15   aks-agentpool-000000-vmss000000  

$ kubectl describe service my-cluster-ip-service  # Check the endpoints in the service.
Name:              my-cluster-ip-service
Namespace:         default
Selector:          app=my-pod
Type:              ClusterIP
IP Family Policy:  SingleStack
IP Families:       IPv4
IP:                10.0.174.133
IPs:               10.0.174.133
Port:              <unset>  80/TCP
TargetPort:        80/TCP
Endpoints:         10.244.0.15:80     # <--- Here

$ kubectl get endpoints  # Check the endpoints directly for verification.
NAME                      ENDPOINTS           AGE
my-cluster-ip-service     10.244.0.15:80      14m

Uç noktalar doğru pod IP adresini göstermiyorsa pod ve hizmet için ve Selectors değerlerini doğrulayınLabels.

Hizmetteki uç noktalar doğru mu? Bu durumda hizmete erişin ve uygulamanın erişilebilir olup olmadığını denetleyin.

ClusterIP hizmetine erişme

Hizmet için kümede ClusterIP bir test podu başlatabilir ve hizmet IP adresine erişebilirsiniz:

Küme I P adresine erişmek için bir Azure Kubernetes Service (A K S) kümesinde test podu kullanma diyagramı. 

# Start a test pod in the cluster:
kubectl run -it --rm aks-ssh --image=debian:stable
  
# After the test pod is running, you will gain access to the pod.
# Then, you can run the following commands:
apt-get update -y && apt-get install dnsutils -y && apt-get install curl -y
  
# After the packages are installed, test the connectivity to the service:
curl -Iv http://<service-ip-address>:<port>

Önceki komut uygun bir yanıt döndürmezse, hizmet olaylarının hataları olup olmadığını denetleyin.

LoadBalancer hizmetine erişme

Hizmet için LoadBalancer yük dengeleyici IP adresine kümenin dışından erişebilirsiniz.

Bir Azure Kubernetes Service (A K S) kümesinin dışından yük dengeleyici I P adresine erişen bir test kullanıcısının diyagramı. 

curl -Iv http://<service-ip-address>:<port>

LoadBalancer Hizmet IP adresi doğru yanıt döndürmüyor mu? Aksi takdirde şu adımları izleyin:

  1. Hizmetin olaylarını doğrulayın.

  2. AKS düğümleri ve AKS alt ağıyla ilişkilendirilmiş ağ güvenlik gruplarının (NSG) hizmet bağlantı noktasında gelen trafiğe izin verdiğini doğrulayın.

Hizmet sorunlarını gidermeye yönelik diğer komutlar için bkz. Hizmetlerde hata ayıklama.

Hizmet yerine giriş kullanan senaryolar

Uygulamanın bir Ingress kaynak kullanılarak kullanıma sunulduğu senaryolar için trafik akışı aşağıdaki ilerlemeye benzer:

İstemci >> DNS adı >> Yük dengeleyici veya uygulama ağ geçidi IP adresi >> Giriş podları küme >> Hizmeti veya podlar içinde

bir Azure Kubernetes Service (A K S) kümesi içindeki bir uygulama giriş kaynağı kullanılarak kullanıma sunulduğunda ağ trafiği akışının diyagramı.

Burada sorun gidermenin iç içe yaklaşımını da uygulayabilirsiniz. Daha fazla bilgi için giriş ve giriş denetleyicisi ayrıntılarını da kontrol edebilirsiniz:

$ kubectl get ing -n <namespace-of-ingress>  # Checking the ingress details and events.
NAME                         CLASS    HOSTS                ADDRESS       PORTS     AGE
hello-world-ingress          <none>   myapp.com            20.84.x.x     80, 443   7d22h

$ kubectl describe ing -n <namespace-of-ingress> hello-world-ingress
Name:             hello-world-ingress
Namespace:        <namespace-of-ingress>
Address:          20.84.x.x
Default backend:  default-http-backend:80 (<error: endpoints "default-http-backend" not found>)
TLS:
  tls-secret terminates myapp.com
Rules:
  Host                Path  Backends
  ----                ----  --------
  myapp.com
                      /blog   blog-service:80 (10.244.0.35:80)
                      /store  store-service:80 (10.244.0.33:80)

Annotations:          cert-manager.io/cluster-issuer: letsencrypt
                      kubernetes.io/ingress.class: nginx
                      nginx.ingress.kubernetes.io/rewrite-target: /$1
                      nginx.ingress.kubernetes.io/use-regex: true
Events:
  Type    Reason  Age    From                      Message
  ----    ------  ----   ----                      -------
  Normal  Sync    5m41s  nginx-ingress-controller  Scheduled for sync
  Normal  Sync    5m41s  nginx-ingress-controller  Scheduled for sync

Bu örnekte aşağıdakiler gibi bir Ingress kaynak bulunur:

  • Konakta myapp.com dinler.
  • yapılandırılmış iki Path dize vardır.
  • Arka uçta ikiye Services yönlendirir.

Arka uç hizmetlerinin çalıştığını doğrulayın ve giriş açıklamasında belirtilen bağlantı noktasına yanıt verin:

$ kubectl get svc -n <namespace-of-ingress>
NAMESPACE       NAME                                     TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)                      
ingress-basic   blog-service                             ClusterIP      10.0.155.154   <none>        80/TCP                       
ingress-basic   store-service                            ClusterIP      10.0.61.185    <none>        80/TCP             
ingress-basic   nginx-ingress-ingress-nginx-controller   LoadBalancer   10.0.122.148   20.84.x.x     80:30217/TCP,443:32464/TCP

Bir hata varsa giriş denetleyicisi podlarının günlüklerini doğrulayın:

$ kubectl get pods -n <namespace-of-ingress>  # Get the ingress controller pods.
NAME                                                     READY   STATUS    RESTARTS   AGE
aks-helloworld-one-56c7b8d79d-6zktl                      1/1     Running   0          31h
aks-helloworld-two-58bbb47f58-rrcv7                      1/1     Running   0          31h
nginx-ingress-ingress-nginx-controller-9d8d5c57d-9vn8q   1/1     Running   0          31h
nginx-ingress-ingress-nginx-controller-9d8d5c57d-grzdr   1/1     Running   0          31h

$ # Check logs from the pods.
$ kubectl logs -n ingress-basic nginx-ingress-ingress-nginx-controller-9d8d5c57d-9vn8q

İstemci giriş ana bilgisayar adına veya IP adresine istekte bulunuyorsa ancak giriş denetleyicisi podunun günlüklerinde hiçbir giriş görünmüyorsa ne olur? Bu durumda, istekler kümeye ulaşmıyor olabilir ve kullanıcı bir Connection Timed Out hata iletisi alıyor olabilir.

Diğer bir olasılık, Load Balancer veya Application Gateway gibi giriş podlarının üstündeki bileşenlerin istekleri kümeye doğru yönlendirmemesidir. Bu doğruysa, bu kaynakların arka uç yapılandırmasını de kontrol edebilirsiniz.

Hata Connection Timed Out iletisi alırsanız AKS düğümleriyle ilişkili ağ güvenlik grubunu denetleyin. Ayrıca AKS alt akını denetleyin. Yük dengeleyiciden veya uygulama ağ geçidinden AKS düğümlerine gelen trafiği engelliyor olabilir.

Giriş sorunlarını giderme (Nginx Girişi gibi) hakkında daha fazla bilgi için bkz. ingress-nginx sorunlarını giderme.

Yardım için bize ulaşın

Sorularınız veya yardıma ihtiyacınız varsa bir destek isteği oluşturun veya Azure topluluk desteği isteyin. Ürün geri bildirimini Azure geri bildirim topluluğuna da gönderebilirsiniz.

Üçüncü tarafla iletişim sorumluluk reddi

Microsoft, bu konu hakkında ek bilgi bulmanıza yardımcı olmak için üçüncü taraf iletişim bilgileri sağlar. Bu iletişim bilgileri önceden haber verilmeksizin değiştirilebilir. Microsoft, üçüncü taraf iletişim bilgilerinin doğruluğunu garanti etmez.