AWX, MetalLB, Gateway API, TLS – Bring it all together

In diesem Artikel beschreibe ich, wie nun alle Komponenten aus den letzten Artikeln zusammengebracht werden: AWX, MetalLB und die Gateway API von Kubernetes – um dann endlich AWX auch über SSL betreiben zu können.

Voraussetzung ist eine laufende AWX Instanz mit einem entsprechenden Service, MetalLB mit einem zugreifbaren IP Pool und die konfigurierte und nutzbare Gateway API im K8s Cluster. Desweiteren benötigt man natürlich ein TLS Zertifikat mit Private-Key. Und das ist auch der erste Schritt: Die Erstellung eines Secret im Namespace „awx“ mit dem Server-Zertifikat, dem Key und entsprechenden CA Zertifikaten.

kubectl -n awx create secret tls awx-cert --key awx_cert.key --cert awx_fullchain.crt

Wie der Name des Zertifikats vermuten lässt, handelt es sich um das Fullchain-Zertifikat. Zur Erinnnerung was dafür in der crt-Datei in welcher Reihenfolge stehen muss:

1. Server Zertifikat
2. Sub CA Zertifikat (falls vorhanden)
3. Root CA Zertifikat

Gateway

Als nächstes wird ein Gateway für AWX mittels der Gateway API erstellt. In den „specs“ sieht man auch, dass hier die NGINX Gateway Class (nginx) verwendet werden soll. Um sicher zu gehen, kann man nochmals prüfen, ob diese zur Verfügung steht:

kubectl get gatewayclasses

Zudem wird hier auch das neu erstellte Secret mit dem TLS Zertifikat angegeben (certificateRefs).

Erstellen des Gateway-Manifests:

nano awx-gateway.yml

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: awx-gateway
  namespace: awx
spec:
  gatewayClassName: nginx
  listeners:
  - name: ansible-awx-service
    protocol: HTTPS
    port: 443
    hostname: awx.xyz.com
    tls:
      certificateRefs:
      - kind: Secret
        name: awx-cert
        namespace: awx

Wichtig: Hier wird angegeben, wie der Service von AWX heißt. Falls man sich nicht mehr sicher ist, kann man hiermit nachschauen:

kubectl get svc -n awx

Gateway erstellen:

kubectl apply -f awx-gateway.yml

Nach einiger Zeit sollte das Gateway vorhanden und nutzbar sein:

kubectl get gateway -n awx

Und hier ist ein entscheidender Punkt: Sofern MetalLB richtig konfiguriert wurde, bekommt das Gateway eine (bzw. die nächste freie IP) aus dem Pool. Erst dann ändert sich der „PROGRAMMED“ Parameter auch auf „True“. Sofern die Ausgabe nicht so aussieht, muss MetalLB überprüft werden.

Route

Was noch fehlt ist die Route. Diese stellt die Verbindung zwischen dem gerade erstellten Gateway und dem AWX Service her.

Erstellen des Manifests:

nano awx-route.yml

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: awx-route
  namespace: awx
spec:
  parentRefs:
  - name: awx-gateway
    namespace: awx
  hostnames: ["awx.xyz.com"]
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: ansible-awx-service
      port: 80

Route erstellen:

kubectl apply -f awx-route.yml

Abfragen kann man diese mittels

kubectl get HTTProute -n awx

Wenn man nochmals die Services abfragt, sollte die Ausgabe folgendermaßen aussehen:

AWX wird jetzt über diese Schritte angesprochen:

1. awx-gateway-nginx – 192.168.2.40 – Port 443
2. awx-route
3. ansible-awx-service – Port 80
4. ansible-awx-web Pod

Auf diese Art und Weise lassen sich natürlich beliebige Services per HTTPS konfigurieren – AWX ist nur ein Beispiel.

1. Gateway mit Secret
2. Route
3. Service
4. Pod

Es war ein langer Weg hierher, aber wenn man es einmal verstanden hat, ist der Aufbau logisch und nachvollziehbar. Mein Glück war u.a. letztlich, dass ich frisch mit dem Thema Gateway API einsteigen konnte.

In den nächsten Artikeln gehe ich auf die Funktionsweise von AWX selbst ein und veranschauliche, wie man Ansible Inventories und Code über Gitlab konfiguriert und benutzt. Hinzu kommen später selbst erstellte Execution Environments.