Kubernetes 1.13 stabilizes cluster bootstrap and external storage

Cluster installation and storage integration both require a clear division of responsibility. An installer must know which tasks belong to Kubernetes and which belong to the surrounding infrastructure. A storage integration needs a stable way to connect vendor behavior to the volume lifecycle. The Kubernetes 1.13 announcement on December 3 brings kubeadm and CSI to general availability and makes CoreDNS the recommended default DNS solution.

I regard these graduations as useful because they clarify where other systems can build on Kubernetes. A supported bootstrap tool can be part of a larger provisioning workflow. An external storage interface can let a vendor deliver its driver without changing the core project. Neither arrangement removes the need to understand the responsibilities on each side of the integration.

The announcement explicitly places kubeadm on existing hardware and describes it as a toolbox for administrators and higher-level automation. CSI similarly allows storage providers to build plugins outside the core codebase. The shared theme is a supported mechanism which another system can use. Understanding its scope is more useful than treating general availability as a promise to automate every surrounding operation.

Kubeadm init is a sequence of named phases

The kubeadm init implementation shipped in 1.13.0 constructs a workflow runner and registers its phases. The sequence begins with preflight checks and kubelet startup, then creates certificates and kubeconfig files. Control-plane and etcd phases precede waiting for the control plane. Later phases upload configuration, mark the control-plane node, arrange bootstrap tokens and install add-ons.

This sequence shows why cluster bootstrap cannot be reduced to writing a set of pod manifests. The control plane requires credentials and client configuration before later operations can use its API. Once it is available, the tool can record configuration and create resources through that API. The order expresses dependencies between local machine preparation and operations against the new cluster.

The runner binds phase subcommands and a skip-phases flag to the command. That makes the workflow usable at more than one level of granularity. Higher-level automation can use the same phase implementations which the complete initialization command invokes. The value is consistency between the combined workflow and the individual operations, with a common data initializer supplying their runtime information.

That initializer applies defaults and validates arguments before constructing the internal initialization configuration. It checks mixed argument use, applies bootstrap-token options and loads the configuration file when one is specified. It also verifies the API server bind address and validates feature choices against the requested Kubernetes version. These checks keep command interpretation separate from executing the phases.

Stable tooling still has versioned configuration

The public configuration type used by this implementation is kubeadm.k8s.io/v1beta1. The command's help text still labels configuration-file usage experimental. Those facts qualify what the general availability announcement means at the interface level. A tool's stable operational status does not make every input representation an unversioned permanent contract.

The source exposes only a subset of configuration options as command-line flags. Its flags include the API server's advertised address and bind port, Service and pod network ranges, and the DNS domain. It also accepts additional subject alternative names for the API server certificate. These options describe decisions which must agree with the environment into which the control plane is installed.

For example, an advertised API address and the names included in its certificate concern different aspects of reaching and trusting the server. A process can listen successfully while a client uses a name the certificate does not cover. The tool exposes both choices because establishing the endpoint and creating its credentials are separate bootstrap responsibilities.

Node registration also has explicit settings for the node name and container runtime socket. The initializer can override those from command-line options after configuration loading. That identifies the local node and runtime connection without assuming all machines present the same runtime endpoint. A higher-level provisioning system still has to supply settings which match the machine it prepared.

Dry run uses different storage and client behavior

The initialization code has a dry-run mode which creates a temporary working directory. Accessors for certificate output, kubeconfig output, manifests and kubelet files return that temporary directory when the mode is active. This lets the workflow produce its files without writing them into the ordinary runtime locations used for an actual initialization.

The client accessor also changes behavior in dry-run mode. It constructs a fake client with responses for some reads and logging for other requests. An ordinary run instead loads a Kubernetes client from the admin kubeconfig file. The comment requires that file to exist before client creation, reflecting the dependency between credential generation and the later API operations.

This gives dry run a defined purpose and a defined boundary. It can reveal generated artifacts and the requests the workflow intends to make. A fake API client cannot establish that a real control-plane process will start or that the machine's networking works. The implementation separates those behaviors rather than presenting dry run as a complete substitute for bringing up the cluster.

External certificate authority handling is another distinct path. The initializer detects an external CA arrangement and validates the kubeconfig files expected for it. It does not assume every installation allows kubeadm to generate all trust material. This is relevant to organizations which already control certificate issuance outside the cluster installation tool.

Initialization leaves networking work for the surrounding system

The success message in the source instructs the operator to install a pod network. It also explains how to use the generated administrator kubeconfig and supplies a node join command. These are separate next steps after the initialization workflow. A successfully initialized control plane is not a claim that every workload networking requirement has already been satisfied.

I find that explicit boundary useful for automation. The larger system can prepare hosts and install the selected network integration while kubeadm handles its defined control-plane workflow. Those operations must fit together, but they do not have to become one undifferentiated installer. Failures can be assigned to the phase or surrounding operation which actually owns the missing state.

The command can suppress printing the bootstrap token while still producing its other output. Its join-command generation iterates over configured tokens after the workflow finishes. This places enrollment instructions at the end of initialization, after the cluster-side bootstrap configuration has been arranged. The output is a consequence of the completed setup sequence rather than its starting point.

The same source contains failure guidance which distinguishes an unhealthy kubelet from a control-plane component that exited under the runtime. It directs the operator toward service logs for the former and container logs for the latter. That distinction follows the workflow's own structure. Starting the kubelet and waiting for the control plane involve related processes, but successful startup of one does not establish successful startup of the other.

CSI stabilizes the storage implementation boundary

The release announcement traces CSI through alpha in 1.9 and beta in 1.10 to general availability in 1.13. It also states that the CSI specification has reached 1.0. Storage vendors can implement drivers outside Kubernetes core and deliver them on their own schedule. That establishes a supported integration model for the storage work which the kubelet and controllers coordinate.

This changes where vendor implementation work belongs without removing Kubernetes' volume abstractions. The announced goal is interoperability through the interface rather than checking each storage implementation into the core repository. Operators still need an appropriate driver and its deployment configuration. A stable interface provides a common contract for that integration, while the storage provider remains responsible for the behavior behind it.

CoreDNS follows a related but distinct progression. Its Kubernetes integration reached general availability in 1.11, when kubeadm already selected it by default. The 1.13 announcement broadens that recommendation and notes the switch in common test infrastructure. This is a change in the project's recommended DNS implementation, alongside the new stability status of kubeadm and CSI.

For a cluster builder, these distinctions identify concrete choices. Kubeadm provides a phased workflow for initializing core components on prepared machines. CSI provides the external storage interface, and CoreDNS supplies the recommended DNS server integration. The kubeadm success output still calls for a pod network, so the higher-level installation remains responsible for completing that part of the cluster environment.