 Hello everybody, welcome to the introduction to SIG Cluster Lifecycle. My name is Justin Sanababra. 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. Lubomir and myself are going to be giving this presentation together, but we are representing the work of a great many people within the SIG. Hello, my name is Lubomir Ivanov. I'm a sequence lifecycle co-lead, software engineer at the VMware open-source program office, and my github handle is Neolit123. So here is what we are going to talk about today. We are going to explain what is SIG Cluster Lifecycle, what is the mission and philosophy of the special intense group. Also, we are going to cover the stack of sub-projects that we maintain. In particular, we are going to highlight three of them. These are Quaster API, Component Config and ImageBuilder. And finally, we are going to show you how you can get involved into contributing to the special intense group. What is SIG Cluster Lifecycle? In Kubernetes, we have special intense groups, also known as SIGs, and SIG Cluster Lifecycle is one of those. All the SIGs also have charter documents, and a charter document is something that defines what are the goals and non-goals of a particular group. SIG Cluster Lifecycle's objective is to simplify the creation, configuration, upgrade, downgrade and tear down of Kubernetes Quasters and their components. As a special intense group, you also have a vision to develop the tooling necessary to build a highly automated metacloud. A metacloud here means imagine something that is a Kubernetes cluster that can be deployed on any cloud provider. We want to avoid the pitfalls of the past because we had some unsuccessful experiments in the past. Everything should be declarative, API-driven, Cades-like deployment type of style, and managing these Quasters should be as easy as managing the Kubernetes objects like pods. That is a familiar button to everyone. 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. We also want to commoditize or standardize Cades-Quaster deployments. So if somebody is looking at your cluster, eventually they are going to know that, okay, this is following a standardized way, a standardized pattern for Quaster deployment. So on this slide we have a diagram of the current stack of tools that we are working on. At the bottom we have FEDCD-ADM. FEDCD-ADM is potentially a manager of FEDCD-Quasters, a CLI and a library that is working progress potentially consumable by high-level tools. On top we have CUBE-ADM. CUBE-ADM is a Quaster boost wrapper, as a lot of people should know already. A Quaster-ADM is a project where we are working on standardizing the way others are deployed in a cluster and they are managed as a life cycle. How do you upgrade them, how do you downgrade them? Quaster API, a lot of people should be familiar with Quaster API as well. This is a project where you can create Quasters using a declarative model. It's very similar to the Kubernetes declarative patterns. So if you combine these tools, you can potentially produce artifacts that you can then feed to an image builder. An image builder can create a virtual machine image for you, and the virtual machine image can then be fed to the Quaster Provisioner, which is a layer on top. The Quaster Provisioner can create you a Quaster that uses this virtual machine image. Finally, on the left we have the component config. The component 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. 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. Every computing infrastructure project that initially meets one's needs 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 software. On this slide you can see a Pseudo Voltron example. It's an immutable node update type of scenario. So on the left side we have a CI that triggers a rebuild of artifacts, notifies an operator to update costar manifests that are potentially consumed by the costar API. The costar API can then perform a rolling update, then a bootstrap provider, which in this case is QBADM to trigger the new nodes to join the costar. During KubeCon AU 2020 we created a survey to let our users get back to us with some feedback. The main takeaways are users are still struggling to keep up with the release cadence of Kubernetes. Currently there is a proposal to shift to three releases per year processing instead of four. This seems to be a very favorable option by all of the users. The upgrade process can be difficult due to core API changes and deprecations and removals. Basically, we saw a number of comments about this as direct responses in the survey itself. Ubuntu as an operating system for VMs, Docker as a container runtime using docker shim in this case, and Calico as a CNI appear to still be the most used projects in their respective areas. We also saw that projects like costar API and QBADM are gaining more traction and are getting positive feedback from the users, but there is still desire to improve the overall UX of these projects. In this section we would like to highlight some projects that we are currently working on. 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. 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. 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. But it's interesting in that cluster API still provides the ability to upgrade the cluster. 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, 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. 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 in cluster API. A machine like a pod is immutable. 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 and 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 mutability at the machine deployment level. 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. A machine class is a Kubernetes object that describes attributes of the machine that are specific to that cloud provider, 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. 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 a 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. 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. 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. 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 E2E tests using cluster API on GCP and on AWS. To learn more about the cluster API, you can join a deep-dive session we have about it here at KubeCon NA 2020. It's going to be presented by Cathy Gimangi and Carlos Panato on Friday, November the 20th. Another project that we wish to highlight is component config. Component 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. They use a lot of flags. And oftentimes, the flags across different components that do exactly the same thing have different names. The solution for that is that the core components 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 config. So adding a component config itself is not that easy. 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-based. And it's a toolkit. It's going to make it easier to write a new component that immediately implements a component config that uses Kate's API-style of configuration. And existing components should be retrofitted to use the same toolkit. Component config gives us a lot of benefits. It has maintainability. So when a component has a flag set that grows over 50 flags, configuration becomes painful. Upgradability. So for upgrades, versioned configuration is arguably easier to manage than flags, since flags are unversioned. Programmability. Configuration expressed as JSON in YAML objects are also consistent manipulation, templating, patching and introspection. And also possibility. Many types of configs simply cannot be expressed as key value pairs. 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 Kallström gave at a previous QubeCon. 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. In Kubernetes we have a working group that is called component standard. It's a combined effort between SQL Still Lifecycle and CKPI Machinery trying to tackle some of these problems around component config. To get engaged or find more about it, you can follow these links. Another project that we wish to highlight is ImageBuilder. ImageBuilder is essentially a tool for building virtual machine images not to be confused with container images. It includes Ansible and Packer scripts which are well supported by VMware, Microsoft and other companies for creating cluster API machine images. The current list of supported operating systems include Ubuntu, CentOS, Real7, Photon, Amazon, Linux and Flatcar support is coming soon. ImageBuilder is targeting VMware, AWS, Azure, QMU and Azure as providers of infrastructure. The project has also started working on a conformant test suite which uses GOSS which is a YAML-based server spec alternative tool for validating server's configuration. The repository of the project also includes some other tools such as CubeDeploy which is still used by cops for creating images for AWS. Config ADM which is a tool for generating cloud in it and cache for configuration of virtual machine images. Here are some of the goals of the ImageBuilder project. Provide a consistent tooling for all approaches for building images so that we can create more standardized, reusable and testable images. Make it easier for downstream consumers to customize their own images and keep their customization up to date. Testing of images to verify conformance using tools like InSpec and GOSS. Release of images for different cloud operating system combinations with regular updates. ImageBuilder is a fairly new project so we have a big roadmap for it. The COI still offers one of the goals is to get it to beta. PR testing for builds on AWS, GCP and QMO are planned. Azure is already running on PR submits. Flood card support and window support are also on the roadmap. Conformant testing and testing suites. Stress testing for long rotation and immutability. Submissions to the Kubernetes test grid which is the tool we use to monitor end-to-end tests. And finally image publishing, signing and release which is similar to a way the official Kubernetes containers are promoted today. To learn more about ImageBuilder you can see our deep dive session here at KubeCon NA 2020 is going to be on Thursday, November 2019 presented by Moshe Emerman and Tushar Agarwal. 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. KubeDM is some of the high-level provisioning cluster provisioning tools are, but otherwise the projects are in beta, in alpha or even pre-alpha. 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. Specifically we have some onboarding documentation which is a great place to start along with our community page. Many of the sub-projects are excellent at 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. There are a number of Zoom meetings, there's an overall SIG cluster lifecycle meeting bi-weekly and many of the sub-projects are owned by 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 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. We have reached the end of the presentation. Thank you very much for your time and now we can have a Q&A session.