Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

HAProxy-Referenzimplementierung für Layer-7-Load-Balancing

Google Distributed Cloud (GDC) air-gapped bietet einen integrierten verwalteten Layer 4 (L4)-Load-Balancer. Viele Unternehmensanwendungen erfordern jedoch erweiterte Layer 7 (L7)-Funktionen wie hostbasiertes Routing, zentralisierte TLS-Verwaltung und komplexe Trafficaufteilung. Bisher wurde dies mit der Ingress API erreicht, die in der Kubernetes-Community jetzt als funktionsmäßig eingefroren gilt.

Diese Referenzarchitektur bietet eine selbstverwaltete Layer 7-Load-Balancing-Lösung. Durch die Bereitstellung des beliebten Open-Source-Controllers HAProxy auf einem GDC-Standardcluster können Kunden L7-Traffic nahtlos an Hybridumgebungen weiterleiten. Diese Architektur verwendet die TLS-Terminierung (HTTPRoute), um Traffic basierend auf der Server Name Indication (SNI) sowohl an integrierte containerisierte Pods als auch an Anwendungen weiterzuleiten, die auf externen virtuellen Maschinen gehostet werden.

Architektur

Architekturdiagramm für HAProxy-Layer-7-Load-Balancing in GDC mit Air Gap.

Zu den wichtigsten Komponenten der Lösung gehören:

Client:Eine Entität, die HTTPS-Anfragen initiiert, um mit den Anwendungen zu interagieren.
GDC-Standardcluster:GDC bietet eine integrierte Möglichkeit zum Erstellen von Kubernetes-Vanilla-Clustern. In dieser Lösung hostet der Cluster den L7-Load-Balancer und seine Controller sowie die Arbeitslasten und den monitorlosen Dienst für externe VMs.
GDC-L4-Load-Balancer:Der integrierte L4-Load-Balancer dient als Einstiegspunkt und verteilt TCP/443-Traffic direkt an die Kubernetes-Pods, auf denen die Controller ausgeführt werden.
Ingress-Controller:HAProxy-Operatoren, die im Standardcluster ausgeführt werden. Sie überwachen die Ingress-Ressourcen und aktualisieren die zugrunde liegenden Proxys dynamisch. Der HAProxy Ingress Controller wird in der folgenden Implementierung verwendet.
Ingress:Standardisierte Kubernetes-Ressourcen, die den physischen Listening-Port (443) und die SNI-basierten Host-Routing-Regeln mit TLS-Terminierung definieren.
Containerisierte Arbeitslast (Pods) : Eine Standard-Kubernetes-Bereitstellung, die intern mit einem regulären Kubernetes-Service bereitgestellt wird.
VM-basierte Arbeitslast (extern) : Eine Arbeitslast, die auf einer externen VM im Projektnetzwerk gehostet wird und für den Proxy über einen monitorlosen Kubernetes-Service und einen benutzerdefinierten Endpunkt mit der direkten IP-Adresse der VM bereitgestellt wird.
Harbor Registry:Eine private Container-Registry, die zum Speichern und Bereitstellen der Proxy- und Anwendungs-Images in der Air-Gap-Umgebung verwendet wird.

Im Standardcluster erstellen Sie drei Namespaces:

Der Namespace load-balancer hostet den HAProxy Ingress Controller und die HAProxy-Load-Balancer-Arbeitslast:
Der Namespace hello-app hostet die Deployment, einen Service und einen Ingress für die containerisierte Demo-Arbeitslast:
Der Namespace vm-app hostet einen monitorlosen Dienst, der die externe VM-IP-Adresse, eine EndpointSlice, die auf die externe IP-Adresse verweist, und einen Ingress bereitstellt:

Hinweis

Bevor Sie diese Lösung bereitstellen, müssen die folgenden Voraussetzungen erfüllt sein:

Erforderliche Software:helm, docker, kubectl

CLI-Anmeldung und lokale Einrichtung:Laden Sie die gdcloud CLI aus der GDC Console herunter und richten Sie Ihre Umgebung lokal ein:

export USER_NAME="USER_NAME"
export PROJECT_ID="PROJECT_ID"
export ZONE="ZONE"
export ORG_NAME="ORG_NAME"
export GDC_URL="GDC_URL"

gdcloud components install gdcloud-k8s-auth-plugin

gdcloud config set core/organization_console_url \
  https://console.$ORG_NAME.$ZONE.$GDC_URL
gdcloud config set core/zone $ZONE
gdcloud config set core/project ${PROJECT_ID}

gdcloud auth login # use --login-config-cert option in case of TLS error

Projekteinrichtung:Erstellen Sie ein Projekt in Ihrer GDC mit Air Gap-Umgebung, um die Ressourcen zu hosten:
```
gdcloud projects create $PROJECT_ID
```

IAM-Rollen:Weisen Sie Ihrem Nutzer die Rollen Cluster Admin und Standard Cluster Admin zu, um Kubernetes-Ressourcen zu verwalten, und die Rolle Harbor Instance Admin , um Images zu übertragen:

# Grant standard cluster and cluster admin roles
gdcloud projects add-iam-policy-binding ${PROJECT_ID} \
  --member="user:${USER_NAME}" \
  --role=cluster-admin

gdcloud projects add-iam-policy-binding ${PROJECT_ID} \
  --member="user:${USER_NAME}" \
  --role=standard-cluster-admin

# Grant Harbor instance admin role
gdcloud projects add-iam-policy-binding ${PROJECT_ID} \
  --member="user:${USER_NAME}" \
  --role=harbor-instance-admin

Standardcluster erstellen

In diesem Abschnitt wird beschrieben, wie Sie einen Standard-Kubernetes-Cluster in Ihrer GDC mit Air Gap-Umgebung einrichten. Ein Standardcluster bietet eine flexible und robuste Grundlage für die Bereitstellung verschiedener Arbeitslasten, einschließlich des HAProxy Ingress Controller und Ihrer benutzerdefinierten Anwendungen. Mit den folgenden Schritten wird sichergestellt, dass Ihr Cluster ordnungsgemäß konfiguriert und für nachfolgende Bereitstellungen zugänglich ist.

Ermitteln Sie die verfügbaren VM-Image-Typen, indem Sie Folgendes ausführen:
```
gdcloud compute machine-types list
```
Wählen Sie einen geeigneten Maschinentyp für Ihre Cluster-Worker-Knoten aus. Für diese Anleitung wird ein Maschinentyp mit mindestens 4 vCPUs empfohlen.
```
export MACHINE_TYPE="MACHINE_TYPE"
```

Rufen Sie die kubeconfig-Datei des Management API-Servers ab und legen Sie einen Alias fest:

export CLUSTER_NAME="CLUSTER_NAME"

KUBECONFIG=kubeconfig-admin.yaml gdcloud clusters \
  get-credentials ${ORG_NAME}-admin

alias km="kubectl --kubeconfig kubeconfig-admin.yaml"

Erstellen Sie einen Standardcluster mit zwei Worker-Knoten:

km create -f - <<EOF
apiVersion: cluster.gdc.goog/v1
kind: Cluster
metadata:
  name: ${CLUSTER_NAME}
  namespace: ${PROJECT_ID}
spec:
  nodePools:
  - machineTypeName: ${MACHINE_TYPE}
    nodeCount: 2
    name: ${CLUSTER_NAME}-node-pool
EOF

Weitere Informationen zu den verfügbaren Optionen finden Sie in der Dokumentation.

Die Erstellung eines Standardclusters kann bis zu 60 Minuten dauern. Verwenden Sie den folgenden Befehl, um den Status zu prüfen:

km get clusters/${CLUSTER_NAME} \
  -n ${PROJECT_ID} \
  --watch

Wenn der Cluster bereit ist, sollte die Ausgabe den Status „Wird ausgeführt“ anzeigen, wie hier:

NAME         STATE     K8S VERSION
my-cluster   Running   1.30.12-gke.300

Rufen Sie nach der Clustererstellung die Anmeldedaten ab:

KUBECONFIG=kubeconfig-${CLUSTER_NAME}.yaml gdcloud clusters \
  get-credentials ${CLUSTER_NAME} \
  --standard \
  --project ${PROJECT_ID} \
  --zone ${ZONE}

Erstellen Sie einen Alias, um kubectl-Befehle im Rest dieser Anleitung kürzer zu halten. Dieser Alias wird für die Interaktion mit dem Standardcluster verwendet:
```
alias kk="kubectl --kubeconfig kubeconfig-${CLUSTER_NAME}.yaml"
```
Erstellen Sie Namespaces für den Controller, die containerisierte Demoanwendung „hello-app“ und die VM-basierte Demoanwendung:
```
kk create namespace load-balancer
kk create namespace hello-app
kk create namespace vm-app
```

Harbor Registry erstellen und einbinden

Harbor ist eine Container-Image-Registry mit integrierter Unterstützung in GDC mit Air Gap. In diesem Abschnitt werden die Schritte zum Einbinden einer Harbor Registry in Ihren Standardcluster beschrieben, einschließlich der Konfiguration von Anmeldedaten und Secrets, um das sichere Abrufen und Übertragen von Images zu ermöglichen.

Erstellen Sie eine Harbor Instanz in Ihrem Projekt.
Erstellen Sie ein Harbor Projekt in Ihrer Harbor-Instanz.

Legen Sie Umgebungsvariablen fest:

export HARBOR_INSTANCE_NAME="HARBOR_INSTANCE_NAME"
export HARBOR_INSTANCE_URL="HARBOR_INSTANCE_URL"
export HARBOR_PROJECT="HARBOR_PROJECT"
export IMAGE_PULL_SECRET_NAME="harbor-secret"

Melden Sie sich mit einem Roboter Konto in der Harbor-Instanz an:
```
docker --config=./docker login ${HARBOR_INSTANCE_URL}
```

Erstellen Sie die Secrets im Standardcluster:

kk create secret docker-registry ${IMAGE_PULL_SECRET_NAME} \
  --from-file=.dockerconfigjson=./docker/config.json \
  -n load-balancer

kk create secret docker-registry ${IMAGE_PULL_SECRET_NAME} \
  --from-file=.dockerconfigjson=./docker/config.json \
  -n hello-app

Containerisierte Demoanwendung bereitstellen

In diesem Abschnitt wird die Bereitstellung einer containerisierten Demoanwendung (hello-app) in Ihrem GDC-Air-Gap-Kubernetes-Cluster beschrieben. Sie erstellen die erforderlichen Kubernetes-Bereitstellungs- und -Dienstressourcen, um die hello-app auszuführen und sie intern im Cluster bereitzustellen, damit sie über den L7-Load-Balancer aufgerufen werden kann.

Laden Sie ein Beispiel-Image für die containerisierte Demoanwendung in Harbor hoch:

docker pull gcr.io/google-samples/hello-app:1.0 \
  --platform linux/amd64
docker tag gcr.io/google-samples/hello-app:1.0 \
  ${HARBOR_INSTANCE_URL}/${HARBOR_PROJECT}/hello-app:1.0
docker --config=./docker push \
  ${HARBOR_INSTANCE_URL}/${HARBOR_PROJECT}/hello-app:1.0

Stellen Sie das folgende Manifest im Standardcluster bereit:

cat << EOF > hello-app.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-app
  namespace: hello-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: hello-app
  template:
    metadata:
      labels:
        app: hello-app
    spec:
      containers:
      - name: hello-server
        image: ${HARBOR_INSTANCE_URL}/${HARBOR_PROJECT}/hello-app:1.0
        ports:
        - containerPort: 8080
      imagePullSecrets:
      - name: ${IMAGE_PULL_SECRET_NAME}
---
apiVersion: v1
kind: Service
metadata:
  name: hello-app
  namespace: hello-app
spec:
  type: ClusterIP
  selector:
    app: hello-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
EOF

kk apply -f hello-app.yaml

Prüfen Sie dann, ob die Bereitstellung und der Dienst vorhanden sind.

kk get svc,deploy -n hello-app

Demo-App in einer VM bereitstellen

In diesem Abschnitt wird die Bereitstellung einer Demoanwendung in einer VM außerhalb Ihres Kubernetes-Clusters beschrieben. Durch das Einrichten eines HTTP-Servers auf einer VM simulieren Sie eine externe Anwendung, die der Load-Balancer bereitstellen kann. So wird die Fähigkeit des Load-Balancers demonstriert, Traffic zu Ressourcen innerhalb und außerhalb des Clusters zu verwalten.

Erstellen Sie zuerst eine VM für die Demo-App:

Öffnen Sie die GDC Console in Ihrem Webbrowser.
Wählen Sie dasselbe Projekt aus, in dem Sie Ihren Standard-Kubernetes-Cluster erstellt haben.
Öffnen Sie das Menü und klicken Sie auf Virtuelle Maschinen.
Klicken Sie auf Instanz erstellen.
Geben Sie der VM den Namen vm-workload. Für das Beispiel reicht ein Image mit 2 vCPUs aus.
Wählen Sie für das Bootlaufwerk-Image eine Ubuntu 22.04-Distribution aus, auf der Python vorinstalliert ist.
Klicken Sie auf Erstellen.
Warten Sie einige Minuten, bis die VM bereit ist.
Stellen Sie eine SSH-Verbindung zur VM her:
1. Klicken Sie in der GDC Console auf die VM.
2. Klicken Sie auf Mit SSH verbinden.

Führen Sie nach der Verbindung mit der SSH-Konsole Folgendes aus:

mkdir ~/simple-server
cd ~/simple-server
echo 'Welcome to my VM!' > index.html
python3 -m http.server --bind 0.0.0.0 8080 &

Um Traffic an eine VM weiterzuleiten, erstellen Sie einen monitorlosen Dienst (ohne Selektoren). Dieser wird manuell der internen IP-Adresse der VM mit einer EndpointSlice-Ressource zugeordnet.

kk apply -f - <<EOF
apiVersion: v1
kind: Service
metadata:
  name: vm-app-svc
  namespace: vm-app
spec:
  ports:
  - protocol: TCP
    port: 443
    targetPort: 443
EOF

Rufen Sie die IP-Adresse der VM vm-workload ab, indem Sie Folgendes ausführen:

gdcloud compute instances list --project ${PROJECT_ID} \
  | grep workload-vm | awk '{print $3}'

Die Ausgabe ist die IP-Adresse der VM, die zum Einrichten der EndpointSlice-Ressource erforderlich ist.

Erstellen Sie die Ressource EndpointSlice, die eine Verbindung zum monitorlosen Dienst der VM-App herstellt und die IP-Adresse der VM angibt, an die der Traffic weitergeleitet werden soll.

apiVersion: discovery.k8s.io/v1
kind: EndpointSlice
metadata:
  name: vm-app-endpoints
  namespace: vm-app
  labels:
    kubernetes.io/service-name: vm-app-svc
addressType: IPv4
ports:
  - port: 8080
endpoints:
  - addresses:
    - "VM_IP"
    conditions:
      ready: true

Selbst signierte Zertifikate erstellen

In diesem Abschnitt wird beschrieben, wie Sie TLS-Zertifikate und Kubernetes-Secrets erstellen, um die Kommunikation für Ihre containerbasierten und VM-basierten Anwendungen zu sichern. In dieser Anleitung werden selbst signierte Zertifikate verwendet. In Produktionsumgebungen müssen Sie jedoch Zertifikate in Produktionsqualität verwenden, wie unter Optional: Zertifikate in Produktionsqualität verwenden beschrieben. Wählen Sie beliebige Beispiel-Domainnamen für diese Apps aus. Durch das Einrichten sicherer Verbindungen sorgen Sie für Datenintegrität und Vertraulichkeit für Clients, die über den HAProxy Ingress Controller auf Ihre Anwendung zugreifen.

Für die containerisierte App erstellen wir ein selbst signiertes Zertifikat und speichern es als Secret im Namespace des Load-Balancers. Dieses wird für TLS verwendet, wenn k8s-app.example.com angefordert wird.

openssl req -x509 -newkey rsa:2048 -nodes \
  -keyout tls-containerized.key \
  -out tls-containerized.crt \
  -subj "/CN=k8s-app.example.com" \
  -days 365

kk create secret tls tls-containerized \
  --namespace load-balancer \
  --key tls-containerized.key \
  --cert tls-containerized.crt

kk create secret tls tls-containerized \
  --namespace hello-app \
  --key tls-containerized.key \
  --cert tls-containerized.crt

Für die VM-App wird ein ähnliches selbst signiertes Zertifikat ausgestellt und gespeichert. Dieses wird für TLS verwendet, wenn vm-app.example.com angefordert wird.

openssl req -x509 -newkey rsa:2048 -nodes \
  -keyout tls-vm.key \
  -out tls-vm.crt \
  -subj "/CN=vm-app.example.com" \
  -days 365

kk create secret tls tls-vm \
  --namespace load-balancer \
  --key tls-vm.key \
  --cert tls-vm.crt

kk create secret tls tls-vm \
  --namespace vm-app \
  --key tls-vm.key \
  --cert tls-vm.crt

HAProxy bereitstellen

HAProxy Ingress Controller und L4-Load-Balancer installieren

export HAPROXY_VERSION=3.1.14

# pull the HAProxy Ingress Controller image and push it to Harbor
docker pull haproxytech/kubernetes-ingress:${HAPROXY_VERSION} \
  --platform linux/amd64
docker tag haproxytech/kubernetes-ingress:${HAPROXY_VERSION} \
  ${HARBOR_INSTANCE_URL}/${HARBOR_PROJECT}/haproxy-ingress:${HAPROXY_VERSION}
docker --config=./docker push \
  ${HARBOR_INSTANCE_URL}/${HARBOR_PROJECT}/haproxy-ingress:${HAPROXY_VERSION}

# Get Helm repo
helm repo add haproxytech https://haproxytech.github.io/helm-charts
helm repo update

# Install the Ingress Controller with helm
helm upgrade --install haproxy-kubernetes-ingress \
  haproxytech/kubernetes-ingress \
  --kubeconfig kubeconfig-${CLUSTER_NAME}.yaml \
  --namespace load-balancer \
  --set controller.image.repository=${HARBOR_INSTANCE_URL}/${HARBOR_PROJECT}/haproxy-ingress \
  --set controller.image.tag=${HAPROXY_VERSION} \
  --set controller.existingImagePullSecret=${IMAGE_PULL_SECRET_NAME} \
  --set controller.service.type=LoadBalancer \
  --set-json \
  controller.service.annotations='{"networking.gke.io/load-balancer-type": "internal"}'

Der HAProxy Ingress Controller erhält eine eindeutige virtuelle IP-Adresse für den Clientzugriff über einen Dienst vom Typ LoadBalancer. Dieser Dienst richtet einen vollständig verwalteten Layer 4-Load-Balancer ein. Um diese Anleitung zu vereinfachen, wird ein interner Load-Balancer erstellt, indem die Annotation load-balancer-type auf internal gesetzt wird. Wenn Sie diese Annotation weglassen, wird ein externer Load-Balancer erstellt. Die Kubernetes-Bereitstellung ruft Images sicher aus Harbor ab, indem das bereitgestellte Secret (${IMAGE_PULL_SECRET_NAME}) verwendet wird, das die Anmeldedaten des Harbor-Roboter-Kontos enthält.

Installation des HAProxy Ingress Controller prüfen

Prüfen Sie, ob die Pods des HAProxy Ingress Controller ausgeführt und bereit sind:

kk get pods -n load-balancer

Die Ausgabe sollte so aussehen:

NAME                                          READY   STATUS      RESTARTS   AGE
haproxy-kubernetes-ingress-78dc9c8676-f8fcb   1/1     Running     0          35s
haproxy-kubernetes-ingress-78dc9c8676-lfnr2   1/1     Running     0          65s
haproxy-kubernetes-ingress-crdjob-3-tgj2h     0/1     Completed   0          65s

Prüfen Sie, ob der Dienst des HAProxy Ingress Controller erstellt und konfiguriert wurde:

kk get services -n load-balancer

Die Ausgabe sieht dann ungefähr so aus:

NAME                         TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)                                                                  AGE
haproxy-kubernetes-ingress   LoadBalancer   10.252.27.46   10.252.4.17   80:32023/TCP,443:31103/TCP,443:31103/UDP,1024:30146/TCP,6060:30718/TCP   10m

Ingress-Ressourcen für die Demoanwendungen definieren

Erstellen Sie die Ingress-Ressource, die HAProxy mit dem Dienst der containerisierten App verbindet.

cat << EOF > hello-app-ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: hello-app-ingress
  namespace: hello-app
  annotations:
    haproxy.org/ssl-redirect: "true"
    haproxy.org/ssl-redirect-port: "443"
    haproxy.org/ssl-redirect-code: "308"
spec:
  ingressClassName: haproxy
  tls:
  - hosts:
    - "k8s-app.example.com"
    secretName: tls-containerized
  rules:
  - host: "k8s-app.example.com"
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: hello-app
            port:
              number: 80
EOF

kk apply -f hello-app-ingress.yaml

Erstellen Sie die Ingress-Ressource, die eine Verbindung zum monitorlosen Dienst der VM-App herstellt und die IP-Adresse der VM angibt, an die der Traffic weitergeleitet werden soll.

cat << EOF > vm-ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: vm-app-ingress
  namespace: vm-app
  annotations:
    haproxy.org/ssl-redirect: "true"
    haproxy.org/ssl-redirect-port: "443"
    haproxy.org/ssl-redirect-code: "308"
spec:
  ingressClassName: haproxy
  tls:
  - hosts:
    - "vm-app.example.com"
    secretName: tls-vm
  rules:
  - host: "vm-app.example.com"
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: vm-app-svc
            port:
              number: 443
EOF

kk apply -f vm-ingress.yaml

IP-Adresse des Load-Balancers abrufen

Führen Sie den Befehl aus, um die IP-Adresse des Load-Balancers abzurufen.

kk get services/haproxy-kubernetes-ingress \
  -n load-balancer \
  -o jsonpath='{.status.loadBalancer.ingress[0].ip}'

Diese ist erforderlich, um den Zugriff auf die Apps zu prüfen. Sie wird als LOAD_BALANCER_IP bezeichnet.

Client-VM erstellen

Führen Sie die Schritte aus, um eine Client-VM zu erstellen:

Öffnen Sie die GDC Console in Ihrem Webbrowser.
Öffnen Sie das Menü und klicken Sie auf Virtuelle Maschinen.
Klicken Sie auf Instanz erstellen.
Erstellen Sie eine VM mit dem Namen client, wählen Sie einen kleinen Maschinentyp und entweder Rocky Linux oder Ubuntu aus, auf denen curl vorinstalliert ist.
Klicken Sie auf Erstellen.
Warten Sie einige Minuten, bis die VM bereit ist.
Nachdem die VM bereit ist, stellen Sie eine SSH-Verbindung zur VM her:
1. Klicken Sie in der GDC Console auf die VM.
2. Klicken Sie auf Mit SSH verbinden.

Zugriff und Routing prüfen

Führen Sie curl-Befehle von Ihrer Client-VM aus, um das Routing zu testen. Sie können mit der IP-Adresse des Load-Balancers über die definierten Hostnamen eine Verbindung zu beiden Anwendungen herstellen.

Wenn Sie das Flag --resolve in curl übergeben, können Sie erzwingen, dass die Domainnamen in die IP-Adresse Ihres GDC mit Air Gap L4 Load Balancers aufgelöst werden. Beachten Sie, dass wir das Flag -k übergeben, um die selbst signierten Zertifikate als vertrauenswürdig einzustufen.

Testen Sie die containerisierte Kubernetes-App:

curl -k --resolve k8s-app.example.com:443:$LOAD_BALANCER_IP https://k8s-app.example.com -v

Testen Sie die externe VM-App:

curl -k --resolve vm-app.example.com:443:$LOAD_BALANCER_IP https://vm-app.example.com -v

Wenn der Ingress Controller richtig konfiguriert ist, fungiert er nahtlos als TLS-Terminator und leitet den Traffic an das Ziel weiter.

Optional: Zertifikate in Produktionsqualität verwenden

In diesem Abschnitt wird beschrieben, wie Sie den GDC-Air-Gap-CA-Dienst verwenden, um eine private Stammzertifizierungsstelle (Certificate Authority, CA) zu erstellen, signierte Zertifikate für Ihre Arbeitslasten auszustellen und Ihren GDC-Air-Gap-Standardcluster und Ihre Client-VMs sicher zu aktualisieren.

In diesem Abschnitt wird beschrieben, wie Sie den GDC-Air-Gap-CA Service verwenden, um eine private Stammzertifizierungsstelle (Certificate Authority, CA) zu erstellen und gültige Zertifikate für Ihre Anwendungen auszustellen. Wenn Sie diese Stammzertifizierungsstelle auf Ihrer Client-VM installieren, können Sie prüfen, ob die TLS-Terminierung nahtlos mit vertrauenswürdigen Zertifikaten funktioniert, ohne SSL-Warnungen umgehen zu müssen (z. B. mit curl -k).

Erforderliche Berechtigungen erteilen und Anmeldedaten abrufen

Um den CA-Dienst zu verwalten und Zertifikate auszustellen, benötigt Ihr Nutzer die entsprechenden IAM-Rollen im Projekt.

Weisen Sie die Rollen certificate-authority-service-admin und certificate-requester zu:

gdcloud projects add-iam-policy-binding ${PROJECT_ID} \
  --member=user:${USER_NAME} \
  --role=certificate-authority-service-admin

gdcloud projects add-iam-policy-binding ${PROJECT_ID} \
  --member=user:${USER_NAME} \
  --role=certificate-requester

Rufen Sie die Anmeldedaten des Management API-Servers ab:
```
gdcloud clusters get-credentials ${ORG_NAME}-admin
```

Stammzertifizierungsstelle erstellen

Sie erstellen eine Zertifizierungsstelle auf dem Management API-Server in Ihrem Projekt-Namespace.

Wenden Sie die Ressource CertificateAuthority an:

km apply -f - <<EOF
apiVersion: pki.security.gdc.goog/v1
kind: CertificateAuthority
metadata:
  name: my-root-ca
  namespace: ${PROJECT_ID}
spec:
  caProfile:
    commonName: "My Root CA"
    duration: 87600h # 10 years
    keyAlgorithm: RSA_2048
    maxChainLength: 1
  caType: ROOT
  keyLocation: HSM
  rotationPolicy:
    cronTime: 0 0 1 1 *
EOF

km -n ${PROJECT_ID} get \
certificateauthority.pki.security.gdc.goog/my-root-ca -ojson \
| jq -r '
.status.conditions[] | select( .type as $id | "Ready" | index($id)) .status'

Zertifikate ausstellen und bereitstellen

Nachdem die Zertifizierungsstelle bereit ist, fordern Sie Zertifikate für die containerisierte App und die VM-basierte App an. Diese Anfragen erfolgen auf dem Management API-Server und die resultierenden Schlüssel müssen in Ihren Standardcluster verschoben werden.

Erstellen Sie Anfragen für beide Domains:

km apply -f - <<EOF
apiVersion: pki.security.gdc.goog/v1
kind: CertificateRequest
metadata:
  name: tls-containerized-req
  namespace: ${PROJECT_ID}
spec:
  certificateAuthorityRef:
    name: my-root-ca
    namespace: ${PROJECT_ID}
  certificateConfig:
    subjectConfig:
      commonName: "k8s-app.example.com"
      dnsNames:
      - "k8s-app.example.com"
  signedCertificateSecret: tls-containerized-signed
---
apiVersion: pki.security.gdc.goog/v1
kind: CertificateRequest
metadata:
  name: tls-vm-req
  namespace: ${PROJECT_ID}
spec:
  certificateAuthorityRef:
    name: my-root-ca
    namespace: ${PROJECT_ID}
  certificateConfig:
    subjectConfig:
      commonName: "vm-app.example.com"
      dnsNames:
      - "vm-app.example.com"
  signedCertificateSecret: tls-vm-signed
EOF

Warten Sie einige Minuten, bis die Zertifikate ausgestellt wurden. Sie können prüfen, ob sie bereit sind, wenn die Bedingung „Bereit“ auf „True“ gesetzt ist:

km get certificaterequests -n ${PROJECT_ID}

Standardcluster aktualisieren

Wenn Sie die vorherigen Abschnitte dieser Anleitung befolgt haben, haben Sie selbst signierte Secrets in Ihrem Standardcluster. Sie müssen sie löschen, bevor Sie die neuen signierten Versionen erstellen:

kk delete secret tls-containerized -n load-balancer
kk delete secret tls-vm -n load-balancer

kk delete secret tls-containerized -n hello-app
kk delete secret tls-vm -n vm-app

Extrahieren Sie nun die signierten Zertifikate vom Management API-Server und erstellen Sie die neuen Secrets im Standardcluster.

km get secret -n ${PROJECT_ID} tls-containerized-signed \
  -o jsonpath='{.data.tls\.crt}' \
  | base64 -d > tls-containerized.crt

km get secret -n ${PROJECT_ID} tls-containerized-signed \
  -o jsonpath='{.data.tls\.key}' \
  | base64 -d > tls-containerized.key

kk create secret tls tls-containerized \
  --namespace load-balancer \
  --key tls-containerized.key \
  --cert tls-containerized.crt

kk create secret tls tls-containerized \
  --namespace hello-app \
  --key tls-containerized.key \
  --cert tls-containerized.crt

km get secret -n ${PROJECT_ID} tls-vm-signed \
  -o jsonpath='{.data.tls\.crt}' \
  | base64 -d > tls-vm.crt

km get secret -n ${PROJECT_ID} tls-vm-signed \
  -o jsonpath='{.data.tls\.key}' \
  | base64 -d > tls-vm.key

kk create secret tls tls-vm \
  --namespace load-balancer \
  --key tls-vm.key \
  --cert tls-vm.crt

kk create secret tls tls-vm \
  --namespace vm-app \
  --key tls-vm.key \
  --cert tls-vm.crt

Die neuen Secrets werden automatisch abgerufen und von Load-Balancern aktualisiert.

Clientvertrauen konfigurieren

Um die Einrichtung zu prüfen, müssen Sie Ihrer Client-VM mitteilen, dass sie Ihrer neuen Stammzertifizierungsstelle vertrauen soll.

Extrahieren Sie das Stamm-CA-Zertifikat in eine Datei:

km get secret -n ${PROJECT_ID} my-root-ca-secret \
  -o jsonpath='{.data.tls\.crt}' \
  | base64 -d > my-root-ca.crt

Übertragen Sie das Zertifikat auf Ihre Client-VM. Sie können den Inhalt von „my-root-ca.crt“ kopieren und in eine Datei auf der Client-VM einfügen.

Aktualisieren Sie auf der Client-VM den Trust Store.

Wenn die VM client Ubuntu ist:

sudo cp my-root-ca.crt /usr/local/share/ca-certificates/
sudo chmod 644 /usr/local/share/ca-certificates/my-root-ca.crt
sudo update-ca-certificates

Wenn die VM client Rocky Linux ist:

sudo cp my-root-ca.crt /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust

Zugriff prüfen

Sie können jetzt mit curl ohne das Flag -k auf Ihre Anwendungen zugreifen. Die Verbindung ist vollständig vertrauenswürdig.