How mature is your business when it comes to adopting Kubernetes? Steve Judd at Jetstack offers a guide for CTOs of enterprises adopting Kubernetes for software deployment, scaling and management

Kubernetes adoption continues apace and, despite the platform technology being less than a decade old, according to recent research the large majority of enterprises have either adopted it or are in the process of doing so.

These organisations already understand that to operate such a key component of their business requires a certain level of technical proficiency and maturity.

So, what can an organisation’s technical functions do to measure their existing maturity and identify where they should focus their efforts to increase it?

Maturity levels

Jetstack has been helping enterprises on their Kubernetes journey for over seven years and we have identified that this journey can be divided into five progressive stages, what we refer to as maturity levels. The higher the level an organisation has, the more confident they can be in their ability to successfully host business critical services and workloads in their Kubernetes environment. Determining the level that applies to an organisation can be achieved by evaluating how they perform within six key aspects: adoption, security, observability, cluster operations, developer experience and deployment process. The table below shows the relationship between levels and aspects:

Enterprises that are serious about capitalising on Kubernetes should be aiming for a maturity level of fundamental as a minimum and ideally repeatable.

For the full assessment experience we have a white paper that you can download and use to self-determine not only your company’s current level of Kubernetes maturity but the level you actually want to get to. For a taste of what is covered in the white paper read on.

What type of workloads are you confident about hosting on Kubernetes?

Understanding what types of workloads and applications your organisation is happy to host in your Kubernetes environment is a good maturity indicator. Recent adopters are likely to be hosting only low-risk, non-business critical applications, but to achieve at least a maturity level of fundamental you need to be comfortable hosting cloud native, distributed applications which have some business criticality; essentially applications that are designed from the outset to be optimised for Kubernetes hosting. To achieve a level of repeatable and beyond, the engineering teams should be confident in hosting any of their critical applications in Kubernetes clusters including those that were not designed with containerisation in mind.

What does your Kubernetes security posture look like?

The more critical your Kubernetes environment becomes to your organisation, the more you need to focus on a good security posture.

There are many aspects to consider: recent adopters should concentrate on the principle of least privilege for their clusters’ RBAC permissions for both users and workloads, and also secrets management (ensuring sensitive configuration can only be accessed by the appropriate workloads).

More mature and critical environments will want to adopt a broader principle of least privilege policy by implementing pod security admission, network policies, a service mesh and runtime image scanning.

Do you have a comprehensive observability strategy?

Kubernetes is designed to host large numbers of ephemeral workloads all of which produce vast amounts of telemetry data (logs, metrics, events, training etc). This data needs to be collected and stored in a central location so that it can be aggregated, analysed and visualised. For non-critical and low-impact clusters logging data (for troubleshooting) and basic health metrics will be sufficient but as more critical and distributed applications are introduced your observability solution will need to handle many more metrics and tracing data. Of course, collecting the data is only half the story – providing relevant and comprehensible visualisations (usually via dashboards) is equally as important.

How automated and consistent are your cluster operations?

Kubernetes is a comprehensive, complex and dynamic platform so there are always Day 2 activities to perform: cluster and add-on upgrades, backups, node pool management, cost optimisation and so on. We have found that a mistake engineering teams often make is to postpone putting automation, tooling and processes in place to reduce and de-risk this Day 2 toil. Typical consequences of this are that upgrades happen less frequently and the day to day standard operational work required just to keep the Kubernetes environment operational keeps growing (as usage and number of clusters increases). As an organisation’s Kubernetes maturity level increases so does its cluster management automation; leading to more frequent, less risky upgrades and greater consistency across clusters.

Do enterprises require much Kubernetes expertise to use your environment?

Enabling developers to be more productive and ship features faster is a fundamental promise of Kubernetes. However, requiring developers to have a deep understanding of its concepts and tooling is counter-productive and likely to provoke a revolt; thus, an organisation’s Kubernetes maturity also depends on ensuring this doesn’t become a requirement. Thoughtful investment in tools that reduce the cognitive burden will make adoption that much easier, for example, UIs that provide easy viewing of cluster components (think Lens and K9s), and developer focused build-test-deploy tools such as Skaffold, Garden and Tilt. Another worthwhile investment is an “Internal Developer Platform” to provide developer “golden paths” and self-service capabilities.

How do you deploy applications into your clusters?

Typically, when enterprises first adopt Kubernetes they deploy add-ons and applications using Helm Charts or raw-yaml manifests – this may be done manually or as part of a CI/CD pipeline but is still essentially an imperative approach to managing deployments in a cluster. As enterprises progress with their Kubernetes adoption – more applications hosted, a greater number of clusters – the deficiencies of this imperative approach become more apparent. Consistency and reliability of deployments and the ability to quickly identify what changes have been applied to clusters over time can only be realistically achieved by embracing a declarative, GitOps approach, where git is used as the source of truth for desired state.

Although the principles of GitOps are straightforward, applying them in practice is not, and will usually take noticeable time and effort to get right. Fortunately, there are many tools designed to facilitate the move to GitOps style deployments and also enable teams to incorporate sophisticated rollout approaches, such as: blue/green, canary, chaos engineering and configuration management.

As mentioned above, we have a whitepaper on this subject that will help you self-assess your own Kubernetes maturity level. Download the Jetstack Kubernetes Maturity whitepaper here for free.

Steve Judd is chief architect at Jetstack

More on Kubernetes

This is why Kubernetes is an in-demand skill – As more companies adopt Google’s open-source software management system, demand for talented individuals with Kubernetes skill is rising rapidly

DIY vs distro: what to pick for your Kubernetes environment – Here’s what organisations need to consider when it comes to deploying their Kubernetes environment

UK-based Kubernetes jobs to apply for this week – Kubernetes has become the key platform for moving workloads onto the cloud. Here are three Kubernetes jobs that you should know about