Dienststeuerung einrichten

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- und TrafficSelector-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:

  1. Erstellen Sie eine VPC mit einer MTU von 8896.
  2. Einen GKE-Cluster installieren
  3. Erstellen Sie die Dienstfunktions-Pods und -Dienste.
  4. Erstellen Sie ServiceFunctionChain.
  5. Erstellen Sie die TrafficSelector-Ressource, die auf ServiceFunctionChain verweist.

Hinweise

Führen Sie die folgenden Schritte durch, 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.

Preise

Die folgenden NFO-Funktionen (Network Function Optimizer) werden nur in Clustern unterstützt, die sich in Projekten mit GKE Enterprise befinden:

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, create 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