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

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

Google Distributed Cloud (GDC) mit Air Gap bietet einen integrierten verwalteten Layer-4-Load-Balancer (L4), aber viele Unternehmensanwendungen erfordern erweiterte Layer-7-Funktionen (L7) wie hostbasiertes Routing, zentralisierte TLS-Verwaltung und komplexe Trafficaufteilung. In der Vergangenheit wurde dies mit der Ingress API erreicht, die in der Kubernetes-Community jetzt als Feature-Frozen gilt.

Diese Referenzarchitektur bietet eine selbstverwaltete Layer-7-Load-Balancing-Lösung. Durch die Bereitstellung des beliebten Open-Source-Controllers NGINX Gateway Fabric auf einem GDC Standard-Cluster können Kunden L7-Traffic nahtlos an Hybridumgebungen weiterleiten. In dieser Architektur wird die TLS-Terminierung (HTTPRoute) verwendet, 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 NGINX-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 zur Interaktion mit den Anwendungen initiiert.
GDC-Standardcluster: GDC bietet eine integrierte Möglichkeit, Kubernetes-Vanilla-Cluster zu erstellen. 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 Gateway-Controller ausgeführt werden.
Gateway-Controller: NGINX-Operatoren, die im Standard-Cluster ausgeführt werden. Sie überwachen Gateway API-Ressourcen (wie Gateway und HTTPRoute) und aktualisieren die zugrunde liegenden Proxys dynamisch. Für die Lösung wird Nginx Gateway Fabric verwendet.
Gateway (mit HTTPRoute): Standardisierte Kubernetes-Ressourcen, die den physischen Listening-Port (443) und die SNI-basierten Host-Routingregeln mit TLS-Terminierung definieren.
Containerisierte Arbeitslast (Pods): Ein Standard-Kubernetes-Deployment, das 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 über einen monitorlosen Kubernetes-Service und einen benutzerdefinierten Endpunkt mit der direkten IP-Adresse der VM für den Proxy freigegeben 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 Standard-Cluster erstellen Sie vier Namespaces:

Der Namespace nginx-gateway, der die Nginx Gateway Fabric-Ressourcen hostet:
Der Namespace load-balancer, der die Gateway-Ressourcen hostet:
Der Namespace vm-app hostet die externe VM-IP-Adresse vm-app, einen monitorlosen Dienst, einen EndpointSlice, der auf die externe IP-Adresse verweist, und einen HTTPRoute für den Gateway:
Der Namespace hello-app hostet die Deployment, ein Service, ein HTTPRoute und ein Gateway für die Demo-Containerarbeitslast:

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-Konsole 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 speichern.
```
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-Umgebung mit Air Gap einrichten. Ein Standardcluster bietet eine flexible und robuste Grundlage für die Bereitstellung verschiedener Arbeitslasten, einschließlich des Nginx Gateway Controllers und Ihrer benutzerdefinierten Anwendungen. Mit den folgenden Schritten wird sichergestellt, dass Ihr Cluster richtig konfiguriert und für nachfolgende Bereitstellungen zugänglich ist.

Führen Sie folgenden Befehl aus, um die verfügbaren VM-Image-Typen zu ermitteln:
```
gdcloud compute machine-types list
```
Wählen Sie einen geeigneten Maschinentyp für die Worker-Knoten des Clusters aus. Für diese Anleitung wird ein Maschinentyp mit mindestens 4 vCPUs empfohlen.
```
export MACHINE_TYPE="MACHINE_TYPE"
```

Rufen Sie die kubeconfig-Datei des Verwaltungs-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 in der Ausgabe der Status „Running“ angezeigt werden, etwa so:

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

Wenn der Cluster bereit ist, rufen Sie seine Anmeldedaten ab:

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

Erstellen Sie einen Alias, um die kubectl-Befehle im weiteren Verlauf dieses Leitfadens prägnanter zu gestalten. 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 Sie durch die Schritte zum Einbinden einer Harbor Registry in Ihren Standardcluster geführt. Dazu gehört auch das Konfigurieren 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 in Ihrer Harbor-Instanz ein Harbor-Projekt.

Legen Sie Umgebungsvariablen fest:

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

Melden Sie sich mit einem Roboterkonto bei 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 Demo-Anwendung bereitstellen

In diesem Abschnitt wird die Bereitstellung einer containerisierten Demoanwendung (hello-app) in Ihrem GDC-Kubernetes-Cluster mit Air Gap beschrieben. Sie erstellen die erforderlichen Kubernetes-Deployment- und -Dienstressourcen, um hello-app auszuführen und intern im Cluster verfügbar zu machen, damit der Zugriff über den L7-Load-Balancer möglich ist.

Laden Sie ein Beispielbild für die containerisierte Demo-Anwendung 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 das Deployment und der Dienst vorhanden sind:

kk get svc,deploy -n hello-app

Demo-App auf einer VM bereitstellen

In diesem Abschnitt wird die Bereitstellung einer Demoanwendung auf einer virtuellen Maschine (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 sowohl innerhalb als auch außerhalb des Clusters zu verwalten.

Erstellen Sie zuerst eine VM für die Demo-Anwendung.

Öffnen Sie die GDC-Konsole in Ihrem Webbrowser.
Wählen Sie dasselbe Projekt aus, in dem Sie Ihren Kubernetes-Standardcluster 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. Ein Image mit 2 vCPUs reicht für das Beispiel 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-Konsole auf die VM.
2. Klicken Sie auf Über SSH verbinden.

Führen Sie nach dem Herstellen der Verbindung zur 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 &

Wenn Sie Traffic an eine VM weiterleiten möchten, erstellen Sie einen monitorlosen Dienst (ohne Selektoren). Diese wird mithilfe einer EndpointSlice-Ressource manuell der internen IP-Adresse der VM 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-workload-VM 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 benötigt wird.

Erstellen Sie die Ressource EndpointSlice, die eine Verbindung zum VM-App-Dienst ohne Selektor herstellt und die IP-Adresse der VM adressiert, 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 selbst signierte TLS-Zertifikate für Ihre Anwendungen generieren. In diesem Leitfaden werden der Einfachheit halber selbst signierte Zertifikate verwendet. In Produktionsumgebungen müssen Sie jedoch produktionsreife Zertifikate verwenden, wie unter Optional: Produktionsreife Zertifikate verwenden beschrieben. Diese Zertifikate sind entscheidend für die HTTPS-Beendigung am Nginx-Gateway und sorgen für eine verschlüsselte Kommunikation zwischen Clients und dem Load Balancer für containerisierte und VM-basierte Arbeitslasten.

Erstellen Sie ein Zertifikat für die Containeranwendung:

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

Erstellen Sie ein Zertifikat für die VM-Anwendung:

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

NGINX bereitstellen

In diesem Abschnitt werden die Schritte zum Bereitstellen des Nginx Gateway-Controllers beschrieben, einschließlich der Installation der benutzerdefinierten Gateway API-Ressourcendefinitionen (CRDs), der Einrichtung von Nginx Gateway Fabric mit Helm und der Überprüfung der Installation in Ihrem Standardcluster. Dadurch wird die Infrastruktur für erweitertes Layer-7-Routing vorbereitet.

Gateway API-CRDs installieren

Für die Gateway API müssen benutzerdefinierte Ressourcendefinitionen (CRDs) im Cluster installiert sein, bevor der Controller bereitgestellt wird. Wir verwenden die offiziellen experimentellen benutzerdefinierten Ressourcendefinitionen (CRD) aus dem Gateway API-Projekt (für diesen Leitfaden wird Version 1.2.0 verwendet).

Installieren Sie die experimentellen CRDs:

kk apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.2.0/experimental-install.yaml

Prüfen Sie mit kk get crd gateways.gateway.networking.k8s.io, ob die CRDs erfolgreich installiert wurden.

NGINX Gateway Fabric installieren

Stellen Sie den NGINX Gateway Fabric-Controller mit Helm bereit. Dieser Controller überwacht Gateway API-Ressourcen und konfiguriert NGINX für die Verarbeitung des Traffics.

Legen Sie das NGINX-Image-Tag fest:

helm template nfg oci://ghcr.io/nginx/charts/nginx-gateway-fabric | grep "image:" # get the tag of the nginx-gateway-fabric (in following case 2.4.2)

export NGINX_TAG="2.4.2"

Rufen Sie die NGINX Gateway Fabric- und NGINX-Images ab und übertragen Sie sie per Push in Ihre Harbor-Registry:

docker pull ghcr.io/nginx/nginx-gateway-fabric:${NGINX_TAG}
docker tag ghcr.io/nginx/nginx-gateway-fabric:${NGINX_TAG} \
  ${HARBOR_INSTANCE_URL}/${HARBOR_PROJECT}/nginx-gateway-fabric:${NGINX_TAG}
docker --config=./docker push \
  ${HARBOR_INSTANCE_URL}/${HARBOR_PROJECT}/nginx-gateway-fabric:${NGINX_TAG}

docker pull nginx:1.27.3
docker tag nginx:1.27.3 \
  ${HARBOR_INSTANCE_URL}/${HARBOR_PROJECT}/nginx:1.27.3
docker --config=./docker push \
  ${HARBOR_INSTANCE_URL}/${HARBOR_PROJECT}/nginx:1.27.3

Erstellen Sie den Namespace nginx-gateway und fügen Sie das Harbor-Image-Pull-Secret hinzu:

kk create namespace nginx-gateway

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

Stellen Sie NGINX Gateway Fabric mit Helm bereit und verweisen Sie auf die Images in Ihrer Harbor-Registry:

KUBECONFIG=kubeconfig-${CLUSTER_NAME}.yaml helm upgrade --install ngf \
  oci://ghcr.io/nginx/charts/nginx-gateway-fabric \
  --create-namespace -n nginx-gateway \
  --set nginxGateway.image.tag="${NGINX_TAG}" \
  --set nginxGateway.image.repository="${HARBOR_INSTANCE_URL}/${HARBOR_PROJECT}/nginx-gateway-fabric" \
  --set nginx.image.repository="${HARBOR_INSTANCE_URL}/${HARBOR_PROJECT}/nginx" \
  --set nginxGateway.serviceAccount.imagePullSecret="${IMAGE_PULL_SECRET_NAME}" \
  --set nginx.imagePullSecret="${IMAGE_PULL_SECRET_NAME}"

Das Kubernetes-Deployment ruft Images sicher aus Harbor ab. Dazu wird das bereitgestellte Secret (${IMAGE_PULL_SECRET_NAME}) verwendet, das die Anmeldedaten des Harbor-Robot-Kontos enthält.

Prüfen Sie, ob die GatewayClass-Ressourcen akzeptiert werden:
```
kk get gatewayclass
```
nginx sollte mit ACCEPTED = True aufgeführt sein.

Gateway-Instanz erstellen

Definieren Sie die logische Load-Balancer-Instanz, die an Port 443 überwacht wird. Wir konfigurieren es für den Terminate-Modus. Das bedeutet, dass das Gateway die TLS-Terminierung durchführt und den Traffic entschlüsselt, bevor er weitergeleitet wird.

Erstellen Sie gateway.yaml und wenden Sie es an:

cat << EOF > gateway.yaml 
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: my-gateway
  namespace: load-balancer
spec:
  gatewayClassName: nginx
  listeners:
  - name: https-k8s-workload
    hostname: "k8s-app.example.com"
    port: 443
    protocol: HTTPS
    allowedRoutes: 
      namespaces: 
        from: All
    tls:
      mode: Terminate
      certificateRefs:
      - kind: Secret
        name: tls-containerized 
  - name: https-vm-workload
    hostname: "vm-app.example.com"
    port: 443
    protocol: HTTPS
    allowedRoutes: 
      namespaces: 
        from: All
    tls:
      mode: Terminate
      certificateRefs:
      - kind: Secret
        name: tls-vm 
EOF

kk apply -f gateway.yaml

Prüfen Sie, ob das Gateway erfolgreich bereitgestellt wurde. Dazu prüfen Sie, ob PROGRAMMED den Wert True hat:

kk get gateway my-gateway --n load-balancer

Prüfen Sie, ob ein verwalteter GDC-L4-Load-Balancer als Dienst zusammen mit dem Gateway bereitgestellt wurde.

kk get services -n load-balancer

Prüfen Sie, ob der Nginx-Dienst erstellt und konfiguriert wurde. Die Ausgabe sollte so aussehen:

NAME               TYPE           CLUSTER-IP      EXTERNAL-IP    PORT(S)         AGE
my-gateway-nginx   LoadBalancer   10.252.19.148   10.200.32.43   443:30649/TCP   45h

L7-Routinglogik (HTTPRoute) definieren

Binden Sie HTTPRoutes an Ihr Gateway, um festzulegen, wie Traffic basierend auf dem angeforderten Hostnamen (SNI) verteilt werden soll.

Erstellen Sie routing.yaml und wenden Sie es an:

cat << EOF > routing.yaml 
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: k8s-http-route
  namespace: hello-app
spec:
  parentRefs:
  - name: my-gateway 
    namespace: load-balancer
  hostnames:
  - "k8s-app.example.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: hello-app 
      namespace: hello-app
      port: 80          
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: vm-http-route
  namespace: vm-app
spec:
  parentRefs:
  - name: my-gateway
    namespace: load-balancer
  hostnames:
  - "vm-app.example.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: vm-app-svc  
      namespace: vm-app
      port: 443       
EOF

kk apply -f routing.yaml

IP-Adresse des Load Balancers abrufen

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

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

Diese wird benötigt, wenn der Zugriff auf die Apps überprüft wird. Diese wird als LOAD_BALANCER_IP bezeichnet.

Client-VM erstellen

Folgen Sie der Anleitung, um eine Client-VM zu erstellen.

Öffnen Sie die GDC-Konsole 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 aus und wählen Sie 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-Konsole auf die VM.
2. Klicken Sie auf Über 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 eine Verbindung zu beiden Anwendungen herstellen, indem Sie die definierten Hostnamen mit der IP-Adresse des Load Balancers verwenden.

Wenn Sie das Flag --resolve in curl übergeben, können Sie erzwingen, dass die Domainnamen in die IP-Adresse des L4-Load-Balancers von GDC mit Air Gap aufgelöst werden. Beachten Sie, dass wir das Flag -k übergeben, um den selbst signierten Zertifikaten zu vertrauen.

Testen Sie die containerisierte Kubernetes-Anwendung:

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

Testen Sie die externe VM-Anwendung:

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

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

Optional: Produktionsreife Zertifikate verwenden

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

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

Erforderliche Berechtigungen gewähren und Anmeldedaten abrufen

Zum Verwalten des CA-Dienstes und zum Ausstellen von Zertifikaten 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
```

Stamm-CA erstellen

Sie erstellen eine Zertifizierungsstelle im 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

Sobald die Zertifizierungsstelle bereit ist, fordern Sie Zertifikate für die containerisierte Anwendung und die VM-basierte Anwendung an. Diese Anfragen erfolgen im 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 einen Moment, bis die Zertifikate ausgestellt wurden. Sie können prüfen, ob sie bereit sind, wenn die Bedingung „Bereit“ auf „Wahr“ festgelegt ist:

km get certificaterequests -n ${PROJECT_ID}

Standardcluster aktualisieren

Wenn Sie die vorherigen Abschnitte dieser Anleitung befolgt haben, haben Sie selbstsignierte 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

Zur Überprüfung der Einrichtung müssen Sie Ihre Client-VM anweisen, Ihrer neuen Stamm-CA zu vertrauen.

Extrahieren Sie das Root-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 den Trust Store auf der Client-VM.

Wenn die client-VM 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 client-VM Rocky Linux ist:

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

Zugriff überprüfen

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