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

small refinement

Browse source
This commit is contained in:
Tobias Brunner 2025-12-08 14:31:28 +01:00
parent 8a33810c6e
commit 77a0d02d2e
Signed by: tobru
SSH key fingerprint: SHA256:kOXg1R6c11XW3/Pt9dbLdQvOJGFAy+B2K6v6PtRWBGQ
1 changed files with 3 additions and 3 deletions
Download patch file Download diff file Expand all files Collapse all files

6
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 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. 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.
@ -88,6 +88,6 @@ Clear mental model: Portal orchestrates, clusters execute.
#### What We're Trading Off #### What We're Trading Off
The Portal becomes critical infrastructure for orchestration. If it's down, orchestration stops. The Portal becomes critical infrastructure for orchestration. If it's down, orchestration stops, though services still continue to be available.
The Portal needs secure access to every workload cluster across all CSPs. We need a connectivity model that's secure, private, and scalable without exposing Kubernetes APIs publicly. The Portal needs secure access to every workload cluster across all CSPs. We need a connectivity model that's secure, private, and scalable without exposing Kubernetes APIs publicly.