[Technical Verification] Same Physical Servers, New Kubernetes Version: Cluster API In-place Upgrade

Operating multiple physical server-based Kubernetes clusters over the long term requires more than simple installation automation—it requires a system that consistently manages creation, scaling, upgrades, and deletion. kt cloud's Cloud Platform Team solved this problem with a combination of Cluster API and the BYOH (Bring Your Own Host) Provider. BYOH works by installing only an Agent on physical servers that already have OS and network set up, bringing them under Cluster API management—allowing existing assets to be used without a BMC, PXE, or Ironic layer.

Two challenges emerged during operation. First, when migrating the BYOH Provider from the v1beta1 to the v1beta2 API, the CRD schema, Controller logic, and Webhook conversion all had to be overhauled, while maintaining backward compatibility without disrupting existing clusters. Second, Cluster API's default approach, Rolling Upgrade, requires spare Hosts, which is costly in physical environments where the number of servers is fixed.

To address this, rather than removing Rolling Upgrade, the team added In-place Upgrade as an option. The In-place approach keeps the existing Host, Machine, and Node names while upgrading only the Kubernetes components in place. When a version change falls within the scope of In-place application, the Controller and BYOH Agent execute role-specific upgrade flows, reflecting progress in real time through Condition, Event, and Log.

• Worker Node: Applies the node component update flow
• Control Plane: Checks API Server and etcd status and cluster quorum, then upgrades in stages
• Explicitly defines stop, retry, and manual intervention policies in case of failure

Verification confirmed that In-place upgrades are possible for both the Control Plane and Worker Nodes without additional Hosts, and this structure also integrates naturally with GitOps flows.