Cloud Native Computing Foundation KubeCon + CloudNativeCon North America 2021, 29 Oct 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Keynote: Breaking Tradition: The Future of Package Management with Kubernetes - Shatarupa Nandi

Description

Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. 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.

Keynote: Breaking Tradition: The Future of Package Management with Kubernetes - Shatarupa Nandi, Engineering Director @ VMware Tanzu, VMware

A

I work on packaging and deployment tools at vmware tanzu and when I'm not passionately debating about packaging abstractions with my team, I enjoy gardening.

A

I love rose bushes, but rose bushes have thorns, and that is what kubernetes package management is today. It gets us started, but we often prick ourselves. What are these thorns? Well today I have to install and update my packages manually without being able to use standard kubernetes apis, managing multiple packages or packages that have dependencies makes this process even more tedious and error prone.

A

Another challenge is, I don't have a single artifact that I can easily inspect to get a bill of materials of everything that will be installed on my cluster overall, I don't have confidence that I know exactly what is running on my cluster and can recreate it anywhere, including in an air gap environment.

A

Now we all value the declarative, apis and layered approach that kubernetes provides. Why not bring that same goodness to package management on kubernetes. Similarly, we as the community are embracing standard oci registry apis. What if we could leverage oci concepts like immutable digests to provide guarantees on what exact bits are running on a cluster?

A

Let's keep the beautiful roses and evolve it to be thornless.

A

We have learned that app operators, cluster operators, developers and package authors all benefit from different abstractions with carvo. We want users to take advantage of the part of the stack they need. Users don't have to take on the complexity introduced by additional layers, and they can easily move up and down the stack when they need to to enable this. We use app as a lowest level abstraction similar to a pod and just like deployment builds on top of pod. A package and packet installed build on top of app a package.

A

Repository builds on top of packages to look at how each of these abstractions actually look like. Let's start with a simple application, it is made up of a service and a deployment I'm going to use an app cr to deploy this app and fcr represents a group of kubernetes resources.

A

I can use it to specify how to fetch, template and deploy my app and for each of these steps, I can specify what tool I want to use to accomplish it, I'm using a git ref here as my source for fetching, because I want to keep my app up to date with changes to the git repo, but fetch actually supports a variety of different sources, including config map, which can be helpful for local development or an oci image.

A

Similarly, for template, we support using ytt and home we'd love to integrate more tools with your involvement and help in the project. We want to make carbo really easy to use an extent, so you can take it and run with it. Now. Let's deploy this app, the deploy succeeded and here's my app now I want to expose my app to the outside world. I want to use contours http proxy. To do that, I would like to consume contour as a package that someone else has authored.

A

This is where a package repository is helpful. You can think of a package repo as a maven, repo or rpm repo. It holds a collection of packages that are available to install on your cluster after adding the package. Repo to my cluster here are all the packages that are now available to install.

A

I know my app works with version 117.1 of contour, so let's go ahead and install that looking at the contour package, we see that a package contains configuration metadata and oci images that tell the package manager how to install itself similar to an app cr package. Authors can use different tools for fetching templating and deploying you'll notice. Here we fetch using an immutable image reference a digest.

A

This means when you install this package, you're always going to get exactly the same bits now to install this package, I'm going to create a package installed, referencing it when I'm conceiving a package authored by someone else. I don't know the details of how that software is fetched, templated and deployed with a layered approach. We can encapsulate those details away from the consumer providing a simpler api while still leveraging the same app cr deploy mechanisms when interacting with the kubernetes api to deploy the package after my package install succeeds.

A

I have contour running, I can now add http proxy, provided by contour to my simple app checking those changes into my git repo, and since I have my app cr watching on changes to my git repo, it will create a http proxy. For me.

A

I am now set up for continuous updates and I have confidence in what's running on my cluster, I can drive updates to my app with changes to the git repo. I can make changes to either my app or the contour package using standard kubernetes objects. I know what's running on my clusters locked down to the contents of an immutable bundle, and I can pick up my configuration and recreate the same state on any kubernetes cluster, including in an air-gapped environment.

A

We just saw what a package manager that is compatible with github's ideas can unlock, and yet there is so much more. I want to share with you. We have an opportunity to build something, really cool and useful with carvo. Please come join us by trying out the tools. We are very active on kubernetes slack and would love to keep in touch with you there. Thank you and have fun at kukon.