diff --git a/content/day2/05_kcp.md b/content/day2/05_kcp.md new file mode 100644 index 0000000..3e93fb7 --- /dev/null +++ b/content/day2/05_kcp.md @@ -0,0 +1,104 @@ +--- +title: Building a Platform Engineering API Layer with KCP +weight: 5 +tags: + - kcp + - platform +--- + + + + +## Baseline + +- Platform is automated and self service +- We always have a bunch of consumers and service providers that get connected via an internal db plattform + +```mermaid +graph TD + subgraph Consume + A + B + end + subgraph Provider + Cert + DB + end + IDP + A-->|discover available services|IDP + A-->|order db|IDP + IDP-->|Notify|DB + DB-->|fulfill|A +``` + +## Why KubeAPI + +- We have it all: Groups, Versions, Optionally Namespaced, ... +- It is extendable via CRDs +- Challenges: CRDs are Cluster Scoped -> Everyone shares them across Namespaces +- Idea: Everyone get's their own cluster +- Problem: Spinning up clusters is slow and resource intensive +- Idea: "Lightweight clusters" aka Hosted Control Plane +- Problem: Now we have to share CRDs Across Clusters + +## WTF is KCP? + +- Idea: What if we had seperate control planes but with a shared datastore +- Goal: Horitontally scalable control plane for extenable APIs +- You don't need Kubernetes to run KCP (it's a standalone binary) +- It does not spin up a real api server but a workspace wit a low memory footprint +- It does not implement all of the container related stuff (Pod, Deployment, ...) + +### Access and setup + +```mermaid +graph LR +User-->|Create APIServer Team A|KCP +KCP-->|Kubeconfig|User +subgraph KCP + APIA(Workspace Team A) + APIB(Workspace Team B) + Datastore +end + +User-->|Kubectl get ns|APIA +APIA-->|Return NS for Workspace A|User +``` + +### Internal Organization + +- Workspaces are organized in a tree +- Possibility of nested fun: `/clusters/root:org-a:team-a` +- Sub-Workspaces can't access ressources from the root workspace + +```mermaid +graph TD +Root +Root-->OrgA +Root-->OrgB +OrgA-->TeamA +``` + +### Sharing + +- KCP owns all Workspaces -> It can share stuff across clusters +- To share: APIExport (Can Share multiple CRDs in one Package) +- To use: APIBinding (Just reference the Exported API By Path to Workspace and name) + +### Order fulfillment + +- Classic Kubernetes: Controller -> But they are isolated, aren't they? +- Virtual Workspace: Provite a computed view of parts of a workspace -> Basicly a URL that you provide to the controller that can be used to watch objects accross workspaces +- Part of KCPs magic -> You don't create it, but it get's managed for each APIExport + +## Notes from the demo + +- Spin up locally is near instant +- Switching to the namespace can be achived with a simple api command or + +## But why do we even need a universal API layer + +- Service Providers should not be responsible to make things discoverable, the plattform should +- The internal pülatform can be bought, customized or diyed but the api layer does not change -> Interchangeable backend switching +- Kubernetes is already widespread and makes it easy to use different projects +- Backed by the CNCF, flat learning curve diff --git a/content/day2/_index.md b/content/day2/_index.md index d8f7193..3c8d32e 100644 --- a/content/day2/_index.md +++ b/content/day2/_index.md @@ -10,4 +10,5 @@ We also had some "normal" work tasks resulting in less talks visited and more "n ## Reccomended talks -- Good speaker [Many Cooks, One Platform: Balancing Ownership and Contribution for the Perfect Broth](./04_many-cooks) \ No newline at end of file +- Good speaker: [Many Cooks, One Platform: Balancing Ownership and Contribution for the Perfect Broth](./04_many-cooks) +- Good intro to kcp: [Building a Platform Engineering API Layer with KCP](05_kcp) \ No newline at end of file