Auf dieser Seite wird gezeigt, wie Sie Dienststeuerung für Ihre Pods einrichten.
Informationen zur Funktionsweise der Dienststeuerung finden Sie unter Funktionsweise der Dienststeuerung.
Voraussetzungen
- GKE-Version 1.30 oder höher.
Beschränkungen
- Eine
ServiceFunctionChain
kann höchstens eine Service-Funktion haben. - Wir empfehlen maximal 100 Knoten plus 10
ServiceFunctionChain
- undTrafficSelector
-Paare. - Die GKE-Dienststeuerung ist nur bei Knoten verfügbar, auf denen das Container-Optimized OS-Knoten-Image ausgeführt wird.
- Die GKE-Dienststeuerung unterstützt nur ausgehenden Traffic und Ziel-IP-Adressen.
- Die Dienststeuerung verarbeitet keine Konflikte, die auftreten, wenn mehrere Trafficselektoren mit identischer Präfixlänge auf dasselbe Thema angewendet werden. Um Konflikte zu vermeiden, entwerfen Sie Ihre Trafficauswahlen mit nicht überlappenden IP-Adressbereichen und klar definierten Auswahlkriterien.
Dienststeuerung implementieren
Mit der GKE-Dienststeuerung können Sie den Fluss des Netzwerktraffics innerhalb eines Clusters anpassen und steuern. In diesem Abschnitt wird gezeigt, wie Sie Service Steering mit einem Webgateway-Beispiel implementieren.
Stellen Sie sich einen Anwendungsfall vor, in dem Sie ein Webgateway erstellen möchten, das den Traffic von Endnutzer-Clientgeräten zum Internet schützt. Ein VPN-Terminator zieht Traffic mithilfe eines sicheren Tunnels in das verwaltete Gateway. Endnutzertraffic wird an die Firewall und dann an den Proxy weitergeleitet. Der Proxy führt eine SNAT (Source Network Address Translation) für den Traffic aus, maskiert die ursprüngliche Quelladresse und sendet sie an das Internet.
So implementieren Sie die GKE-Dienststeuerung:
- Erstellen Sie eine VPC mit einer MTU von 8896.
- Einen GKE-Cluster installieren
- Erstellen Sie die Dienstfunktions-Pods und -Dienste.
- Erstellen Sie
ServiceFunctionChain
. - Erstellen Sie die
TrafficSelector
-Ressource, die aufServiceFunctionChain
verweist.
Hinweise
Führen Sie die folgenden Aufgaben aus, bevor Sie beginnen:
- Aktivieren Sie die Google Kubernetes Engine API. Google Kubernetes Engine API aktivieren
- Wenn Sie die Google Cloud CLI für diese Aufgabe verwenden möchten, müssen Sie die gcloud CLI installieren und dann initialisieren. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit
gcloud components update
ab.
Sehen Sie sich die Anforderungen und Einschränkungen an.
Preise
Die folgenden NFO-Funktionen (Network Function Optimizer) werden nur in Clustern unterstützt, die sich in Projekten mit GKE Enterprise befinden:
- Unterstützung mehrerer Netzwerke für Pods
- Unterstützung für nichtflüchtige IP-Adressen für Pods (Vorabversion)
- Richtlinien für mehrere Netzwerke (Vorschau)
- Unterstützung der Dienststeuerung für Pods (Vorschau)
Informationen zu den Gebühren, die für das Aktivieren der Google Kubernetes Engine (GKE) Enterprise-Version anfallen, finden Sie bei den GKE Enterprise-Preisen.
VPC vorbereiten
VPC Die Dienststeuerung verwendet Kapselung, um Traffic an die entsprechenden Service Functions-Funktionen weiterzuleiten. Bei der Kapselung werden jedem Paket zusätzliche Header hinzugefügt, was die Paketgröße erhöht. Die Dienststeuerung erfordert keine spezielle Konfiguration in VPCs. Bei der Vorbereitung der VPC empfehlen wir, bei der Festlegung der MTU-Größe den Kapselungsaufwand zu berücksichtigen. Weitere Informationen finden Sie unter VPC-Netzwerk mit einer angegebenen MTU.
Mit dem folgenden Befehl wird die MTU-Größe in Ihrer VPC festgelegt:
gcloud compute networks create VPC_NETWORK_NAME --mtu=8896
Ersetzen Sie VPC_NETWORK_NAME
durch den Namen des VPC-Netzwerks, das das Subnetz enthält.
GKE-Cluster erstellen
Um die erweiterten Netzwerkrouting- und IP-Adressverwaltungsfunktionen zu aktivieren, die für die Implementierung von Service Steering in GKE erforderlich sind, erstellen Sie einen GKE Dataplane V2-fähigen GKE-Cluster. Gehen Sie dazu so vor:
gcloud container clusters create CLUSTER_NAME \
--network VPC_NAME \
--release-channel RELEASE_CHANNEL \
--cluster-version CLUSTER_VERSION \
--enable-dataplane-v2 \
--enable-ip-alias
Ersetzen Sie Folgendes:
CLUSTER_NAME
ist der Name des Clusters.VPC_NAME
: der Name der VPC, der Sie den Cluster zuordnen möchten.RELEASE_CHANNEL
ist der Name der Release-Version.VERSION
ist die GKE-Version; die 1.30 oder höher sein muss. Sie können auch das Flag--release-channel
verwenden, um einen Release-Kanal auszuwählen. Die Release-Version muss die Standardversion 1.30 oder höher sein.
ServiceFunction
-Pods erstellen
Stellen Sie zum Einrichten Ihrer Dienstkette den VPN-Terminator-Pod und die erforderlichen Dienstfunktions-Pods in Ihrem Cluster bereit. Pods kapseln die containerisierten Anwendungen ein, die Ihre Netzwerkfunktionen ausführen.
Der VPN-Terminator-Pod ist häufig die erste Service-Funktion in der Kette, die den Traffic beendet, der über das VPN in den Cluster eintritt. Anschließend werden die anderen Dienstfunktionen wie Firewalls und Load Balancing zur weiteren Verarbeitung weitergeleitet, bevor das endgültige Ziel erreicht wird.
In der folgenden Beispielkonfigurationsdatei werden die folgenden drei Komponenten definiert, die für die Verwaltung des Netzwerktraffics in einem Cluster wichtig sind:
- VPN-Pod: Richtet einen VPN-Endpunkt (Virtual Private Network) in Ihrem Cluster ein, der eine sichere und verschlüsselte Kommunikation zwischen dem Cluster und externen Netzwerken ermöglicht.
- Firewallbereitstellung: Stellt mehrere Replikate eines Firewall-Pods bereit, die Sicherheit und Load Balancing bieten.
- Proxy-DaemonSet: Stellt einen Proxy-Pod auf jedem Knoten Ihres Clusters bereit. Damit wird sichergestellt, dass der Netzwerkverkehr lokal verarbeitet werden kann, bevor er an andere Dienste wie die Firewall weitergeleitet wird.
Speichern Sie das folgende Beispielmanifest als 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
Wenden Sie das Manifest an:
kubectl apply -f service_function.yaml
ServiceFunctionChains
erstellen
Um eine Sequenz von Netzwerkfunktionen für den Traffic zu definieren, erstellen Sie eine Pipeline, in der jede Funktion wie Firewall, Proxy und Load Balancer ihre bestimmte Aufgabe ausführt, bevor der Traffic an die nächste weitergeleitet wird.
Speichern Sie das folgende Beispielmanifest als 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
Wenden Sie das Manifest an:
kubectl apply -f ServiceFunctionChain.yaml
Die Service Functions-Funktionen werden inline in ServiceFunctionChain
mithilfe des Felds serviceFunctions
definiert. Eine Dienstfunktion ist ein Endpunktselektor.
Ressource TrafficSelector
erstellen
Um zu definieren, wo und welcher Traffic für die Dienststeuerung ausgewählt wird, erstellen Sie die TrafficSelector
-Ressource, die auf die ServiceFunctionChains
verweist, die auf den ausgewählten Traffic angewendet werden soll.
Speichern Sie das folgende Beispielmanifest als 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
Wenden Sie das Manifest an:
kubectl apply -f TrafficSelector.yaml
Fehlerbehebung bei der Dienststeuerung
In diesem Abschnitt wird beschrieben, wie Sie Probleme im Zusammenhang mit der GKE-Dienststeuerung beheben.
Netzwerktraffic fließt nicht
Sie können die folgenden Maßnahmen ergreifen, um das Problem zu beheben:
Schritt 1: Prüfen, ob servicePathId
auf ServiceFunctionChain
festgelegt ist
Prüfen Sie, ob servicePathId
auf ServiceFunctionChain
eingestellt ist. Jedem ServiceFunctionChain
-Objekt wird eine eindeutige servicePathId
zugewiesen, wie im folgenden Beispiel gezeigt:
apiVersion: networking.gke.io/v1
kind: ServiceFunctionChain
metadata:
name: firewall
spec:
serviceFunctions:
- name: firewall
namespace: firewall
podSelector:
matchLabels:
app: firewal
status:
servicePathId: 1
Schritt 2: Prüfen, ob ein Kubernetes-Service pro Service-Funktion erstellt wird
Für jede Dienstfunktion wird automatisch ein ClusterIP-Dienst erstellt. Sie können die Liste der Dienste mit kubectl
aufrufen:
kubectl get svc -A -l networking.gke.io/managed-by=service-steering-controller.gke.io
Schritt 3: Prüfen, ob für jede Dienstfunktion ein bpf-Zuordnungseintrag auf jedem Knoten erstellt wird, um die Dienst-IP-Adresse zu speichern
Für jede Dienstfunktion wird auf jedem Knoten ein bpf-Zuordnungseintrag erstellt, um die Dienst-IP-Adresse zu speichern.
Rufen Sie den Namen des anetd
-Pods ab:
kubectl get pods -n kube-system -o wide -l k8s-app=cilium
Notieren Sie den Namen des Pods ähnlich wie anetd
.
Führen Sie dazu diesen Befehl aus:
kubectl -n kube-system exec -it ANETD-POD-NAME -- cilium bpf sfcpath list
Ersetzen Sie ANETD-POD-NAME
durch den Namen des anetd
-Pods.
Die Ausgabe sieht in etwa so aus:
PATH SERVICE FUNCTION ADDRESS
(1, 1) 10.4.10.124
Schritt 4: Prüfen, ob bpf-Karteneinträge in der sfcselect
-Zuordnung erstellt wurden
Wenn auf einem Knoten Pods ausgewählt werden, die von einer TrafficSelector
ausgewählt wurden, werden bpf-Zuordnungseinträge in der sfcselect
-Zuordnung erstellt. Das folgende Beispiel zeigt, dass TCP/UDP-Traffic von einem beliebigen Port des Endpunkts (Pod) 3783 zur Ziel-IP-Adresse 10.0.2.12 an einen ServiceFunctionChain
weitergeleitet wird.
Führen Sie dazu diesen Befehl aus:
kubectl -n kube-system exec -it ANETD-POD-NAME -- cilium bpf sfcselect list
Ersetzen Sie ANETD-POD-NAME
durch den tatsächlichen Namen des -netd Pods in Ihrem Cluster.
Die Ausgabe sieht in etwa so aus:
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)
Schritt 5: Netzwerkverkehr mit tcpdump auf Port 7081 erfassen und analysieren
Die Dienststeuerung führt eine Geneve-Kapselung unter UDP-Port 7081 durch. Sie können tcpdump auf den entsprechenden Knoten verwenden, um den Trafficfluss zu analysieren und herauszufinden, wo das Problem auftritt.
Nächste Schritte
- Mehr über die Multi-Netzwerk-Unterstützung für Pods erfahren
- Informationen zur Dienststeuerung
- Lesen Sie Unterstützung mehrerer Netzwerke für Pods einrichten.