Azure Kubernetes Services'te API sunucusu ve vbd sorunlarını giderme

Makale
04/12/2024

Bu kılavuz, büyük Microsoft Azure Kubernetes Services (AKS) dağıtımlarında API sunucusunda karşılaşabileceğiniz olası olmayan sorunları belirlemenize ve çözmenize yardımcı olmak için tasarlanmıştır.

Microsoft, API sunucusunun güvenilirliğini ve performansını 5.000 düğüm ve 200.000 pod ölçeğinde test etti. API sunucusunu içeren kümenin ölçeği otomatik olarak genişletebilir ve Kubernetes Hizmet Düzeyi Hedeflerini (SLO) teslim edebilir. Yüksek gecikme süreleri veya zaman aşımlarıyla karşılaşıyorsanız, bunun nedeni büyük olasılıkla dağıtılmış etc dizinde (vbd) kaynak sızıntısı olması veya rahatsız edici bir istemcinin aşırı API çağrıları olmasıdır.

Önkoşullar

Azure CLI.
Kubernetes kubectl aracı. Azure CLI kullanarak kubectl yüklemek için az aks install-cli komutunu çalıştırın.
Etkin ve Log Analytics çalışma alanına gönderilen AKS tanılama günlükleri (özellikle kube-audit olayları). Günlüklerin kaynağa özgü veya Azure tanılama modu kullanılarak toplanıp toplanmadığını belirlemek için Azure portal Tanılama Ayarları dikey penceresini denetleyin.
AKS kümeleri için Standart katman. Ücretsiz katmanı kullanıyorsanız API sunucusu ve vb. sınırlı kaynaklar içerir. Ücretsiz katmanındaki AKS kümeleri yüksek kullanılabilirlik sağlamaz. Bu genellikle API sunucusu ve vbd sorunlarının kök nedenidir.
Kubernetes denetim düzlemini kullanmadan komutları doğrudan AKS düğümlerinde çalıştırmak için kubectl-aks eklentisi.

Belirtiler

Aşağıdaki tabloda API sunucusu hatalarının yaygın belirtileri özetlenmiştir:

Belirti	Açıklama
API sunucusundan zaman aşımları	AKS API sunucusu SLA'sında garantilerin ötesinde sık sık zaman aşımları. Örneğin komutlar `kubectl` zaman aşımına uğradı.
Yüksek gecikme süreleri	Kubernetes SLO'larının başarısız olmasına neden olan yüksek gecikme süreleri. Örneğin, komutun `kubectl` podları listelemesi 30 saniyeden uzun sürer.
Api sunucu podu `CrashLoopbackOff` durum veya web kancası çağrısı hatalarıyla karşılaşıyor	API sunucusuna yapılan çağrıları engelleyen herhangi bir özel erişim web kancanızın ( Kyverno ilke altyapısı gibi) olmadığını doğrulayın.

Sorun giderme denetim listesi

Yüksek gecikme süreleri yaşıyorsanız, sorunlu istemciyi ve başarısız olan API çağrılarının türlerini saptamak için bu adımları izleyin.

1. Adım: en çok kullanılan kullanıcı aracılarını istek sayısına göre tanımlama

Hangi istemcilerin en çok istek (ve potansiyel olarak en fazla API sunucusu yükü) oluşturduğunu belirlemek için aşağıdaki koda benzer bir sorgu çalıştırın. Aşağıdaki sorgu, gönderilen API sunucusu isteklerinin sayısına göre ilk 10 kullanıcı aracısını listeler.

Kaynağa özgü
Azure tanılaması

AKSAudit
| where TimeGenerated between(now(-1h)..now()) // When you experienced the problem
| summarize count() by UserAgent
| top 10 by count_
| project UserAgent, count_

AzureDiagnostics
| where TimeGenerated between(now(-1h)..now())  // When you experienced the problem
| where Category == "kube-audit" 
| extend event = parse_json(log_s) 
| extend User = tostring(event.user.username) 
| summarize count() by User 
| top 10 by count_ 
| project User, count_

Not

Sorgunuz hiçbir sonuç döndürmezse, tanılama günlüklerini sorgulamak için yanlış tabloyu seçmiş olabilirsiniz. Kaynağa özgü modda veriler, kaynağın kategorisine bağlı olarak tek tek tablolara yazılır. Tanılama günlükleri tabloya AKSAudit yazılır. Azure tanılama modunda tüm veriler tabloya AzureDiagnostics yazılır. Daha fazla bilgi için bkz. Azure kaynak günlükleri.

En yüksek istek hacmini hangi istemcilerin oluşturabileceğini bilmek yararlı olsa da, yalnızca yüksek istek hacmi endişeye neden olmayabilir. Her istemcinin API sunucusunda oluşturduğu gerçek yükün daha iyi bir göstergesi, deneyimledikleri yanıt gecikme süresidir.

2. Adım: Kullanıcı aracısı başına API sunucusu isteklerinin ortalama gecikme süresini belirleme ve grafik oluşturma

Bir zaman grafiğinde çizilen kullanıcı aracısı başına API sunucusu isteklerinin ortalama gecikme süresini belirlemek için aşağıdaki sorguyu çalıştırın:

Kaynağa özgü
Azure tanılaması

AKSAudit
| where TimeGenerated between(now(-1h)..now()) // When you experienced the problem
| extend start_time = RequestReceivedTime
| extend end_time = StageReceivedTime
| extend latency = datetime_diff('millisecond', end_time, start_time)
| summarize avg(latency) by UserAgent, bin(start_time, 5m)
| render timechart

AzureDiagnostics
| where TimeGenerated between(now(-1h)..now())  // When you experienced the problem
| where Category == "kube-audit" 
| extend event = parse_json(log_s) 
| extend User = tostring(event.user.username)
| extend start_time = todatetime(event.requestReceivedTimestamp)
| extend end_time = todatetime(event.stageTimestamp)
| extend latency = datetime_diff('millisecond', end_time, start_time)
| summarize avg(latency) by User, bin(start_time, 5m) 
| render timechart

Bu sorgu, "en iyi kullanıcı aracılarını istek sayısına göre tanımlama" bölümündeki sorgunun bir takibidir . Zaman içinde her kullanıcı aracısı tarafından oluşturulan gerçek yük hakkında daha fazla içgörü verebilir.

İpucu

Bu verileri analiz ederek AKS kümenizdeki veya uygulamalarınızdaki sorunları gösterebilecek desenleri ve anomalileri tanımlayabilirsiniz. Örneğin, belirli bir kullanıcının yüksek gecikme süresi yaşadığını fark edebilirsiniz. Bu senaryo, API sunucusunda veya vb.'de aşırı yüke neden olan API çağrılarının türünü gösterebilir.

3. Adım: Belirli bir kullanıcı aracısı için hatalı API çağrılarını belirleme

Belirli bir istemci için farklı kaynak türlerinde API çağrılarının 99. yüzdebirlik (P99) gecikme süresini sekmeyle görüntülemek için aşağıdaki sorguyu çalıştırın:

Kaynağa özgü
Azure tanılaması

AKSAudit
| where TimeGenerated between(now(-1h)..now()) // When you experienced the problem
| extend HttpMethod = Verb
| extend Resource = tostring(ObjectRef.resource)
| where UserAgent == "DUMMYUSERAGENT" // Filter by name of the useragent you are interested in
| where Resource != ""
| extend start_time = RequestReceivedTime
| extend end_time = StageReceivedTime
| extend latency = datetime_diff('millisecond', end_time, start_time)
| summarize p99latency=percentile(latency, 99) by HttpMethod, Resource
| render table

AzureDiagnostics
| where TimeGenerated between(now(-1h)..now())  // When you experienced the problem
| where Category == "kube-audit" 
| extend event = parse_json(log_s) 
| extend HttpMethod = tostring(event.verb) 
| extend Resource = tostring(event.objectRef.resource) 
| extend User = tostring(event.user.username) 
| where User == "DUMMYUSERAGENT"  // Filter by name of the useragent you are interested in
| where Resource != ""
| extend start_time = todatetime(event.requestReceivedTimestamp)
| extend end_time = todatetime(event.stageTimestamp)
| extend latency = datetime_diff('millisecond', end_time, start_time)
| summarize p99latency=percentile(latency, 99) by HttpMethod, Resource 
| render table

Bu sorgunun sonuçları, yukarı akış Kubernetes SLO'larının başarısız olduğu API çağrılarının türlerini tanımlamak için yararlı olabilir. Çoğu durumda, rahatsız edici bir istemci çok büyük bir nesne veya nesne kümesinde çok fazla LIST çağrı yapıyor olabilir. Ne yazık ki kullanıcılara API sunucusu ölçeklenebilirliği konusunda yol gösterecek sabit ölçeklenebilirlik sınırı yoktur. API sunucusu veya vbd ölçeklenebilirlik sınırları , Kubernetes Ölçeklenebilirlik eşiklerinde açıklanan çeşitli faktörlere bağlıdır.

Neden 1: Ağ kuralı aracı düğümlerinden API sunucusuna gelen trafiği engeller

Bir ağ kuralı aracı düğümleri ile API sunucusu arasındaki trafiği engelleyebilir.

Yanlış yapılandırılmış bir ağ ilkesinin API sunucusu ile aracı düğümleri arasındaki iletişimi engelleyip engellemediğini doğrulamak için aşağıdaki kubectl-aks komutlarını çalıştırın:

kubectl aks config import \
    --subscription <mySubscriptionID> \
    --resource-group <myResourceGroup> \
    --cluster-name <myAKSCluster>

kubectl aks check-apiserver-connectivity --node <myNode>

Yapılandırma içeri aktarma komutu, kümedeki tüm düğümler için Sanal Makine Ölçek Kümesi bilgilerini alır. Ardından check-apiserver-connectivity komutu, api sunucusu ile belirli bir düğüm arasındaki ağ bağlantısını doğrulamak için (özellikle temel ölçek kümesi örneği için) bu bilgileri kullanır.

Not

Komutun çıktısı check-apiserver-connectivity ileti içeriyorsa Connectivity check: succeeded , ağ bağlantısı engellenemez.

Çözüm 1: Trafik engelini kaldırmak için ağ ilkesini düzeltme

Komut çıkışı bir bağlantı hatası oluştuğunu gösteriyorsa, aracı düğümleri ile API sunucusu arasındaki trafiği gereksiz yere engellememesi için ağ ilkesini yeniden yapılandırın.

Neden 2: Rahatsız edici bir istemci etcd nesneleri sızdırıyor ve etcd'nin yavaşlamasına neden oluyor

Yaygın bir sorun, etcd veritabanında kullanılmayan nesneleri silmeden sürekli olarak nesne oluşturmaktır. Etcd herhangi bir türde çok fazla nesneyle (10.000'den fazla) çalıştığında bu durum performans sorunlarına neden olabilir. Bu tür nesnelerdeki değişikliklerin hızlı bir şekilde artması, etcd veritabanı boyutunun (varsayılan olarak 4 gigabayt) aşılmasına da neden olabilir.

Etcd veritabanı kullanımını denetlemek için Azure portal Sorunları tanılama ve çözme bölümüne gidin. Arama kutusunda "etcd" araması yaparak Etcd Kullanılabilirlik Sorunları tanılama aracını çalıştırın. Tanılama aracı, kullanım dökümünü ve toplam veritabanı boyutunu gösterir.

Etcd veritabanınızın geçerli boyutunu bayt cinsinden görüntülemek için hızlı bir yol istiyorsanız aşağıdaki komutu çalıştırın:

kubectl get --raw /metrics | grep -E "etcd_db_total_size_in_bytes|apiserver_storage_size_bytes|apiserver_storage_db_total_size_in_bytes"

Not

Önceki komuttaki ölçüm adı farklı Kubernetes sürümleri için farklıdır. Kubernetes 1.25 ve öncesi için kullanın etcd_db_total_size_in_bytes. Kubernetes 1.26 - 1.28 için kullanın apiserver_storage_db_total_size_in_bytes.

Çözüm 2: Etcd'de nesne oluşturma, nesneleri silme veya nesne ömrünü sınırlama kotaları tanımlama

VBD'nin kapasiteye ulaşmasını ve küme kapalı kalma süresine neden olmasını önlemek için, oluşturulan en fazla kaynak sayısını sınırlayabilirsiniz. Kaynak örnekleri için oluşturulan düzeltmelerin sayısını da yavaşlatabilirsiniz. Oluşturulabilecek nesne sayısını sınırlamak için nesne kotaları tanımlayabilirsiniz.

Artık kullanımda olmayan ancak kaynakları kaplayan nesneler belirlediyseniz, bunları silmeyi göz önünde bulundurun. Örneğin, alan açmak için tamamlanmış işleri silebilirsiniz:

kubectl delete jobs --field-selector status.successful=1

Otomatik temizlemeyi destekleyen nesneler için Yaşam Süresi (TTL) değerlerini bu nesnelerin yaşam süresini sınırlandıracak şekilde ayarlayabilirsiniz. Ayrıca, etiket seçicilerini kullanarak belirli bir türdeki tüm nesneleri toplu olarak silebilmeniz için nesnelerinizi etiketleyebilirsiniz. Nesneler arasında sahip başvuruları oluşturursanız, üst nesne silindikten sonra bağımlı nesneler otomatik olarak silinir.

Neden 3: Rahatsız edici bir istemci aşırı LIST veya PUT çağrıları yapar

Vbd'nin çok fazla nesneyle aşırı yüklenmediğini belirlerseniz, rahatsız edici bir istemci API sunucusuna çok fazla sayıda LIST veya PUT çağrı yapıyor olabilir.

Çözüm 3a: API çağrı deseninizi ayarlama

Kontrol düzlemi üzerindeki baskıyı azaltmak için istemcinizin API çağrı desenini ayarlamayı göz önünde bulundurun.

Çözüm 3b: Kontrol düzlemini zorlayan bir istemciyi kısıtlama

İstemciyi ayarlayamazsanız, istemciyi kısıtlamak için Kubernetes'teki Öncelik ve Eşitlik özelliğini kullanabilirsiniz. Bu özellik, denetim düzleminin durumunu korumaya ve diğer uygulamaların başarısız olmasını önlemeye yardımcı olabilir.

Aşağıdaki yordamda, sorunlu bir istemcinin LIST Pods API'sinin beş eşzamanlı çağrı olarak ayarlanmasını nasıl kısıtladığınız gösterilmektedir:

Sorunlu istemcinin API çağrı deseni ile eşleşen bir FlowSchema İçerik Oluşturucu:

apiVersion: flowcontrol.apiserver.k8s.io/v1beta2
kind: FlowSchema
metadata:
  name: restrict-bad-client
spec:
  priorityLevelConfiguration:
    name: very-low-priority
  distinguisherMethod:
    type: ByUser
  rules:
  - resourceRules:
    - apiGroups: [""]
      namespaces: ["default"]
      resources: ["pods"]
      verbs: ["list"]
    subjects:
    - kind: ServiceAccount
      serviceAccount:
        name: bad-client-account
        namespace: default

İstemcinin hatalı API çağrılarını kısıtlamak için daha düşük öncelikli bir yapılandırma İçerik Oluşturucu:

apiVersion: flowcontrol.apiserver.k8s.io/v1beta2
kind: PriorityLevelConfiguration
metadata:
  name: very-low-priority
spec:
  limited:
    assuredConcurrencyShares: 5
    limitResponse:
      type: Reject
  type: Limited

API sunucusu ölçümlerinde kısıtlanmış çağrıyı gözlemleyin.
```
kubectl get --raw /metrics | grep "restrict-bad-client"
```

Neden 4: Özel bir web kancası API sunucusu podlarında kilitlenmeye neden olabilir

Kyverno gibi özel bir web kancası API sunucu podlarında kilitlenmeye neden olabilir.

API sunucunuzla ilgili olayları denetleyin. Aşağıdaki metne benzeyen olay iletileri görebilirsiniz:

İç hata oluştu: "mutate.kyverno.svc-fail" web kancası çağrılamaz: web kancası çağrılamaz: Post "https://kyverno-system-kyverno-system-svc.kyverno-system.svc:443/mutate/fail?timeout=10s": write unix @->/tunnel-uds/proxysocket: write: broken pipe

Bu örnekte, web kancasını doğrulamak bazı API sunucusu nesnelerinin oluşturulmasını engelliyor. Bu senaryo önyükleme zamanında gerçekleşebileceğinden API sunucusu ve Konnectivity podları oluşturulamaz. Bu nedenle, web kancası bu podlara bağlanamaz. Bu olay dizisi kilitlenmeye ve hata iletisine neden olur.

Çözüm 4: Web kancası yapılandırmalarını silme

Bu sorunu çözmek için doğrulama ve kapatma web kancası yapılandırmalarını silin. Kyverno'da bu web kancası yapılandırmalarını silmek için Kyverno sorun giderme makalesini gözden geçirin.

Üçü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.

Üçüncü taraf bilgileri hakkında yasal uyarı

Bu makalede adı geçen üçüncü taraf ürünleri Microsoft'tan bağımsız şirketler tarafından üretilmektedir. Microsoft, bu ürünlerin performansı veya güvenilirliği ile ilgili örtük veya başka türlü hiçbir garanti vermez.

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.

Aracılığıyla paylaş