1. I'd evaluate it for multi-tenancy in the future, but I'd probably prefer to use something like Loft if I could get away with it. 2. It seems to enable an inheritance model across clusters, but I don't think it stands alone. I'm okay with that, if it commits to being a really good "package" for a full IDP which sticks to making that inheritance easy to set up and inspect. When I'm affecting potentially The Whole System through a series of manual actions, I want my decisions to be guided by a lot of information that comes with a more visual experience than I think kcp is going for, aggregating more kinds of info than I think is in-scope for kcp. 3. I always want to follow GitOps principles, and I think something would need to implement GitOps on top of kcp if that's the route you're going down.
KCP looks really interesting. I worked on a digital bank that had multiple shards which are basically k8s clusters for different customers. KCP would fit really well on this case. Thanks for sharing it Viktor
Thanks for making this video! Very informative. I am trying to get a setup of my own with kcp running on my local machine and add a kubernetes cluster from GCP bound to it. From the documentation, I understand that I need to utilize `--bind-address` in `kcp start`. However, there is not enough details around it. Have you attempted something similar? Any pointers as to what I could do?
Interesting. How it's compared to vCluster that you have reviewed in the past? Both provide multi-tenancy and multi-control-plane if I understand correctly.
Kcp Is like a Gateway, a control plane, towards other clusters abd also a pathway towards more specialized kubernetes distributions. vCluster is a virtual kubernetes cluster often used as a solution for temporary workloads.
Maybe that will be a mis-use of kcp but I'd see this as a manager for a fleet of my k8s clusters hosting various of dev/test envs. And a single deployment to "all" workspace would sync all of these envs. Still not sure to me how to differentiate env-specific configuration but yet keep the envs "synced" 😆PS: Many thanks for bringing up all these exotic CN projects; the landscape keeps evolving so quickly, difficult to track all these newcomers.
KCP is a very interesting project. Watch it since it was announced back in the days! AFAIK I understood, you don't need to install any CRDs on the connected clusters? So for example, If I install the kube_prometheus_stack on the connected cluster without the CRDS and the CRDs on the KCP workspace? Will this still create a Prometheus, when I apply the CR to the KCP control plane on the connected cluster?
@@dirien I think it's the other way around; that you "import" CRDs from a connected cluster into a specific workspace in kcp. That way you decide who can do what and where. I might be wrong though.
Does the kcp processes run locally on the machine where you run the kcp plugin? Or does it get spun up on whatever k8s cluster that you're authenticated with atm? This looks interesting but I'm trying to wrap my head around it.
Kcp itself is a kubernetes distribution. It does not run in kubernetes, it is kubernetes.kcp CLI is equivalent to kubectl (you could actually do everything with kubectl pointing to the kcp server). Think of it as a kubernetes cluster specialized to manage other kubernetes clusters.
@@DevOpsToolkit huh, ok! Can I put everything that I can do with kcp in git and have a versioned, portable declaration of my environments? And even potentially switch out the workload clusters that run my pods?
@@DevOpsToolkitvery interesting. Apologize for all the questions :) but can you potentially use kcp to manage your crossplane compositions as well then? Man, I have to dig into this...
@@DavidBerglund No need to appologise. Questions are great! You can use kcp to manage Crossplane resources applied to other clusters. To be more generic, you can use kcp to manage any type of Kubernetes resources.
I'd add to cons that kcp is missing a GitOps logic. For what I can see, I need another k8s cluster to run ArgoCD/Flux (likely with special addons to handle workspaces abstraction) to sync desired state from git repo to kcp state. It would be nice to have config like ArgoCD: "this is git repo, this is the cluster, go on"
That's true and valid for many other things like, for example, policies. Now, i know that there is some level of cooperation between kcp on one hand and argo CD and kyverno projects but that still in early stages. For now, kcp is not in the "use it" but rather in the "interesting to follow" bucket.
That's true if you exclude observability, multi tenancy, and the possibility to create specialized clusters that are more efficient and performing specific functions. Also, Argo CD project itself is looking into ways to leverage it for it's own needs.
Looks to me like a more elegant solution than vcluster (awesome tool which I learned about from your channel among other channels). But I guess kcp is still not broadly adopted and perhaps not ready for production.
But maybe we shouldn't compare the two too much. They serve slightly different use cases (some of them overlapping). Having a proper (although virtual) cluster at my fingertips, with the ability to run actual workloads and even pause and resume those workloads, is an awesome capability that you get from vcluster
Those have very different goals. vCluster is meant to be virtual kubernetes clusters running inside a kubernetes cluster. Kcp is a standalone kubernetes distribution that does not run inside a different cluster and is meant to manage workloads in other clusters.
What do you think about the idea behind kcp?
Z, 7,6tt , the c
1. I'd evaluate it for multi-tenancy in the future, but I'd probably prefer to use something like Loft if I could get away with it.
2. It seems to enable an inheritance model across clusters, but I don't think it stands alone. I'm okay with that, if it commits to being a really good "package" for a full IDP which sticks to making that inheritance easy to set up and inspect. When I'm affecting potentially The Whole System through a series of manual actions, I want my decisions to be guided by a lot of information that comes with a more visual experience than I think kcp is going for, aggregating more kinds of info than I think is in-scope for kcp.
3. I always want to follow GitOps principles, and I think something would need to implement GitOps on top of kcp if that's the route you're going down.
KCP looks really interesting. I worked on a digital bank that had multiple shards which are basically k8s clusters for different customers. KCP would fit really well on this case. Thanks for sharing it Viktor
12:30 I'm pretty sure you know this but I's possible to switch the context also from k9s, just :ctx 😀
Oh my... That's abvious yet I did not know about it. Thanks a ton for the tip.
Interesting. I think I like this approach to managing multiple clusters more than, say, Rancher's approach.
Very interesting, thanks for sharing.
Thanks for making this video! Very informative. I am trying to get a setup of my own with kcp running on my local machine and add a kubernetes cluster from GCP bound to it. From the documentation, I understand that I need to utilize `--bind-address` in `kcp start`. However, there is not enough details around it. Have you attempted something similar? Any pointers as to what I could do?
The gist in the description of the video is actually using GKE clusters.
Nice Video Victor! Could you please tell me what does the following line mean in the gists. What does it exactly do?
kubectl kcp bind compute root:all
Us that a kcp addon for kubectl? I did not even know it exists.
Interesting. How it's compared to vCluster that you have reviewed in the past? Both provide multi-tenancy and multi-control-plane if I understand correctly.
Kcp Is like a Gateway, a control plane, towards other clusters abd also a pathway towards more specialized kubernetes distributions. vCluster is a virtual kubernetes cluster often used as a solution for temporary workloads.
Maybe that will be a mis-use of kcp but I'd see this as a manager for a fleet of my k8s clusters hosting various of dev/test envs. And a single deployment to "all" workspace would sync all of these envs. Still not sure to me how to differentiate env-specific configuration but yet keep the envs "synced" 😆PS: Many thanks for bringing up all these exotic CN projects; the landscape keeps evolving so quickly, difficult to track all these newcomers.
KCP is a very interesting project. Watch it since it was announced back in the days!
AFAIK I understood, you don't need to install any CRDs on the connected clusters? So for example, If I install the kube_prometheus_stack on the connected cluster without the CRDS and the CRDs on the KCP workspace? Will this still create a Prometheus, when I apply the CR to the KCP control plane on the connected cluster?
I'm not sure I understood the question...
@@DevOpsToolkit I may need to check KCP beforehand! I assumed you apply the CRDS to KCP and not to the connected cluster! Maybe I am wrong 😅
@@dirien I think it's the other way around; that you "import" CRDs from a connected cluster into a specific workspace in kcp. That way you decide who can do what and where. I might be wrong though.
Does the kcp processes run locally on the machine where you run the kcp plugin? Or does it get spun up on whatever k8s cluster that you're authenticated with atm? This looks interesting but I'm trying to wrap my head around it.
Kcp itself is a kubernetes distribution. It does not run in kubernetes, it is kubernetes.kcp CLI is equivalent to kubectl (you could actually do everything with kubectl pointing to the kcp server).
Think of it as a kubernetes cluster specialized to manage other kubernetes clusters.
@@DevOpsToolkit huh, ok! Can I put everything that I can do with kcp in git and have a versioned, portable declaration of my environments? And even potentially switch out the workload clusters that run my pods?
@DavidBerglund you can. It's kube api after all that that means that you can define anything as yaml and store it in git.
@@DevOpsToolkitvery interesting. Apologize for all the questions :) but can you potentially use kcp to manage your crossplane compositions as well then? Man, I have to dig into this...
@@DavidBerglund No need to appologise. Questions are great!
You can use kcp to manage Crossplane resources applied to other clusters. To be more generic, you can use kcp to manage any type of Kubernetes resources.
I'd add to cons that kcp is missing a GitOps logic. For what I can see, I need another k8s cluster to run ArgoCD/Flux (likely with special addons to handle workspaces abstraction) to sync desired state from git repo to kcp state. It would be nice to have config like ArgoCD: "this is git repo, this is the cluster, go on"
That's true and valid for many other things like, for example, policies. Now, i know that there is some level of cooperation between kcp on one hand and argo CD and kyverno projects but that still in early stages.
For now, kcp is not in the "use it" but rather in the "interesting to follow" bucket.
Maybe I'm missing something, but this seems to do what ArgoCD does but without the git integration.
That's true if you exclude observability, multi tenancy, and the possibility to create specialized clusters that are more efficient and performing specific functions. Also, Argo CD project itself is looking into ways to leverage it for it's own needs.
@@DevOpsToolkit Thanks for the added details. Love your work.
Looks to me like a more elegant solution than vcluster (awesome tool which I learned about from your channel among other channels). But I guess kcp is still not broadly adopted and perhaps not ready for production.
But maybe we shouldn't compare the two too much. They serve slightly different use cases (some of them overlapping). Having a proper (although virtual) cluster at my fingertips, with the ability to run actual workloads and even pause and resume those workloads, is an awesome capability that you get from vcluster
Those have very different goals. vCluster is meant to be virtual kubernetes clusters running inside a kubernetes cluster. Kcp is a standalone kubernetes distribution that does not run inside a different cluster and is meant to manage workloads in other clusters.
@@DevOpsToolkit that clears things up, thanks