Een niet-beheerde ingangscontroller maken

Een controller voor inkomend verkeer is een stukje software dat omgekeerde proxy’s, configureerbare verkeersroutering en TLS-beëindiging voor Kubernetes-services biedt. Kubernetes-resources voor inkomend verkeer worden gebruikt om de regels en routes voor uitgaand verkeer worden geconfigureerd voor individuele Kubernetes-services. Bij gebruik van een toegangscontroller en regels voor inkomend verkeer kan er één enkel IP-adres worden gebruikt voor het routeren van verkeer naar meerdere services in een Kubernetes-cluster.

In dit artikel leest u hoe u de NGINX-ingangscontroller implementeert in een AKS-cluster (Azure Kubernetes Service). Er worden vervolgens twee toepassingen uitgevoerd in het AKS-cluster, die elk toegankelijk zijn via het ene IP-adres.

Belangrijk

De invoegtoepassing Toepassingsroutering wordt aanbevolen voor inkomend verkeer in AKS. Zie Beheerde nginx-toegangsbeheerobjecten met de invoegtoepassing voor toepassingsroutering voor meer informatie.

Notitie

Er zijn twee opensource-ingangscontrollers voor Kubernetes op basis van Nginx: één wordt onderhouden door de Kubernetes-community (kubernetes/ingress-nginx) en één wordt onderhouden door NGINX, Inc. (nginxinc/kubernetes-ingress). In dit artikel wordt de controller voor inkomend verkeer van de Kubernetes-community gebruikt.

Voordat u begint

  • In dit artikel wordt Helm 3 gebruikt om de NGINX-ingangscontroller te installeren op een ondersteunde versie van Kubernetes. Zorg ervoor dat u de nieuwste versie van Helm gebruikt en toegang hebt tot de ingress-nginx Helm-opslagplaats. De stappen die in dit artikel worden beschreven, zijn mogelijk niet compatibel met eerdere versies van de Helm-grafiek, NGINX-ingangscontroller of Kubernetes.
  • In dit artikel wordt ervan uitgegaan dat u een bestaand AKS-cluster hebt met een geïntegreerd Azure Container Registry (ACR). Zie Verifiëren met Azure Container Registry vanuit Azure Kubernetes Service voor meer informatie over het maken van een AKS-cluster met een geïntegreerde ACR.
  • Het Kubernetes API-statuseindpunt is healthz afgeschaft in Kubernetes v1.16. U kunt dit eindpunt vervangen door de livez eindpunten en readyz eindpunten. Zie Kubernetes-API-eindpunten voor de status om te bepalen welk eindpunt moet worden gebruikt voor uw scenario.
  • Als u Azure CLI gebruikt, moet u voor dit artikel azure CLI versie 2.0.64 of hoger uitvoeren. Voer az --version uit om de versie te bekijken. Als u Azure CLI 2.0 wilt installeren of upgraden, raadpleegt u Azure CLI 2.0 installeren.
  • Als u Azure PowerShell gebruikt, moet u voor dit artikel Azure PowerShell versie 5.9.0 of hoger gebruiken. Voer Get-InstalledModule -Name Az uit om de versie te bekijken. Als u PowerShell wilt installeren of upgraden, raadpleegt u De Azure PowerShell installeren.

Basisconfiguratie

Als u een eenvoudige NGINX-ingangscontroller wilt maken zonder de standaardwaarden aan te passen, gebruikt u Helm. De volgende configuratie maakt gebruik van de standaardconfiguratie voor het gemak. U kunt parameters toevoegen voor het aanpassen van de implementatie, zoals --set controller.replicaCount=3.

Notitie

Als u het behoud van ip-adressen van clientbronnen wilt inschakelen voor aanvragen voor containers in uw cluster, voegt u deze toe --set controller.service.externalTrafficPolicy=Local aan de installatieopdracht van Helm. Het IP-adres van de clientbron wordt opgeslagen in de aanvraagheader onder X-Forwarded-For. Wanneer u een ingangscontroller gebruikt waarvoor ip-behoud van clientbronnen is ingeschakeld, werkt TLS-passthrough niet.

NAMESPACE=ingress-basic

helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update

helm install ingress-nginx ingress-nginx/ingress-nginx \
  --create-namespace \
  --namespace $NAMESPACE \
  --set controller.service.annotations."service\.beta\.kubernetes\.io/azure-load-balancer-health-probe-request-path"=/healthz \
  --set controller.service.externalTrafficPolicy=Local

Notitie

In deze zelfstudie service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path wordt ingesteld op /healthz. Dit betekent dat als de antwoordcode van de aanvragen niet /healthz200is, de volledige ingangscontroller niet beschikbaar is. U kunt de waarde wijzigen in andere URI's in uw eigen scenario. U kunt dit onderdeel niet verwijderen of de waarde ongedaan maken, of de ingangscontroller is nog steeds niet beschikbaar. Het pakket ingress-nginx dat in deze zelfstudie wordt gebruikt, dat wordt geleverd door kubernetes official, retourneert altijd 200 antwoordcode als deze aanvraagt /healthz, omdat het is ontworpen als standaardback-end voor gebruikers om snel aan de slag te gaan, tenzij het wordt overschreven door regels voor inkomend verkeer.

Aangepaste configuratie

Als alternatief voor de basisconfiguratie die in de bovenstaande sectie wordt weergegeven, ziet u in de volgende reeks stappen hoe u een aangepaste ingangscontroller implementeert. U kunt een intern statisch IP-adres gebruiken of een dynamisch openbaar IP-adres gebruiken.

Importeer de afbeeldingen die door de Helm-grafiek worden gebruikt in uw ACR

Als u installatiekopieën wilt beheren, wilt u deze importeren in uw eigen Azure Container Registry. De Helm-grafiek van de NGINX-ingangscontroller is afhankelijk van drie containerinstallatiekopieën. Gebruik az acr import deze om deze afbeeldingen in uw ACR te importeren.

REGISTRY_NAME=<REGISTRY_NAME>
SOURCE_REGISTRY=registry.k8s.io
CONTROLLER_IMAGE=ingress-nginx/controller
CONTROLLER_TAG=v1.8.1
PATCH_IMAGE=ingress-nginx/kube-webhook-certgen
PATCH_TAG=v20230407
DEFAULTBACKEND_IMAGE=defaultbackend-amd64
DEFAULTBACKEND_TAG=1.5

az acr import --name $REGISTRY_NAME --source $SOURCE_REGISTRY/$CONTROLLER_IMAGE:$CONTROLLER_TAG --image $CONTROLLER_IMAGE:$CONTROLLER_TAG
az acr import --name $REGISTRY_NAME --source $SOURCE_REGISTRY/$PATCH_IMAGE:$PATCH_TAG --image $PATCH_IMAGE:$PATCH_TAG
az acr import --name $REGISTRY_NAME --source $SOURCE_REGISTRY/$DEFAULTBACKEND_IMAGE:$DEFAULTBACKEND_TAG --image $DEFAULTBACKEND_IMAGE:$DEFAULTBACKEND_TAG

Notitie

Naast het importeren van containerinstallatiekopieën in uw ACR, kunt u ook Helm-grafieken importeren in uw ACR. Zie Helm-grafieken pushen en ophalen naar een Azure Container Registry voor meer informatie.

Een ingangscontroller maken

Als u de ingangscontroller wilt maken, gebruikt u Helm om inkomend-nginx te installeren. De ingangscontroller moet worden gepland op een Linux-knooppunt. Windows Server-knooppunten mogen de ingangscontroller niet uitvoeren. Er wordt een knooppuntselector opgegeven met behulp van de parameter --set nodeSelector om de Kubernetes-planner te laten weten dat de NGINX-ingangscontroller moet worden uitgevoerd op een Linux-knooppunt.

Voor toegevoegde redundantie worden er twee replica's van de NGINX-ingangscontrollers geïmplementeerd met de parameter --set controller.replicaCount. Als u volledig wilt profiteren van het uitvoeren van replica's van de ingangscontroller, moet u ervoor zorgen dat er meer dan één knooppunt in uw AKS-cluster is.

In het volgende voorbeeld wordt een Kubernetes-naamruimte gemaakt voor de toegangsbeheerobjectbronnen met de naam ingress-basic en is bedoeld om binnen die naamruimte te werken. Geef indien nodig een naamruimte op voor uw eigen omgeving. Als uw AKS-cluster niet is ingeschakeld voor op rollen gebaseerd toegangsbeheer van Kubernetes, voegt u deze toe --set rbac.create=false aan de Helm-opdrachten.

Notitie

Als u het behoud van ip-adressen van clientbronnen wilt inschakelen voor aanvragen voor containers in uw cluster, voegt u deze toe --set controller.service.externalTrafficPolicy=Local aan de installatieopdracht van Helm. Het IP-adres van de clientbron wordt opgeslagen in de aanvraagheader onder X-Forwarded-For. Wanneer u een ingangscontroller gebruikt waarvoor ip-behoud van clientbronnen is ingeschakeld, werkt TLS-passthrough niet.

# Add the ingress-nginx repository
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update

# Set variable for ACR location to use for pulling images
ACR_LOGIN_SERVER=<REGISTRY_LOGIN_SERVER>

# Use Helm to deploy an NGINX ingress controller
helm install ingress-nginx ingress-nginx/ingress-nginx \
    --version 4.7.1 \
    --namespace ingress-basic \
    --create-namespace \
    --set controller.replicaCount=2 \
    --set controller.nodeSelector."kubernetes\.io/os"=linux \
    --set controller.image.registry=$ACR_LOGIN_SERVER \
    --set controller.image.image=$CONTROLLER_IMAGE \
    --set controller.image.tag=$CONTROLLER_TAG \
    --set controller.image.digest="" \
    --set controller.admissionWebhooks.patch.nodeSelector."kubernetes\.io/os"=linux \
    --set controller.service.annotations."service\.beta\.kubernetes\.io/azure-load-balancer-health-probe-request-path"=/healthz \
    --set controller.service.externalTrafficPolicy=Local \
    --set controller.admissionWebhooks.patch.image.registry=$ACR_LOGIN_SERVER \
    --set controller.admissionWebhooks.patch.image.image=$PATCH_IMAGE \
    --set controller.admissionWebhooks.patch.image.tag=$PATCH_TAG \
    --set controller.admissionWebhooks.patch.image.digest="" \
    --set defaultBackend.nodeSelector."kubernetes\.io/os"=linux \
    --set defaultBackend.image.registry=$ACR_LOGIN_SERVER \
    --set defaultBackend.image.image=$DEFAULTBACKEND_IMAGE \
    --set defaultBackend.image.tag=$DEFAULTBACKEND_TAG \
    --set defaultBackend.image.digest=""

Een ingangscontroller maken met behulp van een intern IP-adres

Standaard wordt een NGINX-ingangscontroller gemaakt met een dynamische openbare IP-adrestoewijzing. Een algemene configuratievereiste is het gebruik van een intern, particulier netwerk en IP-adres. Met deze aanpak kunt u de toegang tot uw services beperken tot interne gebruikers, zonder externe toegang.

Gebruik de --set controller.service.loadBalancerIP en --set controller.service.annotations."service\.beta\.kubernetes\.io/azure-load-balancer-internal"=true parameters om een intern IP-adres toe te wijzen aan uw ingangscontroller. Geef uw eigen interne IP-adres op voor gebruik met de ingangscontroller. Zorg ervoor dat dit IP-adres nog niet in gebruik is binnen uw virtuele netwerk. Als u een bestaand virtueel netwerk en subnet gebruikt, moet u uw AKS-cluster configureren met de juiste machtigingen voor het beheren van het virtuele netwerk en subnet. Zie Kubenet-netwerken gebruiken met uw eigen IP-adresbereiken in Azure Kubernetes Service (AKS) of Azure CNI-netwerken configureren in Azure Kubernetes Service (AKS) voor meer informatie.

# Add the ingress-nginx repository
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update

# Set variable for ACR location to use for pulling images
ACR_LOGIN_SERVER=<REGISTRY_LOGIN_SERVER>

# Use Helm to deploy an NGINX ingress controller
helm install ingress-nginx ingress-nginx/ingress-nginx \
    --version 4.7.1 \
    --namespace ingress-basic \
    --create-namespace \
    --set controller.replicaCount=2 \
    --set controller.nodeSelector."kubernetes\.io/os"=linux \
    --set controller.image.registry=$ACR_LOGIN_SERVER \
    --set controller.image.image=$CONTROLLER_IMAGE \
    --set controller.image.tag=$CONTROLLER_TAG \
    --set controller.image.digest="" \
    --set controller.admissionWebhooks.patch.nodeSelector."kubernetes\.io/os"=linux \
    --set controller.service.loadBalancerIP=10.224.0.42 \
    --set controller.service.annotations."service\.beta\.kubernetes\.io/azure-load-balancer-internal"=true \
    --set controller.service.annotations."service\.beta\.kubernetes\.io/azure-load-balancer-health-probe-request-path"=/healthz \
    --set controller.admissionWebhooks.patch.image.registry=$ACR_LOGIN_SERVER \
    --set controller.admissionWebhooks.patch.image.image=$PATCH_IMAGE \
    --set controller.admissionWebhooks.patch.image.tag=$PATCH_TAG \
    --set controller.admissionWebhooks.patch.image.digest="" \
    --set defaultBackend.nodeSelector."kubernetes\.io/os"=linux \
    --set defaultBackend.image.registry=$ACR_LOGIN_SERVER \
    --set defaultBackend.image.image=$DEFAULTBACKEND_IMAGE \
    --set defaultBackend.image.tag=$DEFAULTBACKEND_TAG \
    --set defaultBackend.image.digest="" 

De load balancer-service controleren

Controleer de load balancer-service met behulp van kubectl get services.

kubectl get services --namespace ingress-basic -o wide -w ingress-nginx-controller

Wanneer de Kubernetes Load Balancer-service wordt gemaakt voor de NGINX-ingangscontroller, wordt er een IP-adres toegewezen onder EXTERNAL-IP, zoals wordt weergegeven in de volgende voorbeelduitvoer:

NAME                       TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)                      AGE   SELECTOR
ingress-nginx-controller   LoadBalancer   10.0.65.205   EXTERNAL-IP     80:30957/TCP,443:32414/TCP   1m   app.kubernetes.io/component=controller,app.kubernetes.io/instance=ingress-nginx,app.kubernetes.io/name=ingress-nginx

Als u in deze fase naar het externe IP-adres bladert, wordt een 404-pagina weergegeven. Dit komt doordat u nog steeds de verbinding met het externe IP-adres moet instellen. Dit gebeurt in de volgende secties.

Demotoepassingen uitvoeren

Als u de ingangscontroller in actie wilt zien, voert u twee demotoepassingen uit in uw AKS-cluster. In dit voorbeeld gebruikt kubectl apply u twee exemplaren van een eenvoudige Hallo wereld-toepassing te implementeren.

  1. Maak een aks-helloworld-one.yaml bestand en kopieer in het volgende voorbeeld YAML:

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: aks-helloworld-one  
    spec:
      replicas: 1
      selector:
        matchLabels:
          app: aks-helloworld-one
      template:
        metadata:
          labels:
            app: aks-helloworld-one
        spec:
          containers:
          - name: aks-helloworld-one
            image: mcr.microsoft.com/azuredocs/aks-helloworld:v1
            ports:
            - containerPort: 80
            env:
            - name: TITLE
              value: "Welcome to Azure Kubernetes Service (AKS)"
    ---
    apiVersion: v1
    kind: Service
    metadata:
      name: aks-helloworld-one  
    spec:
      type: ClusterIP
      ports:
      - port: 80
      selector:
        app: aks-helloworld-one
    
  2. Maak een aks-helloworld-two.yaml bestand en kopieer in het volgende voorbeeld YAML:

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: aks-helloworld-two  
    spec:
      replicas: 1
      selector:
        matchLabels:
          app: aks-helloworld-two
      template:
        metadata:
          labels:
            app: aks-helloworld-two
        spec:
          containers:
          - name: aks-helloworld-two
            image: mcr.microsoft.com/azuredocs/aks-helloworld:v1
            ports:
            - containerPort: 80
            env:
            - name: TITLE
              value: "AKS Ingress Demo"
    ---
    apiVersion: v1
    kind: Service
    metadata:
      name: aks-helloworld-two  
    spec:
      type: ClusterIP
      ports:
      - port: 80
      selector:
        app: aks-helloworld-two
    
  3. Voer de twee demotoepassingen uit met behulp van kubectl apply:

    kubectl apply -f aks-helloworld-one.yaml --namespace ingress-basic
    kubectl apply -f aks-helloworld-two.yaml --namespace ingress-basic
    

Een toegangsbeheerroute maken

Beide toepassingen worden nu uitgevoerd op uw Kubernetes-cluster. Als u verkeer naar elke toepassing wilt routeren, maakt u een Kubernetes-toegangsbeheerresource. De bron voor inkomend verkeer configureert de regels die verkeer routeren naar een van de twee toepassingen.

In het volgende voorbeeld wordt verkeer naar EXTERNAL_IP/hello-world-one doorgestuurd naar de service met de naam aks-helloworld-one. Verkeer naar EXTERNAL_IP/hello-world-two wordt doorgestuurd naar de aks-helloworld-two service. Verkeer naar EXTERNAL_IP/statisch wordt doorgestuurd naar de service met de naam aks-helloworld-one voor statische assets.

  1. Maak een bestand met de naam hello-world-ingress.yaml en kopieer in het volgende voorbeeld YAML:

    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: hello-world-ingress
      annotations:
        nginx.ingress.kubernetes.io/ssl-redirect: "false"
        nginx.ingress.kubernetes.io/use-regex: "true"
        nginx.ingress.kubernetes.io/rewrite-target: /$2
    spec:
      ingressClassName: nginx
      rules:
      - http:
          paths:
          - path: /hello-world-one(/|$)(.*)
            pathType: Prefix
            backend:
              service:
                name: aks-helloworld-one
                port:
                  number: 80
          - path: /hello-world-two(/|$)(.*)
            pathType: Prefix
            backend:
              service:
                name: aks-helloworld-two
                port:
                  number: 80
          - path: /(.*)
            pathType: Prefix
            backend:
              service:
                name: aks-helloworld-one
                port:
                  number: 80
    ---
    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: hello-world-ingress-static
      annotations:
        nginx.ingress.kubernetes.io/ssl-redirect: "false"
        nginx.ingress.kubernetes.io/rewrite-target: /static/$2
    spec:
      ingressClassName: nginx
      rules:
      - http:
          paths:
          - path: /static(/|$)(.*)
            pathType: Prefix
            backend:
              service:
                name: aks-helloworld-one
                port: 
                  number: 80
    
  2. Maak de toegangsbeheerobjectresource met behulp van de kubectl apply opdracht.

    kubectl apply -f hello-world-ingress.yaml --namespace ingress-basic
    

De ingangscontroller testen

Als u de routes voor de ingangscontroller wilt testen, bladert u naar de twee toepassingen. Open een webbrowser naar het IP-adres van uw NGINX-ingangscontroller, zoals EXTERNAL_IP. De eerste demotoepassing wordt weergegeven in de webbrowser, zoals wordt weergegeven in het volgende voorbeeld:

First app running behind the ingress controller

Voeg nu het pad /hello-world-two toe aan het IP-adres, zoals EXTERNAL_IP/hello-world-two. De tweede demotoepassing met de aangepaste titel wordt weergegeven:

Second app running behind the ingress controller

Een intern IP-adres testen

  1. Maak een testpod en koppel er een terminalsessie aan.

    kubectl run -it --rm aks-ingress-test --image=mcr.microsoft.com/dotnet/runtime-deps:6.0 --namespace ingress-basic
    
  2. Installeren curl in de pod met behulp van apt-get.

    apt-get update && apt-get install -y curl
    
  3. Toegang tot het adres van uw Kubernetes-ingangscontroller met behulp curlvan, zoals http://10.224.0.42. Geef uw eigen interne IP-adres op dat is opgegeven toen u de ingangscontroller hebt geïmplementeerd.

    curl -L http://10.224.0.42
    

    Er is geen pad opgegeven met het adres, dus de ingangscontroller is standaard ingesteld op de / route. De eerste demotoepassing wordt geretourneerd, zoals wordt weergegeven in de volgende verkorte voorbeelduitvoer:

    <!DOCTYPE html>
    <html xmlns="http://www.w3.org/1999/xhtml">
    <head>
        <link rel="stylesheet" type="text/css" href="/static/default.css">
        <title>Welcome to Azure Kubernetes Service (AKS)</title>
    [...]
    
  4. Voeg het pad /hello-world-two toe aan het adres, zoals http://10.224.0.42/hello-world-two.

    curl -L -k http://10.224.0.42/hello-world-two
    

    De tweede demotoepassing met de aangepaste titel wordt geretourneerd, zoals wordt weergegeven in de volgende verkorte voorbeelduitvoer:

    <!DOCTYPE html>
    <html xmlns="http://www.w3.org/1999/xhtml">
    <head>
        <link rel="stylesheet" type="text/css" href="/static/default.css">
        <title>AKS Ingress Demo</title>
    [...]
    

Resources opschonen

In dit artikel is Helm gebruikt om de inkomende onderdelen en voorbeeld-apps te installeren. Wanneer u een Helm-grafiek implementeert, worden er veel Kubernetes-resources gemaakt. Deze resources omvatten pods, implementaties en services. Als u deze resources wilt opschonen, kunt u de hele voorbeeldnaamruimte of de afzonderlijke resources verwijderen.

De voorbeeldnaamruimte en alle resources verwijderen

Als u de volledige voorbeeldnaamruimte wilt verwijderen, gebruikt u de kubectl delete opdracht en geeft u de naamruimtenaam op. Alle resources in de naamruimte worden verwijderd.

kubectl delete namespace ingress-basic

Resources afzonderlijk verwijderen

Een meer gedetailleerde benadering is het verwijderen van de afzonderlijke resources die zijn gemaakt.

  1. Geef de Helm-releases weer met de helm list opdracht.

    helm list --namespace ingress-basic
    

    Zoek naar grafieken met de naam ingress-nginx en aks-helloworld, zoals wordt weergegeven in de volgende voorbeelduitvoer:

    NAME                    NAMESPACE       REVISION        UPDATED                                 STATUS          CHART                   APP VERSION
    ingress-nginx           ingress-basic   1               2020-01-06 19:55:46.358275 -0600 CST    deployed        nginx-ingress-1.27.1    0.26.1  
    
  2. Verwijder de releases met de helm uninstall opdracht.

    helm uninstall ingress-nginx --namespace ingress-basic
    
  3. Verwijder de twee voorbeeldtoepassingen.

    kubectl delete -f aks-helloworld-one.yaml --namespace ingress-basic
    kubectl delete -f aks-helloworld-two.yaml --namespace ingress-basic
    
  4. Verwijder de route voor inkomend verkeer dat verkeer naar de voorbeeld-apps heeft geleid.

    kubectl delete -f hello-world-ingress.yaml
    
  5. Verwijder de naamruimte met behulp van de kubectl delete opdracht en geef de naamruimtenaam op.

    kubectl delete namespace ingress-basic
    

Volgende stappen

Zie TLS gebruiken met een ingangscontroller om TLS te configureren met uw bestaande toegangsbeheerobjectonderdelen.

Als u uw AKS-cluster wilt configureren voor het gebruik van HTTP-toepassingsroutering, raadpleegt u de invoegtoepassing Http-toepassingsroutering inschakelen.

Dit artikel bevat enkele externe onderdelen voor AKS. Zie de volgende projectpagina's voor meer informatie over deze onderdelen: