The nucleus of the Kubernetes system is devoted to providing a standard API and manner in which operators and/or software can execute work on the cluster. The nucleus is the bare minimum set of functionality that should be considered absolutely stable in order to build up the layers above. Each piece of this layer is clearly documented, and these pieces are required to build higher-order concepts at other layers of the system. You can consider the APIs here to make up the core bits of the Kubernetes control plane.

The cluster control plane is the first half of the Kubernetes nucleus, and it provides the RESTful APIs that allow operators to utilized the mostly CRUD-based operations of the cluster. It is important to note that the Kubernetes nucleus and consequently the cluster control plane was built with multi-tenancy in mind, so the layer must be flexible enough to provide logical separation of teams or workloads within a single cluster. The cluster control plane follows API conventions that allow it to take advantage of shared services such as identity and auditing, and has access to the namespaces and events of the cluster.

The second half of the nucleus is execution. While there are a number of controllers in Kubernetes, such as the replication controller, replica set, and deployments, the kubelet is the most important controller and it forms the basis of the node and pod APIs that allow us to interact with the container execution layer. Kubernetes builds upon the kubelet with the concept of pods, which allow us to manage many containers and their constituent storage as a core capability of the system. We'll dig more into pods later.

Below the nucleus, we can see the various pieces that the kubelet depends on in order to manage the container, network, container storage, image storage, cloud provider, and identity. We've left these intentionally vague as there are several options for each box, and you can pick and choose from standard and popular implementations or experiment with emerging tech. To give you an idea of how many options there are in the base layer, we'll outline container runtime and network plugin options here.

Container Runtime options: You'll use the Kubernetes Container Runtime Interface (CRI) to interact with the two main container runtimes:

• containerd
• rkt

You're still able to run Docker containers on Kubernetes at this point, and as containerd is the default runtime, it's going to be transparent to the operator at this point due to the defaults. You'll be able to run all of the same docker <action> commands on the cluster to introspect and gather information about your clusters.

There are also several competing, emerging formats:

•  cri-containerd: https://github.com/containerd/cri-containerd
• runv and clear containers, which are hypervisor-based solutions: https://github.com/hyperhq/runv and https://github.com/clearcontainers/runtime
• kata containers, which are a combination of runv and clear containers: https://katacontainers.io/
• frakti containers, which combine runv and Docker: https://github.com/kubernetes/frakti

Network plugin: You can use the CNI to leverage any of the following plugins or the simple Kubenet networking implementation if you're going to rely on a cloud provider's network segmentation, or if you're going to be running a single node cluster:

• Cilium
• Contiv
• Contrail
• Flannel
• Kube-router
• Multus
• Calico
• Romana
• Weave net