Kubernetes CNI conectează orice router logic între diferite MACVLAN (subrețea diferită) este posibil?

în prezent, am explorat Multus CNI pentru proiectul meu experimental despre migrarea mașinii virtuale sau a unor aplicații pe care nu le dorim (nu se poate schimba codul sursă) despre adresa IP, așa că am avut constrângerile de a contesta că am trebuie să utilizați IP fix în prezent am reușit să folosesc Multus cu Pod care au IP secundar via MacVLAN pe Node în Kubernetes-ul meu deja. Am avut două subrețele 192.168.15.0/24 (Zona publică) și 192.168.16.0/24 (zonă privată) pentru fiecare IP care rezidă în zona lor (subrețea) se poate conecta cu succes între Kubernetes Node asemănător Muncitorul A conține pod 192.168.15.10 poate ping la Lucrătorul B conține pod 192.168.15.11 deoarece sunt aceeași subrețea (aceeași MACVLAN)

**Dar am nevoie să am un pod cu MACVLAN diferit (subrețea diferită) care se pot conecta împreună ** astfel Muncitorul A conține pod 192.168.15.10 poate ping la Lucrătorul B conține pod 192.168.16.10 (Subrețea publică se conectează la zona de subrețea securizată)

În conceptul de rețea normal, vom solicita Router dreapta ? Pentru că în prezent topologia mea va arăta similar cu această imagine credit: https://www.practicalnetworking.net/stand-alone/routing-between-vlans/

Exemplu de imagine a comutatorului logic când utilizați VLAN

După cum vedem în imagine, în prezent avem o subrețea diferită și nu are o legătură de cablu intermediară între comutator, așa că nu poate ruta/conecta. Deci, cum pot crea un router logic pentru a reuși această încercare? Este posibil ? Sau induc în eroare în orice concept de design Networking/Kubernetes?

În această imagine veți vedea că podul meu de care se atașează Interfață de subrețea publică pot face ping/conectați împreună prin Kubernetes Node deja din cauza macvlan dar dacă folosesc bridge, va necesita ca ambele să locuiască în aceeași gazdă.

Imagine a podului meu și a interfeței de rețea

Vreau să încerc ceva de genul acesta, deoarece vreau să simulez o topologie de rețea similară cu mașina virtuală locală, astfel încât să pot avea o mașină virtuală Migrate automată la Kubernetes fără a schimba codul. (În prezent am explorat și KubeVirt) Dar, în contextul meu, nu am o soluție de întreprindere precum ESXI sau ceva asemănător, doar un instantaneu simplu al mașinii virtuale și să îl încarc în Kubernetes folosind numai KubeVirt, astfel încât Topologia rețelei este baza acestui experiment de migrare.

Vă mulțumesc foarte mult pentru răspunsul la orice idee/ajutor anticipat :)

Iată exemplul meu Exemplu de NetworkAttachmentDefinition

apiVersion: k8s.cni.cncf.io/v1
fel: NetworkAttachmentDefinition
metadate:
  nume: macvlan-public
  namespace: legacy-company
specificație:
  config: >-
    { 
      "cniVersion": "0.3.1", 
      "tip": "macvlan", 
      "bridge": "macvlan-public-zone", 
      „ipam”: {
        "tip": "gazdă-local", 
        „subrețea”: „192.168.15.0/24”, 
        "rangeStart": "192.168.15.10", 
        „rangeEnd”: „192.168.15.200” 
        } 
    }
---
apiVersion: k8s.cni.cncf.io/v1
fel: NetworkAttachmentDefinition
metadate:
  nume: macvlan-secure
  namespace: legacy-company
specificație:
  config: >-
    { 
      "cniVersion": "0.3.1", 
      "tip": "macvlan", 
      "bridge": "macvlan-secure-zone", 
      „ipam”: {
        "tip": "gazdă-local", 
        „subrețea”: „192.168.16.0/24”, 
        "rangeStart": "192.168.16.10", 
        "rangeEnd": "192.168.16.200" 
        } 
    }
---

Exemplu de pod cu interfață de rețea secundară Multus

fel: Desfăşurare
apiVersion: apps/v1
metadate:
  nume: pod-public
  etichete:
    aplicație: bridge-public
specificație:
  replici: 1
  selector:
    matchLabels:
      aplicație: bridge-public
  șablon:
    metadate:
      etichete:
        aplicație: bridge-public
      adnotari:
        k8s.v1.cni.cncf.io/networks: „[
                { "nume": "macvlan-public"}]'
    specificație:
      nodeSelector:
        kubernetes.io/nume gazdă: 10.111.147.164 
      serviceAccountName: implicit
      containere:
        - denumire: pod-public
          imagine: „quay.io/linxianer12/nettool:0.0.4”
          imagePullPolicy: Întotdeauna
          securityContext:
            capacitati:
              adăuga:
                - „NET_RAW”
      restartPolicy: Întotdeauna
      terminationGracePeriodSeconds: 30
      dnsPolicy: ClusterFirst
---
fel: Desfăşurare
apiVersion: apps/v1
metadate:
  nume: bridge-secure
  etichete:
    aplicație: bridge-secure
specificație:
  replici: 1
  selector:
    matchLabels:
      aplicație: bridge-secure
  șablon:
    metadate:
      etichete:
        aplicație: bridge-secure
      adnotari:
        k8s.v1.cni.cncf.io/networks: „[
                { „nume”: „macvlan-secure”}]”
    specificație:
      serviceAccountName: implicit
      containere:
        - nume: bridge-secure
          imagine: „quay.io/linxianer12/nettool:0.0.4”
          imagePullPolicy: Întotdeauna
          securityContext:
            capacitati:
              adăuga:
                - „NET_RAW”