Orchestrating Kubernetes Cluster Deployment with Kubespray and Progress Chef 360

Deploying Kubernetes consistently, repeatably and in a production-ready manner remains a challenge for many platform teams. While upstream tooling exists to address this complexity, operationalizing these tools within a controlled, auditable workflow is where most teams struggle.

In this blog, we demonstrate how the Progress Chef solution can be used to orchestrate a complete Kubernetes cluster deployment using Kubespray, turning a traditionally complex Ansible-based installation into a single, automated and repeatable execution workflow.

Why Kubespray?

Kubespray is the official Kubernetes deployment framework maintained by the Kubernetes SIG Cluster Lifecycle community. It uses Ansible to provision and manage Kubernetes clusters across cloud, virtualized and bare-metal environments.

Key capabilities include:

• Declarative Kubernetes cluster provisioning
• Support for multiple container runtimes and CNI plugins
• Node lifecycle management (add, remove, upgrade)
• Alignment with upstream Kubernetes best practices.

While Kubespray is extremely powerful, it is also complex to run operationally. It requires careful handling of inventory, SSH access, Python environments, configuration files and execution context, especially in automated environments.

The Operational Challenge:

Running Kubespray directly often raises several operational questions:

• How do we standardize execution across environments?
• How do we ensure the correct inventory, credentials and configurations are always used?
• How do we integrate Kubernetes provisioning into a broader automation workflow?
• How do we make execution observable and repeatable for teams?

This is where the Chef 360 platform fits in.

The Chef Solution

The Chef platform, specifically a capability called Courier, is designed to orchestrate operational workflows by chaining actions executed by different interpreters, such as Ansible, shell and Chef-client, into a single job.

Rather than replacing Kubespray, Courier acts as an orchestration layer around it, providing:

• Controlled execution from a central node
• Repeatable job definitions
• Clear execution status and outcomes
• Support for local or remote content sources
• Integration with existing automation assets

Scenario: Environment Overview:

In this setup:

• An Ansible control node hosts Kubespray and all other required dependencies
• Target Kubernetes nodes (control plane and worker) are accessed over SSH
• Chef triggers and manages execution from the control node<
• Kubespray performs the actual Kubernetes installation

Here, Courier does not modify Kubespray itself. Instead, it orchestrates how and when to execute Kubespray.

The Courier job initiates the Kubernetes installation that uses the Ansible interpreter.

With the Chef 360 platform (SaaS or on-premises), you can build your own Interpreters, and with Ansible, you have an option to select a source from S3, GitHub or from a local repository.

1. Prepares the execution environment
2. References the correct Kubespray inventory
3. Ensures consistent configuration and credentials
4. Invokes Kubespray’s cluster.yml playbook

This approach converts Kubespray’s multi-step execution into a single, repeatable Courier action.

From the user’s perspective, deploying a Kubernetes cluster becomes as simple as running a single job.

Note: You can use the Ansible interpreter to not just deploy a Kubernetes cluster, but also to execute any of the Ansible playbooks using Chef 360.

The Chef Execution Workflow:

At a high level, the workflow looks like this:

• A Courier job is initiated from the Chef 360 interface
• The job uses the Ansible interpreter to execute Kubespray from the control node
• Kubespray provisions the Kubernetes control plane and worker nodes
• Cluster services are installed, configured and started
• Courier captures execution status and results

Kubespray ships with multiple entry-point playbooks (cluster.yml, scale.yml, reset.yml). Instead of invoking these directly from Courier, a lightweight wrapper playbook is used to:

• Define execution paths explicitly
• Set environment variables (ANSIBLE_CONFIG, inventory paths)
• Standardize parameters such as user, SSH key and privilege escalation
• Make execution idempotent within Courier’s job model
• Help maintain consistent Kubespray behavior regardless of where or how the job is triggered

Once complete, the Kubernetes cluster is fully operational.

After deployment, the successful installation is verified by exposing a Kubernetes-hosted application and accessing it through a browser. This provides immediate, visual confirmation that:

• The cluster is running
• Networking is functional
• Workloads can be deployed and accessed

This step helps bridge the gap between infrastructure automation and real-world application readiness.

The Operational Benefits of Using the Chef Solution:

This approach provides several operational advantages:

• Repeatability: Kubernetes clusters can be deployed consistently using the same job definition.
• Observability: The execution state and results are visible within the Chef solution.
• Isolation: All the steps of the Kubespray execution is encapsulated within a controlled environment.
• Extensibility: Additional steps (validation, upgrades, teardown) can be added later to the existing job definition.
• Toolchain reuse: You do not require modification to upstream Kubespray.

Kubespray remains one of the most robust methods for deploying Kubernetes in production environments. When paired with the Chef platform, it becomes significantly easier to operationalize, transforming a complex Ansible-driven process into a clean, orchestrated workflow.

This approach demonstrates how existing open-source infrastructure tooling can be elevated with orchestration, making Kubernetes provisioning simpler, repeatable and more accessible for modern platform teams.