Problemen met de invoegtoepassing Voor inkomend verkeer van istio-service

In dit artikel wordt beschreven hoe u problemen met toegangsbeheerobjectgateways kunt oplossen in de invoegtoepassing Istio service mesh voor Azure Kubernetes Service (AKS). De Istio-gateway voor inkomend verkeer is een omgekeerde proxy op basis van Envoy die u kunt gebruiken om inkomend verkeer naar workloads in de mesh te routeren.

Voor de invoegtoepassing service-mesh op basis van Istio bieden we de volgende opties voor de gateway voor inkomend verkeer:

• Een interne ingangsgateway die gebruikmaakt van een privé-IP-adres.

• Een externe ingangsgateway die gebruikmaakt van een openbaar toegankelijk IP-adres.

De invoegtoepassing implementeert istio-gatewaypods en implementaties per revisie. Als u een canary-upgrade uitvoert en twee revisies van het besturingsvlak in uw cluster hebt geïnstalleerd, moet u mogelijk meerdere gatewaypods voor inkomend verkeer in beide revisies oplossen.

Controlelijst voor probleemoplossing

Stap 1: zorg ervoor dat er geen firewall- of NSG-regels de ingangsgateway blokkeren

Controleer of u geen firewall- of NSG-regels (Network Security Group) hebt waarmee verkeer naar de toegangsbeheergateway wordt geblokkeerd. U moet expliciet een DNAT-regel (Destination Network Address Translation) toevoegen om inkomend verkeer via Azure Firewall toe te staan aan de gateway voor inkomend verkeer .

Stap 2: gateways, virtuele services en doelregels correct configureren

Wanneer u gateways, virtuele services en doelregels configureert voor verkeersroutering via de gateway voor inkomend verkeer, voert u de volgende stappen uit:

1. Zorg ervoor dat de gatewaykiezer voor inkomend verkeer in de gatewayresource is ingesteld op een van de volgende tekstwaarden als u respectievelijk een externe of interne gateway gebruikt:

   • istio: aks-istio-ingressgateway-external
   • istio: aks-istio-ingressgateway-internal

2. Zorg ervoor dat de poorten correct zijn ingesteld in gateways en virtuele services. Voor de gateway moet de poort zijn ingesteld op 80http of 443 voor https. Voor de virtuele service moet de poort worden ingesteld op de poort waarop de bijbehorende service voor de toepassing luistert.

3. Controleer of de service beschikbaar is in de hosts specificatie voor zowel de gateway als de virtuele service. Als u problemen ondervindt met betrekking tot de Host header in de aanvragen, probeert u alle hosts met een sterretje ('*'), toe te voegen aan de acceptatielijst, zoals in dit voorbeeld van de gatewayconfiguratie. We raden u echter aan de acceptatielijst niet te wijzigen als productiepraktijk. hosts De specificatie moet ook expliciet worden geconfigureerd.

Stap 3: De status van de gatewaypod voor inkomend verkeer herstellen

Als de ingangsgatewaypod vastloopt of niet in de status Gereed wordt weergegeven, controleert u of de Istio-daemon (istiod) de status Gereed heeft. De ingangsgateway is afhankelijk van het gereed hebben van de istiod release.

Als de istiod pod niet in de status Gereed wordt weergegeven, moet u ervoor zorgen dat de aangepaste Resourcedefinities (CRD's) van Istio en de base Helm-grafiek correct zijn geïnstalleerd. Gebruik hiervoor de volgende opdracht:

helm ls --all --all-namespaces

Mogelijk ziet u een bredere fout waarbij de installatie van de invoegtoepassing niet specifiek is geconfigureerd voor de ingangsgateway.

Als de istiod pod in orde is, maar de gatewaypods voor inkomend verkeer niet reageren, controleert u de volgende gatewayresources in de aks-istio-ingress naamruimte om meer informatie te verzamelen:

• Helm-release
• Implementatie
• Service

Daarnaast vindt u meer informatie over gateway- en sidecar-foutopsporing in de invoegtoepassing General Istio service mesh.

Stap 4: Resourcegebruik configureren

Hoog resourcegebruik treedt op wanneer de standaardinstellingen voor min/max replica-instellingen voor Istiod en de gateways niet voldoende zijn. In dit geval wijzigt u configuraties voor automatisch schalen van horizontale pods.

Stap 5: Problemen met de beveiligde toegangsbeheergateway oplossen

Wanneer een externe toegangsgateway is geconfigureerd om een beveiligde HTTPS-service beschikbaar te maken met behulp van eenvoudige of wederzijdse TLS, volgt u deze stappen voor probleemoplossing:

1. Controleer of de waarden van de INGRESS_HOST_EXTERNAL en SECURE_INGRESS_PORT_EXTERNAL omgevingsvariabelen geldig zijn op basis van de uitvoer van de volgende opdracht:

   kubectl -n aks-istio-ingress get service aks-istio-ingressgateway-external
   

2. Controleer op foutberichten in de logboeken van de gatewaycontroller:

   kubectl logs -n aks-istio-ingress <gateway-service-pod>
   

3. Controleer of de geheimen zijn gemaakt in de aks-istio-ingress naamruimte:

   kubectl -n aks-istio-ingress get secrets
   

Voor het voorbeeld in de secure-ingangsgateway voor de invoegtoepassing Istio-service-mesh voor Azure Kubernetes Service moet het productpage-credential geheim worden vermeld.

Nadat u de azure Key Vault-invoegtoepassing voor geheimenprovider hebt ingeschakeld, moet u toegang verlenen tot de door de gebruiker toegewezen beheerde identiteit van de invoegtoepassing aan De Azure Key Vault. Als u de toegang tot Azure Key Vault onjuist instelt, wordt voorkomen dat het productpage-credential geheim wordt gemaakt.

Nadat u de SecretProviderClass resource hebt gemaakt, moet u ervoor zorgen dat geheimen worden gesynchroniseerd van Azure Key Vault naar het cluster, of de voorbeeldpod secrets-store-sync-productpage die verwijst naar deze resource, is geïmplementeerd.

Stap 6: Instellingen voor de gatewayservice voor inkomend verkeer aanpassen

De invoegtoepassing biedt ook ondersteuning voor het aanpassen van de Kubernetes-service voor de istio-ingangsgateway voor bepaalde aantekeningen en de .spec.externalTrafficPolicy instelling. In bepaalde gevallen kan het wijzigen .spec.externalTrafficPolicy om Local te helpen bij het oplossen van connectiviteits- en netwerkproblemen, omdat het ip-adres van de clientbron voor de binnenkomende aanvraag op de ingangsgateway behouden blijft.

Opmerking

Als u verandert .spec.externalTrafficPolicy , Local kan dit leiden tot onevenwichtige verkeersspreiding. Voordat u deze wijziging toepast, raden we u aan de Kubernetes-documentatie te lezen over het behouden van het IP-adres van de clientbron om inzicht te hebben in de afwegingen tussen de verschillende externalTrafficPolicy instellingen.

Verwijzingen

• Inschakeling en configuratie van istio-invoegtoepassing voor inkomend verkeer

• Toegangsbeheerobject

• Concepten voor verkeerbeheer voor gateways

• Istio-gatewayconfiguratie

• Configuratie van virtuele Istio-service

• Verkeersbeheer: gatewaytaken voor inkomend verkeer (TLS-beëindiging, beveiligde gateways, enzovoort)

• Best practices voor Istio-beveiliging voor gateways

• Valkuilen voor verkeerbeheer en gateway

• Istio en Kubernetes-inkomend verkeer

• Kubernetes Gateway-API en Istio Inkomend verkeer

Disclaimerinformatie van derden

De producten van derden die in dit artikel worden vermeld, worden vervaardigd door bedrijven die onafhankelijk zijn van Microsoft. Microsoft verleent dan ook geen enkele garantie, impliciet noch anderszins, omtrent de prestaties of de betrouwbaarheid van deze producten.

Disclaimerinformatie van derden

Microsoft verstrekt contactgegevens van derden om u te helpen bij het vinden van extra informatie over dit onderwerp. Deze contactinformatie kan zonder voorafgaande kennisgeving worden gewijzigd. Microsoft kan niet instaan voor de juistheid van contactgegevens van derden.

Contacteer ons voor hulp

Als u vragen hebt of hulp nodig hebt, maak een ondersteuningsaanvraag of vraag de Azure-communityondersteuning. U kunt ook productfeedback verzenden naar de Azure-feedbackcommunity.