OpenStack and Kubernetes: give each layer a clear job

Two platforms, different questions

OpenStack and Kubernetes are often discussed as competing choices. For an infrastructure team, the more useful question is what each platform should own. A virtual machine and a containerized application have different lifecycles, even when they share the same physical hardware.

OpenStack provides infrastructure services such as compute, networking and block storage. Kubernetes manages containerized workloads on nodes. Those nodes can be virtual machines or physical machines. A Kubernetes cluster running on OpenStack is one possible arrangement, not a requirement for either platform. See the OpenStack installation guide and Kubernetes components.

This distinction is especially useful when an environment must support several kinds of work: long-lived virtual machines, containerized services and workloads with particular storage or networking needs. Start with those requirements before deciding which platform should host everything.

Draw the ownership boundary

For a combined deployment, write down who owns the VM image, node replacement, persistent storage, cluster upgrades and application rollout. A diagram is helpful only when it also explains who responds when a dependency fails.

Consider a node that stops responding. Replacing its virtual machine may restore compute capacity, but it does not prove the application recovered. Check what happened to workload scheduling, attached storage and traffic. Define recovery as a user-visible result, such as a successful request, rather than a green infrastructure indicator.

Follow the dependencies

Before adding a workload, trace how it reaches storage and how a user reaches it. Record the relevant network boundaries and the storage interface the application actually uses. “We have a storage cluster” is not enough information to explain volume attachment, access permissions or recovery expectations.

For each important service, ask three questions: what happens when one node disappears, what happens when storage is slow, and what happens when the control plane is unavailable? The answers need a small, controlled exercise and a written observation. They should not depend on an assumption that another team has already tested them.

Prove one complete path first

A useful first milestone is one application deployed, reachable and observable, with a documented recovery path. Add more capacity after that path is understood. This keeps the first troubleshooting exercise small enough to explain.

• Record the workload requirements and the responsible team.
• Verify deployment, access and persistent data separately.
• Exercise a node replacement in a lab or agreed test environment.
• Write down what recovered automatically and what required intervention.

The value of combining platforms is flexibility. The operational cost is another set of dependencies. Make those dependencies visible before they become an incident.