How To Manage Kubernetes Applications Using Crossplane Compositions
ฝัง
- เผยแพร่เมื่อ 7 ธ.ค. 2021
- Crossplane compositions can be used to manage any type of resources, and that includes Kubernetes applications as well.
▬▬▬▬▬▬ 🔗 Additional Info 🔗 ▬▬▬▬▬▬
➡ Gist with the commands: gist.github.com/57689b4095d9c...
🎬 Production-Ready Kubernetes Clusters Using Crossplane Compositions: • Production-Ready Kuber...
🎬 How To Shift Left Infrastructure Management Using Crossplane Compositions: • How To Shift Left Infr... - บันเทิง
Amazing sir! Thank you so much. It's exactly what kind of demo I needed to deep dive into Crossplane. I'm pretty sure that is the tool to solve a lot of problems I'm facing in my daily work.
Very interesting approach, putting more focus on the applications is a good decision. Packaging source code, services and application manifests in one repo enables shift left. One question specific to label selectors on the composition. If there are 2 or more compositions matching the label selectors, will they all be triggered by the claim?
When there are more that one compositions with matching labels, only one would be used. I'm not sure what is the exact criteria. I'll check it out and get back to you.
Thought of asking a silly question , may be I am bit too much excited at the prospect. How can an ops/sre of an organization enforce rule in crd for a back end app so that for accessing s3 or dynamodb from back end app the connection must be routed through vpc end points to save egress networking cost and improve security. Which resource definition level this , per your opinion, should be enforced, the app crd or the infra crd?
I think that's one of the reasons for defining compositions. Whoever designs them can define what and how something should be done in a way that both exposes certain behavior and simplifies usage for others.
I got that but the question was as a Ops I will be designing XR for both infra and app , so which XR should implement the rule , the app XR or Infra XR ?
Yes I would be interested to know upbound's opinion on this also...
What should form the application definition ? And at what point do we draw the line and have it as part of infra definition ?
I have always thought it is best practice to decouple applications from infrastructure.
It's very hard to make a clear cut between apps and infra. For example, ingress resource is considered as a part of an app (it defines the host address) yet ingress is managing infra (external lb).
Advantage to doing this instead of packaging and consuming as Helm charts?
Helm charts are just a way to define templates that will be processed on client side. Crossplane Compositions are a way to create new CRDs with new APIs that can be managed as any other API (e.g., Kubernetes Deployment) and with their own lifecycle. It is, among other things, a way to create your own Kubernetes operators.
How is this different from using a helm chart..all that the dev team needs to change is change the values file
Would you recommend this rather than kubevela?
That's hard to say. On one hard, kubevela is focused on applications so it is more feature rich when apps are concerned. On the other hand, I prefer crossplane model and, more importantly, it's ability to handle everything (infra, services, and apps). Also, crossplane will be putting more focus on apps in the future.
can't find configs from video in your repos :(
Is gist.github.com/vfarcic/57689b4095d9c7825baef3c2aec201ea#file-133-crossplane-apps-sh-L17 what you're looking for?
@@Upbound yamls with crossplain definitions for apps
@@terionname All the packages used in that and other demos done by me (Viktor) are in github.com/vfarcic/devops-toolkit-crossplane/tree/master/packages. The one with the apps package is in the `app` directory.