Attivare funzionalità facoltative su un piano di controllo 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) Cloud Service Mesh. Un file 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 applicare altri overlay, e ogni file overlay sostituisce la configurazione dei livelli precedenti.

Attenzione: l'utilizzo di asmcli install sovrascrive la configurazione del piano di controllo esistente. Quando attivi funzionalità facoltative in un'installazione esistente, assicurati di specificare tutti i file che vuoi conservare nella configurazione originale, nonché i file in 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. In questo modo, non si verificano tempi di riposo durante l'attivazione delle funzionalità facoltative.

Informazioni sui file di overlay

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

Quando installi Cloud Service Mesh utilizzando lo script asmcli, 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 recupererà il file da GitHub per te. In caso contrario, puoi apportare modifiche al file overlay e utilizzare l'opzione --custom_overlay per passarlo a asmcli.

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

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

Come attivare le funzionalità facoltative

I seguenti esempi 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 utilizzato dipende dal fatto che tu debba apportare modifiche al file di overlay.

• Utilizza --option se 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 attivare le funzionalità facoltative e supportate.

Modalità STRICT mTLS

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

Immagine proxy senza distribuzione

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

La seguente configurazione abilita le immagini distroless per l'intero Cloud Service Mesh. Affinché una modifica del tipo di immagine venga applicata, è necessario riavviare ogni pod e iniettarlo di nuovo.

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

L'immagine distroless non contiene binari diversi dal 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 sostituire 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 registry personalizzato

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

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

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

Aggiungere immagini a un registry privato

Per eseguire il push delle immagini di 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. Estrai le immagini di Cloud Service Mesh:

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

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

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

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

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

5. (Facoltativo) Se utilizzi un servizio canonico, aggiungi le immagini del servizio canonico al tuo registry privato.
   1. Estrai le 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 registry 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 registry 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 registry privato, la procedura è andata a buon fine.

Aumenta la durata dello svuotamento in caso di interruzione

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 ulteriori informazioni, vedi Opzioni di 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 ulteriori informazioni, consulta Attivare 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 li installi con la CA Cloud Service Mesh

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

Per ulteriori informazioni, vedi Accedere alle tracce.

In uscita tramite gateway in uscita

Ti consigliamo di installare un gateway inserito come descritto in Installare e aggiornare i gateway.

Interfaccia di rete del contenitore Istio

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

1. Attiva un criterio di rete.

2. Scegli il file 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

Attiva 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

Attivare i log sul traffico per i dati esterni a Google Cloud

L'installazione di Cloud Service Mesh con la CA Istio al di fuori di Google Cloud registra le metriche in Prometheus per impostazione predefinita. Utilizza questa opzione per attivare i report dei log di traffico o entrambi Prometheus e 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

Attivare un bilanciatore del carico interno

Ti consigliamo di installare un gateway iniettato come descritto in Installare e 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 di ingresso

Per informazioni su come attivare la gestione dei certificati esterni sul gateway di ingresso utilizzando Envoy SDS, consulta Gateway sicuri.