Cloud Native Computing Foundation KubeCon + CloudNativeCon North America 2020 - Virtual, 4 Dec 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Navigating the App Delivery Landscape While Solving Everyday Problems - Lei Zhang & Alois Reitbauer

Description

Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2021 Virtual from May 4–7, 2021. Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

Navigating the App Delivery Landscape While Solving Everyday Problems - Lei Zhang, Alibaba & Alois Reitbauer, Dynatrace

Recently there was a lot of buzz around the CNCF landscape getting overly complex. There are more and more options to choose from which is good to see a growing ecosystem. However, this can sometimes also become overwhelming. In this session we walk through major challenges that people are facing and show how they can be solved with projects available today. We will look into scenarios from defining your application all the way to running it in production. Whether you are just about to start running applications on Kubernetes or want to improve your skills. This session will help you to identify what to consider when building app platforms, share good practices, compare different approaches and give you an interactive and quick tour through the CNCF landscape with a focus on delivering and running applications. You will also get some demo code samples to try everything hands on and have a reference to get started with your own projects.

https://sched.co/ekFr

A

Hello, everyone and welcome, first of all to my home office here, second to kubecon, virtual north america and last but not least, to our session today about navigating the app delivery landscape while solving everyday problems that I'll do together, brisley from alibaba. My name is alois. I work at dynatrace where I'm responsible for open source.

A

Okay. So let's get started.

A

This is the session done by the app delivery sig. As you might know, there are a number of six in the cncf. The app delivery sig is dealing with pretty much everything that's required to delivering applications in a cloud-native way. You can engage with us in various ways. You can obviously go to the github repository. You can join our bi-weekly meetings, engage with us on slack or the mailing list and obviously read more in our chat about what we're doing and where you might want to contribute.

A

So when we look at the cncf landscape, we see that there is a lot on it. What started out pretty small has really grown super big. Some people find other words for it. But there's like a lot on this landscape right now and it might be oh it most likely even is pretty much overwhelming when you're looking at it for the very first time, also from an application delivery perspective, you might want to figure out which tools am I going to take?

A

How do I use them and it almost feels like a puzzle which led to people actually creating a puzzle with the cncf landscape? It's a 1000 pieces puzzle that you can assemble and especially for newcomers. It might really feel like this.

A

So from an application delivery perspective, we can obviously scale it down a bit and if you restrict it to only cncf project, there's still a number of projects there. We have some in the application definition image, build area, summing the continuous integration area and some other scheduling and orchestration piece. There is helm, obviously kubernetes the operator framework, argo and quite a number of sandbox projects like captain flux, porter number of others, kudo and so forth.

A

There's also the cncf tech radar, and in june this year, the end user community of the cncf did a tech radar on continuous delivery, which is a subset obviously of application, delivery and categorize tools in three different categories: adopt which means people are using it trial, they're in the stage of rolling it out, they're experimenting and assess, meaning that they are looking into it. So I also encourage you to look at the cncf tech radar what we did within the app delivery sig.

A

We also created, like a reference model, to categorize tools, by what they're doing and also to break down this app delivery space into smaller junks on the top left. You see application definition, so this is pretty much everything you need to define your application in the replication model, then there's application packaging so once you've defined it, you need to package up all of those components that you need and work with them. Then we have to roll them out and orchestrate them.

A

This is the entire area of lifecycle, management, rollout strategies, traffic management and so forth, and then we have obviously their workload instance healing scale out. Sharding lifecycle, management and so forth, so this is just another way to look at it.

A

What we have decided uh in one of the reasons, sick meetings is, we should showcase how you can use different tools for different areas of the application delivery space, and this is how we ended up with project potato head. Potato head is a very simple cloud native project, probably the simplest cloud native project you can build. It just consists of one single service, but it allows you to explore different delivery tools and how you can use them and, last but not least, it's kind of a funny name for a project.

A

So let's start super super super simple.

A

Just with two manifests. The easiest way we can write an application in kubernetes is to write a manifest file that contains a service and a deployment, and this is exactly what we will look at right now.

A

So in the potato head project, you can find this folder called manifest, which contains that.

B

Manifest that has a namespace.

A

Service oops and a deployment over here.

A

Obviously, the only thing we need to do right now is to.

A

C

A

And I'm exposing it right now as a load balancer, so it might take a.

A

A

So just trying to get the ip while this is.

A

A

Taking a bit long here we go so here we have it now we can switch.

D

A

B

A

Have version 0, 1 0 running now I would have to get back into this file. We modify it oops and by oops, applying.

C

A

Again, it will update.

A

And we will see version 1.1, so I think this doesn't come really as a surprise to anybody just get rid of this one here.

A

A

Well, this is easy and straightforward: it doesn't really provide us with a lot of flexibility right and.

D

B

A

Have to kind of get into the manifest files mess around with all the details. This is not what we want to do, so the next step would be to use a helm, template and potato head. The potato head project comes with a very elaborate example of a helm deployment. This is just to showcase what we're trying to do in here and thanks to matt farina for providing it.

A

What we're doing here is basically replacing the namespace by picking one and the images we also replace in the values file and then in the values file. We specify our helm namespace here.

A

So that's pretty much. What we're doing here and if we now get back to our example,.

A

Just move out of this one.

A

A

We can see in the charts that, for our hello service, we have pretty much everything in there if our.

B

A

Charts file our values file, which we'll need in a second. This is not what we should put in here and again. We will be deploying version 1.1.

A

So what we can do right.

B

A

We are in the charts directory.

B

We are deploying our.

A

Key our helm, release called kubecon.

C

A

That's already what we did.

C

We just need to expose the.

A

A

A

Browser version 1.0.

A

Now we get back upgraded to version 1.1.

A

Switching to a helm upgrade.

A

And again, exposing the service.

A

And now we will see that it's running version.

A

1.1 and as we now no longer.

B

A

We're going to use helm, uninstall.

A

A

I'll release again.

A

So not a lot of rocket science here um already great that we only now need to change the values file, but what if we want our changes to be really applied automatically right now we always have to run cube control apply or we have to unreal upgrade.

A

So is there an easier way to do this.

D

And luckily there is.

A

We can use a tool called flux, so flux is a githubs operator which modulus means it takes whatever is in a git repository and uses. What is in this git repository and applies it for us helm. uh Sorry, flux can do even more for us, it can do the same thing, obviously with helm it. I can also pour and point to a container registry and check for container registry updates that we want to use.

A

So what we're doing right now is we will be configuring, flux.

A

To do for us what we want it to do all right.

C

A

In order to make this work, we have to fetch the flux deployment, because there are a couple of things we want to modify in here. Let's get rid of this one and get into the flux directory in the flux deployment, uh we must tell it the branch, the github user.

A

Let me just use the manifest here. We could have used the helm version as well, but it doesn't really matter um the git labels to be used and the polling interval which we're putting down to one minute.

A

You might want to keep it usually the way it.

A

A

C

B

A

A

Flux now, and the only thing we need to do is now that we use our again wait for.

A

Rip: okay: we have now this one minute waiting interval uh already getting there.

A

C

B

A

Interestingly, for flux to work, you also have to provide a deployment key, which I have done already before here, but this is what the github repository users, as you can see. It's using my local fork of this github repository.

A

Wonderful, so in this case we are pointing it to our hello server, see its version and now I'm doing something that I should not be doing, but still for demo purposes. I'm allowed to do it. I'm editing my deployment file here right in git doing it directly.

A

Obviously, what you should be doing is not editing this file directly. You should have a pr workflow behind it and you can have point flux there and then handle it that way or does it have updated the container image um to be used here and we have set our polling interval to one minute so pretty soon we should see the updated version of our deployment.

A

Here, okay, just double checking here: yes, we set it to 1.002.

A

And give it a bit more.

A

Time you see this is already pretty convenient, because now we only have to commit things to the github repository and that's also why I see why git dops is becoming so so popular.

A

You don't really have to know a lot about it, but here we go here. We have it updated how the application is is working, it's just happening, it's just there and everything is fine.

A

So just let me quickly fetch.

A

My deployment again.

A

That's not what I wanted ah yeah. Obviously it doesn't work.

A

Yeah, I'm just getting it and setting the interval to 20 minutes again. I don't want to run into any.

B

A

And also disabling this one.

A

A

C

And deleting the namespace.

A

Because we don't need it anymore,.

A

Okay, so this worked great now, let's move on so what.

D

Do you want to see what.

A

Happens, flux is really great because it's this lean tool that can do all uh well what it's actually doing and it's working great. But what, if you want to have a leaner way of or more, uh let's put that way? Let's have a more interactive way of looking at it, and this is where argo.

B

A

You can see, arco has a very nice ui and it okay. You can also do githubs with argo, so this is what we are going to do right now. We call it demo.

A

I'll call it hello server, argo see it has this very nice ui.

C

Or to create namespace.

A

We're pointing it now to our.

A

A

You can pick the revision you want to take and we also specify the path in our case is again delivery manifest.

C

We could do.

A

The same, and we will do it then in another example, with a helm chart, but for the time being, this is totally fine team space argo.

A

Here we go now, we say create.

A

Okay, now, let's sync it so we see that all of these resources right now are out of sync, and now we have this interactive way on how the application gets created. Service is still under creation.

A

But we see all the resources that get created individually and honestly very appealing way, as I feel so. I hope you like it too. Let's give it just some time again to create the service.

A

Just closing the old one here moving in here.

C

Oops picking this one into the browser.

A

And we have version 01.2 which we set before here, because we're using the same file as before. Now, let's switch it back to 0.10.

A

Commit the changes perfect and what we will now see in argo if we refresh it. Obviously we can set argo to automatically refresh. It shows that some resources are out of sync allows us to resync. It see that for the new version it has created a new service, and now, when we refresh this one here, we see it's back to version zero. One zero very nice thing here is: we can simply go in here and also delete the project and all of its depending resources.

A

Which is pretty neat.

A

So that's great! um What's next so far, we have really worked from like a manifest parameterizing it using a different githubs approaches from flux, which is very lean to argo, which has all like this visually appealing things around it. But what we did we more or less applied everything to the cluster and we didn't really care whether this was a good idea. It wasn't a good idea, we didn't do any cannery releases, look green releases or anything.

A

This is really where argo rollout now comes into play with our go rollouts we are going to replace our deployment with a special crd called a rollout in argo. That looks pretty much like the deployment theory, except that it has this strategy part in here where it defines and how the application should be rolled out.

A

It again has this visual appealing view, and it comes with a nice command line tool here as well. So let's switch over here, creating a new application.

C

A

C

Some policyman automatically create the namespace.

C

A

Or I don't want to type it again, oops.

A

And now we pick delivery, rollout.

A

Locally cluster.

A

A

Argo and with helm, finds the values file, our version tags and everything in there and now we click again on create and sync now.

B

We're creating five.

A

Replicas simply well, it's kind of more helpful that five of them, especially when we should want to show canary releases.

A

Okay, here we have, our service doesn't have a host name.

C

C

Oh right, let's move over.

A

A

C

A big surprise.

A

App is working.

A

Again, what we will now do is we go into the rollout again. This is something you should usually not do directly by editing.

A

In line we'll switch it to version 1.2.

A

And yeah argo already comes with a very, very handy command.

B

A

A

B

A

A

C

And now we can.

A

Say uctl argo.

C

A

Out coping and roll out.

C

A

That's the argo rollout, obviously.

C

A

We make this interest, you can have to specify the namespace demo.

C

A

Ergo and we want it interactive here we go so here we see interactively how this deployment is going.

A

Now we go back to argo and refresh.

A

A

And we see a new part gets created and the status has been changed to paused.

A

Which we can also see over here. The reason why this one here is paused is something we can easily find and a rollout, because the way a rollout is defined that the first weight, uh the first pause here doesn't have a fixed duration.

A

But, rather than having a fixed duration, it will wait for us to manually promote it. So this is what we're doing here now. This is cube control our go.

C

C

C

Mode, what was the raw called again like this oops.

B

Let me just push this on here.

A

Sorry so then, let's get it over.

B

A

C

Go go roll out.

C

My promote space demo space r go yes, perfect.

A

So what we can see here now that the releases are switching over- and we can see the same over here as well releases- are progressing really nicely good.

A

We're not going to wait for this to finish here really, but rather delete it.

A

B

A

One more thing to do now: we have automated quite a lot. We have used roblox strategies, we have shipped different versions, we have switched to github. So what? If we want to do this in a multi-stage environment?

A

D

Is where captain.

A

Comes into play, so what captain provides captain provides a control plane on top of what you have already seen so far that support github that can create stages and can build your entire environment. For you, captain uses a file called a shipyard file.

A

This is what you see over here, so the shipyard file specifies which stages you want.

A

And the deployment strategy and how it should be promoted between the stages most of this is set here to automatic, with one exception.

A

For production.

A

A

So now we move into the captain directory and.

C

A

So we can just say init project over.

A

A

And we should highlight what we actually wanted to do. Let's just create.

A

A

So what happened now is when we switch over to the captain ui just refresh.

A

That we have this project created that has exactly these three stages in there. So as of right now, this isn't really doing a lot.

A

We have to do one more thing over here, which is linking it to an upstream git repository.

A

So captain fully supports skid, ops and what I have handed over here. uh There should be one more here. We go. That's the right one! I had.

B

An empty git, repo.

A

In which we see that captain has started to create a branch for each stage and it's storing its own file like the shipyard file and everything in here as well.

A

D

A

This and also created all the git ops content out of the box.

A

The next thing we need to do is we need to onboard a service.

A

Into this project,.

A

For onboarding the service, you just pass in against your values, which in this case, doesn't really need to contain a lot and your templates again for the deployment and the service. That's pretty much everything that you need.

A

And you see that a lot of the chart- creation that happens inside of captain- and this is obviously still ongoing. And now we already see our hello service here, which has been successfully created if we switch back to git.

A

We load here. We also see that there have been pushes to the individual stages, because now we created all the helm, charts and started to execute them.

A

Also see that there is automatic istio configuration in here, because we're using blue green deployments.

A

And now it is time to actually onboard.

C

The service, which I think is yeah first of all, service.

C

A

And we are deploying version, one.

A

One you see that there is a configuration changed, so captain received a new request to deploy.

A

Something and also the environment will get updated in a minute. It just takes a while to rewrite all the helm charts. I was able to write the values files in this case and start deploying things.

A

Yes, here we already see the deployment finished or you can jump right there. You see it has everything configured out of the box, it's running version 1.1 and even having the stages configured in.

B

A

And obviously, as part of the environment here we also see where that service is already right now, and it's currently now propagating through the stages. Captain also comes with an automated test execution and an evaluation of slis and slos, as we haven't specified them right now for our demo purposes, it automatically passes them because there are no tests.

A

We now see this being propagated to uh our staging environment.

A

And in a second oops, it should be in staging as well.

A

So it's all still.

A

A

Which should be done in a second, so the whole idea is that usually you can also onboard sli slow files, as I mentioned, and test files, you could just give it, for example, a tree meter test, and it will automatically detect to execute that meter. Test has to be executed as part of the deployment.

A

Okay still waiting for this one here to.

A

Deploy now we're done here, we go same thing here and now what we can see here is an approval triggered. If you remember, we specified in the shipyard file that for a production deployment, we want to have manual approval and that's why we get this approval, which you would also see over here.

A

We see that there is one think of this, like, as you have like, git tops in place here. These are obviously two branches is that this branch is like one commit behind the other one and as we're accepting it, we're pushing it through now so, and the last thing we do is.

A

Running and init project deploy service and we now do.

A

A

See the new configuration changed now, things are rather see a bit quicker and see that the new version has now been deployed in depth already here we can see how it's propagating through the individual stages.

A

And well, that's it for captain and now I'd like to pass over to harry.

D

Thank you guys. It's really awesome demonstration to show off the application deliver ecosystem by using such kind of unified demo application. Okay, so I will continue with alloys talk to uh fill up with more uh interesting user cases in the ecosystem. So this is basically about uh in many cases that you that you actually want to deliver and manage the application by by hiding all its details. For example, the first tool you can use is using operator, but this time you will use operator to package your application instead of manage your application.

D

So the reason you can do this is because the operator sdk gives you the way to convert a helm, chart existing hem chart into a crdn operator. So in that case you can define cr to run application, and the specification of this customer resource is exactly generated from the values of your helm template. So this is basically how operating enable you to package any software into a software distribution.

D

So, in order to do this, uh you basically just need to play with the operator sdk to generate the crdn operator for you. So if you do, for example like this, the operator sdk will handle everything for you and then we can actually try to deliver the application by using a customer resource. Let's see the example here,.

D

Okay, so this is the customer resource we have now, and this is exactly a I would say it's a distribution or software, because the user can only configure, for example, the given parameters here. The user cannot change the helm template because it's now a crd right, okay, so in that case we can definitely.

D

We can definitely apply this cr to our cluster right. Just like you deliver your application.

D

Okay, as long as we do this, the hollow service, hello, server or operator will actually create the application for us. If so, if you check the cluster, for example, git deploy because okay, the hello service is running, so if we check the service.

D

You can see the holo service already there and it has to be exposed. So if we use mini kubi to say okay, I want to expose hello service.

D

Okay yeah now we got the running application right here right. So this is basically how you pack your software uh into a operator, so you can distribute your software by using a crd2 cluster okay. So for now we have introduced a bunch of independent tools to solve your problems.

D

But what if I want, is a flow platform right, just like something like eric on top of kubernetes, so I can have pretty awesome user experience, but on kubernetes right. So in that case I will introduce you the kubila project, which is very interesting because it's a extensible application platform based on kubernetes.

D

So essentially, if you are using kubervela, what you need to define is a very simple yamaha file like this, which name is app file, something like docker compose. You define application here and we define the operational configurations like these routes and auto scale. That's all, and then the system will translate this yama file into open application model and then generate the equivalent resources for you, including deployment service, ingress control, revision, certificate, kita, skilled object because you define the autoscaler here, robs the rd, because you have a rod configuration configured here. That's all! That's that's!

D

The kobe villa you can see here is essentially upper layer or application. Centric abstraction on top of kubernetes, but what's more important, is kubervela is highly extensible. It's not it's not just simply a abstraction. It's a highly extensible attraction, for example. If I want to add a new feature like canary rollout in my system, right, which can be provided by flagger, the only thing I need to do is to install this chat definition reference canary crd from flagger as a capability.

D

That's all you need to do, and after after you've done this, you can just define the rollout section in fl directly after you have installed the trade definition. That's all that's how you add a new capability, even as complex as draw out into your kubervilla system, so this is kubernetes project.

D

So, what's next for the potato application, we really want to extend the same application to more complex use cases, including multiple services in one application, including stable workloads database like that and also going to add more tools and user cases around the application from the ecosystem, like chaos, engineering and other kind of application, operation automation system. So this is the goal for this sample application and the next step for sleek application.

D

Delivery is also exciting because we will go to the direction which show you the code instead of white paper, so we're trying to add more real world demonstration to all to answer the question that what the project can be used for, as well as a series of technique, technique, technological blocks, about the deep diving to the project, how different companies are doing that and so and of course, we are working on the cnc beretta, which is for application delivery. It's quite similar to the same separator. We have today, but focus on application management. Okay.

D

So if you are interested in all of these topics in this talk or in this role, map feel free to join the meeting to join the community. We are looking forward to that. Okay, so we hope you have a great journey on the kubicon. Thank you very much.