Container Service for Kubernetes:Container networking FAQ

Dizin

Terway'in Paylaşılan ENI ve Özel ENI ağ modları arasındaki fark nedir?

Terway, Pod'lar için iki ENI tahsis moduna sahiptir.

• Paylaşılan ENI modu: Birden çok Pod, her düğümdeki ENI'leri paylaşır. Varsayılan ve en kaynak verimli moddur. Ağ hızlandırma (DataPathv2 veya IPvlan+eBPF) için gereklidir.

• Özel ENI modu: Her Pod kendi ayrılmış ENI'sini alır. En iyi performansı ve izolasyonu sağlar ancak önemli ölçüde daha fazla ENI kaynağı tüketir.

Bkz. Terway ağ eklentisini kullanma.

ACK kümemin Shared ENI mi yoksa Exclusive ENI modunda Terway kullandığını nasıl anlayabilirim?

Terway Shared ENI modumun ağ hızlandırma için DataPathv2 mi yoksa eski IPvlan+eBPF mi kullandığını nasıl kontrol edebilirim?

Yalnızca Paylaşılan ENI modu ağ hızlandırmayı (DataPathv2 veya IPvlan+eBPF) destekler. DataPathv2, Terway v1.8.0+ sürümlerinde IPvlan+eBPF'nin yerini almıştır; yeni kümeler yalnızca DataPathv2 kullanır.

kube-system ad alanındaki eni-config ConfigMap içindeki eniip_virtual_type değerini kontrol edin.

1. eni-config ConfigMap verilerini almak için aşağıdaki komutu çalıştırın:

   kubectl get cm eni-config -n kube-system -o yaml

2. Çıktıda, eniip_virtual_type alanının değerini kontrol edin:

   • datapathv2: Kümeniz mevcut DataPathv2 hızlandırmasını kullanır.

   • ipvlan: Kümeniz eski IPvlan+eBPF hızlandırmasını kullanır.

   • Alan yoksa ağ hızlandırma devre dışıdır.

Terway'in ağ hızlandırma modlarını (DataPathv2 veya IPvlan+eBPF) kullanırken trafik IPVS'yi bypass eder mi?

Evet, küme içindeki Pod'dan Hizmet'e trafik için Terway'in hızlandırma modları IPVS'yi bypass eder.

Hızlandırma etkinleştirildiğinde, Terway daha düşük gecikme süresi ve daha yüksek aktarım hızı sağlamak için Hizmet adreslerini doğrudan çekirdekte arka uç Pod IP'lerine çevirmek üzere eBPF kullanır ve kube-proxy IPVS ile düğümün ağ yığınını bypass eder.

Bkz. Terway ağ eklentisi.

Mevcut bir ACK kümesinde CNI ağ eklentisini değiştirmek mümkün müdür?

Hayır, mevcut bir ACK kümesinde CNI ağ eklentisini (örneğin Flannel'den Terway'e) değiştiremezsiniz.

Eklenti, küme oluşturma sırasında ayarlanır. Değiştirmek için yeni bir küme oluşturun ve iş yüklerini geçirin.

Bkz. Yönetilen bir ACK kümesi oluşturma.

ACK kümemde Terway için yeni bir vSwitch ekledikten sonra Pod'larım neden İnternet'e erişemiyor?

Yeni vSwitch'in büyük olasılıkla İnternet'e giden bir rotası yoktur, bu nedenle IP'lerini kullanan Pod'lar giden bağlantılar kuramaz.

Çözüm

Pod'lara İnternet erişimi sağlamak için NAT Gateway kullanarak yeni vSwitch'in CIDR bloğu için bir SNAT kuralı yapılandırın.

Bkz. Bir küme için İnternet erişimini etkinleştirme.

Kümemi Kubernetes 1.16+ sürümüne yükselttikten sonra düğümlerim NotReady durumunda. Flannel uyumsuzluğunu nasıl düzeltirim?

Bu sorun, Flannel görüntüsünü manuel olarak güncellemenize ancak CNI yapılandırmasını daha yeni Kubernetes sürümleriyle uyumlu olacak şekilde güncellememenize neden olur.

Neden

Kubernetes 1.16+, CNI yapılandırmasında bir cniVersion gerektirir. Eski Flannel yapılandırmalarında bu alan eksiktir ve düğümlerin NotReady durumuna geçmesine neden olur.

Çözüm

Flannel ConfigMap'e cniVersion alanını ekleyin.

Adımlar

1. kube-flannel-cfg ConfigMap'i düzenleyin:

   kubectl edit cm kube-flannel-cfg -n kube-system 

   net-conf.json verisinde, yapılandırma nesnesine "cniVersion": "0.3.1" ekleyin.

   "name": "cb0",   
   "cniVersion":"0.3.1",
   "type": "flannel",

2. Flannel pod'larını yeniden başlatın:

   kubectl delete pod -n kube-system -l app=flannel

   Düğümler artık Ready durumuna geçmelidir.

Bir Pod başladıktan hemen sonra oluşan ağ gecikmesi sorunlarını nasıl düzeltirim?

Belirti

Yeni başlatılan bir Pod'un ağda iletişim kurabilmesi için belirgin bir gecikme (birkaç saniye) oluşur.

Neden

Terway'in NetworkPolicy motoru, yeni Pod için eBPF kurallarını veya iptables girişlerini hesaplarken ve uygularken bu gecikmeye neden olur.

Çözüm

Ağ İlkelerini kullanmıyorsanız bu başlangıç gecikmesini ortadan kaldırmak için özelliği devre dışı bırakın.

1. Terway eni-config ConfigMap'i düzenleyin:

   kubectl edit cm -n kube-system eni-config 

   data.eni_conf bölümünde, disable_network_policy: "true" bayrağını ekleyin.

   disable_network_policy: "true"

2. İsteğe bağlı:Terway'in en son sürümünü kullanmıyorsanız konsoldan yükseltin.

   1. ACK konsolu üzerinde oturum açın. Sol gezinme bölmesinde Clusters öğesine tıklayın.

   2. Clusters sayfasında kümenizin adına tıklayın. Sol gezinme bölmesinde Add-ons öğesine tıklayın.

   3. Add-ons sayfasında Networking sekmesine tıklayın ve ardından Terway add-on'u için Upgrade öğesine tıklayın.

   4. Görüntülenen iletişim kutusunda istemleri takip ederek yapılandırmayı tamamlayın ve OK öğesine tıklayın.

3. Terway pod'larını yeniden başlatın:

    kubectl delete pod -n kube-system -l app=terway-eniip

Pod'larım kendilerinin sunduğu bir Hizmet'e erişmeye çalışırken neden bağlantı hataları alıyor (hairpinning)?

"Hairpinning" olarak bilinen bu sorun, bir Pod'un trafiği kendisine geri yönlendiren bir Hizmet'e erişmeye çalıştığında oluşur. Davranış, ağ eklentinize bağlıdır.

Neden

Önerilen çözüm

• Headless Hizmet kullanın: Headless Hizmetin bir ClusterIP yoktur ve kube-proxy öğesini bypass eder. DNS doğrudan Pod IP'lerine çözümlenir ve ağ döngülerini ortadan kaldırır.

  Bkz. Headless Services.

• Kümeyi Terway ağ eklentisi ile yeniden oluşturun.

• Flannel yapılandırmasını değiştirin, ardından Flannel eklentisini ve pod'larını yeniden oluşturun.

Alternatif çözümler

• Flannel'de Hairpin Modunu Etkinleştirme (Önerilmez): Hairpinning'i manuel olarak etkinleştirebilirsiniz ancak yükseltmeler bu yapılandırmayı üzerine yazabilir.

1. kube-system ad alanındaki kube-flannel-cfg ConfigMap'i düzenleyin.

kubectl edit cm kube-flannel-cfg -n kube-system

2. CNI yapılandırmasının delegate bölümüne hairpinMode: true ekleyin.

Örnek:

cni-conf.json: |
    {
      "name": "cb0",
      "cniVersion":"0.3.1",
      "type": "flannel",
      "delegate": {
        "isDefaultGateway": true,
        "hairpinMode": true
      }
    }

3. Tüm Flannel pod'larını yeniden başlatın, ardından uygulama pod'larınızı yeniden oluşturun.

kubectl delete pod -n kube-system -l app=flannel   

• Terway Eklentisi Kullanın: Terway ağ eklentisi, hairpin trafiğini varsayılan olarak doğru şekilde işler. Bu kritik bir gereksinimse, Terway ile yeni bir küme oluşturmayı düşünün.

Bir ACK Kubernetes kümesi için Terway ve Flannel ağ eklentileri arasındaki fark nedir?

Doğru ağ eklentisini seçmek, belirli özellik ve performans gereksinimlerinize bağlıdır.

Bir ACK kümesi için ağı planlamanın doğru yolu nedir?

IP tükenmesini ve ağ çakışmalarını önlemek için doğru ağ planlaması çok önemlidir. Bir küme oluşturmadan önce üç ana CIDR bloğuna karar vermeniz gerekir:

1. VPC ve vSwitch CIDR: Bu, ECS düğümleriniz için adres alanıdır. Mevcut ve gelecekteki düğümleriniz için yeterince büyük olduğundan emin olun.

2. Pod CIDR Bloğu: Bu, kümedeki tüm Pod'lar için adres alanıdır.

   • VPC CIDR veya bağlı olan şirket içi ağlardan herhangi biriyle kesişmemelidir.

   • Bloğu, öngörülen maksimum Pod sayınıza göre boyutlandırın. Çok küçük bir blok seçmek yaygın bir hatadır.

3. Service CIDR Bloğu: Bu, Kubernetes Hizmetlerine (ClusterIP'ler) atanan sanal IP'ler için adres alanıdır.

   • VPC CIDR veya Pod CIDR ile kesişmemelidir.

Bu aralıkları önceden planlayın — oluşturulduktan sonra değiştirilemezler.

Bkz. Yönetilen bir ACK kümesi için ağ planlama.

ACK, Pod'lar için hostPort öğesini destekliyor mu?

hostPort desteği CNI ağ eklentisine bağlıdır.

• Flannel: hostPort öğesini destekler.

• Terway: hostPort öğesini desteklemez.

hostPort kullanılması önerilmez. Önerilen alternatifler:

• NodePort Hizmeti: Hizmeti her düğümün IP'sinde statik bir bağlantı noktasında sunar.

• LoadBalancer Hizmeti: Trafiği hizmete yönlendirmek için harici bir cloud yük dengeleyici sağlar.

Terway ile Pod'lar, kendi IP'leri aracılığıyla VPC içinde doğrudan erişilebilir durumdadır ve bu da VPC içi iletişim için hostPort kullanımını gereksiz kılar.

Kümem tarafından kullanılan ağ eklentisini ve vSwitch'leri nasıl tanımlarım?

ACK konsolunu kontrol edin.

1. Ağ eklentisini bulmak için:

• ACK konsolu üzerinde oturum açın. Sol taraftaki gezinme bölmesinde Clusters öğesine tıklayın.

• Clusters sayfasında kümenizin adına tıklayın. Sol gezinme bölmesinde Cluster Information öğesine tıklayın.

• Basic Information sekmesine tıklayın.

• Network Plug-in alanında Flannel veya Terway gösterilir.

2. Düğüm vSwitch'lerini bulmak için:

• Nodes > Node Pools konumuna gidin.

• Bir düğüm havuzu için Details öğesine tıklayın.

• Node vSwitch alanında düğümlerin bulunduğu vSwitch'ler gösterilir.

3. Pod vSwitch'lerini bulmak için (yalnızca Terway):

• Kümenizin sayfasında Add-ons konumuna gidin.

• terway-eniip bileşenini bulun ve Configuration öğesine tıklayın.

• PodVswitchId alanında Pod IP'lerinin tahsis edilmesi için kullanılan vSwitch'ler listelenir. (Bu Flannel için geçerli değildir).

ACK kümem tarafından kullanılan cloud kaynaklarını nasıl görüntülerim?

Bir ACK kümesinde kube-proxy yapılandırmasını değiştirmenin doğru yolu nedir?

Mod (IPVS/iptables) veya bağlantı izleme gibi kube-proxy davranışını ConfigMap'ini düzenleyerek özelleştirin.

Yordam

1. ConfigMap'i tanımlayın:

   • Yönetilen ACK Kümeleri için yalnızca kube-proxy-worker öğesini düzenlemeniz gerekir.

   • Özel ACK Kümeleri için hem kube-proxy-worker hem de kube-proxy-master öğelerini düzenlemeniz gerekir.

2. ConfigMap'i düzenleyin:

   ConfigMap'i kube-system ad alanında bulun ve YAML'sini düzenleyin. Yapılandırma, standart Kubernetes KubeProxyConfiguration API'sini takip eder. Bkz. kube-proxy Configuration.

3. Değişiklikleri Uygulayın:

   Kaydettikten sonra kube-proxy pod'larını yeniden başlatın. DaemonSet denetleyicisi bunları güncellenmiş yapılandırmayla otomatik olarak yeniden oluşturur.

Düğümlerimdeki Linux bağlantı izleme (conntrack) limitini nasıl artırabilirim?

# Snippet from kube-proxy config.conf
conntrack:
  maxPerCore: 65536

kube-proxy'de IPVS yük dengeleme algoritmasını nasıl değiştiririm?

DNS gecikmelerini düzeltmek için kube-proxy IPVS modundaki UDP oturum zaman aşımını nasıl azaltırım?

Bir UDP arka ucu (CoreDNS gibi) kaldırıldığında, IPVS modundaki kube-proxy buna yönelik trafiği 300 saniyeye kadar (varsayılan zaman aşımı) black-hole yapabilir ve bu da dağıtımlar veya yeniden başlatmalar sırasında DNS gecikmelerine neden olur.

Çözüm

kube-proxy yapılandırmasındaki UDP zaman aşımını düşürün.

Kubernetes v1.18 ve sonrası için:

1. kube-system ad alanındaki kube-proxy-worker (ve özel kümeler için kube-proxy-master) ConfigMap'i düzenleyin.

2. ipvs.udpTimeout alanını ekleyin veya değiştirin. Etkiyi en aza indirmek için 10s değeri makul bir seçimdir.

3. Değişikliği uygulamak için kube-proxy pod'larını yeniden başlatın.

Kubernetes v1.16 ve öncesi için:

Bu sürümler udpTimeout desteğine sahip değildir. Ayarı her düğümde ipvsadm aracılığıyla değiştirin. Komutları toplu halde çalıştırmak için OOS (CloudOps Orchestration Service) kullanın.

# This command sets the TCP, TCP-FIN, and UDP timeouts respectively.
# The third parameter '10' sets the UDP timeout to 10 seconds.
ipvsadm --set 900 120 10

IPv6 çift yığınlı bir kümede yaygın sorunları nasıl gideririm?

• Sorun: kubectl get pod yalnızca bir IPv4 adresi gösteriyor.

  • Çözüm: Bir Pod birden çok IP'ye sahip olabilir. Tümünü görüntülemek için JSONPath kullanın. podIPs listesinde bir IPv6 adresi bulunmalıdır.

• Sorun: kubectl get svc yalnızca bir IPv4 CLUSTER-IP gösteriyor.

  • Çözüm: Hizmetin ipFamilyPolicy değerinin PreferDualStack veya RequireDualStack olarak ayarlandığından emin olun. Tüm cluster IP'lerini JSONPath ile görüntüleyin:

• Sorun: Pod'uma IPv6 adresi üzerinden erişemiyorum.

  • Neden: Konteyner içindeki uygulama IPv6 any-address dinlemiyor olabilir (::). Örneğin, bazı web sunucuları varsayılan olarak 0.0.0.0 (yalnızca IPv4) üzerinde dinler.

  • Çözüm: Pod'a exec ile bağlanın ve netstat -anp komutunu çalıştırın. "Local Address" sütununu kontrol edin. tcp6 veya udp6 girişi ::: üzerinde dinliyorsa IPv6'yı doğru şekilde dinliyor demektir. Değilse, uygulamanızı yeniden yapılandırmanız gerekir.

• Sorun: Pod'uma küme içinde IPv6 üzerinden erişilebiliyor ancak İnternet'ten erişilemiyor.

  • Neden: Pod'un IPv6 adresi için genel bant genişliği yapılandırılmamış.

  • Çözüm: Alibaba Cloud konsolunda, bir IPv6 Gateway aracılığıyla IPv6 adresi için genel bant genişliğini etkinleştirin.

• Sorun: Pod'lar IPv6 üzerinden İnternet'e erişemiyor.

  • Çözüm: Giden IPv6 İnternet erişimini etkinleştirmek için VPC'nizde yapılandırılmış bir IPv6 Gateway'e sahip olmanız ve Pod'ların genel bant genişliği etkinleştirilmiş IPv6 adreslerine sahip olması gerekir.

Pod'larım "InvalidVSwitchId.IpNotEnough" hatalarıyla ContainerCreating durumunda takılı kaldı. Daha fazla IP adresini nasıl eklerim?

Pod IP'leri için kullanılan vSwitch adreslerini tüketmiştir. IP havuzunu genişletmek için yeni bir vSwitch ekleyin.

Adımlar

1. Yeni bir vSwitch oluşturun: VPC konsolunda, aynı bölge ve AZ'de bir vSwitch oluşturun. Büyük bir CIDR bloğu kullanın (ör. /19 veya daha küçük).

2. Terway Yapılandırmasını Güncelleyin: ACK konsolunda Add-ons > terway-eniip > Configuration konumuna gidin. Yeni oluşturulan vSwitch'in kimliğini PodVswitchId alanına ekleyin.

3. Terway Pod'larını Yeniden Başlatın: Terway DaemonSet pod'larını yeniden başlatın.

4. Doğrulayın: Yeni Pod'lar başlamalı ve yeni vSwitch'ten IP almalıdır.

Terway yapılandırmasını güncelledikten sonra bile Pod'larım neden eski bir vSwitch CIDR bloğundan IP alıyor?

Düğümlerdeki mevcut ENI'ler eski vSwitch'e bağlı kalır. Terway, yeni vSwitch ayarlarını yalnızca yeni bir ENI oluştururken uygular.

Neden

Bir düğümde zaten bir ENI varsa, yeni Pod'lar güncellenmiş vSwitch ayarlarını yok sayarak o ENI'nin IP havuzunu kullanmaya devam eder. Bu durum, başka bir kümeden düğümleri yeniden kullanırken veya Terway yapılandırmasını düğümleri yeniden döndürmeden değiştirdikten sonra ortaya çıkar.

Çözüm

Yeni yapılandırmayı zorlamak için etkilenen düğümleri döndürün.

Bir düğümü döndürme adımları

1. Drain edin ve kaldırın: İş yüklerini güvenli bir şekilde drain edin ve düğümü kümeden kaldırın.

2. ENI'leri ayırın: ECS konsolunda, kaldırılan örnekten kalan ENI'leri manuel olarak ayırın.

3. Düğümü yeniden ekleyin: Örneği kümeye geri ekleyin. Artık temiz bir başlangıç yapacak ve mevcut Terway yapılandırmasına göre yeni ENI'ler oluşturacaktır.

Terway yapılandırmama yeni bir vSwitch ekledim ancak Pod'larım hala IP alamıyor. Bunun nedeni nedir?

Bu sorun genellikle düğümlerin ECS örnek türü için maksimum ENI ekleme kotasına ulaştığında ortaya çıkar.

Neden

Yeni vSwitch yapılandırılmış olsa da, düğüm donanım ENI ekleme limitine ulaştığı için Terway yeni bir ENI oluşturamaz. Mevcut ENI'ler tükenmiş vSwitch'lere bağlıdır, bu nedenle yeni IP atanamaz.

Çözüm

Mevcut ENI eklerini temizlemek ve güncellenmiş yapılandırmayla yenilerinin yapılmasına izin vermek için etkilenen düğümleri döndürün.

Bir düğümü döndürme adımları

1. Drain edin ve kaldırın: İş yüklerini güvenli bir şekilde drain edin ve düğümü kümeden kaldırın.

2. ENI'leri ayırın: ECS konsoluna gidin ve örnekten tüm ENI'leri manuel olarak ayırın.

3. Düğümü yeniden ekleyin: Örneği kümeye geri ekleyin. Artık güncellenmiş vSwitch yapılandırmasını kullanarak yeni bir ENI ekleyebilecektir.

Mevcut bir Terway IPvlan kümesinde ExternalIP ve LoadBalancer Hizmetleri için küme içi yük dengelemeyi nasıl etkinleştiririm?

Pod'ların LoadBalancer veya ExternalIP hizmetlerine harici IP'leri üzerinden erişmesine ve trafiğin dahili olarak yönlendirilmesine olanak tanır. Yeni Terway IPvlan kümelerinde (v1.2.0+) varsayılan olarak etkindir ancak eski kümelerde manuel etkinleştirme gerektirir.

Önkoşullar

• Terway v1.2.0 veya sonrası.

• Küme IPvlan modunda yapılandırılmalıdır.

Çözüm

eni-config ConfigMap'i düzenleyerek özelliği etkinleştirin.

Adımlar

1. kube-system ad alanındaki eni-config ConfigMap'i düzenleyin:

2. data.eni_conf bölümünde, in_cluster_loadbalance: "true" bayrağını ekleyin:

3. Terway pod'larını yeniden başlatın:

4. Yeni bir Terway pod'unun günlüklerinde enable-in-cluster-loadbalance=true olup olmadığını kontrol ederek doğrulayın.

IP tabanlı izin listesi oluşturma amacıyla bir Terway kümesinde Pod'ları belirli bir vSwitch/CIDR bloğuna nasıl atayabilirim?

Terway'in varsayılan vSwitch ayarlarını düğüm havuzu başına geçersiz kılarak Pod'ları IP tabanlı izin listesi için belirli bir CIDR bloğunu kullanmaya zorlayın.

Çözüm

1. Özel bir Terway ConfigMap oluşturun:

   kube-system ad alanında (ör. eni-config-fixed) izin listesindeki Pod'larınız için ayrılmış vSwitch'i belirten yeni bir ConfigMap oluşturun.

   Bu örnekte vsw-2zem796p76viir02c**** ve 10.2.1.0/24 kullanılmaktadır.

   apiVersion: v1
   data:
     eni_conf: |
       {
          "vswitches": {"cn-beijing-h":["vsw-2zem796p76viir02c****"]},
          "security_group": "sg-bp19k3sj8dk3dcd7****",
          "security_groups": ["sg-bp1b39sjf3v49c33****","sg-bp1bpdfg35tg****"]
       }
   kind: ConfigMap
   metadata:
     name: eni-config-fixed
     namespace: kube-system
   
                           

2. Bir Düğüm Havuzunu Yapılandırın:

   Yeni bir düğüm havuzu oluşturun veya mevcut birini kullanın. Düğümlerine aşağıdaki etiketi uygulayın: terway-config: eni-config-fixed.

3. Pod'ları Node Selector ve Toleration ile Dağıtın:

   Uygulamanızı, 2. adımdaki etiketle eşleşen bir nodeSelector ve taint için bir toleration ile dağıtın.

   apiVersion: apps/v1 # For versions earlier than 1.8.0, use apps/v1beta1.
   kind: Deployment
   metadata:
     name: nginx-fixed
     labels:
       app: nginx-fixed
   spec:
     replicas: 2
     selector:
       matchLabels:
         app: nginx-fixed
     template:
       metadata:
         labels:
           app: nginx-fixed
       spec:
         tolerations:        # Add a toleration.
         - key: "fixed"
           operator: "Equal"
           value: "true"
           effect: "NoSchedule"
         nodeSelector:
           terway-config: eni-config-fixed
         containers:
         - name: nginx
           image: nginx:1.9.0 # Replace with your actual image <image_name:tags>.
           ports:
           - containerPort: 80

   Doğrulama

   Bu düğüm havuzundaki Pod'lar, yalnızca vsw-2zem796p76viir02c**** vSwitch'inden IP alır. Harici hizmetinizin izin listesine bu vSwitch'in CIDR bloğunu ekleyin.

Bir Flannel kümesinde, Pod'larım neden bazı ECS örneklerine ping atabiliyor ama diğerlerine atamıyor?

VPC rotalarınızın Flannel overlay ağı için doğru yapılandırıldığını varsayarsak, bu sorun neredeyse her zaman güvenlik grubu kurallarından kaynaklanır.

• Neden 1: ECS örneği aynı VPC'de ancak farklı bir güvenlik grubunda.

  • Çözüm: Hedef ECS örneğinin güvenlik grubuna, kümenizin düğümlerinin kaynak IP aralığından gelen trafiğe izin veren bir gelen kuralı ekleyin. Daha sağlam bir çözüm için, kümenin Pod CIDR bloğundan gelen trafiğe izin verin.

• Neden 2: ECS örneği farklı bir VPC'de.

  • Çözüm: Pod'lar ECS örneğine genel IP adresi üzerinden erişmelidir. ECS örneğinin güvenlik grubuna, kümenizin genel giden IP adresinden (ör. NAT Gateway'inizin IP'si) gelen trafiğe izin veren bir gelen kuralı eklemeniz gerekir.

Flannel kümemde yeni eklenen düğümler neden NodeNetworkUnavailable taint'i alıyor?

Bu taint, düğümün ağının hazır olmadığını gösterir. cloud-controller-manager (CCM) VPC rotalarını yapılandırır ve bu taint'i kaldırır; kalıcılık CCM hatasını gösterir.

Yaygın nedenler

1. VPC yönlendirme tablosu dolu: VPC yönlendirme tablosu kotasına ulaşmıştır ve CCM yeni düğümün Pod CIDR bloğu için yeni bir rota ekleyemez.

2. VPC'de birden çok yönlendirme tablosu: VPC'niz birden çok yönlendirme tablosu kullanıyor ancak CCM bunları yönetecek şekilde yapılandırılmamış. Varsayılan olarak yalnızca VPC'nin ana yönlendirme tablosuyla etkileşime girer.

Çözüm

1. CCM'den gelen hata mesajları için düğüm olaylarını inceleyin:

2. Yönlendirme tablosu doluysa yer açmak için kullanılmayan rotaları silmeniz gerekir.

3. Birden çok yönlendirme tablosu kullanıyorsanız, CCM'yi ilgili tüm yönlendirme tablosu kimlikleriyle yapılandırın. Bkz. VPC'de birden çok yönlendirme tablosu kullanma.

Pod'larım neden failed to allocate for range 0: no IP addresses available in range set hatasıyla başlatılamıyor?

Düğüm, Pod IP alt ağını tüketmiştir. Bu genellikle IP sızıntılarından — Pod silindikten sonra IP'lerin serbest bırakılmamasından — kaynaklanır.

IP sızıntılarının yaygın nedenleri

• Eski Kubernetes sürümleri (< 1.20): Hızlı Pod yeniden başlatmaları veya kısa ömürlü CronJob'lar, yarış koşulları nedeniyle IP sızıntılarına neden olabilir.

• Eski Flannel sürümleri: IP tahsisini diskte saklayan sürümler (/var/lib/cni/networks/), beklenmeyen kapatmalardan sonra IP'leri tahsis edilmiş olarak işaretli bırakabilir.

Uzun vadeli çözüm (önerilir)

1. Kümeyi yükseltin: ACK kümenizi Kubernetes 1.20 veya daha yeni bir sürüme yükseltin.

2. Flannel'i yükseltin ve tmpfs yapılandırın: Flannel'i yükseltin, ardından IPAM veri dizinini /var/run/cni/networks (yeniden başlatmada temizlenir) olarak ayarlamak için kube-flannel-cfg ConfigMap'i düzenleyin. Yapılandırmadan sonra düğümleri yeniden başlatın.

Geçici geçici çözüm (hemen yükseltemiyorsanız):

1. Etkilenen düğümü drain edin.

2. Düğüme giriş yapın ve /var/lib/cni/networks/cb0/ içindeki IP dosyalarını çalışan konteynerlerle (docker ps veya crictl pods) karşılaştıran, mevcut olmayan konteynerler için girişleri silen bir temizleme betiği çalıştırın.

3. Düğümün cordoning'ini kaldırın.

Mevcut bir ACK kümesi için Pod CIDR, Service CIDR veya düğüm başına IP sayısını nasıl değiştirebilirim?

Bir ACK kümesi oluşturulduktan sonra bu temel ağ parametrelerini değiştiremezsiniz.

Pod CIDR, Service CIDR ve düğüm başına alt ağ boyutu küme oluşturma sırasında sabittir. Bunları değiştirmek için doğru ağ planıyla yeni bir küme oluşturun.

Bir Flannel kümesinde cloud-controller-manager (CCM) öğesini birden çok yönlendirme tablosu için ne zaman yapılandırmam gerekir?

Aşağıdaki senaryolarda bir Flannel kümesinde CCM'yi birden çok yönlendirme tablosunu yönetecek şekilde yapılandırmanız gerekir:

• Senaryo 1: Özel yönlendirme tabloları kullanma

  Küme düğümleriniz ana yönlendirme tablosu yerine özel bir yönlendirme tablosuyla ilişkili alt ağlarda bulunuyorsa, CCM açıkça o özel yönlendirme tablosunun kimliğiyle yapılandırılmadığı takdirde Pod CIDR'leri için rota ekleyemez.

• Senaryo 2: CCM günlüklerinde multiple route tables found hatası gösteriliyor

  Bu hata mesajı, CCM'nin VPC'de birden fazla yönlendirme tablosu algıladığını ve Pod ağ rotalarını yönetmek için hangisini kullanacağını bilmediğini açıkça belirtir.

• Senaryo 3: Yeni düğümlerde kalıcı NodeNetworkUnavailable taint'i

  Yeni düğümler sürekli olarak bu taint ile takılı kalıyorsa, bu genellikle yapılandırılmamış özel bir yönlendirme tablosu nedeniyle CCM'nin rotalarını yapılandıramadığının güçlü bir göstergesidir.

Bir ACK kümesine üçüncü taraf bir CNI ağ eklentisi yüklemek mümkün müdür?

Hayır, ACK kümeleri üçüncü taraf ağ eklentilerinin yüklenmesini veya yapılandırılmasını desteklemez.

ACK, VPC yönlendirmesi ve ENI yönetimi için Terway ve Flannel ile derinlemesine entegredir. Başka bir CNI eklentisi (Calico veya Cilium gibi) yüklemek yönetilen sistemle çakışır ve ağ hatasına neden olur.

Flannel kümemde neden no IP addresses available in range set hatası alıyorum?

Bu hata, bir düğümün belirlenmiş Pod CIDR alt ağından yeni Pod'lara atanacak daha fazla IP adresi olmadığı anlamına gelir.

Neden

Bu sabit bir limittir. Bir Flannel kümesinde, toplam Pod CIDR bloğu daha küçük alt ağlara bölünür ve her düğüme bir alt ağ atanır. Bir düğümün alt ağı dolduğunda daha fazla Pod oluşturamaz. Bu sorun yetersiz ağ planlamasından kaynaklanır.

Çözüm

• Kısa vadeli: IP'leri serbest bırakmak için etkilenen düğümdeki kullanılmayan Pod'ları silin. Kendi yeni IP alt ağını alacak olan kümeye yeni bir düğüm de ekleyebilirsiniz.

• Uzun vadeli: Tek kalıcı çözüm, kümeyi daha büyük bir Pod CIDR bloğu ile yeniden oluşturmaktır. Beklenen düğüm sayısı ve düğüm başına pod sayısı için yeterli IP adresi ayırmak amacıyla ağınızı dikkatlice planlayın.

Bir Terway kümesinde düğüm başına maksimum Pod sayısını ne belirler?

Bir Terway kümesinde düğüm başına maksimum Pod sayısı, altta yatan ECS örnek türünün IP kapasitesi tarafından belirlenir.

Terway, düğüme eklenen ENI'lerden IP atar. Her ECS örnek türünün şu konuda belirli bir limiti vardır:

1. Ekleyebileceği maksimum ENI sayısı.

2. ENI başına maksimum özel IP adresi sayısı.

Toplam kullanılabilir IP (ve dolayısıyla Pod) sayısı (ENI Sayısı) × (ENI Başına IP) olarak hesaplanır. Bu limitleri, belirli örnek türünüz için Alibaba Cloud ECS belgelerinde bulabilirsiniz.

Terway'in DataPath V2 modu nedir ve orijinal IPvlan modundan farkı nedir?

• DataPath V2, orijinal IPvlan+eBPF moduna bir geliştirme olarak Terway'in ağ hızlandırma özelliği için yeni nesil veri düzlemidir.

  Temel noktalar

  • Yeni kümeler için varsayılan: IPvlan hızlandırmanın etkinleştirildiği Terway v1.8.0 veya sonraki sürümleriyle oluşturulan kümeler için DataPath V2 varsayılan olarak kullanılır.

  • Geriye dönük uyumluluk: Zaten eski IPvlan modunu kullanan mevcut kümeler, Terway bileşeni yükseltildikten sonra bile onu kullanmaya devam edecektir. Kesintileri önlemek için veri düzlemi otomatik olarak taşınmaz.

  • Avantajlar: DataPath V2, orijinal uygulamaya göre geliştirilmiş uyumluluk ve performans sunar.

Terway ağ bağlamında Pending ve ContainerCreating gibi farklı Pod durumları ne anlama gelir?

Pod durumu, bir Terway ortamında ağ başlatma ilerlemesini yansıtır.

• Pending: Zamanlayıcı henüz Pod'u bir düğüme atamadı. Bu genellikle kaynak kısıtlamalarından (CPU, bellek) veya zamanlama kurallarından (taint'ler, benzeşim) kaynaklanır. Terway bu aşamada henüz dahil değildir.

• ContainerCreating: Pod zamanlandı ve CNI eklentisi ağını kuruyor (ENI ekleme, IP atama). Buradaki gecikmeler genellikle vSwitch'te IP tükenmesi gibi ağ kaynağı sorunlarını gösterir.

• Running: Pod'daki tüm konteynerler oluşturuldu ve Terway ağını başarıyla yapılandırdı. Pod artık çalışır durumda ve erişilebilir olmalıdır.

Ayrıntıları kubectl describe pod <pod-name> ile inceleyin.

Terway bileşen yükseltmem neden eip pool is not supported hatasıyla başarısız oldu?

Bu hata, EIP (Elastic IP) havuzu özelliğinin kullanımdan kaldırıldığı ve Terway bileşeninin son sürümlerinden kaldırıldığı için oluşur.

Çözüm

Yükseltmeden önce, EIP yönetimini Terway'den artık Pod EIP atamalarını işleyen ack-extend-network-controller bileşenine taşıyın.

Pod'larım bazen bir Terway kümesinde can't found dev by mac hatasıyla neden oluşturulamıyor?

failed to do add; error parse config, can't found dev by mac... hatası, Terway'in düğümde beklenen MAC adresine sahip ENI'yi bulamadığı anlamına gelir.

İki yaygın neden vardır:

1. Eşzamansız ENI ekleme (geçici sorun):

   • Açıklama: Yeni eklenen bir ENI'nin işletim sisteminde başlatılması biraz zaman alır. CNI eklentisi bu pencere sırasında ağı yapılandırırsa cihazı bulamaz.

   • Çözüm: Bu geçici bir zamanlama sorunudur. CNI eklentisi otomatik olarak yeniden dener. Pod Running durumuna ulaşırsa bu günlük hatalarını yok sayın.

2. Düğüm sürücüsü hatası (kalıcı sorun):

   • Açıklama: Hata devam ederse, düğümün sürücüsü yetersiz yüksek dereceli bellek nedeniyle ENI'yi başlatamamış olabilir.

   • Çözüm: Etkilenen ECS örneğini yeniden başlatmak genellikle bu sürücü düzeyindeki hatayı çözer.

ACK kümem için özel bir Cluster Domain yapılandırırken nelere dikkat etmeliyim?

Cluster Domain (varsayılan: cluster.local), küme içindeki tüm hizmetler için DNS sonekidir. Küme oluşturma sırasında özelleştirirseniz DNS çözümleme çakışmalarını önlemek için şu kurallara uymalısınız.

• Değiştirilemez: Cluster Domain yalnızca küme oluşturma sırasında ayarlanabilir ve daha sonra değiştirilemez.

• Benzersiz olmalıdır: Cluster Domain, kullandığınız herhangi bir harici genel alan adı veya özel DNS bölgesiyle (ör. Alibaba Cloud DNS PrivateZone'da) kesişmemelidir.

Bu neden önemlidir?

CoreDNS, tüm Cluster Domain sorgularını dahili olarak işler ve bunları yukarı akışa iletmez (güvenlik ve performans için).

Cluster Domain'iniz mycompany.com ise ve www.mycompany.com adresinde genel bir siteniz varsa, Pod'lar www.mycompany.com adresini çözümleyemez çünkü CoreDNS, mycompany.com adresini yalnızca dahili bir bölge olarak değerlendirir ve sorguyu iletmeyi reddeder.