Konfigurowanie sieci LocalDNS w usłudze Azure Kubernetes Service (AKS)

Dotyczy: ✔️ AKS Automatic AKS Standard ✔️

W przypadku większości obciążeń produkcyjnych AKS Automatic to zalecany, gotowy do użycia produkcyjnego domyślny wybór dla usługi AKS. Usługa LocalDNS jest wstępnie skonfigurowana w klastrach automatycznych usługi AKS. W usłudze AKS Standard zachowanie usługi LocalDNS zależy od wersji Kubernetes i istniejącego profilu LocalDNS dla puli węzłów.

LocalDNS to funkcja w usłudze AKS, która poprawia wydajność rozpoznawania nazw DNS i odporność obciążeń uruchomionych w klastrze. Uruchamiając serwer proxy DNS w każdym węźle, usługa LocalDNS zmniejsza opóźnienie zapytań DNS, zwiększa niezawodność podczas przejściowych zakłóceń sieci i zapewnia zaawansowane kontrolki buforowania i przesyłania dalej w razie potrzeby dostosowania.

Aby dowiedzieć się, czym jest localDNS, w tym szczegóły architektury i kluczowe możliwości, zobacz Rozpoznawanie nazw DNS w Azure Kubernetes Service (AKS).

Zachowanie usługi AKS Automatic i AKS Standard LocalDNS

Sprawdzanie zgodności dla Preferred trybu

Począwszy od wersji Kubernetes 1.37 usługa AKS Standard przypisuje tryb Preferred uprawnionym pulom węzłów, które nie mają jawnie określonego profilu LocalDNS, w momencie ich tworzenia lub aktualizacji. AKS zachowuje jawnie skonfigurowane profile.

Przed pierwszym włączeniem usługi LocalDNS w trybie Preferred AKS sprawdza następujące wymagania dotyczące zgodności. Jeśli wymaganie nie zostanie spełnione, usługa LocalDNS pozostanie wyłączona.

Gdy AKS włączy LocalDNS w trybie Preferred, pozostanie on włączony podczas kolejnych, niezwiązanych z tym aktualizacji puli węzłów. Aby go wyłączyć, jawnie ustaw wartość LocalDNS mode na Disabled.

Najlepsze rozwiązania dotyczące konfiguracji localDNS

Podczas implementowania sieci LocalDNS w klastrach usługi AKS należy wziąć pod uwagę następujące najlepsze rozwiązania:

• Rozpocznij od minimalnej konfiguracji: rozpocznij od prostej konfiguracji, która używa Preferred trybu do weryfikowania składni konfiguracji LocalDNS przed przejściem do Required trybu. Tryb Preferred weryfikuje konfigurację bez włączania LocalDNS, pozwalając na wczesne wykrywanie błędów konfiguracji bez wpływu na klaster.
• Zaimplementuj odpowiednie strategie buforowania: Skonfiguruj ustawienia pamięci podręcznej na podstawie właściwości obciążenia:
  • W przypadku często zmieniających się rekordów użyj krótszych cacheDurationInSeconds wartości. W takim przypadku należy pamiętać, że funkcja cacheDurationInSeconds działa jako limit czasu wygaśnięcia rekordu DNS, ale nie zwiększa go. Wynikowy czas życia (TTL) to najmniejsza wartość spośród tej zwracanej ze źródła nadrzędnego lub ustawionej we wtyczce pamięci podręcznej.
  • W przypadku stabilnych rekordów użyj dłuższych czasów trwania pamięci podręcznej, aby zmniejszyć liczbę zapytań DNS.
  • Włącz serveStale z odpowiednimi ustawieniami, aby zapewnić ciągłość działania usługi w przypadku awarii DNS.
  • Buforowanie z LocalDNS działa na zasadzie najlepszych starań i nie gwarantuje, że odpowiedzi nie będą nieaktualne. Pamięć podręczna jest podzielona na 256 fragmentów i domyślnie maksymalnie 10 000 wpisów, co pozwala każdemu fragmentowi przechowywać około 39 wpisów. Gdy fragment jest pełny i należy dodać nowy wpis, jeden z istniejących wpisów jest wybierany losowo do eksmitowania. Nie ma preferencji dla starszych ani przedawnionych wpisów. W związku z tym nieaktualny rekord może nie zawsze być dostępny, szczególnie w przypadku dużej liczby zapytań.
• Monitorowanie wydajności dns: po włączeniu lokalnej sieciDNS monitoruj wydajność dns aplikacji przy użyciu:
  • Metryki wydajności aplikacji.
  • Metryki węzła do wykrywania zmniejszonego obciążenia sieciowego.
  • Wpisy dziennika, gdy queryLogging jest ustawione na Log.
• Przestrzegaj zasady najniższych uprawnień: podczas konfigurowania reguł przesyłania dalej DNS zezwalaj tylko na dostęp do wymaganych serwerów i domen DNS.
• Testowanie przed wdrożeniem produkcyjnym: zawsze testuj konfigurację LocalDNS w środowisku nieprodukcyjnym przed wdrożeniem go w klastrach produkcyjnych.
• Użyj infrastruktury jako kodu (IaC): zapisz plik localdnsconfig.json w repozytorium infrastruktury i uwzględnij go w szablonach wdrażania usługi AKS.
• Konfiguracja sieci na potrzeby przekazywania TCP: w przypadku używania protokołu TCP do przekazywania DNS do sieci VnetDNS upewnij się, że sieciowe grupy zabezpieczeń, zapory lub wirtualne urządzenia sieciowe (WUS) nie blokują ruchu TCP między serwerami CoreDNS/LocalDNS i VnetDNS.
• Unikaj włączania zarówno nodeLocal DNSCache, jak i LocalDNS: nie zaleca się włączania zarówno nadrzędnego węzła Kubernetes NodeLocal DNSCache, jak i localDNS w puli węzłów. Chociaż usługa AKS nie blokuje tej konfiguracji, cały ruch DNS jest kierowany przez sieć LocalDNS, co może prowadzić do nieoczekiwanego zachowania lub zmniejszonych korzyści z usługi NodeLocal DNSCache.
• Nie nakładaj limitu połączeń TCP na niestandardowy nadrzędny serwer DNS przed włączeniem funkcji LocalDNS: po włączeniu funkcji LocalDNS w puli węzłów każdy węzeł otwiera długotrwałe połączenia TCP ze swojego lokalnego proxy DNS do nadrzędnego resolvera zamiast krótkich wymian UDP używanych wcześniej. Jeśli niestandardowy serwer DNS (taki jak BIND, Unbound, Windows DNS lub urządzenie innej firmy) jest skonfigurowany ze stałym limitem dla współbieżnych połączeń klienta TCP lub jeśli dostosowano ten limit na podstawie ruchu pre-LocalDNS, nowe połączenia TCP z localDNS mogą zostać odrzucone, powodując niepowodzenia rozpoznawania nazw DNS w całym klastrze. Przed włączeniem funkcji LocalDNS pozostaw limit połączeń TCP na odpowiednio wysokiej wartości domyślnej, po jego włączeniu zweryfikuj ustaloną liczbę połączeń TCP na węzłach AKS, a następnie dostosuj ten limit, pozostawiając zapas na skalowanie w poziomie węzłów, uaktualnienia i ponowne tworzenie obrazów.

Wymagania wstępne

Klastry AKS Automatic są dostarczane ze wstępnie skonfigurowaną usługą LocalDNS. Wymagania wstępne w tej sekcji mają zastosowanie głównie podczas włączania lub dostosowywania zachowania LocalDNS, które jest najczęściej stosowane w scenariuszach dostosowywania standardowego i zaawansowanego usługi AKS.

• Aby korzystać z funkcji LocalDNS, musisz mieć istniejący klaster AKS z Kubernetes w wersji 1.31 lub nowszej. Jeśli potrzebujesz klastra usługi AKS, możesz go utworzyć przy użyciu Azure CLI, Azure PowerShell lub portalu Azure.
• Ten artykuł wymaga Azure CLI w wersji 2.80.0 lub nowszej. Jeśli używasz Azure Cloud Shell, najnowsza wersja jest już zainstalowana.
• Usługa LocalDNS jest obsługiwana tylko w pulach węzłów z systemem Azure Linux lub Ubuntu 22.04 i nowszych.
• Jednostka SKU maszyny wirtualnej używana dla puli węzłów musi mieć co najmniej 4 procesory wirtualne (rdzenie) do obsługi sieci LocalDNS.

Włącz lub dostosuj LocalDNS w klastrze AKS

Ustawienia LocalDNS można skonfigurować na poziomie puli węzłów w usłudze AKS, dzięki czemu można dostosować zachowanie według obciążenia i środowiska.

W usłudze AKS Automatic, localDNS jest już wstępnie skonfigurowany, więc ta sekcja jest przeznaczona głównie do dostosowywania.

W usłudze AKS Standard użyj tej sekcji, aby włączyć i skonfigurować usługę LocalDNS.

Zweryfikuj niestandardowy DNS przed włączeniem LocalDNS

Jeśli sieć wirtualna używa niestandardowych serwerów DNS, przetestuj oba transporty DNS z węzła AKS przed włączeniem LocalDNS:

dig +udp @<custom-dns-ip> <fqdn>
dig +tcp @<custom-dns-ip> <fqdn>

Oba polecenia muszą zwrócić prawidłową odpowiedź. Jeśli UDP działa, ale dla TCP występuje przekroczenie limitu czasu, nie włączaj funkcji LocalDNS, dopóki port TCP 53 nie będzie dozwolony na całej ścieżce sieciowej, a niestandardowy serwer DNS nie będzie skonfigurowany tak, aby akceptował zapytania TCP.

Włącz LocalDNS w puli węzłów

Ten krok ma zwykle zastosowanie do usługi AKS Standard. AKS Automatic ma już wstępnie skonfigurowaną funkcję LocalDNS.

Aby włączyć LocalDNS przy tworzeniu puli węzłów, użyj następującego polecenia z niestandardowym plikiem konfiguracji.

az aks nodepool add --name mynodepool1 --cluster-name myAKSCluster --resource-group myResourceGroup --localdns-config ./localdnsconfig.json

Aby włączyć LocalDNS na istniejącej puli węzłów, użyj następującego polecenia z niestandardowym plikiem konfiguracji:

az aks nodepool update --name mynodepool1 --cluster-name myAKSCluster --resource-group myResourceGroup --localdns-config ./localdnsconfig.json

Wyłącz LocalDNS w puli węzłów

Wyłączenie sieci LocalDNS jest operacją zaawansowaną i zazwyczaj nie jest zalecane w przypadku domyślnych ustawień produkcyjnych automatycznych usługi AKS, chyba że masz zweryfikowany wyjątek.

Aby wyłączyć localDNS dla puli węzłów, należy zaktualizować plik localdnsconfig.json , ustawiając mode właściwość na Disabled. Ta zmiana instruuje usługę AKS do wyłączenia lokalnego serwera proxy DNS na wszystkich węzłach w określonej puli, co powoduje przywrócenie rozpoznawania nazw DNS do domyślnego działania klastra. Po zaktualizowaniu pliku konfiguracji zastosuj go do puli węzłów przy użyciu Azure CLI, aby upewnić się, że zmiana zostanie zastosowana.

az aks nodepool update --name mynodepool1 --cluster-name myAKSCluster --resource-group myResourceGroup --localdns-config ./localdnsconfig.json

Weryfikowanie operacji LocalDNS

W usłudze AKS Automatic weryfikacja potwierdza, że wstępnie skonfigurowana konfiguracja bazowa LocalDNS jest aktywna dla Twoich obciążeń. W standardzie AKS weryfikacja potwierdza wdrożenie funkcji LocalDNS.

Po włączeniu usługi LocalDNS można zweryfikować jego działanie, uruchamiając zapytania DNS z zasobników w określonej puli węzłów i sprawdzając SERVER pole w odpowiedziach, aby potwierdzić, że zwracane są adresy LocalDNS (169.254.10.10 lub 169.254.10.11).

Przed uruchomieniem kroków weryfikacji upewnij się, że spełnione są następujące warunki:

1. Zainstalowano kubectl i skonfigurowano dostęp do klastra usługi AKS.
2. Konto użytkownika ma wystarczające uprawnienia do tworzenia i przeprowadzania operacji exec w podach.
3. Pula węzłów, w której chcesz zweryfikować LocalDNS, jest w stanie Gotowe.
4. Obraz BusyBox (busybox:1.28) jest dostępny z węzłów klastra.

Przykład weryfikacji:

1. Utwórz zasobnik debugowania w puli węzłów, w której włączono funkcję LocalDNS:

   kubectl run dnstest --image=busybox:1.28 -- sleep 3600
   

2. Po uruchomieniu zasobnika wykonaj następujące polecenie, aby sprawdzić rozpoznawanie nazw DNS:

   kubectl exec -it dnstest -- nslookup kubernetes.default
   

   Sprawdź dane wyjściowe. Jeśli localDNS działa poprawnie, powinna zostać wyświetlona odpowiedź z adresem serwera 169.254.10.10 lub 169.254.10.11:

   Server:    169.254.10.10
   Address 1: 169.254.10.10
   
   Name:      kubernetes.default
   Address 1: 10.0.0.1 kubernetes.default.svc.cluster.local
   

Konfigurowanie sieci LocalDNS

Usługa LocalDNS używa pliku konfiguracji opartego na formacie JSON localdnsconfig.json do definiowania zachowania rozpoznawania nazw DNS dla każdej puli węzłów. Ten plik umożliwia określenie trybów operacyjnych, bloków serwera dla różnych domen DNS i ustawień wtyczki, takich jak buforowanie, przekazywanie i rejestrowanie.

Domyślna konfiguracja localDNS

W usłudze AKS Automatic funkcja LocalDNS jest wstępnie skonfigurowana. Dostosowywanie należy używać tylko wtedy, gdy masz określone wymaganie.

W usłudze AKS Standard ta domyślna konfiguracja jest dobrym punktem wyjścia.

Podczas dostosowywania LocalDNS użyj następującego formatu konfiguracji jako szablonu. W razie potrzeby można zdefiniować dodatkowe bloki serwera, ale dodanie nieobsługiwanych lub niestandardowych właściwości najwyższego poziomu do konfiguracji powoduje niepowodzenia walidacji.

{
  "mode": "Required",
  "vnetDNSOverrides": {
    ".": {
      "queryLogging": "Error",
      "protocol": "PreferUDP",
      "forwardDestination": "VnetDNS",
      "forwardPolicy": "Sequential",
      "maxConcurrent": 1000,
      "cacheDurationInSeconds": 3600,
      "serveStaleDurationInSeconds": 3600,
      "serveStale": "Immediate"
    },
    "cluster.local": {
      "queryLogging": "Error",
      "protocol": "ForceTCP",
      "forwardDestination": "ClusterCoreDNS",
      "forwardPolicy": "Sequential",
      "maxConcurrent": 1000,
      "cacheDurationInSeconds": 3600,
      "serveStaleDurationInSeconds": 3600,
      "serveStale": "Immediate"
    }
  },
  "kubeDNSOverrides": {
    ".": {
      "queryLogging": "Error",
      "protocol": "PreferUDP",
      "forwardDestination": "ClusterCoreDNS",
      "forwardPolicy": "Sequential",
      "maxConcurrent": 1000,
      "cacheDurationInSeconds": 3600,
      "serveStaleDurationInSeconds": 3600,
      "serveStale": "Immediate"
    },
    "cluster.local": {
      "queryLogging": "Error",
      "protocol": "ForceTCP",
      "forwardDestination": "ClusterCoreDNS",
      "forwardPolicy": "Sequential",
      "maxConcurrent": 1000,
      "cacheDurationInSeconds": 3600,
      "serveStaleDurationInSeconds": 3600,
      "serveStale": "Immediate"
    }
  }
}

Konfigurowanie mode dla LocalDNS

LocalDNS można włączyć w trzech możliwych trybach, które definiują zakres stosowania LocalDNS dla obciążenia.

• Required: LocalDNS jest wymuszany dla puli węzłów, jeśli spełnione są wszystkie wymagania wstępne. Jeśli wymagania nie zostaną spełnione, wdrożenie zakończy się niepowodzeniem.
• Disabled: wyłącza lokalną funkcję DNS, więc zapytania DNS nie są rozpoznawane lokalnie w węźle.
• Preferred: AKS sprawdza, czy konfiguracja usługi LocalDNS jest poprawna składniowo, ale nie włącza usługi LocalDNS na węzłach. Jednak zastosowanie tego trybu nadal wyzwala operację ponownego obrazu węzła, dzięki czemu można przetestować konfigurację pod kątem błędów bez wpływu na rozpoznawanie nazw DNS w klastrze.

W przypadku obciążeń produkcyjnych w usłudze AKS Automatic zachowaj wstępnie skonfigurowane zachowanie LocalDNS, chyba że istnieje potwierdzona potrzeba jego dostosowania.

W poniższej tabeli przedstawiono podsumowanie zachowania localDNS dla każdego trybu i wersji platformy Kubernetes:

Bloki serwera dla LocalDNS

Domyślna konfiguracja ma zastosowanie do zapytań z zasobników przy użyciu dnsPolicy:default (w obszarze vnetDNSOverrides) i zasobników przy użyciu dnsPolicy:ClusterFirst (w obszarze kubeDNSOverrides). W każdym z nich zdefiniowano dwa domyślne bloki serwera: . i cluster.local.

• . reprezentuje wszystkie zewnętrzne zapytania DNS z podów, które próbują rozpoznać domeny publiczne lub nie-klastrowe (na przykład microsoft.com).
• cluster.local reprezentuje wszystkie wewnętrzne zapytania odnajdywania usługi Kubernetes z zasobników, które próbują rozpoznać nazwy usługi Kubernetes lub wewnętrzne zasoby klastra. Te zapytania są kierowane za pośrednictwem sieci CoreDNS w celu rozwiązania w klastrze.

Obsługiwane wtyczki dla konfiguracji LocalDNS

Reguły sprawdzania poprawności konfiguracji

Podczas tworzenia konfiguracji localDNS należy pamiętać o tych regułach walidacji, aby uniknąć błędów wdrażania:

• Ograniczenia strefy korzenia (.): W vnetDNSOverrides, forwardDestination strefy korzenia nie może być ClusterCoreDNS.
• Ograniczenia strefy Cluster.local: zarówno w jak i vnetDNSOverrides, parametr kubeDNSOverrides dla elementu forwardDestination nie może być cluster.local.
• Zgodność z protokołem i parametrem serveStale: Jeśli protocol jest ustawiony na ForceTCP, nie można ustawić serveStale na Verify. Użyj Immediate zamiast tego.

Tworzenie niestandardowego bloku serwera w lokalnej sieciDNS

CoreDNS dopasowuje zapytania do określonego bloku serwera na podstawie dokładnego dopasowania do domeny, a nie częściowych dopasowań. Jeśli potrzebujesz niestandardowych bloków serwera, możesz dodać je do konfiguracji LocalDNS, tworząc plik o nazwie localdnsconfig.json z dodanymi konfiguracjami.

Jeśli na przykład masz określone potrzeby DNS podczas uzyskiwania dostępu do microsoft.com, możesz użyć następującego bloku serwera:

"microsoft.com": {
  "queryLogging": "Error",
  "protocol": "ForceTCP",
  "forwardDestination": "ClusterCoreDNS",
  "forwardPolicy": "Sequential",
  "maxConcurrent": 1000,
  "cacheDurationInSeconds": 3600,
  "serveStaleDurationInSeconds": 3600,
  "serveStale": "Immediate"
}

Monitorowanie lokalnych sieciDN

W usłudze AKS Automatic,LocalDNS jest wstępnie skonfigurowany, więc zacznij od walidacji punktu odniesienia i monitorowania zachowania przed zastosowaniem dostrajania niestandardowego.

Usługa LocalDNS uwidacznia metryki Rozwiązania Prometheus, których można użyć do monitorowania i zgłaszania alertów. Metryki są widoczne na porcie 9253 adresu IP węzła.

Przykładowa konfiguracja scrapingu dla dodatku Azure Managed Prometheus w formie obiektu DaemonSet:

kind: ConfigMap
apiVersion: v1
metadata:
  name: ama-metrics-prometheus-config-node
  namespace: kube-system
data:
  prometheus-config: |-
    global:
      scrape_interval: 1m
    scrape_configs:
    - job_name: localdns-metrics
      scrape_interval: 1m
      scheme: http
      metrics_path: /metrics
      relabel_configs:
      - source_labels: [__metrics_path__]
        regex: (.*)
        target_label: metrics_path
      - source_labels: [__address__]
        replacement: '$NODE_NAME'
        target_label: instance
      static_configs:
      - targets: ['$NODE_IP:9253']

Rozwiązywanie problemów z LocalDNS

Zapytania DNS do określonych domen kończą się niepowodzeniem

Jeśli po włączeniu funkcji LocalDNS zapytania DNS do określonych domen kończą się niepowodzeniem:

1. Sprawdź, czy masz nadpisania specyficzne dla domeny w localdnsconfig.json, które mogą być nieprawidłowo skonfigurowane.

2. Tymczasowo spróbuj usunąć przesłonięcia specyficzne dla domeny i użyć tylko konfiguracji domyślnej . .

3. Sprawdź, czy problem występuje w przypadku protokołu UDP (User Datagram Protocol) i protokołu TCP (Transmission Control Protocol), dostosowując protocol ustawienie.

4. Sprawdź dzienniki CoreDNS pod kątem przekroczeń limitu czasu dla adresów LocalDNS 169.254.10.10:53 lub 169.254.10.11:53. Z węzła, którego dotyczy problem, przetestuj nadrzędny niestandardowy serwer DNS oddzielnie za pośrednictwem protokołu UDP i TCP:

   dig +udp @<custom-dns-ip> <fqdn>
   dig +tcp @<custom-dns-ip> <fqdn>
   

   Jeśli protokół UDP powiedzie się, ale protokół TCP zakończy się niepowodzeniem, sprawdź, czy:

   • Niestandardowy serwer DNS nasłuchuje na porcie 53 protokołu TCP.
   • Sieciowe grupy zabezpieczeń i zapory zezwalają na port TCP 53 z podsieci węzła usługi AKS.
   • Urządzenia NVA i trasy nie odrzucają ruchu DNS przez TCP ani nie kierują go asymetrycznie.

   Aby wyłączyć ustawienia LocalDNS w puli węzłów, której dotyczy problem, zaktualizuj jego tryb LocalDNS na Disabled. Zmiana włączonej puli na Disabled powoduje ponowne utworzenie obrazu węzła w ramach aktualizacji. Aby uzyskać stałą poprawkę, upewnij się, że niestandardowy serwer DNS i ścieżka sieciowa obsługują system DNS zarówno za pośrednictwem protokołu UDP, jak i protokołu TCP na porcie 53.

Aktualizowanie serwerów DNS VNet dla LocalDNS

Podczas aktualizowania niestandardowych serwerów DNS bezpośrednio w konfiguracji sieci wirtualnej (przy użyciu portalu Azure lub interfejsu wiersza polecenia) węzły klastra usługi AKS nie stosują tych zmian automatycznie. Aktualizowanie ustawień DNS na poziomie sieci wirtualnej informuje tylko dostawcę zasobów sieciowych (NRP), ale nie powiadamia dostawcy zasobów usługi AKS. W związku z tym węzły usługi AKS będą nadal używać poprzednich ustawień serwera DNS do momentu podjęcia dalszych działań.

Aby upewnić się, że węzły AKS przejmują nowe ustawienia serwera DNS dla sieci wirtualnej (VNet):

1. Zaktualizuj konfigurację DNS sieci wirtualnej przy użyciu witryny Azure Portal lub interfejsów API zgodnie z potrzebami.

2. Użyj dostawcy zasobów AKS, aby przeinstalować pulę węzłów, a następnie upewnij się, że zaktualizowane ustawienia DNS są stosowane i zachowywane.

   az aks nodepool upgrade --resource-group myResourceGroup --cluster-name myAKSCluster --name mynodepool --node-image-only
   

Ten proces zapewnia, że dostawca zasobów usługi AKS jest świadomy zmian DNS i stosuje je do wszystkich węzłów w puli węzłów.

Zaktualizuj zasady sieciowe Cilium, aby zezwolić na rozwiązywanie nazw DNS za pomocą LocalDNS

W przypadku wdrażania zasad sieci Cilium w klastrze należy jawnie zezwolić na ruch wychodzący podów do adresów IP LocalDNS.

Zasady sieciowe wymuszają domyślny model odmowy dla miejsc docelowych, które nie są określone, więc ruch DNS do sieci LocalDNS jest blokowany, chyba że jest jawnie dozwolony.

• Na Azure CNI Zasilane przez Cilium <=v1.16 z k8s <=1.31, można to osiągnąć za pomocą zasad opartych na CIDR.
• Na Azure CNI obsługiwanym przez Cilium >=v1.17 z K8s >=1.32, można użyć Polityki sieciowej Cilium zezwalającej na ruch wychodzący do jednostek hosta.

Informacje na temat zasady sieciowej Cilium, która zezwala na ruch we wszystkich wersjach, można znaleźć w artykule Czy lokalny system DNS usługi AKS jest obsługiwany w przypadku Azure CNI obsługiwanego przez Cilium?

Treści powiązane

• Co to jest usługa AKS Automatic?
• Utwórz klaster automatyczny AKS
• LocalDNS w Azure Kubernetes Service (koncepcyjne)
• Rozwiązywanie problemów z usługą LocalDNS w usłudze AKS
• Przewodnik dostosowywania usługi CoreDNS
• Strona projektu nadrzędnego coreDNS
• Pojęcia dotyczące sieci dla aplikacji w usłudze AKS