Attivazione di funzionalità facoltative nel piano di controllo in-cluster

Questa pagina descrive come abilitare le funzionalità facoltative su un cluster in-cluster piano di controllo. Per informazioni su per il piano di controllo gestito, Configura Cloud Service Mesh gestito.

Quando installi Cloud 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 overlay durante l'installazione (o l'upgrade) di Cloud Service Mesh. Un file overlay è un file YAML contenente una risorsa personalizzata IstioOperator (RP) utilizzata per configurare il piano di controllo. Specifica una funzionalità per file di overlay. Puoi sovrapporre altri overlay e ogni file di overlay sostituisce la configurazione sui livelli precedenti.

Informazioni sui file di overlay

I file degli overlay su questa pagina si trovano nel anthos-service-mesh in GitHub. Questi file contengono personalizzazioni comuni configurazione. Potete utilizzare questi file così come sono oppure aggiungere se necessario.

Quando installi Cloud Service Mesh utilizzando lo strumento fornito da Google asmcli, devi puoi specificare uno o più file di overlay con i token --option o --custom_overlay opzioni. 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 poi utilizzare l'opzione --custom_overlay per passarlo a asmcli.

Non includere più RP in un unico file di overlay. Crea file di overlay separati per ogni RP
più RP in un unico YAML file YAML 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.

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

  • Usa --option quando non devi apportare modifiche al file dell'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 dell'overlay come iap-operator e attached-cluster. Per un elenco di opzioni, fai riferimento anthos-service-mesh pacchetto.

  • 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 dell'overlay che vuoi utilizzare.

YAML per le caratteristiche facoltative

Le sezioni seguenti forniscono il file YAML per abilitare opzioni facoltative e supportate le funzionalità di machine learning.

Modalità mTLS STRICT

La configurazione global.mtls.enabled è stata rimossa da IstioOperator RP per evitare problemi con gli upgrade e 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-disturbo degli scanner di vulnerabilità ed esposizioni comuni (CVE). Istio fornisce immagini proxy basate su immagini di base senza distribuzione.

La seguente configurazione abilita le immagini senza distrografia per l'intero Cloud Service Mesh. Una modifica al tipo di immagine richiede il riavvio di ogni pod e il reinserimento per avere effetto.

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

L'immagine distroless non contiene file binari diversi dal proxy. Di conseguenza, non è possibile exec una shell o utilizzare curl, ping o altre utilità di debug all'interno del container. Se provi a eseguire una 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 registro 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 a cui è necessario eseguire il mirroring personalizzato Container Registry:

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

Aggiungi immagini a un registro privato

Per eseguire il push delle immagini Cloud Service Mesh in un registro privato, completa quanto segue passaggi.

  1. Esegui il pull delle immagini Cloud Service Mesh:
    docker pull gke.gcr.io/asm/install-cni:1.15.7-asm.23
    docker pull gke.gcr.io/asm/mdp:1.15.7-asm.23
    docker pull gke.gcr.io/asm/pilot:1.15.7-asm.23
    docker pull gke.gcr.io/asm/proxyv2:1.15.7-asm.23
    
  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 registry privato.
  3. Tagga le immagini con l'URL del tuo registry privato:
    docker tag gke.gcr.io/asm/install-cni:1.15.7-asm.23 \
     ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/install-cni:1.15.7-asm.23
    docker tag gke.gcr.io/asm/mdp:1.15.7-asm.23 \
     ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/mdp:1.15.7-asm.23
    docker tag gke.gcr.io/asm/pilot:1.15.7-asm.23 \
     ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/pilot:1.15.7-asm.23
    docker tag gke.gcr.io/asm/proxyv2:1.15.7-asm.23 \
     ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/proxyv2:1.15.7-asm.23
    
  4. Esegui il push delle immagini con tag nel tuo registro privato:
    docker push ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/install-cni:1.15.7-asm.23
    docker push ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/mdp:1.15.7-asm.23
    docker push ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/pilot:1.15.7-asm.23
    docker push ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/proxyv2:1.15.7-asm.23
    
  5. (Facoltativo) Se utilizzi una servizio canonico, quindi aggiungi immagini di servizio canoniche nel tuo registro 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 con tag 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 puoi 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 quando un pod viene terminato.

Il pod terminationGracePeriodSeconds deve essere maggiore del valore terminationDrainDuration.

Per ulteriori informazioni, consulta la sezione sulle opzioni del mesh globale.

---
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, consulta Attivare la registrazione degli accessi di Envoy.

Cloud Trace

Cloud Trace è disponibile per le installazioni di Cloud Service Mesh nei seguenti paesi: piattaforme:

  • GKE su Google Cloud
  • di cluster GKE Enterprise on-premise Autorità di certificazione Cloud Service Mesh
---
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    enableTracing: true
  values:
    global:
      proxy:
        tracer: stackdriver

Per ulteriori informazioni, vedi Accesso alle tracce.

In uscita tramite gateway in uscita

Ti consigliamo di installare injected (gateway inserito) come descritto in Installa ed esegui l'upgrade dei 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 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

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

Abilita i log sul traffico per le attività esterne a Google Cloud

L'installazione di Cloud Service Mesh con Istio CA 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

Abilita un bilanciatore del carico interno

Ti consigliamo di installare injected (gateway inserito) come descritto in Installa ed esegui l'upgrade dei gateway per configurare un server 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 abilitare la gestione dei certificati esterni nel traffico in entrata utilizzando Envoy SDS, consulta Gateway sicuri.