CD on Kubernetes

#talks

Abstract

Kubernetes has become a hot topic in the computing space. There's been lots of talk about spinning up clusters, developer tooling, and monitoring. Applications from large to small are now taking advantage of the ecosystem.

One thing that hasn't changed is how we deliver software to production. Development and operations teams hold their continuous delivery (CD) software close to their chest. It's hard to find good software, harder to get it dialed in for one project, and sometimes an epic effort to get it working across an organization.

With Kubernetes, a platform for platforms, you get all the raw building blocks for creating a delivery platform right out of the box. This talk will walk through the steps for designing a delivery system out of Kubernetes components. We'll start with extracting the problem, and move to identifying the components of the build system. Next, the audience members will be introduced to all the parts of this hypothetical delivery system, and they will leave the talk with ideas of how to employ the process in their organizations and opportunities for extension.

This talk is an introduction to building applications with Kubernetes instead of on Kubernetes. This content will serve as an introduction to Custom Resources, controllers, and RBAC. It will combine that base with a practical example of moving software to production in an automated fashion.

Talk Content

1. We’ve come to grips with deploying objects to Kubernetes
2. As we’ve become more comfortable, our deployments have become more complex.
3. Unfortunately, in many cases, we’ve been building on top Kubernetes of Kubernetes instead of on Kubernetes
4. Kubernetes is a platform for platforms
5. Kubernetes API Machinery is robust.
6. Custom Resource Definition
   1. Talk about declarative management
7. Custom controller for a CRD
8. Introduce Kubebuilder
9. Show snippets of code for creating something simple in Kubebuilder
10. How can we reimagine CD on Kubernetes instead of on top of Kubernetes?
    1. First, what's CD?
    2. Tools abstract away the important details, but CD is all about the pipeline
    3. A pipeline is triggered by some event. eg. a new image is available, someone on slack wanted, or maybe manually initiated
    4. The pipeline is a series of steps that are ran in order
    5. A step can potentially have multiple actions
    6. If a step fails, we need a way to alert the user
    7. Finally, when a pipeline is done, it needs to be able to show its status
    8. Kubernetes has all these capabilities built in
11. Thinking about the pipeline
    1. Before, I introduced CRDs. We can describe a pipeline in a crd
    2. The pipeline is just another object to kubernetes. We can even use kubectl to manage it
    3. Having to create a new pipeline each time so we'll create an PipelineJob which refers to our pipeline
    4. Now once this is created, nothing will happen. This isn't surprising because with Kubernetes, you need a controller to watch resources and perform actions based on their life cycle
12. We haven't fully thought through the problem yet. It wouldn't be trivial to create a workflow engine, so instead, we'll use Argo.
    1. Show quick argo demo
13. I've skipped over an important detail. Our pipelines have steps.
    1. The pipelines have steps. What exactly is a step?
    2. Here's the neat part, they can be whatever you wish. A pipeline steps will be composed on containers.
    3. This idea isn't as crazy as it sounds. Even Google's container builder uses containers in its steps
14. How would you go about putting this all together?
15. Pipelines and PipelineJobs are Kubernetes resources, doesn't this put extra load on our Kubernetes cluster?
    1. Yes, it does. I'm still looking for the right math, but the KUbernetes documentation says we should should be able to handle thousands of objects.
    2. What happens when you outgrow this?
    3. Introduce api aggregation
16. Now, I've showed you an example CD process.
    1. This was chosen because people understand CD at a high level.
    2. These techniques can employed in other ways as well.
    3. Seeing as Kubernetes is a platform for platforms, you can base your APIs on KUbernetes and let it do the heavy lifting for you.
    4. Suggest some other ideas
17. You've painted this as a magical way forward, what are the caveats?
    1. I've only talked about single cluster. Some of these ideas won't scale to multiple clusters without some additional work
18. What's next?
    1. We need to explore using Kubernetes as a platform instead of a simple deployment target
    2. Our tooling needs more people consuming and building