servala/documentation
5
1
Fork 0
Code Issues Pull requests 1 Packages 1 Activity Actions

Compare commits

base: servala:df380a4bd6654129bc5bf24630f1373db7f0b630
Branches Tags
servala:main
servala:adr/k8s-distro
servala:adr/control-plane
..
compare: servala:cf24cec7b7dd08495e6cec6606c962485a6e6d7f
Branches Tags
servala:adr/k8s-distro
servala:main
servala:adr/control-plane

1 commit
df380a4bd6 ... cf24cec7b7

Author SHA1 Message Date
Marco De Luca
cf24cec7b7 add adr001 2025-12-08 14:41:39 +01:00
1 changed files with 2 additions and 2 deletions
Download patch file Download diff file Expand all files Collapse all files

4
docs/ADRs/adr001.md
View file

@ -20,9 +20,9 @@ We're building a sovereign, multi-CSP platform. The control model needs to be si
The split control plane idea comes from [AppCat](https://kb.vshn.ch/app-catalog/control-plane/split-architecture.html).
The control plane needs kubeconfigs to N service clusters. Each service cluster needs a kubeconfig back to the control plane. Due to how SYN works, we can't create these kubeconfigs during compilation time, they have to be generated manually and put into Vault every time we add a new service cluster.
The control plane needs kubeconfigs to N service clusters. Each service cluster needs a kubeconfig back to the control plane. Due to how [Project Syn](https://syn.tools/) works, we can't create these kubeconfigs during compilation time, they have to be generated manually and put into Vault every time we add a new service cluster.
Managing provider configs for Helm and Kubernetes gets complicated because they need to connect to service clusters from the control cluster. Connection details only exist on the control cluster and don't propagate to service clusters. Instead of writing connection details directly into instance namespaces, we have to wrap them into separate secrets and deploy via provider-kubernetes.
Managing provider configs for Helm and Kubernetes gets complicated because they need to connect to service clusters from the control cluster. Connection details only exist on the control cluster and don't propagate to service clusters. Instead of writing connection details directly into instance namespaces, we have to wrap them into separate secrets and deploy via Crossplane provider-kubernetes.
The deletion protection webhooks need to check against composites on the control cluster, which means service clusters need reverse connectivity back to the control plane for webhook lookups. And developers have to constantly remember whether they're dealing with Crossplane Managed Resources (control cluster) or plain Kubernetes resources (service cluster). Some objects like `ProviderConfigs` and `Usages` don't implement the `resource.Managed` interface, which makes this even harder.