Kubernetes Control Plane Configuration

Kubernetes Control Plane Configuration is the specific set of flags, configuration files, and structured configuration objects used to control the behavior of each control plane binary, kube-apiserver, etcd, kube-scheduler, kube-controller-manager, covering both the command-line flag interface each binary accepts directly and the more structured, versioned configuration file formats several of them additionally support.

kube-apiserver Configuration

Command-Line Flags as the Primary Interface

kube-apiserver is formally configured almost entirely through command-line flags rather than a structured configuration file, covering everything from its serving certificates and etcd connection details to which admission plugins and authorization modes are enabled.

kube-apiserver \
  --advertise-address=10.0.1.10 \
  --etcd-servers=https://127.0.0.1:2379 \
  --service-cluster-ip-range=10.96.0.0/12 \
  --authorization-mode=Node,RBAC \
  --enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,ResourceQuota

EncryptionConfiguration as a Referenced File

Where encryption at rest is enabled, kube-apiserver formally references a separate EncryptionConfiguration file via the --encryption-provider-config flag, specifying which resource types are encrypted and with which provider and keys.

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources: ["secrets"]
    providers:
      - aescbc:
          keys:
            - name: key1
              secret: <base64-encoded-key>

etcd Configuration

Flags and an Equivalent Configuration File

etcd formally accepts configuration via command-line flags, environment variables, or a YAML configuration file, all three forms controlling the same underlying settings, with the file form commonly preferred for production deployments to keep configuration under version control.

name: etcd-1
data-dir: /var/lib/etcd
listen-peer-urls: https://10.0.1.10:2380
listen-client-urls: https://10.0.1.10:2379
initial-cluster: etcd-1=https://10.0.1.10:2380,etcd-2=https://10.0.1.11:2380
initial-cluster-state: new

etcd --config-file=/etc/etcd/etcd.yaml

kube-scheduler Configuration

KubeSchedulerConfiguration

kube-scheduler formally supports a structured, versioned configuration object, KubeSchedulerConfiguration, referenced via the --config flag, through which scheduling profiles, enabled plugins, and per-plugin arguments are defined, a more expressive mechanism than flags alone can provide for its plugin-based architecture.

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
leaderElection:
  leaderElect: true
profiles:
  - schedulerName: default-scheduler
    plugins:
      score:
        enabled:
          - name: NodeResourcesBalancedAllocation
            weight: 1

kube-scheduler --config=/etc/kubernetes/scheduler-config.yaml

kube-controller-manager Configuration

Flags Controlling Individual Loop Behavior

kube-controller-manager formally exposes flags governing both cluster-wide behavior, such as --cluster-cidr for Pod networking allocation, and controller-specific tuning, such as --node-monitor-grace-period, determining how long a node may go without a heartbeat before being marked unhealthy.

kube-controller-manager \
  --cluster-cidr=10.244.0.0/16 \
  --node-monitor-grace-period=40s \
  --node-monitor-period=5s \
  --leader-elect=true

Selectively Enabling and Disabling Controllers

The --controllers flag formally allows specific individual controller loops to be enabled or disabled within the single controller-manager binary, using a +/- prefixed list, providing granular control over which of its many bundled loops are actually active in a given deployment.

kube-controller-manager --controllers=*,-nodeipam,-cloud-node-lifecycle

kubeadm ClusterConfiguration

A Higher-Level Declarative Wrapper

For clusters bootstrapped with kubeadm, a ClusterConfiguration object formally provides a single, higher-level declarative source from which kubeadm derives the individual flags and files for each underlying control plane binary, simplifying initial setup at the cost of an additional layer of indirection above each component's own native configuration format.

apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
kubernetesVersion: v1.29.2
controlPlaneEndpoint: "cp-lb.codartium.internal:6443"
networking:
  podSubnet: 10.244.0.0/16
etcd:
  local:
    dataDir: /var/lib/etcd

kubeadm init --config=cluster-config.yaml

Where Configuration Lives on a Running Node

Static Pod Manifests as the Applied Result

On a node using static Pod packaging, each component's fully resolved flags and mounted configuration files formally appear directly within its static Pod manifest, making the manifest itself the authoritative, inspectable record of exactly how that component instance is currently configured.

cat /etc/kubernetes/manifests/kube-scheduler.yaml
cat /etc/kubernetes/manifests/kube-apiserver.yaml

Why Configuration Formats Differ Across Components

The mix of flag-only, flag-plus-file, and structured versioned-object configuration across these binaries reflects each component's own complexity: kube-apiserver's largely flat set of independent settings suits flags well, while kube-scheduler's plugin framework required a structured, versioned configuration object capable of expressing nested, per-plugin settings that flags alone could not represent cleanly.