Questa pagina mostra come configurare il Service Steering per i pod.
Per capire come funziona Service Steering, consulta Come funziona Service Steering.
Requisiti
- GKE 1.30 o versioni successive.
Limitazioni
- Un
ServiceFunctionChain
può avere al massimo una funzione di servizio. - Consigliamo un massimo di 100 nodi più 10 coppie
ServiceFunctionChain
eTrafficSelector
. - La gestione dei servizi GKE è disponibile solo con i nodi che eseguono l'immagine del nodo Container-Optimized OS.
- La gestione dei servizi GKE supporta solo gli indirizzi IP di uscita e di destinazione.
- Service Steering non gestisce i conflitti che si verificano quando più selettori di traffico con lunghezze di prefisso identiche vengono applicati allo stesso soggetto. Per evitare conflitti, progetta in modo proattivo i selettori di traffico con intervalli di indirizzi IP non sovrapposti e criteri di selezione chiaramente definiti.
Implementare il reindirizzamento dei servizi
Il reindirizzamento servizio di GKE ti consente di personalizzare e controllare il flusso del traffico di rete all'interno di un cluster. Questa sezione mostra come implementare il Service Steering utilizzando un esempio di gateway web.
Considera un caso d'uso in cui vuoi creare un gateway web che protegga il traffico proveniente dai dispositivi client degli utenti finali verso internet. Un terminatore VPN indirizza il traffico nel gateway gestito utilizzando un tunnel sicuro. Il traffico dell'utente finale viene reindirizzato al firewall e poi al proxy. Il proxy esegue la Network Address Translation (SNAT) dell'origine sul traffico, maschera l'indirizzo di origine originale e lo invia a internet.
Per implementare il reindirizzamento servizio di GKE, svolgi i seguenti passaggi:
- Crea un VPC con un MTU di 8896.
- Creare un cluster GKE.
- Crea i pod e il servizio delle funzioni di servizio.
- Crea il
ServiceFunctionChain
. - Crea la risorsa
TrafficSelector
facendo riferimento aServiceFunctionChain
.
Prima di iniziare
Prima di iniziare, assicurati di aver eseguito le seguenti operazioni:
- Attiva l'API Google Kubernetes Engine. Attiva l'API Google Kubernetes Engine
- Se vuoi utilizzare Google Cloud CLI per questa attività,
installa e poi
inizializza gcloud CLI. Se hai già installato gcloud CLI, ottieni la versione più recente eseguendo
gcloud components update
.
Esamina i requisiti e le limitazioni.
Prezzi
Le seguenti funzionalità di Network Function Optimizer (NFO) sono supportate solo su cluster che si trovano all'interno di progetti in cui è abilitato GKE Enterprise:
- Supporto di più reti per i pod
- Supporto degli indirizzi IP permanenti per i pod (anteprima)
- Criteri di rete multirete (anteprima)
- Supporto di Service Steering per i pod (anteprima)
Per capire le modifiche relative all'abilitazione della versione Google Kubernetes Engine (GKE) Enterprise, consulta Prezzi di GKE Enterprise.
Preparare un VPC
Prepara un VPC. Service Steering utilizza l'incapsulamento per reindirizzare il traffico alle funzioni di servizio appropriate. L'incapsulamento prevede l'aggiunta di intestazioni aggiuntive a ogni pacchetto, che ne aumenta le dimensioni. Service Steering non richiede una configurazione speciale nei VPC. Durante la preparazione della VPC, ti consigliamo di tenere conto dell'overhead di incapsulamento quando decidi le dimensioni dell'MTU. Per saperne di più, consulta Rete VPC con un'MTU specificata.
Il seguente comando imposta la dimensione del pacchetto nella VPC:
gcloud compute networks create VPC_NETWORK_NAME --mtu=8896
Sostituisci VPC_NETWORK_NAME
con il nome della rete VPC contenente la subnet.
Crea un cluster GKE
Per abilitare le funzionalità avanzate di routing di rete e gestione degli indirizzi IP necessarie per implementare il Service Steering su GKE, create un cluster GKE con GKE Dataplane V2 abilitato come segue:
gcloud container clusters create CLUSTER_NAME \
--network VPC_NAME \
--release-channel RELEASE_CHANNEL \
--cluster-version CLUSTER_VERSION \
--enable-dataplane-v2 \
--enable-ip-alias
Sostituisci quanto segue:
CLUSTER_NAME
: il nome del cluster.VPC_NAME
: il nome della VPC con cui vuoi associare il cluster.RELEASE_CHANNEL
: il nome del canale di rilascio.VERSION
: la versione di GKE, che deve essere 1.30 o successiva. Puoi anche utilizzare il flag--release-channel
per selezionare un canale di rilascio. Il canale di rilascio deve avere una versione predefinita pari o successiva a 1.30.
Crea pod ServiceFunction
Per stabilire la catena di servizi, esegui il deployment del pod di terminazione VPN e dei pod di funzione di servizio necessari all'interno del cluster. I pod incapsulano le applicazioni containerizzate che eseguono le funzioni di rete.
Il pod di terminazione VPN è spesso la prima funzione di servizio della catena, che termina il traffico che entra nel cluster tramite la VPN. Quindi indirizza le altre funzioni di servizio, come firewall e bilanciamento del carico, per l'ulteriore elaborazione prima di raggiungere la destinazione finale.
Il seguente file di configurazione di esempio definisce i tre componenti seguenti essenziali per la gestione del traffico di rete all'interno di un cluster:
- Pod VPN: stabilisce un endpoint di rete privata virtuale (VPN) all'interno del tuo cluster, che consente la comunicazione sicura e criptata tra il cluster e le reti esterne.
- Deployment del firewall:esegue il deployment di più repliche di un pod firewall, che forniscono sicurezza e bilanciamento del carico.
- DaemonSet proxy: esegue il deployment di un pod proxy su ogni nodo del cluster, assicurando che il traffico di rete possa essere elaborato localmente prima di essere inoltrato ad altri servizi come il firewall.
Salva il seguente manifest di esempio come service_function.yaml
:
apiVersion: v1
kind: Pod
name: vpn
namespace: vpn
labels:
app: vpn
spec:
containers:
- name: vpn
image: openvpn
ports:
- containerPort: 51820
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: firewall
namespace: firewall
spec:
replicas: 3
selector:
matchLabels:
app: firewall
template:
metadata:
labels:
app: firewall
spec:
containers:
- name: firewall
image: firewall
---
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: proxy
namespace: proxy
spec:
selector:
matchLabels:
app: proxy
template:
metadata:
labels:
app: proxy
spec:
containers:
- name: proxy
image: proxy
Applica il manifest:
kubectl apply -f service_function.yaml
Crea ServiceFunctionChains
Per definire una sequenza di funzioni di rete per il traffico da attraversare, crea una pipeline in cui ogni funzione, come firewall, proxy e bilanciatore del carico, esegue la propria attività specifica prima di passare il traffico alla successiva.
Salva il seguente manifest di esempio come ServiceFunctionChain.yaml
:
apiVersion: networking.gke.io/v1
kind: ServiceFunctionChain
metadata:
name: firewall
spec:
sessionAffinity:
clientIpNoDestination:
timeoutSeconds: 3600 # 1hr
serviceFunctions:
- name: firewall
namespace: firewall
podSelector:
matchLabels:
app: firewall
---
apiVersion: networking.gke.io/v1
kind: ServiceFunctionChain
metadata:
name: proxy
spec:
sessionAffinity:
clientIpNoDestination: {}
serviceFunctions:
- name: proxy
namespace: proxy
podSelector:
matchLabels:
app: proxy
Applica il manifest:
kubectl apply -f ServiceFunctionChain.yaml
Le funzioni di servizio sono definite in linea all'interno di ServiceFunctionChain
utilizzando
il campo serviceFunctions
. Una funzione di servizio è un selettore di endpoint.
Crea la risorsa TrafficSelector
Per definire dove e quale traffico viene selezionato per il Service Steering, crea la risorsa TrafficSelector
che fa riferimento al ServiceFunctionChains
da applicare al traffico scelto.
Salva il seguente manifest di esempio come TrafficSelector.yaml
:
apiVersion: networking.gke.io/v1
kind: TrafficSelector
metadata:
name: vpn-to-firewall
spec:
serviceFunctionChain: firewall
subject:
pods:
namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: vpn
podSelector:
matchLabels:
app: vpn
egress:
to:
ipBlock:
cidr: 0.0.0.0/0
ports:
- allPorts:
protocol: UDP
- allPorts:
protocol: TCP
---
apiVersion: networking.gke.io/v1
kind: TrafficSelector
metadata:
name: firewall-to-proxy
spec:
serviceFunctionChain: proxy
subject:
pods:
namespaceSelector:
kubernetes.io/metadata.name: firewall
podSelector:
app: firewall
egress:
to:
ipBlock:
cidr: 0.0.0.0/0
ports:
- allPorts:
protocol: UDP
- allPorts:
protocol: TCP
Applica il manifest:
kubectl apply -f TrafficSelector.yaml
Risolvere i problemi relativi al reindirizzamento dei servizi
Questa sezione mostra come risolvere i problemi relativi al Service Steering di GKE.
Il traffico di rete non scorre
Per eseguire il debug del problema, puoi procedere nel seguente modo:
Passaggio 1: verifica che servicePathId
sia impostato su ServiceFunctionChain
Verifica che servicePathId
sia impostato su ServiceFunctionChain
. A ogni
ServiceFunctionChain
oggetto viene assegnato un servicePathId
univoco, come mostrato
nel seguente esempio:
apiVersion: networking.gke.io/v1
kind: ServiceFunctionChain
metadata:
name: firewall
spec:
serviceFunctions:
- name: firewall
namespace: firewall
podSelector:
matchLabels:
app: firewal
status:
servicePathId: 1
Passaggio 2: verifica che venga creato un servizio Kubernetes per ogni funzione di servizio
Per ogni funzione di servizio viene creato automaticamente un servizio ClusterIP. Puoi visualizzare l'elenco di servizi utilizzando kubectl
:
kubectl get svc -A -l networking.gke.io/managed-by=service-steering-controller.gke.io
Passaggio 3: verifica che per ogni funzione di servizio venga creata una voce della mappa bpf su ogni nodo per memorizzare l'indirizzo IP del servizio
Per ogni funzione di servizio, su ogni nodo viene creata una voce della mappa bpf per memorizzare l'indirizzo IP del servizio.
Recupera il nome del pod anetd
:
kubectl get pods -n kube-system -o wide -l k8s-app=cilium
Registra il nome del pod, ad esempio anetd
.
Esegui questo comando:
kubectl -n kube-system exec -it ANETD-POD-NAME -- cilium bpf sfcpath list
Sostituisci ANETD-POD-NAME
con il nome del pod anetd
.
L'output è simile al seguente:
PATH SERVICE FUNCTION ADDRESS
(1, 1) 10.4.10.124
Passaggio 4: verifica che le voci della mappa bpf siano create nella mappa sfcselect
In un nodo, se sono presenti pod selezionati da un TrafficSelector
, le voci della mappa bpf vengono create nella mappa sfcselect
. L'esempio seguente mostra che il traffico TCP/UDP
da qualsiasi porta dell'endpoint (pod) 3783 all'indirizzo IP di destinazione 10.0.2.12 viene indirizzato a un
ServiceFunctionChain
.
Esegui questo comando:
kubectl -n kube-system exec -it ANETD-POD-NAME -- cilium bpf sfcselect list
Sostituisci ANETD-POD-NAME
con il nome effettivo del pod anetd nel cluster.
L'output è simile al seguente:
SELECTOR PATH
3783, egress, 0/TCP, 10.0.2.12/32 /32 (1, 1)
3783, egress, 0/UDP, 10.0.2.12/32 /32 (1, 1)
Passaggio 5: utilizza tcpdump sulla porta 7081 per acquisire e analizzare il traffico di rete
Service Steering esegue l'incapsulamento Geneva sulla porta UDP 7081. Puoi utilizzare tcpdump sui nodi pertinenti per analizzare il flusso di traffico e individuare il punto in cui potrebbe verificarsi il problema.
Passaggi successivi
- Leggi l'articolo Informazioni sul supporto di più reti per i pod
- Leggi l'articolo Informazioni sul reindirizzamento dei servizi
- Leggi l'articolo Configurare il supporto di più reti per i pod