Offloading SSL con il Gateway applicativo per contenitori - API di ingresso

Questo documento consente di configurare un'applicazione di esempio che usa la risorsa Ingress dall'API Ingress:

Background

Il gateway applicativo per contenitori consente lo scaricamento SSL per migliorare le prestazioni di back-end. Vedere lo scenario di esempio seguente:

Figura che mostra l’offloading SSL con il Gateway applicativo per contenitori.

Prerequisiti

Annotazioni

I certificati per Application Gateway per i contenitori devono essere archiviati come segreti di Kubernetes. L'integrazione di Azure Key Vault tramite il driver CSI dell'archivio segreti non è supportata perché il gateway applicazione per i contenitori richiede che i certificati siano locali nel cluster e non possa montarli da volumi esterni. Per la gestione automatica dei certificati, è consigliabile usare cert-manager con Let's Encrypt.

  1. Se si segue la strategia di distribuzione BYO, assicurarsi di configurare l'Application Gateway per le risorse dei contenitori e il controller ALB (Add-on o Helm)

  2. Se si segue la strategia di distribuzione gestita di ALB, assicurarsi di effettuare il provisioning dell'ALB Controller (Add-on o Helm) e dell'Application Gateway per le risorse di contenitori tramite la ApplicationLoadBalancer custom resource.

  3. Distribuire un'applicazione HTTPS di esempio: applicare il file deployment.yaml seguente nel cluster per creare un'applicazione Web di esempio per illustrare l'offload TLS/SSL.

    kubectl apply -f https://raw.githubusercontent.com/MicrosoftDocs/azure-docs/refs/heads/main/articles/application-gateway/for-containers/examples/https-scenario/ssl-termination/deployment.yaml

    Questo comando crea gli elementi seguenti nel cluster:

    • uno spazio dei nomi denominato test-infra
    • un servizio denominato echo nello spazio dei nomi test-infra
    • una distribuzione denominata echo nello spazio dei nomi test-infra
    • un segreto denominato listener-tls-secret nello spazio dei nomi test-infra

Distribuire le risorse dell'API in ingresso necessarie

  1. Creare un ingresso
kubectl apply -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-01
  namespace: test-infra
  annotations:
    alb.networking.azure.io/alb-name: alb-test
    alb.networking.azure.io/alb-namespace: alb-test-infra
spec:
  ingressClassName: azure-alb-external
  tls:
  - hosts:
    - example.com
    secretName: listener-tls-secret
  rules:
  - host: example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: echo
            port:
              number: 80
EOF

Annotazioni

Quando il controller ALB crea l'Application Gateway per le risorse dei contenitori in Azure Resource Manager, usa la convenzione di denominazione seguente per una risorsa frontend: fe-<eight randomly generated characters>.

Se si vuole modificare il nome della risorsa front-end creata in Azure, prendere in considerazione la strategia di distribuzione bring-your-own.

Quando viene creata la risorsa di ingresso, verificare che lo stato mostri il nome host del servizio di bilanciamento del carico e che entrambe le porte siano in ascolto delle richieste.

kubectl get ingress ingress-01 -n test-infra -o yaml

Output di esempio della creazione corretta della risorsa In ingresso.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    alb.networking.azure.io/alb-frontend: FRONTEND_NAME
    alb.networking.azure.io/alb-id: /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/yyyyyyyy/providers/Microsoft.ServiceNetworking/trafficControllers/zzzzzz
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"networking.k8s.io/v1","kind":"Ingress","metadata":{"annotations":{"alb.networking.azure.io/alb-frontend":"FRONTEND_NAME","alb.networking.azure.io/alb-id":"/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/yyyyyyyy/providers/Microsoft.ServiceNetworking/trafficControllers/zzzzzz"},"name"
:"ingress-01","namespace":"test-infra"},"spec":{"ingressClassName":"azure-alb-external","rules":[{"host":"example.com","http":{"paths":[{"backend":{"service":{"name":"echo","port":{"number":80}}},"path":"/","pathType":"Prefix"}]}}],"tls":[{"hosts":["example.com"],"secretName":"listener-tls-secret"}]}}
  creationTimestamp: "2023-07-22T18:02:13Z"
  generation: 2
  name: ingress-01
  namespace: test-infra
  resourceVersion: "278238"
  uid: 17c34774-1d92-413e-85ec-c5a8da45989d
spec:
  ingressClassName: azure-alb-external
  rules:
  - host: example.com
    http:
      paths:
      - backend:
          service:
            name: echo
            port:
              number: 80
        path: /
        pathType: Prefix
  tls:
  - hosts:
    - example.com
    secretName: listener-tls-secret
status:
  loadBalancer:
    ingress:
    - hostname: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.fzyy.alb.azure.com
      ports:
      - port: 80
        protocol: TCP
      - port: 443
        protocol: TCP

Testare l'accesso all'applicazione

A questo punto, è possibile inviare traffico all'applicazione di esempio tramite l’FQDN assegnato al front-end. Usare il comando seguente per ottenere il nome di dominio completo.

fqdn=$(kubectl get ingress ingress-01 -n test-infra -o jsonpath='{.status.loadBalancer.ingress[0].hostname}')

Il curling di questo FQDN deve restituire risposte dal back-end come configurato in HTTPRoute.

fqdnIp=$(dig +short $fqdn)
curl -vik --resolve example.com:443:$fqdnIp https://example.com

Congratulazioni. Il controller ALB è stato installato, è stata distribuita un'applicazione back-end e il traffico è stato instradato all'applicazione tramite ingresso nel Gateway applicativo per contenitori.

  • Last updated on