Abilita funzionalità facoltative su un control plane in-cluster

Attenzione: Cloud Service Mesh in-cluster che utilizza il control plane ISTIOD su GKE su Google Cloud è deprecato. Cloud Service Mesh con un control plane in-cluster su Google Distributed Cloud (solo software) continua a essere supportato come descritto in Piattaforme supportate.

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

Quando installi Cloud Service Mesh in-cluster, le funzionalità abilitate per impostazione predefinita variano in base alla piattaforma. Puoi eseguire l'override della configurazione predefinita e attivare una funzionalità facoltativa includendo un file di overlay durante l'installazione (o 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 altri overlay e ogni file di overlay sostituisce la configurazione dei livelli precedenti.

Attenzione: l'utilizzo di asmcli install sovrascrive la configurazione del control plane esistente. Quando attivi funzionalità facoltative in 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à facoltative 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. che contengono personalizzazioni comuni alla configurazione predefinita. Puoi utilizzare questi file così come sono oppure 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 per te. 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 una CR IstioOperator in un file di overlay perché istioctl install applica solo la prima CR che trova nel file.

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

Come attivare le funzionalità facoltative

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

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 dalla necessità di apportare modifiche al file di overlay.

• Utilizza --option quando non devi apportare modifiche al file di 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 dalla CR IstioOperator per evitare problemi con gli upgrade e fornire un'installazione più flessibile. Per attivare mTLS STRICT, configura invece una policy di autenticazione peer.

Immagine proxy distroless

Importante: Google consiglia vivamente di utilizzare immagini proxy distroless negli ambienti di produzione. Le immagini distroless migliorano la sicurezza limitando i contenuti del container ai soli pacchetti necessari, il che riduce la superficie di attacco e minimizza i falsi positivi negli 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'intero Cloud Service Mesh. Per rendere effettiva una modifica del tipo di immagine, è necessario riavviare ogni pod e inserirlo nuovamente.

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 eseguire exec di una shell o utilizzare curl, ping o altre utilità di debug all'interno del container.

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 eseguire l'override di 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, è necessario utilizzare istioctl proxy-cmd, che non richiede un'immagine di base di debug.

Utilizza un overlay personalizzato per il registry personalizzato

Puoi utilizzare un overlay personalizzato per i registry personalizzati, ad esempio se devi installare Cloud Service Mesh da un container registry 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 di cui devi eseguire il mirroring nel container registry personalizzato:

• Install-cni - gke.gcr.io/asm/install-cni:1.30.5-asm.11
• Piano dati gestito - gke.gcr.io/asm/mdp:1.30.5-asm.11
• Pilota - gke.gcr.io/asm/pilot:1.30.5-asm.11
• Proxyv2 - gke.gcr.io/asm/proxyv2:1.30.5-asm.11

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

Aggiungi immagini a un registry privato

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

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

1. Esegui il pull delle immagini Cloud Service Mesh:

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

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

   export PRIVATE_REGISTRY_URL=PRIVATE_REGISTRY_URL
   

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

   docker tag gke.gcr.io/asm/install-cni:1.30.5-asm.11 \
    ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/install-cni:1.30.5-asm.11
   docker tag gke.gcr.io/asm/mdp:1.30.5-asm.11 \
    ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/pilot:1.30.5-asm.11
   docker tag gke.gcr.io/asm/proxyv2:1.30.5-asm.11 \
    ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/proxyv2:1.30.5-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.30.5-asm.11
   docker push ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/pilot:1.30.5-asm.11
   docker push ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/proxyv2:1.30.5-asm.11
   

5. (Facoltativo) Se utilizzi un servizio canonico, aggiungi le immagini del servizio canonico al tuo registry privato.
   1. Esegui il pull delle immagini dei servizi canonici 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}/gcr.io/kubebuilder/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 eseguire il pull delle immagini taggate dal tuo registro privato, la procedura è andata a buon fine.

Aumenta la durata dello svuotamento della terminazione

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

Il pod terminationGracePeriodSeconds deve essere maggiore del valore terminationDrainDuration.

Per saperne di più, consulta 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 saperne di più, consulta Attiva il logging 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 l'installazione viene eseguita 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ù, consulta Accesso alle tracce.

Traffico in uscita tramite gateway in uscita

Ti consigliamo di installare un gateway inserito come descritto in Installa ed esegui l'upgrade dei gateway. L'inserimento, o inserimento automatico, si riferisce all'utilizzo di webhook di mutazione per modificare le specifiche dei pod al momento della creazione. Utilizza l'inserimento per aggiungere la configurazione del proxy sidecar Envoy per i servizi mesh o per configurare il proxy Envoy dei gateway.

Istio Container Network Interface

La modalità di abilitazione dell'interfaccia di rete container (CNI) di Istio dipende dall'ambiente in cui è installato Cloud Service Mesh.

1. Abilita una policy 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 del traffico per off-Google Cloud

L'installazione di Cloud Service Mesh con Istio CA al di fuori di Google Cloud segnala le metriche a Prometheus per impostazione predefinita. Utilizza questa opzione per abilitare i report sui log del traffico o sia Prometheus che Stackdriver, in modo da poter utilizzare le 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 Installa ed esegui l'upgrade dei 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'abilitazione della gestione dei certificati esterni sul gateway In entrata utilizzando Envoy SDS, consulta Gateway sicuri.