Taken by itself, Kubernetes delivers a lot of value to IT organizations. It elevates containers from something mostly of interest to individual developers to something that can be deployed at scale in production environments. A 2019 Cloud Native Computing Foundation (CNCF) survey found that production Kubernetes use in the cloud-native community increased from 58 percent in 2018 to 78 percent in 2019. A great deal of this value came from the work of the individuals and organizations participating in the Kubernetes community.

However, it also reflects the work of the individuals and organizations creating complementary open source tools that work together with Kubernetes to make it even more powerful. I’ve previously written about some of the more widely used projects that improve Kubernetes. Here, I’m going to highlight some others that you’re perhaps less likely to have heard of. They may be newer, less mature, or primarily of interest to a subset of developers and operators.

[ Get the free O’Reilly eBooks: Kubernetes Operators: Automating the Container Orchestration Platform and Kubernetes patterns for designing cloud-native apps ]

Let’s delve in and see what these might do for your organization:

1. Quarkus

Java, one of the most popular programming languages, was born in the mid-1990s. Over the course of nearly 20 years, it primarily optimized for running dynamic monolithic applications that assumed sole ownership of (virtualized) host CPU and memory (in spite of earlier Service Oriented Architecture (SOA) approaches. An entire application server market grew out of supporting enterprise applications written in this vein.

However, while large monolithic apps are still around (and “majestic monoliths” can sometimes still be the best approach), we’re moving to a world that at least tends to favor microservices, reactive, Function-as-a-Service (FaaS), 12-factor, and  cloud-native applications for reasons of productivity, flexibility, and efficiency. This requires a rethink of how Java can best be used in such an environment.

Enter Quarkus. Quarkus is a Kubernetes-native Java framework tailored for GraalVM and HotSpot. The goal of Quarkus is to make Java a leading platform in Kubernetes and serverless environments while offering developers a unified reactive and imperative programming model to optimally address a wider range of distributed application architectures. It starts up in tens of milliseconds for rapid scaling up and down, has low memory utilization, and a reduced application and container image footprint.

[ How does Quarkus fit with OpenShift to simplify development? Read also: Introducing Quarkus on Red Hat OpenShift. ]

2. OpenTelemetry

One of the hot topics at the most recent Kubecon was observability, as noted by EMA analyst Torsten Volk. The term can cover a lot of ground but a typical definition spans metrics, tracing, and logging. Two of the big projects in this space are Prometheus, a systems monitoring and alerting toolkit built on a time series data model, and Jaeger, a distributed tracing tool. Monitoring is also important but is usually considered to be distinct from observability.

A recent entry in this space is OpenTelemetry, formed by the merger of Google’s OpenCensus and Lightstep’s OpenTracing in 2019. (Lightstep CEO Ben Seligman sat down with me at an earlier Kubecon to talk about a wide range of issues including the key challenges of distributed systems and the sometimes confusing monitoring/logging/tracing/etc. landscape.)

One of the things that makes OpenTelemetry interesting, in addition to the project itself, is that it represents at least a small degree of unification in the distributed system observability space. In fact, there are a lot of open source projects in the vast CNCF landscape that overlap to some degree, that complement each other to some degree, that can sometimes be integrated with each other, and sometimes can’t be. It will be interesting to see if a broader pattern of related projects coming together emerges.

3. Argo CD and Keptn

Projects in the CI/CD space are rethinking build and deployment pipelines in the context of Kubernetes-native development patterns and processes. For example, Tekton Pipelines run on Kubernetes, have Kubernetes clusters as a first-class type, and use containers (and pods) as their building blocks. An offshoot of the popular Jenkins build tool, Jenkins X, likewise is aimed at a cloud-native development world.

While Tekton can handle the full CI/CD pipeline, some newer projects aim to increase the flexibility and capability of the deployment pipeline specifically.

By itself, Tekton effectively pushes a deployment to one or more Kubernetes clusters. If there’s a failure, Tekton has to either re-push the deploy everywhere or an operator needs to manually push just any deployments that failed. Argo CD, by contrast, is a declarative GitOps tool. It makes sure the correct deployed state is reflected in the live clusters, continuously monitors them, and takes any actions needed to bring the desired state and the actual state into alignment.

Keptn is another project that can use either Argo CD’s deployment capabilities on its own; but it’s most focused on additional testing, evaluation, and promotion for the code being placed into production.

[ Kubernetes terminology, demystified: Get our Kubernetes glossary cheat sheet for IT and business leaders. ]

4. Envoy and Contour

I’ve already touched on the observability challenges associated with distributed applications based on microservices. There’s also the matter of handling the traffic between the microservices both within the cluster and between the cluster and the outside world.

The data transfers, i.e. the “data plane” in Kubernetes, has largely standardized around Envoy. Envoy runs alongside every application and abstracts the network by providing common features in a platform-agnostic way.

A service mesh like Istio can build on top of Envoy to provide security, traffic direction, and insight within the cluster (east-west traffic) and between the cluster and the outside world (north-south traffic). Service meshes can be a valuable tool to operate large-scale microservices-based applications. They’re also complex and can be overkill. A project like Contour focuses on north-south traffic only; it makes Envoy available to Kubernetes users as a simple, reliable load balancing solution.

5. OKD 4, Fedora CoreOS, and CodeReady Containers

If you’re looking for a community distribution of Kubernetes that adds developer and operations tooling, take a look at OKD. You can think of it as the “upstream” project to the Red Hat OpenShift product. But it’s really more of a sibling relationship with the introduction of the Universal Base Image, which allows updated code to flow into the project and product in parallel.

[ Read also: OpenShift and Kubernetes: What’s the difference? ]

OKD 4 uses Fedora CoreOS as a base operating system for the nodes. Fedora CoreOS is an automatically-updating, minimal operating system for running containerized workloads securely. OKD 4 gives you a Kubernetes cluster with the latest security fixes and new features like cgroups v2 support; it also supports Kubernetes Operators as first class citizens. (Whereas Kubernetes can make sure an application comes up and has the right storage and networking, Operators allow you to automate all the administrative tasks that might be required on either day one deployment or day two ongoing operations.)

[ Read also: How to explain Kubernetes Operators in plain English and Kubernetes Operators: 4 facts to know. ]

OKD also supports an installer-provisioned infrastructure, where the installer controls all areas of the installation process, on many platforms. While not as flexible as user-provisioned infrastructure, it’s much simpler to use and should generally be considered the default for most users.

Finally, to help out developers before they’re ready to push code to a CI/CD pipeline, OKD 4 lets you set up a minimal pre-configured local Kubernetes cluster on your laptop or desktop with CodeReady Containers for development and testing purposes. They’re the quickest way to get started building OKD (or OpenShift) clusters.

More to come from the Kubernetes community

If you take a look at the almost comically large CNCF landscape, it will probably be instantly obvious that I’ve barely scratched the surface of the community innovation that’s orbiting Kubernetes. But I still think that what I’ve highlighted should give you a sense for projects and areas that you should keep your eye on or get your hands dirty with, in the new year.

[ Kubernetes 101: An introduction to containers, Kubernetes and OpenShift: Watch the on-demand webinar.]