Inside Kubelet: How Kubernetes Starts Pods and Manages Nodes

Kubelet Introduction

The author, Wang Xigang, works on the HULK cloud platform's container services and custom Kubernetes development. This article introduces the Kubelet service startup and pod creation process as a reference for readers interested in the Kubelet source code.

Kubelet Features

Pod management

Container health checks

Container monitoring

Kubelet Code Structure

<code>➜ kubelet (master) tree
.
├── BUILD
├── OWNERS
├── app
│   ├── BUILD
│   ├── OWNERS
│   ├── auth.go
│   ├── options
│   │   ├── BUILD
│   │   ├── container_runtime.go
│   │   ├── options.go
│   │   └── options_test.go
│   ├── plugins.go
│   ├── server.go
│   ├── server_linux.go
│   ├── server_test.go
│   └── server_unsupported.go
└── kubelet.go

2 directories, 15 files</code>

Kubelet Service Startup Process

Kubelet runs on each node, registers the node with the API server, reports resource usage, and monitors containers. The main entry point is cmd/kubelet/kubelet.go , which validates parameters, creates the API client, checks permissions, and starts the Kubelet.

Most functionality resides under pkg/kubelet . The startup sequence includes:

Validate configuration (validateConfig)

Create API server clients (CreateAPIServerClientConfig)

Check permissions (checkPermission)

In RunKubelet , two main actions occur: CreateAndInitKubelet and startKubelet .

<code>func CreateAndInitKubelet(...) (k kubelet.KubeletBootstrap, err error) {
    k, err = kubelet.NewMainKubelet(...)
    if err != nil {
        return nil, err
    }
    k.BirthCry()
    k.StartGarbageCollection()
    return k, nil
}
</code>

NewMainKubelet initializes components such as container garbage collection, status manager, image manager, probe manager, GPU manager, pod cache, secret manager, configMap manager, and network plugin.

<code>func startKubelet() {
    // start the kubelet
    go wait.Until(func() { k.Run(podCfg.Updates()) }, 0, wait.NeverStop)
    // start the kubelet server
    if kubeCfg.ReadOnlyPort > 0 {
        go wait.Until(func() {
            k.ListenAndServeReadOnly(net.ParseIP(kubeCfg.Address), uint(kubeCfg.ReadOnlyPort))
        }, 0, wait.NeverStop)
    }
}
</code>

The first goroutine runs the main loop ( Run ) which launches managers (diskSpaceManager, volumeManager, statusManager, probeManager) and registers the node. The second creates an HTTP server exposing pod and node information.

Pod Creation Process

The main loop ( syncLoop ) watches for pod updates from various sources and triggers handlers. The HandlePodAdditions handler validates the pod (e.g., disk space) and dispatches work to create the pod.

<code>func (kl *Kubelet) syncLoop(updates <-chan kubetypes.PodUpdate, handler SyncHandler) {
    for {
        kl.syncLoopIteration(updates, handler...)
    }
}
</code>

Pod creation involves:

Computing container changes ( computePodContainerChanges )

Creating a sandbox ( createPodSandbox )

<code>func (m *kubeGenericRuntimeManager) createPodSandbox(pod *v1.Pod, attempt uint32) (string, string, error) {
    podSandboxConfig, err := m.generatePodSandboxConfig(pod, attempt)
    // ...
    podSandBoxID, err := m.runtimeService.RunPodSandbox(podSandboxConfig)
    // ...
    return podSandBoxID, "", nil
}
</code>

The sandbox creation pulls the pause image if needed, sets up networking, and starts the pause container. After the sandbox is ready, init containers (if any) run sequentially; then the regular containers are started in a loop.

<code>for idx := range podContainerChanges.ContainersToStart {
    container := &amp;pod.Spec.Containers[idx]
    // ... startContainer logic ...
}
</code>

Starting a container involves ensuring the image exists, generating container config, creating the container via the Docker engine API, and finally starting it, with pre‑start and post‑stop hooks executed.

Summary

The article covered the main Kubelet workflow, from node registration to pod creation, and highlighted key internal components. Future posts will dive deeper into individual services such as volumeManager, diskSpaceManager, secretManager, and configMapManager.