TOC

Einrichten eines Nginx Ingress mit Cert-Manager auf DigitalOcean Kubernetes

Einführung

Mit Kubernetes Ingresses können Sie Datenverkehr von außerhalb Ihres Kubernetes-Clusters flexibel zu Diensten innerhalb Ihres Clusters weiterleiten. Dies erfolgt mithilfe von Ingress-Ressourcen, die Regeln für das Routing von HTTP- und HTTPS-Datenverkehr an Kubernetes Services definieren, und Ingress-Controllern, die die Regeln implementieren, indem sie den Datenverkehr ausgleichen und an die entsprechenden Back-End-Services weiterleiten. Zu den gängigen Ingress-Controllern gehören Nginx, Contour und https: // www. haproxy.com/blog/haproxy_ingress_controller_for_kubernetes/[HAProxy] und Traefik. Ingresses bietet eine effizientere und flexiblere Alternative zum Einrichten mehrerer LoadBalancer-Dienste, von denen jeder seinen eigenen dedizierten Load Balancer verwendet.

In diesem Handbuch richten wir den von Kubernetes gepflegten Nginx Ingress Controller ein und erstellen einige Ingress-Ressourcen, um den Datenverkehr an mehrere Dummy-Backend-Dienste weiterzuleiten. Sobald wir Ingress eingerichtet haben, installieren wir cert-manager in unserem Cluster, um TLS-Zertifikate zum Verschlüsseln des HTTP-Datenverkehrs für Ingress zu verwalten und bereitzustellen.

Voraussetzungen

Bevor Sie mit diesem Handbuch beginnen, sollten Sie Folgendes zur Verfügung haben:

  • Ein Kubernetes 1.10+ -Cluster mit aktiviertem role- based access control (RBAC)

  • Das Befehlszeilentool "+ kubectl ", das auf Ihrem lokalen Computer installiert und für die Verbindung mit Ihrem Cluster konfiguriert ist. Weitere Informationen zur Installation von ` kubectl +` in der offiziellen Dokumentation.

  • Ein Domain-Name und DNS-A-Einträge, die Sie auf den von Ingress verwendeten DigitalOcean Load Balancer verweisen können. Wenn Sie DigitalOcean zum Verwalten der DNS-Einträge Ihrer Domain verwenden, lesen Sie Wie verwalte ich DNS-Einträge?, Um zu erfahren, wie Sie A erstellen Aufzeichnungen.

  • Der auf Ihrem lokalen Computer installierte Helm-Paket-Manager und Tiller auf Ihrem Cluster, wie unter https://www.digitalocean.com/community/tutorials/how-to-install-software-on-kubernetes-clusters-with-the beschrieben -helm-package-manager [Installieren von Software auf Kubernetes-Clustern mit dem Helm Package Manager]. Stellen Sie sicher, dass Sie Helm v2.12.1 oder höher verwenden, da sonst Probleme bei der Installation der Helmkarte von cert-manager auftreten können. Um zu überprüfen, welche Helm-Version Sie installiert haben, führen Sie auf Ihrem lokalen Computer "+ Helm-Version +" aus.

  • Das auf Ihrem lokalen Computer installierte Befehlszeilenprogramm "+ wget ". Sie können ` wget +` mit dem in Ihrem Betriebssystem integrierten Paketmanager installieren.

Sobald Sie diese Komponenten eingerichtet haben, können Sie mit diesem Handbuch beginnen.

Schritt 1 - Einrichten von Dummy-Backend-Diensten

Bevor wir den Ingress Controller bereitstellen, erstellen und implementieren wir zunächst zwei Dummy-Echo-Services, an die wir den externen Datenverkehr mithilfe des Ingress weiterleiten. Die Echodienste führen den Webserver-Container https://hub.docker.com/r/hashicorp/http-echo/ [+ hashicorp / http-echo +] aus, der eine Seite mit einer Textzeichenfolge zurückgibt, die bei der Übergabe des Befehls übergeben wurde Webserver wird gestartet. Weitere Informationen zu "+ http-echo +" finden Sie unter GitHub Repo. Weitere Informationen zu Kubernetes Services finden Sie unter https://kubernetes.io/docs/. concepts / services-networking / service / [Services] aus den offiziellen Kubernetes-Dokumenten.

Erstellen und bearbeiten Sie auf Ihrem lokalen Computer eine Datei mit dem Namen "+ echo1.yaml " mit " nano +" oder Ihrem bevorzugten Editor:

nano echo1.yaml

Fügen Sie das folgende Dienst- und Bereitstellungsmanifest ein:

echo1.yaml

apiVersion: v1
kind: Service
metadata:
 name: echo1
spec:
 ports:
 - port: 80
   targetPort: 5678
 selector:
   app: echo1
---
apiVersion: apps/v1
kind: Deployment
metadata:
 name: echo1
spec:
 selector:
   matchLabels:
     app: echo1
 replicas: 2
 template:
   metadata:
     labels:
       app: echo1
   spec:
     containers:
     - name: echo1
       image: hashicorp/http-echo
       args:
       - "-text=echo1"
       ports:
       - containerPort: 5678

In dieser Datei definieren wir einen Service mit dem Namen "+ echo1 ", der den Datenverkehr mit der Beschriftungsauswahl " app: echo1 " zu Pods weiterleitet. Es akzeptiert TCP-Verkehr an Port " 80 " und leitet ihn an den Standardport von Port " 5678 ", " http-echo +" weiter.

Anschließend definieren wir ein Deployment, auch "+ echo1 " genannt, das Pods mit der App "" verwaltet: echo1 + "https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/[Label Selector] . Wir geben an, dass die Bereitstellung 2 Pod-Replikate enthalten soll und dass die Pods einen Container mit dem Namen "+ echo1 " starten sollen, in dem das Image " hashicorp / http-echo " ausgeführt wird. Wir übergeben den Parameter " text " und setzen ihn auf " echo1 ", damit der Webserver " http-echo " "" + echo1 + "zurückgibt. Schließlich öffnen wir den Port " 5678 +" auf dem Pod-Container.

Speichern und schließen Sie die Datei, sobald Sie mit Ihrem Dummy-Service- und Bereitstellungsmanifest zufrieden sind.

Erstellen Sie dann die Kubernetes-Ressourcen mit + kubectl create + mit dem Flag + -f + und geben Sie die Datei an, die Sie gerade als Parameter gespeichert haben:

kubectl create -f echo1.yaml

Sie sollten die folgende Ausgabe sehen:

Outputservice/echo1 created
deployment.apps/echo1 created

Stellen Sie sicher, dass der Dienst ordnungsgemäß gestartet wurde, indem Sie sicherstellen, dass er über eine Cluster-IP verfügt, die interne IP, auf der der Dienst verfügbar gemacht wird:

kubectl get svc echo1

Sie sollten die folgende Ausgabe sehen:

OutputNAME      TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE
echo1     ClusterIP   10.245.222.129   <none>        80/TCP    60s

Dies zeigt an, dass der "+ echo1 " - Dienst jetzt intern unter " 10.245.222.129 " an Port " 80 " verfügbar ist. Es leitet den Verkehr zu containerPort ` 5678 +` auf den ausgewählten Pods weiter.

Nachdem der Dienst "+ echo1 " ausgeführt wird, wiederholen Sie diesen Vorgang für den Dienst " echo2 +".

Erstellen und öffnen Sie eine Datei mit dem Namen "+ echo2.yaml +":

echo2.yaml

apiVersion: v1
kind: Service
metadata:
 name: echo2
spec:
 ports:
 - port: 80
   targetPort: 5678
 selector:
   app: echo2
---
apiVersion: apps/v1
kind: Deployment
metadata:
 name: echo2
spec:
 selector:
   matchLabels:
     app: echo2
 replicas: 1
 template:
   metadata:
     labels:
       app: echo2
   spec:
     containers:
     - name: echo2
       image: hashicorp/http-echo
       args:
       - "-text=echo2"
       ports:
       - containerPort: 5678

Hier verwenden wir im Wesentlichen das gleiche Service- und Deployment-Manifest wie oben, benennen den Service und das Deployment jedoch "+ echo2 " und kennzeichnen ihn neu. Um eine gewisse Abwechslung zu gewährleisten, erstellen wir nur eine Pod-Replik. Wir stellen sicher, dass wir den Parameter " text " auf " echo2 " setzen, damit der Webserver den Text " echo2 +" zurückgibt.

Speichern und schließen Sie die Datei und erstellen Sie die Kubernetes-Ressourcen mit + kubectl +:

kubectl create -f echo2.yaml

Sie sollten die folgende Ausgabe sehen:

Outputservice/echo2 created
deployment.apps/echo2 created

Stellen Sie erneut sicher, dass der Dienst ausgeführt wird:

kubectl get svc

Sie sollten die beiden Dienste "+ echo1 " und " echo2 +" mit zugewiesenen ClusterIPs sehen:

OutputNAME         TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE
echo1        ClusterIP   10.245.222.129   <none>        80/TCP    6m6s
echo2        ClusterIP   10.245.128.224   <none>        80/TCP    6m3s
kubernetes   ClusterIP   10.245.0.1       <none>        443/TCP   4d21h

Nachdem unsere Dummy-Echo-Webservices nun verfügbar sind, können wir den Nginx Ingress Controller einführen.

Schritt 2 - Einrichten des Kubernetes Nginx Ingress Controllers

In diesem Schritt rollen wir "++" des von Kubernetes gepflegten Nginx Ingress Controllers aus. Beachten Sie, dass es https://github.com/nginxinc/kubernetes-ingress/blob/master/docs/nginx-ingress-controllers.md[several Nginx Ingress Controllers gibt. Die Kubernetes-Community unterhält die in diesem Handbuch verwendete und Nginx Inc. verwaltet kubernetes-ingress. Die Anweisungen in diesem Lernprogramm basieren auf denen des offiziellen Kubernetes Nginx Ingress Controller (https://kubernetes.github.io/ingress-nginx/deploy/[Installation Guide).

Der Nginx Ingress Controller besteht aus einem Pod, der den Nginx-Webserver ausführt und die Kubernetes-Steuerebene auf neue und aktualisierte Ingress Resource-Objekte überwacht. Eine Ingress-Ressource ist im Wesentlichen eine Liste von Verkehrslenkungsregeln für Back-End-Dienste. Beispielsweise kann eine Ingress-Regel festlegen, dass HTTP-Datenverkehr, der auf dem Pfad "+ / web1 " ankommt, zum " web1 " - Backend-Webserver geleitet werden soll. Mithilfe von Ingress Resources können Sie auch hostbasiertes Routing durchführen: Zum Beispiel Routing von Anforderungen, die auf " web1.Ihre_Domäne.com " lauten, an den Back-End-Kubernetes-Dienst " web1 +".

In diesem Fall erstellt der Controller, da wir den Ingress Controller in einem DigitalOcean Kubernetes-Cluster bereitstellen, einen LoadBalancer-Dienst, der einen DigitalOcean Load Balancer startet, an den der gesamte externe Datenverkehr geleitet wird. Dieser Load Balancer leitet externen Datenverkehr an den Ingress Controller Pod mit Nginx weiter, der den Datenverkehr dann an die entsprechenden Backend-Dienste weiterleitet.

Zunächst erstellen wir die Kubernetes-Ressourcen, die vom Nginx Ingress Controller benötigt werden. Diese bestehen aus ConfigMaps mit der Konfiguration des Controllers, Rollen für die rollenbasierte Zugriffssteuerung (RBAC), um dem Controller Zugriff auf die Kubernetes-API zu gewähren, und der tatsächlichen Ingress Controller-Bereitstellung, die https://quay.io/repository/kubernetes-ingress- verwendet. controller / nginx-ingress-controller? tag = 0.24.1 & tab = tags [v0.24.1] des Nginx Ingress Controller-Image. Eine vollständige Liste dieser erforderlichen Ressourcen finden Sie im GitHub-Repository des Kubernetes Nginx Ingress Controllers unter manifest .

Um diese obligatorischen Ressourcen zu erstellen, verwenden Sie "+ kubectl apply " und das Flag " -f +", um die auf GitHub gehostete Manifestdatei anzugeben:

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx//deploy/mandatory.yaml

Wir verwenden hier "+ apply " anstelle von " create ", damit wir in Zukunft schrittweise Änderungen an den Ingress Controller-Objekten anwenden können, anstatt sie vollständig zu überschreiben. Weitere Informationen zu " apply +" finden Sie in den offiziellen Kubernetes-Dokumenten unter Managing Resources.

Sie sollten die folgende Ausgabe sehen:

Outputnamespace/ingress-nginx created
configmap/nginx-configuration created
configmap/tcp-services created
configmap/udp-services created
serviceaccount/nginx-ingress-serviceaccount created
clusterrole.rbac.authorization.k8s.io/nginx-ingress-clusterrole created
role.rbac.authorization.k8s.io/nginx-ingress-role created
rolebinding.rbac.authorization.k8s.io/nginx-ingress-role-nisa-binding created
clusterrolebinding.rbac.authorization.k8s.io/nginx-ingress-clusterrole-nisa-binding created
deployment.extensions/nginx-ingress-controller created

Diese Ausgabe dient auch als praktische Zusammenfassung aller Ingress Controller-Objekte, die aus dem Manifest "+ obligatorisch.yaml +" erstellt wurden.

Als Nächstes erstellen wir den Ingress Controller LoadBalancer-Dienst, der einen DigitalOcean Load Balancer erstellt, der den Lastausgleich und die Weiterleitung des HTTP- und HTTPS-Verkehrs an den im vorherigen Befehl bereitgestellten Ingress Controller Pod ausführt.

Um den LoadBalancer-Dienst zu erstellen, wenden Sie erneut "+ kubectl" eine Manifestdatei an, die die Dienstdefinition enthält:

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx//deploy/provider/cloud-generic.yaml

Sie sollten die folgende Ausgabe sehen:

Outputservice/ingress-nginx created

Stellen Sie nun sicher, dass der DigitalOcean Load Balancer erfolgreich erstellt wurde, indem Sie die Servicedetails mit + kubectl + abrufen:

kubectl get svc --namespace=ingress-nginx

Sie sollten eine externe IP-Adresse sehen, die der IP-Adresse des DigitalOcean Load Balancer entspricht:

OutputNAME            TYPE           CLUSTER-IP      EXTERNAL-IP       PORT(S)                      AGE
ingress-nginx   LoadBalancer         80:32486/TCP,443:32096/TCP   20h

Notieren Sie sich die externe IP-Adresse des Load Balancers, da Sie diese in einem späteren Schritt benötigen.

Dieser Load Balancer empfängt Datenverkehr über die HTTP- und HTTPS-Ports 80 und 443 und leitet ihn an den Ingress Controller Pod weiter. Der Ingress Controller leitet den Datenverkehr dann an den entsprechenden Back-End-Service weiter.

Wir können jetzt unsere DNS-Einträge auf diesen externen Load Balancer verweisen und einige Ingress-Ressourcen erstellen, um Verkehrsroutingregeln zu implementieren.

Schritt 3 - Erstellen der Ingress-Ressource

Beginnen wir mit der Erstellung einer minimalen Ingress-Ressource, um Datenverkehr, der an eine bestimmte Unterdomäne gerichtet ist, an einen entsprechenden Back-End-Service weiterzuleiten.

In diesem Handbuch wird die Testdomain * example.com * verwendet. Sie sollten dies durch den Domainnamen ersetzen, den Sie besitzen.

Wir erstellen zunächst eine einfache Regel, um an * echo1. * Gerichteten Datenverkehr an den Backend-Service "+ echo1 " und an * echo2. * Gerichteten Datenverkehr an den Backend-Service " echo2 +" weiterzuleiten.

Beginnen Sie mit dem Öffnen einer Datei mit dem Namen "+ echo_ingress.yaml +" in Ihrem bevorzugten Editor:

nano echo_ingress.yaml

Fügen Sie die folgende Ingress-Definition ein:

echo_ingress.yaml

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
 name: echo-ingress
spec:
 rules:
 - host: echo1.
   http:
     paths:
     - backend:
         serviceName: echo1
         servicePort: 80
 - host: echo2.
   http:
     paths:
     - backend:
         serviceName: echo2
         servicePort: 80

Speichern und schließen Sie die Datei, wenn Sie mit der Bearbeitung Ihrer Ingress-Regeln fertig sind.

Hier haben wir festgelegt, dass wir eine Ingress-Ressource mit dem Namen "+ Echo-Ingress " erstellen und den Datenverkehr basierend auf dem Host-Header weiterleiten möchten. Ein HTTP-Anforderungshost-Header gibt den Domänennamen des Zielservers an. Weitere Informationen zu Host-Anforderungs-Headern finden Sie im Mozilla Developer Network unter https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Host[definition page]. Anfragen mit Host * echo1. * Werden an das in Schritt 1 eingerichtete " echo1 " - Backend weitergeleitet, und Anfragen mit Host * echo2. * Werden an das " echo2 +" - Backend weitergeleitet.

Sie können den Ingress jetzt mit + kubectl + erstellen:

kubectl apply -f echo_ingress.yaml

Die folgende Ausgabe bestätigt die Ingress-Erstellung:

Outputingress.extensions/echo-ingress created

Navigieren Sie zum Testen des Ingress zu Ihrem DNS-Verwaltungsdienst und erstellen Sie A-Einträge für "+ echo1.example.com " und " echo2.example.com ", die auf die externe IP des DigitalOcean Load Balancer verweisen. Die externe IP des Load Balancers ist die externe IP-Adresse für den Dienst " ingress-nginx +", den wir im vorherigen Schritt abgerufen haben. Wenn Sie DigitalOcean zum Verwalten der DNS-Einträge Ihrer Domain verwenden, lesen Sie Wie verwalte ich DNS-Einträge?, Um zu erfahren, wie Sie A erstellen Aufzeichnungen.

Nachdem Sie die erforderlichen DNS-Einträge "+ echo1.example.com " und " echo2.example.com " erstellt haben, können Sie den von Ihnen erstellten Ingress Controller und die Ressource mit dem Befehlszeilendienstprogramm " curl +" testen.

Von Ihrem lokalen Computer aus können Sie den Service "+ curl ` the ` echo1 +` "ausführen:

curl echo1.example.com

Sie sollten die folgende Antwort vom "+ echo1 +" - Dienst erhalten:

Outputecho1

Dies bestätigt, dass Ihre Anfrage an "+ echo1.example.com " korrekt über den Nginx-Eingang an den " echo1 +" - Backend-Service weitergeleitet wird.

Führen Sie nun den gleichen Test für den Dienst "+ echo2 +" durch:

curl echo2.example.com

Sie sollten die folgende Antwort vom "+ echo2 +" - Dienst erhalten:

Outputecho2

Dies bestätigt, dass Ihre Anfrage an "+ echo 2.example.com " korrekt über den Nginx-Eingang an den " echo 2" -Backend-Service weitergeleitet wird.

Zu diesem Zeitpunkt haben Sie erfolgreich ein grundlegendes Nginx-Ingress für die Ausführung von Routing auf Basis virtueller Hosts eingerichtet. Im nächsten Schritt installieren wir cert-manager mithilfe von Helm, um TLS-Zertifikate für unseren Ingress bereitzustellen und das sicherere HTTPS-Protokoll zu aktivieren.

Schritt 4 - Installation und Konfiguration von Cert-Manager

In diesem Schritt verwenden wir Helm, um cert-manager in unserem Cluster zu installieren. cert-manager ist ein Kubernetes-Dienst, der TLS-Zertifikate von Let’s Encrypt und anderen Zertifizierungsstellen bereitstellt und deren Lebenszyklen verwaltet. Zertifikate können angefordert und konfiguriert werden, indem Sie Ingress-Ressourcen mit der Anmerkung "+ certmanager.k8s.io / issuer " versehen, der Ingress-Spezifikation einen Abschnitt " tls +" hinzufügen und einen oder mehrere Issuers konfigurieren, um Ihre bevorzugte Zertifizierungsstelle anzugeben. Weitere Informationen zu Ausstellerobjekten finden Sie in der offiziellen Cert-Manager-Dokumentation unter Issuers.

Bevor Sie mit Helm Cert-Manager in unserem Cluster installieren können, müssen Sie den Cert-Manager Custom Resource Definitions erstellen. ( CRDs). Erstellen Sie diese, indem Sie sie direkt vom Cert-Manager aus anwenden: GitHub repository:

kubectl apply \
   -f https://raw.githubusercontent.com/jetstack/cert-manager/release-0.8/deploy/manifests/00-crds.yaml

Sie sollten die folgende Ausgabe sehen:

Outputcustomresourcedefinition.apiextensions.k8s.io/certificates.certmanager.k8s.io created
customresourcedefinition.apiextensions.k8s.io/issuers.certmanager.k8s.io created
customresourcedefinition.apiextensions.k8s.io/clusterissuers.certmanager.k8s.io created
customresourcedefinition.apiextensions.k8s.io/orders.certmanager.k8s.io created
customresourcedefinition.apiextensions.k8s.io/challenges.certmanager.k8s.io created

Als Nächstes fügen wir dem Namespace "+ kube-system +" eine Bezeichnung hinzu, in der cert-manager installiert wird, um die erweiterte Ressourcenvalidierung mithilfe von https://docs.cert-manager.io/en/venafi/ zu ermöglichen. admin / resource-validation-webhook.html [webhook]:

kubectl label namespace kube-system certmanager.k8s.io/disable-validation="true"

Nun fügen wir das Jetstack Helm Repository zu Helm hinzu. Dieses Repository enthält das Zertifikat-Manager-Diagramm Helm chart.

helm repo add jetstack https://charts.jetstack.io

Schließlich können wir das Diagramm in den Namespace "+ kube-system" installieren:

helm install --name cert-manager --namespace kube-system jetstack/cert-manager --version v0.8.0

Sie sollten die folgende Ausgabe sehen:

Output. . .
NOTES:
cert-manager has been deployed successfully!

In order to begin issuing certificates, you will need to set up a ClusterIssuer
or Issuer resource (for example, by creating a 'letsencrypt-staging' issuer).

More information on the different types of issuers and how to configure them
can be found in our documentation:

https://cert-manager.readthedocs.io/en/latest/reference/issuers.html

For information on how to configure cert-manager to automatically provision
Certificates for Ingress resources, take a look at the `ingress-shim`
documentation:

https://cert-manager.readthedocs.io/en/latest/reference/ingress-shim.html

Dies zeigt an, dass die Installation von cert-manager erfolgreich war.

Bevor wir anfangen, Zertifikate für unsere Ingress-Hosts auszustellen, müssen wir einen Aussteller erstellen, der die Zertifizierungsstelle angibt, von der signierte x509-Zertifikate bezogen werden können. In diesem Handbuch wird die Let’s Encrypt-Zertifizierungsstelle verwendet, die kostenlose TLS-Zertifikate bereitstellt und sowohl einen Staging-Server zum Testen Ihrer Zertifikatkonfiguration als auch einen Produktionsserver zum Bereitstellen überprüfbarer TLS-Zertifikate bietet.

Erstellen wir einen Testaussteller, um sicherzustellen, dass der Mechanismus zur Zertifikatbereitstellung ordnungsgemäß funktioniert. Öffnen Sie eine Datei mit dem Namen "+ staging_issuer.yaml +" in Ihrem bevorzugten Texteditor:

nano staging_issuer.yaml

Fügen Sie das folgende ClusterIssuer-Manifest ein:

staging_issuer.yaml

apiVersion: certmanager.k8s.io/v1alpha1
kind: ClusterIssuer
metadata:
name: letsencrypt-staging
spec:
acme:
  # The ACME server URL
  server: https://acme-staging-v02.api.letsencrypt.org/directory
  # Email address used for ACME registration
  email:
  # Name of a secret used to store the ACME account private key
  privateKeySecretRef:
    name: letsencrypt-staging
  # Enable the HTTP-01 challenge provider
  http01: {}

Hier geben wir an, dass wir ein ClusterIssuer-Objekt mit dem Namen "+ letsencrypt-staging +" erstellen und den Let’s Encrypt-Staging-Server verwenden möchten. Wir werden später den Produktionsserver verwenden, um unsere Zertifikate bereitzustellen. Der Produktionsserver kann jedoch die Anzahl der Anfragen begrenzen, die zu Testzwecken gestellt werden. Verwenden Sie daher am besten die Staging-URL.

Anschließend geben wir eine E-Mail-Adresse zum Registrieren des Zertifikats an und erstellen einen Kubernetes-https://kubernetes.io/docs/concepts/configuration/secret/[Secret] mit dem Namen "+ letsencrypt-staging ", um den privaten Schlüssel des ACME-Kontos zu speichern. Wir aktivieren auch den Challenge-Mechanismus " HTTP-01 +". Weitere Informationen zu diesen Parametern finden Sie in der offiziellen Cert-Manager-Dokumentation unter Issuers.

Stellen Sie den ClusterIssuer mit + kubectl + bereit:

kubectl create -f staging_issuer.yaml

Sie sollten die folgende Ausgabe sehen:

Outputclusterissuer.certmanager.k8s.io/letsencrypt-staging created

Nachdem wir unseren Let’s Encrypt-Staging-Issuer erstellt haben, können wir die oben erstellte Ingress-Ressource ändern und die TLS-Verschlüsselung für die Pfade "+ echo1.example.com " und " echo2.example.com +" aktivieren.

Öffne + echo_ingress.yaml + noch einmal in deinem Lieblingseditor:

nano echo_ingress.yaml

Fügen Sie dem Ingress Resource-Manifest Folgendes hinzu:

echo_ingress.yaml

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
 name: echo-ingress



spec:





 rules:
 - host: echo1.example.com
   http:
     paths:
     - backend:
         serviceName: echo1
         servicePort: 80
 - host: echo2.example.com
   http:
     paths:
     - backend:
         serviceName: echo2
         servicePort: 80

Hier fügen wir einige Anmerkungen hinzu, um das "+ ingress.class +" anzugeben, das den Ingress-Controller bestimmt, der zur Implementierung der Ingress-Regeln verwendet werden soll. Außerdem definieren wir den Cluster-Aussteller als letsencrypt-staging, den soeben erstellten Zertifikatsaussteller.

Schließlich fügen wir einen "+ tls " - Block hinzu, um die Hosts anzugeben, für die wir Zertifikate erwerben möchten, und geben einen " secretName +" an. Dieses Geheimnis enthält den privaten TLS-Schlüssel und das ausgestellte Zertifikat.

Speichern und schließen Sie die Datei, wenn Sie mit den Änderungen fertig sind.

Wir aktualisieren jetzt die vorhandene Ingress-Ressource mit "+ kubectl apply +":

kubectl apply -f echo_ingress.yaml

Sie sollten die folgende Ausgabe sehen:

Outputingress.extensions/echo-ingress configured

Sie können "+ kubectl describe +" verwenden, um den Status der soeben angewendeten Ingress-Änderungen zu verfolgen:

kubectl describe ingress
OutputEvents:
 Type    Reason             Age               From                      Message
 ----    ------             ----              ----                      -------
 Normal  CREATE             14m               nginx-ingress-controller  Ingress default/echo-ingress
 Normal  UPDATE             1m (x2 over 13m)  nginx-ingress-controller  Ingress default/echo-ingress
 Normal  CreateCertificate  1m                cert-manager              Successfully created Certificate "letsencrypt-staging"

Sobald das Zertifikat erfolgreich erstellt wurde, können Sie ein zusätzliches "+ describe +" ausführen, um die erfolgreiche Erstellung weiter zu bestätigen:

kubectl describe certificate

Sie sollten die folgende Ausgabe im Abschnitt "+ Events +" sehen:

OutputEvents:
 Type    Reason         Age   From          Message
 ----    ------         ----  ----          -------
 Normal  Generated      63s   cert-manager  Generated new private key
 Normal  OrderCreated   63s   cert-manager  Created Order resource "letsencrypt-staging-147606226"
 Normal  OrderComplete  19s   cert-manager  Order "letsencrypt-staging-147606226" completed successfully
 Normal  CertIssued     18s   cert-manager  Certificate issued successfully

Dies bestätigt, dass das TLS-Zertifikat erfolgreich ausgestellt wurde und die HTTPS-Verschlüsselung nun für die beiden konfigurierten Domänen aktiv ist.

Wir sind jetzt bereit, eine Anfrage an einen "+ echo +" - Server zu senden, um zu testen, ob HTTPS ordnungsgemäß funktioniert.

Führen Sie den folgenden Befehl "+ wget" aus, um eine Anforderung an "+ echo1.example.com " zu senden und die Antwortheader an " STDOUT" zu drucken:

wget --save-headers -O- echo1.example.com

Sie sollten die folgende Ausgabe sehen:

OutputURL transformed to HTTPS due to an HSTS policy
--2018-12-11 14:38:24--  https://echo1.example.com/
Resolving echo1.example.com (echo1.example.com)... 203.0.113.0
Connecting to echo1.example.com (echo1.example.net)|203.0.113.0|:443... connected.
ERROR: cannot verify echo1.example.com's certificate, issued by ‘CN=Fake LE Intermediate X1’:
 Unable to locally verify the issuer's authority.
To connect to echo1.example.com insecurely, use `--no-check-certificate'.

Dies zeigt an, dass HTTPS erfolgreich aktiviert wurde, das Zertifikat jedoch nicht überprüft werden kann, da es sich um ein gefälschtes temporäres Zertifikat handelt, das vom Let’s Encrypt-Staging-Server ausgestellt wurde.

Nachdem wir nun getestet haben, dass mit diesem temporären gefälschten Zertifikat alles funktioniert, können wir Produktionszertifikate für die beiden Hosts "+ echo1.example.com " und " echo2.example.com +" bereitstellen.

Schritt 5 - Einführung des Produktionsausstellers

In diesem Schritt ändern wir das Verfahren zum Bereitstellen von Staging-Zertifikaten und generieren ein gültiges, überprüfbares Produktionszertifikat für unsere Ingress-Hosts.

Zunächst erstellen wir ein Produktionszertifikat ClusterIssuer.

Öffnen Sie eine Datei mit dem Namen "+ prod_issuer.yaml +" in Ihrem bevorzugten Editor:

nano prod_issuer.yaml

Fügen Sie das folgende Manifest ein:

prod_issuer.yaml

apiVersion: certmanager.k8s.io/v1alpha1
kind: ClusterIssuer
metadata:
 name: letsencrypt-prod
spec:
 acme:
   # The ACME server URL
   server: https://acme-v02.api.letsencrypt.org/directory
   # Email address used for ACME registration
   email:
   # Name of a secret used to store the ACME account private key
   privateKeySecretRef:
     name: letsencrypt-prod
   # Enable the HTTP-01 challenge provider
   http01: {}

Notieren Sie die unterschiedliche ACME-Server-URL und den Namen des geheimen Schlüssels "+ letsencrypt-prod +".

Speichern und schließen Sie die Datei, wenn Sie mit der Bearbeitung fertig sind.

Führen Sie diesen Issuer jetzt mit + kubectl + aus:

kubectl create -f prod_issuer.yaml

Sie sollten die folgende Ausgabe sehen:

Outputclusterissuer.certmanager.k8s.io/letsencrypt-prod created

Aktualisieren Sie "+ echo_ingress.yaml +", um diesen neuen Emittenten zu verwenden:

nano echo_ingress.yaml

Nehmen Sie die folgenden Änderungen an der Datei vor:

echo_ingress.yaml

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
 name: echo-ingress
 annotations:
   kubernetes.io/ingress.class: nginx
   certmanager.k8s.io/cluster-issuer:
spec:
 tls:
 - hosts:
   - echo1.example.com
   - echo2.example.com
   secretName:
 rules:
 - host: echo1.example.com
   http:
     paths:
     - backend:
         serviceName: echo1
         servicePort: 80
 - host: echo2.example.com
   http:
     paths:
     - backend:
         serviceName: echo2
         servicePort: 80

Hier aktualisieren wir sowohl den ClusterIssuer als auch den geheimen Namen auf "+ letsencrypt-prod +".

Wenn Sie mit Ihren Änderungen zufrieden sind, speichern und schließen Sie die Datei.

Führen Sie die Änderungen mit + kubectl apply + aus:

kubectl apply -f echo_ingress.yaml
Outputingress.extensions/echo-ingress configured

Warten Sie einige Minuten, bis der Let’s Encrypt-Produktionsserver das Zertifikat ausgestellt hat. Sie können den Fortschritt mit + kubectl describe + für das Objekt + certificate + verfolgen:

kubectl describe certificate letsencrypt-prod

Sobald Sie die folgende Ausgabe sehen, wurde das Zertifikat erfolgreich ausgestellt:

OutputEvents:
 Type    Reason         Age   From          Message
 ----    ------         ----  ----          -------
 Normal  Generated      82s   cert-manager  Generated new private key
 Normal  OrderCreated   82s   cert-manager  Created Order resource "letsencrypt-prod-2626449824"
 Normal  OrderComplete  37s   cert-manager  Order "letsencrypt-prod-2626449824" completed successfully
 Normal  CertIssued     37s   cert-manager  Certificate issued successfully

Wir führen jetzt einen Test mit "+ curl +" durch, um zu überprüfen, ob HTTPS richtig funktioniert:

curl echo1.example.com

Sie sollten Folgendes sehen:

Output<html>
<head><title>308 Permanent Redirect</title></head>
<body>
<center><h1>308 Permanent Redirect</h1></center>
<hr><center>nginx/1.15.9</center>
</body>
</html>

Dies zeigt an, dass HTTP-Anforderungen zur Verwendung von HTTPS umgeleitet werden.

Führen Sie "+ curl" auf "+ https: // echo 1.example.com +" aus:

curl https://echo1.example.com

Sie sollten jetzt die folgende Ausgabe sehen:

Outputecho1

Sie können den vorherigen Befehl mit dem ausführlichen Flag "+ -v +" ausführen, um tiefer in den Zertifikat-Handshake einzudringen und die Zertifikatinformationen zu überprüfen.

Zu diesem Zeitpunkt haben Sie HTTPS mithilfe eines Let’s Encrypt-Zertifikats für Ihren Nginx Ingress erfolgreich konfiguriert.

Fazit

In diesem Handbuch richten Sie einen Nginx Ingress ein, um externe Anforderungen an Back-End-Services innerhalb Ihres Kubernetes-Clusters zu verteilen und weiterzuleiten. Sie haben Ingress auch durch Installieren des Zertifikatsbereitstellungsprogramms von cert-manager und Einrichten eines Let’s Encrypt-Zertifikats für zwei Hostpfade gesichert.

Es gibt viele Alternativen zum Nginx Ingress Controller. Weitere Informationen finden Sie in der offiziellen Kubernetes-Dokumentation unter Ingress controller.

Related