This page shows how Kube-DC controllers turn platform custom resources into
Kubernetes, network, identity, storage, and security state. It is an operator
view: resource names and component responsibilities are shown, but source-code
paths and implementation details are intentionally omitted.
Fleet and Flux deliver desired state to the Kubernetes API; resource-specific Kube-DC controllers then reconcile identity, networking, virtualization, security, endpoints, and observability integrations.
Project lifecycle reconciliationA platform administrator creates an Organization through the Kubernetes API. Product controllers reconcile its Keycloak realm and groups and publish Organization status. An Organization administrator then creates a Project. Product controllers create its backing namespace, hierarchy, RBAC, trust resources, VPC, subnet, network attachment, SNAT, router policies, optional backup and image resources, observability scope, and Project status. Finally, an OrganizationGroup is reconciled into a Keycloak membership target and Project RoleBindings.create Organizationreconcilerealm + groupspublish statuscreate Projectreconcilenamespace · RBAC · trustVPC · subnet · policiesbackup + imagesdatasource scopepublish statuscreate OrgGroupreconcilesync identity targetcreate RoleBindings1 · ORGANIZATION SETUPPlatform adminactorKubernetes APIOrganization APIProduct controllersOrganizationreconcileKeycloakrealm + groups2 · PROJECT SETUPOrg adminactorKubernetes APIProject APIProduct controllersProjectreconcileAPI resourcesnamespace +accessNetworkingKube-OVN +MultusVirtualizationKubeVirt +storageObservabilitydatasourcescopeProject statusProjectconditions3 · ACCESS MAPPINGOrg adminactorKubernetes APIOrganizationGroupAPIProduct controllersaccessreconcileKeycloakmembershiptargetRoleBindingsper Project
Reconciliation proceeds in three operator-visible phases: establish the Organization and identity state, create all Project boundaries and integrations, then materialize group-based Project RoleBindings.
Project workload network flowProject virtual machines and Pods connect to the Project VPC and subnet, which uses outbound SNAT to the public or cloud external subnet. A LoadBalancer Service is synchronized by the service load-balancer controller through an EIp allocation and OVN load balancer. A FIp resource is synchronized through an EIp allocation and OVN floating-IP rules. External clients reach the external subnet, which forwards through the appropriate OVN rule to the Service or workload.PROJECTNETWORK CONTROLLERSKUBE-OVNEXTERNALWorkloadsVMs + PodsProject networkVPC + subnetOutbound SNATdefault egressExternal subnetcloud / publicServicetype LoadBalancerLB controllerService syncEIpallocationLoad-balancer ruleOVN load balancerFIp resourceone-to-one NATFIp controllerFloating IP syncFloating-IP rulesDNAT + SNATClientsingress source
Three paths share the Project VPC but remain distinct: default outbound SNAT, Service LoadBalancer publication, and one-to-one Floating IP translation.
Kube-DC has two address concepts:
EIp is the allocated external address object. It can back a Project
gateway, a service load balancer, or another higher-level resource.
FIp creates a 1:1 NAT mapping from an EIp to either a selected VM
interface (vmTarget) or an explicit internal workload address
(ipAddress). The guest or Pod keeps its internal address.
The controller keeps ownership and status on the Kube-DC resources while
Kube-OVN owns the low-level routing, NAT, and load-balancer programming.
Project secret and certificate flowManagedSecret, ManagedCertificate, KMSKey, and DatabaseCredentialPolicy resources in a Project backing namespace are handled by dedicated security controllers. Secret sync uses OpenBao and writes a projected Kubernetes Secret. Certificate sync uses OpenBao and cert-manager to create a Certificate. KMS key sync uses OpenBao. Database credential policy sync uses OpenBao and the database manager and writes a projected Secret. All four controllers report to Project status aggregation.PROJECT BACKING NAMESPACESECURITY CONTROLLERSPLATFORM BACKENDSManagedSecretsource resourceManagedCertificatesource resourceKMSKeysource resourceDatabaseCredentialPolicysource resourceProjected SecretManagedSecret + DB policyCertificatecert-manager outputSecret syncsecret reconciliationCertificate synccertificatereconciliationKMS key synckey reconciliationDB policy synccredentialreconciliationOpenBaosecret + key backendcert-managercertificate issuerDatabase managercredential sourceProject statuscontroller conditions
Each Project-scoped security resource has a dedicated controller and backend path; controller conditions converge separately in Project status without exposing platform credentials.
Security controllers validate and reconcile Project-scoped requests while
keeping backend credentials and privileged operations in platform service
accounts. Ready conditions on child resources are aggregated so the Project
status can show whether its security dependencies are usable.
Platform endpoint reconciliationThe chart and Fleet desired state defines the MetalLB IPAddressPool and advertisement, annotated selectorless LoadBalancer Service, and Envoy or Kubernetes API listener. The Service triggers PlatformEndpointReconciler, which watches the Service and Nodes, probes each eligible node backend, and maintains a companion EndpointSlice attached to the Service. A Managed Cluster or Project workload resolves a vpc-dns hostname rewrite to a stable internal VIP and reaches the same Service.FLEET DESIRED STATEPLATFORM ENDPOINT RECONCILERPROJECT VPC PATHMetalLB addressespool + advertisementAnnotated ServiceselectorlessLoadBalancerGateway listenerEnvoy orKubernetes APIWatchService + NodesProbeeligible node backendsEndpointSlicecompanion resourceProject clientManaged Cluster / workloadvpc-dnshostname rewriteInternal VIPstable internal address
Fleet owns the address pool, listener, and selectorless Service; the endpoint controller probes eligible nodes and maintains its EndpointSlice, while Project clients resolve a stable internal VIP.
The chart and Fleet configuration own the MetalLB pool, advertisement,
LoadBalancer Service, Gateway resources, routes, and certificates. The
PlatformEndpointReconciler does not create those objects. It watches an
explicitly annotated selectorless Service, health-probes the eligible node
backends, and maintains the Service's companion EndpointSlice.
For topologies that cannot hairpin through the public address, vpc-dns
rewrites platform hostnames to the internal VIP. This keeps the hostname and TLS
identity unchanged while selecting a reachable path. See
Internal platform endpoints.
The CLI and Fleet repository define desired state.
Flux applies that state to the management cluster.
Kube-DC controllers reconcile custom resources and selected Kubernetes
resources into real platform state.
External platform systems such as Keycloak, OpenBao, Kube-OVN, KubeVirt,
cert-manager, Envoy Gateway, and observability components do the specialized
work.
Status flows back to Kube-DC resources so the UI, CLI, and operators can read
the platform state from Kubernetes.