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, le funzionalità abilitate per impostazione predefinita variano in base alla piattaforma. Puoi abilitare le funzionalità facoltative 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 (RP) personalizzata di IstioOperator
che utilizzi per configurare il piano di controllo. Puoi eseguire l'override della configurazione predefinita e attivare una funzionalità facoltativa o disattivare una funzionalità predefinita in un file di overlay. Specifica una funzionalità per file di overlay. Puoi sovrapporre più overlay e ogni file di overlay sostituisce la configurazione dei livelli precedenti.
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
.
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 le
altre opzioni della riga di comando.
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. Per un elenco delle opzioni, consulta il pacchettoanthos-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 provi a eseguire una shell, visualizzerai 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 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 -
gcr.io/gke-release/asm/install-cni:1.13.9-asm.10
- Piano dati gestito -
gcr.io/gke-release/asm/mdp:1.13.9-asm.10
- Progetto pilota -
gcr.io/gke-release/asm/pilot:1.13.9-asm.10
- Proxyv2 -
gcr.io/gke-release/asm/proxyv2:1.13.9-asm.10
Aggiungere immagini a un registro privato
Per eseguire il push delle immagini Anthos Service Mesh in un registro privato, segui questi passaggi.
-
Esegui il pull delle immagini Anthos Service Mesh:
docker pull gcr.io/gke-release/asm/install-cni:1.13.9-asm.10 docker pull gcr.io/gke-release/asm/mdp:1.13.9-asm.10 docker pull gcr.io/gke-release/asm/pilot:1.13.9-asm.10 docker pull gcr.io/gke-release/asm/proxyv2:1.13.9-asm.10 docker pull gcr.io/gke-release/asm/vaultclient:1.13.9-asm.10
-
Crea una variabile per l'URL del registro privato:
Sostituisciexport PRIVATE_REGISTRY_URL=PRIVATE_REGISTRY_URL
PRIVATE_REGISTRY_URL
con l'URL del tuo registro privato. -
Aggiungi l'URL del registro privato alle immagini:
docker tag gcr.io/gke-release/asm/install-cni:1.13.9-asm.10 \ ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/install-cni:1.13.9-asm.10 docker tag gcr.io/gke-release/asm/mdp:1.13.9-asm.10 \ ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/mdp:1.13.9-asm.10 docker tag gcr.io/gke-release/asm/pilot:1.13.9-asm.10 \ ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/pilot:1.13.9-asm.10 docker tag gcr.io/gke-release/asm/proxyv2:1.13.9-asm.10 \ ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/proxyv2:1.13.9-asm.10 docker tag gcr.io/gke-release/asm/vaultclient:1.13.9-asm.10 \ ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/vaultclient:1.13.9-asm.10
- Esegui il push delle immagini taggate al tuo registro privato:
docker push ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/install-cni:1.13.9-asm.10 docker push ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/mdp:1.13.9-asm.10 docker push ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/pilot:1.13.9-asm.10 docker push ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/proxyv2:1.13.9-asm.10 docker push ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/vaultclient:1.13.9-asm.10
- (Facoltativo) Se utilizzi un servizio canonico, aggiungi le immagini canoniche del servizio al tuo registro privato.
- Esegui il pull delle immagini del servizio canonico Anthos Service Mesh:
docker pull gcr.io/kubebuilder/kube-rbac-proxy:v0.5.0 docker pull gcr.io/gke-release/asm/canonical-service-controller:1.10.3-asm.16
- Aggiungi l'URL del registro privato alle immagini:
docker tag gcr.io/kubebuilder/kube-rbac-proxy:v0.5.0 \ ${PRIVATE_REGISTRY_URL}/gcr.io/kubebuilder/kube-rbac-proxy:v0.5.0 docker tag gcr.io/gke-release/asm/canonical-service-controller:1.10.3-asm.16 \ ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/canonical-service-controller:1.10.3-asm.16
- Esegui il push delle immagini taggate al tuo registro privato:
docker push ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/kube-rbac-proxy:v0.5.0 docker push ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/canonical-service-controller:1.10.3-asm.16
- Esegui il pull delle immagini del servizio canonico Anthos Service Mesh:
Se riesci a eseguire il pull delle immagini con tag dal tuo registro privato, la procedura è andata a buon fine.
Indirizza Envoy a 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)
Per informazioni più dettagliate sui prezzi, consulta la pagina dei prezzi di Cloud Trace.
La frequenza di campionamento predefinita è pari all'1%, ma puoi sostituire quella predefinita specificando un valore tracing.sampling
. Il valore deve essere compreso tra 0,0 e 100,0 con una precisione di 0,01. Ad esempio, per tracciare 5 richieste ogni 10.000,utilizza 0, 05.
L'esempio seguente mostra una frequenza di campionamento del 100% (che useresti solo a scopo dimostrativo o per la risoluzione dei problemi).
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
meshConfig:
enableTracing: true
defaultConfig:
tracing:
sampling: 100
values:
global:
proxy:
tracer: stackdriver
Tieni presente che, attualmente la configurazione del tracer fa parte della configurazione del bootstrap del proxy, quindi è necessario riavviare il pod e reinserirlo per recuperare l'aggiornamento del tracer. Ad esempio, puoi utilizzare il comando seguente in cui i pod di riavvio appartengono a un deployment:
kubectl rollout restart deployment -n NAMESPACE DEPLOYMENT_NAME
Trace la propagazione del contesto
Sebbene i proxy collaterali possano inviare automaticamente intervalli di traccia, hanno bisogno di alcuni suggerimenti per collegare l'intera traccia. Le applicazioni devono propagare le intestazioni HTTP appropriate in modo che, quando i proxy inviano informazioni sugli intervalli, gli intervalli possano essere correlati correttamente in un'unica traccia.
A questo scopo, un'applicazione deve raccogliere e propagare le intestazioni appropriate dalla richiesta in entrata a tutte le richieste in uscita. La configurazione di tracciamento Stackdriver di Anthos Service Mesh accetta uno qualsiasi dei seguenti formati di intestazione e produrrà tutti i seguenti formati:
- B3 (
x-b3-traceid
,x-b3-spanid
,x-b3parentspanid
,x-b3-sampled
,x-b3-flags
) - TraceContext di W3C (
traceparent
) - Google Cloud Trace (
x-cloud-trace-context
) - TraceBin gRPC (
grpc-trace-bin
)
Ciò significa che le tue applicazioni possono utilizzare uno qualsiasi di questi formati per propagare il contesto di tracciamento. Le tracce verranno generate e impostate su Stackdriver in modo appropriato.
Esempio
Ecco un esempio di richiesta HTTP-Get con intestazione traceparent
nella richiesta originale. Osserva le intestazioni aggiuntive del contesto della traccia aggiunte dal proxy.
$ kubectl exec -it sleep-557747455f-n6flv -- curl "httpbin:8000/anything?freeform=" -H "accept: application/json" -H "Traceparent: 00-7543d15e09e5d61801d4f74cde1269b8-604ef051d35c5b3f-01" -vv
* Trying 10.12.3.52:8000...
* Connected to httpbin (10.12.3.52) port 8000 (#0)
> GET /anything?freeform= HTTP/1.1
> Host: httpbin:8000
> User-Agent: curl/7.80.0-DEV
> accept: application/json
> Traceparent: 00-7543d15e09e5d61801d4f74cde1269b8-604ef051d35c5b3f-01
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< server: envoy
< date: Wed, 10 Nov 2021 20:36:04 GMT
< content-type: application/json
< content-length: 1032
< access-control-allow-origin: *
< access-control-allow-credentials: true
< x-envoy-upstream-service-time: 5
<
{
"args": {
"freeform": ""
},
"data": "",
"files": {},
"form": {},
"headers": {
"Accept": "application/json",
"Grpc-Trace-Bin": "AAB1Q9FeCeXWGAHU90zeEmm4AaDHmGRtdM7wAgE",
"Host": "httpbin:8000",
"Traceparent": "00-7543d15e09e5d61801d4f74cde1269b8-a0c798646d74cef0-01",
"User-Agent": "curl/7.80.0-DEV",
"X-B3-Sampled": "1",
"X-B3-Spanid": "a0c798646d74cef0",
"X-B3-Traceid": "7543d15e09e5d61801d4f74cde1269b8",
"X-Cloud-Trace-Context": "7543d15e09e5d61801d4f74cde1269b8/11585396123534413552;o=1",
"X-Envoy-Attempt-Count": "1",
"X-Forwarded-Client-Cert": "<REDACTED>"
},
"json": null,
"method": "GET",
"origin": "127.0.0.6",
"url": "http://httpbin:8000/anything?freeform="
}
Tieni presente che nel set restituito delle intestazioni delle richieste è presente l'insieme completo delle intestazioni di contesto delle tracce.
Per altri esempi di propagazione delle intestazioni, consulta Trace del contesto di propagazione.
Crea una traccia dal client con un ID personalizzato
Per creare una traccia da un client con un ID personalizzato, usa il comando curl
per creare una richiesta con un client esterno e forzare la visualizzazione di una traccia. Ad esempio:
curl $URL --header "x-client-trace-id: 105445aa7843bc8bf206b12000100000"
Per ulteriori informazioni su x-client-trace-id
, consulta la
documentazione di Envoy.
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.
Scegli il file dell'overlay che corrisponde alla tua piattaforma.
Abilita CNI su GKE
Abilita CNI on-premise
Abilita l'osservabilità di Google Cloud per ambienti esterni 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. Utilizza questa opzione per abilitare le metriche di reporting per l'osservabilità di Google Cloud oppure per Prometheus e Stackdriver, in modo da poter utilizzare le dashboard di Anthos Service Mesh.
Solo Stackdriver
Stackdriver e Prometheus
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.