What Does Kubernetes Cluster Automation Actually Cover?

According to the official Kubernetes documentation, cluster management automation spans cluster creation and initial configuration, master and worker node upgrades, routine maintenance, and eventual cluster deletion. It can also extend into day-two operations such as autoscaling, certificate rotation, and multi-cloud federation. Any tool you choose should be evaluated against those requirements for your specific environment.

1. Kops: Automated Cluster Lifecycle on Cloud Providers

Kops (Kubernetes Operations) is often described as “the easiest way to get a production-grade cluster up and running.” Unlike Kubeadm—which is better suited to manual, hands-on setups—Kops is built from the ground up with automation in mind. It handles the full cluster lifecycle: infrastructure provisioning, cluster creation and configuration, rolling updates, and cluster deletion.

Key capabilities of Kops include:

• Automated cluster creation, configuration, and deletion
• Support for cloud-native features such as Auto Scaling groups
• Rolling cluster updates with minimal disruption
• Heterogeneous clusters (mixed instance types)
• Public and private network topologies
• Single and multi-master configurations
• Ability to generate Terraform configurations for infrastructure-as-code workflows
• Support for multiple CNI networking providers including Calico, Weave Net, Canal, and Flannel

If you are already familiar with kubectl, the Kops CLI will feel relatively natural. Scaling nodes, upgrading the control plane, and destroying a cluster can all be scripted into CI/CD pipelines. The primary limitation is cloud support: as of the original publication of this article, Kops supported AWS, GCE, OpenStack, and VMware vSphere. AWS remains the best-supported target. Check the current Kops documentation for the latest supported platforms, as the project is actively maintained.

2. Kubespray: Ansible Playbooks for Flexible Cluster Provisioning

Kubespray takes a different approach by building on top of Ansible’s provisioning and idempotent deployment model. At its core, Kubespray is a curated set of Ansible playbooks that automate cluster creation, inventory management, and deployment planning. Additional playbooks handle cluster scaling, updates, and upgrades.

Kubespray strengths include:

• Highly customizable via Ansible variables and role overrides
• Supports on-premises bare metal as well as AWS, GCE, Azure, OpenStack, and Oracle Cloud Infrastructure
• Compatible with nearly all major Linux distributions
• Supports multiple CNI networking providers
• Allows the same cluster topology to be replicated across multiple datacenters, making it well-suited for hybrid environments
• Integrates with Terraform on most public clouds for infrastructure provisioning
• Includes a deployment verification tool called NetChecker

The main trade-off compared to Kops is that Kubespray does not self-provision or orchestrate cloud infrastructure natively—you typically pair it with Terraform for that layer. Some teams see this as added flexibility rather than a drawback, because it allows independent control over infrastructure and cluster configuration. If your team already uses Ansible extensively, Kubespray is a natural fit.

3. Conjure-up: Declarative Stack Automation with Canonical Juju

Conjure-up comes from Canonical, the company behind Ubuntu. It wraps Canonical’s Juju application modeling framework to let operators deploy complex software stacks—called “spells”—with minimal manual intervention.

The Juju model represents your entire infrastructure as a single entity, encompassing applications, storage volumes, and network spaces. Deployment logic lives in “charms,” which are collections of scripts and YAML files encoding everything needed to deploy, configure, resize, upgrade, and maintain a cluster. “Hooks” within charms define how the software responds to lifecycle events.

Conjure-up adds an orchestration layer on top of Juju:

• A conjurefile lets you predefine all stack requirements before deployment, enabling fully unattended installs
• Post-deployment steps can be scripted inside the conjurefile, removing the need for manual follow-up configuration
• A library of ready-made spells covers common Kubernetes deployment scenarios
• Native AWS integration is included

Conjure-up is best suited for teams already invested in the Ubuntu/Canonical ecosystem. Note that as of 2020, Conjure-up was in maintenance mode; verify its current status and community support before adopting it for a new project.

4. Kube-AWS: YAML-Driven Kubernetes on Amazon Web Services

Kube-AWS is a Kubernetes incubator project designed specifically for AWS customers who want fine-grained control over their clusters without sacrificing automation. Like Conjure-up’s conjurefile, Kube-AWS uses a single cluster.yaml file to define every aspect of the cluster before it is created.

Under the hood, Kube-AWS leverages a range of AWS-native services:

• CloudFormation for stack provisioning and lifecycle management
• EC2 for compute nodes
• KMS for secrets encryption
• S3 for asset storage
• Auto Scaling and Spot Fleet for cost-optimized node groups

Notable features include node-level customization through cloud-config and CloudFormation templates, the ability to reuse existing AWS resources such as VPCs, subnets, IAM roles, and security groups, and support for multi-AZ etcd clusters to ensure control-plane high availability across multiple AWS availability zones.

The obvious limitation is AWS lock-in. If your infrastructure spans multiple clouds or includes on-premises nodes, Kube-AWS is not the right fit. For AWS-only shops, however, its deep native integration can significantly simplify operations.

5. Ansible: End-to-End Automation Beyond Cluster Bootstrapping

While Kubespray uses Ansible under the hood, Ansible itself deserves consideration as a standalone automation platform for Kubernetes environments. Its scope extends far beyond initial cluster provisioning.

With Ansible, platform and infrastructure engineers can automate:

• Node provisioning and OS configuration across bare metal and cloud VMs
• Kubernetes installation and cluster bootstrapping
• Rolling upgrades of control-plane and worker nodes
• Application deployment and configuration management
• Certificate rotation and secret management workflows
• Any repetitive operational task that can be expressed as a sequence of steps

The key productivity advantage of Ansible is its human-readable YAML playbook syntax. Operators do not need to memorize the exact API calls or shell commands for a given task; they describe the desired state and Ansible figures out the execution. Community and vendor-published playbooks cover the most common Kubernetes operations, reducing the amount of custom automation code you need to write and maintain.

Ansible is typically paired with Terraform—Terraform handles immutable infrastructure provisioning (creating VMs, networks, and storage), while Ansible handles mutable configuration (installing software, applying policies, deploying applications). This combination gives you end-to-end automation from raw infrastructure to running workloads.

Choosing the Right Automation Approach

No single tool is the right choice for every team. Use the following questions to guide your evaluation:

• Cloud or on-premises? Kops and Kube-AWS are cloud-centric. Kubespray and Ansible support bare metal equally well.
• AWS-only or multi-cloud? Kube-AWS is AWS-only. Kubespray and Ansible are cloud-agnostic. Kops supports multiple providers but works best on AWS.
• Existing toolchain? If your team already uses Ansible and Terraform, Kubespray is a natural extension. If you are in the Canonical ecosystem, Conjure-up may reduce friction.
• Operational maturity? Managed Kubernetes services (EKS, GKE, AKS) handle much of the automation described here at the platform level and may be the right choice if your team is still building Kubernetes expertise.
• Scope of automation needed? If you need automation that spans the full development and operations lifecycle—not just cluster bootstrapping—Ansible’s breadth makes it a strong contender.

Kubernetes automation is not a destination but a practice. Start with the tool that best fits your current environment and expertise, instrument your automation pipelines well, and iterate as your operational requirements evolve.

The Growing Tension Between OpenStack and Kubernetes Communities

As Kubernetes has grown into the dominant container orchestration platform, open source contributors and enterprise IT organizations alike have been forced to make difficult choices about where to invest their time and infrastructure dollars. Two of the most prominent frameworks in cloud infrastructure — OpenStack and Kubernetes — have a relationship that is neither straightforwardly complementary nor directly competitive. It is, in a word, complicated.

Contributors to open source projects must decide where to prioritize their efforts, while IT organizations must determine to what degree they still need a framework like OpenStack to deploy and operate Kubernetes at scale.

How Kubernetes Has Typically Been Deployed

Historically, most Kubernetes deployments have run on top of virtual machine platforms — either open source hypervisors or commercial platforms such as VMware vSphere. Several practical factors drove this pattern:

• Workload isolation: Running Kubernetes clusters inside VMs provides a well-understood security and isolation boundary when multiple teams share the same physical infrastructure.
• Tooling familiarity: Many IT organizations lacked the skills to manage Kubernetes natively. Extending existing VM-centric tools to treat Kubernetes as another workload was operationally simpler.
• Risk management: Building on a proven virtualization layer reduced the perceived operational risk of adopting a new orchestration paradigm.

As a result, OpenStack — with its mature networking, storage, and compute APIs — became a natural substrate for Kubernetes clusters in many private cloud environments.

The Case for Moving Beyond OpenStack

The central question for 2020 and beyond was whether this approach would hold as organizations grew more comfortable with native Kubernetes tooling and lighter-weight alternatives emerged.

Rob Hirschfeld, CEO of RackN — a provider of an infrastructure automation platform built on open source Digital Rebar software — noted that lighter-weight alternatives to OpenStack and VMware for deploying Kubernetes clusters already existed at this time. The implication was clear: organizations willing to accept a learning curve could bypass the complexity of a full OpenStack deployment entirely.

Meanwhile, managed service providers such as Mirantis had begun rolling out highly distributed Kubernetes-based services that made no use of OpenStack whatsoever — signaling that the market was evolving past the assumption that OpenStack was a prerequisite for enterprise Kubernetes.

The OpenStack Foundation’s Perspective

Jonathan Bryce, executive director of the OpenStack Foundation (OSF), argued that OpenStack and Kubernetes would continue to evolve in a complementary fashion rather than as rivals. Organizations that had already invested heavily in OpenStack were unlikely to abandon that investment quickly — a reasonable assessment given the operational and organizational inertia involved in large infrastructure transitions.

Bryce also noted that the OpenStack community as a whole did not tend to be “super religious” about platforms like Kubernetes — acknowledging the pragmatic, ecosystem-aware stance the community had adopted.

OpenStack Projects Bridging the Gap

To remain relevant in a Kubernetes-dominated world, the OpenStack community had been developing tools designed to work alongside, rather than in opposition to, Kubernetes:

• Airship: A collection of open source tools for automating cloud infrastructure provisioning using a declarative, document-driven framework. Airship was designed to manage the full lifecycle of a cloud platform — including the underlying OpenStack services — in a Kubernetes-native way.
• Kata Containers: An open source container runtime that runs containers inside lightweight virtual machines. Kata Containers provided a middle ground between traditional KVM-based VMs and standard containers, offering stronger isolation than runC while remaining compatible with the Kubernetes CRI (Container Runtime Interface). This made it relevant to environments with strict security or multi-tenancy requirements.

Both projects reflected a broader strategy: rather than competing with Kubernetes directly, parts of the OpenStack ecosystem were repositioning to serve as infrastructure layers and security-focused complements to Kubernetes workloads.

Parallels with VMware’s Challenges

The OpenStack community was not alone in navigating these pressures. VMware faced a structurally similar challenge: its core value proposition was built around virtual machines, but the industry was shifting toward container-centric architectures where the VM was no longer the primary unit of deployment.

Both communities were grappling with the same fundamental question: in a world where Kubernetes is the de facto application platform, what role does the underlying virtualization layer play?

What the Future Deployment Landscape Looks Like

Rather than converging on a single deployment model, the likely outcome was a highly diverse ecosystem of Kubernetes deployments. Several patterns were expected to coexist:

• Kubernetes on traditional VMs (OpenStack or VMware): Legacy infrastructure investments and workload isolation requirements would keep this pattern alive for many years, particularly in regulated industries.
• Kubernetes on lightweight VMs: Projects like Kata Containers and firecracker-based microVMs offered stronger isolation than standard containers without the overhead of a full hypervisor stack.
• Kubernetes on bare metal: Greenfield cloud-native applications and performance-sensitive workloads would increasingly run on Kubernetes clusters deployed directly on physical servers, using tools like Digital Rebar, Metal3, or Cluster API providers.
• Managed Kubernetes services: Public cloud providers and managed service providers would continue to absorb complexity, allowing organizations to consume Kubernetes without managing the infrastructure layer at all.

Key Takeaways for Infrastructure and DevOps Teams

For DevOps and platform engineering teams evaluating their infrastructure strategy, the OpenStack-Kubernetes dynamic surfaces several practical considerations:

• If your organization has a mature OpenStack deployment, Kubernetes-on-OpenStack remains a viable path — particularly if workload isolation and multi-tenancy are hard requirements.
• If you are building a new private cloud from scratch, evaluate whether the full complexity of OpenStack is warranted, or whether a lighter-weight Kubernetes-centric stack (with tools like Cluster API, Rancher, or OpenShift) meets your needs.
• Projects like Kata Containers are worth tracking if you need container-level speed with VM-level isolation — especially in shared or regulated environments.
• Airship is relevant if you need declarative, GitOps-style lifecycle management of the full infrastructure stack beneath your Kubernetes clusters.
• Avoid assuming that managed Kubernetes services eliminate all infrastructure concerns — networking, storage, and security posture still require careful design regardless of the layer managing the control plane.

Conclusion

The relationship between OpenStack and Kubernetes is neither a clean handoff nor a zero-sum competition. It is an ongoing negotiation shaped by organizational inertia, workload requirements, tooling maturity, and community investment. The diversity of deployment patterns that was already visible in 2020 has only grown since. For most teams, the right answer depends less on ideology and more on a clear-eyed assessment of what they actually need from their infrastructure — and what operational cost they are willing to pay to get it.

Empowering Developer Innovation on Kubernetes

A recurring challenge with enterprise Kubernetes is the steep operational learning curve that can slow down application developers. OpenShift 4.2 addressed this directly by automating cluster setup and management tasks, allowing developers to focus on writing application code rather than managing Kubernetes infrastructure. The release also bundled a set of ready-to-use developer services covering the most common cloud-native concerns: service mesh, serverless compute, and CI/CD pipelines.

OpenShift Service Mesh

Red Hat OpenShift Service Mesh, based on the upstream Istio, Kiali, and Jaeger open source projects, became available in this release. Delivered and managed via Kubernetes Operators, it is designed to simplify the development, deployment, and observability of microservices-based applications running on OpenShift. Istio handles traffic management and mutual TLS, Kiali provides a visual topology of the mesh, and Jaeger enables distributed tracing across services.

OpenShift Serverless (Technology Preview)

Built on the Knative project, OpenShift Serverless was introduced as a Technology Preview in 4.2. It allows workloads to scale down to zero replicas when idle and scale up on demand in response to incoming requests. This model can reduce infrastructure costs for workloads with variable or unpredictable traffic patterns while keeping applications responsive.

OpenShift Pipelines (Developer Preview)

OpenShift Pipelines, available as a Developer Preview and delivered as a Kubernetes Operator, brought a cloud-native CI/CD approach based on the Tekton project. Each step of a pipeline runs in its own isolated container, which means individual steps can be versioned, reused, and scaled independently. This is a meaningful architectural difference from traditional CI/CD systems that run pipeline steps in a shared agent environment.

Local Development with Red Hat CodeReady Containers

One of the most developer-facing additions in OpenShift 4.2 was Red Hat CodeReady Containers (CRC). CRC lets developers install a minimal, pre-configured OpenShift cluster on a local laptop or workstation. This provides a self-contained environment that mirrors a full OpenShift cluster closely enough to develop and test cloud-native applications locally before deploying to a production cluster.

Previously, iterating on OpenShift-specific features—such as Operator-managed services or OpenShift-specific build configurations—required access to a remote cluster. CodeReady Containers lowered that barrier significantly by bringing the cluster to the developer’s machine.

Hybrid Cloud Consistency and Simplified Operations

Beyond developer tooling, OpenShift 4.2 included several platform-level improvements aimed at consistent operations across cloud and on-premises environments.

• Multi-cloud installation: Simplified, automated installation across major public cloud providers including AWS, Microsoft Azure, and Google Cloud Platform (GCP), as well as private clouds based on Red Hat OpenStack Platform, with a consistent enterprise experience across all targets.
• OpenShift 3 to 4 migration tooling: Red Hat introduced migration tooling to help existing OpenShift 3 customers move workloads to OpenShift 4 clusters. The tooling was designed to automate copying workloads between clusters, reducing the manual effort involved in a major platform upgrade.
• Container Storage Interface (CSI) drivers: OpenShift 4.2 added CSI driver support, giving third-party storage vendors a standardized way to integrate with the Kubernetes storage ecosystem. The release also included support for OpenShift Container Storage 4, which was in beta at the time of this announcement.

Summary

OpenShift 4.2 marked a deliberate shift toward making enterprise Kubernetes more accessible to application developers, not just platform operators. The combination of CodeReady Containers for local development, Operator-delivered services for service mesh, serverless, and pipelines, and cross-cloud installation automation reflected Red Hat’s strategy of reducing the gap between developer intent and production Kubernetes deployments. Organisations still running OpenShift 3 at the time of this release had a clear migration path to evaluate.

This article is based on Red Hat’s October 2019 announcement of OpenShift 4.2. Feature availability statuses (GA, Technology Preview, Developer Preview) reflect the state at the time of that release and will have changed in subsequent versions.