k3s op een enkele VPS: wanneer is dit de juiste keuze?

Wat k3s is en wat één node u biedt

k3s is een volledige Kubernetes-distributie verpakt als één binary. Door dit op een enkele VPS te draaien, beschikt u over de echte Kubernetes API zonder dat u een control plane met drie machines nodig heeft. Het is een gecertificeerde Kubernetes-distributie, wat betekent dat een manifest dat hier werkt, later ook op een managed cluster toepasbaar is. De installatie bestaat uit één commando en duurt ongeveer een minuut. De prijs die u betaalt is geheugen dat niet langer beschikbaar is voor uw applicaties, plus een reeks faalmodi die bij Docker Compose nooit voorkomen.

SUSE bouwt k3s voor edge-locaties en kleine installaties; elk verschil met upstream Kubernetes is bedoeld om het pakket kleiner te maken. De standaard datastore is sqlite achter een shim genaamd kine, in plaats van etcd, waardoor er geen etcd-quorum onderhouden hoeft te worden. containerd is ingebed in de binary in plaats van afzonderlijk geïnstalleerd. Dezelfde binary bevat ook CoreDNS voor cluster-DNS, Traefik als ingress controller, ServiceLB (ook wel klipper-lb genoemd) zodat LoadBalancer-services werken zonder cloudprovider, de local-path provisioner voor persistent volumes, metrics-server en flannel voor pod-netwerken. Al deze onderdelen starten standaard op. Daarom is het hieronder beschreven poortconflict het meest voorkomende eerste probleem op een VPS die al in gebruik was.

Wanneer een enkele k3s-node de juiste keuze is

Gebruik k3s wanneer de Kubernetes API het doel is: u leert Kubernetes op een machine die u beheert, of de software die u wilt draaien is enkel beschikbaar via een Helm chart. De overdraagbaarheid van manifesten is ook een voordeel, omdat een Deployment die u hier schrijft ongewijzigd naar een beheerd cluster kan worden verplaatst. Gebruik Docker Compose wanneer de applicaties zelf het doel zijn. Compose start dezelfde containers met aanzienlijk minder complexe onderdelen, en een Compose file op een VPS is een jaar later eenvoudiger te lezen dan een map vol manifesten.

Wees u bewust van wat één node u niet biedt.

• Geen hoge beschikbaarheid. Wanneer de VPS herstart, stoppen alle workloads. Kubernetes probeert een pod opnieuw in te plannen op een andere node, maar die is er niet.
• Geen rolling update die een service online houdt, tenzij de applicatie twee replica's op één machine toestaat die hetzelfde volume delen.
• Opslag die gebonden is aan de machine, om de reden die in de onderstaande sectie over local-path wordt beschreven.
• Een control plane die ongeveer een gigabyte aan RAM verbruikt, ongeacht of u iets implementeert of niet.

Dit maakt k3s geen slechte keuze. Het maakt het echter een slechte keuze om de reden die mensen meestal aanvoeren: betrouwbaarheid. Als u in werkelijkheid meerdere machines wilt om een echt multi-node cluster te bouwen, dan komt die beslissing eerst: Proxmox op eigen hardware versus een gehuurde VPS bepaalt waar de nodes vandaan komen voordat k3s bepaalt wat er op die nodes draait.

Wat k3s verbruikt aan RAM en CPU voordat u iets implementeert

Het k3s-project publiceert gemeten waarden in plaats van schattingen. Lees deze zorgvuldig, want het getal dat vaak wordt genoemd, is niet het verbruik van een inactieve k3s-installatie.

[
  {
    "label": "Server, sqlite datastore",
    "ram_mb": "1,596",
    "cpu_percent_of_one_core": 6
  },
  {
    "label": "Server, embedded etcd",
    "ram_mb": "1,606",
    "cpu_percent_of_one_core": 6
  },
  {
    "label": "Agent node only",
    "ram_mb": "275",
    "cpu_percent_of_one_core": 3
  }
]

Een server-node in die test gebruikte 1,596 MB RAM op het 95e percentiel en ongeveer 6 procent van één core. Dit zijn gepubliceerde cijfers, geen metingen uit deze handleiding. De test draaide k3s v1.26.5 met alle meegeleverde componenten ingeschakeld, plus een Prometheus en Grafana monitoring-stack. Het getal bevat dus een werkelijke workload in plaats van een leeg cluster. Het vervangen van sqlite door de ingebouwde etcd verhoogde het verbruik naar 1,606 MB. Een agent-node, die kubelet en containerd draait zonder control plane, gebruikte 275 MB. Het gedocumenteerde minimum voor een server is 2 cores en 2 GB RAM; dit minimum dekt k3s en de meegeleverde componenten vóór uw eigen workloads.

De praktische conclusie: op een 2 GB VPS houden de control plane en de gebundelde add-ons weinig ruimte over. Het eerste wat gebeurt onder druk, is dat de kubelet pods verwijdert (eviction). 4 GB is een comfortabele ondergrens voor één node met enkele kleine services. Meet uw eigen systeem in plaats van te vertrouwen op gepubliceerde cijfers, inclusief deze.

free -h
sudo k3s kubectl top node
sudo k3s kubectl get pods -A

Voer free -h uit voordat u installeert en nogmaals zodra elke pod in kube-system de status Running heeft. Het verschil is wat de control plane kost op uw hardware. k3s kubectl top node geeft error: Metrics API not available terug gedurende de eerste minuut of twee na installatie, omdat metrics-server nog niets heeft verzameld. Dit is geen fout. Als u één systeem tegelijkertijd hiervoor en voor ander werk wilt inrichten, is de berekening in RAM en CPU voor een VPS bepalen ongewijzigd van toepassing.

k3s installeren met een specifieke release in plaats van de nieuwste

De snelstartopdracht die iedereen kopieert, installeert de versie waarnaar het stable-kanaal op dat moment verwijst. Op een machine die u voor langere tijd wilt gebruiken, moet u de versie vastzetten. k3s publiceert een kanaal per Kubernetes minor-versie, dus INSTALL_K3S_CHANNEL=v1.36 volgt patch-releases binnen v1.36 en zal nooit automatisch overstappen naar een volgende minor-versie. Sinds augustus 2026 verwijst het stable-kanaal naar v1.36.3+k3s1.

Schrijf eerst het configuratiebestand en voer daarna de installatie uit. k3s leest /etc/rancher/k3s/config.yaml bij het opstarten, waardoor instellingen in dit bestand zowel bij de eerste keer opstarten als bij alle volgende keren worden toegepast.

sudo mkdir -p /etc/rancher/k3s
sudo tee /etc/rancher/k3s/config.yaml >/dev/null <<'EOF'
tls-san:
  - k3s.example.com
EOF
curl -sfL https://get.k3s.io | INSTALL_K3S_CHANNEL=v1.36 sh -

Gebruik INSTALL_K3S_VERSION=v1.36.3+k3s1 om een specifieke release vast te zetten in plaats van een kanaal. Het plusteken maakt deel uit van de tag. Controleer daarna of de installatie is geslaagd.

k3s --version
sudo systemctl status k3s
sudo k3s kubectl get node
sudo k3s kubectl get pods -A

kubectl get node zou binnen ongeveer dertig seconden één node met STATUS Ready moeten tonen, en elke pod in kube-system zou de status Running of Completed moeten bereiken. Een node die blijft steken op NotReady betekent meestal dat de container runtime niet is gestart; raadpleeg in dat geval sudo journalctl -u k3s -n 100 --no-pager. Voer op een afwijkende VPS-image eerst sudo k3s check-config uit voordat u andere zaken onderzoekt: dit commando rapporteert ontbrekende kernel-functies, wat sneller uitsluitsel geeft dan het lezen van logs.

Waarom poort 80 al in gebruik is en wat u moet opgeven om dit op te lossen

Dit is de fout die vaak optreedt op een VPS die al een andere dienst draaide. De installatie slaagt. Traefik krijgt vervolgens geen adres toegewezen en de site die u al draaide blijft werken, waardoor er niets defect lijkt totdat u een ingress probeert te bereiken.

Het mechanisme: de meegeleverde Traefik-chart maakt een Service van het type LoadBalancer aan op poort 80 en 443. ServiceLB beantwoordt dat verzoek door een DaemonSet van kleine pods aan te maken, genaamd met een svclb--voorvoegsel, die die poortnummers als hostPort op elke node claimen. hostPort publiceert de containerpoort direct in de netwerk-namespace van de node, precies zoals docker run -p 80:80 dat doet. Als nginx, Caddy, Apache of een andere container poort 80 al bezet houdt, zal de kernel deze niet dubbel toewijzen, waardoor de scheduler de pod nergens kan plaatsen.

sudo k3s kubectl -n kube-system get pods
sudo k3s kubectl -n kube-system get svc traefik
sudo ss -lntp '( sport = :80 or sport = :443 )'

U ziet de svclb-pod op Pending staan en de service heeft geen extern adres:

svclb-traefik-8f2c1a-r6k9x   0/2   Pending   0   3m
traefik   LoadBalancer   10.43.62.11   <pending>   80:31480/TCP,443:30219/TCP

Het uitvoeren van kubectl -n kube-system describe pod svclb-traefik-... benoemt de oorzaak direct:

0/1 nodes are available: 1 node(s) didn't have free ports for the requested pod ports.

ss -lntp vertelt u welk proces de poort bezet houdt. Er is meer dan één uitweg, en elke optie heeft een prijs.

Geef de poorten aan k3s. Stop en schakel de bestaande webserver uit en laat Traefik poort 80 en 443 beheren. Dit is de juiste keuze wanneer de VPS uitsluitend als k3s-server gaat dienen en alles wat u serveerde achter een Ingress wordt verplaatst.

Schakel ServiceLB uit en behoud uw bestaande proxy. Installeer met --disable=servicelb. Een Service van het type LoadBalancer wijst nog steeds een NodePort toe, dus Traefik blijft bereikbaar op een hoge poort zoals 31480, en uw nginx of Caddy proxyt naar 127.0.0.1:31480. Wat u opgeeft is het externe adres: de service rapporteert voor altijd <pending>, wat eruitziet als een fout terwijl het een bewuste keuze is.

Schakel Traefik uit en routeer met uw eigen proxy. Installeer met --disable=traefik. U heeft dan geen ingress controller, dus Ingress-objecten doen helemaal niets: ze blijven in de API staan zonder dat een controller ze monitort. Dat is prima wanneer u routeert vanaf een host-proxy naar NodePorts, en het is de eerlijke keuze als u al weet hoe u HTTP wilt afhandelen. Als u nog twijfelt over wat er aan de voorkant moet staan, bepaal dan de keuze tussen nginx, Caddy en Traefik als reverse proxy voordat u iets uitschakelt.

Beide vlaggen horen bij het installatieprogramma of in het configuratiebestand:

tls-san:
  - k3s.example.com
disable:
  - traefik
  - servicelb

Het bewerken van dat bestand na de installatie en het uitvoeren van sudo systemctl restart k3s werkt ook, omdat --disable meer doet dan alleen een component overslaan tijdens de installatie. Het verwijdert ook een component die al is uitgerold, waardoor de wijziging effect heeft op een draaiend cluster.

Om Traefik te behouden maar de configuratie van de chart te wijzigen, moet u /var/lib/rancher/k3s/server/manifests/traefik.yaml niet bewerken. k3s overschrijft dat bestand bij elke start met standaardwaarden. Voeg in plaats daarvan een apart bestand toe in dezelfde map, omdat alles in /var/lib/rancher/k3s/server/manifests automatisch wordt toegepast bij het opstarten en telkens wanneer het bestand op schijf wordt gewijzigd.

apiVersion: helm.cattle.io/v1
kind: HelmChartConfig
metadata:
  name: traefik
  namespace: kube-system
spec:
  valuesContent: |-
    ports:
      web:
        forwardedHeaders:
          trustedIPs:
            - 10.0.0.0/8

Dat voorbeeld stelt één Traefik-chartwaarde in: de vertrouwde proxy-adressen. Hetzelfde mechanisme stelt elke andere waarde in die de chart blootstelt, inclusief de poorten.

Persistente opslag op één node

k3s levert standaard een StorageClass genaamd local-path, ondersteund door de local-path provisioner van Rancher. Een PersistentVolumeClaim zonder storageClassName krijgt deze toegewezen. Volumes bevinden zich in /var/lib/rancher/k3s/storage, met één subdirectory per volume, op de lokale schijf van de node.

sudo k3s kubectl get storageclass
sudo k3s kubectl get pvc -A
sudo ls -l /var/lib/rancher/k3s/storage

Er zijn twee gevolgen van het opslaan op de lokale schijf van de node, die beide pas later problemen veroorzaken.

De StorageClass gebruikt volumeBindingMode: WaitForFirstConsumer, waardoor een nieuwe PVC de status Pending behoudt totdat een pod deze daadwerkelijk mount. kubectl describe pvc toont:

waiting for first consumer to be created before binding

Dit is normaal; het aanmaken van een PVC zonder pod zal de status dus nooit wijzigen.

Zodra het volume is gekoppeld, krijgt het een node-affinity voor de node waarop het is aangemaakt. Hierdoor is elke pod die deze claim gebruikt voor de levensduur van het volume aan die specifieke node gebonden. Op een systeem met één node merkt u hier niets van. Voegt u later een tweede node toe, dan lijkt een pod die weigert te verplaatsen op een scheduler-fout, totdat u kubectl get pv -o yaml uitvoert en de hostname in nodeAffinity ziet staan.

Back-ups zijn uw eigen verantwoordelijkheid. Het opnieuw installeren van de VPS vernietigt die directory, evenals het onderstaande verwijderingsscript. Maak een back-up van /var/lib/rancher/k3s/storage, plus de sqlite-datastore op /var/lib/rancher/k3s/server/db/state.db. Kopieer deze laatste terwijl de service is gestopt, aangezien het een actieve database betreft. Het alternatief is om het cluster als vervangbaar te beschouwen en elk manifest in git te beheren.

Ingress en TLS

Wanneer Traefik ingeschakeld blijft, volstaat een standaard Ingress-object.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: hello
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt
spec:
  ingressClassName: traefik
  tls:
    - hosts:
        - hello.example.com
      secretName: hello-tls
  rules:
    - host: hello.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: hello
                port:
                  number: 80

Certificaten worden niet automatisch aangemaakt. De gebruikelijke oplossing is cert-manager, geïnstalleerd via het gepubliceerde manifest, aangevuld met één ClusterIssuer. Versie v1.21.1 is de huidige versie per augustus 2026.

sudo k3s kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.21.1/cert-manager.yaml

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt
spec:
  acme:
    email: you@example.com
    server: https://acme-v02.api.letsencrypt.org/directory
    privateKeySecretRef:
      name: letsencrypt-account-key
    solvers:
      - http01:
          ingress:
            ingressClassName: traefik

De HTTP-01 challenge houdt in dat de ACME-server (automatic certificate management environment) verbinding maakt met http://hello.example.com/.well-known/acme-challenge/... vanaf het openbare internet. Het DNS A-record moet daarom al naar de VPS verwijzen en poort 80 moet Traefik kunnen bereiken. Als u ServiceLB heeft uitgeschakeld en uw eigen proxy ervoor heeft geplaatst, moet die proxy het challenge-pad eveneens doorsturen; anders blijft cert-manager hangen met de volgende melding op het Challenge-object:

Waiting for HTTP-01 challenge propagation: wrong status code '404', expected '200'

Monitor de uitgifte met sudo k3s kubectl describe certificate hello-tls en sudo k3s kubectl get order,challenge -A.

De kubeconfig, en waarom de API server privé blijft

k3s schrijft beheerdersreferenties naar /etc/rancher/k3s/k3s.yaml. Het bestand is eigendom van root en heeft standaard modus 600. Het bevat een clientcertificaat met cluster-admin rechten; iedereen die dit bestand kan lezen, heeft volledige controle over het cluster.

sudo k3s kubectl get node
export KUBECONFIG=/etc/rancher/k3s/k3s.yaml
kubectl get node

Een afzonderlijk geïnstalleerde kubectl zonder ingestelde KUBECONFIG faalt met The connection to the server localhost:8080 was refused - did you specify the right host or port?, omdat het terugvalt op een standaardlocatie die niet gerelateerd is aan k3s. Stel KUBECONFIG in, of gebruik sudo k3s kubectl, dat het juiste bestand automatisch inleest.

U zult zien dat --write-kubeconfig-mode 644 wordt aanbevolen zodat een normale gebruiker kubectl kan uitvoeren. Begrijp wat dit doet: het maakt cluster-admin referenties leesbaar voor elk lokaal account op de machine. Op een systeem met één beheerder is dit wellicht een acceptabel risico. Op een gedeeld systeem is dat niet het geval. Door het bestand te kopiëren, krijgt één gebruiker toegang zonder de rechten voor iedereen open te stellen:

mkdir -p ~/.kube
sudo install -o $USER -g $USER -m 600 /etc/rancher/k3s/k3s.yaml ~/.kube/config

De server: regel in dat bestand bevat https://127.0.0.1:6443. Open poort 6443 niet voor het internet om kubectl vanaf uw laptop te gebruiken. Een publieke Kubernetes API is een constant doelwit; een blootgestelde API is de manier waarop kleine clusters eindigen met het minen van cryptocurrency voor derden. Tunnel het verkeer via SSH en laat het adres in het bestand ongewijzigd:

ssh -N -L 6443:127.0.0.1:6443 user@your-vps
KUBECONFIG=./k3s.yaml kubectl get node

Indien u de API via een privaat netwerkadres moet bereiken, installeer dan met tls-san waarbij die naam of dat adres wordt opgegeven, en pas vervolgens de server: regel in het gekopieerde bestand aan. Zonder de SAN (subject alternative name) vermelding weigert kubectl de verbinding:

x509: certificate is valid for 127.0.0.1, 10.43.0.1, not 203.0.113.10

De gedocumenteerde inkomende poorten voor een cluster zijn TCP 6443 voor de API, UDP 8472 voor flannel VXLAN tussen nodes, en TCP 10250 voor kubelet metrics. Op een enkele node hoeft geen van deze poorten open te staan naar het internet.

containerd is niet Docker

k3s draait zijn eigen ingebedde containerd en deelt geen image-store met Docker. Een image die u zojuist hebt gebouwd met docker build is onzichtbaar voor k3s, waardoor de pod faalt met ErrImagePull, ook al toont docker images de image wel. Importeer deze expliciet:

docker save myapp:0.1 | sudo k3s ctr images import -
sudo k3s crictl images

Vermijd daarna de :latest-tag op die container, omdat :latest standaard een imagePullPolicy van Always gebruikt en de kubelet alsnog naar een registry gaat. Elke andere tag gebruikt standaard IfNotPresent, wat de image gebruikt die u hebt geïmporteerd. Het draaien van beide op één VPS werkt, en het is nuttig om te weten dat een normale Docker-installatie op een VPS en k3s elk hun eigen image-store en hun eigen iptables-regels op dezelfde machine bijhouden.

k3s verwijderen

Het installatieprogramma schrijft een verwijderingsscript. Er is geen mogelijkheid voor gedeeltelijke verwijdering of een ongedaan-actie.

sudo /usr/local/bin/k3s-uninstall.sh

Dit script stopt en verwijdert de service, wist de datastore, verwijdert de data van persistent volumes, verwijdert de node-configuratie en verwijdert de tools die door het installatieprogramma zijn toegevoegd. Op een agent-node is het script in plaats daarvan k3s-agent-uninstall.sh. Kopieer eerst alle inhoud onder /var/lib/rancher/k3s/storage van de server af, omdat die map wordt verwijderd. Controleer daarna of er geen processen meer zijn die poorten of interfaces bezet houden met ip link show en sudo ss -lntp. Een achtergebleven cni0 of flannel.1 interface wordt bij de volgende herstart gewist.

Besluiten dat één Kubernetes-node meer infrastructuur vereist dan nodig is voor de taak, is een normale uitkomst en geen falen. Het migreren van die workloads terug naar Compose kost doorgaans een middag werk.

Foutmodi en de meldingen die u zult zien

Node NotReady, of k3s start in een lus opnieuw op. Lees eerst sudo journalctl -u k3s -n 200 --no-pager. Op een kleine VPS is de meest voorkomende oorzaak dat de kernel out-of-memory killer het proces beëindigt, wat in dmesg verschijnt als een regel waarin k3s-server wordt genoemd. Het gedocumenteerde minimum van 2 GB is een harde ondergrens.

Pod blijft hangen in Pending. kubectl describe pod benoemt dit telkens. Insufficient memory of Insufficient cpu betekent dat de node geen ruimte meer heeft. didn't have free ports is de eerder genoemde hostPort-botsing. waiting for first consumer bij een PVC betekent dat WaitForFirstConsumer zijn werk doet.

ImagePullBackOff. Of de tag bestaat niet in een registry die de node kan bereiken, of u heeft de image gebouwd met Docker en deze niet geïmporteerd in containerd.

Traefik antwoordt, de app niet. Een response body van 404 page not found komt van Traefik zelf en betekent dat het verzoek is aangekomen, maar dat er geen router overeenkwam. Controleer of de Ingress host overeenkomt met de naam die u heeft ingevoerd, en dat ingressClassName gelijk is aan traefik.

Cluster DNS faalt terwijl de host correct resolveert. Controleer CoreDNS met sudo k3s kubectl -n kube-system logs -l k8s-app=kube-dns. Een melding zoals plugin/loop: Loop ... detected for zone "." zorgt ervoor dat CoreDNS niet start. Dit gebeurt omdat CoreDNS doorstuurt naar een resolver die het verzoek terugstuurt naar CoreDNS zelf; dit is wat een loopback-adres in /etc/resolv.conf veroorzaakt. Wijs k3s naar het werkelijke upstream-bestand met --resolv-conf /run/systemd/resolve/resolv.conf.

FAQ

Is k3s de moeite waard op een enkele VPS?

Het is de moeite waard als u de Kubernetes API wilt gebruiken: om deze te leren op een machine die u beheert, om deployments draagbaar te houden als manifests, om software te draaien die enkel een Helm chart aanbiedt, of om iets te bouwen dat u later naar een managed cluster verplaatst. Het is niet de moeite waard als u enkel containers wilt draaien, omdat Docker Compose dit doet met veel minder onderhoud en ongeveer een gigabyte meer vrij RAM-geheugen. Eén node biedt geen high availability, dus betrouwbaarheid is nooit de reden om hiervoor te kiezen.

Waarom blijft mijn k3s LoadBalancer-service op Pending staan?

ServiceLB maakt svclb--pods aan die de poorten van de service claimen als hostPort op de node, waardoor ze alleen worden ingepland waar die poorten vrij zijn. Als nginx of een andere proxy al poort 80 bezet houdt, blijft de pod op Pending staan en krijgt de service nooit een extern adres. kubectl -n kube-system describe pod svclb-... rapporteert 0/1 nodes are available: 1 node(s) didn't have free ports for the requested pod ports. Maak de poort vrij, of installeer opnieuw met --disable=servicelb en proxy naar de NodePort die de service nog steeds toewijst.

Hoeveel RAM heeft k3s nodig op een VPS?

Het gedocumenteerde minimum voor een server-node is 2 cores en 2 GB; dit dekt k3s en de meegeleverde componenten nog voordat uw workloads worden opgestart. De eigen profilering van het project mat een server-node op 1,596 MB met een monitoring-stack actief, dus beschouw 2 GB als de ondergrens en 4 GB als de eerste grootte waarbij één node comfortabel draait. Meet uw eigen systeem met free -h vóór de installatie en opnieuw nadat elke pod in kube-system de status Running heeft.

Kan ik Docker en k3s op dezelfde VPS draaien?

Ja, ze blijven gescheiden. k3s gebruikt zijn eigen ingebedde containerd, dus een image die is gebouwd met docker build is niet zichtbaar voor k3s totdat u docker save myapp:0.1 | sudo k3s ctr images import - uitvoert. Beide schrijven ook hun eigen iptables-regels en hun eigen bridge-netwerken. Houd het totale geheugengebruik in de gaten, want Docker plus k3s plus uw containers passen niet op een systeem met 2 GB.

Hoe verwijder ik k3s volledig?

Voer sudo /usr/local/bin/k3s-uninstall.sh uit op een server-node, of sudo /usr/local/bin/k3s-agent-uninstall.sh op een agent. Dit stopt de service, verwijdert de datastore, verwijdert data van persistent volumes onder /var/lib/rancher/k3s/storage en verwijdert de meegeleverde tools. Kopieer eerst alle data die u wilt behouden van de server, want dit proces kan niet ongedaan worden gemaakt. Een achtergebleven cni0 of flannel.1 netwerkinterface verdwijnt bij de volgende herstart.