Skip to content

NETWAYS Managed Kubernetes® v1 vs. v2

Since December 2025, NETWAYS Managed Kubernetes® offers two different deployment models:

  • clusters provisioned and managed by OpenStack Magnum (v1)
  • clusters provisioned and managed by Gardener (v2)

This results in several differences in the handling of the created clusters, which are listed below.

Deprecation of NETWAYS Managed Kubernetes® v1

An official End of Life (EOL) date for NETWAYS Managed Kubernetes® v1 has not been set yet. Once a date is set, affected customers and projects will be informed by NWS.

Starting NETWAYS Managed Kubernetes® Clusters

Clusters in both versions can still be started as usual via MyNWS. The version of the cluster is derived from the underlying project. The version of a project is determined by the project name:

  • XXXXX-kubernetes-XXXXX: OpenStack Magnum project (v1)
  • XXXXX-gardener-XXXXX: Gardener project (v2)

In existing v1 projects, v1 clusters can still be created. However, we recommend creating new clusters in a Gardener project.

Visibility of Resources in the Cluster

Due to the different provisioning of NETWAYS Managed Kubernetes® clusters in v1 vs. v2, the resources running (or visible) in the cluster differ from each other.

Resources removed in NETWAYS Managed Kubernetes® v2

The following resources are removed in NETWAYS Managed Kubernetes® v2 with the same configuration in MyNWS or are no longer visible via the API:

  • cluster-autoscaler (if autoscaling is enabled in v1 clusters)
  • csi-cinder-controllerplugin
  • etcd-backup-job
  • etcd-proxy
  • k8s-keystone-auth
  • kube-dns-autoscaler
  • openstack-cloud-controller-manager

New resources in NETWAYS Managed Kubernetes® v2

The following resources are new in NETWAYS Managed Kubernetes® v2 with the same configuration in MyNWS or are newly visible via the API:

  • apiserver-proxy
  • blackbox-exporter
  • csi-driver-node
  • hubble-generate-certs
  • node-exporter
  • vpn-shoot

Different CIDRs When Creating Clusters

When provisioning clusters, NETWAYS Managed Kubernetes® v2 uses different CIDRs than v1. This must be taken into account for certain configurations (e.g., NetworkPolicies or controllers that need to communicate with the Kubernetes API).

The default CIDRs for NETWAYS Managed Kubernetes® v1 and v2 are as follows:

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

Available Container Networking Interfaces (CNIs)

The available Container Networking Interfaces (CNIs) differ between NETWAYS Managed Kubernetes® v1 and v2.

In v1, Flannel (default) and Cilium are available. In v2, Cilium (default) and Calico are available.

The reason for the removal of Flannel as a supported CNI is that Gardener automatically deploys certain NetworkPolicies in the cluster, and Flannel does not support this Kubernetes resource.

Default NetworkPolicies

Gardener automatically deploys several NetworkPolicies to block east‑west traffic in the kube-system namespace. To work around this, appropriate labeling of the desired applications is required.

The table below provides a complete overview of all deployed NetworkPolicies, their effects, and the required labels:

Policy Name Effect Affected Labels
gardener.cloud--allow-dns Allows ingress to CoreDNS. Allows egress from CoreDNS to the Kubernetes API. k8s-app=kube-dns
gardener.cloud--allow-from-seed Allows ingress from the external control plane of the cluster. networking.gardener.cloud/from-seed=allow
gardener.cloud--allow-to-apiserver Allows egress to the Kubernetes API. networking.gardener.cloud/to-apiserver=allowed
gardener.cloud--allow-to-dns Allows egress to CoreDNS. networking.gardener.cloud/to-dns=allowed
gardener.cloud--allow-to-kubelet Allows egress to the kubelet. networking.gardener.cloud/to-kubelet=allowed
gardener.cloud--allow-to-public-networks Allows egress to all networks. networking.gardener.cloud/to-public-networks=allowed
gardener.cloud--allow-vpn Allows ingress to the cluster VPN. Allows egress from the cluster VPN. app=vpn-shoot
gardener.cloud--deny-all Denies any ingress or egress that is not explicitly allowed. matches all Pods

NetworkPolicies in the kube-system Namespace

All the NetworkPolicies listed above apply exclusively to workloads in the kube-system namespace.

Best Practice is therefore to deploy your own applications, including those for cluster management (e.g., ArgoCD, Kyverno, Flux, etc.), in dedicated namespaces. This ensures that the existing NetworkPolicies do not unintentionally restrict communication.