Google utilizza la tecnologia AI per tradurre i contenuti nella tua lingua preferita. Le traduzioni generate dall'AI potrebbero contenere errori.

Implementazione di riferimento del bilanciamento del carico di livello 7 HAProxy

Google Distributed Cloud (GDC) con air gap fornisce un bilanciatore del carico gestito integrato di livello 4 (L4), ma molte applicazioni aziendali richiedono funzionalità avanzate di livello 7 (L7), come il routing basato sull'host, la gestione TLS centralizzata e la suddivisione del traffico complessa. In passato, questo obiettivo veniva raggiunto utilizzando l'API Ingress, che ora è considerata in fase di blocco delle funzionalità nella community di Kubernetes.

Questa architettura di riferimento fornisce una soluzione di bilanciamento del carico di livello 7 autogestita. Eseguendo il deployment del popolare controller open source HAProxy su un cluster GDC standard, i clienti possono instradare senza problemi il traffico L7 verso ambienti ibridi. Questa architettura utilizza la terminazione TLS (HTTPRoute) per instradare il traffico in base all'indicazione del nome del server (SNI) sia ai pod containerizzati integrati sia alle applicazioni ospitate su macchine virtuali esterne.

Architettura

Diagramma dell'architettura per il bilanciamento del carico di livello 7 di HAProxy su GDC con air gap.

I componenti chiave della soluzione includono:

Client: un'entità che avvia richieste HTTPS per interagire con le applicazioni.
Cluster GDC standard: GDC fornisce un modo integrato per creare cluster Kubernetes Vanilla. In questa soluzione, il cluster ospiterà il bilanciatore del carico L7 e i relativi controller, insieme ai workload e al servizio headless per le VM esterne
Bilanciatore del carico GDC L4: il bilanciatore del carico L4 integrato funge da punto di ingresso e distribuisce il traffico TCP/443 direttamente ai pod Kubernetes che eseguono i controller.
Controller Ingress: operatori HAProxy in esecuzione nel cluster standard. Monitorano le risorse Ingress e aggiornano dinamicamente i proxy sottostanti. Nella seguente implementazione verrà utilizzato il controller Ingress HAProxy
Ingress: risorse Kubernetes standardizzate che definiscono la porta di ascolto fisica (443) e le regole di instradamento degli host basate su SNI con terminazione TLS.
Workload containerizzato (pod): un deployment Kubernetes standard esposto internamente con un Service Kubernetes standard.
Workload basato su VM (esterno): un workload ospitato su una VM esterna nella rete del progetto, esposto al proxy utilizzando un Service Kubernetes headless e un endpoint personalizzato contenente l'IP diretto della VM.
Harbor Registry: un Container Registry privato utilizzato per archiviare ed erogare le immagini del proxy e dell'applicazione nell'ambiente con air gap.

Nel cluster standard, crei tre spazi dei nomi:

Lo spazio dei nomi load-balancer ospita il controller Ingress HAProxy e il workload del bilanciatore del carico HAProxy:
Lo spazio dei nomi hello-app ospita Deployment, Service e Ingress per il workload del container demo:
Lo spazio dei nomi vm-app ospita un servizio headless che espone l'IP esterno della VM, un EndpointSlice che punta all'IP esterno e un Ingress:

Prima di iniziare

Prima di eseguire il deployment di questa soluzione, assicurati di soddisfare i seguenti prerequisiti:

Software necessario: helm, docker, kubectl

Accesso tramite interfaccia a riga di comando e configurazione locale: scarica l'interfaccia a riga di comando gdcloud dalla console GDC e configura l'ambiente localmente:

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

Configurazione del progetto: crea un progetto nel tuo ambiente GDC con air gap per contenere le risorse:
```
gdcloud projects create $PROJECT_ID
```

Ruoli IAM: concedi al tuo utente i ruoli Cluster Admin e Standard Cluster Admin per gestire le risorse Kubernetes e il ruolo Harbor Instance Admin per eseguire il push delle immagini:

# 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

crea un cluster standard

Questa sezione ti guida nella procedura di configurazione di un cluster Kubernetes standard all'interno del tuo ambiente GDC con air gap. Un cluster standard fornisce una base flessibile e solida per il deployment di vari workload, tra cui il controller Ingress HAProxy e le tue applicazioni personalizzate. I passaggi seguenti garantiranno che il cluster sia configurato correttamente e accessibile per i deployment successivi.

Identifica i tipi di immagini delle macchine virtuali disponibili eseguendo:
```
gdcloud compute machine-types list
```
Seleziona un tipo di macchina appropriato per i nodi worker del cluster. Per questo tutorial, è consigliato un tipo di macchina con almeno 4 vCPU.
```
export MACHINE_TYPE="MACHINE_TYPE"
```

Recupera il kubeconfig del server API di gestione e imposta un alias:

export CLUSTER_NAME="CLUSTER_NAME"

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

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

Crea un cluster standard con due nodi worker:

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

Per maggiori dettagli sulle opzioni disponibili, consulta la documentazione.

La creazione di un cluster standard può richiedere fino a 60 minuti. Per controllare lo stato, utilizza il seguente comando:

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

Una volta che il cluster è pronto, l'output dovrebbe mostrare lo stato In esecuzione, come questo:

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

Quando il cluster è pronto, recupera le relative credenziali:

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

Crea un alias per mantenere i comandi kubectl più concisi nel resto di questa guida. Questo alias verrà utilizzato per interagire con il cluster standard:
```
alias kk="kubectl --kubeconfig kubeconfig-${CLUSTER_NAME}.yaml"
```
Crea gli spazi dei nomi per il controller, l'app containerizzata demo "hello-app" e l'app demo basata su VM:
```
kk create namespace load-balancer
kk create namespace hello-app
kk create namespace vm-app
```

Crea e integra il registro Harbor

Harbor è un registry di immagini container con supporto integrato in GDC con air gap. Questa sezione illustra i passaggi per integrare un registro Harbor con il tuo cluster standard, inclusa la configurazione di credenziali e secret per consentire il pull e il push sicuri delle immagini.

Crea un'istanza Harbor nel tuo progetto.
Crea un progetto Harbor nella tua istanza Harbor.

Imposta le variabili di ambiente:

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"

Accedi all'istanza Harbor utilizzando un account robot:

docker --config=./docker login ${HARBOR_INSTANCE_URL}

Crea i secret nel cluster standard:

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

Esegui il deployment dell'app containerizzata demo

Questa sezione descrive in dettaglio il deployment di un'applicazione containerizzata demo (hello-app) all'interno del tuo cluster Kubernetes GDC con air gap. Creerai le risorse di deployment e servizio Kubernetes necessarie per eseguire hello-app ed esporlo internamente al cluster, preparandolo per l'accesso tramite il bilanciatore del carico L7.

Carica un'immagine di esempio per l'app containerizzata demo in Harbor:

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

Esegui il deployment del seguente manifest nel cluster Standard:

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

Poi verifica che il deployment e il servizio siano presenti

kk get svc,deploy -n hello-app

Esegui il deployment dell'app demo in una VM

Questa sezione descrive in dettaglio il deployment di un'applicazione demo all'interno di una macchina virtuale (VM) esterna al cluster Kubernetes. Configurando un server HTTP su una VM, simulerai un'applicazione esterna che il bilanciatore del carico può esporre, dimostrando la sua capacità di gestire il traffico verso le risorse sia all'interno che all'esterno del cluster.

Innanzitutto, crea una VM per l'app demo:

Apri la console GDC nel browser web.
Seleziona lo stesso progetto in cui hai creato il cluster Kubernetes standard.
Apri il menu, quindi fai clic su Macchine virtuali.
Fai clic su Crea istanza.
Assegna alla VM il nome vm-workload. Un'immagine con 2 vCPU è sufficiente per l'esempio.
Per l'immagine disco di avvio, seleziona una distribuzione Ubuntu 22.04, che include Python preinstallato.
Fai clic su Crea.
Attendi qualche minuto finché la VM non è pronta.
Stabilisci una connessione SSH alla VM:
1. Nella console GDC, fai clic sulla VM.
2. Fai clic su Connetti con SSH.

Dopo aver eseguito la connessione alla console SSH, esegui questo comando:

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

Per instradare il traffico a una VM, crea un servizio headless (senza selettori). Questo indirizzo verrà mappato manualmente all'indirizzo IP interno della VM utilizzando una risorsa EndpointSlice.

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

Ottieni l'indirizzo IP della VM vm-workload eseguendo questo comando:

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

L'output sarà l'indirizzo IP della VM necessario per configurare la risorsa EndpointSlice.

Crea la risorsa EndpointSlice che si connetterà al servizio senza selettore VM-app e indirizza l'IP della VM a cui deve essere instradato il traffico.

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

Crea certificati autofirmati

Questa sezione ti guida nel processo di creazione di certificati TLS e secret Kubernetes per proteggere la comunicazione per le tue applicazioni basate su container e VM. Questa guida utilizza certificati autofirmati per comodità, ma negli ambienti di produzione devi utilizzare certificati di livello di produzione, come descritto in (Facoltativo) Utilizza certificati pronti per la produzione. Scegli nomi di dominio di esempio arbitrari per queste app. Stabilendo connessioni sicure, garantisci l'integrità e la riservatezza dei dati per i client che accedono alla tua applicazione tramite il controller Ingress HAProxy.

Per l'app containerizzata, creiamo un certificato autofirmato e lo salviamo come secret nello spazio dei nomi del bilanciatore del carico. Verrà utilizzato per TLS quando viene richiesto k8s-app.example.com

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

Per l'app VM, viene emesso e salvato un certificato autofirmato simile. Questo verrà utilizzato per TLS quando viene richiesto vm-app.example.com

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

Esegui il deployment di HAProxy

Installa il controller Ingress HAProxy e il bilanciatore del carico L4

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"}'

Il controller Ingress HAProxy ottiene un indirizzo IP virtuale univoco per l'accesso client utilizzando un servizio di tipo LoadBalancer. Questo servizio configura un bilanciatore del carico di livello 4 completamente gestito. Per semplicità, in questa guida viene creato un bilanciatore del carico interno impostando l'annotazione load-balancer-type su internal. Se ometti questa annotazione, verrà creato un bilanciatore del carico esterno. Il deployment di Kubernetes esegue il pull delle immagini da Harbor in modo sicuro utilizzando il secret fornito (${IMAGE_PULL_SECRET_NAME}), che contiene le credenziali dell'account robot di Harbor.

Convalida l'installazione del controller Ingress HAProxy

Verifica che i pod del controller Ingress HAProxy siano in esecuzione e pronti:

kk get pods -n load-balancer

L'output dovrebbe essere simile all'esempio seguente:

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

Verifica che il servizio del controller Ingress HAProxy sia stato creato e configurato:

kk get services -n load-balancer

L'output è simile al seguente:

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

Definisci le risorse Ingress per le app demo

Crea la risorsa Ingress che collegherà HAProxy al servizio dell'app containerizzata

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

Crea la risorsa Ingress che si connetterà al servizio senza selettore VM-app e indirizzerà l'IP della VM a cui deve essere instradato il traffico.

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

Recupera l'indirizzo IP del bilanciatore del carico

Esegui il comando per ottenere l'indirizzo IP del bilanciatore del carico.

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

Queste informazioni saranno necessarie per verificare l'accesso alle app. Questo verrà chiamato LOAD_BALANCER_IP.

Crea una VM client

Segui questi passaggi per creare una VM client:

Apri la console GDC nel browser web.
Apri il menu e fai clic su Macchine virtuali.
Fai clic su Crea istanza.
Crea una VM denominata client, seleziona un tipo di macchina di piccole dimensioni e seleziona Rocky Linux o Ubuntu, che hanno curl preinstallato.
Fai clic su Crea.
Attendi qualche minuto finché la VM non è pronta.
Quando la VM è pronta, stabilisci una connessione SSH con la VM:
1. Nella console GDC, fai clic sulla VM.
2. Fai clic su Connetti con SSH.

Verifica l'accesso verificato e il routing

Per testare il routing, esegui i comandi curl dalla VM client. Puoi connetterti a entrambe le applicazioni utilizzando i relativi nomi host definiti con l'indirizzo IP del bilanciatore del carico.

Se passi il flag --resolve in curl, puoi forzare la risoluzione dei nomi di dominio all'IP del bilanciatore del carico L4 di GDC con air gap. Tieni presente che passiamo il flag -k per considerare attendibili i certificati autofirmati.

Testa l'app containerizzata di Kubernetes:

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

Testa l'app della VM esterna:

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

Se configurato correttamente, il controller Ingress fungerà perfettamente da terminatore TLS e trasmetterà il traffico alla destinazione.

(Facoltativo) Utilizza certificati pronti per la produzione

Questa sezione spiega come utilizzare il servizio CA di GDC air-gapped per creare un'autorità di certificazione (CA) radice privata, emettere certificati firmati per i tuoi workload e aggiornare in modo sicuro il cluster standard GDC air-gapped e le VM client.

Questa sezione descrive come utilizzare il servizio CA GDC con air gap per creare un'autorità di certificazione radice (CA) privata ed emettere certificati validi per le tue applicazioni. Installando questa CA radice sulla VM client, puoi verificare che la terminazione TLS funzioni perfettamente con i certificati attendibili, senza dover ignorare gli avvisi SSL (ad esempio, utilizzando curl -k).

Concedi le autorizzazioni necessarie e ottieni le credenziali

Per gestire CA Service ed emettere certificati, l'utente deve disporre dei ruoli IAM appropriati nel progetto.

Concedi i ruoli certificate-authority-service-admin e certificate-requester:

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

Recupera le credenziali del server API di gestione:

gdcloud clusters get-credentials ${ORG_NAME}-admin

Crea la CA radice

Creerai un'autorità di certificazione nel server API di gestione all'interno dello spazio dei nomi del progetto.

Applica la risorsa CertificateAuthority:

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'

Emetti ed esegui il deployment dei certificati

Una volta che la CA è pronta, richiederai i certificati sia per l'app containerizzata sia per l'app basata su VM. Queste richieste vengono eseguite nel server API di gestione e le chiavi risultanti devono essere spostate nel cluster standard.

Crea richieste per entrambi i domini:

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

Attendi qualche istante affinché i certificati vengano emessi. Puoi verificare che siano pronti quando la condizione Ready è True:

km get certificaterequests -n ${PROJECT_ID}

Aggiorna il cluster standard

Se hai seguito le sezioni precedenti di questa guida, hai secret autofirmati nel tuo cluster standard. Devi eliminarle prima di creare le nuove versioni firmate:

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

Ora estrai i certificati firmati dal server API di gestione e crea i nuovi secret nel cluster standard.

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

I nuovi secret verranno ottenuti automaticamente e aggiornati dai bilanciatori del carico.

Configura l'attendibilità del client

Per verificare la configurazione, devi indicare alla VM client di considerare attendibile la nuova CA radice.

Estrai il certificato CA radice in un file:

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

Trasferisci il certificato alla VM client. Puoi copiare i contenuti di my-root-ca.crt e incollarli in un file sulla VM client.

Sulla VM client, aggiorna l'archivio di attendibilità.

Se la VM client è Ubuntu:

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

Se la VM client è Rocky Linux:

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

Verifica l'accesso

Ora puoi accedere alle tue applicazioni utilizzando curl senza il flag -k. La connessione sarà completamente attendibile.

Testa l'app containerizzata k8s:

curl -v --resolve k8s-app.example.com:443:LOAD_BALANDER_IP https://k8s-app.example.com

Testa l'app VM:

curl -v --resolve vm.example.com:443:LOAD_BALANDER_IP https://vm-app.example.com

Se l'operazione va a buon fine, vedrai immediatamente l'output dell'applicazione senza avvisi relativi ai certificati SSL.