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 tested and verified 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. The capacity values in the following sections are the baseline aggregate resources that Chef 360 Platform pods request from your cluster. They aren’t the total cluster size, and they don’t represent the capacity of a single worker node. For Tiered-HA and Hyperscale HA, each table row shows the baseline capacity for that role’s worker pool. Provision additional allocatable capacity for the Kubernetes system, other workloads, storage overhead, and node failure recovery.
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.
Your worker nodes must provide at least the following 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.
Your worker nodes must provide at least the following 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 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 and chef.io/controller=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 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 |
These requirements are baseline recommendations. Plan for additional capacity based on the following factors:
- Number of managed nodes
- Job execution frequency and duration
- Job output size
- Compliance scanning workloads
- Configuration management workloads
- Data retention requirements
- Availability and redundancy objectives
Work with a Chef 360 Platform architect to validate node sizing for your environment.
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