keptn Keptn Lifecycle Toolkit, 27 Apr 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Introducing Keptn Lifecycle Toolkit

Description

This video walks you through the 3 major use cases of Keptn Lifecycle Toolkit:
1: Keptn Metrics Server standardizes access to all Observability Data
2: Keptn makes ANY K8s Deployment OBSERVABLE
3: Keptn can orchestrates deployment checks as part of scheduler

You can install the individual components of the Lifecycle Toolkit separately allowing you to pick and choose the use case you are interested in

Learn more: https://lifecycle.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/lifecycle-toolkit
Follow us on Twitter: https://twitter.com/keptnProject
Sign up to our newsletter: https://bit.ly/KeptnNews

00:00 - Introduction
00:47 - Use Case 1 - Keptn Metrics Server
05:03 - Use Case 2- Making ANY K8s Deployment Observable
11:10 - Use Case 3 - Automated Deployment Checks
16:30 - Wrap Up

A

Hi welcome to the introduction of the cap lifecycle toolkit, it's April 2023 if you are completely new to Captain. This is what Captain really is all about we're going to learn today. If you already experienced with Captain- and you know, Captain V1, then this is a great overview of what the captain life cycle. Toolkits can do for you. You also see all the links on the bottom lifecycle.caping.sh is a way to get started. You can also follow us on Twitter starus or join our slack conversation all right.

A

Let's get started, what can get captain be for you, uh everything I'm showing you today is a lifecycle.cap.sh. So this is the new trajectory forward. First of all, I really want to focus on three use cases. The three major use cases and I want to show you a demo on each. The first use case is around that we are standardizing the way you can access observability data in your kubernetes cluster, so you may have tools like Argo flux, cada, HPA or even Captain itself. That needs observability data to make automated decision.

A

Whether a rollout is good, whether you should scale up or down now in a world where you only have a Prometheus cluster, maybe for your stability data. Well, that might not be the greatest use case, but in most cases you have multiple observability Solutions. You have maybe a data dog, a diner Trace. You have data in AWS in Google and Azure. You may have data in lightstep or honeycomb or even Splunk or whatever data source you have.

A

If you have multiple data sources right now in kubernetes, you would need to maintain point-to-point Integrations from Argo rollouts flux, cada and HBA. They all have some plugins already, but it's really hard to maintain and especially as you move from one tool to another from one Ops ability platform to another, it's going to be really hard to maintain this. Therefore, the cap metric server is really unifying and standardizing access to this data. You can install the captain metric server completely Standalone. It's part of the toolkit all right.

A

Let me give you a demo, so what I have here? I have my kubernetes cluster installed just to let you know, I have the full cap lifecycle toolkit installed, but for the metrics operator, the stuff that I'm showing you the metric server. This is really uh all you need. You can use the helm chart and then just specify you just want to install the metric server. What's important is that I can specify metrics that I want to pull in from an external obserability platform. So in my case, I have kept metrics oops.

A

Here we go and I actually have two specified one from Prometheus and one from dinotrace. You can see the different queries here, so I can specify through a C or D what type of data I want to import and Pull and fetch it on account on a constant basis into Prometheus. This data is not only available through the CD here, but also through Prometheus itself and also through the captain to The kubernetes Matrix API. Now let me also show you a little bit on the configuration Here in My Demo environment.

A

The way the captain metric server works. You can specify one or multiple so-called metrics, provided. Let me zoom in here a little bit: I have the Prometheus Captain metrics provider in my namespace, pointing to that particular kubernetes or sorry Prometheus cluster and then I also have I have multiple data sources here. I also have a diner Trace provider, so here I have a dynatrace capital, metrics provider, with the information about how I can reach my Dimension server same would be true for data dog and any other uh data providers.

A

Now how do I specify what I want to retrieve I? Have a captain metric crd I actually have two here: I have my metric for available CPUs I'm using Prometheus to fetch this data every 10 seconds, and then I have a kept metric for the availability service level objective that I have in dynatrace, so I just specify the damage with query, and it also gets fetched in by the metric server on a continuous basis. That means to sum up this use case.

A

You can Define any type of metric from any type of data source and the captain metric server is pulling it in into kubernetes and makes it available to you via Prometheus or through the kubernetes Matrix API. One applicable use case I want to highlight here also a great blog post from one of our colleagues. This is about how we can use these metrics to scale YouTube using HPA. So you can see here. Hpa can now reference the metrics from Captain, for instance, as a kept metric on CPU throttling, and then you get the target.

A

So the point is you: do no longer need to maintain all of these point-to-point Integrations or wait until a certain tool, Builds an integration with your observability platform. We are taking care of this in case you're interested in this particular post. It's called scaling, kubernetes workloads in this case based on balances, metrics it's on LinkedIn and was posted by Florian Baja, all right, first use case Capital metric server, standardizes access to all of your possibility data, the Second Use case is Captain, makes any of your kubernetes deployments observable. What does this mean?

A

If you have multiple different tools that deploy into your kubernetes cluster, whether it's argoflex gitlab or even the coop CTL, sometimes it's a little hard to figure out what really happens? Why does the deployment take that long? Why does it fail so in order to troubleshoot failed deployments or slow deployments, or if you want to just figure out what is actually really happening in the kubernetes port scheduler?

A

You can also install the captain lifecycle toolkit, because Captain makes any of your kubernetes deployments observable by emitting open, Telemetry traces for all of the stuff that is happening in the kubernetes port scheduler, as you're deploying your workloads, we're also creating metrics. So you actually automatically get your Dora metrics for free and what's also very important. We don't just do this for a single workload, but we can also aggregate multiple workloads that belong to a logical, app together. This is why it says you will have automated application aware durometrics.

A

If you're deploying five containers, they all belong to an app. You can use metadata to tell us about what app do these deployments belong to and then we create an end-to-end Trace. Don't believe me, let's see it live alright. So, let's go back to my environment. I have, in my case, I'm using Argo CD in my demo and I'm deploying uh my repository. What is my repository? The same I showed you earlier with the kept metrics. So what I have here is I have a simple deployment, just a regular deployment.

A

The only thing I need to do really, there's actually two things you need to do. You need to put in some of the labels and annotations that kept and understand, so you can either use the standard, API kubernetes name, to give this a workload name and also the version. So we'll pick this up optionally.

A

If you have multiple deployments or state full sets, then you can also use the part off that really allows Captain to then, as I mentioned earlier, understand that all of these deployments belong to a single app and then you will get the information, metrics and traces for that app. Now, if you don't want to use those, we also have a captain specific annotations, as I said here, cap nap workload and version, but we also have always have a fallback to these others right.

A

So this is one thing you need to do and the other thing you need to do on the namespace just enable the captain lifecycle toolkit so on your namespace, where you want Captain to become active and make your deployments observable just put in lifecycle toolkit enabled, and that's really it so.

A

What I'm doing now I am going to change my deployment here, actually I'm going to change it to deploy version number three and I am going to change, also deploy a different image and I say: deploy V 302 of my sample app, that's great right committing and then what will happen is, in my case, uh Argo, hopefully will figure out. There is uh auto sync, and then it will start syncing so what's happening in the background.

A

Captain is understands that there's a deployment that belongs to certain app and it starts tracing the deployment itself within the kubernetes Pod scheduler. It's then creating open, Telemetry traces and it is going to create a metrics. Now if I go back to my environment again, what I'm talking about here is the lifecycle operator, also the scheduler, because we're extending the Pod scheduler to get in there. We are I think it's called a permit hook that we have Internet permit uh plugin.

A

What I also have here, I have an open, Telemetry collector because remember we are creating open, Telemetry traces here and metrics, so I have these sent to uh grafana, in my case, and also to Jaeger, which is installed in my case. So let me actually look at this data now I have oh here we go. I have my grafana here, the refresh see if we get some data here, we go. I got two successful deployments uh already right, I get some metrics average time between deployments deployment time.

A

These are all metrics that I get from Captain. These are all kept metrics behind the scenes. Let me just show you right edit. This is a captain. App total count metric that we give you with the dimension of uh you know what is successful, failed and also the app name itself. So let's go back here. So that's this piece same is true for all the other metrics. Now, what's really nice on the bottom here you can see that we have to this here. Let me go back and refresh.

A

We also have traces, so we do have traces for every single uh version version. One version two version three and let me actually open up version there. You go, let's open it up, and then you tab all right, I'm using the Jaeger extension here for grafana, but I basically get to see an end-to-end trace on everything that happens uh within your deployment and I can see here the big part, that's actually where the workload gets deployed.

A

We would then catch here if there's any failures, if it's low, why it is failing- or you know if everything is smooth, then that's great now there's a couple of other things here that will I will come to in a second, but just by enabling the captain lifecycle, toolkit you'll get observability into your deployments. Great for troubleshooting and remember great for getting all, or at least the deployment related Dora metrics, the devops metrics.

A

So this was number two Captain makes any of the kubernetes deployment observable with. However, you deploy, you get your metrics, you get your traces and what you can also do with this. We not only allow you to do traces for one particular environment, we're currently working on also tracing deployments across environments, so as you're promoting your changes from stage to Stage.

A

We also think about promoting the open, Telemetry Trace ID to the next stage and then be able to show you an end-to-end Trace from code all the way or from git to Cloud, as it's called Second Use case. The third use case can also orchestrate deployment checks as part of your job, scheduler, pre and post deployment. What does this mean, as we already sitting in the Pod scheduler, and we can trace start to end, and we are also application aware.

A

We can actually extend the task that the prod scheduler does before and after with what we call tasks and evaluations. That means we allow you to actually write either some JavaScript code that we run in the dino, runtime, pre and post deployment. To give you some examples, you could validate external dependencies. You can confirm that your images that are getting deployed are actually scanned post deployment. You may want to execute some tests, notify people on slack, promote it to the next stage.

A

So this is all possible through just writing some custom typescript that we run in the dino runtime for you, we do it before the deployment we actually block the deployment if the deployment checks are not healthy or not good, if everything is good, we'll let it go, and then we execute the checks after now, we also allow you to validate any type of metric pre and post deployment using the metrics from the captain metric server. So anything before is your environment healthy? Can we deploy into it?

A

Do we have enough resources would be a great pre-deployment check post deployment? Is my application really healthy, not not just the ports running? How are my slos? How is my user experience? Do? I see any new logs? Maybe that came in from my log monitoring solution. This is all possible here, so let me show you as well. That means let me go back into my demo here right, my deployment. You may have seen this earlier already under the annotations.

A

We allow you to specify pre and post deployment tasks and evaluations tasks. This can be a list. Evaluations links to a CID both linked to a CD evaluations, would be a list of objectives of metrics with a Target. So let's have a look at notify and also the evaluate dependencies we go up here.

A

Right I have a captain task. This is a sample of a JavaScript. That means we allow you to write any type of JavaScript that gets in some secure data that allows you to handle API tokens for external tools that you are calling and also the context. The context would be in which context is this function called for which app for which version for which workload you can see here. My example is actually Building Together constructing some markdown for slick, because my my function here is actually sending a select message for pre and post deployment.

A

Right I put this this tasks into the into kubernetes into the core kubernetes pod scheduler. You can see here it's secure parameters. This is where I keep my select token. So this is the function now remember. The function has been executed in my case. Remember this. What did they say here if I go to my deployment?

A

I said pre-deployment impulse deployment I want to notify. So now, let's make sure to check this out. I got my slack here and voila version. 302 was just deployed pre and post deployment. These were tests that are executed in as part of the captain lifecycle toolkit, meaning in the context of your kubernetes Port scheduler. That means you don't need to put these things into your pipeline into Jenkins Argo. You don't need to figure this out how to do this externally.

A

We do this at the core at the heart of kubernetes, which means if somebody tried to tries to bypass your pipeline, where you have your checks implemented, and it's just using a cube CTL to make changes. This will still be executed because we sit at the core of kubernetes all right. So this is it for the tasks. How about the evaluations? We also have the ability- and let me show you this as well Captain evaluations, so here I can specify evaluation definitions, I have one for evaluate dependencies.

A

This is where I say and again I'm referencing a captain metric the evaluator available CPUs should be more than four otherwise I will not deploy as a post deployment. Captain evaluation definition I can also specify multiple objectives. That should be evaluated, and this is an example of mixing and matching Prometheus and dinosaurs metrics all right, so this gets automatically executed. How can I see this well, in my case, easy to see. I can look at my Argo because some of these objects- the pre and post deployment checks- they're also shown here in my UI.

A

So, for instance, uh pre-evaluation checks. Look at this here, pre-evaluation kept and evaluated, and I can see here. Everything is successful because the available CPUs was actually eight, which is above the target, so it's all green right, so automated checks. So folks what this is. In summary, um we are helping you to orchestrate deployment checks as part of your scheduler native link, kubernetes pre-deployment, post deployment tasks, automated validation against geometrics everything annotation based, so that you don't have to put these checks into your Pipelines.

A

If you want to get started as I said lifecycle.cap.sh now, if you are already familiar with Captain what we built with Captain V1, you still find Captain Vivo on there as well. But hopefully you see how the lifecycle toolkit is a much better option, especially if you are purely on kubernetes, if you, if you're, already doing githubs with tools like Argo and flux, if you using cada HBA and you need metrics so we're pulling in the metrics, we are giving up stability into deployments and we're adding the deployment checks for you. This is it okay.

A

Actually, last thing I want to show you right. This is the current status, the life cycle. uh Captain.Sh, let's open up the website, it's still under progress. There will be new things happening all the time, but please join us with this. Thank you so much and uh happy captaining and uh see you soon.