Enterprise Ready GitOps with the Weave Kubernetes Platform
Weaveworkers Mark Ramm (@markramm), Director of Product Management and Mark Emeis (@MarkEmeis), Engineering Manager walk you through the history of the product, how it works and what cluster platform creation and team management looks like in WKP. Learn how to create repeatable, auditable clusters managed with WKP and GitOps.
Have you heard about the Weave Kubernetes Platform and are curious about how WKP really works? Read the transcript from a recent video by the folks from VM Blog shot at the Weaveworks’ booth during Kubecon US held in San Diego.
Weaveworkers Mark Ramm (@markramm), Director of Product Management and Mark Emeis (@MarkEmeis), Engineering Manager walk you through the history of the product, how it works and what cluster platform creation and team management looks like in WKP. Learn how to create repeatable, auditable clusters managed with WKP and GitOps.
Mark Ramm: Weaveworks founder, Alexis Richardson, coined the term GitOps to talk about storing a model of what you want to deploy in Git. With the state or model kept in git, you can then automate updates and deployments to a running cluster, effectively creating a reconciliation loop. In this way, you can always see what is deployed in production since it should match the model kept in Git. We then developed a set of tooling around that concept in the Kubernetes and cloud native ecosystem. Flux is a GitOps tool we used internally to manage our own clusters and our own SaaS product. Later this was expanded on and it became a complete set of tools used to build the Weave Kubernetes Platform.
Brian: And speaking of Kubernetes, how do you fit into the ecosystem? What specific problems does Weaveworks aim to solve?
Mark Ramm: Explicitly outside of the scope of Kubernetes is an operations model. How do you operate software over the entire life cycle of the cluster? We think GitOps is the operations model that Kubernetes lacks. We've built a number of tools to help people automate application deployments to Kubernetes as well as manage Kubernetes clusters via GitOps. This provides a continuous understanding of what is going on in the cluster with easy to use tools that developers and operators are already comfortable with and use every day.
Brian: And would it be possible for us to maybe take a look at the product or get a demo?
Mark Emeis: Here is a view of the management dashboard where you can see all of the clusters that have been created in the Weave Kubernetes Platform. The foundational principle of WKP is that it is all GitOps driven. From the management UI, you can see all of the clusters with their definitions and configurations stored and versioned in Git. What I'm going to show you is some of the functionality that WKP provides to manage these clusters.
Mark Emeis: Creating a new cluster in WKP is done through the create cluster button. From there, you can choose what model to use. I'll talk more about models in just a second. Next choose the provider: Amazon EKS, Microsoft Azure or on-premise, a region and a version of Kubernetes, and that’s it.
I mentioned models. Instead of letting your different business units or individual teams stamp out snowflake clusters everytime they need a specific app or configuration, we want you to be able to spin up clusters with a well-defined pattern. You can choose one of the pre-configured models or you can create your own models with a specific set of add-ons. Now, when any of your teams need a cluster, those pre-configured apps, components and add-ons will be that the correct items needed for a specific Kubernetes cluster.
Mark Emeis: Models allow you to avoid snowflake clusters, and instead provides you with a way to ‘stamp out clusters’ that are known and that can be easily managed. With a model cluster available from the UI, I can now scale this particular WKP cluster straight from the UI and version my change in Git.
Since GitOps is fundamental to the system, I'm going to show you what happens underneath the covers when you autoscale with WKP.
This is the dashboard for the management cluster itself. You'll notice here that we have a link that opens the cluster’s Git repo. Let’s take a look at the commit with the change made in the UI that scaled your cluster scale definition from 3 nodes all the way down to 2.
Mark Emeis: The key takeaways for WKP are repeatable, auditable clusters that you can manage with GitOps. In addition to being a cluster manager, WKP can also configure individual clusters as well as the ability to create team workspaces.
I'm going to demonstrate what a team workspace looks like and how it works. Here is a view onto a cluster that I launched previously from WKP. On the right hand side, we have a set of team workspaces defined. But before I describe those, I wanted to show you the preconfigured cluster components. This set of components are ones that we've curated and made to work together and that get installed onto each of the clusters with WKP. Right away you get applications and cluster components and add-ons like Prometheus, Grafana, Flagger, Tiller, ingress, Flux and the web UI.
Mark Emeis: These are the cluster components that we think are the right set, but since they are all stored in Git, you also have the ability to manipulate which components you need to install onto your clusters. And the models that I talked about earlier feed into that as well. For example, if you had a team that came to you and said, we have an application and we want to use GitOps and we need to run it inside of Kubernetes. What you can do for that team is create a workspace for them along with the cluster.
A workspace is connected to your GitHub organization and it creates repo for the team’s cluster. Again since everything is run with GitOps and backed by Git, we can define the workspace for a team that needs a repo so that they can deploy their microservices to a Kubernetes cluster.
Mark Emeis: If we take a look at the Bravo workspace, you'll see that a Git repo was created in Git. The Bravo team is also matched up with a namespace inside of the cluster. With a workspace created, you can hand this over to the team and tell them to commit all of their manifests in here. When they commit YAML files or Helm charts and the new commit is pushed to the repo, it automatically gets deployed to the namespace on that cluster, making it unnecessary to set up a separate Continuous Deployment process. With WKP you essentially get GitOps straight out of the box.
Watch the entire video here:
Just starting out with Kubernetes?
Excited about the opportunity of cloud native and GitOps but not sure how to navigate your organization to the path to success? Whether you’re using Kubernetes in the cloud or behind the firewall your team needs battle-tested architectures, workflows and skills to operate Kubernetes reliably. Our QuickStart program is a comprehensive package to design, build and operate Kubernetes in production using the GitOps methodology. Contact us for information.
