Simplifying Your Kubernetes Infrastructure With CDK8s
In this presentation, learn more about an open-source CNCF project that helps represent Kubernetes resources and application as code (not YAML!).
Join the DZone community and get the full member experience.Join For Free
Of late, I have started to pen down summaries of my talks for those not interested in sitting through a 45-minute video or staring at slides without getting much context. Here is one for AWS DevDay Hyderabad 2023 where I spoke about "Simplifying Your Kubernetes Infrastructure With CDK8s."
CDK for Kubernetes, or CDK8s is an open-source CNCF project that helps represent Kubernetes resources and application as code (not YAML!).
You can check out this link for the slides, and the recording is coming soon!
Many of you work on Kubernetes, perhaps in different capacities: architect, DevOps engineer, SRE, platform engineer, software engineer, etc. No matter what we tell our friends, family, or even recruiters (we need to convince them how hard it is to work across the entire CNCF landscape, isn't it? ), the real question is...
...What do we actually do?
(This is all light-hearted stuff, please don't take this personally.)
Can you relate to this ^^ as well?
Working on Kubernetes does not have to mean turning into a YAML engineer (unless that becomes the "next big thing"). But the reality is that there is...
It has become the "lingua franca" of the Kubernetes world. Every tool set that we use including Helm, Kustomize, GitOps, Kubernetes operators, etc. involves using (and debugging) YAML.
But what I covered in the talk was not about removing or getting rid of YAML. To be honest, that's almost impossible. It's more about circumventing it or pushing it behind the scenes, using tools and frameworks - and one of those is CDK for Kubernetes.
There is only so much I can cover in 30-40 minutes. If you are interested in learning more, you are more than welcome to check out this. It’s kind of a mini-book along with a GitHub repo that has all the code.
I think you will find it useful!
You may have used Terraform or AWS CloudFormation. These fall into the Infrastructure as Code (IaC) category, where you write configuration to define your resources, be it YAML or JSON or a custom templating language.
On the other end of the spectrum, there are tools like AWS CDK or Pulumi. This is where you step into the Infrastructure Is Code zone, where configuration takes a back seat and code dominates.
And the best part is that you can use it anywhere. It's not specific to AWS or any other provider: it's an open-source CNCF project.
I showed how to bootstrap a Go CDK8s application using the CLI (
cdk8s init go-app), define an NGINX application (see code below), convert it to YAML manifest (yes, we can't get rid of it!), and deploy using
kubectl apply -f dist/.
Before we move on, let's understand these concepts:
- Every CDK8s application consists of a tree of components, also called constructs.
- At the top of the tree is what you call an
App. We create it using
Appcan contain multiple
Charts and we create a chart using
- Within that
Chartis where you would define your basic building blocks. In the above example, we defined a Kubernetes
Service, but it could be other types of constructs as well (covered later).
Since CDK8s is a low-level API, it can be a bit verbose, and that's where the CDK8s plus library comes in.
Now look at this example which is directly from the CDK8s documentation - the difference is clear. But it can vary depending on the language - the example here is actually Nodejs.
Here is a Go example:
More than the lines of code and verbosity, I think the more important point to consider is the level of abstraction.
CDK8s+ provides higher level abstraction:
- This means in most cases you will have fewer lines of code
- An ergonomic API with better defaults
- Overall, less mental overload/overhead
As developers, we all know how that can improve productivity!
Imagine you are building a complex application on Kubernetes using CDK8s, and it is required by many teams in the company - perhaps each with a different configuration. Instead of each dev team writing their own version, you can externalize this in the form of Custom Construct and share it across the company.
It's nothing fancy, to be honest - it’s the same as using a dependency or library - but this is still very powerful. The great thing is that there is already something called a Constructs Hub that has constructs published by AWS, the community, and other providers as well!
In this demo:
- I walked through a "WordPress" deployment on Kubernetes to demonstrate the ease of use and intuitiveness of the CDK8s+ API
- Demonstrated custom constructs, in the context of the same "WordPress" deployment.
Here is what it would look like using a custom "WordPress" construct:
Then we moved into a slightly advanced topic. You can use the CDK8s library to represent native Kubernetes objects like a deployment, service, etc. But in any real-world implementation, it's highly likely that you are using custom resource definitions (CRD). So if you have existing CRDS, can you manage them as code using CDK8s???
A good example of a CRD and operator is AWS Controllers for Kubernetes (or ACK). With the ACK project, you can manage AWS services from Kubernetes.
This is just an example of an Amazon RDS database, but the same applies to an Amazon DynamoDB table, an Amazon S3 bucket, an Amazon Elasticache cluster, or even an AWS Lambda function. The ACK project has different controllers/operators for each service. When you create an ACK resource, these operators do what’s needed to create and manage the corresponding service(s) in AWS.
How Do You Use CRDs With CDK8s?
To use any CRD with CDK8s:
- The first step is to run “CDK8s import” by pointing it to the CRD.
- This will result in APIs being auto-generated.
- Write your code using these APIs.
- Then business as usual - use
cdk8s synthto generate the manifest for your Kubernetes application.
It’s a simple URL shortener app that is deployed to Amazon EKS and uses DynamoDB as the database. The interesting part here is the fact that both the application and DynamoDB are defined using CDK8s.
So far we have had one thing to think about. We brought in CDK8s and were able to represent both the AWS resources and the respective Kubernetes applications in the form of code.
But what if we don’t want to use ACK, and stick to something like AWS CDK for AWS resources but use CDK8s for Kubernetes apps? CDK8s is great, and AWS CDK is awesome. So what’s stopping us from using them together?
Deploying Apps to EKS With AWS CDK – The "Hard" Way
Here is a glimpse of using only AWS CDK to deploy an app to an Amazon EKS cluster (note that this is just AWS CDK code, not cdk8s)
- First, you declare the Kubernetes deployment.
- Then, the Kubernetes service
- And finally, call the addManifest function declared on the EKS cluster object - this is equivalent to calling
addCdk8sChart to the Rescue!
addCdk8sChart method acts like a bridge between CDK and cdk8s - check out the CDK reference docs for details.
This makes life much easier!
Recap: We’re Almost Done!
- It's not about removing YAML, it's about reducing it and embracing the Infrastructure Is code paradigm.
- Use CDK8s with regular programming languages and make use of the related tools and best practices (testing, OOP, etc.).
- Optimize with CDK8s plus, share and reuse common components as constructs, and extend with CRDs.
- Combine CDK8s with AWS CDK, or existing workflow/practices like GitOps, or even Helm charts.
Hope to see you next time!
Published at DZone with permission of Abhishek Gupta, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.