Bereitstellung von HTTPS-Diensten auf Magnum Kubernetes in der EO-Lab FRA1-1 Cloud
Mit Kubernetes kann eine Anwendung sehr schnell bereitgestellt und öffentlich zugänglich gemacht werden, zum Beispiel mit dem Diensttyp LoadBalancer. Beispielimplementierungen, die diese Fähigkeit demonstrieren, werden in der Regel mit HTTP bereitgestellt. Die Bereitstellung eines produktionsreifen Dienstes, der mit HTTPS gesichert ist, kann auch problemlos mit zusätzlichen Tools erfolgen.
In diesem Artikel zeigen wir, wie man einen HTTPS-geschützten Dienst auf EO-Lab FRA1-1.
Was wir behandeln werden
Installation der benutzerdefinierten Ressourcendefinitionen von Cert Manager
Cert Manager Helm-Diagramm installieren
Erstellen einer Einrichtung und eines Dienstes
Erstellen und Bereitstellen eines Ausstellers
Assoziieren der Domäne mit NGINX Ingress
Erstellen und Bereitstellen einer Ingress-Ressource
Voraussetzungen
Nr. 1 Konto
Sie benötigen einen Hosting-Zugang mit Zugriff auf die Horizon-Schnittstelle: https://cloud.fra1-1.cloudferro.com/auth/login/?next=/.
Nr. 2 Kubernetes-Cluster auf FRA1-1 Cloud, mit aktiviertem NGINX Ingress
Siehe diesen Artikel Erstellen eines Kubernetes-Clusters mit EO-Lab OpenStack Magnum
Nr. 3 Kenntnisse von kubectl
Weitere Anweisungen finden Sie in Zugriff auf Kubernetes-Cluster nach der Bereitstellung mit Kubectl auf EO-Lab OpenStack Magnum
Nr. 4 Kenntnis der Kubernetes-Ingress-Funktion
Es wird im Artikel Using Kubernetes Ingress on EO-Lab FRA1-1 OpenStack Magnum erklärt
Nr. 5 Kenntnisse über den Einsatz von Helm-Diagrammen
Siehe diesen Artikel:
Einsatz von Helm Charts auf Magnum Kubernetes-Clustern auf der EO-Lab FRA1-1 Cloud
Nr. 6 Sie müssen eine bei einer Registrierstelle erworbene Domain besitzen
Sie müssen auch eine Domain besitzen, die Sie bei einem Registrar (Domain-Wiederverkäufer) erworben haben. Der Bezug einer Domain von einem Registrar wird in diesem Artikel nicht behandelt.
Nr. 7 Nutzen Sie den DNS-Befehl Horizon, um eine Verbindung mit dem Domainnamen herzustellen
Dies ist optional. Hier ist der Artikel mit detaillierten Informationen:
Schritt 1 Installieren Sie die benutzerdefinierten Ressourcendefinitionen (CRDs) von Cert Manager
Wir gehen davon aus, dass Sie Ihr
Magnum-Cluster eingerichtet ist und läuft und
kubectl auf Ihre Cluster- config-Datei verweist.
Als Vorabprüfung können Sie die Knoten Ihres Clusters auflisten:
# export KUBECONFIG=<your-kubeconfig-file-location>
kubectl get nodes
Das CertManager Helm-Chart verwendet einige benutzerdefinierte Ressourcendefinitionen (Custom Resource Definitions, CRDs), die wir in unserem Cluster einsetzen müssen. Neben mehreren standardmäßig in Kubernetes verfügbaren Ressourcen (z. B. Pods, Deployments oder Services) ermöglichen CRDs die Bereitstellung benutzerdefinierter Ressourcen, die von Drittentwicklern definiert wurden, um weitere benutzerdefinierte Anwendungsfälle zu erfüllen. Fügen wir mit dem folgenden Befehl CRDs zu unserem Cluster hinzu:
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.9.2/cert-manager.crds.yaml
Die Liste der Ressourcen wird nach der Ausführung des Befehls angezeigt. Wenn wir später auf sie verweisen wollen, können wir auch den folgenden kubectl-Befehl verwenden:
kubectl get crd -l app.kubernetes.io/name=cert-manager
...
NAME CREATED AT
certificaterequests.cert-manager.io 2022-12-18T11:15:08Z
certificates.cert-manager.io 2022-12-18T11:15:08Z
challenges.acme.cert-manager.io 2022-12-18T11:15:08Z
clusterissuers.cert-manager.io 2022-12-18T11:15:08Z
issuers.cert-manager.io 2022-12-18T11:15:08Z
orders.acme.cert-manager.io 2022-12-18T11:15:08Z
Warnung
Magnum führt einige Pod-Sicherheitsrichtlinien (PSP) ein, die einige zusätzliche Sicherheitsvorkehrungen für den Cluster bieten, aber Konflikte mit dem CertManager Helm-Diagramm verursachen. PodSecurityPolicy ist bis Kubernetes 1.25 veraltet, wird aber noch in den Versionen 1.21 bis 1.23 von Kubernetes unterstützt, die auf EO-Lab cloud verfügbar sind. Die folgenden Befehle können Warnungen über die Veralterung ausgeben, aber die Installation sollte trotzdem fortgesetzt werden.
Schritt 2 Installieren Sie CertManager Helm chart
Um eine korrekte Bereitstellung der CertManager Helm-Tabelle zu gewährleisten, müssen wir die Datei my-values.yaml überschreiben und den entsprechenden Inhalt einfügen:
my-values.yaml
global:
podSecurityPolicy:
enabled: true
useAppArmor: false
Der folgende Code installiert das CertManager Helm-Diagramm in einem Namespace cert-manager und verwendet gleichzeitig my-values.yaml:
helm repo add jetstack https://charts.jetstack.io
helm repo update
helm install cert-manager jetstack/cert-manager --namespace cert-manager --create-namespace --version v1.9.2 --values my-values.yaml
Dies ist das Ergebnis:
helm install cert-manager jetstack/cert-manager --namespace cert-manager --create-namespace --version v1.9.2 --values my-values.yaml
W0208 10:16:08.364635 212 warnings.go:70] policy/v1beta1 PodSecurityPolicy is deprecated in v1.21+, unavailable in v1.25+
W0208 10:16:08.461599 212 warnings.go:70] policy/v1beta1 PodSecurityPolicy is deprecated in v1.21+, unavailable in v1.25+
W0208 10:16:08.502602 212 warnings.go:70] policy/v1beta1 PodSecurityPolicy is deprecated in v1.21+, unavailable in v1.25+
W0208 10:16:11.489377 212 warnings.go:70] policy/v1beta1 PodSecurityPolicy is deprecated in v1.21+, unavailable in v1.25+
W0208 10:16:11.489925 212 warnings.go:70] policy/v1beta1 PodSecurityPolicy is deprecated in v1.21+, unavailable in v1.25+
W0208 10:16:11.524300 212 warnings.go:70] policy/v1beta1 PodSecurityPolicy is deprecated in v1.21+, unavailable in v1.25+
W0208 10:16:13.949045 212 warnings.go:70] policy/v1beta1 PodSecurityPolicy is deprecated in v1.21+, unavailable in v1.25+
W0208 10:16:15.038803 212 warnings.go:70] policy/v1beta1 PodSecurityPolicy is deprecated in v1.21+, unavailable in v1.25+
W0208 10:17:36.084859 212 warnings.go:70] policy/v1beta1 PodSecurityPolicy is deprecated in v1.21+, unavailable in v1.25+
NAME: cert-manager
LAST DEPLOYED: Wed Feb 8 10:16:07 2023
NAMESPACE: cert-manager
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
cert-manager v1.9.2 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).
Wir sehen, dass cert-manager erfolgreich bereitgestellt wurde, erhalten aber auch einen Hinweis, dass ClusterIssuer oder eine Issuer-Ressource ebenfalls installiert werden muss. Unser nächster Schritt besteht darin, einen Beispieldienst im Cluster zu installieren und dann mit der Erstellung und Bereitstellung eines Issuer fortzufahren.
Schritt 3 Erstellen eines Deployments und eines Dienstes
Lassen Sie uns den NGINX-Dienst als Standardbeispiel für eine Kubernetes-Anwendung bereitstellen. Zuerst erstellen wir ein Standard-Kubernetes-Deployment und dann einen Dienst vom Typ NodePort. Schreiben Sie den folgenden Inhalt in die Datei my-nginx.yaml :
my-nginx.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-nginx-deployment
spec:
selector:
matchLabels:
run: my-nginx
replicas: 1
template:
metadata:
labels:
run: my-nginx
spec:
containers:
- name: my-nginx
image: nginx
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: my-nginx-service
labels:
run: my-nginx
spec:
type: NodePort
ports:
- port: 80
protocol: TCP
selector:
run: my-nginx
Bereitstellung mit dem folgenden Befehl:
kubectl apply -f my-nginx.yaml
Schritt 4 Erstellen und Bereitstellen eines Emittenten
Installieren Sie nun einen Issuer. Es handelt sich dabei um eine benutzerdefinierte Kubernetes-Ressource und stellt eine Zertifizierungsstelle (CA) dar, die sicherstellt, dass unsere HTTPS signiert sind und daher von den Browsern als vertrauenswürdig eingestuft werden. CertManager unterstützt verschiedene Aussteller, in unserem Beispiel werden wir Let’s Encrypt verwenden, das das ACME-Protokoll nutzt.
Erstellen Sie eine neue Datei mit dem Namen my-nginx-issuer.yaml und fügen Sie den folgenden Inhalt in diese Datei ein. Ändern Sie die E-Mail-Adresse XXXXXXXXX@YYYYYYYYY.com in Ihre eigene und echte E-Mail-Adresse.
my-nginx-issuer.yaml
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
name: my-nginx-issuer
spec:
acme:
email: [email protected]
server: https://acme-v02.api.letsencrypt.org/directory # production
privateKeySecretRef:
name: letsencrypt-secret # different secret name than for ingress
solvers:
# HTTP-01 challenge provider, creates additional ingress, refer to CertManager documentation for detailed explanation
- http01:
ingress:
class: nginx
Dann auf dem Cluster bereitstellen:
kubectl apply -f my-nginx-issuer.yaml
Als Ergebnis wird der Issuer bereitgestellt, und ein Secret namens letsencrypt-secret mit einem privaten Schlüssel wird ebenfalls bereitgestellt.
Schritt 5 Assoziieren der Domäne mit NGINX Ingress
Um die Website im Browser anzuzeigen, muss Ihr HTTPS-Zertifikat mit einer bestimmten Domain verknüpft werden. Dazu sollten Sie eine echte Domain haben, die bereits bei einem Domain-Registrar registriert ist.
Als Sie Ihren Cluster mit NGINX ingress eingerichtet haben, wurde im Hintergrund ein LoadBalancer mit einer öffentlichen IP-Adresse eingerichtet. Sie erhalten diese Adresse, indem Sie sie in der Horizon-Webschnittstelle nachschlagen. Wenn Ihre Liste der Floating-IPs länger ist, können Sie sie leicht am Namen erkennen:
Nun müssen Sie bei Ihrer Domänenregistrierungsstelle den A-Eintrag der Domäne mit der floating IP-Adresse des Ports verbinden, an dem Ihre Anwendung zugänglich sein wird. Wie dies zu bewerkstelligen ist, hängt von der jeweiligen Registrierstelle ab, weshalb wir hier keine detaillierten Anweisungen geben werden.
Sie können auch den DNS-Befehl in Horizon verwenden, um den Domänennamen, den Sie haben, mit dem Cluster zu verbinden. Siehe Voraussetzung Nr. 7 für weitere Details.
Schritt 6 Erstellen und Bereitstellen einer Ingress-Ressource
Der letzte Schritt ist die Bereitstellung der Ingress-Ressource. Diese führt die notwendigen Schritte durch, um die Zertifikatsanforderung bei der CA zu initiieren und schließlich das HTTPS-Zertifikat für Ihren Dienst bereitzustellen. Um fortzufahren, fügen Sie den folgenden Inhalt in die Datei my-nginx-ingress.yaml ein. Ersetzen Sie mysampledomain.eu durch Ihre Domain.
my-nginx-ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: my-nginx-ingress
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
# below annotation is for using cert manager's "ingress shim", refer to CertManager documentation
cert-manager.io/issuer: my-nginx-issuer # use the name of the issuer here
spec:
ingressClassName: nginx
tls:
- hosts:
- mysampledomain.eu #change to own domain
secretName: my-nginx-secret
rules:
- host: mysampledomain.eu #change to own domain
http:
paths:
- path: /*
pathType: Prefix
backend:
service:
name: my-nginx-service
port:
number: 80
Dann stellen Sie bereit mit:
kubectl apply -f my-nginx-ingress.yaml
Wenn alles funktioniert, ist der Vorgang abgeschlossen und nach ein paar Minuten sollte das Schlosszeichen vor unserer IP-Adresse zu sehen sein. Der Dienst ist nun HTTPS-gesichert, und Sie können die Details des Zertifikats überprüfen, indem Sie auf das Schloss-Symbol klicken.
Was als nächstes zu tun ist
Der Artikel Using Kubernetes Ingress on EO-Lab FRA1-1 OpenStack Magnum zeigt, wie man einen HTTP-basierten Dienst oder eine Site erstellt.
Wenn Sie weitere Informationen zu Helm-Charts benötigen: Einsatz von Helm Charts auf Magnum Kubernetes-Clustern auf der EO-Lab FRA1-1 Cloud.