Multus mit IPVLAN und Whereabouts konfigurieren

In diesem Dokument wird erläutert, wie Sie Pods in Google Kubernetes Engine (GKE) mit mehreren Netzwerkschnittstellen konfigurieren. Dazu verwenden Sie Multus CNI, das IPVLAN CNI-Plug-in und das Whereabouts IPAM-Plug-in.

Das IPVLAN CNI-Plug-in bietet Layer 2-Konnektivität für zusätzliche Pod-Schnittstellen und das Whereabouts IPAM-Plug-in weist ihnen dynamisch IP-Adressen zu.

Diese Einrichtung ermöglicht erweiterte Netzwerkkonfigurationen, z. B. das Trennen des Traffics der Steuerungsebene und der Datenebene für eine verbesserte Netzwerktrennung und -segmentierung.

Dieses Dokument richtet sich an Cloud-Architekten und Netzwerkspezialisten, die das Netzwerk für ihre Organisation entwerfen und erstellen. Weitere Informationen zu gängigen Rollen und Beispielaufgaben, auf die wir in Google Cloud Inhalten verweisen, finden Sie unter Häufig verwendete GKE-Nutzerrollen und -Aufgaben.

Bevor Sie dieses Dokument lesen, sollten Sie mit den folgenden Konzepten vertraut sein:

Vorteile der Verwendung von Multus mit IPVLAN

Die Konfiguration Ihrer Pods mit mehreren Netzwerkschnittstellen mithilfe dieser Lösung bietet mehrere wichtige Vorteile. Die primären Anwendungsfälle für die Konfiguration von Multus mit IPVLAN im Layer 2-Modus sind die Netzwerksegmentierung, für die eine Layer 2-Nachbarschaft erforderlich ist:

  • Verkehrstrennung:Trennen Sie verschiedene Arten von Verkehr, um die Sicherheit und Leistung zu verbessern. Sie können beispielsweise sensiblen Verwaltungsverkehr vom Anwendungsdatenverkehr trennen.
  • Trennung von Steuerungsebene und Datenebene:Verwenden Sie die primäre Netzwerkschnittstelle für den Verkehr der Steuerungsebene und leiten Sie den Datenverkehr der Datenebene mit hohem Durchsatz über eine sekundäre IPVLAN-Schnittstelle.
  • Layer 2-Nachbarschaft:Erfüllen Sie die Anforderungen für Anwendungen, die eine direkte Layer 2-Verbindung zwischen Pods im selben sekundären Netzwerk benötigen.

Beschränkungen

Für Multus mit IPVLAN und Whereabouts gelten die folgenden Einschränkungen:

  • Pods, die mit Multus-Schnittstellen konfiguriert sind, können die integrierten Multi-Netzwerk-Funktionen von GKE nicht gleichzeitig verwenden. Die Netzwerkkonfiguration eines Pods muss entweder Multus oder die integrierten Multi-Netzwerk-Funktionen des Clusters verwenden.
  • Multus mit IPVLAN und Whereabouts erfordert eine Layer 2-ARP-Auflösung innerhalb des Pods, um ordnungsgemäß zu funktionieren.
  • Standardmäßig lassen VPC-Subnetze keine ARP-Auflösung auf sekundären Schnittstellen von Compute Engine-VMs zu. Wenn Sie diese ARP-Auflösung zulassen möchten, können Sie sich für die Private Preview des Features resolve-subnet-mask registrieren, indem Sie eine Supportanfrage erstellen.

Funktionsweise von Multus mit IPVLAN und Whereabouts

Multus ist ein CNI-Meta-Plug-in, mit dem Pods an mehrere Netzwerke angehängt werden können. Multus fungiert als Dispatcher und ruft andere CNI-Plug-ins auf, um Netzwerkschnittstellen basierend auf NetworkAttachmentDefinition-Ressourcen zu konfigurieren. Sie definieren jedes zusätzliche Netzwerk mit einer NetworkAttachmentDefinition, die angibt, welches CNI-Plug-in (z. B. IPVLAN) und IPAM-Plug-in (z. B. Whereabouts) für dieses Netzwerk verwendet werden soll.

Das folgende Diagramm veranschaulicht die Multus-Architektur mit IPVLAN- und Whereabouts-Plug-ins.Das Whereabouts-Plug-in funktioniert mit Multus und IPVLAN, um die IP-Adressverwaltung (IPAM) für die zusätzlichen Netzwerkschnittstellen der Pods zu verwalten.

Diagramm, das zeigt, wie Multus, IPVLAN und Whereabouts in GKE zusammenarbeiten.
Abbildung 1. Multus-Architektur mit IPVLAN- und Whereabouts-Plug-ins.

Dieses Diagramm zeigt zwei Knoten mit jeweils einem Pod. Jeder Pod hat eine primäre und eine zusätzliche Schnittstelle. Die beiden primären Schnittstellen sind mit einer gemeinsamen Netzwerkkarte verbunden und die beiden zusätzlichen Schnittstellen mit einer anderen gemeinsamen Netzwerkkarte.

Wenn Sie Multus mit IPVLAN und Whereabouts in GKE verwenden, haben Pods in der Regel die folgende Schnittstellenkonfiguration:

  • Primäre Schnittstelle (eth0): Diese Schnittstelle wird von GKE Dataplane V2 verwaltet und bietet die Standard-Clusterkonnektivität.
  • Zusätzliche Schnittstellen (net1 usw.): Diese Schnittstellen werden von Multus verwaltet. Multus ruft das IPVLAN CNI-Plug-in im Layer 2-Modus für jede NetworkAttachmentDefinition auf, die Sie in den Annotationen eines Pods angeben. Diese Konfiguration bietet Layer 2-Konnektivität zu einem sekundären VPC-Netzwerk.
  • IP-Adressverwaltung (IPAM): Sie konfigurieren das Whereabouts IPAM-Plug-in in der NetworkAttachmentDefinition. Das Whereabouts IPAM-Plug-in weist den zusätzlichen IPVLAN-Schnittstellen dynamisch IP-Adressen aus einem vordefinierten Bereich zu.

Pod-Planung mit mehreren Netzwerken

Wenn Sie einen Pod erstellen und in seinen Annotationen eine NetworkAttachmentDefinition angeben, platziert der GKE-Scheduler den Pod nur auf einem Knoten, der die Netzwerkanforderungen erfüllen kann. Der Scheduler identifiziert Knoten in einem Knotenpool, auf denen die erforderliche sekundäre Netzwerkschnittstelle konfiguriert ist. Dieser Knotenidentifizierungsprozess trägt dazu bei, dass der Scheduler den Pod auf einem Knoten plant, der eine Verbindung zum zusätzlichen Netzwerk herstellen und eine IP-Adresse aus dem angegebenen Bereich empfangen kann.

In den folgenden Abschnitten wird beschrieben, wie Sie Multus mit IPVLAN- und Whereabouts-Plug-ins in Ihrem GKE-Cluster konfigurieren.

Hinweis

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 diesen Task verwenden möchten, installieren und dann initialisieren Sie die gcloud CLI. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit dem gcloud components update Befehl ab. Ältere gcloud CLI-Versionen unterstützen möglicherweise nicht die Ausführung der Befehle in diesem Dokument.
  • Installieren Sie das kubectl-Befehlszeilentool.
  • Richten Sie einen GKE-Cluster mit Version 1.28 oder höher ein, auf dem Dataplane V2, IP-Alias und Multi-Netzwerk aktiviert sind. Weitere Informationen finden Sie unter Unterstützung mehrerer Netzwerke für Pods einrichten. Wenn Sie Multi-Netzwerk aktivieren, werden auch die Features Multi-IP-Subnetz und HA-Richtlinie für persistente IP-Adressen aktiviert, sodass keine manuelle Einrichtung der Konnektivität zwischen Knoten erforderlich ist.
  • Verwenden Sie eine von GKE validierte Version von Multus CNI (z. B. v4.2.1), um die Kompatibilität zu gewährleisten.

VPC einrichten

So richten Sie die Virtual Private Cloud (VPC) für die Verwendung mit Multus ein, einschließlich der Erstellung eines Subnetzes für die Knotenvernetzung und sekundärer Bereiche für die Pod-Vernetzung:

  1. Erstellen Sie eine neue VPC oder verwenden Sie eine vorhandene:

    gcloud compute networks create VPC_NAME \
--subnet-mode=custom

    Ersetzen Sie VPC_NAME durch den Namen der VPC.

  2. Erstellen Sie ein neues Subnetz in dieser VPC:

    gcloud compute networks subnets create SUBNET_NAME \
    --range=PRIMARY_RANGE \
    --network=VPC_NAME \
    --region=REGION \
    --secondary-range=SECONDARY_RANGE_NAME=SECONDARY_RANGE_CIDR

    Ersetzen Sie Folgendes:

    • SUBNET_NAME: der Name des neuen Subnetzes.
    • PRIMARY_RANGE: der primäre CIDR-Bereich für das Subnetz, z. B. 10.0.1.0/24. Dieser Befehl verwendet diesen Bereich für Knotenschnittstellen.
    • VPC_NAME: der Name der VPC.
    • REGION: die Region für das Subnetz, z. B. us-central1.
    • SECONDARY_RANGE_NAME: der Name des sekundären IP-Adressbereichs für Pods im Subnetz.
    • SECONDARY_RANGE_CIDR: der sekundäre CIDR-Bereich für Pods, z. B. 172.16.1.0/24. Zusätzliche Schnittstellen auf Pods verwenden diesen Bereich.

    Mit diesem Befehl wird ein Subnetz mit einem primären CIDR-Bereich für eine zusätzliche Knotenschnittstelle und einem sekundären Bereich für die zusätzlichen Pod-Schnittstellen erstellt.

GKE-Standardcluster erstellen

Erstellen Sie einen GKE-Standardcluster mit aktiviertem Multi-Netzwerk:

gcloud container clusters create CLUSTER_NAME \
    --cluster-version=CLUSTER_VERSION \
    --enable-dataplane-v2 \
    --enable-ip-alias \
    --enable-multi-networking

Ersetzen Sie Folgendes:

  • CLUSTER_NAME: der Name des neuen Clusters.
  • CLUSTER_VERSION: die Version Ihres GKE-Clusters. Sie müssen Version 1.28 oder höher verwenden.

Wenn Sie Multi-Netzwerk aktivieren, können Sie Knotenpools mit mehreren Netzwerkschnittstellen erstellen, die für Multus CNI erforderlich sind.

GKE-Standardknotenpool erstellen

Erstellen Sie einen GKE-Standardknotenpool, der mit zusätzlichen VPC-Netzwerken verbunden ist:

gcloud container node-pools create NODEPOOL_NAME \
    --cluster CLUSTER_NAME \
    --zone "ZONE" \
    --additional-node-network network=VPC_NAME,subnetwork=SUBNET_NAME \
    --additional-pod-network subnetwork=SUBNET_NAME,pod-ipv4-range=SECONDARY_RANGE_NAME,max-pods-per-node=8

Ersetzen Sie Folgendes:

  • NODEPOOL_NAME: der Name des neuen Knotenpools.
  • CLUSTER_NAME: der Name Ihres Clusters.
  • ZONE: die Zone für den Knotenpool, z. B. us-central1-c.
  • VPC_NAME: der Name der zusätzlichen VPC.
  • SUBNET_NAME: der Name des Subnetzes.
  • SECONDARY_RANGE_NAME: der Name des sekundären IP-Adressbereichs für Pods im Subnetz.

Mit diesem Befehl wird ein Knotenpool erstellt, in dem Knoten eine zusätzliche Netzwerk schnittstelle in SUBNET_NAME haben und Pods auf diesen Knoten IP-Adressen aus SECONDARY_RANGE_NAME verwenden können.

Weitere Informationen zum Erstellen von GKE-Clustern mit Multi-Netzwerk Funktionen finden Sie unter Unterstützung mehrerer Netzwerke für Pods einrichten.

Multus-Bereitstellung anwenden

Wenn Sie mehrere Netzwerkschnittstellen für Ihre Pods aktivieren möchten, installieren Sie das Multus CNI-Plug-in. Speichern Sie das folgende Manifest, das das erforderliche DaemonSet und die benutzerdefinierte Ressourcendefinition (Custom Resource Definition, CRD) enthält, als multus-manifest.yaml:

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: ippools.whereabouts.cni.cncf.io
spec:
  group: whereabouts.cni.cncf.io
  names:
    kind: IPPool
    listKind: IPPoolList
    plural: ippools
    singular: ippool
  scope: Namespaced
  versions:
  - name: v1alpha1
    schema:
      openAPIV3Schema:
        description: IPPool is the Schema for the ippools API
        properties:
          apiVersion:
            description: 'APIVersion defines the versioned schema of this representation
                of an object. Servers should convert recognized schemas to the latest
                internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/api-conventions.md#resources'
            type: string
          kind:
            description: 'Kind is a string value representing the REST resource this
                object represents. Servers may infer this from the endpoint the client
                submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/api-conventions.md#types-kinds'
            type: string
          metadata:
            type: object
          spec:
            description: IPPoolSpec defines the desired state of IPPool
            properties:
              allocations:
                additionalProperties:
                  description: IPAllocation represents metadata about the pod/container
                    owner of a specific IP
                  properties:
                    id:
                      type: string
                    podref:
                      type: string
                  required:
                  - id
                  type: object
                description: Allocations is the set of allocated IPs for the given
                  range. Its indices are a direct mapping to the IP with the same
                  index/offset for the pools range.
                type: object
              range:
                description: Range is a RFC 4632/4291-style string that represents
                  an IP address and prefix length in CIDR notation
                type: string
            required:
            - allocations
            - range
            type: object
        type: object
    served: true
    storage: true
status:
  acceptedNames:
    kind: ""
    plural: ""
  conditions: []
  storedVersions: []
---
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  annotations:
    controller-gen.kubebuilder.io/version: v0.4.1
  name: overlappingrangeipreservations.whereabouts.cni.cncf.io
spec:
  group: whereabouts.cni.cncf.io
  names:
    kind: OverlappingRangeIPReservation
    listKind: OverlappingRangeIPReservationList
    plural: overlappingrangeipreservations
    singular: overlappingrangeipreservation
  scope: Namespaced
  versions:
  - name: v1alpha1
    schema:
      openAPIV3Schema:
        description: OverlappingRangeIPReservation is the Schema for the OverlappingRangeIPReservations
          API
        properties:
          apiVersion:
            description: 'APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources'
            type: string
          kind:
            description: 'Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds'
            type: string
          metadata:
            type: object
          spec:
            description: OverlappingRangeIPReservationSpec defines the desired state
              of OverlappingRangeIPReservation
            properties:
              containerid:
                type: string
              podref:
                type: string
            required:
            - containerid
            type: object
        required:
        - spec
        type: object
    served: true
    storage: true
status:
  acceptedNames:
    kind: ""
    plural: ""
  conditions: []
  storedVersions: []
---
kind: ConfigMap
apiVersion: v1
metadata:
  name: multus-cni-config
  namespace: kube-system
  labels:
    app: gke-multinet
data:
  cni-conf.json: |
    {
      "name": "multus-cni-network",
      "type": "multus",
      "confDir": "/etc/cni/net.d",
      "namespaceIsolation": true,
      "logLevel": "verbose",
      "logFile": "/var/log/multus.log",
      "kubeconfig": "/var/lib/kubelet/kubeconfig",
      "clusterNetwork": "gke-pod-network"
    }
---
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: network-attachment-definitions.k8s.cni.cncf.io
spec:
  group: k8s.cni.cncf.io
  scope: Namespaced
  names:
    plural: network-attachment-definitions
    singular: network-attachment-definition
    kind: NetworkAttachmentDefinition
    shortNames:
    - net-attach-def
  versions:
  - name: v1
    served: true
    storage: true
    schema:
      openAPIV3Schema:
        description: 'NetworkAttachmentDefinition is a CRD schema specified by the Network Plumbing
            Working Group to express the intent for attaching pods to one or more logical or physical
            networks. More information available at: https://github.com/k8snetworkplumbingwg/multi-net-spec'
        type: object
        properties:
          apiVersion:
            description: 'APIVersion defines the versioned schema of this represen
                tation of an object. Servers should convert recognized schemas to the
                latest internal value, and may reject unrecognized values. More info:
                https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources'
            type: string
          kind:
            description: 'Kind is a string value representing the REST resource this
                object represents. Servers may infer this from the endpoint the client
                submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds'
            type: string
          metadata:
            type: object
          spec:
            description: 'NetworkAttachmentDefinition spec defines the desired state of a network attachment'
            type: object
            properties:
              config:
                description: 'NetworkAttachmentDefinition config is a JSON-formatted CNI configuration'
                type: string
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: multus-role
rules:
- apiGroups: ["k8s.cni.cncf.io"]
  resources:
  - '*'
  verbs:
  - '*'
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: whereabouts
rules:
- apiGroups:
  - whereabouts.cni.cncf.io
  resources:
  - ippools
  - overlappingrangeipreservations
  verbs:
  - get
  - list
  - watch
  - create
  - update
  - patch
  - delete
- apiGroups:
  - coordination.k8s.io
  resources:
  - leases
  verbs:
  - create
- apiGroups:
  - coordination.k8s.io
  resources:
  - leases
  resourceNames:
  - whereabouts
  verbs:
  - '*'
- apiGroups: [""]
  resources:
  - pods
  verbs:
  - list
  - get
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: multus-role-binding
subjects:
- kind: Group
  name: system:nodes
roleRef:
  kind: ClusterRole
  name: multus-role
  apiGroup: rbac.authorization.k8s.io
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: whereabouts-role-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: whereabouts
subjects:
- kind: ServiceAccount
  name: whereabouts-sa
  namespace: kube-system
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: whereabouts-sa
  namespace: kube-system
---
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: gke-multinet
  namespace: kube-system
  labels:
    app: gke-multinet
spec:
  selector:
    matchLabels:
      app: gke-multinet
  template:
    metadata:
      labels:
        app: gke-multinet
    spec:
      priorityClassName: system-node-critical
      hostNetwork: true
      tolerations:
      - operator: Exists
      serviceAccountName: whereabouts-sa
      containers:
      - name: whereabouts-gc
        command: [/ip-control-loop]
        args:
        - "--log-level=debug"
        - "--enable-pod-watch=false"
        - "--cron-schedule=* * * * *"
        image: gcr.io/gke-release/whereabouts:v0.7.0-gke.3@sha256:2bb8450a99d86c73b262f5ccd8c433d3e3abf17d36ee5c3bf1056a1fe479e8c2
        env:
        - name: NODENAME
          valueFrom:
            fieldRef:
              apiVersion: v1
              fieldPath: spec.nodeName
        - name: WHEREABOUTS_NAMESPACE
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace
        resources:
          requests:
            cpu: "100m"
            memory: "50Mi"
          limits:
            cpu: "100m"
            memory: "50Mi"
      initContainers:
      - name: install-multus-config
        image: gcr.io/gke-release/multus-cni:v4.2.1-gke.6@sha256:25b48b8dbbf6c78a10452836f52dee456514783565b70633a168a39e6d322310
        args:
        - "--cni-conf-dir=/host/etc/cni/net.d"
        - "--multus-conf-file=/tmp/multus-conf/00-multus.conf"
        - "--multus-log-level=verbose"
        - "--multus-kubeconfig-file-host=/var/lib/kubelet/kubeconfig"
        - "--skip-multus-binary-copy=true"
        - "--skip-config-watch=true"
        resources:
          requests:
            cpu: "100m"
            memory: "50Mi"
          limits:
            cpu: "100m"
            memory: "50Mi"
        securityContext:
          privileged: true
        volumeMounts:
        - name: cni
          mountPath: /host/etc/cni/net.d
        - name: multus-cfg
          mountPath: /tmp/multus-conf
      - name: install-whereabouts
        command: ["/bin/sh"]
        args:
        - -c
        - >
          SLEEP=false /install-cni.sh
        image: gcr.io/gke-release/whereabouts:v0.7.0-gke.3@sha256:2bb8450a99d86c73b262f5ccd8c433d3e3abf17d36ee5c3bf1056a1fe479e8c2
        env:
        - name: NODENAME
          valueFrom:
            fieldRef:
              apiVersion: v1
              fieldPath: spec.nodeName
        - name: WHEREABOUTS_NAMESPACE
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace
        resources:
          requests:
            cpu: "100m"
            memory: "50Mi"
          limits:
            cpu: "100m"
            memory: "50Mi"
        securityContext:
          privileged: true
        volumeMounts:
        - name: cni
          mountPath: /host/etc/cni/net.d
        - name: cnibin
          mountPath: /host/opt/cni/bin
      - name: install-binary
        image: gcr.io/gke-release/multus-cni:v4.2.1-gke.6@sha256:25b48b8dbbf6c78a10452836f52dee456514783565b70633a168a39e6d322310
        command: ["/gkecmd"]
        args:
        - "-operation=copy"
        - "-cni-bin-dir=/host/opt/cni/bin"
        resources:
          requests:
            cpu: "10m"
            memory: "100Mi"
          limits:
            cpu: "10m"
            memory: "100Mi"
        securityContext:
          privileged: true
        volumeMounts:
        - name: cnibin
          mountPath: /host/opt/cni/bin
      volumes:
      - hostPath:
          path: /var/lib/kubelet/kubeconfig
          type: File
        name: kubelet-credentials
      - name: cni
        hostPath:
          path: /etc/cni/net.d
          type: DirectoryOrCreate
      - name: cnibin
        hostPath:
          path: /home/kubernetes/bin
          type: DirectoryOrCreate
      - name: multus-cfg
        configMap:
          name: multus-cni-config
          items:
          - key: cni-conf.json
            path: 00-multus.conf
  updateStrategy:
    rollingUpdate:
      maxUnavailable: 2
    type: RollingUpdate

Wenden Sie dann das Manifest auf Ihren Cluster an:

kubectl apply -f multus-manifest.yaml

NetworkAttachmentDefinition-Manifest erstellen

Damit Pods eine Verbindung zu zusätzlichen Netzwerken herstellen können, erstellen Sie ein NetworkAttachmentDefinition-Manifest. In diesem Manifest wird definiert, wie Pods eine Verbindung zu einem Netzwerk herstellen, und der IP-Adressbereich angegeben, der von einem IPAM-Plug-in wie Whereabouts zugewiesen wird. Dieser Bereich muss Teil des Subnetzes sein, das die zusätzlichen Netzwerkschnittstellen Ihrer Knoten verbindet.

  1. Speichern Sie dieses Manifest als nad.yaml. Dieses Manifest verwendet die Plug-ins IPVLAN und Whereabouts.

    apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: NAD_NAME
spec:
  config: '{
    "cniVersion": "0.3.1",
    "plugins": [
      {
        "type": "ipvlan",
        "master": "eth1",
        "mode": "l2",
        "ipam": {
          "type": "whereabouts",
          "range": SECONDARY_RANGE_NAME
        }
      }
    ]
  }'

    Das Manifest enthält die folgenden Felder:

    • NAD_NAME: der Name Ihrer NetworkAttachmentDefinition.
    • master: der Name der sekundären Netzwerkschnittstelle des Knotens, die als master-Schnittstelle für IPVLAN fungiert. In GKE beginnen sekundäre Netzwerkschnittstellen in der Regel mit eth1 und werden sequenziell benannt. Um den Schnittstellennamen zu bestätigen, stellen Sie mit SSH eine Verbindung zu einem Knoten her und führen Sie den Befehl ip addr aus.
    • range: der IP-Adressbereich für Pod-Schnittstellen, der mit dem sekundären IPv4-Bereich identisch ist, den Sie für die Pods erstellt haben (SECONDARY_RANGE_NAME). Beispiel: 172.16.1.0/24.

  2. Wenden Sie das Manifest auf Ihren Cluster an:

    kubectl apply -f nad.yaml

Pods an zusätzliche Netzwerke anhängen

Wenn Sie einen Pod an ein zusätzliches Netzwerk anhängen möchten, fügen Sie dem Pod-Manifest die Annotation k8s.v1.cni.cncf.io/networks hinzu. Für mehrere Netzwerke geben Sie eine durch Kommas getrennte Liste von NetworkAttachmentDefinition Namen im folgenden Format an: <namespace>/<nad-name>.

Das folgende Beispiel zeigt ein Pod-Manifest, das an die NetworkAttachmentDefinition mit dem Namen NAD_NAME im Namespace default angehängt wird:

apiVersion: v1
kind: Pod
metadata:
  name: samplepod
  annotations:
    k8s.v1.cni.cncf.io/networks: default/NAD_NAME
spec:
  containers:
  - name: sample-container
    image: nginx

Ersetzen Sie NAD_NAME durch den Namen der von Ihnen erstellten NetworkAttachmentDefinition.

Wenn Sie dieses Manifest anwenden, erstellt Kubernetes den Pod mit einer zusätzlichen Netzwerkschnittstelle (net1), die mit dem Netzwerk verbunden ist, das in der NetworkAttachmentDefinition angegeben ist.

Zusätzliche IP-Adresse des Pods prüfen

Prüfen Sie die Netzwerkschnittstellen im Pod, um zu bestätigen, dass der Pod eine zusätzliche IP-Adresse erhält, nachdem Sie ihn an ein zusätzliches Netzwerk angehängt haben:

  1. Verwenden Sie den folgenden Befehl, um samplepod zu prüfen und die zusätzliche IP-Adresse zu bestätigen:

    $kubectl describe pod PODNAME

    Ersetzen Sie PODNAME durch den Namen Ihres Pods, z. B. samplepod.

  2. Prüfen Sie die Ausgabe. Die Schnittstelle eth0 hat die primäre IP-Adresse des Pods. Das Whereabouts-Plug-in weist die zusätzliche IP-Adresse einer anderen Schnittstelle zu, z. B. net1.

    Die Ausgabe sieht etwa so aus:

    k8s.v1.cni.cncf.io/network-status:
  [{
    "name": "gke-pod-network",
    "interface": "eth0",
    "ips": [
      "10.104.3.4"
    ],
    "mac": "ea:e2:f6:ce:18:b5",
    "default": true,
    "dns": {},
    "gateway": [
      "\u003cnil\u003e"
    ]
  },{
    "name": "default/my-nad",
    "interface": "net1",
    "ips": [
      "10.200.1.1"
    ],
    "mac": "42:01:64:c8:c8:07",
    "dns": {}
  }]
k8s.v1.cni.cncf.io/networks: default/my-nad

    In diesem Beispiel ist 10.104.5.19 die primäre IP-Adresse auf eth0 und 10.200.1.1 die zusätzliche IP-Adresse auf net1.

Nächste Schritte