Eigene Konfigurationen für ingress-nginx mit kustomize? So geht’s ohne Kopfschmerzen!Verständlich gemacht: eigene Konfigurationen für ingress-nginx mit kustomize

Ingress-nginx ist einer der beliebtesten ingress-controller für Kubernetes. In diesem Blogpost zeigen wir, wie man die ingress-nginx K8s-Ressourcen anpassen und mittels kustomize einfach persistieren kann. Dadurch werden Installation und Updates einfacher und weniger fehleranfällig.

1. Problemstellung

Viele ingress-nginx Installationen benötigen Anpassungen. Sei es ein eigenes Fehler-Backend, wodurch die Command-Args und die ConfigMap angepasst werden müssen. Oder z.B. weil zusätzliche Ports benötigt werden, oder der K8s-Service Annotations benötigt, um mit einem Load Balancer zu matchen. Diese Anpassungen können zwar manuell vorgenommen werden. Das erhöht allerdings sowohl bei der Installation, als auch bei Updates das Risiko, etwas zu übersehen oder falsch zu konfigurieren. Zudem ist jedes Update mühselig und erfordert ein zusätzliches Dokumentieren der Anpassungen, damit man nichts vergisst.

Da stellt sich doch die Frage: wie kann man diese Anpassungen so persistieren, dass sie automatisch aufgegriffen werden und bei Updates bestenfalls nur noch die Versionsnummer angepasst werden muss?

2. Lösungsansatz

kustomize to the rescue! Die Anforderungen sind klar, Anpassungen an den K8s-Ressourcen sollen in Code abgelegt werden und bei der Installation und bei Updates automatisch ausgerollt werden. Kustomize ermöglicht es, die K8s yaml-Manifeste von ingress-nginx als Ressource zu spezifizieren und mit Patches die benötigten Anpassungen vorzunehmen. Folgende kustomization.yaml haben wir in ./base/ingress-nginx abgelegt:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
  - github.com/kubernetes/ingress-nginx/deploy/static/provider/cloud?ref=controller-v1.12.3

patches:
  - path: patch-configmap.yaml
  - path: patch-deployment.yaml
  - path: patch-service.yaml

Als resources werden die K8s-Manifeste in Version 1.12.3 spezifiziert. Zusätzlich haben wir drei Patches, für die Configmap, für das Deployment und für den Service. Diese schauen wir uns in den nächsten Absätzen genauer an.

3. Configmap anpassen

Der Patch für die ConfigMap muss im selben Verzeichnis liegen wie die kustomization.yaml, so wie es dort spezifiziert ist. Hier ist der Inhalt von patch-configmap.yaml:

apiVersion: v1
kind: ConfigMap
metadata:
  name: ingress-nginx-controller
  namespace: ingress-nginx
data:
  proxy-buffer-number: "4"
  proxy-buffer-size: 128k
  proxy-busy-buffers-size: 256k
  custom-http-errors: 404,503,502,504

In der ConfigMap werden ein paar proxy-Werte gesetzt, sowie die HTTP-Statuscodes spezifiziert, für die eine Response vom Custom Errors Backend gerendert werden soll.

4. Command anpassen

Um den Command anzupassen, muss das Deployment gepatcht werden. patch-deployment.yaml sieht folgendermaßen aus:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ingress-nginx-controller
  namespace: ingress-nginx
spec:
  template:
    spec:
      containers:
        - name: controller
          args:
          - /nginx-ingress-controller
          - --publish-service=$(POD_NAMESPACE)/ingress-nginx-controller
          - --election-id=ingress-nginx-leader
          - --controller-class=k8s.io/ingress-nginx
          - --ingress-class=nginx
          - --configmap=$(POD_NAMESPACE)/ingress-nginx-controller
          - --validating-webhook=:8443
          - --validating-webhook-certificate=/usr/local/certificates/cert
          - --validating-webhook-key=/usr/local/certificates/key
          - --tcp-services-configmap=$(POD_NAMESPACE)/tcp-services
          - --default-backend-service=default/nginx-errors
          ports:
            - containerPort: 21
              name: ftp
              protocol: TCP

In diesem Beispiel werden die args überschrieben, um --default-backend-service auf default/nginx-errors zu setzen. Zusätzlich wird noch der Port 21 spezifiziert, um FTP-Requests zu ermöglichen.

5. Service anpassen

Der Service enthält üblicherweise Annotations, die für den Load Balancer relevant sind. Ingress-nginx bietet auch K8s Manifeste, die bereits für AWS, GKE, oder Azure optimiert sind. Falls man diese ergänzen möchte, oder einen anderen Cloud-Anbieter wählt, kann man auch das über einen Patch lösen. Hier ist das entsprechende patch-service.yaml:

apiVersion: v1
kind: Service
metadata:
  name: ingress-nginx-controller
  namespace: ingress-nginx
  annotations:
    load-balancer.hetzner.cloud/location: fsn1
    load-balancer.hetzner.cloud/name: # …
spec:
  ports:
    - name: ftp
      port: 21
      protocol: TCP
      targetPort: ftp

Es sind zwei exemplarische Annotations enthalten, die bei Hetzner relevant sind. Eine, um die Location des Load Balancer zu spezifizieren und die andere für den Namen des Load Balancers. Weiterhin ist am Service auch der Port 21 spezifiziert, damit die FTP-Requests zum Deployment gelangen.

Michael Schilonka LinkedIn

Wir können auch Deine Kubernetes Umgebungen optimieren und verwalten.

Jetzt Kontakt aufnehmen

×

Du kannst einen Termin mit unserem Experten vereinbaren

Michael Schilonka

Termin vereinbaren

oder

oder

Go here

Formular lädt gerade...

Schließen

6. Deployment und Updates

Die yaml-Beispiele aus den vorigen Abschnitten sind bereits alles, was für das Deployment und für Updates benötigt wird. Wenn man manuell mit kubectl deployt, genügt folgender Command: kubectl apply -k ./base/ingress-nginx.

Für Updates muss lediglich die Version in ./base/ingress-nginx/kustomization.yaml angepasst werden und der kubectl Command von oben angewendet werden. Vor jedem Deployment oder Update bietet es sich an, die Ressourcen mittels kubectl kustomize ./base/ingress-nginx rendern zu lassen, damit man überprüfen kann, ob alles korrekt ist.

7. Fazit

Wie ihr hoffentlich gesehen habt, ist es ein einfaches, ingress-nginx mittels kustomize anzupassen. Die Codebeispiele dieses Blogposts sind bereits alles, was man benötigt. Der Inhalt ist natürlich von Fall zu Fall anzupassen. Genauso kann es sein, dass man mehrere Overlays benötigt, weil z.B. im Staging und im Production unterschiedliche Annotations benötigt werden. Aber auch das macht es nicht komplexer. Die Änderungen sind übersichtlich und sauber im Repository abgelegt und damit auch gleich dokumentiert. Bei Updates muss lediglich die Version geändert werden, einfacher geht es nicht.

Aus unserer Sicht gibt es keinen Grund, warum man ingress-nginx Anpassungen nicht mittels kustomize erledigen sollte. Hast du ein Gegenargument? Dann lass es uns gerne in den Kommentaren wissen.

Häufige Fragen

1. Warum sollte ich ingress-nginx überhaupt anpassen?

Viele Setups benötigen Custom-Configs – etwa ein eigenes Fehler-Backend, zusätzliche Ports oder spezielle Load-Balancer-Anbindungen. Ohne Anpassung fehlen oft wichtige Features.

2. Was bringt mir kustomize gegenüber einem Helm-Chart?

Kustomize arbeitet deklarativ und direkt auf Kubernetes-YAMLs. Du brauchst kein Template-Rendering und kannst gezielt einzelne Ressourcen patchen - einfach, lesbar und Git-friendly.

3. Kann ich kustomize auch mit Helm kombinieren?

Ja, aber dieser Blogpost nutzt bewusst nur kustomize, um die ingress-nginx-Standardressourcen direkt zu patchen. Wer Helm einsetzt, kann helm template und kustomize kombinieren.

4. Welche Risiken gibt es bei Updates?

Wenn Upstream-Ressourcen sich stark ändern, können Patches fehlschlagen. Deshalb: Vor jedem Update kubectl kustomize ausführen und prüfen, ob alles sauber rendert.

5. Was, wenn ich mehrere Umgebungen wie Staging und Production habe?

Kustomize unterstützt Overlays. Du kannst ein gemeinsames Base-Verzeichnis nutzen und spezifische Patches pro Umgebung in separaten Overlays definieren.

6. Muss ich bei jeder neuen ingress-nginx-Version alle Patches anpassen?

Nicht unbedingt. Solange sich Namen, Strukturen und Pfade der Ressourcen nicht ändern, bleiben Patches oft stabil. Trotzdem solltest du sie beim Versionswechsel kurz überprüfen.