Cloud Native Computing Foundation GitOpsCon EU 2022, 19 May 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Lightning Talk: Day 2 Has Arrived - How Carvel Suite and Cluster API Can Bring Gi... Pietro Terrizzi

Description

Lightning Talk: Day 2 Has Arrived - How Carvel Suite and Cluster API Can Bring GitOps to Your Kubernetes Infrastructure - Pietro Terrizzi, CLASTIX srl

Kubernetes has emerged as the de-facto standard for cloud and container orchestration, thanks to its composability and extensibility; however, these positives don't come without a cost. While setting up a cluster as compositions of YAML manifests may seem like a challenge at hand, managing and upgrading a fleet across multiple environments and distributions could seriously become hell. In this talk, we will discover how to maintain and upgrade the state of an infrastructure deployed through the Cluster API, a Kubernetes SIG project based on kubeadm that aims to extend k8s core capabilities through a configuration-as-code. Then, we’ll see how this methodology can be empowered by the Carvel suite, a composable toolchain that makes use of a declarative and layered approach for application building, configuration and deployment, in order to reduce the toil of cluster day 2 operations.

A

uh So hi everyone uh thank you for to be here, uh I'm peter terizi and I'm a devops engineer at classics. This is my first talk, as I said so be easy on me. I will try to do my best to describe you my talk. So as you can see, the title is day two has arrived, so our car will suite and cluster api can bring g tops to your kubernetes infrastructure.

A

This is my contact, so you can ask to me whatever you want after the call, I will be really happy to speak with you and have a some networking.

A

So whenever you think about a product, it could be a simple app or an infrastructure. So on so forth you have to design your journey to satisfaction for the client and for yourself- and this is a step-by-step guide- a simple way to describe it based on days so which are what are these days on day zero? You have to design your application, so you have some requirements and you have to apply them to an existing infrastructure.

A

So you have to create an architecture, and this one just a day after tomorrow will be a place on your environment during the day. One step that is deploying so during the deploying you have to install a simple and minimal available way to install your application with a first configuration that will just work right, but then pain comes in and is the pain of the day too. That is maintaining your application.

A

So whenever you are on a production grade environment, maybe, for example, uh you will try to achieve all your um point to success, uh fighting with or new challenges about, network traffic and traffic security, monitoring and so on and so forth. But in this talk we will focus on infrastructure, update and application update.

A

So these are some of the challenges that you will have on during day. Two that could be really different, but uh this is the first one that comes to my mind, that can be uh is repetitive during the various enterprise installation and is timing. That is a rapid development and delivery of updates that have to be reliable. So you can avoid disruptive times to your client.

A

uh You have to use trust for with us trustworthy technologies, so your components has to be adopted from many companies, maybe, and they have to be uh able to integrate with themselves.

A

At the same time, this could be a really um difficult uh challenge that leads to complexity, so you have to develop strong, gtops and devops culture with your team. So how can we achieve this? Not all these changes could be achieved directly, but using a declarative way with the gitops methodology can help. You continuously reconcile the state of your application and infrastructures on different environment.

A

How we can achieve this. We can involve some tools like cluster api and carbon suite.

A

So what is cluster api cluster api is a kubernetes sub project, kubernetes sync, since two or three years, I I don't really know, and uh it's a way to provide a declarative api uh to your management cluster, on kubernetes, to simplify provisioning, upgrading and so on and so forth to your uh managed kubernetes cluster.

A

This comes with a ugly tool that is called uh cluster ctl and cluster ctl can help you to bootstrap a first cluster that will call will be called bootstrap, cluster or management. Cluster, to which you will deploy your custom resources like control, planes, machine deployment, machine and so on and so forth. This will be your nodes, your nodes for your new infrastructure as a pod as a custom resource and during deploy.

A

There will be some bootstrap phase, based on cloud init to join the nodes to the cuba, dma control plane how we can achieve this on different environments and different public cloud. There are three types of providers, but we will focus on just two. The first one is the bootstrap provider. That is the way to deploy your first cluster to deploy also your custom resource definition for cluster api, and they will be different because you can have a different base: cluster based on docker, based on cuba, dm on talos and so on and so forth.

A

And then we will have a workload cluster where your enterprise deploy your is up its application for production grade environment that could be placed on the most famous managed public cloud like aws, gcp, asia and so on and so forth, but also on digitalocean, openstack, etc.

A

These are some simple concepts on which, on how cluster api achieved this so uh fundamentally, there is a operator in install on the management cluster that uh tries to reconcile on different level your infrastructure, core, bootstrap infrastructure, control, plane and so on, and it will be, they will be placed on a different environment, as you can see.

A

uh But now there is is the time to uh do not use in in an imperative way, so just creating the uh the money, the ml manifest with the cluster ctl is not enough, uh so you have to continuously reconcile your your infrastructure to reflect the um the state of the uh of it.

A

um In this way, there is a fundamental application that is called cap controller, that is, an operator created by vmware and carbon team that deploys a fundamentally operator with cap, and cap has to manage a cloud native application, so it continuously fetched configuration from different locations. It could be your github repository, git lab or shared folder and so on, and it will try to deploy it and overlay it with different values on your environment.

A

So the first step, as I say, is to create a bootstrap cluster on this test. We will, we use a kind, so a simple docker provider, and you will create a management cluster on this. You will deploy your copy crd. That is a general way to deploy cap controller customers, definition on your environment, and then we will deploy uh specific or more specific uh providers on it, so cap d cup, z and so on, uh to manage different cloud providers.

A

Finally, we will deploy as the cab controller that will continuously fetch the configuration from your branch and deploy it with cap copy.

A

The powerful way to achieve this with the cap controller is a custom resource called cap app that provides a declarative way to install manage an upgrade application on your kubernetes cluster. As you can see, we have a different patch definition to achieve the most precise way to install your environment, but in generally speaking, the one that you will, that will interest you most are the ur, the reference, the sub path and how you will deploy your template based on different languages. um The kerbal suite comes with the tools like ytt.

A

There is a specific language to deploy your packages and applications, but in this case our it's, it's a template and it comes with different way to personalize your deployment using secret comfy map and so on, to to pass some values and variables, like the name of your cluster, the number of nodes version and so on.

A

So finally, we will achieve this.

A

Installing a cap app so the custom resource to your management cluster, the cap controller will read your custom up custom resource and will fetch it to your management cluster um in less than seconds. And finally, it will deploy step by step uh the nodes on your environment.

A

So, as you can see, with our cube ctl get pods, we will pass the cubeconfig created during the first step when we deploy the custom resource about machine nodes, machine deployment and so on, and we can see that is uh completely uh a simple way to achieve a different workload cluster on different environment. uh Watching your pods, you will see that this is the typical installation of a kubernetes cluster.

A

So what we achieve now we can uh declarative, deploy, uh kubernetes cluster or more kubernetes clusters on different environments and simply changing values on your uh branch on github, like the version of the num or the number of nodes, the operator will reconcile uh the application, the customer resource of a copy on your environment, and so you will automatically see new nodes or less nodes on your workload clusters and it could lead to an upgrading your environment to a new version.

A

For example, 1.22 easily as changing a value on your github branch, so thank you for watching. Thank you for your attention, write to me for every question or so on. Thank you.