Wir sind inzwischen in der Lage, Webanwendungen in unser Kubernetes zu deployen, und können per kubectl port-forward von unserem lokale Rechner auf die Anwendungen zugreifen.

Im letzten Blogpost GitOps haben wir einen Ingresscontroller per GitOps installiert und können nun per Ingress, Services aus dem Internet erreichbar machen. Dieser Blogpost erläutert einige Hintergründe zum Setup.

In einer klassischen IT-Architektur übernimmt häufig ein sogenannter Reverse-Proxy diese Aufgabe. Er leitet auf verschiedenen Webseiten direkt auf dem Webserver oder auch auf andere Server hinter der Firewall weiter.

In Kubernetes wird die Funktion des Reverse-Proxies vom sogenannten Ingress-Controller zur Verfügung gestellt. Es gibt mittlerweile zahlreiche verschiedene Implementierungen. Bekannte und häufig genutzte Implementierungen sind z.B.

• Nginx
• Traefik
• Ambassador

Ich habe mich für eine Kombination aus Nginx-Ingress und HA-Proxy entschieden. Wobei der eigentliche Ingresscontroller ein Nginx ist. Der Service hat den Typ NodePort und öffnet die Ports 31080 (HTTP) und 31443 (HTTPS).

NodePort, ClusterIp, …

In Kubernetes stehen verschiedene Typen von Services zur Verfügung. Der Hauptunterschied ist die Art und Weise, wie die Services Ports exponieren.

Mehr Informationen zu den verschiedenen Typen von Services sind zu finden unter https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types

Auf den Master-Nodes ist ein HA-Proxy installiert, der die Last auf die NodePorts (31080 und 31443) aller 5 Nodes verteilt. Die HA-Proxies wurden wie im Blogpost Konfiguration der Basis Infrastruktur beschrieben per Ansible installiert.

Installation des Ingress-Controllers

Die Installation des Ingress-Controllers per GitOps ist bereits im Blogpost GitOps beschrieben. Um den Ingress-Controller per Helm-CLI manuell zu installieren, würden wir folgende Befehle ausführen:

helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update
helm upgrade --install ingress-nginx ingress-nginx/ingress-nginx \
--set controller.service.type=NodePort \
--set controller.nodePorts.http=31080 \
--set controller.nodePorts.https=31443 \
--set controller.config.use-proxy-protocol=true \
--set defaultBackend.enabled=true

Ingress

Was für einen Reverse Proxy eine Regel ist (ProxyPass, …), ist für den Ingress-Controller ein Ingress. Ein Ingress wird wie andere Ressourcen im Cluster installiert.

Ein einfaches Beispiel eines Ingress Manifests:

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: test-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - http:
      paths:
      - path: /testpath
        pathType: Prefix
        backend:
          serviceName: test
          servicePort: 80

Wir sind nun der Lage, Webanwendungen aus dem Internet zugänglich zu machen. Ohne SSL/TLS geht heute aber nichts mehr. Transport-Verschlüsselung ist Pflicht. Insofern fehlt noch ein wichtiger Schritt, um unsere erste Webseite wirklich online zu bringen. Daher werde ich im nächsten Blogpost beschreiben, wie wir CertManager aufsetzen, um per ACME Let’s encryptZertifikate zu generieren und installieren.