One of the key design decisions of GKE Autopilot is the fact that we kept the same semantic meaning of the Kubernetes node object.
It’s “nodeless” in the sense that you don’t need to care about, or plan for nodes—they are provisioned and managed automatically based on your PodSpec. However, the node object still exists and has the same meaning. Each node is still backed by a single VM under the hood.
This means that constructs that rely on nodes like workload separation, pod topology spread, pod affinity, and DaemonSets all still work on Autopilot. When using constructs like workload separation and affinity, at no time do you ever manually specify or target individual nodes. We figure out the placement based on your PodSpecs. For example, if you want to co-locate two pods on one node, you can do it, purely via your PodSpec and without referring to node constructs like node or nodepool names.
All this makes GKE Autopilot very much Kubernetes-native. While you don’t have the concern of nodes, having the node construct available means you can take advantage of everything Kubernetes has to offer.
Case in point: today’s announcement of 12 partners for GKE Autopilot. Many of these solutions have always run as DaemonSets. Since Autopilot supports DaemonSets, they can run in the same way. No need to embed these solutions into your individual pods with sidecars and the like.
Not only does this make those solutions much easier to use, it’s typically cheaper this way too. The DaemonSet only runs one pod on every node and this pod is able to cater for multiple user pods, whereas a sidecar container adds resource requirements to every pod.
There is one caveat with DaemonSets: since Autopilot is fully managed, some higher privileged actions are reserved from regular pods (including pods managed by a DaemonSet). You can deploy any pod as a DaemonSet as long as it doesn’t violate those constraints and use-cases like reading logs from nodes are supported. For partner solutions (like security products) that require higher privileges to operate, they can be validated and explicitly listed by the Autopilot team in order to run.
The end result is that if you want to run a security product like Aqua, Prisma Cloud or Sysdig, or a logging and monitoring solution like DataDog, Splunk or Dynatrace, you can run it on GKE Autopilot, just like you always do.