Dieses Dokument wurde mithilfe automatisierter maschineller Übersetzungstechnologie übersetzt. Wir bemühen uns um korrekte Übersetzungen, übernehmen jedoch keine Gewähr für die Vollständigkeit, Richtigkeit oder Zuverlässigkeit der übersetzten Inhalte. Im Falle von Abweichungen ist die englische Originalversion maßgebend und stellt den verbindlichen Text dar.

Isolierung von virtuellen Maschinen

Alle Funktionen, die Kube-OVN verwenden, gelten als experimentell. Für weitere Informationen zu experimentellen Funktionen siehe Funktionsbezeichnungen.

Die Isolierung zwischen virtuellen Maschinen wird typischerweise entweder durch VLANs (in traditionellen Netzwerken) oder durch virtuelle Switches (in Kube-OVN) erreicht. Wenn Sie virtuelle Maschinen innerhalb des gleichen virtuellen Switch-Netzwerks isolieren möchten, können Sie eine der folgenden Methoden verwenden, um die erforderliche Mikrosegmentierung zu erreichen:

Subnetz-Zugriffskontrolllisten (ACLs): Regeln auf ein Subnetz anwenden, das von virtuellen Maschinen verwendet wird.
Kubernetes-Netzwerkrichtlinien: Regeln innerhalb von Netzwerk-Namespaces und unter Verwendung von Pod-Selektoren anwenden.

Subnetz-ACLs

Für weitere Informationen über das Schema und die Nutzungshinweise siehe Subnetz-ACL und ACL-API-Referenz in der Kube-OVN-Dokumentation.

Beispiele

Beispiel 1: Alle virtuellen Maschinen innerhalb des 172.20.10.0/24 Subnetzes, mit Ausnahme derjenigen mit den Adressen 172.20.10.2 und 172.20.10.3 im Subnetzbereich 172.20.10.0/30, dürfen miteinander kommunizieren.

Kube-OVN fügt automatisch die Gateway-Adresse 172.20.10.1 zur excludeIps Liste hinzu, wodurch verhindert wird, dass sie virtuellen Maschinen zugewiesen wird. Die Kommunikation zu und von der Gateway-Adresse ist ebenfalls betroffen.

  apiVersion: kubeovn.io/v1
  kind: Subnet
  metadata:
    name: vswitch1
  spec:
    acls:
    - action: drop
      direction: to-lport
      match: ip4.dst == 172.20.10.0/30
      priority: 1005
    - action: drop
      direction: from-lport
      match: ip4.src == 172.20.10.0/30
      priority: 1005
    cidrBlock: 172.20.10.0/24
    excludeIps:
    - 172.20.10.1
    gateway: 172.20.10.1
    gatewayNode: ""
    natOutgoing: false
    private: false
    protocol: IPv4
    provider: vswitch1.default.ovn
    vpc: vpc1

Beispiel 2: Alle virtuellen Maschinen innerhalb des 172.20.10.0/24 Subnetzes, mit Ausnahme derjenigen mit der Adresse 172.20.10.3, dürfen miteinander kommunizieren. Virtuelle Maschinen mit der Adresse 172.20.10.2 dürfen kommunizieren, da die Ausführung der ACL-Regeln auf Priorität basiert. Für dieses Subnetz werden Regeln mit einem Prioritätswert von 1006 vor 1005 ausgeführt.

  apiVersion: kubeovn.io/v1
  kind: Subnet
  metadata:
    name: vswitch1
  spec:
    acls:
    - action: allow
      direction: to-lport
      match: ip4.dst == 172.20.10.2
      priority: 1006
    - action: allow
      direction: from-lport
      match: ip4.src == 172.20.10.2
      priority: 1006
    - action: drop
      direction: to-lport
      match: ip4.dst == 172.20.10.0/30
      priority: 1005
    - action: drop
      direction: from-lport
      match: ip4.src == 172.20.10.0/30
      priority: 1005
    cidrBlock: 172.20.10.0/24
    excludeIps:
    - 172.20.10.1
    gateway: 172.20.10.1
    gatewayNode: ""
    natOutgoing: false
    private: false
    protocol: IPv4
    provider: vswitch1.default.ovn
    vpc: vpc1

Beispiel 3: Virtuelle Maschinen mit der Adresse 172.20.10.2 dürfen mit anderen virtuellen Maschinen kommunizieren. Der Datenverkehr in die entgegengesetzte Richtung ist jedoch blockiert. Keine virtuellen Maschinen dürfen mit 172.20.10.2 kommunizieren.

  apiVersion: kubeovn.io/v1
  kind: Subnet
  metadata:
    name: vswitch1
  spec:
    acls:
    - action: drop
      direction: to-lport
      match: ip4.dst == 172.20.10.2
      priority: 1005
    cidrBlock: 172.20.10.0/24
    excludeIps:
    - 172.20.10.1
    gateway: 172.20.10.1
    gatewayNode: ""
    natOutgoing: false
    private: false
    protocol: IPv4
    provider: vswitch1.default.ovn
    vpc: vpc1

Beispiel 4: TCP-Verkehr, der von Port 9501 und der IP-Adresse 172.20.10.6 stammt, wird im Subnetz vswitch1 blockiert.

  apiVersion: kubeovn.io/v1
  kind: Subnet
  metadata:
    name: vswitch1
  spec:
    acls:
    - action: drop
      direction: from-lport
      match: ip4.src == 172.20.10.6 && tcp.src == 9501
      priority: 1005
    cidrBlock: 172.20.10.0/24
    excludeIps:
    - 172.20.10.1
    gateway: 172.20.10.1
    gatewayNode: ""
    natOutgoing: false
    private: false
    protocol: IPv4
    provider: vswitch1.default.ovn
    vpc: vpc1

Netzwerkrichtlinien

Die Regeln der Netzwerkrichtlinie verweigern standardmäßig den Verkehr. Um andere Pods nicht zu beeinträchtigen, stellen Sie sicher, dass Folgendes beachtet wird:

Alle erforderlichen Übereinstimmungsbedingungen sind der Richtlinie hinzugefügt.
Der Verkehr wird mithilfe von Pod-Selektoren und Namespaces isoliert.

Die Beispiele in diesem Dokument konzentrieren sich darauf, die Isolation zwischen virtuellen Maschinen im selben Subnetz zu erreichen.

Für weitere Informationen siehe Netzwerkrichtlinien in der Kubernetes-Dokumentation und NetworkPolicy-Protokollierung in der Kube-OVN-Dokumentation.

Beispiele

Die folgenden virtuellen Maschinen werden im Namespace default erstellt und sind mit dem Overlay-Netzwerk verbunden, das für den Subnetzbereich 172.20.10.0/24 erstellt wurde.

Virtuelle Maschine IP-Adresse

Virtuelle Maschine	IP-Adresse
`VM1`	`172.20.10.2`
`VM2`	`172.20.10.3`
`VM3`	`172.20.10.4`
`VM4`	`172.20.10.5`
`VM5`	`172.20.10.6`

VM1

172.20.10.2

VM2

172.20.10.3

VM3

172.20.10.4

VM4

172.20.10.5

VM5

172.20.10.6

Beispiel 1: VM1 und VM2 dürfen miteinander kommunizieren, da ihre Adressen im Subnetz 172.20.10.0/30 liegen. Der gesamte übrige Verkehr im Namespace default, einschließlich Verkehr zu und von VM3, VM4 und VM5, wird blockiert.

  apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: ip-block
    namespace: default
  spec:
    egress:
    - to:
      - ipBlock:
          cidr: 172.20.10.0/30
    ingress:
    - from:
      - ipBlock:
          cidr: 172.20.10.0/30
    policyTypes:
    - Ingress
    - Egress

Beispiel 2: VM1 und VM2 dürfen miteinander kommunizieren und mit anderen virtuellen Maschinen im Subnetz 172.20.10.0/24. Andere virtuelle Maschinen in diesem Subnetz können jedoch nicht mit VM1, VM2 und untereinander kommunizieren. Das liegt daran, dass die Eingangsrichtlinie nur Verkehr zulässt, der von 172.20.10.0/30 stammt.
```
  apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: ip-block
    namespace: default
  spec:
    ingress:
    - from:
      - ipBlock:
          cidr: 172.20.10.0/30
    policyTypes:
    - Ingress
```
Beispiel 3: VM1 und VM2 dürfen miteinander kommunizieren, jedoch nicht mit anderen virtuellen Maschinen im Subnetz 172.20.10.0/24. Die anderen virtuellen Maschinen im selben Subnetz können mit VM1 und VM2 kommunizieren. Das liegt daran, dass die Ausgangsrichtlinie den Verkehr zu 172.20.10.0/30 zulässt.
```
  apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: ip-block
    namespace: default
  spec:
    egress:
    - to:
      - ipBlock:
          cidr: 172.20.10.0/30
    policyTypes:
    - egress
```

Beispiel 4: VM2 darf mit VM1 kommunizieren, jedoch nicht mit anderen virtuellen Maschinen im Subnetz 172.20.10.0/24. Das liegt daran, dass ein Pod-Selektor-Label auf VM2 angewendet wird. Alle anderen virtuellen Maschinen im selben Subnetz können mit VM1 und untereinander kommunizieren.

  apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: ip-block
    namespace: default
  spec:
    podSelector:
      matchLabels:
        vm.kubevirt.io/name: VM2
    egress:
    - to:
      - ipBlock:
          cidr: 172.20.10.0/30
    ingress:
    - from:
      - ipBlock:
          cidr: 172.20.10.0/30
    policyTypes:
    - Ingress
    - Egress