)
Why Sovereign Cloud?
This article is not a feature-by-feature product showcase of KCP (kt cloud PLATFORM). It is a prologue that illustrates how kt cloud brought networking, validation, release operations, and upstream collaboration together into a single operating model for controlling the core of its cloud platform.
Digital sovereignty begins with knowing where data lives and who can access it. Data residency and access control are essential requirements, but a state verified at a single point in time is not enough. In real cloud operations, operators must be able to diagnose, modify, and validate the software that moves data—and carry necessary changes upstream—even after upgrades and architectural changes. The key lesson kt cloud learned while building KCP is that sovereign cloud is not about choosing a particular product. It is a continuous operational capability to control the network model, validation system, release operations, and community collaboration on our own terms.
With this perspective, kt cloud transformed its existing classic platform into KCP. Classic was operational, but its hardware-centric isolation model and solution-oriented structure limited the speed at which the platform could respond to horizontal scaling, multi-AZ requirements, API automation, and rapidly evolving customer and regulatory needs. The main challenge was not the absence of a specific feature, but the limited flexibility to reshape the platform as requirements changed. We therefore redesigned the platform as software-defined infrastructure and an engineering-led operating model by combining OpenStack Neutron and OVN-based VPC networking, Zuul-based OpenStack validation, and a Kubernetes-based operational architecture. This article introduces how KCP connects network control, software validation, operational resilience, and upstream collaboration into one operating model.
Architecture: Designing for Control Across the Stack
KCP’s architecture aligns with OpenInfra’s view of digital sovereignty and reflects the layered perspective described in the NIST SP 500-292 cloud computing reference architecture. We focused on implementing a structure that spans physical infrastructure, a Kubernetes-based operations layer, the OpenStack control layer, service orchestration, and user-facing interfaces all built on OpenStack, Kubernetes, and OVN.
KCP separates operational responsibilities across three Kubernetes-based clusters: the Admin Cluster for deployment and DevOps, the Stack Cluster for OpenStack and VM workloads, and the Mgmt Cluster for the portal, IAM, VPC, and observability services. The Admin Cluster manages deployment and lifecycle operations for the other clusters, the Stack Cluster runs the OpenStack control plane and customer workloads, and the Mgmt Cluster provides customer-facing and shared management services. Each cluster has a distinct role and failure domain while following the same declarative operating model. The clusters are deployed across multiple availability zones to help maintain service continuity even if a single data center fails.
However, the declarative control chain does not extend indefinitely. The regional Admin Cluster itself is created through an Ansible-based bootstrap process, and Cluster API reconciliation begins from that point onward. Making this boundary explicit is not about identifying an exception to declarative operations; it is about defining the recovery sequence in the event of failure.
The Core of Network Sovereignty: Designing a Native VPC Model with Neutron and OVN
In KCP, tenant isolation previously handled by vDOM (Virtual Domain)-based hardware firewalls in Classic was replaced with OpenStack Neutron and OVN.
We designed VPC as a logical hierarchy of Project → VPC → Router → Subnet. Neutron provides isolated networking by combining project, address scope, subnet pool, router, and related resources, but it does not provide a single VPC lifecycle object that customers can create, name, configure quotas for, audit, and delete. KCP fills this gap with its own VPC model and implements Neutron definitions as OVN Logical Routers, Logical Switches, and ACLs. NACLs operate as stateless firewalls at the subnet level, while Security Groups operate as stateful firewalls at the instance level, allowing broad policies and fine-grained policies to be applied together.
We also selected kube-ovn as the Kubernetes CNI so that OpenStack Neutron and Kubernetes could share the same OVN instance. As a result, KCP uses a single network stack in which VMs and Pods communicate natively over the same OVN fabric. This design gave us direct control over how the network is defined and implemented, but it also exposed the need to clearly define ownership boundaries for shared resources. Each controller must be able to distinguish which resources it created and which resources it is allowed to modify or delete so that reconciliation and garbage collection do not conflict. Network sovereignty, therefore, is not only about building an integrated data plane; it also includes the ability to control who can change shared resources.
Software Transparency: Validating What We Change
Using open source and internalizing it in an operable form are different challenges. Based on upstream OpenStack, kt cloud manages its own downstream OpenStack supply chain spanning code, container images, and Helm charts. We maintain only the required features and critical bug fixes downstream, while contributing changes upstream whenever possible. The goal is not to operate an isolated fork, but to stay aligned with the community while retaining the ability to operate and validate changes in our own environment.
For validation, we use our own OpenStack validation pipeline based on Zuul. Upstream CI validates combinations of code and environments supported by upstream, but it does not guarantee KCP’s OVN version, an OpenStack control plane running on Kubernetes, or our downstream changes. The claim that we can modify software is meaningful only when those changes can be validated in the actual operating configuration. The challenge was to continuously reuse the evolving validation assets of upstream OpenStack in a downstream environment without copying them. Zuul’s job inheritance model was well suited to this requirement.
Zuul is the project gating system used across OpenInfra Foundation projects for OpenStack validation. By referencing upstream jobs instead of copying them, KCP can keep downstream validation aligned with community standards even as those validation jobs evolve.
In the actual implementation, only the target code under validation is replaced with our downstream OpenStack code, while the test environment and procedures are delegated to upstream jobs. We also combined this with the OpenStack Resource Provider to create a structure that validates an OpenStack distribution on top of an OpenStack environment. The current scope covers OpenStack code validation, and we plan to expand it to cluster-level validation based on the KCP architecture and the design of our own jobs.
Operational Resilience: Sustaining Control Over Time
From this perspective, operational resilience means the ability to maintain, patch, and scale infrastructure without being overly dependent on any single vendor roadmap or external constraint. KCP defines release cadence, audit visibility, and Multi-AZ high availability as the core pillars of operational resilience.
KCP operates its own regular release cadence and risk-based patching process. For OpenStack, we follow the community’s SLURP (Skip Level Upgrade Release Process) flow while selecting releases only after a sufficient stabilization period. Kubernetes versions are also managed based on internal validation. Version combinations of major components are managed through the platform BOM (Bill of Materials), and high-risk CVEs are handled through a separate hotfix process.
We also implemented network audit visibility. To meet the audit requirements of CSAP, Korea’s public cloud security certification, we developed a VPC Flow Log service using ACL Flow Sampling and an IPFIX Collector in OVN 24.09. Flows collected from compute nodes are correlated with Sample, ACL, and Logical Switch information in the OVN Northbound DB, enriched with project ID, ACL action, and direction, and then delivered to a central pipeline. This design reduces the disk I/O overhead and metadata limitations of existing Neutron Packet Logging while making it possible to explain which policy allowed or denied which traffic.
For high availability, we configured the Seoul region as a stretched cluster across two availability zones. The full stack—including Kubernetes, OpenStack, observability, storage, and DevOps pipelines—was designed to support Multi-AZ operations, turning sovereign cloud into an operating model that remains sustainable after the initial build.
Upstream Collaboration: Contributing Operational Lessons Back
OpenInfra’s “4 Opens” are about more than consuming open source software. They are about improving software together through open source code, open design, open development, and an open community. In that spirit, kt cloud brings issues and improvements discovered while operating KCP back to upstream OpenStack, kube-ovn, and OVN. Identifying and fixing root causes internally is important, but maintaining long-lived downstream patches creates operational cost. When required changes are merged upstream, we reduce downstream divergence and stay within a shared validation and maintenance model. Upstream contribution is therefore not only a way to give back; it is an operating practice that helps sustain platform control.
These contributions are not a one-way return to the community; they are a learning process shared between the operating organization and the community. Sovereign cloud should not be an isolated platform. It can evolve into a more transparent and sustainable operational capability when it remains connected to an open ecosystem.
The table below highlights representative contribution cases in which issues discovered during KCP operations were connected to upstream issues, reviews, pull requests, and commits.
| Project | Contribution | Link |
| openstack-helm | Updated the Cinder conversion directory path | OpenDev Review #986024 |
| openstack-helm | Fixed a resource allocation bug in the OVN metadata agent | OpenDev Review #971882 |
| openstack-exporter | Added support for Octavia statistics metrics | Pull Request #547 · openstack-exporter/openstack-exporter |
| kube-ovn | Improved synchronization between OpenStack Neutron Security Groups and OVN ACLs | Issue #5995 · kubeovn/kube-ovn |
| kube-ovn | Added an update strategy for the ovs-ovn DaemonSet | Pull Request #6406 · kubeovn/kube-ovn |
| kube-ovn | Added kt cloud usage information to the kube-ovn project | Update USERS.md (#5399) · kubeovn/kube-ovn@1f9a8e2 |
Conclusion: Technical Sovereignty Is a Journey, Not a One-Time Choice
kt cloud’s experience points to three lessons. First, sovereign cloud starts not only with where data resides, but also with the ability to understand and change the network model directly. Second, adopting open source infrastructure is not enough on its own; changes must be continuously validated through systems such as Zuul. Third, when operational findings are shared upstream, they strengthen both the stability of the local platform and the sustainability of the broader community.
The journey is not over. Next, we plan to continue contributing the VPC model and stateless NACLs upstream, expand gating from OpenStack code validation to KCP architecture-level validation, and further improve Multi-AZ operational automation and observability. AI-assisted operations are not a separate starting point; they become possible when declarative state, authoritative inventory, machine-readable validation results, and controlled change paths are connected. What matters is that this evolution is not driven solely by a vendor roadmap, but by what we choose, validate, and share with the OpenInfra ecosystem.
Planned Follow-up Articles
In upcoming installments of this series, we will cover VPC networking design and Zuul-based OpenStack validation as separate technical case studies, with more concrete operational lessons from the implementation process.
The author is employed by kt cloud
The digital sovereignty concepts, OpenInfra approach, and OpenStack comparison perspectives discussed in this article are covered in more detail in the following references.
- OpenInfra Digital Sovereignty: https://openinfra.org/digital-sovereignty/
- Best Practices with OpenInfra for Digital Sovereignty: https://openinfra.org/best-practices-with-openinfra-for-digital-sovereignty
- OpenStack vs Proprietary Clouds Comparison Guide: https://openinfra.org/openstack-vs-proprietary-clouds-a-digital-sovereignty-comparison-guide
- kt cloud tech blog: https://tech.ktcloud.com
- Part 1: Building Sovereign Cloud Control with OpenStack, OVN, and Zuul - October 14, 2026
