Abilitazione delle funzionalità facoltative nel piano di controllo nel cluster

Questa pagina descrive come abilitare le funzionalità facoltative su un piano di controllo nel cluster. Per informazioni sul piano di controllo gestito, consulta Configurare Anthos Service Mesh gestito.

Quando installi Anthos Service Mesh nel 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 Anthos Service Mesh. Un file di overlay è un file YAML contenente una risorsa personalizzata (RP) IstioOperator che utilizzi per configurare il piano di controllo. Specifica una funzionalità per file di overlay. Puoi sovrapporre più overlay e ogni file di overlay sostituisce la configurazione dei livelli precedenti.

Attenzione: l'utilizzo di asmcli install sovrascrive la configurazione del piano di controllo esistente. Quando abiliti 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 tuo piano di controllo con gli upgrade o quando attivi funzionalità facoltative aggiuntive. Ciò garantisce l'assenza di tempi di inattività durante l'abilitazione di funzionalità facoltative.

Informazioni sui file di overlay

I file degli overlay in questa pagina si trovano all'interno del pacchetto anthos-service-mesh in GitHub. Questi file contengono personalizzazioni comuni alla configurazione predefinita. Puoi utilizzare questi file così come sono o apportare ulteriori modifiche in base alle esigenze.

Quando installi Anthos Service Mesh utilizzando lo script asmcli fornito da Google, puoi specificare uno o più file 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 dell'overlay e poi utilizzare l'opzione --custom_overlay per inoltrarlo a asmcli.

Importante: non specificare più di una RP IstioOperator in un file di overlay, poiché istioctl install applica solo la prima RP che trova nel file.

Non includere più RP in un unico file di overlay	Creare file di overlay separati per ogni RP

Come attivare le funzionalità facoltative

I seguenti esempi sono semplificati in modo che vengano visualizzati solo utilizzando gli overlay personalizzati per abilitare 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, dopodiché i file di overlay.

Il comando asmcli install offre due modi per abilitare una funzionalità facoltativa. Il metodo da utilizzare varia a seconda che tu debba o meno apportare modifiche al file dell'overlay.

• Utilizza --option se non devi apportare modifiche al file dell'overlay. Con --option, asmcli recupera automaticamente il file dal repository GitHub, quindi devi disporre di 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 overlay, ad esempio iap-operator e attached-cluster. Per un elenco delle opzioni, consulta il pacchetto anthos-service-mesh.

• Usa --custom_overlay quando devi personalizzare il file dell'overlay.

  ./asmcli install \
    OTHER_FLAGS \
    --custom_overlay PATH_TO_FILE
  

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

YAML per funzionalità facoltative

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

Modalità mTLS STRICT

La configurazione di global.mtls.enabled è stata rimossa dalla risposta predefinita IstioOperator per evitare problemi con gli upgrade e offrire un'installazione più flessibile. Per attivare la tecnologia mTLS di STRICT, configura invece un criterio di autenticazione peer.

Immagine proxy senza distribuzione

Come best practice, dovresti limitare i contenuti del runtime di un 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 senza distribuzione.

La configurazione seguente consente di utilizzare immagini senza distribuzioni per l'intero Anthos Service Mesh. Una modifica del tipo di immagine richiede il riavvio di ogni pod e il reinserimento effettivo.

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 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, vedrai il seguente errore.v

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 dei 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 registro personalizzato

Puoi utilizzare un overlay personalizzato per i registry personalizzati, ad esempio se devi installare Anthos Service Mesh da un registro di container personalizzato. Ad esempio:

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

Di seguito è riportato un elenco di immagini per Anthos Service Mesh di cui devi eseguire il mirroring al Container Registry personalizzato:

• Installa-cni - gke.gcr.io/asm/install-cni:1.23.2-asm.2
• Piano dati gestito - gke.gcr.io/asm/mdp:1.23.2-asm.2
• Progetto pilota - gke.gcr.io/asm/pilot:1.23.2-asm.2
• Proxyv2 - gke.gcr.io/asm/proxyv2:1.23.2-asm.2

Nota: se utilizzi un servizio canonico, devi anche eseguire il mirroring dei registry 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 Anthos Service Mesh in un registro privato, segui questi passaggi.

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

1. Esegui il pull delle immagini Anthos Service Mesh:

   docker pull gke.gcr.io/asm/install-cni:1.23.2-asm.2
   docker pull gke.gcr.io/asm/mdp:1.23.2-asm.2
   docker pull gke.gcr.io/asm/pilot:1.23.2-asm.2
   docker pull gke.gcr.io/asm/proxyv2:1.23.2-asm.2
   

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

   export PRIVATE_REGISTRY_URL=PRIVATE_REGISTRY_URL
   

   Sostituisci PRIVATE_REGISTRY_URL con l'URL del tuo registro privato.
3. Aggiungi l'URL del registro privato alle immagini:

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

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

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

5. (Facoltativo) Se utilizzi un servizio canonico, aggiungi le immagini canoniche del servizio al tuo registro privato.
   1. Esegui il pull delle immagini del servizio canonico Anthos 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. Aggiungi l'URL del registro privato alle immagini:

              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 al 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 eseguire il pull delle immagini con tag 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 all'arresto di un pod.

Il valore del pod terminationGracePeriodSeconds deve essere superiore al valore di terminationDrainDuration.

Per ulteriori informazioni, consulta la sezione Opzioni mesh globali.

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

Abilita log degli accessi

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

Per ulteriori informazioni, vedi Abilitare il logging degli accessi di Envoy.

Cloud Trace

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

• GKE su Google Cloud
• Cluster GKE Enterprise on-premise se installi l'autorità di certificazione Anthos Service Mesh (Mesh CA)

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

Per maggiori informazioni, vedi Accesso alle tracce.

In uscita tramite gateway in uscita

Ti consigliamo di installare un gateway inserito come descritto in Installare ed eseguire l'upgrade dei gateway.

Interfaccia di rete del container Istio

L'abilitazione dell'interfaccia CINI (Container Network Interface) per Istio dipende dall'ambiente in cui è installato Anthos Service Mesh.

1. Attivare un criterio di rete.

2. Scegli il file dell'overlay che corrisponde 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

Abilita log sul traffico per attività esterne a Google Cloud

L'installazione di Anthos Service Mesh con Istio CA al di fuori di Google Cloud segnala le metriche a Prometheus per impostazione predefinita. Usa questa opzione per abilitare i report sui log di traffico, oppure sia Prometheus che Stackdriver, in modo da poter utilizzare le dashboard di Anthos 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 iniettato come descritto in Installare ed eseguire 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 su come abilitare la gestione dei certificati esterni sul gateway in entrata utilizzando Envoy SDS, consulta Gateway sicuri.