Weaveworks’ WKSctl Brings GitOps-based Fleet Management to Kubernetes – InApps Technology 2022

It seems that everything has an “Ops” these days, and GitOps is leading the next-gen BlankOps. If git is your single source of versioning and truth in your distributed system, then GitOps is the way you manage and deploy across a complex and heterogeneous environment.

To help facilitate a GitOps environment, Weaveworks has released WKSctl (Weaveworks Kubernetes System Control), an open source component in its GitOps suite. WKSctl looks to find that happy balance between automation and control for the Kubernetes-hybrid organization. And you can get it up and running with just IP addresses and SSH keys.

“You have a model of a system and then automated tools that make sure the system is in the desired state. The tools will detect if you’re not in a correct state, and it should fix the state itself or it should at least tell you,” said Weaveworks founder Alexis Richardson.

“Enterprises like to interfere with the running system, thinking they are making it more secure. But actually, by letting people touch the running system, they are making it less secure,” he said.

That’s why a GitOps approach is a cloud-native operating model that provides in-demand enterprise governance, including policy enforcement, deployment, management, monitoring, and reusability.

This is all in line with the industry pendulum swinging back from developer independence toward guardrails and best practice enforcement. And the tooling to back it all up.

WKSctl in GitOps Action, Cross-Cloud and Across Air Gaps

Weaveworks describes WKSctl as a command-line interface with backing services that use GitOps to configure and manage application clusters, policy like operational automation, and cross-cloud management of Kubernetes clusters.

WKSctl and the whole Weaveworks stack looks to apply GitOps to a single Kubernetes cluster and for fleet management. A fleet is usually a group of clusters with a common set of properties like app delivery clusters or database clusters. Each of these Kubernetes clusters shares similar security, audit and compliance requirements and can and usually should be treated in the same way.

Richardson says WKSctl meets the demand for a single installable tool that works with upstream Kubernetes, but that allows for that enterprise governance. WKSctl works for open source Kubernetes in the cloud or on your own computers, on bare metal, virtual machines and even in air-gapped environments.

This air gap application is particularly interesting in edge cases because it can allow you to manage clusters even while you aren’t connected to the Internet — like during a natural disaster.

Weaveworks Chief Technology Officer Cornelia Davis said, the way that companies have normally maintained operation while they are disconnected “is pretty bespoke.”

Describing this as a core tenant for WKSctl, she continued that, “Kubernetes has emerged as a kind of uniform layer that is applicable to air gap and edge, but it does require specific approaches to deal with sporadic connectivity.”

Davis says that WSKctl looks to make sure an enterprise deployment policy supports the disconnected, often heterogeneous nature of continuous delivery, out of the box.

Richardson explained that WSKctl is designed to essentially subscribe to a repository containing policies for how it’s configured, which add-ons you want — like Service Mesh for progressive delivery — and what operating system it’s going to run on.

“It’s not a homogeneous lump of distribution. It’s a composition of upstream distributions,” he said.

Patching versus Real Enterprise Security

“We think that it’s really important to make sure that when you are making critical changes to your cluster you are updating the model [in git]. That can be adding an app, updating a configuration — making an update to all things,” Richardson said.

Richardson said that “It’s not just patching security. In our architecture, we’ve separated all the installations and management machinery from the code itself. It’s clear when it’s upstream and you can mix it with more add-ons.”

Richardson was referring to WKSctl’s management delivery, including upgrades, patches and updates being achieved via a GitOps approach, which enforces the correct cluster state.

WKSctl then tracks the version, when appropriate changes that version in the model, and then the customer knows immediately when there’s been a new version upgrade. The reconciliation loop happening underneath the cover will automatically apply the upgrade.

Following the GitOps modus operandi, WKSctl looks to enforce governance without increasing risk — the fewer the people with access, the better.

Cluster and Fleet Management for Kubernetes

Davis says the git just makes it all more secure.

She said, “Every single thing is recorded. You can’t go back and change things in git. It’s a write-once audit log for a new generation of applications,” like decomposed microservices and Kubernetes.

Then using a tool like WKSctl as a part of managing a fleet of clusters allows you to uniformly apply these components for an organization that often has a heterogeneous blend of in-cloud, on-premise and even edge computing, bare metal and air-gapped environments.

Kubernetes fleet management helps answer essential questions at a glance, like: How do you know if you can shut down a cluster? How do you know if a cluster has had all security-related patches applied? When security patches do need to be applied, fleet management allows you to do so quickly and comprehensively.

Davis pointed to Zalando e-commerce site as one of the earliest companies to map out it components in this way. It was running about 100 different Kubernetes clusters across each microservice, with consistent policies applied, giving them a reasonable way of performing cluster upgrades, and addressing common vulnerabilities.

This is one way of limiting just how complex those complex systems can get.

He sees a future a la Clone Wars where you can take down and toss up properly configured  clusters at basically zero cost or effort. If it takes 40 seconds to start your phone, that’s how long spinning up most clusters should take soon.

Sure there will be hardened connections — like for storage and production — but, for the rest, Richardson says it’s gotta be that fast.

How to Run WKSctl

There are three ways to run and install WKSctl.

First, if you’re already a commercial customer of Weaveworks, you buy the GitOps platform and the company will manage it all for you.

You can also use Weave Firekube, where Weaveworks provides a tool called Weave Ignite that leverages Amazon’s micro-VM technology Firecracker to automatically provision the VMs. In combination with WKSctl then, Firekube bootstraps your git repository and provides Kubernetes cluster lifecycle management including infrastructure self-provisioning, out of the box.

But the most common and recommended way to leverage WKSctl is to pair a configuration with GitHub and GitOps. You need to provision your machines first, along with an SSH key that allows access. Then you send the list of machines and the SSH key to WKSctl.

WKSctl will convert your machines into the Kubernetes nodes that then form a Kubernetes cluster. WKSctl is a cluster API (CAPI) provider that only needs the SSH key and the IP addresses of your machines.

Weaveworks is not the only company embracing GitOps-styled Kubernetes management, Google has also released a GitOps-focused service for the Google Kubernetes Engine, called Application Manager.

Feature image by Jonathan Saleh on Unsplash.

InApps Technology is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Real.