Slack Releases Bedrock Rollout Kubernetes Operator for StatefulSets
Slack has developed and released a Kubernetes operator as a means of managing the limitations that exist when wrangling with StatefulSet deployments.
To break down those terms, a Kubernetes operator is a code extension designed to look after tasks associated with deploying an application or service. Comprised of software controllers and custom resource identifiers, a Kubernetes operator automates and oversees the deployment and execution of workloads without the developer needing a granular knowledge of how any given piece of code works at the back end. An operator can perform automated actions from database deployment to backup.
As the Cloud Native Computing Foundation (CNCF) explains, “This [set of automation capabilities] is why operators are so powerful: They enable complex clusters and systems to operate automatically based on a set of patterns and principles. In short, operators are patterns that extend the behavior of the cluster without changing the Kubernetes code. Its APIs act as custom resource controllers.”
StatefulSet
Intrinsic to this story is StatefulSet, a workload API object used to manage stateful applications.
As Kubernetes.IO defines, “[StatefulSet] manages the deployment and scaling of a set of Pods and provides guarantees about the ordering and uniqueness of these Pods. Like a deployment, a StatefulSet manages Pods that are based on an identical container spec. Unlike a deployment, a StatefulSet maintains a sticky identity for each of its Pods. These pods are created from the same spec, but are not interchangeable: Each has a persistent identifier that it maintains across any rescheduling.”
Slack senior software engineer, cloud, Clément Labbe has detailed the Bedrock Rollout Operator, which is designed to provide a new level of control for developers using StatefulSet. Bedrock is Slack’s internal platform and is designed to give software engineers an “opinionated configuration” for Kubernetes deployments via a simple config interface alongside easy-to-use Slack integrations.
“Implementing custom rollout logic in a Kubernetes operator is not simple work, and incoming Kubernetes features like the maxUnavailable field for StatefulSet might, one day, let us pull out some of our custom code,” wrote Labbe, on the Slack engineering blog. “Managing rollouts in an operator is a model that we’re happy with, since the operator allows us to easily send Slack notifications for the state of rollouts as well as integrate with some of our other internal systems like Consul. Since this pattern has worked well for us, we aim to expand the use of the operator in the future.”
Labbe says that at Slack, engineers deploy their applications to Kubernetes by using internal Bedrock tooling as noted. As of now, Slack has in excess of 200 Kubernetes clusters, over 50 stateless services (deployments) and nearly 100 stateful services (StatefulSets). The operator is deployed to each cluster, which Labbe says allows the team to control who can deploy where.
Internal Control Factor
The end game here comes down to Slack engineers gaining an enhanced degree of control of StatefulSet deployments. Because this technology is built using Slack’s own Bedrock platform it enjoys a more precision-engineered fit in terms of integration and developer flexibility.
