Opzioni per la configurazione dei pod di Google Kubernetes Engine mediante l'inserimento automatico di Envoy
Questa guida fornisce informazioni su opzioni e attività aggiuntive per l'iniettore automatico del sidecar Envoy.
Aggiunta di proxy collaterali ai carichi di lavoro esistenti
Dopo aver installato l'injector dei file collaterali nei cluster, i proxy collaterali vengono inseriti automaticamente nei pod appena creati negli spazi dei nomi abilitati. Se carichi di lavoro già in esecuzione prima di abilitare l'injector sidecar, devi riavviale per consentire l'iniezione.
Per i pod gestiti da controller Deployment, DaemonSet o StatefulSet, esegui questo comando:
# Deployment kubectl rollout restart deployment/DEPLOYMENT_NAME --namespace NAMESPACE # DaemonSet kubectl rollout restart daemonset/DAEMONSET_NAME --namespace NAMESPACE # StatefulSet kubectl rollout restart statefulset/STATEFULSET_NAME --namespace NAMESPACE
Se non hai utilizzato nessuno dei controller sopra riportati per eseguire il deployment dei pod, devi eliminare i pod singolarmente. In seguito, vengono ricreati automaticamente con nuovi proxy sidecar.
kubectl delete pod POD_NAME -n NAMESPACE
Verifica che un container proxy sidecar sia stato inserito in ciascuno dei tuoi pod:
kubectl get pods -n NAMESPACE
Ad esempio, con il client trafficato creato in precedenza, dovresti vedere 2/2 pod una per l'applicazione trafficata e una per l' Envoy inserito proxy sidecar:
NAME READY STATUS RESTARTS AGE busybox-c54f578c9-c9fk4 2/2 Running 183 7d15h
Override di inserimento
Per impostazione predefinita, l'attivazione di uno spazio dei nomi abilita l'inserimento di proxy sidecar per tutti dei pod residenti. L'inserimento può anche essere configurato in modo selettivo per ambiti diversi per soddisfare esigenze specifiche. Ad esempio, è necessario utilizzare gli override per impedire iniezione di proxy sidecar per servizi gRPC proxyless.
Tieni presente che gli override dell'inserimento si applicano solo quando lo spazio dei nomi è abilitato e entreranno in vigore con la seguente priorità: Annotazioni sui pod > NeverInjectSelector > AlwaysInjectSelector > Predefinita Norme
Attivare/disattivare l'inserimento per singoli pod specifici
Utilizza la seguente annotazione sui pod per attivare o disattivare l'inserimento per un pod specifico in uno spazio dei nomi abilitato:
... metadata: annotations: sidecar.istio.io/inject: "true" / "false"
Abilitare/disabilitare l'inserimento per gruppi specifici di pod
L'iniettore collaterale stesso può essere configurato in modo da inserire sempre o mai i pod in abilitati per gli spazi dei nomi basati su un array Selettori di etichette Kubernetes. Ad esempio, usa i comandi seguenti per configurare l'iniettore collaterale per non inserire un proxy sidecar se il pod ha l'etichetta "run=client":
kubectl edit configmap -n istio-control istio-sidecar-injector ... config: |- policy: enabled alwaysInjectSelector: [] neverInjectSelector: - matchLabels: run: client ...
I deployment di sidecar injector esistenti devono essere riavviati per questa configurazione per applicare le modifiche.
Personalizzazione del comportamento di intercettazione del traffico
Per impostazione predefinita, tutto il traffico in uscita dalla tua applicazione viene intercettato e reindirizzato al proxy sidecar di Envoy. Il proxy Envoy può quindi gestire il traffico in base alle istruzioni ricevute da Cloud Service Mesh. In alcuni casi, potresti voler modificare questo comportamento per bypassare il proxy sidecar.
Utilizza le seguenti annotazioni dei pod per escludere il traffico dalle intercettazioni il reindirizzamento.
Escludi dall'intercettazione in base all'intervallo di indirizzi IP in uscita
È possibile escludere il traffico dall'intercettazione in base all'intervallo di indirizzi IP.
... metadata: annotations: cloud.google.com/excludeOutboundCIDRs: "10.0.0.1/32,169.254.169.254/32"
L'annotazione del pod cloud.google.com/excludeOutboundCIDRs
è separata da virgole
degli intervalli di indirizzi IP in uscita in formato CIDR. Traffico in uscita destinato a
questi intervalli di indirizzi IP non vengono reindirizzati al file collaterale di Envoy.
Tieni presente che devi elencare 169.254.169.254/32
nell'annotazione dei pod per
assicurano che le applicazioni possano comunicare con il server dei metadati. Se
non specificare l'annotazione dei pod cloud.google.com/excludeOutboundCIDRs
,
l'intercettazione del traffico è configurata in modo da escludere "169.254.169.254/32"
nell'intervallo CIDR in uscita.
Includi nell'intercettazione da parte dell'intervallo di indirizzi IP in uscita
Puoi includere il traffico nell'intercettazione in base all'intervallo di indirizzi IP.
... metadata: annotations: cloud.google.com/includeOutboundCIDRs: "10.0.0.1/32,169.254.169.254/32"
L'annotazione del pod cloud.google.com/includeOutboundCIDRs
è separata da virgole
degli intervalli di indirizzi IP in uscita in formato CIDR. Traffico in uscita destinato a
questi intervalli di indirizzi IP vengono reindirizzati al file collaterale di Envoy.
Il carattere jolly *
può essere utilizzato per reindirizzare tutto il traffico in uscita. Un campo vuoto
disattiva tutto il traffico in uscita. L'annotazione predefinita è *
.
Escludi dall'intercettazione in base al numero di porta in uscita
Puoi escludere il traffico dall'intercettazione e dal reindirizzamento tramite la porta in uscita numero.
... metadata: annotations: cloud.google.com/excludeOutboundPorts: "10001, 10002"
L'annotazione del pod cloud.google.com/excludeOutboundPorts
è separata da virgole
di porte in uscita. Il traffico in uscita destinato a queste porte viene escluso da
l'intercettazione e il reindirizzamento
al file collaterale di Envoy.
Se non specifichi l'annotazione cloud.google.com/excludeOutboundPorts
,
il traffico in uscita destinato a una qualsiasi porta viene intercettato e reindirizzato
Sidecar di Envoy. Ciò equivale a trasmettere il
Annotazione cloud.google.com/excludeOutboundPorts
con un elenco ("") vuoto.
Includi nell'intercettazione per numero di porta in entrata
Puoi includere il traffico nell'intercettazione in base al numero di porta in entrata.
... metadata: annotations: cloud.google.com/includeInboundPorts: "10001, 10002"
L'annotazione del pod cloud.google.com/includeInboundPorts
è separata da virgole
elenco di porte in entrata verso le quali il traffico deve essere reindirizzato a Envoy
di terze parti. Il carattere jolly *
può essere utilizzato per configurare il reindirizzamento per tutti
porte. Un valore vuoto disattiva tutti i reindirizzamenti in entrata. Il valore predefinito è
una stringa vuota ("").
Escludi dall'intercettazione per numero di porta in entrata
Puoi escludere il traffico dall'intercettazione in base al numero di porta in entrata.
... metadata: annotations: cloud.google.com/excludeInboundPorts: "10001, 10002"
L'annotazione del pod cloud.google.com/excludeInboundPorts
è separata da virgole
elenco di porte in entrata da escludere dal reindirizzamento al sidecar Envoy. La
L'annotazione si applica solo quando tutto il traffico in entrata (*
) viene reindirizzato. La
il valore predefinito è una stringa vuota ("").
Abilita certificati gestiti
Puoi abilitare i certificati per i carichi di lavoro gestiti.
... metadata: annotations: cloud.google.com/enableManagedCerts: "true"
Quando l'annotazione pod cloud.google.com/enableManagedCerts
è impostata su true
,
Certificati dei carichi di lavoro gestiti di GKE firmati da Certificate Authority Service
vengono inserite e montate sul container collaterale. Il valore dell'annotazione
il valore predefinito è false
.
Configurazione dei metadati proxy sidecar
Per supportare funzionalità aggiuntive di Cloud Service Mesh, i proxy sidecar possono ereditare e metadati specifici dai propri pod incapsulati. Ci sono due modi per ottenere questo. Entrambe le opzioni aggiungono metadati e li condividono con Cloud Service Mesh quando il proxy sidecar si connette a Cloud Service Mesh. Le opzioni sono reciprocamente esclusivi.
La prima opzione consente di specificare singole coppie chiave/valore di metadati. Per
Ad esempio, includi la seguente annotazione nella specifica del modello di pod
applicare l'etichetta "version": "dev"
ai proxy sidecar inseriti.
... metadata: annotations: cloud.google.com/proxyMetadata: '{"version": "dev"}'
La seconda opzione aggiunge tutte le etichette del pod al file collaterale inserito del pod proxy.
... metadata: annotations: cloud.google.com/forwardPodLabels: "true"
Se non specifichi l'annotazione cloud.google.com/forwardPodLabels
, il pod
non verranno aggiunte al proxy sidecar. Tieni presente che
cloud.google.com/proxyMetadata
e cloud.google.com/forwardPodLabels
le annotazioni si escludono a vicenda. Se li imposti entrambi,
cloud.google.com/forwardPodLabels
ha la priorità e cloud.google.com/proxyMetadata
viene ignorato.
Filtro di configurazione
consente quindi a Cloud Service Mesh di condividere un sottoinsieme della configurazione solo con
proxy specifici che corrispondono a questa etichetta "version": "dev"
.
Per applicare questa configurazione, è necessario riavviare i deployment esistenti.
Annotazioni sui pod supportate
Cloud Service Mesh supporta le seguenti annotazioni dei pod per il file collaterale iniezione di codice. Anche se potrebbero funzionare anche altre annotazioni degli iniettori collaterali, le annotazioni supportate da Cloud Service Mesh. A evitare interruzioni o instabilità, non creare una dipendenza da altre annotazioni nel deployment di produzione.
Nome annotazione | Valore | Descrizione |
---|---|---|
sidecar.istio.io/inject | Valore booleano, rappresentato come una stringa. Ad esempio: "true " |
Specifica se un file collaterale di Envoy deve essere inserito automaticamente o meno nel carico di lavoro. |
cloud.google.com/proxyMetadata | Mappa JSON di coppie chiave/valore. Ad esempio: "'{"version":
"dev"}' "
|
Specifica le coppie chiave/valore in una mappa JSON che devono essere aggiunte a Metadati Envoy. |
cloud.google.com/forwardPodLabels | "vero" o "false" | Se impostato su "true", tutte le etichette dei pod vengono aggiunte ai metadati Envoy, e "cloud.google.com/proxyMetadata" viene ignorata. Il valore predefinito è "false". |
cloud.google.com/excludeOutboundPorts | Elenco separato da virgole di porte in uscita | Traffico in uscita che indica che una di queste porte di destinazione è esclusa dall'intercettazione/reindirizzamento al file collaterale di Envoy. Questo traffico ignorano il proxy Envoy e non saranno gestiti in base a Cloud Service Mesh configurazione. Il valore predefinito è una stringa vuota (ad es. ""). |
cloud.google.com/includeInboundPorts | Elenco separato da virgole di porte in entrata | Un elenco separato da virgole di porte in entrata per le quali il traffico viene reindirizzato al file collaterale di Envoy. Utilizza il carattere jolly "*" per e configurare il reindirizzamento per tutte le porte. Un valore vuoto disattiva tutti reindirizzamento in entrata. Per impostazione predefinita, il valore è una stringa vuota (""). |
cloud.google.com/excludeInboundPorts | Elenco separato da virgole di porte in entrata | Un elenco separato da virgole di porte in entrata per le quali il traffico viene non vengono reindirizzati al file collaterale di Envoy. L'annotazione si applica solo quando tutto il traffico in entrata (*) viene reindirizzato. Il valore predefinito in una stringa vuota (""). |
cloud.google.com/excludeOutboundCIDRs | Elenco separato da virgole di intervalli IP in uscita in formato CIDR. | Traffico in uscita che indica che uno qualsiasi di questi IP di destinazione è escluso dall'intercettazione/reindirizzamento al file collaterale di Envoy. Questo traffico ignorano il proxy Envoy e non saranno gestiti in base a Cloud Service Mesh configurazione. Il valore predefinito è "169.254.169.254/32", che è l'intervallo richiesto. per comunicare con il server dei metadati. Tieni presente che questo intervallo è obbligatorio se specifichi l'annotazione "excludedOutboundCIDRs", assicurati di inserire anche includi "169.254.169.254/32" oltre a qualsiasi altro CIDR. Assicurati che non siano presenti spazi nell'elenco separato da virgole. |
cloud.google.com/includeOutboundCIDRs | Elenco separato da virgole di intervalli IP in uscita in formato CIDR. | Traffico in uscita che indica che uno di questi IP di destinazione è incluso nell'intercettazione/reindirizzamento al file collaterale di Envoy. Questo traffico è indirizzato al proxy Envoy e gestito in base a Cloud Service Mesh configurazione. Il valore predefinito è "169.254.169.254/32", che è l'intervallo richiesto. per comunicare con il server dei metadati. Tieni presente che questo intervallo è obbligatorio se specifichi l'annotazione "includeOutboundCIDRs", assicurati di inserire anche includi "169.254.169.254/32" oltre a qualsiasi altro CIDR. Assicurati che non siano presenti spazi nell'elenco separato da virgole. |
cloud.google.com/enableManagedCerts | Valore booleano, rappresentato come una stringa. Ad esempio: "true " |
Se impostato su "true ", il carico di lavoro gestito da GKE
i certificati firmati da Certificate Authority Service siano inseriti e montati
sul container collaterale. Il valore predefinito è "false ".
|
Disinstallazione dell'iniettore collaterale
Disinstalla l'iniettore collaterale con i seguenti comandi:
kubectl delete -f specs/ kubectl label namespace default istio-injection-