Cloud Native Computing Foundation KubeCon + CloudNativeCon Europe 2020 - Virtual, 4 Sep 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Introduction to SIG-Cluster Lifecycle - Lubomir Ivanov , VMware & Justin Santa Barbara, Google

Description

Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io. The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

Introduction to SIG-Cluster Lifecycle - Lubomir Ivanov , VMware & Justin Santa Barbara, Google

The Cluster Lifecycle SIG is the Special Interest Group that is responsible for building the user experience for deploying and upgrading Kubernetes clusters. Our mission is examining how we should change Kubernetes to make it easier to operate. Since the group's formation we have focused on creating kubeadm, a streamlined installer tool and building block to simplify the installation and upgrade experience, and building a Cluster API to provide an abstraction of machines across different deployment environments and a common control plane configuration. In this introduction session, we will present the SIG's mission statement, review recent accomplishments, and discuss our future plans, where you are very welcome to contribute to the discussion. We will also focus on how new contributors can get involved in helping shape the future of Kubernetes' cluster lifecycle management.

https://sched.co/Zevf

A

Hello, everybody welcome to the introduction to sig cluster lifecycle. My name is justin santa barbara. I am one of the sig cluster lifecycle co-leads, I'm also a software engineer at google. My github handle is just an sb lubermir and myself are going to be giving this presentation together, but we are representing the work of a great many people within the sig.

B

Hello, my name is ruben verivanov, I'm a sequel life cycle colleague, software engineer at vmware's, open source program office and my github handle is neolit123.

A

Okay, so what are we going to talk about today? We're going to talk about sigs and what sid cluster lifecycle is trying to achieve we're going to talk about how we're trying to achieve that through multiple sub-projects.

A

We have time to highlight only a few of those sub-projects, so we're going to talk quickly about kubereum, cluster api and component config and finally, we're going to tell you how you can get involved and ask you to start your involvement today by filling out a survey that will help us figure out what we should prioritize in, say, cluster lifecycle.

A

B

Is sequester lifecycle in kubernetes? We have special interest groups, also known as six and sequester lifecycle is one of those all the six also have charter documents, and a chartered document is something that defines what are the goals and long goals of a particular group.

B

Sequester lifecycle's objective is to simplify the creation, configuration upgrade, downgrade and tear down of kubernetes clusters and their components as a special interest group. You also have a vision to develop the tooling necessary to build a highly automated meta cloud. A meta cloud here means imagine something that is a kubernetes cluster that can be deployed on any cloud provider.

B

We want to avoid the pitfalls of the past, because we had some unsuccessful experiments in the past. Everything should be declarative. Api driven arcade, like deployment type of style and managing these questions should be as easy as managing the kubernetes objects like pots. That is a familiar pattern to everyone.

B

We want to make the 80 use case simple, and the 20 use case possible always consider a simple configuration available to everyone, but there has to be this advanced configuration that is still possible to the rest of the users.

B

We also want to commoditize or standardize kate's cluster deployments. So if somebody is looking at your cluster, eventually they're going to know that okay, this is following a standardized way. A standardized pattern for cluster deployment.

B

So in this slide, we have a diagram of the current stack of tools that we are working on at the bottom. We have hcdadm and cddm is potentially a manager of hc requesters, a cli and a library that is working, progress, potentially consumable by high level tools.

B

On top, we have cube adm cube. Adm is a cluster bootstrapper, as uh a lot of people should know already.

B

Equestrados is a project where we are working on standardizing the way adults are deployed in a cluster and they're managed as a life cycle like how do you upgrade them? How do you downgrade them? Quasar api? A lot of people should be familiar with quest api as well. This is a project where you can create clusters using a declarative model, it's very similar to the kubernetes declarative patterns. So if you combine these two, these tools, you can potentially produce artifacts that you can then feed to an image builder.

B

An image builder can create a like a virtual machine image for you, and the virtual machine image can then be fed to the cursor provisioner, which is a layer on top the custom provisional can create. You a cluster that uses this virtual machine image and, finally, on the left we have component config. Corporate config's idea is that we can configure all these components on the right side with a declarative api that is very similar to the kubernetes api and in fact it uses the same machinery.

B

As a group, we are also trying to follow a particular philosophy, and that is arguably the unix philosophy we want to make each program do one thing and do it very well. The boundaries between the separate projects should be clear, and there should not be ideally that much overlap.

B

Every computing infrastructure project that initially meets one need well will eventually expand in scope to only meet several needs poorly. This is something that we have to avoid. We also expect the output of every program to become the input of another program and combining all the tools that we have. We want to create this voltron-like.

B

B

On this slide, you can see abseldo voltron example. It's a immutable, node update type of scenario, so the left side. We have a ci that triggers a rebuild of artifacts notifies an operator to update customer manifests that are potentially consumed by the cluster api. The cluster api can then perform a rolling update. Then a bootstrap provider which in this case is cube adm to trigger the new nodes to join the cluster.

B

In this section, we would like to highlight some projects that we are currently working on.

B

The first project we would like to highlight is cubadium. Our of you should be familiar with kubernetes at this point. Cubadiem is a coaster bootstrapper. It has a simple task. It should create a best practice, kubernetes cluster, for each kubernetes version. It should have a simple user experience and the cluster should be reasonably secure. Kubernetes has a limited scope. It's intended as a building block only deals with the local file system in the kubernetes api. It does not deploy a cni network for you. This is out of scope and you have to manage this yourself.

B

You can pick a cni solution and apply it over the cubedium created cluster as an addon. It has a composable architecture and everything is divided into phases, mostly everything. It was for high level tools to break down the phase process and pick the elements that they want and such high level tools are, for example, chef and puppet.

B

On this diagram, you can see example, usage of cube adm, so the first layer is the infrastructure provider that can give you machines, such as a control, plane, machine designated for that role and also regular nodes.

B

The second layer is where the bootstrapping happens, and also the kubernetes api creation, and finally, the third layer is where you can apply add-ons, that is the infrastructure orchestration. Also cluster api is there so based on a cluster api specification, you can trigger a certain implementation of the cost api to reprovision infrastructure, for you.

B

The kubernetes project has a roadmap. We want to simplify day 2 operations. To do that, we want to create a cube adm operator. The kuberium operator's idea is to allow the users to manage some features that are currently missing in kubernetes, for instance, we mentioned earlier, a tool should be designated to do one thing and it's always called for cubadiem to manage all the nodes, because cubadm is run on a particular node.

B

It does not know about the other nodes in the cluster on the infrastructure level, so you should be able to reconfigure these nodes using the kubernetes operator and potentially by utilizing a declarative pattern. We want to support different workflows like changing the cluster behavior overall or certificate rotation. We want to make cube adm friendly for high level tools.

B

We want to do that by enabling machine, readable output. Currently machine, readable output is only possible for some of the commands we want to enable it for all the commands and we want to make the phases for cubed emulating join retriable and, where possible, with important.

B

We also want to increase the flexibility around add-ons and lcd by leveraging some of the ideas of coastal addons. We want to transition our coordinates in q, proxy deployments, which are currently the core add-ons incubation to operators, and we have to also lower the barrier between what is considered local lcd and external lcd. We want to simplify component config management.

B

We are going to talk about this later in the slides and also, very importantly, move cube, adm out of three out of three means: the kubernetes kubernetes repository and around that we have to define a new release process and build automation, and this will allow easier vendoring for those that wish to consume cubadiem as a library.

B

If you want to learn more about cube adm, we have a cubed deep dive session at kubecon europe 2020, that's on wednesday august 19th. The presenters are going to be ross gergier from vmware and rafael lopez from.

A

Susie, okay, I'm going to highlight another one of our projects. The cluster api cluster api is building a declarative, kubernetes style api for creation and management of clusters.

A

It also manages some of the infrastructure that is cluster scoped things like networks or iam policy. From your cloud provider, it's focused around a declarative specification of the machines that become the nodes of the cluster.

A

Some important things to understand this is different from the kubernetes cloud provider, which provides workload cloud resources like volumes and load balancers. This is provisioning, similar infrastructure, but for the cluster itself, and one of the important design decisions was that the specification of a machine is immutable.

A

But it's interesting in that cluster api still provides the ability to upgrade the cluster.

A

You may be asking yourself: how is this possible? How can the machine be immutable yet the cluster can be upgraded and therefore be mutable, and the answer is that we follow a similar pattern as kubernetes does we don't just want to use kubernetes crds?

A

We want to follow the kubernetes api design patterns and in kubernetes there is indeed a similar design pattern. Pods are immutable, but pods are wrapped by replica sets which runs a number of them. A replica set remains immutable, but a deployment creates mutability over those replica sets.

A

It is able to create a new replica set and scales down the old one and scales up the new one, so we use exactly the same pattern and cluster api. A machine like a pod is immutable.

A

A machine has a number of replicas in a machine set like a replica set and a machine set is still immutable, but a machine deployment can create a new machine set scale down the old machine set and scale up the new one. A machine deployment is just like a deployment and that's how we can achieve immutability at the machine deployment level.

A

The machine is the same crd, whether this is on aws or gcp or vmware, and there's an analogy here to storage classes in kubernetes. There is similarly a machine class machine class is a kubernetes object that describes attributes of the machine that are specific to that cloud provider.

A

Just as a storage class describes, attributes that are specific to a particular storage backend cluster api is a newer api and we've actually developed our thinking around this design pattern over time. Machine class objects are actually typed objects. It has a different kind on aws than on gcp aws is an aws machine. Template gce is a gce machine template.

A

This allows for the fields of a machine class object to be specific to the cloud or infrastructure provider, and that allows us to get richer type, checking and validation than we do in the storage class, where a storage class has the same kind across all the storage backends, so not only reuse but also evolution of the kubernetes design patterns.

A

So let's talk a little bit about the cluster api roadmap. Cluster api is still in alpha, so how does it get to beta? Generally? The main goal is to get it into widespread real world use and continue to get feedback on whether our expectations match how this thing is used in production.

A

More automation also helps with this goal, both automation of testing and of the project processes, but the next couple of alphas are going to focus on some of those blockers, robustness of the control plane, a few features like auto scaling and spot instances, some improvements to the primary user facing tool called cluster ctl and in the alpha after that, resiliency of the nodes extensibility of load balancing using the latest features from some of the other sig sub projects.

A

In order to get to beta. The really big thing we need is better documentation which goes hand in hand with more feedback from real world users, like you, also getting it integrated into some of those higher level tools. So, for example, cops is planning to support cluster api initially for the nodes and getting the existing kubernetes e to e tests using cluster api on gcp and on aws.

A

As you can tell, cluster api is an exciting and rapidly evolving. Project. Nadir and cecile are giving a deep dive talk on wednesday. So if you'd like to learn more, I highly encourage you to attend that another.

B

Project that we wish to highlight is component config. Corporate config is a kubernetes style api for configuring components and component config is trying to solve some problems. The first one is that the core kubernetes components are not consistent in how they are configured.

B

They use a lot of flags and often times the flags across different components that do exactly the same thing have different names. The solution for that is that the core component should implement component config and in fact, most of the core components have already started doing that. Another problem is that it's pretty hard to write a case like component with declarative conflict, so adding a corporate conflict itself is not that easy.

B

So the solution for that is that we should factor common logic for component related code in the repository designated for that that is component base, and it's a toolkit. It's going to make it easier to write a new component that immediately implements a corporate config that uses cades api style of configuration and existing components should be retrofitted to use the same toolkit component config gives us a lot of benefits.

B

It has maintainability. So when a component has a flag set that grows over 50 flags, configuration becomes painful, upgradability, so for upgrades version, configuration is arguably easier to manage than flags since flags are convergent.

B

Programmability configuration expressed as json and yammer objects allows for consistent manipulation, templating patching and introspection and also possibility. Many types of config simply cannot be expressed as key value pairs.

B

And, finally, it's also declarative open api information can be exposed using component config and used for generating documentation for your config to learn more about component config. You can watch this talk that lucas kelstrom gave the previous cube call, and in this talk you can actually see some of the details. Implementation details around how we are actually implementing component config in existing components or how do we want future components to implement it?

B

In kubernetes we have a working group that is called component standards. It's a combined effort between sequence, lifecycle and sick api machinery trying to tackle some of these problems around component config to get engaged to find more about it. You can follow these links.

A

I wanted to talk a little bit about how you can get involved. Most of the projects we've described are not yet in ga. Kube dm is some of the high level provisioning cluster provisioning tools are, but otherwise the projects are in beta in alpha or even pre-alpha.

A

So we need your help and I'd suggest this is also an opportunity, sometimes as a kubernetes contributor, it can feel like everything that can be done has either already been done, or there are 10 existing issues stating why you can't do it. That is very much not the case in sig cluster lifecycle. There's a lot of work still to do that. Work is very concrete and we are very oriented around encouraging contributors.

A

Specifically, we have some onboarding documentation, which is a great place to start along with our community page.

A

Many of the sub projects are excellent, triaging issues, they label issues with good first issue or help wanted to try to steer you to issues that don't require the in-depth knowledge that you'll likely gain over time. A great way to get involved is with documentation or even just trying out different things and reporting any issues you encounter.

A

There are a number of zoom meetings, there's an overall sig cluster life cycle week, meeting bi-weekly and many of the sub-projects have their own bi-weekly meetings as well. So please attend ask questions. Introduce yourself, introduce yourself on slack, there's a very active slack channel where you can find people at all hours of the day and night, if you're not yet a kubernetes contributor. I encourage you to attend the new contributor sessions that are run by sig contributor experience in general.

A

The kubernetes community philosophy is that you earn your place at the table by chopping wood and carrying water by taking on the tasks that need to be done, so everyone is expected to get involved, and the flip side of that is that you are therefore welcome and encouraged to get involved.

A

If you want more c cluster lifecycle content, there are two other talks of particular relevance to sig cluster lifecycle on wednesday. There is a talk about minicube and on thursday talk around component config dynamic configuration with component config and the control loop.

B

Sql's lifecycle is running a survey for 2020. in this survey. We have some generic questions like custom sizes, different mechanics usage of cloud providers, but also we have some questions specific to sub projects like cube admin cluster api. So if you are interested, please find the time to fill this survey. It will be very appreciated.

B

We have reached the end of the presentation. Thank you very much for your time and now we can have a q a session.