Unit 6.1: Kubernetes Platform Design

Introduction

The decision that governs a Managed Kubernetes design is not "which Kubernetes" but "where does IONOS stop managing and where do you begin". IONOS runs the control plane for you and does not charge for it; you own the worker capacity, the load-balancing edge, the in-cluster network policy, and the compliance posture of everything that runs on top. Treating that line precisely is what separates a design that behaves in production from one that assumes hyperscaler conveniences the platform does not provide.

This unit is design-only. It establishes the architecture and the trade-offs; the public cluster is built in the Data Center Designer in Unit 6.2 and the private variant in Unit 6.3. Read this unit for the boundaries, then build against them.

1. The Managed Boundary: Free Control Plane, Paid Node Pools

Managed Kubernetes is structured as two layers with different ownership, different billing, and different SLAs.

The control plane (kube-apiserver, kube-scheduler, kube-controller-manager, etcd) is fully managed by IONOS and is hidden: its components are not visible to you and cannot be modified directly, and the kube-apiserver is reached only through its REST API. The matrix value for the billing model is plain: the control plane is free of charge. The qualifier matters and must travel with the claim: the service layer is free, but you still pay for the underlying node-pool compute and storage. A statement that "Managed Kubernetes is free" without that qualifier is misleading.

The node pools are the worker capacity. Their servers are ordinary Compute Engine instances provisioned into your Virtual Data Center; within a node pool, all servers are identical in configuration. You choose the server type per pool from Dedicated Core or vCPU. CPU mapping is consistent across both: one provisioned core equals two Managed Kubernetes CPUs (two logical threads per CPU unit).

The two layers carry separate SLAs, and this is a frequent design blind spot:

The control-plane SLA is scoped to the Kubernetes API of the control plane only, not to your workloads and not to node availability. Node pools, being built on Compute Engine, inherit the Compute Engine SLA as a separate, additional commitment. Designing for availability therefore means designing your node pools and your workload for resilience; the managed control-plane SLA does not extend to either.

Operationally, IONOS keeps the control plane current: supported Kubernetes versions are 1.34, 1.33, 1.32, and 1.31, with a maximum minor-version skew of one between the control plane and node pools. The CNI is Calico, fixed, with no option to choose a different CNI, and it is the substrate for the network policies discussed in Section 4.

2. Node Pools as Immutable, Autoscaling Capacity

A node pool is the unit of capacity and the unit of lifecycle. Two properties drive the design.

Nodes are immutable. Nodes are never patched in place. When a node pool is upgraded, whether automatically during the weekly maintenance window or triggered manually for a version change, every node in the pool is rebuilt: an old node is replaced by a new one. Two planning facts follow. First, a rebuild can add an extra billable active node during the replacement, so the contract's server quota must have headroom or the rebuild stalls. Second, anything that must survive a node has to live off the node: persistent state belongs on Block Storage persistent volumes via the CSI provisioner (cloud.ionos.com), never on local disk. The maintenance window is bounded at four hours per run; size your PodDisruptionBudget and replica counts so a rolling replacement never takes the workload below quorum.

Node pools autoscale, but there is no scale-to-zero. The cluster autoscaler grows a pool when pods cannot be scheduled for lack of CPU or memory and shrinks it when nodes stay underutilised and their pods can move elsewhere. It will not exceed the maximum you set (nor the contract quota), and it cannot reduce a pool to zero. The practical floor is one warm node: a cluster that exists costs at least one node per pool you keep alive. Architect cost around that floor by consolidating intermittent workloads onto a shared pool rather than keeping many single-purpose pools each pinned at one warm node.

Sizing limits to design within (recommended versus hard ceilings are distinct and must not be conflated):

The pattern is one node pool per workload class (for example, a pool for general services and a separate pool for memory-heavy or Dedicated-Core-bound workloads), each with its own autoscaling band, sitting on a floor of one node.

3. The Four Boundaries

These are the substance of the unit. Each is a place where Managed Kubernetes does not behave like a hyperscaler-managed offering, and each has a native pattern to compose around it.

3.1 A LoadBalancer Service is a single-node static IP, not a managed load balancer

This is the boundary most likely to cause an outage if it is misunderstood. The current implementation of a service of type LoadBalancer does not deploy a true load balancer in front of the cluster. Instead, IONOS reserves a static public IP address and assigns it as a secondary IP to a single worker node, which then acts as the ingress node. If the target pod is not running on that node, kube-proxy NATs the traffic to wherever the pod lives.

Three consequences follow directly:

• No high availability from the service itself. One node carries the IP. If it fails, that endpoint is down until the IP is reassigned.
• Source IP is lost unless you set externalTrafficPolicy: Local, because kube-proxy NATs the traffic.
• Throughput is bounded by that one node's public interface, which is up to 2 Gbit/s. You do not get aggregate cluster bandwidth at the service IP.

The native pattern is to expose only the ingress controller as a LoadBalancer service and route everything else through in-cluster ingress. To scale beyond one node's ceiling, you reserve multiple static IPs and spread them across multiple ingress nodes (one IP per node, distributed by DNS), reserving those IPs outside the cluster so they survive node rebuilds. Note also that the LoadBalancer service type is supported on public node pools only; private node pools do not support it and lack static node IPs. Where you need genuine managed Layer 7 routing with TLS termination, that is the separately provisioned Managed Application Load Balancer from Module 3, placed in front of the cluster; it is not auto-provisioned from a manifest. Unit 6.2 covers wiring that managed ingress.

3.2 Control-plane events do not reach the Logging Service

Node-pool logs flow to the IONOS Logging Service (export to Object Storage is supported), but the managed control plane's events do not. Because the control plane is hidden and operated by IONOS, its component logs are outside your telemetry plane. You will not find kube-apiserver or scheduler events in your logging pipeline.

Design around this by instrumenting what you do own: application and node-level logs through the in-cluster logging stack to the Logging Service or Object Storage, and Kubernetes API audit visibility built from your own resources. Do not design an alerting or forensic workflow that assumes control-plane event logs are available; they are not, and Unit 7.2 treats this as one of the platform's fixed observability gaps.

3.3 Security groups cannot be applied to Managed Kubernetes worker nodes

NIC-level firewalls and Network Security Groups cannot be applied to Managed Kubernetes worker nodes at all: node-pool nodes are explicitly excluded from NSG membership, and NSGs likewise do not apply to the managed control plane or to managed load balancers. A security group has no attachment point on cluster infrastructure at all.

The only segmentation mechanism available at the pod and namespace level is in-cluster Kubernetes network policies, enforced by the fixed Calico CNI; NIC firewalls and Network Security Groups are not an option for node-level perimeter control on Managed Kubernetes. Traffic between nodes and the control plane is itself secured by mutual TLS, so node-to-control-plane confidentiality is handled by the platform; your job is east-west workload policy inside the cluster.

3.4 Compliance attribution covers infrastructure, not workloads

Managed Kubernetes sits within the ISO 27001 certificate based on IT-Grundschutz (granted by the BSI on 2022-09-14, German data centers). It is not within the BSI C5 attestation: C5 (a Type 1 Testat granted 2023-11-07) covers Compute Engine, Cloud Cubes, and S3 Object Storage, but not Managed Kubernetes. State the scope precisely and never generalise to "the platform is certified".

The deeper point is the attribution boundary. These credentials cover the IONOS infrastructure layer only: the managed service, the data centers, the operational controls. They do not attest your workloads. Your container images, RBAC configuration, network policies, secrets handling, and application data remain your responsibility and your evidence to produce in any audit. IONOS encrypts secret data at rest and secures the node-to-control-plane channel with mutual TLS, which are infrastructure controls; the security of what runs in the pods is the customer's. For a regulated workload, the IT-Grundschutz scope is the floor of the shared-responsibility line, not the whole compliance story.

4. Control-Plane Placement and Sovereignty

Where the control plane runs is a sovereignty decision, and it is cluster-type dependent. For a public cluster, the IONOS-managed control plane runs in Frankfurt or in one of the three US data centers (Lenexa, Newark, Las Vegas). For a private cluster, the control plane can be created in any data center, that is, the customer's chosen region.

Sovereignty follows the chosen location. Choose the German (Frankfurt) control plane and control-plane data stays in Germany, preserving EU and German sovereignty. Choose a US control plane and control-plane metadata resides in the US, so German sovereignty is not obtained for that metadata. In all cases, node-pool workloads and their data remain in the chosen customer region regardless of where the control plane sits.

For a regulated German workload, this is decisive: a public cluster left to default placement can put control-plane metadata in a US data center, which carries US jurisdictional exposure even though the worker data never leaves Germany. The design response is to pin the control plane to Frankfurt for a public cluster, or to use a private cluster (control plane in the chosen German region) when the requirement is that no control-plane metadata leaves the country. This connects directly back to the sovereignty foundation in Unit 1.4: sovereignty is a property of where data is operated, applied as a filter over every placement decision, including this one.

Enterprise Case Study (FinCorp)

FinCorp, the German financial-services firm under GDPR and BSI obligations, is standing up its container platform for the new AI-adjacent services. The boundaries above shape the design.

Because the first cluster fronts a customer-facing API, it is a public cluster, so the architects pin its control plane to Frankfurt rather than accept default placement that could land metadata in a US data center; the node pools sit in the German region with the workloads.

They define two node pools: a general-services pool (vCPU, autoscaling 1 to 6) and a Dedicated-Core pool for a latency-sensitive service (autoscaling 1 to 4). Both honour the one-warm-node floor, and FinCorp accepts two always-on nodes as the price of isolating the two workload classes. Persistent state goes on CSI Block Storage volumes, and quota headroom is reserved so a maintenance rebuild's extra billable node never stalls.

At the edge, FinCorp exposes only an ingress controller and places a separately provisioned Managed Application Load Balancer in front for the HA and TLS termination a single-node ingress IP cannot offer. Inside the cluster, Calico network policies segment the customer-facing namespace from internal services; NIC-level Network Security Groups cannot be applied to the worker nodes at all, since node-pool nodes are excluded from NSG membership. For audit, FinCorp records that IT-Grundschutz covers the Managed Kubernetes infrastructure while its own images, RBAC, and application data remain FinCorp's evidence to produce, and it forwards application and node logs to Object Storage knowing control-plane events will not appear there.

Decision Summary

Summary

Managed Kubernetes gives you a free, fully managed control plane under its own 99.95% API SLA and leaves you owning billable node pools (with their inherited Compute Engine SLA), the load-balancing edge, in-cluster network policy, observability of what you run, and the compliance of your workloads. Design the node pools as immutable, autoscaling capacity with a one-warm-node floor, and architect deliberately around the four boundaries, because each one is a place where assuming hyperscaler behaviour produces an outage, a blind spot, or a failed audit.

Key Points:

• The control plane is free and managed under a 99.95% API-only SLA; node pools are billable Compute Engine capacity under a separate inherited 99.95% SLA. Keep the "you pay for the infrastructure" qualifier on any "free" claim.
• Nodes are immutable and rebuilt on every upgrade or weekly maintenance run; keep state on CSI Block Storage volumes and keep server-quota headroom for the extra billable rebuild node.
• There is no scale-to-zero; the autoscaling floor is one warm node per pool, so consolidate intermittent workloads rather than running many single-purpose pools.
• A LoadBalancer service is a single-node static IP (public pools only, up to 2 Gbit/s, no HA, source IP lost without externalTrafficPolicy: Local); use an ingress controller behind a separately provisioned Managed ALB for real edge behaviour.
• Control-plane events never reach the Logging Service, NIC-level security groups cannot be applied to worker nodes at all (use Calico network policies for workload segmentation), and the IT-Grundschutz scope covers the infrastructure layer, not your workloads. C5 does not cover Managed Kubernetes.
• Control-plane placement is cluster-type dependent and decides sovereignty: pin Frankfurt (public) or use a private cluster in the chosen German region to keep control-plane metadata in country.

Important Terminology:

• Node pool: A set of identically configured worker nodes provisioned as Compute Engine instances into your VDC; the unit of capacity, server type, and autoscaling, and immutable in that nodes are replaced rather than patched.
• Ingress node: The single worker node to which a LoadBalancer service's static IP is attached as a secondary IP; it carries that service's external traffic and kube-proxy NATs to the target pod.

Further Reading

• Unit 6.2: Provisioning a Public Cluster (the build of the public design here)
• Unit 6.3: Provisioning a Private Cluster (private control plane, networking-first)
• Unit 1.4: Sovereignty and Compliance as Design Inputs
• Unit 7.2: Observability and Operations (the control-plane logging gap in context)