Attivare funzionalità facoltative su un control plane in-cluster

Questa pagina descrive come attivare le funzionalità facoltative su Cloud Service Mesh con un control plane in-cluster.

Quando installi Cloud Service Mesh nel cluster, le funzionalità abilitate per impostazione predefinita variano in base alla piattaforma. Puoi sostituire la configurazione predefinita e attivare una funzionalità facoltativa includendo un file overlay quando installi (o esegui l'upgrade) di Cloud Service Mesh. Un file di overlay è un file YAML contenente una risorsa personalizzata (CR) IstioOperator che utilizzi per configurare il control plane. Specifica una funzionalità per file di overlay. Puoi aggiungere altre sovrapposizioni e ogni file di sovrapposizione sostituisce la configurazione dei livelli precedenti.

Attenzione: l'utilizzo di asmcli install sovrascrive la configurazione esistente del control plane. Quando attivi le funzionalità facoltative per un'installazione esistente, assicurati di specificare tutti i file che vuoi conservare nella configurazione originale, nonché i file di overlay per le funzionalità che vuoi attivare. Ti consigliamo di archiviare i file di overlay che utilizzi per l'installazione nel controllo del codice sorgente in modo da poter applicare le stesse configurazioni al control plane con gli upgrade o quando abiliti funzionalità opzionali aggiuntive. In questo modo, non si verificano tempi di inattività quando vengono attivate le funzionalità facoltative.

Informazioni sui file di overlay

I file di overlay in questa pagina si trovano nel pacchetto anthos-service-mesh in GitHub. Questi file contengono personalizzazioni comuni della configurazione predefinita. Puoi utilizzare questi file così come sono o apportare ulteriori modifiche in base alle tue esigenze.

Quando installi Cloud Service Mesh utilizzando lo script asmcli, puoi specificare uno o più file di overlay con le opzioni --option o --custom_overlay. Se non devi apportare modifiche ai file nel repository anthos-service-mesh, puoi utilizzare --option e lo script recupera il file da GitHub. In caso contrario, puoi apportare modifiche al file di overlay e quindi utilizzare l'opzione --custom_overlay per passarlo a asmcli.

Importante: non specificare più di un CR IstioOperator in un file overlay perché istioctl install applica solo il primo CR che trova nel file.

Non includere più CR in un unico file overlay	Crea file di sovraimpressione separati per ogni risposta predefinita

Come attivare le funzionalità facoltative

Gli esempi seguenti sono semplificati per mostrare solo l'utilizzo delle overlay personalizzate per attivare le funzionalità facoltative. Sostituisci OTHER_FLAGS con i flag di installazione obbligatori.

Importante: l'ordine dei file nella riga di comando è importante. Assicurati di specificare prima la configurazione richiesta per le funzionalità predefinite e poi i file di overlay.

Il comando asmcli install offre due modi per attivare una funzionalità facoltativa. Il metodo che utilizzi dipende dal fatto che tu debba apportare modifiche al file di sovrapposizione.

• Utilizza --option quando non devi apportare modifiche al file overlay. Con --option, asmcli recupera il file dal repository GitHub per te, quindi devi avere una connessione a internet.

  ./asmcli install \
    OTHER_FLAGS \
    --option OPTION_NAME
  

  Sostituisci OPTION_NAME con l'opzione che vuoi attivare. Assicurati di omettere l'estensione .yaml e di includere solo il nome del file di overlay, ad esempio iap-operator e attached-cluster. Per un elenco di opzioni, consulta il pacchetto anthos-service-mesh.

• Utilizza --custom_overlay quando devi personalizzare il file di overlay.

  ./asmcli install \
    OTHER_FLAGS \
    --custom_overlay PATH_TO_FILE
  

  Sostituisci PATH_TO_FILE con il percorso del file di overlay che vuoi utilizzare.

YAML per le funzionalità facoltative

Le sezioni seguenti forniscono il codice YAML per abilitare le funzionalità facoltative e supportate.

Modalità mTLS STRICT

La configurazione global.mtls.enabled è stata rimossa dal IstioOperator CR per evitare problemi con gli upgrade e fornire un'installazione più flessibile. Per attivare mTLS STRICT, configura invece un criterio di autenticazione peer.

Immagine proxy Distroless

Come best practice, devi limitare i contenuti di un runtime del container solo ai pacchetti necessari. Questo approccio migliora la sicurezza e il rapporto segnale/rumore degli scanner di vulnerabilità ed esposizioni comuni (CVE). Istio fornisce immagini proxy basate su immagini di base distroless.

La seguente configurazione abilita le immagini distroless per l'intera rete mesh di servizi. Una modifica del tipo di immagine richiede il riavvio e la reiniezione di ogni pod per diventare effettiva.

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    defaultConfig:
      image:
        imageType: distroless

L'immagine distroless non contiene altri file binari oltre al proxy. Pertanto, non è possibile exec una shell o utilizzare curl, ping o altre utilità di debug all'interno del contenitore.

Se esegui un comando curl, viene visualizzato il seguente errore:

error: Internal error occurred: error executing command in container: failed to exec in container: failed to start exec  "<container-id>"
OCI runtime exec failed: exec failed: unable to start container process: exec: "curl": executable file not found in $PATH: unknown

Se esegui un comando shell, viene visualizzato il seguente errore:

error: Internal error occurred: error executing command in container: failed to exec in container: failed to start exec "<container-id>"
OCI runtime exec failed: exec failed: container_linux.go:380: starting container process caused: exec: "sh": executable file not found in $PATH: unknown

Se hai bisogno di accedere a questi strumenti per pod specifici, puoi ignorare imageType utilizzando la seguente annotazione del pod.

sidecar.istio.io/proxyImageType: debug

Dopo aver modificato il tipo di immagine di un deployment tramite l'annotazione, il deployment deve essere riavviato.

kubectl rollout restart deployment -n NAMESPACE DEPLOYMENT_NAME

Per la maggior parte dei tipi di debug del proxy, deve essere utilizzato istioctl proxy-cmd, che non richiede un'immagine di base di debug.

Utilizzare un overlay personalizzato per il registro personalizzato

Puoi utilizzare un overlay personalizzato per i registri personalizzati, ad esempio se devi installare Cloud Service Mesh da un registro contenitori personalizzato. Ad esempio:

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  hub: {private_registry_url}

Di seguito è riportato un elenco di immagini per Cloud Service Mesh che devi eseguire il mirroring nel registro container personalizzato:

• Install-cni - gke.gcr.io/asm/install-cni:1.23.6-asm.11
• Managed Data Plane - gke.gcr.io/asm/mdp:1.23.6-asm.11
• Pilot - gke.gcr.io/asm/pilot:1.23.6-asm.11
• Proxyv2 - gke.gcr.io/asm/proxyv2:1.23.6-asm.11

Nota: se utilizzi un servizio canonico, devi anche eseguire il mirroring dei registri dei container personalizzati gcr.io/kubebuilder/kube-rbac-proxy:v0.13.1 e gke.gcr.io/asm/canonical-service-controller:1.10.3-asm.16.

Aggiungere immagini a un registro privato

Per eseguire il push delle immagini di Cloud Service Mesh in un registro privato, completa i seguenti passaggi.

Nota: utilizza un client da cui puoi eseguire il pull da gcr.io e il push nel tuo registro privato.

1. Estrai le immagini di Cloud Service Mesh:

   docker pull gke.gcr.io/asm/install-cni:1.23.6-asm.11
   docker pull gke.gcr.io/asm/mdp:1.23.6-asm.11
   docker pull gke.gcr.io/asm/pilot:1.23.6-asm.11
   docker pull gke.gcr.io/asm/proxyv2:1.23.6-asm.11
   

2. Crea una variabile per l'URL del tuo registro privato:

   export PRIVATE_REGISTRY_URL=PRIVATE_REGISTRY_URL
   

   Sostituisci PRIVATE_REGISTRY_URL con l'URL del tuo registro privato.
3. Tagga le immagini con l'URL del tuo registro privato:

   docker tag gke.gcr.io/asm/install-cni:1.23.6-asm.11 \
    ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/install-cni:1.23.6-asm.11
   docker tag gke.gcr.io/asm/mdp:1.23.6-asm.11 \
    ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/mdp:1.23.6-asm.11
   docker tag gke.gcr.io/asm/pilot:1.23.6-asm.11 \
    ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/pilot:1.23.6-asm.11
   docker tag gke.gcr.io/asm/proxyv2:1.23.6-asm.11 \
    ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/proxyv2:1.23.6-asm.11
   

4. Esegui il push delle immagini taggate nel tuo registro privato:

   docker push ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/install-cni:1.23.6-asm.11
   docker push ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/mdp:1.23.6-asm.11
   docker push ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/pilot:1.23.6-asm.11
   docker push ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/proxyv2:1.23.6-asm.11
   

5. (Facoltativo) Se utilizzi un servizio canonico, aggiungi le immagini del servizio canonico al tuo registro privato.
   1. Estrai le immagini del servizio canonico di Cloud Service Mesh:

              docker pull gcr.io/kubebuilder/kube-rbac-proxy:v0.13.1
              docker pull gke.gcr.io/asm/canonical-service-controller:1.10.3-asm.16
              

   2. Tagga le immagini con l'URL del tuo registro privato:

              docker tag gcr.io/kubebuilder/kube-rbac-proxy:v0.13.1 \
              ${PRIVATE_REGISTRY_URL}/gcr.io/kubebuilder/kube-rbac-proxy:v0.13.1
              docker tag gke.gcr.io/asm/canonical-service-controller:1.10.3-asm.16 \
              ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/canonical-service-controller:1.10.3-asm.16
              

   3. Esegui il push delle immagini taggate nel tuo registro privato:

              docker push ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/kube-rbac-proxy:v0.13.1
              docker push ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/canonical-service-controller:1.10.3-asm.16
              

Se riesci a estrarre le immagini taggate dal tuo registro privato, la procedura è andata a buon fine.

Aumentare la durata del drenaggio dell'arresto

Per impostazione predefinita, Envoy attende cinque secondi (5s) per il completamento delle connessioni esistenti quando un pod termina.

Il pod terminationGracePeriodSeconds deve essere maggiore del valore terminationDrainDuration.

Per saperne di più, vedi Opzioni mesh globale.

---
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    defaultConfig:
      terminationDrainDuration: 30s

Abilita i log di accesso

---
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    accessLogFile: "/dev/stdout"

Per maggiori informazioni, vedi Attivare la registrazione degli accessi di Envoy.

Cloud Trace

Cloud Trace è disponibile con le installazioni di Cloud Service Mesh sulle seguenti piattaforme:

• GKE su Google Cloud
• Cluster GKE Enterprise on-premise se esegui l'installazione con l'autorità di certificazione Cloud Service Mesh

---
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    enableTracing: true
  values:
    global:
      proxy:
        tracer: stackdriver

Per saperne di più, vedi Accesso alle tracce.

In uscita tramite gateway in uscita

Ti consigliamo di installare un gateway inserito come descritto in Installazione e upgrade dei gateway.

Container Network Interface di Istio

Il modo in cui abiliti l'interfaccia di rete dei container (CNI) Istio dipende dall'ambiente in cui è installato Cloud Service Mesh.

1. Abilita un criterio di rete.

2. Scegli il file di overlay corrispondente alla tua piattaforma.

Abilita CNI su GKE

---
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  components:
    cni:
      enabled: true
      namespace: kube-system
  values:
    cni:
      cniBinDir: /home/kubernetes/bin
      excludeNamespaces:
        - istio-system
        - kube-system

Abilita CNI on-premise

---
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  components:
    cni:
      enabled: true
      namespace: kube-system
  values:
    cni:
      cniBinDir: /opt/cni/bin
      excludeNamespaces:
        - istio-system
        - kube-system
        - gke-system

Attiva i log sul traffico per off-Google Cloud

L'installazione di Cloud Service Mesh con Istio CA al di fuori di Google Cloud genera report sulle metriche in Prometheus per impostazione predefinita. Utilizza questa opzione per attivare la generazione di report dei log di traffico o di Prometheus e Stackdriver, in modo da poter utilizzare i dashboard di Cloud Service Mesh.

Solo Stackdriver

---
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  values:
    telemetry:
      enabled: true
      v2:
        enabled: true
        prometheus:
          enabled: false
        stackdriver:
          enabled: true

Stackdriver e Prometheus

---
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  values:
    telemetry:
      enabled: true
      v2:
        enabled: true
        prometheus:
          enabled: true
        stackdriver:
          enabled: true

Abilita un bilanciatore del carico interno

Ti consigliamo di installare un gateway inserito come descritto in Installare e aggiornare i gateway per configurare un bilanciatore del carico interno su GKE. Quando configuri il servizio gateway, includi l'annotazione: networking.gke.io/load-balancer-type: "Internal"

Gestione dei certificati esterni sul gateway in entrata

Per informazioni sull'attivazione della gestione dei certificati esterni sul gateway ingress utilizzando Envoy SDS, consulta Gateway sicuri.