NETWAYS Managed Kubernetes® v1 vs. v2
Seit Dezember 2025 bietet NETWAYS Managed Kubernetes® zwei verschiedene Deploymentmodelle an:
- von OpenStack Magnum provisionierte und gemanagte Cluster (v1)
- von Gardener provisionierte und gemanagte Cluster (v2)
Daraus ergeben sich einige Unterschiede in der Handhabe der erstellten Cluster, die im Folgenden aufgelistet sind.
Abkündigung von NETWAYS Managed Kubernetes® v1
Ein offizielles End of Life (EOL) für NETWAYS Managed Kubernetes® v1 ist noch nicht bekannt. Nach Festlegung eines Datums werden betroffene Kunden und Projekte von NWS informiert.
Starten von NETWAYS Managed Kubernetes® Clustern
Cluster in beiden Versionen können weiterhin wie gewohnt über MyNWS gestartet werden. Die Version des Clusters ergibt sich hierbei aus dem zugrundeliegenden Projekt. Die Version eines Projekts ergibt sich aus dem Projektnamen:
XXXXX-kubernetes-XXXXX: OpenStack Magnum Projekt (v1)XXXXX-gardener-XXXXX: Gardener Projekt (v2)
In bestehenden v1 Projekten können weiterhin v1 Cluster erstellt werden. Unsere Empfehlung ist allerdings, neue Cluster in einem Gardener-Projekt zu erstellen.
Sichtbarkeit von Ressourcen im Cluster
Durch die unterschiedliche Provisionierung von NETWAYS Managed Kubernetes® Clustern in v1 vs. v2 unterscheiden sich die im Cluster laufenden (bzw. sichtbaren) Ressourcen voneinander.
Wegfallende Ressourcen in NETWAYS Managed Kubernetes® v2
Folgende Ressourcen fallen in NETWAYS Managed Kubernetes® v2 bei gleicher Konfiguration in MyNWS weg bzw. sind nicht mehr über die API einsehbar:
cluster-autoscaler(falls Autoscaling in v1 Clustern aktiviert)csi-cinder-controllerpluginetcd-backup-jobetcd-proxyk8s-keystone-authkube-dns-autoscaleropenstack-cloud-controller-manager
Neue Ressourcen in NETWAYS Managed Kubernetes® v2
Folgende Ressourcen sind in NETWAYS Managed Kubernetes® v2 bei gleicher Konfiguration in MyNWS neu bzw. neu über die API einsehbar:
apiserver-proxyblackbox-exportercsi-driver-nodehubble-generate-certsnode-exportervpn-shoot
Abweichende CIDRs bei Clustererstellung
Bei der Provisionierung von Clustern nutzt NETWAYS Managed Kubernetes® v2 *andere CIDRs als v1. Dies gilt es bei manchen Konfigurationen (bspw. von NetworkPolicies oder Controllern, die mit der Kubernetes-API sprechen müssen) zu beachten.
Die Default-CIDRs für NETWAYS Managed Kubernetes® v1 bzw. v2 lauten wie folgt:
| CIDR | v1 | v2 |
|---|---|---|
| Pods | 10.100.0.0/16 |
10.0.0.0/16 |
| Nodes | 10.69.0.0/16 |
10.1.0.0/16 |
| Services | 10.254.0.0/16 |
10.2.0.0/16 |
Verfügbare Container Networking Interfaces (CNIs)
Die verfügbaren Container Networking Interfaces (CNIs) unterscheiden sich zwischen NETWAYS Managed Kubernetes® v1 bzw. v2.
In v1 sind Flannel (Default) und Cilium verfügbar. In v2 sind Cilium (Default) und Calico verfügbar.
Hintergrund des Wegfalls von Flannel als unterstützte CNI ist, dass Gardener automatisiert einige NetworkPolicies im Cluster ausspielt und Flannel diese Kubernetes-Ressource nicht unterstützt.
Default NetworkPolicies
Gardener spielt automatisiert einige NetworkPolicies zur Unterbindung von Ost-/West-Traffic im kube-system Namespace aus. Um diese zu umgehen, ist ein entsprechendes Labeling der gewünschten Anwendungen notwendig.
In der folgenden Tabelle ist eine vollständige Übersicht aller ausgespielten NetworkPolicies, ihrer Effekte und der benötigten Labels gegeben:
| Policy-Name | Effekt | Betroffene Label |
|---|---|---|
gardener.cloud--allow-dns |
Erlaubt Ingress zu CoreDNS. Erlaubt Egress von CoreDNS auf die Kubernetes API. | k8s-app=kube-dns |
gardener.cloud--allow-from-seed |
Erlaubt Ingress vom externen Controlplane des Clusters. | networking.gardener.cloud/from-seed=allow |
gardener.cloud--allow-to-apiserver |
Erlaubt Egress zur Kubernetes API. | networking.gardener.cloud/to-apiserver=allowed |
gardener.cloud--allow-to-dns |
Erlaubt Egress zu CoreDNS. | networking.gardener.cloud/to-dns=allowed |
gardener.cloud--allow-to-kubelet |
Erlaubt Egress zum Kubelet. | networking.gardener.cloud/to-kubelet=allowed |
gardener.cloud--allow-to-public-networks |
Erlaubt Egress in alle Netzwerke. | networking.gardener.cloud/to-public-networks=allowed |
gardener.cloud--allow-vpn |
Erlaubt Ingress zum Cluster VPN. Erlaubt Egress vom Cluster VPN. | app=vpn-shoot |
gardener.cloud--deny-all |
Verbietet jeglichen nicht explizit freigegebenen Ingress und Egress. | matcht alle Pods |
NetworkPolicies im kube-system Namespace
Alle oben gelisteten NetworkPolicies beziehen sich ausschließlich auf Workloads im kube-system Namespace.
Best Practice ist es daher, eigene Anwendungen, auch zum Clustermanagement (bspw. ArgoCD, Kyverno, Flux usw.) in dedizierten Namespaces zu deployen. So kann sichergestellt werden, dass die bestehenden NetworkPolicies nicht versehentlich die Kommunikation einschränken.