Every one of the Sysbox install steps assumes the underlying node pool is already shaped correctly. It isn’t, by default, and figuring that out the hard way costs more time than reading about it up front. Trying to troubleshoot a DaemonSet that keeps failing silently on nodes that is never going to work.
The first surprise is the node image. GKE hands you Container Optimized OS by default, which is a reasonable choice for almost every other workload on the cluster. Sysbox needs Ubuntu though, and specifically a kernel at 5.4 or newer, which COS simply doesn’t provide. So, the first real prerequisite isn’t a Sysbox setting at all. It’s provisioning a separate node pool that actually runs Ubuntu with containerd, using the UBUNTU_CONTAINERD image type, rather than assuming the default pool will work.
Sizing is the second thing teams underestimate. A node running nested Docker daemons inside user namespaces needs genuine headroom, not the smallest instance that technically boots. Four vCPUs and 4GB of RAM per node is closer to a floor than a comfortable target, and going below it doesn’t throw a clean error. It just shows up later as sandboxes that intermittently fail to start.
Version alignment is where things get quietly wrong. Sysbox wants Kubernetes 1.32 or newer, running alongside containerd 2.0.5 or later. There’s a specific range, containerd 2.0.1 through 2.0.4, carrying a bug that blocks pods from launching under any non-default runtime, Sysbox included. Land a node pool in that range and the installer falls back to deploying its own CRI-O runtime and switching the node over, which restarts kubelet and disrupts running pods for a minute or two. Survivable, but not something worth discovering by accident on a cluster other teams depend on. Pin the node pool version on purpose instead of letting a release channel decide for you.
The last piece is scheduling. The Sysbox installer looks for a specific label, sysbox-install=yes, before it will touch a node, and in practice a taint is worth adding too, so nothing lands on that node except workloads that actually want Sysbox underneath them. Both belong in the same Terraform that provisions the pool, not in a kubectl command someone runs once during setup and never writes down again.
Here’s roughly what that node pool looks like in practice:
resource "google_container_node_pool" "sysbox_pool" {
name = "sysbox-nodes"
cluster = google_container_cluster.primary.name
location = google_container_cluster.primary.location
node_count = 2
version = "1.32.4-gke.1236000"
node_config {
machine_type = "e2-standard-4"
image_type = "UBUNTU_CONTAINERD"
disk_size_gb = 100
labels = {
"sysbox-install" = "yes"
}
taint {
key = "sysbox"
value = "true"
effect = "NO_SCHEDULE"
}
oauth_scopes = [
"https://www.googleapis.com/auth/cloud-platform"
]
}
management {
auto_repair = true
auto_upgrade = false
}
}The image_type line does most of the real work here. Everything else is tuning around it. Get that node pool right and the rest of the install, labeling the node, applying the manifest, watching the DaemonSet come up healthy, turns into the straightforward part it’s supposed to be.
None of this is complicated once it’s written down. It’s just the kind of setup that stays invisible when done correctly and expensive when skipped, which is probably why it rarely gets more than a passing mention in the official documentation.
 | Anuj Tuli, Chief Technology Officer Anuj specializes in developing and delivering vendor-agnostic solutions that avoid the “rip-and-replace” of existing IT investments. He has worked on Cloud Automation, DevOps, Cloud Readiness Assessments, and Migration projects for healthcare, banking, ISP, telecommunications, government and other sectors. He leads the development and management of Cloud Automation IP (intellectual property) and related professional services. During his career, he held multiple roles in the Cloud and Automation, and DevOps domains. With certifications in AWS, VMware, HPE, BMC and ITIL, Anuj offers a hands-on perspective on these technologies. Like what you read? Follow Anuj on LinkedIn at https://www.linkedin.com/in/anujtuli/ |