Helm focuses on being a templating engine merging values into templates that specify placeholders. Kustomize acts like a stream editor producing yaml via a merging process of layers of configuration. Both of these tools excel at providing engines that can produce a wide variety of output using a smaller set of definitions. This goes along with the idea DRY.
For precise patching within a complex structure, Escape hatches seem to provide a viable solution.
It's true that Helm provides great flexibility and power via the application of Go Templates, it's just that it's still a TEMPLATING solution. Now don't get me wrong, I find this solution better than solutions relying on static sets of configurations because of the programmability of the template layer. It's just the templating is still not really coding. You can embed some logic within your templates but you can't actually escape the fact a template is not an object and you are not using an API.
Along comes CDK8s. Now things are a bit different. Configuration is CODE. It's not annotations ON code it's actual CODE. Now you can function with configuration in the ways you normally process data. You can create lists of configuration, loop through configurations, have associations between configurations, express inheritance via configurations.... "configuration is code"... 3 very powerful words. Again it's similar in the way Helm can take values and merge them with templates to produce the resulting configuration, just instead of templates you have code.
In earlier posts on this blog, I have spoken about systems composed of higher level structures dynamically changing shape based on feedback loops. I did see that Kubernetes Operators and Custom Resource definitions were part of the solution to creating this system of higher order structures, but I have been struggling with problem of how to prototype these systems. There is a high overhead of creating this operator machinery to even start. Perhaps there is an intermediate stage? One without operators but still defined using the CRDs? It could allow prototyping and testing to occur which would facilitate iteration on the structure of the grid of CRDs without having to implement all the operators and CRDs that make the system alive.
The Resource, Data, Routing, and Execution DSL's might be able to be defined as CDK8s API objects, and these objects get transformed into the working implementation in base Kubernetes objects. This is what is shown in the examples on the CDK8s site. Gradually, these API Objects could be implemented with CRDs in an iterative approach.
For the initialization of complex object graphs, constructs appear to be perfect.
Update 1/22/21
I am using EKS and the addCdk8sChart method from the EKS Cluster to deploy apps to my kubernetes cluster in EKS. This will work for deploying simple applications, but Helm still shines in this area with Chart level rollback. Also, a CDK deploy can take forever! We ended up creating a Lambda to call helm from inside the CDK application to install kubernetes charts. CDK is great for deploying infrastructure and CDK8s might remove template creation...but it appears there is still going to be code generation option unless CRDs are created to abstract out some of the templating.
The icing on the cake? It's that CDK8's support CRDs!!!! As the system evolves, structures can be migrated from API object to CRD and hybrid systems can exist.
Although it's yet to be seen exactly what can be created using CDK8s, what does seem clear is whatever you are making; it's going to easier.
You may be saying but now in order to change a system I need to change code? This is a step backward? Well, as a favorite quote of the chief architect at my company originating from Butler Lampson states: "All problems in computer science can be solved by another level of indirection"; a simpler dsl could be created that allows generation of graphs of CDK8s objects.
If you look at the code example above example again you see the variables in this system could be extracted into simple yaml, that concerned with only data (no special syntax relating to kubernetes). An engine could be created to read this yaml and produce the underlying CDK8s objects dynamically. Now you are not changing code but a configuration file. Ironically, we have come full circle, just now our yaml is quite a bit simpler.
mychart:
- webservice:
name: "hello"
image: "paulbower/hello-kubernetes:1.7"
replicas: 2
- webservice:
name: "ghost"
image: "ghost"
containerPort : 2368
No comments:
Post a Comment