keptn Keptn Lifecycle Toolkit, 8 Nov 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Keptn Lifecycle Toolkit in a Nutshell - November 2022

Description

The goal of this toolkit (https://github.com/keptn/lifecycle-toolkit/) is to introduce a more “cloud-native” approach for pre- and post-deployment, as well as the concept of application health checks. It is an incubating project, under the umbrella of the Keptn Application Lifecycle working group.

Learn more: https://keptn.sh
Get started with tutorials: https://tutorials.keptn.sh
Join us in Slack: https://slack.keptn.sh
Star us on Github: https://github.com/keptn/keptn
Follow us on Twitter: https://twitter.com/keptnProject
Sign up to our newsletter: https://bit.ly/KeptnNews

Timestamps
00:00 - Introduction
00:35 - Why look into Keptn?
01:28 - What is Keptn Lifecycle Toolkit?
02:27 - Keptn Lifecycle Toolkit in Action
05:24 - How to use Keptn Lifecycle Controller
08:10 - Demo Application Explained
10:20 - LIVE DEMO
18:10 - RECAP

A

Welcome everyone to another special episode around Captain.

B

A

Lifecycle toolkit in a nutshell, my name is Andy grabner I'm with me: Thomas hi Thomas, yes, hello, London, hi, uh cool pictures. Here we took them at cubecon in Detroit and really what we want to do with this quick video is give everybody an overview of what we have presented and demoed at the captain: booth in Detroit everything around the life cycle, toolkit and uh all the links you can find here also in the recording on the on the notes.

A

But let's get started um Captain lifecycle toolkit is something that you may have not heard about, but before I tell you about it, we want to start with actually trying to figure out what's the problem that we want to solve. So if you've ever asked yourself, the question: have you ever deployed an app into an environment that wasn't ready if we answered this question with yes, because maybe external dependencies were not ready, somebody was just running a test or something else was going on.

A

If you answer this with yes, then the captain lifecycle toolkit is for you or have you ever deployed an app and thought all of your ports are running, but users were complaining, the app is not working as expected. Maybe Pages were slow, API calls were failing, some traffic was still redirecting you to the old version, even though you just said you deployed the new one, or maybe you violated some slos.

A

If you can answer this question with yes, if this ever happened to you, then the captain lifecycle toolkit is for you now what is Captain lifecycle toolkit it's pipelineless and kubernetes Native. This is big feedback. We received from the first work we've done over the last three to four years, with the first iteration of Captain. But what does this really mean? Captain is pipelines and kubernetes Native, and it helps you by stopping your deployments.

A

If one of these reasons happen, your dependencies are not ready, the environment might be in a quarantine, you don't even have error budget and so on and so forth, and we're doing this kubernetes native through pre-deployment tasks. So we are hooking into kubernetes and we can run these checks as pre-deployment tasks before kubernetes deploys, but we're also validating your deployments to ensure that the app meets your slos after it's deployed, your users can use the key features by maybe executing some synthetic tests we want.

A

We can validate and reach out to your obserability platform to figure out if you have not introduced any performance regressions and what's really cool, we can also do things like inform everyone about successful or failed deployments. We're doing this through so-called post deployment tasks. Now lifecycle toolkit in action. What does this really mean? We wanted to make it as smooth and easy as possible for you. So we heard your feedback. Therefore, the captain lifecycle toolkit truly extends kubernetes with application lifecycle awareness.

A

That means you keep your tools that you're using right now for your GitHub space deployment. You can see all of these Jenkins Azure devops gitlab, Argo flux, whatever it is, use your tools and Deploy on your kubernetes cluster. What you do with Captain, you can Define so-called day one tasks with simple scripts. Thomas will show you later in the demo. We allow you to write and Define actions what tasks as we call them, and now here's the magic.

A

You use your tools and apply your CDs, your deployments, your stateful sets you deploy your changes into kubernetes, but then Captain comes in and we are injecting ourselves into the deployment life cycle. That means, first of all, we also introduce a concept of detecting applications. That means, if you're, deploying an app that consists of multiple Services multiple deployments, we can execute pre-deployment checks. What would that be? For instance, we could check if your infrastructure is ready.

A

If your external dependencies are there, then, when you deploy a change that includes multiple workloads, we can do pre-deployment checks on every single workload. For instance, do you have enough error budget to actually make this deployment right now? We're doing this and Thomas will show you this by extending the kubernetes scheduler and really stopping your deployments before. Kubernetes really puts the ports on the right nodes. If all of the pre-deployment checks go well, then we let kubernetes to the deployment and then our work continuous after the deployment is done.

A

You can Define host deployment actions on each individual workload, for instance, you can say I want to execute tests or, and all of these are done and the application is deployed in the new version. You would do things like evaluating whether your slos are still met so really cool stuff and the next cool thing you gain full life cycle observability. So what does this mean? Captain makes your deployments the life cycle of your deployments observable via open Telemetry. That means we are you'll, see later we're exposing metrics we're exposing traces.

A

So all of the actions on top pre-deployment app, pre-deployment workload, post deployment, workload and post deployment app will all be traced through open Telemetry. We also expose your metrics that you can use to bring back to your management. How often do you deploy how many deployments are failing and you can do and visualize all of this in the tool of choice, all right? This is kind of from my side.

A

um Everything I wanted to say on what this is all about. Now enough with the theory Thomas you take it over. Yes,.

B

Thank you Andy for this great explanations. um Now, let's go up with people into the technical part of the lifecycle control.

B

um So when you want to use the lifecycle controller with your IPL native deployments, the first thing you have to do is you have to enable the life cycle controller, and this can simply be done by annotating, your namespace and telling um the lifecycle controller that it should get aware of your application deployments. Furthermore, you are using the same deployments as you ever ever: used um and annotates them with Captain annotations.

B

So you'll tell the lifecycle controller, how the workload is named to which application it belongs, which in which version it is present and which brilliant post deployment tasks it should execute.

B

Furthermore, if you want to to use applications, so if you want to bundle your workloads into main into one large application, you have to create an app manifest and therefore you take exactly the same workout name in the app manifest as you used in your annotations, and you also use the version name which you use there.

B

Furthermore, you can you um you can execute brilliant post deployment tasks based on the application. So before the first service, before the first workloads gets deployed and after the last version of an application gets deployed- and this has also to be done in this adminifest foreign- you have to Define your tasks and evaluations.

B

um For instance, you can define an evaluation which is called positive line, my case, which is using Prometheus as a source and I, say: I, have one objectives which is called available: cpules and I added a simple prom, ql query, which simply checks if the evaluation Target is um below one.

B

Furthermore, I came the final Captain task, which is named post deployment Halo, and you can define a simple typescript function either in line of the custom resource definition. You could also use it outside so store it on an HTTP server, but also use it in a config map.

B

Okay and that's it in the in the end. The only thing you have to do is to do a cubesatel, prime minister and watch how your applications get deployed. um Reliably.

B

That's really cool okay, so um we will demonstrate exactly this based on the team application. The Potato Head and here is simple overview, so we have an application which is which is consisting of six Services.

B

um One of them is the entry service, which is the body of the Potato Head. We have a head service right down and left arm service and we have a right leg and left leg service, and what we want to show in this example is that the entry service has to exist before all of the other services can be deployed.

B

Therefore, um this is our demo floor, so in the beginning, I will be working safe of the Manifest, um the lifecycle controller. Will an application will do an application, pre-deployment evaluation which will check if enough CPUs are available.

B

Furthermore, we will have some workload pre-deployment tasks which will check if the if the entry service is already available, and after that um we will have an application post deployment task, which will notify me if, um um if the application has been deployed successfully.

B

um So I made some preparations of Rome to make this team a bit faster, so the only things I had to do up front was I had to install the shirt manager. This is a pretty prerequisite pick because we need we need Certificate certificates.

B

Furthermore, I applied the lifecycle toolkit Manifest. This installed all of the livestock controller components after that I cloned, the lifecycle, toolkit Repository and um installed one of the demos.

B

So this was um this was more or less the demo we had on the cubecon North America and after that, I simply put forward to grafana and input that the grafana dashboard- and this is where we go from now, so um I will switch to Michelle now and what you see here is I. Have my demo directory here and I have a base directory and in this base directory I have kind of my manifests, and this is exactly as we expected it before.

B

So um this is a simple kubernetes, manifest by Services. We have deployment and so on. um We annotated our our deployments, either via the kubernetes recommended labors or via the captain labels, so that the lifecycle controller is aware of what you should do.

B

The second thing we have is: we have an app manifest where we defined the whole application, so we have each service with with the corresponding version. Furthermore, we have a post deployment task, which has the notification in the, um and we have some kind of post deployment task um which is lying on an HTTP server in this case, um which uses a Secret store in the community in the communities environment and which will um add this like notification.

B

For me in the end, okay- and now, let's simply apply this so I use customize for this and therefore I will simply add the customization. For the first thing, sorry.

B

And, as you see here, we are doing no magic, so we are installing a namespace. We are installing a secret. We are installing typically kubernetes services deployments and we have our captain app our cabin evolution, definition providers and so on. So the important thing about the lifecycle controller. Is we tried to avoid creating new custom resources as long as possible, but as there was no application resourcing customer in kilometers, we had to create one the same for the evaluations and the same for the task definitions.

B

If we take a closer look on our on our communities Health tomorrow and on the parts of it, we see that all of the odds are currently in a painting state and if we take a much closer look into the into the kubernetes cluster, we have a new custom resource definition, which is called Captain application version, and this specifies what um this this specifies. Our application, and what we saw here is that we wanted to apply the application for the Potato Head in the version 0 1 0..

B

um We also saw that the pre-deployment tasks has been succeeded, but what we also see is that the pre-deployment evaluations failed, and in this case this was because I said, because I specified in the evaluation that I should have more than foresee views, and my virtual machine here only has one CPU.

B

Therefore, this wasn't possible that it's that it's that it's working in a second case um I, have created a second version which fixes exactly this problem, and this is what I want to apply now, so this was mainly the same and as it is sometimes cumbersome to look at all of these communities, custom resources and so on.

B

um We have a more graphically graphical way to take a look on such things uh and we added some dashboards in our case to gravano, and this um can be done with each episode solution you would like, because we are simply exporting data via open Telemetry, and the only thing you have to do is to to configure the collector in a way that this works.

B

So, let's take a look closer look on our application. um What we see here is that now one application deployment is active. We saw that between the first and the second um deployment um ellipse 53 seconds. I saw that I see that one of my deployments has failed and I can even take a trace. A look on the trace of these failed deployment and I also see that this is failing the pre-plant evaluation step.

B

Furthermore, I can also take a look at the at the current um trees, and this will take some some minutes until this um gets filled.

B

um So, let's get back to the shade here and what we see in our communities custom now is that our that our pre-deployment evaluations have now succeeded after the second cry. We also see that our workload overall state is progressing. So now all of the pro of the of the deployments are being deployed. We can take a closer look into these resources and we see in the meanwhile that the entry service has succeeded to deploy.

B

um Therefore, we can also take a look at our plots and we see now that all of our ports are also starting and after some time um also the application should get to a to a finished state, um which you will also see in the local final dashboard in a few seconds.

B

So after some after some time, we get all of this information also into our craze. um What we see now is that our application deployment, so the deployment of all of our workloads, has finished.

B

So you see the application deployment started at this time after that, all of the other things got deployed, so the pre-deployment deployment and post deployment of these workloads has been executed and now, in the end, the application pulls deployment. Tasks have been have been started.

B

um You can trust me that I've got the that I've got the notification now and yes, after that, everything should be fine, and um you should be able to know that your application is now working perfectly.

A

Can you go back to the grafana dashboard? Yes,.

B

A

That's really awesome.

B

So what you also see here now is that you see how long the first the first deployment took us to deploy. So we see that we that, with the took us 55 seconds and the second version took us a bit longer- um and this was because it um because the deployment also also finished in the end- um you could all could also take a closer look on all of this on the record. Whatever so you'll see the same, when you are when each workload workload has been deployed um in this time.

B

In this case, we have no average time between deployments at the moment, because at my first trial the deployment of the workload didn't even start.

B

And yes, we also see that the entry service took us one, one about one minute to deploy um the same for the left arm service, which took took a bit longer and so on, and this is a little start. So we are planning to do a lot of more Experts of such data. Yeah.

B

Thank you with this I go back to the presentation.

B

And yes, what we saw in our demonstration and what we heard by the by um on these explanations was that, with the cap lifecycle controller, we can deploy applications in an applicational Railway. So we don't have simply the possibility to work on a workload lever. We could also work on an application Level and this is really powerful.

B

Furthermore, we have render neutral observability included, so everything we have in the lifecycle controller is instrumented and can be exported to whatever open telemetric compatible solution you want.

B

um Furthermore, the integration of external tools is very easy, so you simply have to write a function or you could either create your own runtime and can execute whatever you want and in the end you saw that everything is very easy to install and configure and.

A

Maybe Thomas one thing to add here, because one of the magic things is: you are getting all of this by still using your tools that you use for deploying your changes, so you can use your Argo, your Flex, you can use your chain cans or you can do a cube, CTL apply, but we automatically without you having to touch or extend or build any of this into your existing pipelines, pre and post deployment checks.

A

We give you this pre and post deployment tasks natively in kubernetes everything through configuration, and this is what what gets mixed I don't think. We had a lot of great feedback from the people that are booth and uh yeah. It's awesome.

B

Yes, I also think these are very powerful features and will make the difficult native deployments much much um more reliable.

B

Okay, so um you who are looking on this video at the moment um might want to get in touch with us, and for that we have a repository for the lifecycle toolkit bottom word: there is a there's, a working group which is mainly focusing on all of these application deployment, things which is the app lifecycle working group, and you can always share your thoughts with us in the captains, in the sincere slack in the app lifecycle working group Channel and furthermore, there is also um a select channel for the development team where you can get in touch directly with the Developers and, yes, you can contribute, you can open up issues and so on I'm sure all of the cabin contributors are happy to approve your pull requests and um we are.

B

We are happy to get in touch with you, so um with this I think we're done on the right.

A

I think so too, uh please give feedback. Thomas is the main guy here, I'm, really just one of the people that tell the high level story but Thomas. Thank you so much for this. The goal is to get feedback you use it, give us feedback, and uh with this we can figure out in which direction we're taking this next. Thank you so much. Thank you.