Kubernetes: What It Does and Doesn’t Do

Kubernetes has become a must-have tool for deploying cloud-native applications – especially those that run in containers or are deployed in distributed, microservices-based clusters. In these environments, Kubernetes solves some of the key orchestration and management challenges associated with deploying cloud-native applications at scale.

Yet, that doesn’t mean that Kubernetes solves every management challenge. There are a variety of critical areas of functionality that it doesn’t address.

Understanding what Kubernetes both does and does not do, then, is critical for using the tool appropriately as part of a modern application stack.

Key features

Kubernetes’s functionality can be broken down into several core categories:

• Container scheduling and deployment: It determines which servers (or nodes, as they are known in the Kubernetes world) within a cluster should host a given container. It then deploys them there automatically.
• Self-healing for failed containers: It automatically restarts containers when they fail. It also shuts down containers that have stopped responding.
• Load balancing: It manages network traffic both within a cluster and between clusters and the Internet to keep it properly balanced.
• Security: It provides a basic security framework in the form of pod security policies. This is by no means a full-fledged container security solution, but it allows admins to define some security rules to govern container behavior.

These core features automate many of the management tasks that teams need to handle when deploying container-based applications.

Kubernetes: Features not offered

On the other hand, there are lots of important areas of functionality that Kubernetes doesn’t handle on its own:

• Container image management: It doesn’t have any built-in tools for storing or managing container images. You need to connect it to a container registry to do that.
• Container image security: It also does not scan container images for potential vulnerabilities. You need to do that separately.
• Application storage: It can interface with a variety of external storage systems, but Kubernetes doesn’t set up or automatically integrate with persistent storage on its own. Admins need to deploy storage separately and connect Kubernetes to it.
• Infrastructure deployment: It itself doesn’t set up or provision the servers needed to build a cluster. The servers must exist before you can turn them into a Kubernetes cluster.
• Infrastructure scaling: Along similar lines, it generally doesn’t scale infrastructure up or down on its own. Kubernetes 1.8 and later do have a built-in autoscaler feature that can automatically add or remove nodes from a cluster based on demand, but it works only with certain public cloud environments.
• Fixing application bugs: Although it can automatically restart failed containers, that self-healing functionality doesn’t help much in situations where a container keeps failing due to a bug in the application itself. If you have a problem somewhere in your source code, Kubernetes is not going to fix that for you.

Conclusion: Kuberenetes makes life easier, but not painless

The bottom line is that, while Kubernetes automates much of the dirty work required to run complex, microservices-based applications, it leaves key tasks – including container image management, infrastructure management, and application quality control – up to developers and IT teams.

It’s hard to imagine deploying a modern application without Kubernetes, but it’s completely impossible to deploy an application with Kubernetes alone.