Services beschikbaar maken met Ingress en automatische TLS via cert-manager

Dit is standaard, open-source Kubernetes-tooling, niet specifiek voor één provider. Het werkt op dezelfde manier, ongeacht op welke infrastructuur je cluster draait. Zie Zelfbeheerde Kubernetes op Worldstream: je infrastructuur kiezen als je dat nog niet hebt gekozen.

Service vs. Ingress

Een Service geeft een groep pods, geselecteerd op label, een stabiel virtueel IP en een DNS-naam, en verdeelt het verkeer daartussen (load balancing). Dat is genoeg voor intern verkeer tussen pods, of voor een Service van het type LoadBalancer die één applicatie extern beschikbaar maakt. Het geeft je geen HTTP-bewuste routering: geen host-gebaseerde regels, geen path-gebaseerde regels, en geen gedeeld toegangspunt voor meerdere applicaties.

Een Ingress-resource zit daar een laag boven. Die beschrijft routeringsregels, bijvoorbeeld "verzoeken voor shop.example.com gaan naar de shop-Service, verzoeken voor api.example.com/v1 gaan naar de api-Service", en een ingress controller die in het cluster draait (nginx-ingress wordt het meest gebruikt, maar Traefik en andere bestaan ook) leest die regels en verzorgt de daadwerkelijke routering. Eén ingress controller, en meestal één externe load balancer of publiek IP-adres, kan op deze manier meerdere applicaties voor zijn rekening nemen.

Een eenvoudig Ingress-manifest

Dit stuurt verkeer voor shop.example.com naar een Service met de naam shop-service op poort 80.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: shop-ingress
  namespace: shop
spec:
  ingressClassName: nginx
  rules:
    - host: shop.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: shop-service
                port:
                  number: 80

Op dit punt levert de Ingress alleen platte HTTP. Om HTTPS te laten werken, moet je óf handmatig een certificaat koppelen, óf, duurzamer, cert-manager de uitgifte en vernieuwing laten regelen.

cert-manager toevoegen voor automatische TLS

cert-manager is een Kubernetes-add-on die certificaataanvragen in de gaten houdt en contact opneemt met een certificaatautoriteit, meestal Let's Encrypt, om certificaten uit te geven en te vernieuwen zonder handmatig ingrijpen. Je installeert het eenmalig in het cluster en configureert het vervolgens met een Issuer of ClusterIssuer die aangeeft welke CA gebruikt wordt en hoe domeineigendom wordt aangetoond.

Een ClusterIssuer die de HTTP-01-challenge van Let's Encrypt gebruikt, waarbij domeineigendom wordt aangetoond door een token via platte HTTP aan te bieden via de ingress controller, ziet er zo uit:

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: platform-team@example.com
    privateKeySecretRef:
      name: letsencrypt-prod-key
    solvers:
      - http01:
          ingress:
            ingressClassName: nginx

Met die ClusterIssuer op zijn plek annoteer je de Ingress en voeg je een tls-blok toe met de naam van het secret dat cert-manager moet aanmaken en actueel houden. cert-manager houdt deze annotatie in de gaten, vraagt het certificaat aan en slaat het op in het genoemde secret, en vernieuwt het automatisch voordat het verloopt.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: shop-ingress
  namespace: shop
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
spec:
  ingressClassName: nginx
  tls:
    - hosts:
        - shop.example.com
      secretName: shop-tls
  rules:
    - host: shop.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: shop-service
                port:
                  number: 80

Vanaf hier verdelen cert-manager en de ingress controller het lopende werk onderling: de controller routeert en beëindigt TLS, cert-manager houdt het certificaat daarachter geldig. Controleer op elk moment de status van een certificaat met kubectl get certificate -n shop en kubectl describe certificate shop-tls -n shop, dat laatste is de snelste manier om te zien waarom een uitgifte is mislukt als het secret niet verschijnt.