In de wereld van Industrial IoT en fabrieksautomatisering lopen we vaak tegen uitdagingen aan door fysieke en logische netwerkscheidingen. Machinebouwers leveren gestandaardiseerde installaties op die intern allemaal hetzelfde subnet gebruiken. Het probleem wordt blootgelegd op het moment dat zo’n machine aan een centraal Kubernetes cluster gekoppeld moet worden.
Traditioneel wordt dit opgelost door bij elke machine een fysieke NAT-router te plaatsen. Dit is duur, foutgevoelig en lastig schaalbaar. Bovendien is het ingewikkeld om op een goede manier met zo’n IP overlap om te gaan.
In deze blog laat ik zien hoe we met Cilium en eBPF een Kubernetes node laten functioneren als een software defined OT gateway.
De Casus: Bakery-Automation Solutions
Stel je een leverancier voor van geautomatiseerde industriële bakkerijen. Elke productielijn heeft een Siemens PLC, sensoren en displays met vaste IP adressen in het 192.168.2.0/24 subnet. De klant wil vanuit een centraal Kubernetes cluster (waarop Node-RED draait) alle productielijnen over verschillende locaties aansturen.
Normaal is er een afhankelijkheid van kostbare fysieke routers. Hier staat bij elke productielijn een Thin Edge node. Dit is een industriële PC’s uitgerust met Talos Linux, Kubernetes, Cilium en twee netwerkkaarten (Dual-NIC).
De Omgeving
Onze testopstelling bestaat uit een Kubernetes cluster met 4 Talos nodes:
- Nodes 1-3: Control plane nodes.
- Amsterdam-1 (Thin Edge node):
- ens3: Verbonden met het primaire IT-netwerk (het cluster-netwerk).
- ens4: Direct verbonden met de PLC in het geïsoleerde OT-netwerk (192.168.2.x).
- Cilium (eBPF & Egress Gateway zijn ingeschakeld):
Bekijk hier
➜ kubectl get nodes -L locatie
NAME STATUS ROLES AGE VERSION LOCATIE
node-1 Ready control-plane 3h59m v1.35.0
node-2 Ready control-plane 3h59m v1.35.0
node-3 Ready control-plane 3h59m v1.35.0
amsterdam-1 Ready gateway 3h59m v1.35.0 amsterdam-1
Copy code
➜ talosctl -n amsterdam-1 get address ens4/192.168.2.3/24
NODE NAMESPACE TYPE ID LINK
amsterdam-1 network AddressStatus ens4/192.168.2.3/24 ens4
Copy code
De Oplossing: Software Defined Gateway
Met Cilium gebruiken we een feature om het verkeer te routeren zonder dat de PLC doorheeft dat deze met een extern cluster communiceert.
Cilium Egress Gateway
Met een CiliumEgressGatewayPolicy dwingen we verkeer van onze centrale applicatie (de Node-RED pod) om het cluster te verlaten via de specifieke interface van de Thin Edge node (amsterdam-1).
Cilium past met behulp van eBPF dynamisch Source NAT (SNAT) toe. De PLC ziet een inkomend verzoek van 192.168.2.3. De PLC verwerkt het verzoek van de client alsof het verkeer van het lokale netwerk afkomstig is.
apiVersion: cilium.io/v2
kind: CiliumEgressGatewayPolicy
metadata:
name: traffic-to-192-168-2-0
spec:
selectors:
- podSelector:
matchLabels:
io.kubernetes.pod.namespace: amsterdam-1
destinationCIDRs:
- "192.168.2.0/0"
egressGateway:
nodeSelector:
matchLabels:
node-role.kubernetes.io/gateway: "gateway"
locatie: "amsterdam-1"
interface: ens4
Copy code
Proof of Concept: werkt het echt?
Om de setup te valideren draaien we een test-pod op node-1. Deze node heeft fysiek geen verbinding met de fabrieksvloer.
Stap 1: Controleer de routering
We kijken op de Thin Edge node met behulp van Cilium CLI of de policy actief is:
➜ kubectl -n kube-system exec cilium-q6vrs -- cilium bpf egress list
Source IP Destination CIDR Egress IP Gateway IP
10.244.1.167 0.0.0.0/0 192.168.2.3 192.168.4.20
Copy code
Verkeer van onze pod (10.244.1.167) wordt keurig gerouteerd via het IP van de Edge node.
Stap 2: De verbindingstest
We voeren een curl commando uit vanuit de pod op node-1 naar het IP van de PLC:
➜ kubectl -n edge-namespace get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE
curl 1/1 Running 0 71m 10.244.1.167 node-1
➜ kubectl -n amsterdam-1 exec curl -- curl -s http://192.168.2.2
200 OK
Copy code
Het antwoord 200 OK geeft aan dat het opzetten van een verbinding succesvol is. Hoewel de pod op een centrale server in het datacenter draait, bereikt het de PLC op de fabrieksvloer via de Cilium Egress Gateway.
Waarom dit toekomstbestendig is?
De routering verplaatsen van fysieke hardware naar een software defined laag van Cilium heeft de volgende voordelen:
- Kosten: Geen dure industriële routers per machine of productielijn.
- Beheer: Alle netwerkconfiguraties zijn nu vastgelegd in code en worden uitgerold door middel van GitOps. Een omgeving voor een nieuwe machine is een kwestie van een extra YAML bestand plaatsen.
- Security: Het filteren en monitoren van het verkeer kan met Cilium netwerk policies, zelfs voor verkeer dat het cluster verlaat.
Hiermee zijn handmatige NAT configuraties en managed switches op locatie overbodig. Met Cilium maken we de fabrieksvloer echt onderdeel van het software defined network.
