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) air-gapped fornisce un bilanciatore del carico di livello 4 (L4) gestito integrato, ma molte applicazioni aziendali richiedono funzionalità avanzate di livello 7 (L7), come il routing basato sull'host, la gestione centralizzata di TLS e la suddivisione complessa del traffico. Storicamente, questa operazione viene eseguita utilizzando l'API Ingress, che ora è considerata una funzionalità fissa nella community 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 standard GDC, i clienti possono instradare senza problemi il traffico L7 agli 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 air-gap.

I componenti chiave della soluzione includono:

Client: un'entità che avvia richieste HTTPS per interagire con le applicazioni.
Cluster standard GDC: 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 carichi di lavoro e al servizio headless per le VM esterne.
Bilanciatore del carico L4 GDC: il bilanciatore del carico L4 integrato che funge da punto di ingresso, distribuendo 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. Il controller Ingress HAProxy verrà utilizzato nella seguente implementazione.
Ingress: risorse Kubernetes standardizzate che definiscono la porta di ascolto fisica (443) e le regole di routing host basate su SNI con terminazione TLS.
Carico di lavoro containerizzato (pod): un deployment Kubernetes standard esposto internamente con un Service Kubernetes normale.
Carico di lavoro basato su VM (esterno): un carico di lavoro 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.
Registro Harbor: un registro di container privati utilizzato per archiviare e pubblicare le immagini proxy e delle applicazioni nell'ambiente air-gapped.

Nel cluster standard, crea tre spazi dei nomi:

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

Prima di iniziare

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

Software necessario: helm, docker, kubectl

Accesso alla CLI e configurazione locale: scarica la CLI gdcloud dalla console GDC e configura l'ambiente in locale:

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 Amministratore cluster e Amministratore cluster standard per gestire le risorse Kubernetes e il ruolo Amministratore istanza Harbor 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 carichi di lavoro, tra cui il controller Ingress HAProxy e le tue applicazioni personalizzate. I passaggi seguenti assicurano che il cluster sia configurato correttamente e accessibile per i deployment successivi.

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

Ottieni 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

Quando il cluster è pronto, l'output dovrebbe mostrare lo stato In esecuzione, come di seguito:

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 rendere 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 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 registro di immagini container con supporto integrato in GDC con air gap. Questa sezione ti guida nei passaggi per integrare un registro Harbor con il 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 nell'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 cluster Kubernetes GDC con air gap. Creerai le risorse Kubernetes Deployment e Service necessarie per eseguire hello-app ed esporla internamente al cluster, preparandola 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

Quindi 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) al di fuori del 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 all'interno e 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 e fai clic su Macchine virtuali.
Fai clic su Crea istanza.
Assegna alla VM il nome vm-workload. Per l'esempio è sufficiente un'immagine con 2 vCPU.
Per l'immagine del disco di avvio, seleziona una distribuzione Ubuntu 22.04, che viene fornita con 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 stabilito la connessione alla console SSH, esegui quanto segue:

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 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:

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 selettori VM-app e indirizzerà 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 nella procedura di creazione di certificati TLS e secret Kubernetes per proteggere la comunicazione per le 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. Questo verrà utilizzato per TLS quando si richiede 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 si richiede 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 acquisisce 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 semplificare 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 Kubernetes esegue il pull sicuro delle immagini da Harbor 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 al 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 connetterà 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 selettori 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}'

Questo sarà necessario per verificare l'accesso alle app. Questo verrà indicato come LOAD_BALANCER_IP.

Crea una VM client

Segui i 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 vengono forniti con 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 e il routing

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

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

Testa l'app containerizzata Kubernetes:

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

Testa l'app 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à senza problemi da terminatore TLS e trasmetterà il traffico alla destinazione.

(Facoltativo) Utilizza certificati pronti per la produzione

Questa sezione spiega come utilizzare il servizio CA GDC con air gap per creare un'autorità di certificazione radice privata, emettere certificati firmati per i carichi di lavoro e aggiornare in modo sicuro il cluster standard GDC con air gap e le VM client.

Questa sezione descrive come utilizzare il servizio CA GDC con air gap CA Service per creare un'autorità di certificazione radice privata ed emettere certificati validi per le applicazioni. Installando questa CA radice sulla VM client, puoi verificare che la terminazione TLS funzioni senza problemi 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 il servizio CA 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

Ottieni le credenziali del server API di gestione:

gdcloud clusters get-credentials ${ORG_NAME}-admin

Crea la CA radice

Creerai una CA 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

Quando 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 che 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, nel cluster standard sono presenti secret autofirmati. Devi eliminarli 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 e aggiornati automaticamente 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.