Convert site to Hugo (#8316)

This commit converts content and layout to use Hugo.
This commit is contained in:
Bjørn Erik Pedersen
2018-05-05 18:00:51 +02:00
committed by k8s-ci-robot
parent 7745f0e0c5
commit 7f3b633aa0
2327 changed files with 10928 additions and 171503 deletions
+5
View File
@@ -0,0 +1,5 @@
---
title: "Kubeadm"
weight: 10
---
@@ -0,0 +1 @@
All files in this directory are auto-generated from other repos. **Do not edit them manually. You must edit them in their upstream repo.**
@@ -0,0 +1,6 @@
---
title: "Kubeadm Generated"
weight: 10
toc_hide: true
---
@@ -0,0 +1,60 @@
kubeadm: easily bootstrap a secure Kubernetes cluster
### Synopsis
kubeadm: easily bootstrap a secure Kubernetes cluster.
┌──────────────────────────────────────────────────────────┐
│ KUBEADM IS CURRENTLY IN BETA │
│ │
│ But please, try it out and give us feedback at: │
│ https://github.com/kubernetes/kubeadm/issues │
│ and at-mention @kubernetes/sig-cluster-lifecycle-bugs │
│ or @kubernetes/sig-cluster-lifecycle-feature-requests │
└──────────────────────────────────────────────────────────┘
Example usage:
Create a two-machine cluster with one master (which controls the cluster),
and one node (where your workloads, like Pods and Deployments run).
┌──────────────────────────────────────────────────────────┐
│ On the first machine: │
├──────────────────────────────────────────────────────────┤
│ master# kubeadm init │
└──────────────────────────────────────────────────────────┘
┌──────────────────────────────────────────────────────────┐
│ On the second machine: │
├──────────────────────────────────────────────────────────┤
│ node# kubeadm join <arguments-returned-from-init> │
└──────────────────────────────────────────────────────────┘
You can then repeat the second step on as many other machines as you like.
### Options
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">help for kubeadm</td>
</tr>
</tbody>
</table>
@@ -0,0 +1,29 @@
Experimental sub-commands not yet fully functional.
### Synopsis
Experimental sub-commands not yet fully functional.
### Options
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">help for alpha</td>
</tr>
</tbody>
</table>
@@ -0,0 +1,29 @@
Invoke subsets of kubeadm functions separately for a manual install.
### Synopsis
This command is not meant to be run on its own. See list of available subcommands.
### Options
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">help for phase</td>
</tr>
</tbody>
</table>
@@ -0,0 +1,29 @@
Installs required addons for passing Conformance tests
### Synopsis
This command is not meant to be run on its own. See list of available subcommands.
### Options
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">help for addon</td>
</tr>
</tbody>
</table>
@@ -0,0 +1,115 @@
Installs all addons to a Kubernetes cluster
### Synopsis
Installs the kube-dns and the kube-proxys addons components via the API server.
Please note that although the DNS server is deployed, it will not be scheduled until CNI is installed.
Alpha Disclaimer: this command is currently alpha.
```
kubeadm alpha phase addon all [flags]
```
### Examples
```
# Installs the kube-dns and the kube-proxys addons components via the API server,
# functionally equivalent to what installed by kubeadm init.
kubeadm alpha phase selfhosting from-staticpods
```
### Options
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--apiserver-advertise-address string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The IP address or DNS name the API server is accessible on</td>
</tr>
<tr>
<td colspan="2">--apiserver-bind-port int32&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 6443</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The port the API server is accessible on</td>
</tr>
<tr>
<td colspan="2">--config string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Path to a kubeadm config file. WARNING: Usage of a configuration file is experimental!</td>
</tr>
<tr>
<td colspan="2">--feature-gates string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">A set of key=value pairs that describe feature gates for various features.Options are:<br/>Auditing=true|false (ALPHA - default=false)<br/>CoreDNS=true|false (BETA - default=false)<br/>DynamicKubeletConfig=true|false (ALPHA - default=false)<br/>SelfHosting=true|false (ALPHA - default=false)<br/>StoreCertsInSecrets=true|false (ALPHA - default=false)</td>
</tr>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">help for all</td>
</tr>
<tr>
<td colspan="2">--image-repository string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "k8s.gcr.io"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Choose a container registry to pull control plane images from</td>
</tr>
<tr>
<td colspan="2">--kubeconfig string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/admin.conf"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The KubeConfig file to use when talking to the cluster</td>
</tr>
<tr>
<td colspan="2">--kubernetes-version string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "stable-1.10"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Choose a specific Kubernetes version for the control plane</td>
</tr>
<tr>
<td colspan="2">--pod-network-cidr string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The range of IP addresses used for the Pod network</td>
</tr>
<tr>
<td colspan="2">--service-cidr string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "10.96.0.0/12"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The range of IP address used for service VIPs</td>
</tr>
<tr>
<td colspan="2">--service-dns-domain string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "cluster.local"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Alternative domain for services</td>
</tr>
</tbody>
</table>
@@ -0,0 +1,85 @@
Installs the kube-dns addon to a Kubernetes cluster
### Synopsis
Installs the kube-dns addon components via the API server.
Please note that although the DNS server is deployed, it will not be scheduled until CNI is installed.
Alpha Disclaimer: this command is currently alpha.
```
kubeadm alpha phase addon kube-dns [flags]
```
### Options
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--config string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Path to a kubeadm config file. WARNING: Usage of a configuration file is experimental!</td>
</tr>
<tr>
<td colspan="2">--feature-gates string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">A set of key=value pairs that describe feature gates for various features.Options are:<br/>Auditing=true|false (ALPHA - default=false)<br/>CoreDNS=true|false (BETA - default=false)<br/>DynamicKubeletConfig=true|false (ALPHA - default=false)<br/>SelfHosting=true|false (ALPHA - default=false)<br/>StoreCertsInSecrets=true|false (ALPHA - default=false)</td>
</tr>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">help for kube-dns</td>
</tr>
<tr>
<td colspan="2">--image-repository string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "k8s.gcr.io"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Choose a container registry to pull control plane images from</td>
</tr>
<tr>
<td colspan="2">--kubeconfig string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/admin.conf"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The KubeConfig file to use when talking to the cluster</td>
</tr>
<tr>
<td colspan="2">--kubernetes-version string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "stable-1.10"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Choose a specific Kubernetes version for the control plane</td>
</tr>
<tr>
<td colspan="2">--service-cidr string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "10.96.0.0/12"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The range of IP address used for service VIPs</td>
</tr>
<tr>
<td colspan="2">--service-dns-domain string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "cluster.local"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Alternative domain for services</td>
</tr>
</tbody>
</table>
@@ -0,0 +1,84 @@
Installs the kube-proxy addon to a Kubernetes cluster
### Synopsis
Installs the kube-proxy addon components via the API server.
Alpha Disclaimer: this command is currently alpha.
```
kubeadm alpha phase addon kube-proxy [flags]
```
### Options
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--apiserver-advertise-address string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The IP address or DNS name the API server is accessible on</td>
</tr>
<tr>
<td colspan="2">--apiserver-bind-port int32&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 6443</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The port the API server is accessible on</td>
</tr>
<tr>
<td colspan="2">--config string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Path to a kubeadm config file. WARNING: Usage of a configuration file is experimental!</td>
</tr>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">help for kube-proxy</td>
</tr>
<tr>
<td colspan="2">--image-repository string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "k8s.gcr.io"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Choose a container registry to pull control plane images from</td>
</tr>
<tr>
<td colspan="2">--kubeconfig string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/admin.conf"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The KubeConfig file to use when talking to the cluster</td>
</tr>
<tr>
<td colspan="2">--kubernetes-version string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "stable-1.10"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Choose a specific Kubernetes version for the control plane</td>
</tr>
<tr>
<td colspan="2">--pod-network-cidr string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The range of IP addresses used for the Pod network</td>
</tr>
</tbody>
</table>
@@ -0,0 +1,36 @@
Manage kubeadm-specific bootstrap token functions
### Synopsis
This command is not meant to be run on its own. See list of available subcommands.
### Options
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">help for bootstrap-token</td>
</tr>
<tr>
<td colspan="2">--kubeconfig string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/admin.conf"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The KubeConfig file to use when talking to the cluster</td>
</tr>
</tbody>
</table>
@@ -0,0 +1,115 @@
Makes all the bootstrap token configurations and creates an initial token
### Synopsis
Bootstrap tokens are used for establishing bidirectional trust between a node joining the cluster and a the master node.
This command makes all the configurations required to make bootstrap tokens works and then creates an initial token.
Alpha Disclaimer: this command is currently alpha.
```
kubeadm alpha phase bootstrap-token all [flags]
```
### Examples
```
# Makes all the bootstrap token configurations and creates an initial token, functionally
# equivalent to what generated by kubeadm init.
kubeadm alpha phase bootstrap-token all
```
### Options
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--config string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Path to kubeadm config file (WARNING: Usage of a configuration file is experimental)</td>
</tr>
<tr>
<td colspan="2">--description string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "The default bootstrap token generated by 'kubeadm init'."</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">A human friendly description of how this token is used.</td>
</tr>
<tr>
<td colspan="2">--groups stringSlice&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: [system:bootstrappers:kubeadm:default-node-token]</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Extra groups that this token will authenticate as when used for authentication. Must match "system:bootstrappers:[a-z0-9:-]{0,255}[a-z0-9]"</td>
</tr>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">help for all</td>
</tr>
<tr>
<td colspan="2">--skip-token-print</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Skip printing of the bootstrap token</td>
</tr>
<tr>
<td colspan="2">--token string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The token to use for establishing bidirectional trust between nodes and masters</td>
</tr>
<tr>
<td colspan="2">--ttl duration&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 24h0m0s</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The duration before the token is automatically deleted (e.g. 1s, 2m, 3h). If set to '0', the token will never expire</td>
</tr>
<tr>
<td colspan="2">--usages stringSlice&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: [signing,authentication]</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Describes the ways in which this token can be used. You can pass --usages multiple times or provide a comma separated list of options. Valid options: [signing,authentication]</td>
</tr>
</tbody>
</table>
### Options inherited from parent commands
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--kubeconfig string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/admin.conf"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The KubeConfig file to use when talking to the cluster</td>
</tr>
</tbody>
</table>
@@ -0,0 +1,58 @@
Uploads the cluster-info ConfigMap from the given kubeconfig file
### Synopsis
Uploads the "cluster-info" ConfigMap in the "kube-public" namespace, populating it with cluster information extracted from the given kubeconfig file. The ConfigMap is used for the node bootstrap process in its initial phases, before the client trusts the API server.
See online documentation about Authenticating with Bootstrap Tokens for more details.
Alpha Disclaimer: this command is currently alpha.
```
kubeadm alpha phase bootstrap-token cluster-info [flags]
```
### Options
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">help for cluster-info</td>
</tr>
</tbody>
</table>
### Options inherited from parent commands
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--kubeconfig string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/admin.conf"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The KubeConfig file to use when talking to the cluster</td>
</tr>
</tbody>
</table>
@@ -0,0 +1,107 @@
Creates a bootstrap token to be used for node joining
### Synopsis
Creates a bootstrap token. If no token value is given, kubeadm will generate a random token instead.
Alternatively, you can use kubeadm token.
Alpha Disclaimer: this command is currently alpha.
```
kubeadm alpha phase bootstrap-token create [flags]
```
### Options
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--config string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Path to kubeadm config file (WARNING: Usage of a configuration file is experimental)</td>
</tr>
<tr>
<td colspan="2">--description string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "The default bootstrap token generated by 'kubeadm init'."</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">A human friendly description of how this token is used.</td>
</tr>
<tr>
<td colspan="2">--groups stringSlice&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: [system:bootstrappers:kubeadm:default-node-token]</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Extra groups that this token will authenticate as when used for authentication. Must match "system:bootstrappers:[a-z0-9:-]{0,255}[a-z0-9]"</td>
</tr>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">help for create</td>
</tr>
<tr>
<td colspan="2">--skip-token-print</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Skip printing of the bootstrap token</td>
</tr>
<tr>
<td colspan="2">--token string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The token to use for establishing bidirectional trust between nodes and masters</td>
</tr>
<tr>
<td colspan="2">--ttl duration&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 24h0m0s</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The duration before the token is automatically deleted (e.g. 1s, 2m, 3h). If set to '0', the token will never expire</td>
</tr>
<tr>
<td colspan="2">--usages stringSlice&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: [signing,authentication]</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Describes the ways in which this token can be used. You can pass --usages multiple times or provide a comma separated list of options. Valid options: [signing,authentication]</td>
</tr>
</tbody>
</table>
### Options inherited from parent commands
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--kubeconfig string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/admin.conf"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The KubeConfig file to use when talking to the cluster</td>
</tr>
</tbody>
</table>
@@ -0,0 +1,50 @@
Configures the node bootstrap process
### Synopsis
This command is not meant to be run on its own. See list of available subcommands.
### Options
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">help for node</td>
</tr>
</tbody>
</table>
### Options inherited from parent commands
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--kubeconfig string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/admin.conf"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The KubeConfig file to use when talking to the cluster</td>
</tr>
</tbody>
</table>
@@ -0,0 +1,58 @@
Configures RBAC rules to allow the csrapprover controller automatically approve CSRs from a node bootstrap token
### Synopsis
Configures RBAC rules to allow the csrapprover controller to automatically approve certificate signing requests generated by nodes joining the cluster. It configures also RBAC rules for certificates rotation (with auto approval of new certificates).
See online documentation about TLS bootstrapping for more details.
Alpha Disclaimer: this command is currently alpha.
```
kubeadm alpha phase bootstrap-token node allow-auto-approve [flags]
```
### Options
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">help for allow-auto-approve</td>
</tr>
</tbody>
</table>
### Options inherited from parent commands
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--kubeconfig string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/admin.conf"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The KubeConfig file to use when talking to the cluster</td>
</tr>
</tbody>
</table>
@@ -0,0 +1,58 @@
Configures RBAC to allow node bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
### Synopsis
Configures RBAC rules to allow node bootstrap tokens to post a certificate signing request, thus enabling nodes joining the cluster to request long term certificate credentials.
See online documentation about TLS bootstrapping for more details.
Alpha Disclaimer: this command is currently alpha.
```
kubeadm alpha phase bootstrap-token node allow-post-csrs [flags]
```
### Options
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">help for allow-post-csrs</td>
</tr>
</tbody>
</table>
### Options inherited from parent commands
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--kubeconfig string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/admin.conf"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The KubeConfig file to use when talking to the cluster</td>
</tr>
</tbody>
</table>
@@ -0,0 +1,29 @@
Generates certificates for a Kubernetes cluster
### Synopsis
This command is not meant to be run on its own. See list of available subcommands.
### Options
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">help for certs</td>
</tr>
</tbody>
</table>
@@ -0,0 +1,91 @@
Generates all PKI assets necessary to establish the control plane
### Synopsis
Generates a self-signed CA to provision identities for each component in the cluster (including nodes) and client certificates to be used by various components.
If a given certificate and private key pair both exist, kubeadm skips the generation step and
existing files will be used.
Alpha Disclaimer: this command is currently alpha.
```
kubeadm alpha phase certs all [flags]
```
### Examples
```
# Creates all PKI assets necessary to establish the control plane,
# functionally equivalent to what generated by kubeadm init.
kubeadm alpha phase certs all
# Creates all PKI assets using options read from a configuration file.
kubeadm alpha phase certs all --config masterconfiguration.yaml
```
### Options
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--apiserver-advertise-address string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The IP address the API server is accessible on, to use for the API server serving cert</td>
</tr>
<tr>
<td colspan="2">--apiserver-cert-extra-sans stringSlice</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Optional extra altnames to use for the API server serving cert. Can be both IP addresses and dns names</td>
</tr>
<tr>
<td colspan="2">--cert-dir string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/pki"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The path where to save the certificates</td>
</tr>
<tr>
<td colspan="2">--config string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Path to kubeadm config file (WARNING: Usage of a configuration file is experimental)</td>
</tr>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">help for all</td>
</tr>
<tr>
<td colspan="2">--service-cidr string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "10.96.0.0/12"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Alternative range of IP address for service VIPs, from which derives the internal API server VIP that will be added to the API Server serving cert</td>
</tr>
<tr>
<td colspan="2">--service-dns-domain string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "cluster.local"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Alternative domain for services, to use for the API server serving cert</td>
</tr>
</tbody>
</table>
@@ -0,0 +1,51 @@
Generates a client certificate for the API server to connect to etcd securely
### Synopsis
Generates the client certificate for the API server to connect to etcd securely and the respective key, and saves them into apiserver-etcd-client.crt and apiserver-etcd-client.key files.
If both files already exist, kubeadm skips the generation step and existing files will be used.
Alpha Disclaimer: this command is currently alpha.
```
kubeadm alpha phase certs apiserver-etcd-client [flags]
```
### Options
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--cert-dir string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/pki"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The path where to save the certificates</td>
</tr>
<tr>
<td colspan="2">--config string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Path to kubeadm config file (WARNING: Usage of a configuration file is experimental)</td>
</tr>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">help for apiserver-etcd-client</td>
</tr>
</tbody>
</table>
@@ -0,0 +1,51 @@
Generates a client certificate for the API server to connect to the kubelets securely
### Synopsis
Generates the client certificate for the API server to connect to the kubelet securely and the respective key, and saves them into apiserver-kubelet-client.crt and apiserver-kubelet-client.key files.
If both files already exist, kubeadm skips the generation step and existing files will be used.
Alpha Disclaimer: this command is currently alpha.
```
kubeadm alpha phase certs apiserver-kubelet-client [flags]
```
### Options
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--cert-dir string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/pki"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The path where to save the certificates</td>
</tr>
<tr>
<td colspan="2">--config string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Path to kubeadm config file (WARNING: Usage of a configuration file is experimental)</td>
</tr>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">help for apiserver-kubelet-client</td>
</tr>
</tbody>
</table>
@@ -0,0 +1,81 @@
Generates an API server serving certificate and key
### Synopsis
Generates the API server serving certificate and key and saves them into apiserver.crt and apiserver.key files.
The certificate includes default subject alternative names and additional SANs provided by the user; default SANs are: <node-name>, <apiserver-advertise-address>, kubernetes, kubernetes.default, kubernetes.default.svc, kubernetes.default.svc. <service-dns-domain>, <internalAPIServerVirtualIP>(that is the .10 address in <service-cidr>address space).
If both files already exist, kubeadm skips the generation step and existing files will be used.
Alpha Disclaimer: this command is currently alpha.
```
kubeadm alpha phase certs apiserver [flags]
```
### Options
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--apiserver-advertise-address string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The IP address the API server is accessible on, to use for the API server serving cert</td>
</tr>
<tr>
<td colspan="2">--apiserver-cert-extra-sans stringSlice</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Optional extra altnames to use for the API server serving cert. Can be both IP addresses and dns names</td>
</tr>
<tr>
<td colspan="2">--cert-dir string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/pki"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The path where to save the certificates</td>
</tr>
<tr>
<td colspan="2">--config string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Path to kubeadm config file (WARNING: Usage of a configuration file is experimental)</td>
</tr>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">help for apiserver</td>
</tr>
<tr>
<td colspan="2">--service-cidr string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "10.96.0.0/12"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Alternative range of IP address for service VIPs, from which derives the internal API server VIP that will be added to the API Server serving cert</td>
</tr>
<tr>
<td colspan="2">--service-dns-domain string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "cluster.local"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Alternative domain for services, to use for the API server serving cert</td>
</tr>
</tbody>
</table>
@@ -0,0 +1,51 @@
Generates a self-signed kubernetes CA to provision identities for components of the cluster
### Synopsis
Generates the self-signed kubernetes certificate authority and related key, and saves them into ca.crt and ca.key files.
If both files already exist, kubeadm skips the generation step and existing files will be used.
Alpha Disclaimer: this command is currently alpha.
```
kubeadm alpha phase certs ca [flags]
```
### Options
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--cert-dir string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/pki"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The path where to save the certificates</td>
</tr>
<tr>
<td colspan="2">--config string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Path to kubeadm config file (WARNING: Usage of a configuration file is experimental)</td>
</tr>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">help for ca</td>
</tr>
</tbody>
</table>
@@ -0,0 +1,51 @@
Generates a self-signed CA to provision identities for etcd
### Synopsis
Generates the self-signed etcd certificate authority and related key and saves them into etcd/ca.crt and etcd/ca.key files.
If both files already exist, kubeadm skips the generation step and existing files will be used.
Alpha Disclaimer: this command is currently alpha.
```
kubeadm alpha phase certs etcd-ca [flags]
```
### Options
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--cert-dir string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/pki"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The path where to save the certificates</td>
</tr>
<tr>
<td colspan="2">--config string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Path to kubeadm config file (WARNING: Usage of a configuration file is experimental)</td>
</tr>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">help for etcd-ca</td>
</tr>
</tbody>
</table>
@@ -0,0 +1,51 @@
Generates a client certificate for liveness probes to healthcheck etcd
### Synopsis
Generates the client certificate for liveness probes to healthcheck etcd and the respective key, and saves them into etcd/healthcheck-client.crt and etcd/healthcheck-client.key files.
If both files already exist, kubeadm skips the generation step and existing files will be used.
Alpha Disclaimer: this command is currently alpha.
```
kubeadm alpha phase certs etcd-healthcheck-client [flags]
```
### Options
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--cert-dir string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/pki"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The path where to save the certificates</td>
</tr>
<tr>
<td colspan="2">--config string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Path to kubeadm config file (WARNING: Usage of a configuration file is experimental)</td>
</tr>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">help for etcd-healthcheck-client</td>
</tr>
</tbody>
</table>
@@ -0,0 +1,53 @@
Generates an etcd peer certificate and key
### Synopsis
Generates the etcd peer certificate and key and saves them into etcd/peer.crt and etcd/peer.key files.
The certificate includes default subject alternative names and additional SANs provided by the user; default SANs are: <node-name>, <apiserver-advertise-address>.
If both files already exist, kubeadm skips the generation step and existing files will be used.
Alpha Disclaimer: this command is currently alpha.
```
kubeadm alpha phase certs etcd-peer [flags]
```
### Options
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--cert-dir string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/pki"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The path where to save the certificates</td>
</tr>
<tr>
<td colspan="2">--config string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Path to kubeadm config file (WARNING: Usage of a configuration file is experimental)</td>
</tr>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">help for etcd-peer</td>
</tr>
</tbody>
</table>
@@ -0,0 +1,53 @@
Generates an etcd serving certificate and key
### Synopsis
Generates the etcd serving certificate and key and saves them into etcd/server.crt and etcd/server.key files.
The certificate includes default subject alternative names and additional SANs provided by the user; default SANs are: localhost, 127.0.0.1.
If both files already exist, kubeadm skips the generation step and existing files will be used.
Alpha Disclaimer: this command is currently alpha.
```
kubeadm alpha phase certs etcd-server [flags]
```
### Options
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--cert-dir string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/pki"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The path where to save the certificates</td>
</tr>
<tr>
<td colspan="2">--config string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Path to kubeadm config file (WARNING: Usage of a configuration file is experimental)</td>
</tr>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">help for etcd-server</td>
</tr>
</tbody>
</table>
@@ -0,0 +1,51 @@
Generates a front proxy CA certificate and key for a Kubernetes cluster
### Synopsis
Generates the front proxy CA certificate and key and saves them into front-proxy-ca.crt and front-proxy-ca.key files.
If both files already exist, kubeadm skips the generation step and existing files will be used.
Alpha Disclaimer: this command is currently alpha.
```
kubeadm alpha phase certs front-proxy-ca [flags]
```
### Options
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--cert-dir string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/pki"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The path where to save the certificates</td>
</tr>
<tr>
<td colspan="2">--config string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Path to kubeadm config file (WARNING: Usage of a configuration file is experimental)</td>
</tr>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">help for front-proxy-ca</td>
</tr>
</tbody>
</table>
@@ -0,0 +1,51 @@
Generates a front proxy CA client certificate and key for a Kubernetes cluster
### Synopsis
Generates the front proxy client certificate and key and saves them into front-proxy-client.crt and front-proxy-client.key files.
If both files already exist, kubeadm skips the generation step and existing files will be used.
Alpha Disclaimer: this command is currently alpha.
```
kubeadm alpha phase certs front-proxy-client [flags]
```
### Options
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--cert-dir string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/pki"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The path where to save the certificates</td>
</tr>
<tr>
<td colspan="2">--config string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Path to kubeadm config file (WARNING: Usage of a configuration file is experimental)</td>
</tr>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">help for front-proxy-client</td>
</tr>
</tbody>
</table>
@@ -0,0 +1,51 @@
Generates a private key for signing service account tokens along with its public key
### Synopsis
Generates the private key for signing service account tokens along with its public key, and saves them into sa.key and sa.pub files.
If both files already exist, kubeadm skips the generation step and existing files will be used.
Alpha Disclaimer: this command is currently alpha.
```
kubeadm alpha phase certs sa [flags]
```
### Options
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--cert-dir string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/pki"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The path where to save the certificates</td>
</tr>
<tr>
<td colspan="2">--config string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Path to kubeadm config file (WARNING: Usage of a configuration file is experimental)</td>
</tr>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">help for sa</td>
</tr>
</tbody>
</table>
@@ -0,0 +1,29 @@
Generates all static Pod manifest files necessary to establish the control plane
### Synopsis
This command is not meant to be run on its own. See list of available subcommands.
### Options
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">help for controlplane</td>
</tr>
</tbody>
</table>
@@ -0,0 +1,123 @@
Generates all static Pod manifest files necessary to establish the control plane
### Synopsis
Generates all static Pod manifest files necessary to establish the control plane.
Alpha Disclaimer: this command is currently alpha.
```
kubeadm alpha phase controlplane all [flags]
```
### Examples
```
# Generates all static Pod manifest files for control plane components,
# functionally equivalent to what generated by kubeadm init.
kubeadm alpha phase controlplane all
# Generates all static Pod manifest files using options read from a configuration file.
kubeadm alpha phase controlplane --config masterconfiguration.yaml
```
### Options
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--apiserver-advertise-address string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The IP address of the API server is accessible on</td>
</tr>
<tr>
<td colspan="2">--apiserver-bind-port int32&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 6443</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The port the API server is accessible on</td>
</tr>
<tr>
<td colspan="2">--apiserver-extra-args mapStringString</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">A set of extra flags to pass to the API Server or override default ones in form of &lt;flagname&gt;=&lt;value&gt;</td>
</tr>
<tr>
<td colspan="2">--cert-dir string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/pki"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The path where certificates are stored</td>
</tr>
<tr>
<td colspan="2">--config string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Path to kubeadm config file (WARNING: Usage of a configuration file is experimental)</td>
</tr>
<tr>
<td colspan="2">--controller-manager-extra-args mapStringString</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">A set of extra flags to pass to the Controller Manager or override default ones in form of &lt;flagname&gt;=&lt;value&gt;</td>
</tr>
<tr>
<td colspan="2">--feature-gates string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">A set of key=value pairs that describe feature gates for various features. Options are:<br/>Auditing=true|false (ALPHA - default=false)<br/>CoreDNS=true|false (BETA - default=false)<br/>DynamicKubeletConfig=true|false (ALPHA - default=false)<br/>SelfHosting=true|false (ALPHA - default=false)<br/>StoreCertsInSecrets=true|false (ALPHA - default=false)</td>
</tr>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">help for all</td>
</tr>
<tr>
<td colspan="2">--kubernetes-version string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "stable-1.10"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Choose a specific Kubernetes version for the control plane</td>
</tr>
<tr>
<td colspan="2">--pod-network-cidr string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The range of IP addresses used for the Pod network</td>
</tr>
<tr>
<td colspan="2">--scheduler-extra-args mapStringString</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">A set of extra flags to pass to the Scheduler or override default ones in form of &lt;flagname&gt;=&lt;value&gt;</td>
</tr>
<tr>
<td colspan="2">--service-cidr string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "10.96.0.0/12"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The range of IP address used for service VIPs</td>
</tr>
</tbody>
</table>
@@ -0,0 +1,91 @@
Generates the API server static Pod manifest.
### Synopsis
Generates the static Pod manifest file for the API server and saves it into /etc/kubernetes/manifests/kube-apiserver.yaml file.
Alpha Disclaimer: this command is currently alpha.
```
kubeadm alpha phase controlplane apiserver [flags]
```
### Options
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--apiserver-advertise-address string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The IP address of the API server is accessible on</td>
</tr>
<tr>
<td colspan="2">--apiserver-bind-port int32&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 6443</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The port the API server is accessible on</td>
</tr>
<tr>
<td colspan="2">--apiserver-extra-args mapStringString</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">A set of extra flags to pass to the API Server or override default ones in form of &lt;flagname&gt;=&lt;value&gt;</td>
</tr>
<tr>
<td colspan="2">--cert-dir string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/pki"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The path where certificates are stored</td>
</tr>
<tr>
<td colspan="2">--config string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Path to kubeadm config file (WARNING: Usage of a configuration file is experimental)</td>
</tr>
<tr>
<td colspan="2">--feature-gates string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">A set of key=value pairs that describe feature gates for various features. Options are:<br/>Auditing=true|false (ALPHA - default=false)<br/>CoreDNS=true|false (BETA - default=false)<br/>DynamicKubeletConfig=true|false (ALPHA - default=false)<br/>SelfHosting=true|false (ALPHA - default=false)<br/>StoreCertsInSecrets=true|false (ALPHA - default=false)</td>
</tr>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">help for apiserver</td>
</tr>
<tr>
<td colspan="2">--kubernetes-version string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "stable-1.10"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Choose a specific Kubernetes version for the control plane</td>
</tr>
<tr>
<td colspan="2">--service-cidr string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "10.96.0.0/12"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The range of IP address used for service VIPs</td>
</tr>
</tbody>
</table>
@@ -0,0 +1,70 @@
Generates the controller-manager static Pod manifest.
### Synopsis
Generates the static Pod manifest file for the controller-manager and saves it into /etc/kubernetes/manifests/kube-controller-manager.yaml file.
Alpha Disclaimer: this command is currently alpha.
```
kubeadm alpha phase controlplane controller-manager [flags]
```
### Options
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--cert-dir string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/pki"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The path where certificates are stored</td>
</tr>
<tr>
<td colspan="2">--config string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Path to kubeadm config file (WARNING: Usage of a configuration file is experimental)</td>
</tr>
<tr>
<td colspan="2">--controller-manager-extra-args mapStringString</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">A set of extra flags to pass to the Controller Manager or override default ones in form of &lt;flagname&gt;=&lt;value&gt;</td>
</tr>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">help for controller-manager</td>
</tr>
<tr>
<td colspan="2">--kubernetes-version string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "stable-1.10"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Choose a specific Kubernetes version for the control plane</td>
</tr>
<tr>
<td colspan="2">--pod-network-cidr string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The range of IP addresses used for the Pod network</td>
</tr>
</tbody>
</table>
@@ -0,0 +1,63 @@
Generates the scheduler static Pod manifest.
### Synopsis
Generates the static Pod manifest file for the scheduler and saves it into /etc/kubernetes/manifests/kube-scheduler.yaml file.
Alpha Disclaimer: this command is currently alpha.
```
kubeadm alpha phase controlplane scheduler [flags]
```
### Options
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--cert-dir string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/pki"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The path where certificates are stored</td>
</tr>
<tr>
<td colspan="2">--config string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Path to kubeadm config file (WARNING: Usage of a configuration file is experimental)</td>
</tr>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">help for scheduler</td>
</tr>
<tr>
<td colspan="2">--kubernetes-version string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "stable-1.10"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Choose a specific Kubernetes version for the control plane</td>
</tr>
<tr>
<td colspan="2">--scheduler-extra-args mapStringString</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">A set of extra flags to pass to the Scheduler or override default ones in form of &lt;flagname&gt;=&lt;value&gt;</td>
</tr>
</tbody>
</table>
@@ -0,0 +1,29 @@
Generates static Pod manifest file for etcd.
### Synopsis
This command is not meant to be run on its own. See list of available subcommands.
### Options
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">help for etcd</td>
</tr>
</tbody>
</table>
@@ -0,0 +1,60 @@
Generates the static Pod manifest file for a local, single-node etcd instance
### Synopsis
Generates the static Pod manifest file for a local, single-node etcd instance and saves it to /etc/kubernetes/manifests/etcd.yaml file.
Alpha Disclaimer: this command is currently alpha.
```
kubeadm alpha phase etcd local [flags]
```
### Examples
```
# Generates the static Pod manifest file for etcd, functionally
# equivalent to what generated by kubeadm init.
kubeadm alpha phase etcd local
# Generates the static Pod manifest file for etcd.
kubeadm alpha phase etcd local --config masterconfiguration.yaml
```
### Options
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--cert-dir string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/pki"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The path where certificates are stored</td>
</tr>
<tr>
<td colspan="2">--config string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Path to kubeadm config file (WARNING: Usage of a configuration file is experimental)</td>
</tr>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">help for local</td>
</tr>
</tbody>
</table>
@@ -0,0 +1,29 @@
Generates all kubeconfig files necessary to establish the control plane and the admin kubeconfig file
### Synopsis
This command is not meant to be run on its own. See list of available subcommands.
### Options
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">help for kubeconfig</td>
</tr>
</tbody>
</table>
@@ -0,0 +1,70 @@
Generates a kubeconfig file for the admin to use and for kubeadm itself
### Synopsis
Generates the kubeconfig file for the admin and for kubeadm itself, and saves it to admin.conf file.
Alpha Disclaimer: this command is currently alpha.
```
kubeadm alpha phase kubeconfig admin [flags]
```
### Options
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--apiserver-advertise-address string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The IP address the API server is accessible on</td>
</tr>
<tr>
<td colspan="2">--apiserver-bind-port int32&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 6443</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The port the API server is accessible on</td>
</tr>
<tr>
<td colspan="2">--cert-dir string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/pki"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The path where certificates are stored</td>
</tr>
<tr>
<td colspan="2">--config string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Path to kubeadm config file (WARNING: Usage of a configuration file is experimental)</td>
</tr>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">help for admin</td>
</tr>
<tr>
<td colspan="2">--kubeconfig-dir string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The port where to save the kubeconfig file</td>
</tr>
</tbody>
</table>
@@ -0,0 +1,88 @@
Generates all kubeconfig files necessary to establish the control plane and the admin kubeconfig file
### Synopsis
Generates all kubeconfig files necessary to establish the control plane and the admin kubeconfig file.
Alpha Disclaimer: this command is currently alpha.
```
kubeadm alpha phase kubeconfig all [flags]
```
### Examples
```
# Generates all kubeconfig files, functionally equivalent to what generated
# by kubeadm init.
kubeadm alpha phase kubeconfig all
# Generates all kubeconfig files using options read from a configuration file.
kubeadm alpha phase kubeconfig all --config masterconfiguration.yaml
```
### Options
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--apiserver-advertise-address string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The IP address the API server is accessible on</td>
</tr>
<tr>
<td colspan="2">--apiserver-bind-port int32&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 6443</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The port the API server is accessible on</td>
</tr>
<tr>
<td colspan="2">--cert-dir string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/pki"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The path where certificates are stored</td>
</tr>
<tr>
<td colspan="2">--config string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Path to kubeadm config file (WARNING: Usage of a configuration file is experimental)</td>
</tr>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">help for all</td>
</tr>
<tr>
<td colspan="2">--kubeconfig-dir string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The port where to save the kubeconfig file</td>
</tr>
<tr>
<td colspan="2">--node-name string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The node name that should be used for the kubelet client certificate</td>
</tr>
</tbody>
</table>
@@ -0,0 +1,70 @@
Generates a kubeconfig file for the controller manager to use
### Synopsis
Generates the kubeconfig file for the controller manager to use and saves it to /etc/kubernetes/controller-manager.conf file.
Alpha Disclaimer: this command is currently alpha.
```
kubeadm alpha phase kubeconfig controller-manager [flags]
```
### Options
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--apiserver-advertise-address string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The IP address the API server is accessible on</td>
</tr>
<tr>
<td colspan="2">--apiserver-bind-port int32&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 6443</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The port the API server is accessible on</td>
</tr>
<tr>
<td colspan="2">--cert-dir string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/pki"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The path where certificates are stored</td>
</tr>
<tr>
<td colspan="2">--config string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Path to kubeadm config file (WARNING: Usage of a configuration file is experimental)</td>
</tr>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">help for controller-manager</td>
</tr>
<tr>
<td colspan="2">--kubeconfig-dir string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The port where to save the kubeconfig file</td>
</tr>
</tbody>
</table>
@@ -0,0 +1,79 @@
Generates a kubeconfig file for the kubelet to use. Please note that this should be used *only* for bootstrapping purposes.
### Synopsis
Generates the kubeconfig file for the kubelet to use and saves it to /etc/kubernetes/kubelet.conf file.
Please note that this should only be used for bootstrapping purposes. After your control plane is up, you should request all kubelet credentials from the CSR API.
Alpha Disclaimer: this command is currently alpha.
```
kubeadm alpha phase kubeconfig kubelet [flags]
```
### Options
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--apiserver-advertise-address string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The IP address the API server is accessible on</td>
</tr>
<tr>
<td colspan="2">--apiserver-bind-port int32&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 6443</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The port the API server is accessible on</td>
</tr>
<tr>
<td colspan="2">--cert-dir string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/pki"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The path where certificates are stored</td>
</tr>
<tr>
<td colspan="2">--config string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Path to kubeadm config file (WARNING: Usage of a configuration file is experimental)</td>
</tr>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">help for kubelet</td>
</tr>
<tr>
<td colspan="2">--kubeconfig-dir string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The port where to save the kubeconfig file</td>
</tr>
<tr>
<td colspan="2">--node-name string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The node name that should be used for the kubelet client certificate</td>
</tr>
</tbody>
</table>
@@ -0,0 +1,70 @@
Generates a kubeconfig file for the scheduler to use
### Synopsis
Generates the kubeconfig file for the scheduler to use and saves it to /etc/kubernetes/scheduler.conf file.
Alpha Disclaimer: this command is currently alpha.
```
kubeadm alpha phase kubeconfig scheduler [flags]
```
### Options
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--apiserver-advertise-address string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The IP address the API server is accessible on</td>
</tr>
<tr>
<td colspan="2">--apiserver-bind-port int32&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 6443</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The port the API server is accessible on</td>
</tr>
<tr>
<td colspan="2">--cert-dir string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/pki"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The path where certificates are stored</td>
</tr>
<tr>
<td colspan="2">--config string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Path to kubeadm config file (WARNING: Usage of a configuration file is experimental)</td>
</tr>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">help for scheduler</td>
</tr>
<tr>
<td colspan="2">--kubeconfig-dir string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The port where to save the kubeconfig file</td>
</tr>
</tbody>
</table>
@@ -0,0 +1,84 @@
Outputs a kubeconfig file for an additional user
### Synopsis
Outputs a kubeconfig file for an additional user.
Alpha Disclaimer: this command is currently alpha.
```
kubeadm alpha phase kubeconfig user [flags]
```
### Examples
```
# Outputs a kubeconfig file for an additional user named foo
kubeadm alpha phase kubeconfig user --client-name=foo
```
### Options
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--apiserver-advertise-address string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The IP address the API server is accessible on</td>
</tr>
<tr>
<td colspan="2">--apiserver-bind-port int32&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 6443</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The port the API server is accessible on</td>
</tr>
<tr>
<td colspan="2">--cert-dir string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/pki"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The path where certificates are stored</td>
</tr>
<tr>
<td colspan="2">--client-name string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The name of user. It will be used as the CN if client certificates are created</td>
</tr>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">help for user</td>
</tr>
<tr>
<td colspan="2">--kubeconfig-dir string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The port where to save the kubeconfig file</td>
</tr>
<tr>
<td colspan="2">--token string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The token that should be used as the authentication mechanism for this kubeconfig (instead of client certificates)</td>
</tr>
</tbody>
</table>
@@ -0,0 +1,66 @@
Mark a node as master
### Synopsis
Applies a label that specifies that a node is a master and a taint that forces workloads to be deployed accordingly.
Alpha Disclaimer: this command is currently alpha.
```
kubeadm alpha phase mark-master [flags]
```
### Examples
```
# Applies master label and taint to the current node, functionally equivalent to what executed by kubeadm init.
kubeadm alpha phase mark-master
# Applies master label and taint to a specific node
kubeadm alpha phase mark-master --node-name myNode
```
### Options
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--config string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Path to kubeadm config file (WARNING: Usage of a configuration file is experimental)</td>
</tr>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">help for mark-master</td>
</tr>
<tr>
<td colspan="2">--kubeconfig string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/admin.conf"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The KubeConfig file to use when talking to the cluster</td>
</tr>
<tr>
<td colspan="2">--node-name string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The node name to which label and taints should apply</td>
</tr>
</tbody>
</table>
@@ -0,0 +1,29 @@
Run pre-flight checks
### Synopsis
This command is not meant to be run on its own. See list of available subcommands.
### Options
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">help for preflight</td>
</tr>
</tbody>
</table>
@@ -0,0 +1,42 @@
Run master pre-flight checks
### Synopsis
Run master pre-flight checks, functionally equivalent to what implemented by kubeadm init.
Alpha Disclaimer: this command is currently alpha.
```
kubeadm alpha phase preflight master [flags]
```
### Examples
```
# Run master pre-flight checks.
kubeadm alpha phase preflight master
```
### Options
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">help for master</td>
</tr>
</tbody>
</table>
@@ -0,0 +1,42 @@
Run node pre-flight checks
### Synopsis
Run node pre-flight checks, functionally equivalent to what implemented by kubeadm join.
Alpha Disclaimer: this command is currently alpha.
```
kubeadm alpha phase preflight node [flags]
```
### Examples
```
# Run node pre-flight checks.
kubeadm alpha phase preflight node
```
### Options
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">help for node</td>
</tr>
</tbody>
</table>
@@ -0,0 +1,29 @@
Makes a kubeadm cluster self-hosted
### Synopsis
This command is not meant to be run on its own. See list of available subcommands.
### Options
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">help for selfhosting</td>
</tr>
</tbody>
</table>
@@ -0,0 +1,75 @@
Converts a static Pod-hosted control plane into a self-hosted one
### Synopsis
Converts static Pod files for control plane components into self-hosted DaemonSets configured via the Kubernetes API.
See the documentation for self-hosting limitations.
Alpha Disclaimer: this command is currently alpha.
```
kubeadm alpha phase selfhosting convert-from-staticpods [flags]
```
### Examples
```
# Converts a static Pod-hosted control plane into a self-hosted one,
# functionally equivalent to what generated by kubeadm init executed
# with --feature-gates=SelfHosting=true.
kubeadm alpha phase selfhosting convert-from-staticpods
```
### Options
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--cert-dir string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/pki"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The path where certificates are stored</td>
</tr>
<tr>
<td colspan="2">--config string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Path to a kubeadm config file. WARNING: Usage of a configuration file is experimental!</td>
</tr>
<tr>
<td colspan="2">--feature-gates string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">A set of key=value pairs that describe feature gates for various features. Options are:<br/>Auditing=true|false (ALPHA - default=false)<br/>CoreDNS=true|false (BETA - default=false)<br/>DynamicKubeletConfig=true|false (ALPHA - default=false)<br/>SelfHosting=true|false (ALPHA - default=false)<br/>StoreCertsInSecrets=true|false (ALPHA - default=false)</td>
</tr>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">help for convert-from-staticpods</td>
</tr>
<tr>
<td colspan="2">--kubeconfig string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/admin.conf"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The KubeConfig file to use when talking to the cluster</td>
</tr>
</tbody>
</table>
@@ -0,0 +1,58 @@
Uploads the currently used configuration for kubeadm to a ConfigMap
### Synopsis
Uploads the kubeadm init configuration of your cluster to a ConfigMap called kubeadm-config in the kube-system namespace. This enables correct configuration of system components and a seamless user experience when upgrading.
Alternatively, you can use kubeadm config.
Alpha Disclaimer: this command is currently alpha.
```
kubeadm alpha phase upload-config [flags]
```
### Examples
```
# uploads the configuration of your cluster
kubeadm alpha phase upload-config --config=myConfig.yaml
```
### Options
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--config string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Path to a kubeadm config file. WARNING: Usage of a configuration file is experimental!</td>
</tr>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">help for upload-config</td>
</tr>
<tr>
<td colspan="2">--kubeconfig string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/admin.conf"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The KubeConfig file to use when talking to the cluster</td>
</tr>
</tbody>
</table>
@@ -0,0 +1,70 @@
Output shell completion code for the specified shell (bash or zsh).
### Synopsis
Output shell completion code for the specified shell (bash or zsh).
The shell code must be evaluated to provide interactive
completion of kubeadm commands. This can be done by sourcing it from
the .bash_profile.
Note: this requires the bash-completion framework, which is not installed
by default on Mac. This can be installed by using homebrew:
$ brew install bash-completion
Once installed, bash_completion must be evaluated. This can be done by adding the
following line to the .bash_profile
$ source $(brew --prefix)/etc/bash_completion
Note for zsh users: [1] zsh completions are only supported in versions of zsh >= 5.2
```
kubeadm completion SHELL [flags]
```
### Examples
```
# Install bash completion on a Mac using homebrew
brew install bash-completion
printf "\n# Bash completion support\nsource $(brew --prefix)/etc/bash_completion\n" >> $HOME/.bash_profile
source $HOME/.bash_profile
# Load the kubeadm completion code for bash into the current shell
source <(kubeadm completion bash)
# Write bash completion code to a file and source if from .bash_profile
kubeadm completion bash > ~/.kube/kubeadm_completion.bash.inc
printf "\n# Kubeadm shell completion\nsource '$HOME/.kube/kubeadm_completion.bash.inc'\n" >> $HOME/.bash_profile
source $HOME/.bash_profile
# Load the kubeadm completion code for zsh[1] into the current shell
source <(kubeadm completion zsh)
```
### Options
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">help for completion</td>
</tr>
</tbody>
</table>
@@ -0,0 +1,45 @@
Manage configuration for a kubeadm cluster persisted in a ConfigMap in the cluster.
### Synopsis
There is a ConfigMap in the kube-system namespace called "kubeadm-config" that kubeadm uses to store internal configuration about the
cluster. kubeadm CLI v1.8.0+ automatically creates this ConfigMap with the config used with 'kubeadm init', but if you
initialized your cluster using kubeadm v1.7.x or lower, you must use the 'config upload' command to create this
ConfigMap. This is required so that 'kubeadm upgrade' can configure your upgraded cluster correctly.
```
kubeadm config [flags]
```
### Options
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">help for config</td>
</tr>
<tr>
<td colspan="2">--kubeconfig string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/admin.conf"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The KubeConfig file to use when talking to the cluster.</td>
</tr>
</tbody>
</table>
@@ -0,0 +1,54 @@
Upload configuration about the current state, so that 'kubeadm upgrade' can later know how to configure the upgraded cluster.
### Synopsis
Upload configuration about the current state, so that 'kubeadm upgrade' can later know how to configure the upgraded cluster.
```
kubeadm config upload [flags]
```
### Options
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">help for upload</td>
</tr>
</tbody>
</table>
### Options inherited from parent commands
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--kubeconfig string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/admin.conf"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The KubeConfig file to use when talking to the cluster.</td>
</tr>
</tbody>
</table>
@@ -0,0 +1,67 @@
Upload a configuration file to the in-cluster ConfigMap for kubeadm configuration.
### Synopsis
Using this command, you can upload configuration to the ConfigMap in the cluster using the same config file you gave to 'kubeadm init'.
If you initialized your cluster using a v1.7.x or lower kubeadm client and used the --config option, you need to run this command with the
same config file before upgrading to v1.8 using 'kubeadm upgrade'.
The configuration is located in the "kube-system" namespace in the "kubeadm-config" ConfigMap.
```
kubeadm config upload from-file [flags]
```
### Options
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--config string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Path to a kubeadm config file. WARNING: Usage of a configuration file is experimental.</td>
</tr>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">help for from-file</td>
</tr>
</tbody>
</table>
### Options inherited from parent commands
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--kubeconfig string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/admin.conf"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The KubeConfig file to use when talking to the cluster.</td>
</tr>
</tbody>
</table>
@@ -0,0 +1,151 @@
Create the in-cluster configuration file for the first time from using flags.
### Synopsis
Using this command, you can upload configuration to the ConfigMap in the cluster using the same flags you gave to 'kubeadm init'.
If you initialized your cluster using a v1.7.x or lower kubeadm client and set certain flags, you need to run this command with the
same flags before upgrading to v1.8 using 'kubeadm upgrade'.
The configuration is located in the "kube-system" namespace in the "kubeadm-config" ConfigMap.
```
kubeadm config upload from-flags [flags]
```
### Options
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--apiserver-advertise-address string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The IP address the API Server will advertise it's listening on. Specify '0.0.0.0' to use the address of the default network interface.</td>
</tr>
<tr>
<td colspan="2">--apiserver-bind-port int32&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 6443</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Port for the API Server to bind to.</td>
</tr>
<tr>
<td colspan="2">--apiserver-cert-extra-sans stringSlice</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Optional extra Subject Alternative Names (SANs) to use for the API Server serving certificate. Can be both IP addresses and DNS names.</td>
</tr>
<tr>
<td colspan="2">--cert-dir string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/pki"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The path where to save and store the certificates.</td>
</tr>
<tr>
<td colspan="2">--cri-socket string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/var/run/dockershim.sock"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Specify the CRI socket to connect to.</td>
</tr>
<tr>
<td colspan="2">--feature-gates string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">A set of key=value pairs that describe feature gates for various features. Options are:<br/>Auditing=true|false (ALPHA - default=false)<br/>CoreDNS=true|false (BETA - default=false)<br/>DynamicKubeletConfig=true|false (ALPHA - default=false)<br/>SelfHosting=true|false (ALPHA - default=false)<br/>StoreCertsInSecrets=true|false (ALPHA - default=false)</td>
</tr>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">help for from-flags</td>
</tr>
<tr>
<td colspan="2">--kubernetes-version string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "stable-1.10"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Choose a specific Kubernetes version for the control plane.</td>
</tr>
<tr>
<td colspan="2">--node-name string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Specify the node name.</td>
</tr>
<tr>
<td colspan="2">--pod-network-cidr string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Specify range of IP addresses for the pod network. If set, the control plane will automatically allocate CIDRs for every node.</td>
</tr>
<tr>
<td colspan="2">--service-cidr string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "10.96.0.0/12"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Use alternative range of IP address for service VIPs.</td>
</tr>
<tr>
<td colspan="2">--service-dns-domain string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "cluster.local"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Use alternative domain for services, e.g. "myorg.internal".</td>
</tr>
<tr>
<td colspan="2">--token string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The token to use for establishing bidirectional trust between nodes and masters.</td>
</tr>
<tr>
<td colspan="2">--token-ttl duration&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 24h0m0s</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The duration before the bootstrap token is automatically deleted. If set to '0', the token will never expire.</td>
</tr>
</tbody>
</table>
### Options inherited from parent commands
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--kubeconfig string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/admin.conf"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The KubeConfig file to use when talking to the cluster.</td>
</tr>
</tbody>
</table>
@@ -0,0 +1,58 @@
View the kubeadm configuration stored inside the cluster.
### Synopsis
Using this command, you can view the ConfigMap in the cluster where the configuration for kubeadm is located.
The configuration is located in the "kube-system" namespace in the "kubeadm-config" ConfigMap.
```
kubeadm config view [flags]
```
### Options
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">help for view</td>
</tr>
</tbody>
</table>
### Options inherited from parent commands
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--kubeconfig string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/admin.conf"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The KubeConfig file to use when talking to the cluster.</td>
</tr>
</tbody>
</table>
@@ -0,0 +1,152 @@
Run this command in order to set up the Kubernetes master.
### Synopsis
Run this command in order to set up the Kubernetes master.
```
kubeadm init [flags]
```
### Options
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--apiserver-advertise-address string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The IP address the API Server will advertise it's listening on. Specify '0.0.0.0' to use the address of the default network interface.</td>
</tr>
<tr>
<td colspan="2">--apiserver-bind-port int32&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 6443</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Port for the API Server to bind to.</td>
</tr>
<tr>
<td colspan="2">--apiserver-cert-extra-sans stringSlice</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Optional extra Subject Alternative Names (SANs) to use for the API Server serving certificate. Can be both IP addresses and DNS names.</td>
</tr>
<tr>
<td colspan="2">--cert-dir string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/pki"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The path where to save and store the certificates.</td>
</tr>
<tr>
<td colspan="2">--config string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Path to kubeadm config file. WARNING: Usage of a configuration file is experimental.</td>
</tr>
<tr>
<td colspan="2">--cri-socket string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/var/run/dockershim.sock"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Specify the CRI socket to connect to.</td>
</tr>
<tr>
<td colspan="2">--dry-run</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Don't apply any changes; just output what would be done.</td>
</tr>
<tr>
<td colspan="2">--feature-gates string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">A set of key=value pairs that describe feature gates for various features. Options are:<br/>Auditing=true|false (ALPHA - default=false)<br/>CoreDNS=true|false (BETA - default=false)<br/>DynamicKubeletConfig=true|false (ALPHA - default=false)<br/>SelfHosting=true|false (ALPHA - default=false)<br/>StoreCertsInSecrets=true|false (ALPHA - default=false)</td>
</tr>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">help for init</td>
</tr>
<tr>
<td colspan="2">--ignore-preflight-errors stringSlice</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">A list of checks whose errors will be shown as warnings. Example: 'IsPrivilegedUser,Swap'. Value 'all' ignores errors from all checks.</td>
</tr>
<tr>
<td colspan="2">--kubernetes-version string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "stable-1.10"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Choose a specific Kubernetes version for the control plane.</td>
</tr>
<tr>
<td colspan="2">--node-name string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Specify the node name.</td>
</tr>
<tr>
<td colspan="2">--pod-network-cidr string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Specify range of IP addresses for the pod network. If set, the control plane will automatically allocate CIDRs for every node.</td>
</tr>
<tr>
<td colspan="2">--service-cidr string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "10.96.0.0/12"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Use alternative range of IP address for service VIPs.</td>
</tr>
<tr>
<td colspan="2">--service-dns-domain string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "cluster.local"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Use alternative domain for services, e.g. "myorg.internal".</td>
</tr>
<tr>
<td colspan="2">--skip-token-print</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Skip printing of the default bootstrap token generated by 'kubeadm init'.</td>
</tr>
<tr>
<td colspan="2">--token string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The token to use for establishing bidirectional trust between nodes and masters.</td>
</tr>
<tr>
<td colspan="2">--token-ttl duration&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 24h0m0s</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The duration before the bootstrap token is automatically deleted. If set to '0', the token will never expire.</td>
</tr>
</tbody>
</table>
@@ -0,0 +1,151 @@
Run this on any machine you wish to join an existing cluster
### Synopsis
When joining a kubeadm initialized cluster, we need to establish
bidirectional trust. This is split into discovery (having the Node
trust the Kubernetes Master) and TLS bootstrap (having the Kubernetes
Master trust the Node).
There are 2 main schemes for discovery. The first is to use a shared
token along with the IP address of the API server. The second is to
provide a file - a subset of the standard kubeconfig file. This file
can be a local file or downloaded via an HTTPS URL. The forms are
kubeadm join --discovery-token abcdef.1234567890abcdef 1.2.3.4:6443,
kubeadm join --discovery-file path/to/file.conf, or kubeadm join
--discovery-file https://url/file.conf. Only one form can be used. If
the discovery information is loaded from a URL, HTTPS must be used.
Also, in that case the host installed CA bundle is used to verify
the connection.
If you use a shared token for discovery, you should also pass the
--discovery-token-ca-cert-hash flag to validate the public key of the
root certificate authority (CA) presented by the Kubernetes Master. The
value of this flag is specified as "<hash-type>:<hex-encoded-value>",
where the supported hash type is "sha256". The hash is calculated over
the bytes of the Subject Public Key Info (SPKI) object (as in RFC7469).
This value is available in the output of "kubeadm init" or can be
calcuated using standard tools. The --discovery-token-ca-cert-hash flag
may be repeated multiple times to allow more than one public key.
If you cannot know the CA public key hash ahead of time, you can pass
the --discovery-token-unsafe-skip-ca-verification flag to disable this
verification. This weakens the kubeadm security model since other nodes
can potentially impersonate the Kubernetes Master.
The TLS bootstrap mechanism is also driven via a shared token. This is
used to temporarily authenticate with the Kubernetes Master to submit a
certificate signing request (CSR) for a locally created key pair. By
default, kubeadm will set up the Kubernetes Master to automatically
approve these signing requests. This token is passed in with the
--tls-bootstrap-token abcdef.1234567890abcdef flag.
Often times the same token is used for both parts. In this case, the
--token flag can be used instead of specifying each token individually.
```
kubeadm join [flags]
```
### Options
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--config string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Path to kubeadm config file.</td>
</tr>
<tr>
<td colspan="2">--cri-socket string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/var/run/dockershim.sock"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Specify the CRI socket to connect to.</td>
</tr>
<tr>
<td colspan="2">--discovery-file string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">A file or url from which to load cluster information.</td>
</tr>
<tr>
<td colspan="2">--discovery-token string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">A token used to validate cluster information fetched from the master.</td>
</tr>
<tr>
<td colspan="2">--discovery-token-ca-cert-hash stringSlice</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">For token-based discovery, validate that the root CA public key matches this hash (format: "&lt;type&gt;:&lt;value&gt;").</td>
</tr>
<tr>
<td colspan="2">--discovery-token-unsafe-skip-ca-verification</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">For token-based discovery, allow joining without --discovery-token-ca-cert-hash pinning.</td>
</tr>
<tr>
<td colspan="2">--feature-gates string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">A set of key=value pairs that describe feature gates for various features. Options are:<br/>Auditing=true|false (ALPHA - default=false)<br/>CoreDNS=true|false (BETA - default=false)<br/>DynamicKubeletConfig=true|false (ALPHA - default=false)<br/>SelfHosting=true|false (ALPHA - default=false)<br/>StoreCertsInSecrets=true|false (ALPHA - default=false)</td>
</tr>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">help for join</td>
</tr>
<tr>
<td colspan="2">--ignore-preflight-errors stringSlice</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">A list of checks whose errors will be shown as warnings. Example: 'IsPrivilegedUser,Swap'. Value 'all' ignores errors from all checks.</td>
</tr>
<tr>
<td colspan="2">--node-name string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Specify the node name.</td>
</tr>
<tr>
<td colspan="2">--tls-bootstrap-token string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">A token used for TLS bootstrapping.</td>
</tr>
<tr>
<td colspan="2">--token string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Use this token for both discovery-token and tls-bootstrap-token.</td>
</tr>
</tbody>
</table>
@@ -0,0 +1,54 @@
Run this to revert any changes made to this host by 'kubeadm init' or 'kubeadm join'.
### Synopsis
Run this to revert any changes made to this host by 'kubeadm init' or 'kubeadm join'.
```
kubeadm reset [flags]
```
### Options
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--cert-dir string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/pki"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The path to the directory where the certificates are stored. If specified, clean this directory.</td>
</tr>
<tr>
<td colspan="2">--cri-socket string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/var/run/dockershim.sock"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The path to the CRI socket to use with crictl when cleaning up containers.</td>
</tr>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">help for reset</td>
</tr>
<tr>
<td colspan="2">--ignore-preflight-errors stringSlice</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">A list of checks whose errors will be shown as warnings. Example: 'IsPrivilegedUser,Swap'. Value 'all' ignores errors from all checks.</td>
</tr>
</tbody>
</table>
@@ -0,0 +1,64 @@
Manage bootstrap tokens.
### Synopsis
This command manages bootstrap tokens. It is optional and needed only for advanced use cases.
In short, bootstrap tokens are used for establishing bidirectional trust between a client and a server.
A bootstrap token can be used when a client (for example a node that is about to join the cluster) needs
to trust the server it is talking to. Then a bootstrap token with the "signing" usage can be used.
bootstrap tokens can also function as a way to allow short-lived authentication to the API Server
(the token serves as a way for the API Server to trust the client), for example for doing the TLS Bootstrap.
What is a bootstrap token more exactly?
- It is a Secret in the kube-system namespace of type "bootstrap.kubernetes.io/token".
- A bootstrap token must be of the form "[a-z0-9]{6}.[a-z0-9]{16}". The former part is the public token ID,
while the latter is the Token Secret and it must be kept private at all circumstances!
- The name of the Secret must be named "bootstrap-token-(token-id)".
You can read more about bootstrap tokens here:
https://kubernetes.io/docs/admin/bootstrap-tokens/
```
kubeadm token [flags]
```
### Options
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--dry-run</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Whether to enable dry-run mode or not</td>
</tr>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">help for token</td>
</tr>
<tr>
<td colspan="2">--kubeconfig string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/admin.conf"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The KubeConfig file to use when talking to the cluster</td>
</tr>
</tbody>
</table>
@@ -0,0 +1,110 @@
Create bootstrap tokens on the server.
### Synopsis
This command will create a bootstrap token for you.
You can specify the usages for this token, the "time to live" and an optional human friendly description.
The [token] is the actual token to write.
This should be a securely generated random token of the form "[a-z0-9]{6}.[a-z0-9]{16}".
If no [token] is given, kubeadm will generate a random token instead.
```
kubeadm token create [token]
```
### Options
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--config string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Path to kubeadm config file (WARNING: Usage of a configuration file is experimental)</td>
</tr>
<tr>
<td colspan="2">--description string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">A human friendly description of how this token is used.</td>
</tr>
<tr>
<td colspan="2">--groups stringSlice&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: [system:bootstrappers:kubeadm:default-node-token]</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Extra groups that this token will authenticate as when used for authentication. Must match "system:bootstrappers:[a-z0-9:-]{0,255}[a-z0-9]".</td>
</tr>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">help for create</td>
</tr>
<tr>
<td colspan="2">--print-join-command</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Instead of printing only the token, print the full 'kubeadm join' flag needed to join the cluster using the token.</td>
</tr>
<tr>
<td colspan="2">--ttl duration&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 24h0m0s</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The duration before the token is automatically deleted (e.g. 1s, 2m, 3h). If set to '0', the token will never expire.</td>
</tr>
<tr>
<td colspan="2">--usages stringSlice&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: [signing,authentication]</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Describes the ways in which this token can be used. You can pass --usages multiple times or provide a comma separated list of options. Valid options: [signing,authentication].</td>
</tr>
</tbody>
</table>
### Options inherited from parent commands
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--dry-run</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Whether to enable dry-run mode or not</td>
</tr>
<tr>
<td colspan="2">--kubeconfig string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/admin.conf"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The KubeConfig file to use when talking to the cluster</td>
</tr>
</tbody>
</table>
@@ -0,0 +1,66 @@
Delete bootstrap tokens on the server.
### Synopsis
This command will delete a given bootstrap token for you.
The [token-value] is the full Token of the form "[a-z0-9]{6}.[a-z0-9]{16}" or the
Token ID of the form "[a-z0-9]{6}" to delete.
```
kubeadm token delete [token-value]
```
### Options
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">help for delete</td>
</tr>
</tbody>
</table>
### Options inherited from parent commands
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--dry-run</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Whether to enable dry-run mode or not</td>
</tr>
<tr>
<td colspan="2">--kubeconfig string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/admin.conf"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The KubeConfig file to use when talking to the cluster</td>
</tr>
</tbody>
</table>
@@ -0,0 +1,71 @@
Generate and print a bootstrap token, but do not create it on the server.
### Synopsis
This command will print out a randomly-generated bootstrap token that can be used with
the "init" and "join" commands.
You don't have to use this command in order to generate a token. You can do so
yourself as long as it is in the format "[a-z0-9]{6}.[a-z0-9]{16}". This
command is provided for convenience to generate tokens in the given format.
You can also use "kubeadm init" without specifying a token and it will
generate and print one for you.
```
kubeadm token generate [flags]
```
### Options
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">help for generate</td>
</tr>
</tbody>
</table>
### Options inherited from parent commands
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--dry-run</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Whether to enable dry-run mode or not</td>
</tr>
<tr>
<td colspan="2">--kubeconfig string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/admin.conf"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The KubeConfig file to use when talking to the cluster</td>
</tr>
</tbody>
</table>
@@ -0,0 +1,63 @@
List bootstrap tokens on the server.
### Synopsis
This command will list all bootstrap tokens for you.
```
kubeadm token list [flags]
```
### Options
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">help for list</td>
</tr>
</tbody>
</table>
### Options inherited from parent commands
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--dry-run</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Whether to enable dry-run mode or not</td>
</tr>
<tr>
<td colspan="2">--kubeconfig string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/admin.conf"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The KubeConfig file to use when talking to the cluster</td>
</tr>
</tbody>
</table>
@@ -0,0 +1,82 @@
Upgrade your cluster smoothly to a newer version with this command.
### Synopsis
Upgrade your cluster smoothly to a newer version with this command.
```
kubeadm upgrade [flags]
```
### Options
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--allow-experimental-upgrades</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Show unstable versions of Kubernetes as an upgrade alternative and allow upgrading to an alpha/beta/release candidate versions of Kubernetes.</td>
</tr>
<tr>
<td colspan="2">--allow-release-candidate-upgrades</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Show release candidate versions of Kubernetes as an upgrade alternative and allow upgrading to a release candidate versions of Kubernetes.</td>
</tr>
<tr>
<td colspan="2">--config string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Path to kubeadm config file. WARNING: Usage of a configuration file is experimental!</td>
</tr>
<tr>
<td colspan="2">--feature-gates string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">A set of key=value pairs that describe feature gates for various features.Options are:<br/>Auditing=true|false (ALPHA - default=false)<br/>CoreDNS=true|false (BETA - default=false)<br/>DynamicKubeletConfig=true|false (ALPHA - default=false)<br/>SelfHosting=true|false (ALPHA - default=false)<br/>StoreCertsInSecrets=true|false (ALPHA - default=false)</td>
</tr>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">help for upgrade</td>
</tr>
<tr>
<td colspan="2">--ignore-preflight-errors stringSlice</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">A list of checks whose errors will be shown as warnings. Example: 'IsPrivilegedUser,Swap'. Value 'all' ignores errors from all checks.</td>
</tr>
<tr>
<td colspan="2">--kubeconfig string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/admin.conf"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The KubeConfig file to use when talking to the cluster.</td>
</tr>
<tr>
<td colspan="2">--print-config</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Specifies whether the configuration file that will be used in the upgrade should be printed or not.</td>
</tr>
</tbody>
</table>
@@ -0,0 +1,131 @@
Upgrade your Kubernetes cluster to the specified version.
### Synopsis
Upgrade your Kubernetes cluster to the specified version.
```
kubeadm upgrade apply [version]
```
### Options
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--dry-run</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Do not change any state, just output what actions would be performed.</td>
</tr>
<tr>
<td colspan="2">--etcd-upgrade&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: true</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Perform the upgrade of etcd.</td>
</tr>
<tr>
<td colspan="2">-f, --force</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Force upgrading although some requirements might not be met. This also implies non-interactive mode.</td>
</tr>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">help for apply</td>
</tr>
<tr>
<td colspan="2">--image-pull-timeout duration&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 15m0s</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The maximum amount of time to wait for the control plane pods to be downloaded.</td>
</tr>
<tr>
<td colspan="2">-y, --yes</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Perform the upgrade and do not prompt for confirmation (non-interactive mode).</td>
</tr>
</tbody>
</table>
### Options inherited from parent commands
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--allow-experimental-upgrades</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Show unstable versions of Kubernetes as an upgrade alternative and allow upgrading to an alpha/beta/release candidate versions of Kubernetes.</td>
</tr>
<tr>
<td colspan="2">--allow-release-candidate-upgrades</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Show release candidate versions of Kubernetes as an upgrade alternative and allow upgrading to a release candidate versions of Kubernetes.</td>
</tr>
<tr>
<td colspan="2">--config string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Path to kubeadm config file. WARNING: Usage of a configuration file is experimental!</td>
</tr>
<tr>
<td colspan="2">--feature-gates string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">A set of key=value pairs that describe feature gates for various features.Options are:<br/>Auditing=true|false (ALPHA - default=false)<br/>CoreDNS=true|false (BETA - default=false)<br/>DynamicKubeletConfig=true|false (ALPHA - default=false)<br/>SelfHosting=true|false (ALPHA - default=false)<br/>StoreCertsInSecrets=true|false (ALPHA - default=false)</td>
</tr>
<tr>
<td colspan="2">--ignore-preflight-errors stringSlice</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">A list of checks whose errors will be shown as warnings. Example: 'IsPrivilegedUser,Swap'. Value 'all' ignores errors from all checks.</td>
</tr>
<tr>
<td colspan="2">--kubeconfig string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/admin.conf"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The KubeConfig file to use when talking to the cluster.</td>
</tr>
<tr>
<td colspan="2">--print-config</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Specifies whether the configuration file that will be used in the upgrade should be printed or not.</td>
</tr>
</tbody>
</table>
@@ -0,0 +1,96 @@
Check which versions are available to upgrade to and validate whether your current cluster is upgradeable.
### Synopsis
Check which versions are available to upgrade to and validate whether your current cluster is upgradeable.
```
kubeadm upgrade plan [flags]
```
### Options
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">help for plan</td>
</tr>
</tbody>
</table>
### Options inherited from parent commands
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--allow-experimental-upgrades</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Show unstable versions of Kubernetes as an upgrade alternative and allow upgrading to an alpha/beta/release candidate versions of Kubernetes.</td>
</tr>
<tr>
<td colspan="2">--allow-release-candidate-upgrades</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Show release candidate versions of Kubernetes as an upgrade alternative and allow upgrading to a release candidate versions of Kubernetes.</td>
</tr>
<tr>
<td colspan="2">--config string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Path to kubeadm config file. WARNING: Usage of a configuration file is experimental!</td>
</tr>
<tr>
<td colspan="2">--feature-gates string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">A set of key=value pairs that describe feature gates for various features.Options are:<br/>Auditing=true|false (ALPHA - default=false)<br/>CoreDNS=true|false (BETA - default=false)<br/>DynamicKubeletConfig=true|false (ALPHA - default=false)<br/>SelfHosting=true|false (ALPHA - default=false)<br/>StoreCertsInSecrets=true|false (ALPHA - default=false)</td>
</tr>
<tr>
<td colspan="2">--ignore-preflight-errors stringSlice</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">A list of checks whose errors will be shown as warnings. Example: 'IsPrivilegedUser,Swap'. Value 'all' ignores errors from all checks.</td>
</tr>
<tr>
<td colspan="2">--kubeconfig string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/admin.conf"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">The KubeConfig file to use when talking to the cluster.</td>
</tr>
<tr>
<td colspan="2">--print-config</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Specifies whether the configuration file that will be used in the upgrade should be printed or not.</td>
</tr>
</tbody>
</table>
@@ -0,0 +1,40 @@
Print the version of kubeadm
### Synopsis
Print the version of kubeadm
```
kubeadm version [flags]
```
### Options
<table style="width: 100%;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">help for version</td>
</tr>
<tr>
<td colspan="2">-o, --output string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%">Output format; available options are 'yaml', 'json' and 'short'</td>
</tr>
</tbody>
</table>
@@ -0,0 +1,582 @@
---
approvers:
- mikedanese
- luxas
- jbeda
title: Implementation details
content_template: templates/concept
---
{{% capture overview %}}
`kubeadm init` and `kubeadm join` together provides a nice user experience for creating a best-practice but bare Kubernetes cluster from scratch.
However, it might not be obvious _how_ kubeadm does that.
This document provide additional details on what happen under the hood, with the aim of sharing knowledge on Kubernetes cluster best practices.
{{% /capture %}}
{{% capture body %}}
## Core design principles
The cluster that `kubeadm init` and `kubeadm join` set up should be:
- Secure:
- It should adopt latest best-practices like:
- enforcing RBAC
- using the Node Authorizer
- using secure communication between the control plane components
- using secure communication between the API server and the kubelets
- lock-down the kubelet API
- locking down access to the API for system components like the kube-proxy and kube-dns
- locking down what a Bootstrap Token can access
- etc.
- Easy to use:
- The user should not have to run anything more than a couple of commands:
- `kubeadm init`
- `export KUBECONFIG=/etc/kubernetes/admin.conf`
- `kubectl apply -f <network-of-choice.yaml>`
- `kubeadm join --token <token> <master-ip>:<master-port>`
- Extendable:
- It should for example _not_ favor any network provider, instead configuring a network is out-of-scope
- Should provide the possibility to use a config file for customizing various parameters
## Constants and well-known values and paths
In order to reduce complexity and to simplify development of an on-top-of-kubeadm-implemented deployment solution, kubeadm uses a
limited set of constants values for well know-known paths and file names.
The Kubernetes directory `/etc/kubernetes` is a constant in the application, since it is clearly the given path
in a majority of cases, and the most intuitive location; other constants paths and file names are:
- `/etc/kubernetes/manifests` as the path where kubelet should look for static Pod manifests. Names of static Pod manifests are:
- `etcd.yaml`
- `kube-apiserver.yaml`
- `kube-controller-manager.yaml`
- `kube-scheduler.yaml`
- `/etc/kubernetes/` as the path where kubeconfig files with identities for control plane components are stored. Names of kubeconfig files are:
- `kubelet.conf` (`bootstrap-kubelet.conf` during TLS bootstrap)
- `controller-manager.conf`
- `scheduler.conf`
- `admin.conf` for the cluster admin and kubeadm itself
- Names of certificates and key files :
- `ca.crt`, `ca.key` for the Kubernetes certificate authority
- `apiserver.crt`, `apiserver.key` for the API server certificate
- `apiserver-kubelet-client.crt`, `apiserver-kubelet-client.key` for the client certificate used by the API server to connect to the kubelets securely
- `sa.pub`, `sa.key` for the key used by the controller manager when signing ServiceAccount
- `front-proxy-ca.crt`, `front-proxy-ca.key` for the front proxy certificate authority
- `front-proxy-client.crt`, `front-proxy-client.key` for the front proxy client
## kubeadm init workflow internal design
The `kubeadm init` [internal workflow](kubeadm-init.md/#init-workflow) consists of a sequence of atomic work tasks to perform,
as described in `kubeadm init`.
The [`kubeadm alpha phase`](kubeadm-alpha.md) command allows users to invoke individually each task, and ultimately offers a reusable and composable
API/toolbox that can be used by other Kubernetes bootstrap tools, by any IT automation tool or by advanced user
for creating custom clusters.
### Preflight checks
Kubeadm executes a set of preflight checks before starting the init, with the aim to verify preconditions and avoid common cluster startup problems.
In any case the user can skip specific preflight checks (or eventually all preflight checks) with the `--ignore-preflight-errors` option.
- [warning] If the Kubernetes version to use (specified with the `--kubernetes-version` flag) is at least one minor version higher than the kubeadm CLI version
- Kubernetes system requirements:
- if running on linux:
- [error] if not Kernel 3.10+ or 4+ with specific KernelSpec
- [error] if required cgroups subsystem aren't in set up
- if using docker:
- [warning/error] if Docker service does not exists, if it is disabled, if it is not active.
- [error] if Docker endpoint does not exist or does not work
- [warning] if docker version >17.03
- If using other cri engine:
- [error] if crictl socket does not answer
- [error] if user is not root
- [error] if the machine hostname is not a valid DNS subdomain
- [warning] if the host name cannot be reached via network lookup
- [error] if kubelet version is lower that the minimum kubelet version supported by kubeadm (current minor -1)
- [error] if kubelet version is at least one minor higher than the required controlplane version (unsupported version skew)
- [warning] if kubelet service does not exist or if it is disabled
- [warning] if firewalld is active
- [error] if API server bindPort or ports 10250/10251/10252 are used
- [Error] if `/etc/kubernetes/manifest` folder already exists and it is not empty
- [Error] if `/proc/sys/net/bridge/bridge-nf-call-iptables` file does not exist/does not contain 1
- [Error] if advertise address is ipv6 and `/proc/sys/net/bridge/bridge-nf-call-ip6tables` does not exist/does not contain 1.
- [Error] if swap is on
- [Error] if `ip`, `iptables`, `mount`, `nsenter` commands are not present in the command path
- [warning] if `ebtables`, `ethtool`, `socat`, `tc`, `touch`, `crictl` commands are not present in the command path
- [warning] if extra arg flags for API server, controller manager, scheduler contains some invalid options
- [warning] if connection to https://API.AdvertiseAddress:API.BindPort goes thought proxy
- [warning] if connection to services subnet goes thought proxy (only first address checked)
- [warning] if connection to Pods subnet goes thought proxy (only first address checked)
- If external etcd is provided:
- [Error] if etcd version less than 3.0.14
- [Error] if etcd certificates or keys are specified, but not provided
- If external etcd is NOT provided (and thus local etcd will be installed):
- [Error] if ports 2379 is used
- [Error] if Etcd.DataDir folder already exists and it is not empty
- If authorization mode is ABAC:
- [Error] if abac_policy.json does not exist
- If authorization mode is WebHook
- [Error] if webhook_authz.conf does not exist
Please note that:
1. Preflight checks can be invoked individually with the [`kubeadm alpha phase preflight`](kubeadm-alpha.md/#cmd-phase-preflight) command
### Generate the necessary certificates
Kubeadm generates certificate and private key pairs for different purposes:
- A self signed certificate authority for the Kubernetes cluster saved into `ca.crt` file and `ca.key` private key file
- A serving certificate for the API server, generated using `ca.crt` as the CA, and saved into `apiserver.crt` file with
its private key `apiserver.key`. This certificate should contains following alternative names:
- The Kubernetes service's internal clusterIP (the first address in the services CIDR, e.g. `10.96.0.1` if service subnet is `10.96.0.0/12`)
- Kubernetes DNS names, e.g. `kubernetes.default.svc.cluster.local` if `--service-dns-domain` flag value is `cluster.local`, plus default DNS names `kubernetes.default.svc`, `kubernetes.default`, `kubernetes`
- The node-name
- The `--apiserver-advertise-address`
- Additional alternative names specified by the user
- A client certificate for the API server to connect to the kubelets securely, generated using `ca.crt` as the CA and saved into
`apiserver-kubelet-client.crt` file with its private key `apiserver-kubelet-client.key`.
This certificate should be in the `system:masters` organization
- A private key for signing ServiceAccount Tokens saved into `sa.key` file along with its public key `sa.pub`
- A certificate authority for the front proxy saved into `front-proxy-ca.crt` file with its key `front-proxy-ca.key`
- A client cert for the front proxy client, generate using `front-proxy-ca.crt` as the CA and saved into `front-proxy-client.crt` file
with its private key`front-proxy-client.key`
Certificates are stored by default in `/etc/kubernetes/pki`, but this directory is configurable using the `--cert-dir` flag.
Please note that:
1. If a given certificate and private key pair both exist, and its content is evaluated compliant with the above specs, the existing files will
be used and the generation phase for the given certificate skipped. This means the user can, for example, copy an existing CA to
`/etc/kubernetes/pki/ca.{crt,key}`, and then kubeadm will use those files for signing the rest of the certs.
See also [using custom certificates](kubeadm-init.md/#custom-certificates)
2. Only for the CA, it is possible to provide the `ca.crt` file but not the `ca.key` file, if all other certificates and kubeconfig files
already are in place kubeadm recognize this condition and activates the ExternalCA , which also implies the `csrsigner`controller in
controller-manager won't be started
3. If kubeadm is running in [ExternalCA mode](kubeadm-init.md/#external-ca-mode); all the certificates must be provided by the user,
because kubeadm cannot generate them by itself
4. In case of kubeadm is executed in the `--dry-run` mode, certificates files are written in a temporary folder
5. Certificate generation can be invoked individually with the [`kubeadm alpha phase certs all`](kubeadm-alpha.md/#cmd-phase-certs) command
### Generate kubeconfig files for control plane components
Kubeadm kubeconfig files with identities for control plane components:
- A kubeconfig file for kubelet to use, `/etc/kubernetes/kubelet.conf`; inside this file is embedded a client certificate with kubelet identity.
This client cert should:
- Be in the `system:nodes` organization, as required by the [Node Authorization](/docs/admin/authorization/node/) module
- Have the CN `system:node:<hostname-lowercased>`
- A kubeconfig file for controller-manager, `/etc/kubernetes/controller-manager.conf`; inside this file is embedded a client
certificate with controller-manager identity. This client cert should have the CN `system:kube-controller-manager`, as defined
by default [RBAC core components roles](/docs/admin/authorization/rbac/#core-component-roles)
- A kubeconfig file for scheduler, `/etc/kubernetes/scheduler.conf`; inside this file is embedded a client certificate with scheduler identity.
This client cert should have the CN `system:kube-scheduler`, as defined by default [RBAC core components roles](/docs/admin/authorization/rbac/#core-component-roles)
Additionally, a kubeconfig file for kubeadm to use itself and the admin is generated and save into the `/etc/kubernetes/admin.conf` file.
The "admin" here is defined the actual person(s) that is administering the cluster and want to have full control (**root**) over the cluster.
The embedded client certificate for admin should:
- Be in the `system:masters` organization, as defined by default [RBAC user facing role bindings](/docs/admin/authorization/rbac/#user-facing-roles)
- Include a CN, but that can be anything. Kubeadm uses the `kubernetes-admin` CN
Please note that:
1. `ca.crt` certificate is embedded in all the kubeconfig files.
2. If a given kubeconfig file exists, and its content is evaluated compliant with the above specs, the existing file will be used and the generation phase for the given kubeconfig skipped
3. If kubeadm is running in [ExternalCA mode](kubeadm-init.md/#external-ca-mode), all the required kubeconfig must be provided by the user as well, because kubeadm cannot generate any of them by itself
4. In case of kubeadm is executed in the `--dry-run` mode, kubeconfig files are written in a temporary folder
5. Kubeconfig files generation can be invoked individually with the [`kubeadm alpha phase kubeconfig all`](kubeadm-alpha.md/#cmd-phase-kubeconfig) command
### Generate static Pod manifests for control plane components
Kubeadm writes static Pod manifest files for control plane components to `/etc/kubernetes/manifests`; the kubelet watches this directory for Pods to create on startup.
Static Pod manifest share a set of common properties:
- All static Pods are deployed on `kube-system` namespace
- All static Pods gets `tier:control-plane` and `component:{component-name}` labels
- All static Pods gets `scheduler.alpha.kubernetes.io/critical-pod` annotation (this will be moved over to the proper solution
of using Pod Priority and Preemption when ready)
- `hostNetwork: true` is set on all static Pods to allow control plane startup before a network is configured; as a consequence:
* The `address` that the controller-manager and the scheduler use to refer the API server is `127.0.0.1`
* If using a local etcd server, `etcd-servers` address will be set to `127.0.0.1:2379`
- Leader election is enabled for both the controller-manager and the scheduler
- Controller-manager and the scheduler will reference kubeconfig files with their respective, unique identities
- All static Pods gets any extra flags specified by the user as described in [passing custom arguments to control plane components](kubeadm-init.md/#custom-args)
- All static Pods gets any extra Volumes specified by the user (Host path)
Please note that:
1. All the images, for the `--kubernetes-version`/current architecture, will be pulled from `k8s.gcr.io`;
In case an alternative image repository or CI image repository is specified this one will be used; In case a specific container image
should be used for all control plane components, this one will be used. see [using custom images](kubeadm-init.md/#custom-images)
for more details
2. In case of kubeadm is executed in the `--dry-run` mode, static Pods files are written in a temporary folder
3. Static Pod manifest generation for master components can be invoked individually with the [`kubeadm alpha phase controlplane all`](kubeadm-alpha.md/#cmd-phase-controlplane) command
#### API server
The static Pod manifest for the API server is affected by following parameters provided by the users:
- The `apiserver-advertise-address` and `apiserver-bind-port` to bind to; if not provided, those value defaults to the IP address of
the default network interface on the machine and port 6443
- The `service-cluster-ip-range` to use for services
- If an external etcd server is specified, the `etcd-servers` address and related TLS settings (`etcd-cafile`, `etcd-certfile`, `etcd-keyfile`);
if an external etcd server is not be provided, a local etcd will be used (via host network)
- If a cloud provider is specified, the corresponding `--cloud-provider` is configured, together with the `--cloud-config` path
if such file exists (this is experimental, alpha and will be removed in a future version)
- If kubeadm is invoked with `--feature-gates=HighAvailability`, the flag `--endpoint-reconciler-type=lease` is set, thus enabling
automatic reconciliation of endpoints for the internal API server VIP
- If kubeadm is invoked with `--feature-gates=DynamicKubeletConfig`, the corresponding feature on API server is activated
with the `--feature-gates=DynamicKubeletConfig=true` flag
Other API server flags that are set unconditionally are:
- `--insecure-port=0` to avoid insecure connections to the api server
- `--enable-bootstrap-token-auth=true` to enable the `BootstrapTokenAuthenticator` authentication module. see [TLS Bootstrapping](/docs/admin/kubelet-tls-bootstrapping.md) for more details
- `--allow-privileged` to `true` (required e.g. by kube proxy)
- `--requestheader-client-ca-file` to `front-proxy-ca.crt`
- `--enable-admission-plugins` to:
- [`Initializers`](/docs/admin/admission-controllers/#initializers-alpha) to enable [Dynamic Admission Control](/docs/admin/extensible-admission-controllers/).
- [`NamespaceLifecycle`](/docs/admin/admission-controllers/#namespacelifecycle) e.g. to avoid deletion of
system reserved namespaces
- [`LimitRanger`](/docs/admin/admission-controllers/#limitranger) and [`ResourceQuota`](/docs/admin/admission-controllers/#resourcequota) to enforce limits on namespaces
- [`ServiceAccount`](/docs/admin/admission-controllers/#serviceaccount) to enforce service account automation
- [`PersistentVolumeLabel`](/docs/admin/admission-controllers/#persistentvolumelabel) attaches region or zone labels to
PersistentVolumes as defined by the cloud provider (This admission controller is deprecated and will be removed in a future version.
It is not deployed by kubeadm by default with v1.9 onwards when not explicitly opting into using `gce` or `aws` as cloud providers)
- [`DefaultStorageClass`](/docs/admin/admission-controllers/#defaultstorageclass) to enforce default storage class on `PersistentVolumeClaim` objects
- [`DefaultTolerationSeconds`](/docs/admin/admission-controllers/#defaulttolerationseconds)
- [`NodeRestriction`](/docs/admin/admission-controllers/#noderestriction) to limit what a kubelet can modify
(e.g. only pods on this node)
- `--kubelet-preferred-address-types` to `InternalIP,ExternalIP,Hostname;` this makes `kubectl logs` and other API server-kubelet
communication work in environments where the hostnames of the nodes aren't resolvable
- Flags for using certificates generated in previous steps:
- `--client-ca-file` to `ca.crt`
- `--tls-cert-file` to `apiserver.crt`
- `--tls-private-key-file` to `apiserver.key`
- `--kubelet-client-certificate` to `apiserver-kubelet-client.crt`
- `--kubelet-client-key` to `apiserver-kubelet-client.key`
- `--service-account-key-file` to `sa.pub`
- `--requestheader-client-ca-file` to`front-proxy-ca.crt`
- `--proxy-client-cert-file` to `front-proxy-client.crt`
- `--proxy-client-key-file` to `front-proxy-client.key`
- Other flags for securing the front proxy ([API Aggregation](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/aggregated-api-servers.md)) communications:
- `--requestheader-username-headers=X-Remote-User`
- `--requestheader-group-headers=X-Remote-Group`
- `--requestheader-extra-headers-prefix=X-Remote-Extra-`
- `--requestheader-allowed-names=front-proxy-client`
#### Controller manager
The static Pod manifest for the API server is affected by following parameters provided by the users:
- If kubeadm is invoked specifying a `--pod-network-cidr`, the subnet manager feature required for some CNI network plugins is enabled by
setting:
- `--allocate-node-cidrs=true`
- `--cluster-cidr` and `--node-cidr-mask-size` flags according to the given CIDR
- If a cloud provider is specified, the corresponding `--cloud-provider` is specified, together with the `--cloud-config` path
if such configuration file exists (this is experimental, alpha and will be removed in a future version)
Other flags that are set unconditionally are:
- `--controllers` enabling all the default controllers plus `BootstrapSigner` and `TokenCleaner` controllers for TLS bootstrap.
see [TLS Bootstrapping](/docs/admin/kubelet-tls-bootstrapping.md) for more details
- `--use-service-account-credentials` to `true`
- Flags for using certificates generated in previous steps:
- `--root-ca-file` to `ca.crt`
- `--cluster-signing-cert-file` to `ca.crt`, if External CA mode is disabled, otherwise to `""`
- `--cluster-signing-key-file` to `ca.key`, if External CA mode is disabled, otherwise to `""`
- `--service-account-private-key-file` to `sa.key`
#### Scheduler
The static Pod manifest for the scheduler is not affected by parameters provided by the users.
### Generate static Pod manifest for local etcd
If the user specified an external etcd this step will be skipped, otherwise kubeadm generates a static Pod manifest file for creating
a local etcd instance running in a Pod with following attributes:
- listen on `localhost:2379` and use `HostNetwork=true`
- make a `hostPath` mount out from the `dataDir` to the host's filesystem
- Any extra flags specified by the user
Please note that:
1. The etcd image will be pulled from `k8s.gcr.io`. In case an alternative image repository is specified this one will be used;
In case an alternative image name is specified, this one will be used. see [using custom images](kubeadm-init.md/#custom-images) for more details
2. in case of kubeadm is executed in the `--dry-run` mode, the etcd static Pod manifest is written in a temporary folder
3. Static Pod manifest generation for local etcd can be invoked individually with the [`kubeadm alpha phase etcd local`](kubeadm-alpha.md/#cmd-phase-etcd) command
### (optional and alpha in v1.9) Write init kubelet configuration
If kubeadm is invoked with `--feature-gates=DynamicKubeletConfig`, it writes the kubelet init configuration
into `/var/lib/kubelet/config/init/kubelet` file.
The init configuration is used for starting the kubelet on this specific node, providing an alternative for the kubelet drop-in file;
such configuration will be replaced by the kubelet base configuration as described in following steps.
See [set Kubelet parameters via a config file](/docs/tasks/administer-cluster/kubelet-config-file.md) for additional info.
Please note that:
1. To make dynamic kubelet configuration work, flag `--dynamic-config-dir=/var/lib/kubelet/config/dynamic` should be specified
in `/etc/systemd/system/kubelet.service.d/10-kubeadm.conf`
1. Kubelet init configuration can be changed by using kubeadm MasterConfiguration file by setting `.kubeletConfiguration.baseConfig`.
See [using kubeadm init with a configuration file](kubeadm-init.md/#config-file) for more detail
### Wait for the control plane to come up
This is a critical moment in time for kubeadm clusters.
kubeadm waits until `localhost:6443/healthz` returns `ok`, however in order to detect deadlock conditions, kubeadm fails fast
if `localhost:10255/healthz` (kubelet liveness) or `localhost:10255/healthz/syncloop` (kubelet readiness) don't return `ok`,
respectively after 40 and 60 second.
kubeadm relies on the kubelet to pull the control plane images and run them properly as static Pods.
After the control plane is up, kubeadm completes a the tasks described in following paragraphs.
### (optional and alpha in v1.9) Write base kubelet configuration
If kubeadm is invoked with `--feature-gates=DynamicKubeletConfig`:
1. Write the kubelet base configuration into the `kubelet-base-config-v1.9` ConfigMap in the `kube-system` namespace
2. Creates RBAC rules for granting read access to that ConfigMap to all bootstrap tokens and all kubelet instances
(that is `system:bootstrappers:kubeadm:default-node-token` and `system:nodes` groups)
3. Enable the dynamic kubelet configuration feature for the initial master node by pointing `Node.spec.configSource` to the newly-created ConfigMap
### Save kubeadm MasterConfiguration in a ConfigMap for later reference
kubeadm saves the configuration passed to `kubeadm init`, either via flags or the config file, in a ConfigMap
named `kubeadm-config` under `kube-system` namespace.
This will ensure that kubeadm actions executed in future (e.g `kubeadm upgrade`) will be able to determine the actual/current cluster
state and make new decisions based on that data.
Please note that:
1. Before uploading, sensitive information like e.g. the token are stripped from the configuration
2. Upload of master configuration can be invoked individually with the [`kubeadm alpha phase upload-config`](kubeadm-alpha.md/#cmd-phase-upload-config) command
3. If you initialized your cluster using kubeadm v1.7.x or lower, you must create manually the master configuration ConfigMap
before `kubeadm upgrade` to v1.8 . In order to facilitate this task, the [`kubeadm config upload (from-flags|from-file)`](kubeadm-config.md)
was implemented
### Mark master
As soon as the control plane is available, kubeadm executes following actions:
- Label the master with `node-role.kubernetes.io/master=""`
- Taints the master with `node-role.kubernetes.io/master:NoSchedule`
Please note that:
1. Mark master phase can be invoked individually with the [`kubeadm alpha phase mark-master`](kubeadm-alpha.md/#cmd-phase-mark-master) command
### Configure TLS-Bootstrapping for node joining
Kubeadm uses [Authenticating with Bootstrap Tokens](/docs/admin/bootstrap-tokens/) for joining new nodes to an
existing cluster; for more details see also [design proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/cluster-lifecycle/bootstrap-discovery.md).
`kubeadm init` ensures that everything is properly configured for this process, and this includes following steps as well as
setting API server and controller flags as already described in previous paragraphs.
Please note that:
1. TLS bootstrapping for nodes can be configured with the [`kubeadm alpha phase bootstrap-token all`](kubeadm-alpha.md/#cmd-phase-bootstrap-token)
command, executing all the configuration steps described in following paragraphs; alternatively, each step can be invoked individually
#### Create a bootstrap token
`kubeadm init` create a first bootstrap token, either generated automatically or provided by the user with the `--token` flag; as documented
in bootstrap token specification, token should be saved as secrets with name `bootstrap-token-<token-id>` under `kube-system` namespace.
Please note that:
1. The default token created by `kubeadm init` will be used to validate temporary user during TLS bootstrap process; those users will
be member of `system:bootstrappers:kubeadm:default-node-token` group
2. The token has a limited validity, default 24 hours (the interval may be changed with the `—token-ttl` flag)
3. Additional tokens can be created with the [`kubeadm token`](kubeadm-token.md) command, that provide as well other useful functions
for token management
#### Allow joining nodes to call CSR API
Kubeadm ensure that users in `system:bootstrappers:kubeadm:default-node-token` group are able to access the certificate signing API.
This is implemented by creating a ClusterRoleBinding named `kubeadm:kubelet-bootstrap` between the group above and the default
RBAC role `system:node-bootstrapper`.
#### Setup auto approval for new bootstrap tokens
Kubeadm ensures that the Bootstrap Token will get its CSR request automatically approved by the csrapprover controller.
This is implemented by creating ClusterRoleBinding named `kubeadm:node-autoapprove-bootstrap` between
the `system:bootstrappers:kubeadm:default-node-token` group and the default role `system:certificates.k8s.io:certificatesigningrequests:nodeclient`.
The role `system:certificates.k8s.io:certificatesigningrequests:nodeclient` should be created as well, granting
POST permission to `/apis/certificates.k8s.io/certificatesigningrequests/nodeclient`.
#### Setup nodes certificate rotation with auto approval
Kubeadm ensures that certificate rotation is enabled for nodes, and that new certificate request for nodes will get its CSR request
automatically approved by the csrapprover controller.
This is implemented by creating ClusterRoleBinding named `kubeadm:node-autoapprove-certificate-rotation` between the `system:nodes` group
and the default role `system:certificates.k8s.io:certificatesigningrequests:selfnodeclient`.
#### Create the public cluster-info ConfigMap
This phase creates the `cluster-info` ConfigMap in the `kube-public` namespace.
Additionally it is created a role and a RoleBinding granting access to the ConfigMap for unauthenticated users
(i.e. users in RBAC group `system:unauthenticated`)
Please note that:
1. The access to the `cluster-info` ConfigMap _is not_ rate-limited. This may or may not be a problem if you expose your master
to the internet; worst-case scenario here is a DoS attack where an attacker uses all the in-flight requests the kube-apiserver
can handle to serving the `cluster-info` ConfigMap.
### Install addons
Kubeadm installs the internal DNS server and the kube-proxy addon components via the API server.
Please note that:
1. This phase can be invoked individually with the [`kubeadm alpha phase addon all`](kubeadm-alpha.md/#cmd-phase-addon) command.
#### proxy
A ServiceAccount for `kube-proxy` is created in the `kube-system` namespace; then kube-proxy is deployed as a DaemonSet:
- The credentials (`ca.crt` and `token`) to the master come from the ServiceAccount
- The location of the master comes from a ConfigMap
- The `kube-proxy` ServiceAccount is bound to the privileges in the `system:node-proxier` ClusterRole
#### DNS
A ServiceAccount for `kube-dns` is created in the `kube-system` namespace.
Deploy the kube-dns Deployment and Service:
- It's the upstream kube-dns deployment relatively unmodified
- The `kube-dns` ServiceAccount is bound to the privileges in the `system:kube-dns` ClusterRole
Please note that:
1. If kubeadm is invoked with `--feature-gates=CoreDNS`, CoreDNS is installed instead of `kube-dns`
### (Optional and alpha in v1.9) self-hosting
This phase is performed only if `kubeadm init` is invoked with `—features-gates=selfHosting`
The self hosting phase basically replaces static Pods for control plane components with DaemonSets; this is achieved by executing
following procedure for API server, scheduler and controller manager static Pods:
- Load the static Pod specification from disk
- Extract the PodSpec from static Pod manifest file
- Mutate the PodSpec to be compatible with self-hosting, and more in detail:
- Add node selector attribute targeting nodes with `node-role.kubernetes.io/master=""` label,
- Add a toleration for `node-role.kubernetes.io/master:NoSchedule` taint,
- Set `spec.DNSPolicy` to `ClusterFirstWithHostNet`
- Build a new DaemonSet object for the self-hosted component in question. Use the above mentioned PodSpec
- Create the DaemonSet resource in `kube-system` namespace. Wait until the Pods are running.
- Remove the static Pod manifest file. The kubelet will stop the original static Pod-hosted component that was running
Please note that:
1. Self hosting is not yet resilient to node restarts; this can be fixed with external checkpointing or with kubelet checkpointing
for the control plane Pods. See [self-hosting](kubeadm-init.md/#self-hosting) for more details.
2. If invoked with `—features-gates=StoreCertsInSecrets` following additional steps will be executed
- Creation of `ca`, `apiserver`, `apiserver-kubelet-client`, `sa`, `front-proxy-ca`, `front-proxy-client` TLS secrets
in `kube-system` namespace with respective certificates and keys.
Important! storing the CA key in a Secret might have security implications
- Creation of `schedler.conf` and `controller-manager.conf` secrets in`kube-system` namespace with respective kubeconfig files
- Mutation of all the Pod specs by replacing host path volumes with projected volumes from the secrets above
3. This phase can be invoked individually with the [`kubeadm alpha phase selfhosting convert-from-staticpods`](kubeadm-alpha.md/#cmd-phase-self-hosting) command.
## kubeadm join phases internal design
Similarly to `kubeadm init`, also `kubeadm join` internal workflow consists of a sequence of atomic work tasks to perform.
This is split into discovery (having the Node trust the Kubernetes Master) and TLS bootstrap (having the Kubernetes Master trust the Node).
see [Authenticating with Bootstrap Tokens](/docs/admin/bootstrap-tokens/) or the corresponding [design proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/cluster-lifecycle/bootstrap-discovery.md).
### Preflight checks
`kubeadm` executes a set of preflight checks before starting the join, with the aim to verify preconditions and avoid common
cluster startup problems.
Please note that:
1. `kubeadm join` preflight checks are basically a subset `kubeadm init` preflight checks
1. Starting from 1.9, kubeadm provides better support for CRI-generic functionality; in that case, docker specific controls
are skipped or replaced by similar controls for crictl.
1. Starting from 1.9, kubeadm provides support for joining nodes running on Windows; in that case, linux specific controls are skipped.
1. In any case the user can skip specific preflight checks (or eventually all preflight checks) with the `--ignore-preflight-errors` option.
### Discovery cluster-info
There are 2 main schemes for discovery. The first is to use a shared token along with the IP address of the API server.
The second is to provide a file (that is a subset of the standard kubeconfig file).
#### Shared token discovery
If `kubeadm join` is invoked with `--discovery-token`, token discovery is used; in this case the node basically retrieves
the cluster CA certificates from the `cluster-info` ConfigMap in the `kube-public` namespace.
In order to prevent "man in the middle" attacks, several steps are taken:
- First, the CA certificate is retrieved via insecure connection (this is possible because `kubeadm init` granted access to `cluster-info` users for `system:unauthenticated` )
- Then the CA certificate goes trough following validation steps:
- Basic validation: using the token ID against a JWT signature
- Pub key validation: using provided `--discovery-token-ca-cert-hash`. This value is available in the output of `kubeadm init` or can
be calculated using standard tools (the hash is calculated over the bytes of the Subject Public Key Info (SPKI) object as in RFC7469).
The `--discovery-token-ca-cert-hash flag` may be repeated multiple times to allow more than one public key.
- As a additional validation, the CA certificate is retrieved via secure connection and then compared with the CA retrieved initially
Please note that:
1. Pub key validation can be skipped passing `--discovery-token-unsafe-skip-ca-verification` flag; This weakens the kubeadm security
model since others can potentially impersonate the Kubernetes Master.
#### File/https discovery
If `kubeadm join` is invoked with `--discovery-file`, file discovery is used; this file can be a local file or downloaded via an HTTPS URL; in case of HTTPS, the host installed CA bundle is used to verify the connection.
With file discovery, the cluster CA certificates is provided into the file itself; in fact, the discovery file is a kubeconfig
file with only `server` and `certificate-authority-data` attributes set, as described in [`kubeadm join`](/kubeadm-join.md/#file-or-https-based-discovery) reference doc;
when the connection with the cluster is established, kubeadm try to access the `cluster-info` ConfigMap, and if available, uses it.
## TLS Bootstrap
Once the cluster info are known, the file `bootstrap-kubelet.conf` is written, thus allowing kubelet to do TLS Bootstrapping
(conversely until v.1.7 TLS bootstrapping were managed by kubeadm).
The TLS bootstrap mechanism uses the shared token to temporarily authenticate with the Kubernetes Master to submit a certificate
signing request (CSR) for a locally created key pair.
The request is then automatically approved and the operation completes saving `ca.crt` file and `kubelet.conf` file to be used
by kubelet for joining the cluster, while`bootstrap-kubelet.conf` is deleted.
Please note that:
- The temporary authentication is validated against the token saved during the `kubeadm init` process (or with additional tokens
created with `kubeadm token`)
- The temporary authentication resolve to a user member of `system:bootstrappers:kubeadm:default-node-token` group which was granted
access to CSR api during the `kubeadm init` process
- The automatic CSR approval is managed by the csrapprover controller, according with configuration done the `kubeadm init` process
### (optional and alpha in v1.9) Write init kubelet configuration
If kubeadm is invoked with `--feature-gates=DynamicKubeletConfig`:
1. Read the kubelet base configuration from the `kubelet-base-config-v1.9` ConfigMap in the `kube-system` namespace using the
Bootstrap Token credentials, and write it to disk as kubelet init configuration file `/var/lib/kubelet/config/init/kubelet`
2. As soon as kubelet starts with the Node's own credential (`/etc/kubernetes/kubelet.conf`), update current node configuration
specifying that the source for the node/kubelet configuration is the above ConfigMap.
Please note that:
1. To make dynamic kubelet configuration work, flag `--dynamic-config-dir=/var/lib/kubelet/config/dynamic` should be specified in `/etc/systemd/system/kubelet.service.d/10-kubeadm.conf`
{{% /capture %}}
@@ -0,0 +1,154 @@
---
approvers:
- mikedanese
- luxas
- jbeda
title: kubeadm alpha
---
{{< caution >}}
`kubeadm alpha` provides a preview of a set of features made available for gathering feedback
from the community. Please try it out and give us feedback!
{{< /caution >}}
In v1.8.0, kubeadm introduced the `kubeadm alpha phase` command with the aim of making kubeadm more modular. This modularity enables you to invoke atomic sub-steps of the bootstrap process; you can let kubeadm do some parts and fill in yourself where you need customizations.
`kubeadm alpha phase` is consistent with [kubeadm init workflow](kubeadm-init.md#init-workflow),
and behind the scene both use the same code.
* [kubeadm alpha phase preflight](#cmd-phase-preflight)
* [kubeadm alpha phase certs](#cmd-phase-certs)
* [kubeadm alpha phase kubeconfig](#cmd-phase-kubeconfig)
* [kubeadm alpha phase controlplane](#cmd-phase-controlplane)
* [kubeadm alpha phase etcd](#cmd-phase-etcd)
* [kubeadm alpha phase mark-master](#cmd-phase-mark-master)
* [kubeadm alpha phase bootstrap-token](#cmd-phase-bootstrap-token)
* [kubeadm alpha phase upload-config](#cmd-phase-upload-config)
* [kubeadm alpha phase addon](#cmd-phase-addon)
* [kubeadm alpha phase selfhosting](#cmd-phase-self-hosting)
## kubeadm alpha phase preflight {#cmd-phase-preflight}
You can execute preflight checks both for the master node, like in `kubeadm init`, or for the worker node
like in `kubeadm join`.
{{< tabs name="tab-preflight" >}}
{{< tab name="master" include="generated/kubeadm_alpha_phase_preflight_master.md" />}}
{{< tab name="node" include="generated/kubeadm_alpha_phase_preflight_node.md" />}}
{{< /tabs >}}
## kubeadm alpha phase certs {#cmd-phase-certs}
You can create all required certificates with the `all` subcommand or selectively create certificates.
{{< tabs name="tab-certs" >}}
{{< tab name="all" include="generated/kubeadm_alpha_phase_certs_all.md" />}}
{{< tab name="ca" include="generated/kubeadm_alpha_phase_certs_ca.md" />}}
{{< tab name="apiserver" include="generated/kubeadm_alpha_phase_certs_apiserver.md" />}}
{{< tab name="apiserver-kubelet-client" include="generated/kubeadm_alpha_phase_certs_apiserver-kubelet-client.md" />}}
{{< tab name="sa" include="generated/kubeadm_alpha_phase_certs_sa.md" />}}
{{< tab name="front-proxy-ca" include="generated/kubeadm_alpha_phase_certs_front-proxy-ca.md" />}}
{{< tab name="front-proxy-client" include="generated/kubeadm_alpha_phase_certs_front-proxy-client.md" />}}
{{< /tabs >}}
## kubeadm alpha phase kubeconfig {#cmd-phase-kubeconfig}
You can create all required kubeconfig files with the `all` subcommand, or selectively create the files.
Additionally, the `user` subcommand supports the creation of kubeconfig files for additional users.
{{< tabs name="tab-kubeconfig" >}}
{{< tab name="all" include="generated/kubeadm_alpha_phase_kubeconfig_all.md" />}}
{{< tab name="admin" include="generated/kubeadm_alpha_phase_kubeconfig_admin.md" />}}
{{< tab name="kubelet" include="generated/kubeadm_alpha_phase_kubeconfig_kubelet.md" />}}
{{< tab name="controller-manager" include="generated/kubeadm_alpha_phase_kubeconfig_controller-manager.md" />}}
{{< tab name="scheduler" include="generated/kubeadm_alpha_phase_kubeconfig_scheduler.md" />}}
{{< tab name="user" include="generated/kubeadm_alpha_phase_kubeconfig_user.md" />}}
{{< /tabs >}}
## kubeadm alpha phase controlplane {#cmd-phase-controlplane}
You can create all required static Pod files for the control plane components with the `all` subcommand,
or selectively create the files.
{{< tabs name="tab-controlplane" >}}
{{< tab name="all" include="generated/kubeadm_alpha_phase_controlplane_all.md" />}}
{{< tab name="apiserver" include="generated/kubeadm_alpha_phase_controlplane_apiserver.md" />}}
{{< tab name="controller-manager" include="generated/kubeadm_alpha_phase_controlplane_controller-manager.md" />}}
{{< tab name="scheduler" include="generated/kubeadm_alpha_phase_controlplane_scheduler.md" />}}
{{< /tabs >}}
## kubeadm alpha phase etcd {#cmd-phase-etcd}
Use the following command to create a self-hosted, local etcd instance based on a static Pod file.
{{< tabs name="tab-etcd" >}}
{{< tab name="etcd local" include="generated/kubeadm_alpha_phase_etcd_local.md" />}}
{{< /tabs >}}
## kubeadm alpha phase mark-master {#cmd-phase-mark-master}
Use the following command to label and taint the node with the `node-role.kubernetes.io/master=""` key-value pair.
{{< tabs name="tab-mark-master" >}}
{{< tab name="mark-master" include="generated/kubeadm_alpha_phase_mark-master.md" />}}
{{< /tabs >}}
## kubeadm alpha phase bootstrap-token {#cmd-phase-bootstrap-token}
Use the following actions to fully configure bootstrap tokens.
You can fully configure bootstrap tokens with the `all` subcommand,
or selectively configure single elements.
{{< tabs name="tab-bootstrap-token" >}}
{{< tab name="all" include="generated/kubeadm_alpha_phase_bootstrap-token_all.md" />}}
{{< tab name="create" include="generated/kubeadm_alpha_phase_bootstrap-token_create.md" />}}
{{< tab name="cluster-info" include="generated/kubeadm_alpha_phase_bootstrap-token_cluster-info.md " />}}
{{< tab name="node allow-auto-approve" include="generated/kubeadm_alpha_phase_bootstrap-token_node_allow-auto-approve.md" />}}
{{< tab name="node allow-post-csrs" include="generated/kubeadm_alpha_phase_bootstrap-token_node_allow-post-csrs.md" />}}
{{< /tabs >}}
## kubeadm alpha phase upload-config {#cmd-phase-upload-config}
You can use this command to upload the kubeadm configuration to your cluster.
Alternatively, you can use [kubeadm config](kubeadm-config.md).
{{< tabs name="upload-config" >}}
{{< tab name="mark-master" include="generated/kubeadm_alpha_phase_upload-config.md" />}}
{{< /tabs >}}
## kubeadm alpha phase addon {#cmd-phase-addon}
You can install all the available addons with the `all` subcommand, or
install them selectively.
Please note that if kubeadm is invoked with `--feature-gates=CoreDNS=true`, [CoreDNS](https://coredns.io/) is installed instead of `kube-dns`.
{{< tabs name="tab-addon" >}}
{{< tab name="all" include="generated/kubeadm_alpha_phase_addon_all.md" />}}
{{< tab name="kube-proxy" include="generated/kubeadm_alpha_phase_addon_kube-proxy.md" />}}
{{< tab name="kube-dns" include="generated/kubeadm_alpha_phase_addon_kube-dns.md" />}}
{{< /tabs >}}
## kubeadm alpha phase self-hosting {#cmd-phase-self-hosting}
{{< caution >}}
**Caution:** Self-hosting is an alpha feature. See [kubeadm init](kubeadm-init.md) documentation for self-hosting limitations.
{{< /caution >}}
{{< tabs name="tab-self-hosting" >}}
{{< tab name="self-hosting" include="generated/kubeadm_alpha_phase_selfhosting_convert-from-staticpods.md" />}}
{{< /tabs >}}
## What's next
* [kubeadm init](kubeadm-init.md) to bootstrap a Kubernetes master node
* [kubeadm join](kubeadm-join.md) to connect a node to the cluster
* [kubeadm reset](kubeadm-reset.md) to revert any changes made to this host by `kubeadm init` or `kubeadm join`
@@ -0,0 +1,34 @@
---
approvers:
- mikedanese
- luxas
- jbeda
title: kubeadm config
content_template: templates/concept
---
{{% capture overview %}}
Beginning with v1.8.0, kubeadm uploads the configuration of your cluster to a ConfigMap called
`kubeadm-config` in the `kube-system` namespace, and later reads the ConfigMap when upgrading.
This enables correct configuration of system components, and provides a seamless user experience.
You can execute `kubeadm config view` to view the ConfigMap. If you initialized your cluster using
kubeadm v1.7.x or lower, you must use `kubeadm config upload` to create the ConfigMap before you
may use `kubeadm upgrade`.
{{% /capture %}}
{{% capture body %}}
## kubeadm config upload from-file {#cmd-config-from-file}
{{< include "generated/kubeadm_config_upload_from-file.md" >}}
## kubeadm config upload from-flags {#cmd-config-from-flags}
{{< include "generated/kubeadm_config_upload_from-flags.md" >}}
## kubeadm config view {#cmd-config-view}
{{< include "generated/kubeadm_config_view.md" >}}
{{% /capture %}}
{{% capture whatsnext %}}
* [kubeadm upgrade](kubeadm-upgrade.md) to upgrade a Kubernetes cluster to a newer version
{{% /capture %}}
@@ -0,0 +1,460 @@
---
approvers:
- mikedanese
- luxas
- jbeda
title: kubeadm init
content_template: templates/concept
---
{{% capture overview %}}
{{% /capture %}}
{{% capture body %}}
{{< include "generated/kubeadm_init.md" >}}
### Init workflow {#init-workflow}
`kubeadm init` bootstraps a Kubernetes master node by executing the
following steps:
1. Runs a series of pre-flight checks to validate the system state
before making changes. Some checks only trigger warnings, others are
considered errors and will exit kubeadm until the problem is corrected or the
user specifies `--skip-preflight-checks`.
1. Generates a self-signed CA (or using an existing one if provided) to set up
identities for each component in the cluster. If the user has provided their
own CA cert and/or key by dropping it in the cert directory configured via `--cert-dir`
(`/etc/kubernetes/pki` by default) this step is skipped as described in the
[Using custom certificates](#custom-certificates) document.
1. Writes kubeconfig files in `/etc/kubernetes/` for
the kubelet, the controller-manager and the scheduler to use to connect to the
API server, each with its own identity, as well as an additional
kubeconfig file for administration named `admin.conf`.
1. If kubeadm is invoked with `--feature-gates=DynamicKubeletConfig` enabled,
it writes the kubelet init configuration into the `/var/lib/kubelet/config/init/kubelet` file.
See [Set Kubelet parameters via a config file](/docs/tasks/administer-cluster/kubelet-config-file/)
and [Reconfigure a Node's Kubelet in a Live Cluster](/docs/tasks/administer-cluster/reconfigure-kubelet/)
for more information about Dynamic Kubelet Configuration.
This functionality is now by default disabled as it is behind a feature gate, but is expected to be a default in future versions.
1. Generates static Pod manifests for the API server,
controller manager and scheduler. In case an external etcd is not provided,
an additional static Pod manifest are generated for etcd.
Static Pod manifests are written to `/etc/kubernetes/manifests`; the kubelet
watches this directory for Pods to create on startup.
Once control plane Pods are up and running, the `kubeadm init` sequence can continue.
1. If kubeadm is invoked with `--feature-gates=DynamicKubeletConfig` enabled,
it completes the kubelet dynamic configuration by creating a ConfigMap and some RBAC rules that enable
kubelets to access to it, and updates the node by pointing `Node.spec.configSource` to the
newly-created ConfigMap.
This functionality is now by default disabled as it is behind a feature gate, but is expected to be a default in future versions.
1. Apply labels and taints to the master node so that no additional workloads will
run there.
1. Generates the token that additional nodes can use to register
themselves with the master in the future. Optionally, the user can provide a
token via `--token`, as described in the
[kubeadm token](kubeadm-token.md) docs.
1. Makes all the necessary configurations for allowing node joining with the
[Bootstrap Tokens](/docs/admin/bootstrap-tokens/) and
[TLS Bootstrap](/docs/admin/kubelet-tls-bootstrapping/)
mechanism:
- Write a ConfigMap for making available all the information required
for joining, and set up related RBAC access rules.
- Let Bootstrap Tokens access the CSR signing API.
- Configure auto-approval for new CSR requests.
See [kubeadm join](kubeadm-join.md) for additional info.
1. Installs the internal DNS server (kube-dns) and the kube-proxy addon components via the API server. If kubeadm is invoked with --feature-gates=CoreDNS=true, then [CoreDNS](https://coredns.io/) will be installed as the default internal DNS server instead of kube-dns.
Please note that although the DNS server is deployed, it will not be scheduled until CNI is installed.
1. If `kubeadm init` is invoked with the alpha self-hosting feature enabled,
(`--feature-gates=SelfHosting=true`), the static Pod based control plane is
transformed into a [self-hosted control plane](#self-hosting).
### Using kubeadm init with a configuration file {#config-file}
{{< caution >}}
**Caution:** The config file is
still considered alpha and may change in future versions.
{{< /caution >}}
It's possible to configure `kubeadm init` with a configuration file instead of command
line flags, and some more advanced features may only be available as
configuration file options. This file is passed in the `--config` option.
```yaml
apiVersion: kubeadm.k8s.io/v1alpha1
kind: MasterConfiguration
api:
advertiseAddress: <address|string>
controlPlaneEndpoint: <string>
bindPort: <int>
etcd:
endpoints:
- <endpoint1|string>
- <endpoint2|string>
caFile: <path|string>
certFile: <path|string>
keyFile: <path|string>
dataDir: <path|string>
extraArgs:
<argument>: <value|string>
<argument>: <value|string>
image: <string>
kubeProxy:
config:
mode: <value|string>
networking:
dnsDomain: <string>
serviceSubnet: <cidr>
podSubnet: <cidr>
kubernetesVersion: <string>
cloudProvider: <string>
nodeName: <string>
authorizationModes:
- <authorizationMode1|string>
- <authorizationMode2|string>
token: <string>
tokenTTL: <time duration>
selfHosted: <bool>
apiServerExtraArgs:
<argument>: <value|string>
<argument>: <value|string>
controllerManagerExtraArgs:
<argument>: <value|string>
<argument>: <value|string>
schedulerExtraArgs:
<argument>: <value|string>
<argument>: <value|string>
apiServerExtraVolumes:
- name: <value|string>
hostPath: <value|string>
mountPath: <value|string>
controllerManagerExtraVolumes:
- name: <value|string>
hostPath: <value|string>
mountPath: <value|string>
schedulerExtraVolumes:
- name: <value|string>
hostPath: <value|string>
mountPath: <value|string>
apiServerCertSANs:
- <name1|string>
- <name2|string>
certificatesDir: <string>
imageRepository: <string>
unifiedControlPlaneImage: <string>
featureGates:
<feature>: <bool>
<feature>: <bool>
```
### Passing custom arguments to control plane components {#custom-args}
If you would like to override or extend the behaviour of a control plane component, you can provide
extra arguments to kubeadm. When the component is deployed, these additional arguments are added to
the Pod command itself.
For example, to add additional feature-gate arguments to the API server, your [configuration file](#config-file)
will need to look like this:
```
apiVersion: kubeadm.k8s.io/v1alpha1
kind: MasterConfiguration
apiServerExtraArgs:
feature-gates: APIResponseCompression=true
```
To customize the scheduler or controller-manager, use `schedulerExtraArgs` and `controllerManagerExtraArgs` respectively.
More information on custom arguments can be found here:
- [kube-apiserver](/docs/admin/kube-apiserver/)
- [kube-controller-manager](/docs/admin/kube-controller-manager/)
- [kube-scheduler](/docs/admin/kube-scheduler/)
### Using custom images {#custom-images}
By default, kubeadm pulls images from `k8s.gcr.io`, unless
the requested Kubernetes version is a CI version. In this case,
`gcr.io/kubernetes-ci-images` is used.
You can override this behavior by using [kubeadm with a configuration file](#config-file).
Allowed customization are:
* To provide an alternative `imageRepository` to be used instead of
`k8s.gcr.io`.
* To provide a `unifiedControlPlaneImage` to be used instead of different images for control plane components.
* To provide a specific `etcd.image` to be used instead of the image available at`k8s.gcr.io`.
### Using custom certificates {#custom-certificates}
By default, kubeadm generates all the certificates needed for a cluster to run.
You can override this behavior by providing your own certificates.
To do so, you must place them in whatever directory is specified by the
`--cert-dir` flag or `CertificatesDir` configuration file key. By default this
is `/etc/kubernetes/pki`.
If a given certificate and private key pair exists, kubeadm skips the
generation step and existing files are used for the prescribed
use case. This means you can, for example, copy an existing CA into `/etc/kubernetes/pki/ca.crt`
and `/etc/kubernetes/pki/ca.key`, and kubeadm will use this CA for signing the rest
of the certs.
#### External CA mode {#external-ca-mode}
It is also possible to provide just the `ca.crt` file and not the
`ca.key` file (this is only available for the root CA file, not other cert pairs).
If all other certificates and kubeconfig files are in place, kubeadm recognizes
this condition and activates the "External CA" mode. kubeadm will proceed without the
CA key on disk.
Instead, run the controller-manager standalone with `--controllers=csrsigner` and
point to the CA certificate and key.
### Managing the kubeadm drop-in file for the kubelet {#kubelet-drop-in}
The kubeadm package ships with configuration for how the kubelet should
be run. Note that the `kubeadm` CLI command never touches this drop-in file.
This drop-in file belongs to the kubeadm deb/rpm package.
This is what it looks like:
```
[Service]
Environment="KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf"
Environment="KUBELET_SYSTEM_PODS_ARGS=--pod-manifest-path=/etc/kubernetes/manifests --allow-privileged=true"
Environment="KUBELET_NETWORK_ARGS=--network-plugin=cni --cni-conf-dir=/etc/cni/net.d --cni-bin-dir=/opt/cni/bin"
Environment="KUBELET_DNS_ARGS=--cluster-dns=10.96.0.10 --cluster-domain=cluster.local"
Environment="KUBELET_AUTHZ_ARGS=--authorization-mode=Webhook --client-ca-file=/etc/kubernetes/pki/ca.crt"
Environment="KUBELET_CADVISOR_ARGS=--cadvisor-port=0"
Environment="KUBELET_CERTIFICATE_ARGS=--rotate-certificates=true --cert-dir=/var/lib/kubelet/pki"
ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_SYSTEM_PODS_ARGS $KUBELET_NETWORK_ARGS $KUBELET_DNS_ARGS $KUBELET_AUTHZ_ARGS $KUBELET_CADVISOR_ARGS $KUBELET_CERTIFICATE_ARGS $KUBELET_EXTRA_ARGS
```
Here's a breakdown of what/why:
* `--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf` path to a kubeconfig
file that is used to get client certificates for kubelet during node join.
On success, a kubeconfig file is written to the path specified by `--kubeconfig`.
* `--kubeconfig=/etc/kubernetes/kubelet.conf` points to the kubeconfig file that
tells the kubelet where the API server is. This file also has the kubelet's
credentials.
* `--pod-manifest-path=/etc/kubernetes/manifests` specifies from where to read
static Pod manifests used for starting the control plane.
* `--allow-privileged=true` allows this kubelet to run privileged Pods.
* `--network-plugin=cni` uses CNI networking.
* `--cni-conf-dir=/etc/cni/net.d` specifies where to look for the
[CNI spec file(s)](https://github.com/containernetworking/cni/blob/master/SPEC.md).
* `--cni-bin-dir=/opt/cni/bin` specifies where to look for the actual CNI binaries.
* `--cluster-dns=10.96.0.10` use this cluster-internal DNS server for `nameserver`
entries in Pods' `/etc/resolv.conf`.
* `--cluster-domain=cluster.local` uses this cluster-internal DNS domain for
`search` entries in Pods' `/etc/resolv.conf`.
* `--client-ca-file=/etc/kubernetes/pki/ca.crt` authenticates requests to the Kubelet
API using this CA certificate.
* `--authorization-mode=Webhook` authorizes requests to the Kubelet API by `POST`-ing
a `SubjectAccessReview` to the API server.
* `--cadvisor-port=0` disables cAdvisor from listening to `0.0.0.0:4194` by default.
cAdvisor will still be run inside of the kubelet and its API can be accessed at
`https://{node-ip}:10250/stats/`. If you want to enable cAdvisor to listen on a
wide-open port, run:
```bash
sed -e "/cadvisor-port=0/d" -i /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
systemctl daemon-reload
systemctl restart kubelet
```
* `--rotate-certificates` auto rotate the kubelet client certificates by requesting new
certificates from the `kube-apiserver` when the certificate expiration approaches.
* `--cert-dir`the directory where the TLS certs are located.
### Use kubeadm with other CRI runtimes
Since v1.6.0, Kubernetes has enabled the use of CRI, Container Runtime Interface, by default.
The container runtime used by default is Docker, which is enabled through the built-in
`dockershim` CRI implementation inside of the `kubelet`.
Other CRI-based runtimes include:
- [cri-containerd](https://github.com/containerd/cri-containerd)
- [cri-o](https://github.com/kubernetes-incubator/cri-o)
- [frakti](https://github.com/kubernetes/frakti)
- [rkt](https://github.com/kubernetes-incubator/rktlet)
After you have successfully installed `kubeadm` and `kubelet`, execute
these two additional steps:
1. Install the runtime shim on every node, following the installation
document in the runtime shim project listing above.
1. Configure kubelet to use the remote CRI runtime. Please remember to change
`RUNTIME_ENDPOINT` to your own value like `/var/run/{your_runtime}.sock`:
```shell
cat > /etc/systemd/system/kubelet.service.d/20-cri.conf <<EOF
[Service]
Environment="KUBELET_EXTRA_ARGS=--container-runtime=remote --container-runtime-endpoint=$RUNTIME_ENDPOINT"
EOF
systemctl daemon-reload
```
Now `kubelet` is ready to use the specified CRI runtime, and you can continue
with the `kubeadm init` and `kubeadm join` workflow to deploy Kubernetes cluster.
You may also want to set `--cri-socket` to `kubeadm init` and `kubeadm reset` when
using an external CRI implementation.
### Using internal IPs in your cluster
In order to set up a cluster where the master and worker nodes communicate with internal IP addresses (instead of public ones), execute following steps.
1. When running init, you must make sure you specify an internal IP for the API server's bind address, like so:
`kubeadm init --apiserver-advertise-address=<private-master-ip>`
2. When a worker node has been provisioned, add a flag to `/etc/systemd/system/kubelet.service.d/10-kubeadm.conf` that specifies the private IP of the worker node:
`--node-ip=<private-node-ip>`
3. Finally, when you run `kubeadm join`, make sure you provide the private IP of the API server addressed as defined in step 1.
### Self-hosting the Kubernetes control plane {#self-hosting}
As of 1.8, you can experimentally create a _self-hosted_ Kubernetes control
plane. This means that key components such as the API server, controller
manager, and scheduler run as [DaemonSet pods](/docs/concepts/workloads/controllers/daemonset/)
configured via the Kubernetes API instead of [static pods](/docs/tasks/administer-cluster/static-pod/)
configured in the kubelet via static files.
{{< caution >}}
**Caution:** Self-hosting is alpha, but is expected to become the default in
a future version. To create a self-hosted cluster, pass the `--feature-gates=SelfHosting=true`
flag to `kubeadm init`.
{{< /caution >}}
{{< warning >}}
**Warning:** see self-hosted caveats and limitations.
{{< /warning >}}
#### Caveats
Self-hosting in 1.8 has some important limitations. In particular, a
self-hosted cluster _cannot recover from a reboot of the master node_
without manual intervention. This and other limitations are expected to be
resolved before self-hosting graduates from alpha.
By default, self-hosted control plane Pods rely on credentials loaded from
[`hostPath`](https://kubernetes.io/docs/concepts/storage/volumes/#hostpath)
volumes. Except for initial creation, these credentials are not managed by
kubeadm. You can use `--feature-gates=StoreCertsInSecrets=true` to enable an
experimental mode where control plane credentials are loaded from Secrets
instead. This requires very careful control over the authentication and
authorization configuration for your cluster, and may not be appropriate for
your environment.
In kubeadm 1.8, the self-hosted portion of the control plane does not include etcd,
which still runs as a static Pod.
#### Process
The self-hosting bootstrap process is documented in the [kubeadm design
document](https://github.com/kubernetes/kubeadm/blob/master/docs/design/design_v1.9.md#optional-self-hosting).
In summary, `kubeadm init --feature-gates=SelfHosting=true` works as follows:
1. Waits for this bootstrap static control plane to be running and
healthy. This is identical to the `kubeadm init` process without self-hosting.
1. Uses the static control plane Pod manifests to construct a set of
DaemonSet manifests that will run the self-hosted control plane.
It also modifies these manifests where necessary, for example adding new volumes
for secrets.
1. Creates DaemonSets in the `kube-system` namespace and waits for the
resulting Pods to be running.
1. Once self-hosted Pods are operational, their associated static Pods are deleted
and kubeadm moves on to install the next component. This triggers kubelet to
stop those static Pods.
1. When the original static control plane stops, the new self-hosted control
plane is able to bind to listening ports and become active.
This process (steps 3-6) can also be triggered with `kubeadm phase selfhosting convert-from-staticpods`.
### Running kubeadm without an internet connection
For running kubeadm without an internet connection you have to pre-pull the required master images for the version of choice:
| Image Name | v1.8 release branch version | v1.9 release branch version |
|----------------------------------------------------------|-----------------------------|-----------------------------|
| k8s.gcr.io/kube-apiserver-${ARCH} | v1.8.x | v1.9.x |
| k8s.gcr.io/kube-controller-manager-${ARCH} | v1.8.x | v1.9.x |
| k8s.gcr.io/kube-scheduler-${ARCH} | v1.8.x | v1.9.x |
| k8s.gcr.io/kube-proxy-${ARCH} | v1.8.x | v1.9.x |
| k8s.gcr.io/etcd-${ARCH} | 3.0.17 | 3.1.10 |
| k8s.gcr.io/pause-${ARCH} | 3.0 | 3.0 |
| k8s.gcr.io/k8s-dns-sidecar-${ARCH} | 1.14.5 | 1.14.7 |
| k8s.gcr.io/k8s-dns-kube-dns-${ARCH} | 1.14.5 | 1.14.7 |
| k8s.gcr.io/k8s-dns-dnsmasq-nanny-${ARCH} | 1.14.5 | 1.14.7 |
Here `v1.8.x` means the "latest patch release of the v1.8 branch".
`${ARCH}` can be one of: `amd64`, `arm`, `arm64`, `ppc64le` or `s390x`.
If using `--feature-gates=CoreDNS=true` image `coredns/coredns:1.0.2` is required (instead of the three `k8s-dns-*` images).
### Automating kubeadm
Rather than copying the token you obtained from `kubeadm init` to each node, as
in the [basic kubeadm tutorial](/docs/setup/independent/create-cluster-kubeadm/), you can parallelize the
token distribution for easier automation. To implement this automation, you must
know the IP address that the master will have after it is started.
1. Generate a token. This token must have the form `<6 character string>.<16
character string>`. More formally, it must match the regex:
`[a-z0-9]{6}\.[a-z0-9]{16}`.
kubeadm can generate a token for you:
```bash
kubeadm token generate
```
1. Start both the master node and the worker nodes concurrently with this token.
As they come up they should find each other and form the cluster. The same
`--token` argument can be used on both `kubeadm init` and `kubeadm join`.
Once the cluster is up, you can grab the admin credentials from the master node
at `/etc/kubernetes/admin.conf` and use that to talk to the cluster.
Note that this style of bootstrap has some relaxed security guarantees because
it does not allow the root CA hash to be validated with
`--discovery-token-ca-cert-hash` (since it's not generated when the nodes are
provisioned). For details, see the [kubeadm join](kubeadm-join.md).
{{% /capture %}}
{{% capture whatsnext %}}
* [kubeadm join](kubeadm-join.md) to bootstrap a Kubernetes worker node and join it to the cluster
* [kubeadm upgrade](kubeadm-upgrade.md) to upgrade a Kubernetes cluster to a newer version
* [kubeadm reset](kubeadm-reset.md) to revert any changes made to this host by `kubeadm init` or `kubeadm join`
{{% /capture %}}
@@ -0,0 +1,238 @@
---
approvers:
- mikedanese
- luxas
- jbeda
title: kubeadm join
content_template: templates/concept
---
{{% capture overview %}}
{{% /capture %}}
{{% capture body %}}
{{< include "generated/kubeadm_join.md" >}}
### The joining workflow
`kubeadm join` bootstraps a Kubernetes worker node and joins it to the cluster.
This action consists of the following steps:
1. kubeadm downloads necessary cluster information from the API server.
By default, it uses the bootstrap token and the CA key hash to verify the
authenticity of that data. The root CA can also be discovered directly via a
file or URL.
1. If kubeadm is invoked with `--feature-gates=DynamicKubeletConfig` enabled,
it first retrieves the kubelet init configuration from the master and writes it to
the disk. When kubelet starts up, kubeadm updates the node `Node.spec.configSource` property of the node.
See [Set Kubelet parameters via a config file](/docs/tasks/administer-cluster/kubelet-config-file/)
and [Reconfigure a Node's Kubelet in a Live Cluster](/docs/tasks/administer-cluster/reconfigure-kubelet/)
for more information about Dynamic Kubelet Configuration.
1. Once the cluster information is known, kubelet can start the TLS bootstrapping
process.
The TLS bootstrap uses the shared token to temporarily authenticate
with the Kubernetes API server to submit a certificate signing request (CSR); by
default the control plane signs this CSR request automatically.
1. Finally, kubeadm configures the local kubelet to connect to the API
server with the definitive identity assigned to the node.
### Discovering what cluster CA to trust
The kubeadm discovery has several options, each with security tradeoffs.
The right method for your environment depends on how you provision nodes and the
security expectations you have about your network and node lifecycles.
#### Token-based discovery with CA pinning
This is the default mode in Kubernetes 1.8 and above. In this mode, kubeadm downloads
the cluster configuration (including root CA) and validates it using the token
as well as validating that the root CA public key matches the provided hash and
that the API server certificate is valid under the root CA.
The CA key hash has the format `sha256:<hex_encoded_hash>`. By default, the hash value is returned in the `kubeadm join` command printed at the end of `kubeadm init` or in the output of `kubeadm token create --print-join-command`. It is in a standard format (see [RFC7469](https://tools.ietf.org/html/rfc7469#section-2.4)) and can also be calculated by 3rd party tools or provisioning systems. For example, using the OpenSSL CLI:
```bash
openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der 2>/dev/null | openssl dgst -sha256 -hex | sed 's/^.* //'
```
**Example `kubeadm join` command:**
```bash
kubeadm join --discovery-token abcdef.1234567890abcdef --discovery-token-ca-cert-hash sha256:1234..cdef 1.2.3.4:6443
```
**Advantages:**
- Allows bootstrapping nodes to securely discover a root of trust for the
master even if other worker nodes or the network are compromised.
- Convenient to execute manually since all of the information required fits
into a single `kubeadm join` command that is easy to copy and paste.
**Disadvantages:**
- The CA hash is not normally known until the master has been provisioned,
which can make it more difficult to build automated provisioning tools that
use kubeadm. By generating your CA in beforehand, you may workaround this
limitation though.
#### Token-based discovery without CA pinning
_This was the default in Kubernetes 1.7 and earlier_, but comes with some
important caveats. This mode relies only on the symmetric token to sign
(HMAC-SHA256) the discovery information that establishes the root of trust for
the master. It's still possible in Kubernetes 1.8 and above using the
`--discovery-token-unsafe-skip-ca-verification` flag, but you should consider
using one of the other modes if possible.
**Example `kubeadm join` command:**
```
kubeadm join --token abcdef.1234567890abcdef --discovery-token-unsafe-skip-ca-verification 1.2.3.4:6443`
```
**Advantages:**
- Still protects against many network-level attacks.
- The token can be generated ahead of time and shared with the master and
worker nodes, which can then bootstrap in parallel without coordination. This
allows it to be used in many provisioning scenarios.
**Disadvantages:**
- If an attacker is able to steal a bootstrap token via some vulnerability,
they can use that token (along with network-level access) to impersonate the
master to other bootstrapping nodes. This may or may not be an appropriate
tradeoff in your environment.
#### File or HTTPS-based discovery
This provides an out-of-band way to establish a root of trust between the master
and bootstrapping nodes. Consider using this mode if you are building automated provisioning
using kubeadm.
**Example `kubeadm join` commands:**
- `kubeadm join --discovery-file path/to/file.conf` (local file)
- `kubeadm join --discovery-file https://url/file.conf` (remote HTTPS URL)
**Advantages:**
- Allows bootstrapping nodes to securely discover a root of trust for the
master even if the network or other worker nodes are compromised.
**Disadvantages:**
- Requires that you have some way to carry the discovery information from
the master to the bootstrapping nodes. This might be possible, for example,
via your cloud provider or provisioning tool. The information in this file is
not secret, but HTTPS or equivalent is required to ensure its integrity.
### Securing your installation even more {#securing-more}
The defaults for kubeadm may not work for everyone. This section documents how to tighten up a kubeadm installation
at the cost of some usability.
#### Turning off auto-approval of node client certificates
By default, there is a CSR auto-approver enabled that basically approves any client certificate request
for a kubelet when a Bootstrap Token was used when authenticating. If you don't want the cluster to
automatically approve kubelet client certs, you can turn it off by executing this command:
```console
$ kubectl delete clusterrole kubeadm:node-autoapprove-bootstrap
```
After that, `kubeadm join` will block until the admin has manually approved the CSR in flight:
```console
$ kubectl get csr
NAME AGE REQUESTOR CONDITION
node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ 18s system:bootstrap:878f07 Pending
$ kubectl certificate approve node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ
certificatesigningrequest "node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ" approved
$ kubectl get csr
NAME AGE REQUESTOR CONDITION
node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ 1m system:bootstrap:878f07 Approved,Issued
```
Only after `kubectl certificate approve` has been run, `kubeadm join` can proceed.
#### Turning off public access to the cluster-info ConfigMap
In order to achieve the joining flow using the token as the only piece of validation information, a
ConfigMap with some data needed for validation of the master's identity is exposed publicly by
default. While there is no private data in this ConfigMap, some users might wish to turn
it off regardless. Doing so will disable the ability to use the `--discovery-token` flag of the
`kubeadm join` flow. Here are the steps to do so:
* Fetch the `cluster-info` file from the API Server:
```console
$ kubectl -n kube-public get cm cluster-info -o yaml | grep "kubeconfig:" -A11 | grep "apiVersion" -A10 | sed "s/ //" | tee cluster-info.yaml
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: <ca-cert>
server: https://<ip>:<port>
name: ""
contexts: []
current-context: ""
kind: Config
preferences: {}
users: []
```
* Use the `cluster-info.yaml` file as an argument to `kubeadm join --discovery-file`.
* Turn off public access to the `cluster-info` ConfigMap:
```console
$ kubectl -n kube-public delete rolebinding kubeadm:bootstrap-signer-clusterinfo
```
These commands should be run after `kubeadm init` but before `kubeadm join`.
### Using kubeadm join with a configuration file {#config-file}
{{< caution >}}
**Caution:** The config file is
still considered alpha and may change in future versions.
{{< /caution >}}
It's possible to configure `kubeadm join` with a configuration file instead of command
line flags, and some more advanced features may only be available as
configuration file options. This file is passed in the `--config` option.
```yaml
apiVersion: kubeadm.k8s.io/v1alpha1
kind: NodeConfiguration
caCertPath: <path|string>
discoveryFile: <path|string>
discoveryToken: <string>
discoveryTokenAPIServers:
- <address|string>
- <address|string>
nodeName: <string>
tlsBootstrapToken: <string>
token: <string>
discoveryTokenCACertHashes:
- <SHA-256 hash|string>
- <SHA-256 hash|string>
discoveryTokenUnsafeSkipCAVerification: <bool>
```
{{% /capture %}}
{{% capture whatsnext %}}
* [kubeadm init](kubeadm-init.md) to bootstrap a Kubernetes master node
* [kubeadm token](kubeadm-token.md) to manage tokens for `kubeadm join`
* [kubeadm reset](kubeadm-reset.md) to revert any changes made to this host by `kubeadm init` or `kubeadm join`
{{% /capture %}}
@@ -0,0 +1,32 @@
---
approvers:
- mikedanese
- luxas
- jbeda
title: kubeadm reset
content_template: templates/concept
---
{{% capture overview %}}
{{% /capture %}}
{{% capture body %}}
{{< include "generated/kubeadm_reset.md" >}}
### External etcd clean up!
`kubeadm reset` will not delete any etcd data if external etcd is used. This means that if you run `kubeadm init` again using the same etcd endpoints, you will see state from previous clusters.
To wipe etcd data it is recommended you use a client like etcdctl, such as:
```bash
etcdctl del "" --prefix
```
See the [etcd documentation](https://github.com/coreos/etcd/tree/master/etcdctl) for more information.
{{% /capture %}}
{{% capture whatsnext %}}
* [kubeadm init](kubeadm-init.md) to bootstrap a Kubernetes master node
* [kubeadm join](kubeadm-join.md) to bootstrap a Kubernetes worker node and join it to the cluster
{{% /capture %}}
@@ -0,0 +1,37 @@
---
approvers:
- mikedanese
- luxas
- jbeda
title: kubeadm token
content_template: templates/concept
---
{{% capture overview %}}
Bootstrap tokens are used for establishing bidirectional trust between a node joining
the cluster and a master node, as described in [authenticating with bootstrap tokens](/docs/admin/bootstrap-tokens/).
`kubeadm init` creates an initial token with a 24-hour TTL. The following commands allow you to manage
such a token and also to create and manage new ones.
{{% /capture %}}
{{% capture body %}}
## kubeadm token create {#cmd-token-create}
{{< include "generated/kubeadm_token_create.md" >}}
## kubeadm token delete {#cmd-token-delete}
{{< include "generated/kubeadm_token_delete.md" >}}
## kubeadm token generate {#cmd-token-generate}
{{< include "generated/kubeadm_token_generate.md" >}}
## kubeadm token list {#cmd-token-list}
{{< include "generated/kubeadm_token_list.md" >}}
{{% /capture %}}
{{% capture whatsnext %}}
* [kubeadm join](kubeadm-join.md) to bootstrap a Kubernetes worker node and join it to the cluster
{{% /capture %}}
@@ -0,0 +1,41 @@
---
approvers:
- mikedanese
- luxas
- jbeda
title: kubeadm upgrade
content_template: templates/concept
---
{{% capture overview %}}
`kubeadm upgrade` is a user-friendly command that wraps complex upgrading logic behind one command, with support
for both planning an upgrade and actually performing it. `kubeadm upgrade` can also be used for downgrading
cluster if necessary.
{{% /capture %}}
{{% capture body %}}
## kubeadm upgrade guidance
Every upgrade process might be a bit different, so we've documented each minor upgrade process individually.
Please check these documents out for more detailed how-to-upgrade guidance:
* [1.6 to 1.7 upgrades](/docs/tasks/administer-cluster/kubeadm-upgrade-1-7/)
* [1.7.x to 1.7.y upgrades](/docs/tasks/administer-cluster/kubeadm-upgrade-1-8/)
* [1.7 to 1.8 upgrades](/docs/tasks/administer-cluster/kubeadm-upgrade-1-8/)
* [1.8.x to 1.8.y upgrades](/docs/tasks/administer-cluster/kubeadm-upgrade-1-8/)
* [1.8.x to 1.9.x upgrades](/docs/tasks/administer-cluster/kubeadm-upgrade-1-9/)
* [1.9.x to 1.9.y upgrades](/docs/tasks/administer-cluster/kubeadm-upgrade-1-9/)
* [1.9.x to 1.9.y HA cluster upgrades](/docs/tasks/administer-cluster/kubeadm-upgrade-ha/)
## kubeadm upgrade plan {#cmd-upgrade-plan}
{{< include "generated/kubeadm_upgrade_plan.md" >}}
## kubeadm upgrade apply {#cmd-upgrade-apply}
{{< include "generated/kubeadm_upgrade_apply.md" >}}
{{% /capture %}}
{{% capture whatsnext %}}
* [kubeadm config](kubeadm-config.md) if you initialized your cluster using kubeadm v1.7.x or lower, to configure your cluster for `kubeadm upgrade`
{{% /capture %}}
@@ -0,0 +1,16 @@
---
approvers:
- mikedanese
- luxas
- jbeda
title: kubeadm version
content_template: templates/concept
---
{{% capture overview %}}
{{% /capture %}}
{{% capture body %}}
{{< include "generated/kubeadm_version.md" >}}
{{% /capture %}}
@@ -0,0 +1,21 @@
---
approvers:
- mikedanese
- luxas
- jbeda
title: Overview of kubeadm
---
<img src="https://raw.githubusercontent.com/cncf/artwork/master/kubernetes/certified-kubernetes/versionless/color/certified-kubernetes-color.png" align="right" width="150px">Kubeadm is a tool built to provide `kubeadm init` and `kubeadm join` as best-practice “fast paths” for creating Kubernetes clusters.
kubeadm performs the actions necessary to get a minimum viable cluster up and running. By design, it cares only about bootstrapping, not about provisioning machines. Likewise, installing various nice-to-have addons, like the Kubernetes Dashboard, monitoring solutions, and cloud-specific addons, is not in scope.
Instead, we expect higher-level and more tailored tooling to be built on top of kubeadm, and ideally, using kubeadm as the basis of all deployments will make it easier to create conformant clusters.
## What's next
* [kubeadm init](kubeadm-init.md) to bootstrap a Kubernetes master node
* [kubeadm join](kubeadm-join.md) to bootstrap a Kubernetes worker node and join it to the cluster
* [kubeadm upgrade](kubeadm-upgrade.md) to upgrade a Kubernetes cluster to a newer version
* [kubeadm config](kubeadm-config.md) if you initialized your cluster using kubeadm v1.7.x or lower, to configure your cluster for `kubeadm upgrade`
* [kubeadm token](kubeadm-token.md) to manage tokens for `kubeadm join`
* [kubeadm reset](kubeadm-reset.md) to revert any changes made to this host by `kubeadm init` or `kubeadm join`