Diese Seite wurde von der Cloud Translation API übersetzt.

Multus mit IPVLAN und Whereabouts konfigurieren

Standard

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

Das IPVLAN CNI-Plug-in bietet Layer 2-Verbindungen 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 von Traffic auf der Steuerungsebene und der Datenebene für eine verbesserte Netzwerkisolation 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.

Machen Sie sich vor dem Lesen dieses Dokuments mit den folgenden Konzepten vertraut:

Vorteile der Verwendung von Multus mit IPVLAN

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

Traffic-Isolation:Isolieren Sie verschiedene Arten von Traffic, um die Sicherheit und Leistung zu verbessern. So können Sie beispielsweise sensiblen Verwaltungs-Traffic vom Anwendungsdaten-Traffic trennen.
Trennung von Steuerungs- und Datenebene:Die primäre Netzwerkschnittstelle wird für den Traffic auf der Steuerungsebene verwendet, während der Datenebenen-Traffic mit hohem Durchsatz über eine sekundäre IPVLAN-Schnittstelle geleitet wird.
Layer 2-Nachbarschaft:Erfüllt die Anforderungen für Anwendungen, die eine direkte Layer 2-Verbindung zwischen Pods im selben sekundären Netzwerk benötigen.

Beschränkungen

Pods, die mit Multus-Schnittstellen konfiguriert sind, können die integrierten Multi-Networking-Funktionen von GKE nicht gleichzeitig verwenden. Für die Netzwerkkonfiguration eines Pods muss entweder Multus oder das integrierte Multi-Networking des Clusters verwendet werden.

So funktioniert Multus mit IPVLAN und Whereabouts

Multus ist ein CNI-Metaplug‑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 einem NetworkAttachmentDefinition, das 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 verarbeiten.

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

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 standardmäßige Clusterkonnektivität.
Zusätzliche Schnittstellen (net1 usw.): Multus verwaltet diese Schnittstellen. Multus ruft das IPVLAN-CNI-Plug-in im Layer 2-Modus für jede NetworkAttachmentDefinition auf, die Sie in den Anmerkungen eines Pods angeben. Diese Konfiguration bietet eine Ebene-2-Verbindung 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 Anmerkungen ein 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. Durch diesen Knotenidentifizierungsprozess wird sichergestellt, 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 den IPVLAN- und Whereabouts-Plug-ins in Ihrem GKE-Cluster konfigurieren.

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 diesen Task 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 dem Befehl gcloud components update ab. In früheren gcloud CLI-Versionen werden die Befehle in diesem Dokument möglicherweise nicht unterstützt.
Hinweis: Legen Sie für vorhandene Installationen der gcloud CLI das compute/region-Attribut fest. Wenn Sie hauptsächlich zonale Cluster verwenden, legen Sie stattdessen compute/zone fest. Wenn Sie einen standardmäßigen Speicherort festlegen, können Sie in der gcloud CLI Fehler wie diesen vermeiden: One of [--zone, --region] must be supplied: Please specify location. Bei bestimmten Befehlen müssen Sie möglicherweise den Speicherort angeben, wenn er sich von dem von Ihnen festgelegten Standard unterscheidet.

Installieren Sie das kubectl-Befehlszeilentool.
Richten Sie einen GKE-Cluster mit Version 1.28 oder höher ein, für den Dataplane V2, IP-Alias und Multi-Netzwerke aktiviert sind. Informationen zum Einrichten der Unterstützung mehrerer Netzwerke für Pods Wenn Sie Multi-Networking aktivieren, werden auch die Funktionen „Multi-IP-Subnetz“ und „Persistent-IP-HA-Richtlinie“ aktiviert. Dadurch entfällt die Notwendigkeit, die Inter-Node-Konnektivität manuell einzurichten.
Verwenden Sie eine von GKE validierte Version von Multus CNI (z. B. v4.2.1), um die Kompatibilität zu gewährleisten.

VPC einrichten

Führen Sie die folgenden Schritte aus, um die Virtual Private Cloud (VPC) für die Verwendung mit Multus einzurichten. Dazu gehört auch das Erstellen eines Subnetzes für das Knotennetzwerk und sekundärer Bereiche für das Pod-Netzwerk:

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.
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

So erstellen Sie einen GKE Standard-Cluster mit aktivierter Multi-Networking-Funktion:

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

Ersetzen Sie Folgendes:

CLUSTER_NAME ist 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-Networking aktivieren, können Sie Knotenpools mit mehreren Netzwerkschnittstellen erstellen, was für Multus CNI erforderlich ist.

GKE Standard-Knotenpool erstellen

GKE-Standardknotenpool erstellen, 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: 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 Netzwerkschnittstelle 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 Funktionen für mehrere Netzwerke 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 das Manifest dann auf Ihren Cluster an:

kubectl apply -f multus-manifest.yaml

`NetworkAttachmentDefinition`-Manifest erstellen

Damit Pods eine Verbindung zu zusätzlichen Netzwerken herstellen können, müssen Sie ein NetworkAttachmentDefinition-Manifest erstellen. Dieses Manifest definiert, wie Pods eine Verbindung zu einem Netzwerk herstellen, und gibt den IP-Adressbereich an, 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.

Speichern Sie dieses Manifest als nad.yaml. In diesem Manifest werden die IPVLAN- und Whereabouts-Plug-ins verwendet.
```
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 Ihres NetworkAttachmentDefinition.
- master: 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), z. B. 172.16.1.0/24.
Wenden Sie das Manifest auf Ihren Cluster an:
```
kubectl apply -f nad.yaml
```

Pods mit zusätzlichen Netzwerken verbinden

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. Wenn Sie mehrere Netzwerke angeben möchten, 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 das 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 NetworkAttachmentDefinition, die Sie erstellt haben.

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

Zusätzliche IP-Adresse des Pods prüfen

So prüfen Sie, ob der Pod eine zusätzliche IP-Adresse erhält, nachdem Sie ihn an ein zusätzliches Netzwerk angehängt haben:

Verwenden Sie den folgenden Befehl, um die 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.

Sehen Sie sich die Ausgabe an. Die eth0-Schnittstelle 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.

Multus mit IPVLAN und Whereabouts konfigurieren Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.