Bring your own Kubernetes (BYOK) system requirements
Use this page to prepare a Kubernetes environment for a Chef 360 Platform bring your own Kubernetes (BYOK) deployment.
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 fully qualified domain name (FQDN).
- Choose a standard installation or an air-gapped installation and complete its network requirements.
Shared responsibility model
Responsibilities
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 the 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.
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 and disaster recovery for Kubernetes infrastructure components
- Container registry access
- Cluster security, role-based access control (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
Common requirements
Supported Kubernetes platforms
Chef 360 Platform runs on the following supported Kubernetes distributions:
| Platform | Requirement |
|---|---|
| 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 and readiness
Access permissions
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.
Kubernetes cluster readiness
Confirm that your cluster meets the following conditions:
- All worker nodes report
Readystatus. - The control plane components are running.
- The cluster has a default StorageClass.
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 |
Ports
Chef 360 Platform uses the following default ports. Open these ports when you use the default port configuration.
The following 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 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 requires a fully qualified domain name (FQDN) that’s RFC 1123-compliant and registered with the Domain Name System (DNS). Confirm that DNS lookups for the FQDN succeed and return the correct IP address from the workstations, user devices, and managed nodes that need to reach Chef 360 Platform.Backup and disaster recovery
You’re responsible for backup and disaster recovery for BYOK deployments. 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.
Network and infrastructure requirements
Chef 360 Platform’s network and infrastructure requirements depend on whether your cluster has internet access:
- An internet-connected cluster needs outbound connectivity to Chef 360 Platform endpoints and Docker Hub domains.
- An air-gapped cluster needs a private container registry and local artifact storage instead of internet access.
Complete the requirements that match your cluster’s connectivity model. For step-by-step installation instructions, see the standard installation or air-gapped installation guide.
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