Cloud Native Computing Foundation KubeCon + CloudNativeCon Europe 2017 (Berlin), 6 Apr 2017

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Lightning Talk: Boosting Helm with AppController - Maciej Kwiek, Mirantis Inc.

Description

Lightning Talk: Boosting Helm with AppController - Maciej Kwiek, Mirantis Inc.

Helm is emerging as a standard for Kubernetes application packaging. While researching it we discovered that its orchestration part can be improved. We did just that by injecting AppController right into Helm orchestration engine. This lightning talk is aimed to give users insight into advanced orchestration capabilities that AppController aims to introduce in Helm.

About Maciej Kwiek
Maciej Kwiek is a software engineer at Mirantis involved in Kubernetes development (both core and external parts). Before that he was working on orchestrating and deployment tools developed by Mirantis: Solar and OpenStack Fuel.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! 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.

A

Please join me in welcoming ma che a covey egg of Moran tez.

A

Hi, my name is Magic Jake I work as a software developer at Mir, aunties and today, I will talk to you a bit about how we are, how we are adding the advanced orchestration capabilities provided by app controller to helm or how you can boost he'll move up controller.

A

So, first of all, I guess most of you know what helm is and use it. It's super awesome. You have supports dependencies, so you can have charts that depend on under chart, but there is no empty orchestration helm. If your application actually needs orchestration, you need to write it yourself. You need to do it, for example, with any containers or any other way possible. So current from architecture looks like this picture, maybe not too nice, but there it is so there's client which gets input from user. It requests.

A

It sends request to the server which is called tiller, which receives user input and acts. Accordingly, it can create delete rollback, update your kubernetes objects and it also stores data about your installed releases. What we are currently doing is we are trying to update this architecture. We are adding new micro service called rudder, so tiller is still the component which handles resource which handles releases, but it, but it requests the actions to be taken on kubernetes objects to rather itself. So rather is the part which actually installs upgrades roles back your kubernetes deployment, pods, etc.

A

So rudder is an interface tiller or anything else communicates to it via RPC, and as long as it implements the specified dirties interface, you can write your own rather the proposal for it is here. If you take a look at this presentation later, you can follow, link and see it. So first, we started off with a default rather basic, rudder native rudder, nothing changes. So the only thing that changes is the architecture of the helm deployment which has additional pod with rather running in it.

A

But what it gives us is that we have a framework on which we can improve upon and which we can use, as as a baseline for our further implementation with better orchestration.

A

This is where up controller comes in to mix up control is a project which we are working in my aunty's since the end of the last year. It is focused solely on orchestration inside Cuba, this cluster.

A

It runs as a standalone pod. You define your deployment graph and you store it in kubernetes storage, so you don't need any additional storage and you run orchestration when you define your whole deployment graph and it just deploys it. It goes topologically through the deployment graph, so so that children in the graph are created after parents and it gets also some advanced status checks. So, to give you an example, we have a basic chart in helm, for example, WordPress chart which depends on the MariaDB chart, so there is helm dependency here.

A

So what up controller specific rudder actually does? Is that when tiller requests, creation of the objects called from which helm from it sorry from each mariadb and WordPress chart consists, it creates up controller, specific dependencies between all WordPress objects and all MariaDB objects. It may sound complicated, but what it boils down to is that no WordPress object will be created before all Maria. Db objects are actually ready and by ready, I mean ready in sense of having readiness probe returning that the status is ready.

A

So right now the current implementation of a controller, rather, as I said it derived the deployment graph from chart dependencies. So it goes through your chart from her home chart tree and create dependencies based on that in the future. We also want to add the dependencies derived from the intro chart definitions, so the parts of your chart, which is one whole, can depend on each other.

A

So if you have a parts of your application which shouldn't be in separate chart, but which should consist one chart, they should be able to, they should be able to depend on each other, but this will. This will need update. Update of the chart of the chart, format on which we are will be working on this is it. Thank you very much.