Self-Service-DNS- und Zertifikatsverwaltung in Kubernetes ermöglichen

Jason Schmidt

Das letztendliche Ziel der Anwendungsentwicklung besteht natürlich darin, Apps im Internet bereitzustellen. Kubernetes vereinfacht diesen Prozess für Entwickler bis zu einem gewissen Grad, indem es den Ingress-Controller als Mechanismus zur Weiterleitung von Anfragen an die Anwendung bereitstellt. Doch nicht alles lässt sich so eigenständig erledigen, wie Sie es sich vermutlich wünschen: Sie benötigen weiterhin einen Eintrag im Domain Name System (DNS), um den Domainnamen der App der IP-Adresse des Ingress-Controllers zuzuordnen, sowie ein TLS-Zertifikat, um Verbindungen über HTTPS abzusichern. In den meisten Unternehmen sind Sie nicht selbst für DNS oder TLS zuständig und müssen sich daher mit der dafür verantwortlichen Betriebsabteilung (oder den verantwortlichen Betriebsabteilungen!) abstimmen.

Für Administratoren ist es nicht unbedingt einfacher. In den meisten Unternehmen müssen DNS-Einträge so selten aktualisiert werden, dass die entsprechenden Verfahren – sowohl die Geschäftsregeln als auch die konkreten technischen Schritte – meist nur unzureichend oder gar nicht dokumentiert sind. Wenn Sie einen DNS-Eintrag hinzufügen müssen, müssen Sie daher zunächst die Dokumentation finden, einen Kollegen fragen oder im schlimmsten Fall selbst herausfinden, wie es geht. Außerdem müssen Sie sicherstellen, dass Sie alle Sicherheitsrichtlinien des Unternehmens einhalten und dass der Ingress für die Firewalls korrekt gekennzeichnet ist.

Glücklicherweise gibt es eine Möglichkeit, sowohl Entwicklern als auch Betreibern das Leben zu erleichtern. In diesem Beitrag zeigen wir, wie Betreiber eine Kubernetes-Bereitstellung so konfigurieren können, dass Entwickler DNS-Einträge selbstständig aktualisieren und TLS-Zertifikate in einer Kubernetes-Umgebung generieren können. Indem Sie die Infrastruktur im Voraus aufbauen, können Sie sicherstellen, dass alle erforderlichen geschäftlichen und technischen Anforderungen erfüllt werden.

Überblick und Voraussetzungen

Sobald die Lösung eingerichtet ist, muss ein Entwickler lediglich anhand einer bereitgestellten Vorlage einen Ingress-Controller erstellen, um eine Anwendung im Internet bereitzustellen. Die Vorlage enthält einen vollständig qualifizierten Domänennamen (FQDN) innerhalb einer von der Kubernetes-Installation verwalteten Domäne. Kubernetes verwendet die Vorlage, um dem Ingress-Controller eine IP-Adresse zuzuweisen, den DNS-A-Eintrag zur Zuordnung des FQDN zur IP-Adresse zu erstellen sowie TLS-Zertifikate für den FQDN zu generieren und dem Ingress-Controller hinzuzufügen. Die Bereinigung ist ebenso einfach: Wenn der Ingress entfernt wird, werden auch die DNS-Einträge gelöscht.

Die Lösung nutzt die folgenden Technologien (Installations- und Konfigurationsanweisungen finden Sie weiter unten):

• Kubernetes.
• ExternalDNS.
• cert-manager.
• Let’s Encrypt.
• NGINX Ingress Controller von F5 NGINX, basierend auf NGINX Open Source oder NGINX Plus. Die Lösung funktioniert nicht mit dem von der Kubernetes-Community verwalteten NGINX Ingress Controller. Weitere Informationen zu den Unterschieden zwischen den beiden Projekten finden Sie in unserem Blog.

Bevor Sie die Lösung konfigurieren, benötigen Sie Folgendes:

• Eine Kubernetes-Cloud-Installation mit einem Egress-Objekt (LoadBalancer). Die Lösung verwendet Linode, funktioniert aber auch mit anderen Cloud-Anbietern.
• Ein Domainname, der bei Cloudflare gehostet wird. Wir haben uns für diesen Anbieter entschieden, weil er zu den unterstützten DNS-Anbietern für cert-manager gehört und ExternalDNS unterstützt (zum Zeitpunkt der Erstellung in der Betaphase). Wir empfehlen dringend, die Domain nicht für Produktionsumgebungen oder andere kritische Zwecke zu verwenden.
• Zugriff auf die Cloudflare-API, der im kostenlosen Tarif enthalten ist.
• Helm zur Installation und Bereitstellung von Kubernetes.
• kubectl als Befehlszeilenschnittstelle für Kubernetes.
• Optional K9s, eine ausgereifte textbasierte Benutzeroberfläche (TUI), die eine strukturiertere Interaktion mit Kubernetes ermöglicht.

Wir setzen außerdem voraus, dass Sie über grundlegende Kubernetes-Kenntnisse verfügen (wie Sie ein Manifest anwenden, ein Helm-Chart verwenden und kubectl-Befehle ausführen, um Ausgaben anzuzeigen und Probleme zu beheben). Ein Verständnis der Grundkonzepte von Let’s Encrypt ist hilfreich, aber nicht erforderlich. Einen Überblick finden Sie in unserem Blog. Sie müssen auch nicht wissen, wie cert-manager funktioniert. Wenn Sie jedoch erfahren möchten, wie cert-manager (und Zertifikate im Allgemeinen) mit dem NGINX Ingress Controller funktioniert, lesen Sie meinen kürzlich veröffentlichten Beitrag Automatisierung der Zertifikatsverwaltung in einer Kubernetes-Umgebung.

Wir haben die Lösung sowohl unter macOS als auch unter Linux getestet. Unter Windows-Subsystem für Linux Version 2 (WSL2) haben wir sie zwar nicht getestet, erwarten jedoch keine Probleme.

Hinweis: Die Lösung ist als beispielhafter Machbarkeitsnachweis und nicht für den produktiven Einsatz vorgesehen. Insbesondere berücksichtigt sie nicht alle bewährten Verfahren für Betrieb und Sicherheit. Informationen zu diesen Themen finden Sie in der Dokumentation zu cert-manager und ExternalDNS.

Bereitstellen der Lösung

Führen Sie die in diesen Abschnitten beschriebenen Schritte aus, um die Lösung bereitzustellen:

• Software herunterladen
• NGINX Ingress Controller bereitstellen
• cert-manager bereitstellen
• ExternalDNS bereitstellen
• Beispielanwendung bereitstellen
• Lösung validieren

Software herunterladen

1. Laden Sie Ihr Cloudflare-API-Token herunter.
2. Klonen Sie das Repository des NGINX Ingress Controllers:

$ git clone https://github.com/nginxinc/kubernetes-ingress.gitCloning into 'kubernetes-ingress'...
remote: Enumerating objects: 45176, done.
remote: Counting objects: 100% (373/373), done.
remote: Compressing objects: 100% (274/274), done.
remote: Total 45176 (delta 173), reused 219 (delta 79), pack-reused 44803
Receiving objects: 100% (45176/45176), 60.45 MiB | 26.81 MiB/s, done.
Resolving deltas: 100% (26592/26592), done.

1. Überprüfen Sie, ob Sie eine Verbindung zum Kubernetes-Cluster herstellen können.

$ kubectl cluster-infoKubernetes control plane is running at https://ba35bacf-b072-4600-9a04-e04...6a3d.us-west-2.linodelke.net:443
KubeDNS is running at https://ba35bacf-b072-4600-9a04-e04...6a3d.us-west-2.linodelke.net:443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
 
To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

NGINX Ingress Controller bereitstellen

1. Stellen Sie den NGINX Ingress Controller mit Helm bereit. Beachten Sie, dass wir drei nicht standardmäßige Konfigurationsoptionen hinzufügen:

$ helm install nginx-kic nginx-stable/nginx-ingress --namespace nginx-ingress --set controller.enableCustomResources=true --create-namespace --set controller.enableCertManager=true --set controller.enableExternalDNS=trueNAME: nginx-kic
LAST DEPLOYED: Day Mon DD hh:mm:ss YYYY
NAMESPACE: nginx-ingress
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
The NGINX Ingress Controller has been installed.

• controller.enableCustomResources – Weist Helm an, die benutzerdefinierten Ressourcendefinitionen (CRDs) zu installieren, die zum Erstellen der benutzerdefinierten NGINX-Ressourcen VirtualServer und VirtualServerRoute verwendet werden.
• controller.enableCertManager – Konfiguriert den NGINX Ingress Controller für die Kommunikation mit cert-manager-Komponenten.
• controller.enableExternalDNS – Konfiguriert den Ingress Controller für die Kommunikation mit ExternalDNS-Komponenten.

1. Überprüfen Sie, ob der NGINX Ingress Controller ausgeführt wird, und notieren Sie den Wert im Feld „EXTERNAL-IP“. Dies ist die IP-Adresse des NGINX Ingress Controllers (hier: www.xxx.yyy.zzz). Zur besseren Lesbarkeit wird die Ausgabe auf zwei Zeilen verteilt.

$ kubectl get services --namespace nginx-ingressNAME                      TYPE           CLUSTER-IP      ...
nginx-kic-nginx-ingress   LoadBalancer   10.128.152.88   ... 

   ... EXTERNAL-IP       PORT(S)                      AGE
   ... www.xxx.yyy.zzz   80:32457/TCP,443:31971/TCP   3h8m

cert-manager bereitstellen

In der Lösung verwendet cert-manager den Challenge-Typ DNS-01 zum Abrufen eines TLS-Zertifikats. Hierfür muss das Cloudflare-API-Token bei der Erstellung der ClusterIssuer-Ressource angegeben werden. In der Lösung wird das API-Token als Kubernetes-Secret bereitgestellt.

1. Stellen Sie cert-manager mit Helm bereit:

$ helm install cert-manager jetstack/cert-manager --namespace cert-manager --create-namespace --version v1.9.1 --set installCRDs=trueNAME: cert-manager
LAST DEPLOYED: Day Mon DD hh:mm:ss YYYY
NAMESPACE: cert-manager
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
cert-manager v1.9.1 has been deployed successfully!

1. Stellen Sie das Cloudflare-API-Token als Kubernetes Secret bereit und ersetzen Sie dabei <your-API-token>:

$ kubectl apply -f - <<EOFapiVersion: v1 kind: Secret metadata: name: Cloudflare-api-token-secret namespace: cert-manager type: Opaque stringData: api-token: "<your-API-token>" EOF
secret/Cloudflare-api-token-secret created

1. Erstellen Sie ein ClusterIssuer-Objekt und geben Sie Cloudflare-api-token-secret (im vorherigen Schritt definiert) als Speicherort an, aus dem das Token abgerufen werden soll. Bei Bedarf können Sie example-issuer im Feld metadata.name (und example-issuer-account-key im Feld spec.acme.privateKeySecretRef.name) durch einen anderen Namen ersetzen.

$ kubectl apply -f - <<EOFapiVersion: cert-manager.io/v1 kind: ClusterIssuer metadata: name: example-issuer namespace: cert-manager spec: acme: email: example@example.com server: https://acme-v02.api.letsencrypt.org/directory privateKeySecretRef: name: example-issuer-account-key solvers: - dns01: Cloudflare: apiTokenSecretRef: name: Cloudflare-api-token-secret key: api-token EOF
clusterissuer.cert-manager.io/example-issuer created

1. Überprüfen Sie, ob der ClusterIssuer bereitgestellt und einsatzbereit ist (der Wert im Feld READY lautet True).

$ kubectl get clusterissuerNAME             READY   AGE
example-issuer   True    3h9m

ExternalDNS bereitstellen

Wie cert-manager benötigt auch das ExternalDNS-Projekt ein Cloudflare-API-Token zur Verwaltung von DNS. Dasselbe Token kann für beide Projekte verwendet werden, dies ist jedoch nicht erforderlich.

1. Erstellen Sie die ExternalDNS-CRDs für den NGINX Ingress Controller, um die Integration zwischen den Projekten zu ermöglichen.

$ kubectl create -f ./kubernetes-ingress/deployments/common/crds/externaldns.nginx.org_dnsendpoints.yamlcustomresourcedefinition.apiextensions.k8s.io/dnsendpoints.externaldns.nginx.org created

1. Erstellen Sie den External-DNS-Dienst (external-dns). Da das Manifest recht lang ist, teilen wir es hier in zwei Teile auf. Im ersten Teil werden Konten, Rollen und Berechtigungen konfiguriert:

$ kubectl apply -f - <<EOFapiVersion: v1 kind: ServiceAccount metadata: name: external-dns --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: external-dns rules: - apiGroups: [""] resources: ["services","endpoints","pods"] verbs: ["get","watch","list"] - apiGroups: ["extensions","networking.k8s.io"] resources: ["ingresses"] verbs: ["get","watch","list"] - apiGroups: ["externaldns.nginx.org"] resources: ["dnsendpoints"] verbs: ["get","watch","list"] - apiGroups: ["externaldns.nginx.org"] resources: ["dnsendpoints/status"] verbs: ["update"] - apiGroups: [""] resources: ["nodes"] verbs: ["list","watch"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: external-dns-viewer roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: external-dns subjects: - kind: ServiceAccount name: external-dns namespace: default EOF
serviceaccount/external-dns created
clusterrole.rbac.authorization.k8s.io/external-dns created
clusterrolebinding.rbac.authorization.k8s.io/external-dns-viewer created

1. Der zweite Teil des Manifests erstellt das ExternalDNS-Deployment:

$  kubectl apply -f - <<EOF --- apiVersion: apps/v1 kind: Deployment metadata: name: external-dns spec: strategy: type: Recreate selector: matchLabels: app: external-dns template: metadata: labels: app: external-dns spec: serviceAccountName: external-dns containers: - name: external-dns image: k8s.gcr.io/external-dns/external-dns:v0.12.0 args: - --source=service - --source=ingress - --source=crd - --crd-source-apiversion=externaldns.nginx.org/v1 - --crd-source-kind=DNSEndpoint - --domain-filter=example.com - --provider=Cloudflare env: - name: CF_API_TOKEN value: "<your-API-token>" - name: FREE_TIER value: "true" EOF
serviceaccount/external-dns created
clusterrole.rbac.authorization.k8s.io/external-dns created
clusterrolebinding.rbac.authorization.k8s.io/external-dns-viewer created
deployment.apps/external-dns created

• Erstellt ein ServiceAccount-Objekt namens „external-dns“, das alle Schreib- und Aktualisierungsvorgänge zur DNS-Verwaltung übernimmt.
• Erstellt ein ClusterRole-Objekt (ebenfalls mit dem Namen „external-dns“), das die erforderlichen Berechtigungen definiert.
• Bindet die ClusterRole an das ServiceAccount.
• Erstellt einen Domainfilter, der das Ausmaß möglicher Schäden begrenzt, die ExternalDNS bei der Verwaltung von Domains verursachen kann. Sie können beispielsweise die Domainnamen von Staging-Umgebungen angeben, um Änderungen an Produktionsumgebungen zu verhindern. In diesem Beispiel setzen wir domain-filter auf example.com.
• Legt die Umgebungsvariable CF_API_TOKEN auf Ihr Cloudflare-API-Token fest. Ersetzen Sie <your-API-token> entweder durch das tatsächliche Token oder durch ein Secret, das das Token enthält. Im letzteren Fall müssen Sie außerdem das Secret mithilfe einer Umgebungsvariable in den Container projizieren.
• Setzt die Umgebungsvariable FREE_TIER auf "true" (sofern Sie kein kostenpflichtiges Cloudflare-Abonnement haben).

Beispielanwendung bereitstellen

Verwenden Sie zu Testzwecken die Standard-Beispielanwendung des NGINX Ingress Controllers namens „Cafe“.

1. Stellen Sie die Cafe-Anwendung bereit.

$ kubectl apply -f ./kubernetes-ingress/examples/ingress-resources/complete-example/cafe.yamldeployment.apps/coffee created
service/coffee-svc created
deployment.apps/tea created
service/tea-svc created

1. Stellen Sie den NGINX Ingress Controller für die Cafe-Anwendung bereit. Beachten Sie dabei die folgenden Einstellungen: Die Dauer dieses Schritts hängt stark vom DNS-Anbieter ab, da Kubernetes mit dessen DNS-API interagiert.

$ kubectl apply -f - <<EOFapiVersion: k8s.nginx.org/v1 kind: VirtualServer metadata: name: cafe spec: host: cafe.example.com tls: secret: cafe-secret cert-manager: cluster-issuer: example-issuer externalDNS: enable: true upstreams: - name: tea service: tea-svc port: 80 - name: coffee service: coffee-svc port: 80 routes: - path: /tea action: pass: tea - path: /coffee action: pass: coffee EOF
virtualserver.k8s.nginx.org/cafe created

• kind: VirtualServer – Wir verwenden die benutzerdefinierte NGINX-VirtualServer-Ressource und nicht die standardmäßige Kubernetes-Ingress-Ressource.
• spec.host – Ersetzen Sie cafe.example.com durch den Namen des Hosts, den Sie bereitstellen. Der Host muss sich innerhalb der von ExternalDNS verwalteten Domain befinden.
• spec.tls.cert-manager.cluster-issuer – Wenn Sie die in diesem Beitrag angegebenen Werte verwendet haben, lautet dieser Wert example-issuer. Ersetzen Sie ihn bei Bedarf durch den Namen, den Sie in Schritt 3 unter cert‑manager bereitstellen ausgewählt haben.
• spec.externalDNS.enable – Der Wert true weist ExternalDNS an, einen DNS-A-Eintrag zu erstellen.

Lösung validieren

1. Überprüfen Sie den DNS-A-Eintrag – insbesondere, ob im ANSWER-SECTION-Block der FQDN (hier cafe.example.com) der richtigen IP-Adresse (www.xxx.yyy.zzz) zugeordnet ist.

$ dig cafe.example.com 
; <<>> DiG 9.10.6 <<>> cafe.example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22633
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
 
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;cafe.example.com.		IN	A
 
;; ANSWER SECTION:
cafe.example.com.	279	IN	A	www.xxx.yyy.zzz
 
;; Query time: 1 msec
;; SERVER: 2607:fb91:119b:4ac4:2e0:xxxx:fe1e:1359#53(2607:fb91:119b:4ac4:2e0:xxxx:fe1e:1359)
;; WHEN: Day Mon DD hh:mm:ss TZ YYYY
;; MSG SIZE  rcvd: 67

1. Überprüfen Sie, ob das Zertifikat gültig ist (der Wert im Feld „READY“ lautet „True“).

$ kubectl get certificatesNAME          READY   SECRET        AGE
cafe-secret   True    cafe-secret   8m51s

1. Überprüfen Sie, ob Sie die Anwendung erreichen können.

$ curl https://cafe.example.com/coffeeServer address: 10.2.2.4:8080
Server name: coffee-7c86d7d67c-lsfs6
Date: DD/Mon/YYYY:hh:mm:ss +TZ-offset
URI: /coffee
Request ID: 91077575f19e6e735a91b9d06e9684cd
$ curl https://cafe.example.com/tea
Server address: 10.2.2.5:8080
Server name: tea-5c457db9-ztpns
Date: DD/Mon/YYYY:hh:mm:ss +TZ-offset
URI: /tea
Request ID: 2164c245a495d22c11e900aa0103b00f

Was passiert, wenn ein Entwickler den NGINX Ingress Controller bereitstellt?

Sobald die Lösung implementiert ist, laufen im Hintergrund zahlreiche Prozesse ab. Das Diagramm zeigt, was geschieht, wenn ein Entwickler den NGINX Ingress Controller mit einer benutzerdefinierten NGINX-VirtualServer-Ressource bereitstellt. Beachten Sie, dass einige betriebliche Details nicht dargestellt sind.

1. Der Entwickler stellt mithilfe der NGINX-CRD eine VirtualServer-Ressource bereit
2. Kubernetes erstellt den VirtualServer mithilfe des NGINX Ingress Controllers
3. NGINX Ingress Controller ruft ExternalDNS auf, um einen DNS-A-Eintrag zu erstellen
4. ExternalDNS erstellt den A-Eintrag im DNS
5. Der NGINX Ingress Controller ruft cert-manager auf, um ein TLS-Zertifikat anzufordern
6. cert-manager fügt einen DNS-Eintrag hinzu, der während der DNS-01-Challenge verwendet wird
7. cert-manager kontaktiert Let’s Encrypt, um die Challenge abzuschließen
8. Let’s Encrypt validiert die Challenge anhand des DNS-Eintrags
9. Let’s Encrypt stellt das TLS-Zertifikat aus
10. cert-manager stellt dem NGINX Ingress Controller das TLS-Zertifikat bereit
11. Der NGINX Ingress Controller leitet TLS-gesicherte externe Anfragen an die Anwendungs-Pods weiter

Fehlerbehebung

Angesichts der Komplexität von Kubernetes und der von uns verwendeten Komponenten ist es schwierig, einen umfassenden Leitfaden zur Fehlerbehebung bereitzustellen. Dennoch gibt es einige grundlegende Empfehlungen, die Ihnen dabei helfen können, die Ursache des Problems zu ermitteln.

• Verwenden Sie die Befehle „kubectl get“ und „kubectl describe“, um die Konfiguration der bereitgestellten Objekte zu überprüfen.
• Verwenden Sie den Befehl „kubectl logs <component>“, um die Protokolldateien der verschiedenen bereitgestellten Komponenten anzuzeigen.
• Verwenden Sie K9s zur Überprüfung der Installation. Die Software hebt Probleme je nach Schweregrad gelb oder rot hervor und bietet eine Oberfläche für den Zugriff auf Protokolle und Details zu Objekten.

Wenn Sie weiterhin Probleme haben, besuchen Sie uns bitte im NGINXCommunity Slack und bitten Sie um Hilfe! Wir haben eine lebendige Community und helfen Ihnen jederzeit gerne bei der Lösung von Problemen.

Wenn Sie den auf NGINX Plus basierenden NGINX Ingress Controller ausprobieren möchten, starten Sie noch heute Ihre kostenlose 30-Tage-Testversion oder kontaktieren Sie uns, um Ihre Anwendungsfälle zu besprechen.

Über den Autor

Jason Schmidt

Weitere Blogbeiträge von Jason Schmidt