KubeVirt en MetalLB

Sudo Friday Kubernetes Networking KubeVirt MetalLB
  Wander Boessenkool

Meestal als je KubeVirt (OpenShift Virtualization voor de OpenShift gebruikers onder ons) draait, en je wilt virtuele machines van buiten het cluster beschikbaar maken, dan grijp je naar zaken als Secundaire netwerken met OVS of Multus. Dit is dan ook de methode die bijvoorbeeld door Red Hat wordt aangeraden voor OpenShift. Het voordeel hiervan is dat het mooi samenwerkt met dingen als UserDefinedNetworks (UDN), VLAN tagging/trunking, etc.

Maar we hebben niet altijd allemaal toegang tot nodes met extra netwerk-kaarten, mooie netwerk setups, enzovoort. Sommige van ons doen veel werk met dingen als Kind, OpenShift Local (CRC), of andere kleine setups. In die gevallen kun je je VMs wel exposen aan het externe netwerk als je een beetje vals speelt door bijvoorbeeld MetalLB te gebruiken.

In deze video laat Wander zien hoe hij een virtuele machine met behulp van een LoadBalancer Service en MetalLB aan het externe netwerk knoopt.

Gerelateerde posts

MetalLB op OpenShift

Om verkeer van buiten een Kubernetes/OpenShift cluster in te krijgen heb je waarschijnlijk een LoadBalancer nodig, om bijvoorbeeld je Ingress te ontsluiten, of om services rechtstreeks aan te bieden. Wanneer je in een cloud omgeving draait biedt je provider waarschijnlijk loadbalancers aan die rechtstreeks door je cluster aangestuurd kunnen worden, maar wanneer je op Baremetal draait, of op LibVirt, of op VMWare, dan missen deze opties.

OpenShift Virtualization

Via het upstream “kubevirt” project is het mogelijk om virtuele machines te draaien als pods op een Kubernetes cluster. Op OpenShift is hier een door Red Hat ondersteunde versie van genaamd “OpenShift Virtualization”. Op deze manier kun je je VMs makkelijk (bijna) hetzelfde beheren als je containers, bijvoorbeeld met een tool als ArgoCD, of met Tekton Pipelines.

Ovn Egress Firewalls op OpenShift

In sommige omgevingen krijgen OpenShift beheerders te horen dat (specifieke) workloads gelimiteerd moeten worden in wat ze (buiten het cluster) kunnen aanspreken aan externe diensten en hosts. Nu kun je dit met standaard NetworkPolicy objecten oplossen, maar aangezien afnemers over het algemeenNetworkPolicy objecten in hun eigen namespaces mogen editen is dit niet de meest robuuste oplossing. Je zou ook kunnen gaan werken met EgressIP objecten, en verkeer van die IP adressen buiten het cluster laten filteren, maar dan kom je al snel in een wereld waar je honderden extra IPv4 adressen nodig hebt. Je zou ook met AdminNetworkPolicy objecten bezig kunnen gaan, maar deze zijn nog redelijk nieuw, en werken nog niet buiten OpenShift. Gelukkig is er ook nog een vierde optie voor gebruikers van het OVN-Kubernetes SDN: EgressFirewalls