---
title: "Verständlich gemacht: eigene Konfigurationen für ingress-nginx mit kustomize"
description: "Lerne, wie man eigene Konfigurationen für ingress-nginx mit kustomize ausrollt."
canonical_url: "https://www.blueshoe.de/blog/wie-kustomize-ingress-nginx/"
---

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.

![Eigene Konfigurationen für ingress-nginx mit kustomize](/img/blog/kustomize-ingress-nginx.png)

<global-blog-level-info>

- Kubernetes Basics, [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/)
- [Ingress-Nginx](https://github.com/kubernetes/ingress-nginx)
- kustomize

Solltest du Fragen haben, oder dir etwas unklar sein, kannst du die Kommentarfunktion unter dem Artikel nutzen.

</global-blog-level-info>

## 1. Problemstellung

Viele [ingress-nginx](https://github.com/kubernetes/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:

```yaml
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`:

```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:

```yaml
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`:

```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.

<global-call-an-expert :bg="bg-bs-blue">
<template v-slot:buttonBlockTitle="">

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

</template>
</global-call-an-expert>

## 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.

## Sitemap

See the full [sitemap](/sitemap.md) for all pages.