Bring your own Kubernetes (BYOK) system requirements
Use this page to confirm that your Kubernetes environment meets the requirements for a Chef 360 Platform bring your own Kubernetes (BYOK) deployment.
Overview
A BYOK deployment installs Chef 360 Platform into a Kubernetes environment that you manage. Unlike the bundled deployment model, Chef 360 Platform doesn’t provision, manage, or operate the Kubernetes cluster. You’re responsible for providing and maintaining a supported Kubernetes environment, networking, storage, security controls, and operational processes.
Chef 360 Platform runs as a collection of Kubernetes workloads and integrates with standard Kubernetes APIs, storage classes, ingress controllers, and container registries.
Before you begin
Use this checklist to confirm that your environment is ready for a BYOK installation:
- Confirm that your Kubernetes platform and version are supported.
- Choose a deployment topology and confirm that your cluster has enough allocatable CPU, memory, and disk capacity.
- Confirm that your deployment identity has the required Kubernetes access.
- Confirm that all worker nodes are
Readyand that a default StorageClass is available. - Configure the required ports and a DNS-registered, RFC 1123-compliant FQDN.
- Choose a standard installation or an air-gapped installation and complete its network requirements.
Requirements at a glance
Before you choose an installation path, confirm that your environment meets these requirements:
| Area | What to confirm |
|---|---|
| Kubernetes platform | Your cluster runs a supported Kubernetes distribution and version. |
| Cluster access | Your deployment identity can use kubectl, create namespaces and CRDs, manage Helm releases, and access StorageClasses. |
| Cluster health | Worker nodes report Ready, control plane components are running, and a default StorageClass is available. |
| Capacity | Your selected topology has enough allocatable CPU, memory, and disk, plus capacity for Kubernetes and recovery overhead. |
| Network | Required ports, DNS, ingress, registry, and outbound endpoints are configured for your network model. |
| Operations | Your organization owns cluster lifecycle, security, monitoring, backup, and recovery. |
Use the detailed sections below to verify each area before installation.
Shared responsibility model
Customer responsibilities
You’re responsible for:
- Kubernetes cluster deployment and lifecycle management
- Worker node provisioning and replacement
- Cluster networking
- Load balancers and ingress configuration
- Persistent storage infrastructure
- Backup of Kubernetes infrastructure components
- Container registry access
- Cluster security, RBAC, and compliance controls
- Monitoring and alerting for Kubernetes infrastructure
Chef 360 Platform responsibilities
Chef 360 Platform provides:
- Platform services deployed into Kubernetes
- Application upgrades
- Platform functionality
- Integration with supported Kubernetes services
Supported Kubernetes platforms
Chef 360 Platform runs on the following tested and verified Kubernetes distributions:
| Platform | Support status |
|---|---|
| Amazon Elastic Kubernetes Service (EKS) | Supported |
| Azure Kubernetes Service (AKS) | Supported |
| Red Hat OpenShift | 4.10 or later |
| Generic Kubernetes distributions | Kubernetes 1.29 or later |
Kubernetes access requirements
Before you deploy, work with your Kubernetes administration team to confirm that your deployment identity can:
- Connect to the target cluster with
kubectl. - Read nodes, pods, events, and StorageClasses across the cluster.
- Create or update the StorageClass configuration required by your deployment.
- Label worker nodes for a Tiered-HA or Hyperscale HA deployment.
- Create namespaces and install Custom Resource Definitions (CRDs).
- Install and manage the Chef 360 Platform Helm releases in the target namespace.
Confirm that all worker nodes report Ready status, the control plane components are running, and the cluster has a default StorageClass before you continue.
Deployment topologies and capacity requirements
Chef 360 Platform uses a topology model to distribute its workloads across your Kubernetes worker nodes. You provision the worker nodes and Chef 360 Platform schedules its pods onto them. Choose the topology that matches your availability and scalability requirements.
How to read the capacity tables
The capacity values in the following sections are baseline aggregate resources, not the total cluster size or the capacity of a single worker node:
- Each table shows the baseline aggregate CPU, memory, and disk that Chef 360 Platform pods request from your cluster.
- For Tiered-HA and Hyperscale HA, each table row shows the baseline capacity for that role’s worker pool.
- Each HA node group needs at least three worker nodes, in addition to meeting the group’s aggregate CPU and memory capacity.
Distribute aggregate capacity across nodes
Because the aggregate capacity values are independent of any specific node size, you can distribute them across worker nodes however you choose, as long as the node group meets both the aggregate capacity requirement and the minimum node count. For example, a Hyperconverged HA deployment requires at least 48 vCPU and 96 GB of memory across its worker node group. You can meet this requirement with different node configurations, such as:
- Three worker nodes with 16 vCPU and 32 GB of memory each
- Four worker nodes with 12 vCPU and 24 GB of memory each
- Six worker nodes with 8 vCPU and 16 GB of memory each
Each of these configurations meets both the aggregate capacity requirement and the minimum node count requirement for an HA node group.
Plan for additional capacity
The capacity values in the tables are baseline recommendations, not guarantees for every workload. Provision additional allocatable capacity beyond these baselines for:
- Kubernetes system overhead and other workloads that aren’t part of Chef 360 Platform
- Storage overhead and node failure recovery
- Number of managed nodes
- Job execution frequency, duration, and output size
- Compliance scanning and configuration management workloads
- Data retention requirements
- Availability and redundancy objectives
Work with a Chef 360 Platform architect to validate node sizing for your environment.
Topologies
Chef 360 Platform supports the following deployment topologies:
Non-HA deployment topology
A non-HA topology, also known as Hyperconverged Non-HA, runs a single instance of each required platform service. This topology doesn’t provide high availability, automatic failover, or redundancy. Use it only for development, testing, or proof-of-concept environments.
Provision enough worker nodes to collectively provide at least the following aggregate capacity:
| vCPU | Memory (GB) | Disk (GB) |
|---|---|---|
| 16 | 32 | 200 |
HA deployment topology
An HA topology, also known as Hyperconverged HA, runs multiple instances of each platform service across your cluster to provide high availability, automatic failover, and redundancy. Platform services remain available if an individual instance or node fails. Use this topology for production environments with moderate workload requirements.
Provision enough worker nodes to collectively provide at least the following aggregate capacity:
| vCPU | Memory (GB) | Disk (GB) |
|---|---|---|
| 48 | 96 | 600 |
Tiered-HA deployment topology
A Tiered-HA topology helps you run a highly available production environment while scaling backend and frontend workloads independently. It uses hard node affinity for backend services and soft node affinity for frontend services. Backend services run only on backend nodes and aren’t scheduled elsewhere. Frontend services prefer frontend nodes, but the scheduler can place them on backend nodes when the frontend worker pool doesn’t have enough available resources. Choose this topology when you want dedicated backend capacity with flexible frontend scheduling during changes in workload or worker availability.
Use the following node labels to control where Chef 360 Platform places workloads in your cluster:
| Role | Node label | vCPU | Memory (GB) | Disk (GB) |
|---|---|---|---|---|
| Backend | chef.io/backend=true | 48 | 96 | 600 |
| Frontend | chef.io/frontend=true | 24 | 48 | 150 |
Hyperscale HA deployment topology
A Hyperscale HA topology helps you run a highly available production environment with maximum separation between backend and frontend workloads. It uses hard affinity to require dedicated worker pools for each service group. Backend pods run only on backend nodes, and frontend pods run only on frontend nodes; pods can’t use the other worker pool, even when capacity is available there. Choose this topology when you need predictable resource allocation, strict workload isolation, and independent scaling for backend and frontend services.
Use the following node labels to control where Chef 360 Platform places workloads in your cluster:
| Role | Node label | vCPU | Memory (GB) | Disk (GB) |
|---|---|---|---|---|
| Backend | chef.io/backend=true | 48 | 96 | 600 |
| Frontend | chef.io/frontend=true | 24 | 48 | 150 |
Choose an installation option
Choose the installation option that matches your network environment before you configure the cluster:
- Standard installation: Use this option when the cluster can reach the internet during installation and operation.
- Air-gapped installation: Use this option when the cluster has no direct internet access and artifacts must be transferred into the environment.
The following sections apply to both installation options unless they identify an option-specific requirement.
Ports
Chef 360 Platform uses the following default ports. Open these ports if you use the default port configuration.
Inbound ports are the default Kubernetes service ports that clients use to reach platform components. Use your ingress or load balancer configuration to determine which of these ports must be reachable from outside the cluster.
| Port | Component |
|---|---|
31000 | API gateway |
31050 | RabbitMQ |
31101 | Mailpit (optional) |
Outbound HTTPS on port 443 lets a non-air-gapped installation reach the endpoints listed for an internet-connected cluster.
Air-gapped installations don’t require outbound connectivity.
| Port | Purpose |
|---|---|
443 | Outbound HTTPS for non-air-gapped installations |
Fully qualified domain name
Chef 360 Platform Server requires a fully qualified domain name (FQDN) that’s RFC 1123-compliant and registered with the Domain Name System (DNS). Confirm that the FQDN resolves from the workstations, user devices, and managed nodes that need to reach Chef 360 Platform.Backup and disaster recovery
Backup and disaster recovery for BYOK deployments falls under customer’s responsibility model. Work with your Kubernetes administration team to develop backup and restore processes that align with your organization’s recovery time objective (RTO) and recovery point objective (RPO) policies.
Kubernetes cluster
Air-gapped cluster
An air-gapped deployment has the following network and infrastructure requirements.
Network isolation:
- The Kubernetes cluster has no direct internet connectivity.
- Cluster nodes can communicate with each other over the internal network.
- If the cluster’s workstation is also air-gapped, you need a secure file-transfer mechanism to move artifacts to the workstation.
Infrastructure:
A private container registry that’s reachable from all Kubernetes nodes. Supported options include Docker Registry, Harbor, or a similar registry. The registry must have enough storage capacity for Chef 360 Platform images.
A local file server or object storage to host installation artifacts that don’t reside in the private container registry. Supported options include:
- An HTTP or HTTPS file server
- An S3-compatible object storage service
- A network file share that’s reachable from the installation host
Internet-connected cluster
An internet-connected cluster must have outbound connectivity to the following services:
- Container registry:
registry.chef360.chef.io - Downloads portal:
download.chef360.chef.io - Proxy registry services:
proxy.chef360.chef.io - Application services:
appservice.chef360.chef.io - Docker Hub domains:
index.docker.iocdn.auth0.com*.docker.io*.docker.com
If your environment uses a corporate proxy, configure it to allow access to these endpoints over HTTPS. Configure proxy settings in the following locations:
- The Docker daemon on cluster nodes
- The Kubernetes cluster configuration
- The container runtime, such as containerd or CRI-O
Review your plan
Before you start the installation, confirm that every item in this checklist is complete:
- Your Kubernetes distribution and version are supported.
- You selected a deployment topology and provided its baseline capacity plus additional capacity for Kubernetes, other workloads, storage, and node failure recovery.
- Your deployment identity can connect with
kubectl, read cluster resources, manage StorageClasses, create namespaces and CRDs, and install and manage Chef 360 Platform Helm releases. - All worker nodes report
Ready, the control plane is running, and a default StorageClass is available. - Required ports are available, and the deployment FQDN is DNS-registered and RFC 1123-compliant.
- You selected the correct standard or air-gapped installation path.
- Your registry, artifact storage, firewall, and proxy configuration meet the requirements for your network model.
- Your organization has a backup and recovery plan for the Kubernetes cluster and Chef 360 Platform data.
When every item is complete, continue to install Chef 360 Platform Server on a BYOK cluster.
Next steps
- For an internet-connected cluster, follow the standard BYOK installation.
- For a cluster without direct internet access, follow the air-gapped BYOK installation.
Need access to this capability?
Deploying Chef 360 Platform requires a valid product license and access to the installation artifacts. Review the Chef 360 Platform product page to learn more and connect with the marketing or account team about access and deployment options.