kubeadm: update reference documentation for 1.16 (#16014)
Lubomir I. Ivanov
Kubernetes Prow Robot
parent
420afb2d9f
commit
bd9a46b1b9
|
|
@ -8,13 +8,9 @@ content_template: templates/concept
|
|||
weight: 50
|
||||
---
|
||||
{{% 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`.
|
||||
During `kubeadm init`, kubeadm uploads the `ClusterConfiguration` object to your cluster
|
||||
in a ConfigMap called `kubeadm-config` in the `kube-system` namespace. This configuration is then read during
|
||||
`kubeadm join`, `kubeadm reset` and `kubeadm upgrade`. To view this ConfigMap call `kubeadm config view`.
|
||||
|
||||
You can use `kubeadm config print` to print the default configuration and `kubeadm config migrate` to
|
||||
convert your old configuration files to a newer version. `kubeadm config images list` and
|
||||
|
|
|
|||
|
|
@ -2,7 +2,9 @@
|
|||
title: kubeadm init phase
|
||||
weight: 90
|
||||
---
|
||||
In v1.8.0, kubeadm introduced the `kubeadm alpha phase` command with the aim of making kubeadm more modular. In v1.13.0 this command graduated to `kubeadm init phase`. This modularity enables you to invoke atomic sub-steps of the bootstrap process. Hence, you can let kubeadm do some parts and fill in yourself where you need customizations.
|
||||
`kubeadm init phase` enables you to invoke atomic steps of the bootstrap process.
|
||||
Hence, you can let kubeadm do some of the work and you can fill in the gaps
|
||||
if you wish to apply customization.
|
||||
|
||||
`kubeadm init phase` is consistent with the [kubeadm init workflow](/docs/reference/setup-tools/kubeadm/kubeadm-init/#init-workflow),
|
||||
and behind the scene both use the same code.
|
||||
|
|
|
|||
|
|
@ -37,7 +37,7 @@ following steps:
|
|||
kubeconfig file for administration named `admin.conf`.
|
||||
|
||||
1. Generates static Pod manifests for the API server,
|
||||
controller manager and scheduler. In case an external etcd is not provided,
|
||||
controller-manager and scheduler. In case an external etcd is not provided,
|
||||
an additional static Pod manifest is generated for etcd.
|
||||
|
||||
Static Pod manifests are written to `/etc/kubernetes/manifests`; the kubelet
|
||||
|
|
@ -75,7 +75,7 @@ following steps:
|
|||
|
||||
### Using init phases with kubeadm {#init-phases}
|
||||
|
||||
Kubeadm allows you create a control-plane node in phases. In 1.13 the `kubeadm init phase` command has graduated to GA from it’s previous alpha state under `kubeadm alpha phase`.
|
||||
Kubeadm allows you to create a control-plane node in phases using the `kubeadm init phase` command.
|
||||
|
||||
To view the ordered list of phases and sub-phases you can call `kubeadm init --help`. The list will be located at the top of the help screen and each phase will have a description next to it.
|
||||
Note that by calling `kubeadm init` all of the phases and sub-phases will be executed in this exact order.
|
||||
|
|
@ -113,9 +113,9 @@ The config file is still considered beta and may change in future versions.
|
|||
|
||||
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.
|
||||
configuration file options. This file is passed with the `--config` option.
|
||||
|
||||
In Kubernetes 1.11 and later, the default configuration can be printed out using the
|
||||
The default configuration can be printed out using the
|
||||
[kubeadm config print](/docs/reference/setup-tools/kubeadm/kubeadm-config/) command.
|
||||
|
||||
It is **recommended** that you migrate your old `v1beta1` configuration to `v1beta2` using
|
||||
|
|
@ -139,8 +139,8 @@ For information about passing flags to control plane components see:
|
|||
|
||||
### 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,
|
||||
By default, kubeadm pulls images from `k8s.gcr.io`. If the
|
||||
requested Kubernetes version is a CI label (such as `ci/latest`)
|
||||
`gcr.io/kubernetes-ci-images` is used.
|
||||
|
||||
You can override this behavior by using [kubeadm with a configuration file](#config-file).
|
||||
|
|
@ -187,11 +187,10 @@ 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.
|
||||
If a given certificate and private key pair exists before running `kubeadm init`,
|
||||
kubeadm will not overwrite them. 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 certificates.
|
||||
|
||||
#### External CA mode {#external-ca-mode}
|
||||
|
||||
|
|
@ -212,47 +211,14 @@ For further information, see [Managing the kubeadm drop-in file for systemd](/do
|
|||
|
||||
### Use kubeadm with 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)
|
||||
|
||||
Refer to the [CRI installation instructions](/docs/setup/cri) for more information.
|
||||
|
||||
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.
|
||||
By default kubeadm attempts to detect your container runtime. For more details on this detection, see
|
||||
the [kubeadm CRI installation guide](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-runtime).
|
||||
|
||||
### Setting the node name
|
||||
|
||||
By default, `kubeadm` assigns a node name based on a machine's host address. You can override this setting with the `--node-name`flag.
|
||||
By default, `kubeadm` assigns a node name based on a machine's host address. You can override this setting with the `--node-name` flag.
|
||||
The flag passes the appropriate [`--hostname-override`](/docs/reference/command-line-tools-reference/kubelet/#options)
|
||||
to the kubelet.
|
||||
value to the kubelet.
|
||||
|
||||
Be aware that overriding the hostname can [interfere with cloud providers](https://github.com/kubernetes/website/pull/8873).
|
||||
|
||||
|
|
@ -260,25 +226,25 @@ Be aware that overriding the hostname can [interfere with cloud providers](https
|
|||
|
||||
For running kubeadm without an internet connection you have to pre-pull the required control-plane images.
|
||||
|
||||
In Kubernetes 1.11 and later, you can list and pull the images using the `kubeadm config images` sub-command:
|
||||
You can list and pull the images using the `kubeadm config images` sub-command:
|
||||
|
||||
```shell
|
||||
kubeadm config images list
|
||||
kubeadm config images pull
|
||||
```
|
||||
|
||||
In Kubernetes 1.12 and later, the `k8s.gcr.io/kube-*`, `k8s.gcr.io/etcd` and `k8s.gcr.io/pause` images
|
||||
don't require an `-${ARCH}` suffix.
|
||||
All images that kubeadm requires such as `k8s.gcr.io/kube-*`, `k8s.gcr.io/etcd` and `k8s.gcr.io/pause` support multiple architectures.
|
||||
|
||||
### Automating kubeadm
|
||||
|
||||
Rather than copying the token you obtained from `kubeadm init` to each node, as
|
||||
in the [basic kubeadm tutorial](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/), you can parallelize the
|
||||
token distribution for easier automation. To implement this automation, you must
|
||||
know the IP address that the control-plane node will have after it is started.
|
||||
know the IP address that the control-plane node will have after it is started,
|
||||
or use a DNS name or an address of a load balancer.
|
||||
|
||||
1. Generate a token. This token must have the form `<6 character string>.<16
|
||||
character string>`. More formally, it must match the regex:
|
||||
character string>`. More formally, it must match the regex:
|
||||
`[a-z0-9]{6}\.[a-z0-9]{16}`.
|
||||
|
||||
kubeadm can generate a token for you:
|
||||
|
|
|
|||
|
|
@ -2,8 +2,9 @@
|
|||
title: kubeadm join phase
|
||||
weight: 90
|
||||
---
|
||||
In v1.14.0, kubeadm introduces the `kubeadm join phase` command with the aim of making kubeadm more modular. This modularity enables you to invoke atomic sub-steps of the join process.
|
||||
Hence, you can let kubeadm do some parts and fill in yourself where you need customizations.
|
||||
`kubeadm join phase` enables you to invoke atomic steps of the join process.
|
||||
Hence, you can let kubeadm do some of the work and you can fill in the gaps
|
||||
if you wish to apply customization.
|
||||
|
||||
`kubeadm join phase` is consistent with the [kubeadm join workflow](/docs/reference/setup-tools/kubeadm/kubeadm-join/#join-workflow),
|
||||
and behind the scene both use the same code.
|
||||
|
|
|
|||
|
|
@ -47,7 +47,7 @@ For control-plane nodes additional steps are performed:
|
|||
|
||||
### Using join phases with kubeadm {#join-phases}
|
||||
|
||||
Kubeadm allows you join a node to the cluster in phases. The `kubeadm join phase` command was added in v1.14.0.
|
||||
Kubeadm allows you join a node to the cluster in phases using `kubeadm join phase`.
|
||||
|
||||
To view the ordered list of phases and sub-phases you can call `kubeadm join --help`. The list will be located
|
||||
at the top of the help screen and each phase will have a description next to it.
|
||||
|
|
@ -76,7 +76,7 @@ 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
|
||||
This is the default mode in kubeadm. 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.
|
||||
|
|
@ -117,15 +117,14 @@ if the `kubeadm init` command was called with `--upload-certs`.
|
|||
- The CA hash is not normally known until the control-plane node 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.
|
||||
limitation.
|
||||
|
||||
#### 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
|
||||
This mode relies only on the symmetric token to sign
|
||||
(HMAC-SHA256) the discovery information that establishes the root of trust for
|
||||
the control-plane. It's still possible in Kubernetes 1.8 and above using the
|
||||
`--discovery-token-unsafe-skip-ca-verification` flag, but you should consider
|
||||
the control-plane. To use the mode the joining nodes must skip the hash validation of the
|
||||
CA public key, using `--discovery-token-unsafe-skip-ca-verification`. You should consider
|
||||
using one of the other modes if possible.
|
||||
|
||||
**Example `kubeadm join` command:**
|
||||
|
|
@ -150,9 +149,13 @@ kubeadm join --token abcdef.1234567890abcdef --discovery-token-unsafe-skip-ca-ve
|
|||
tradeoff in your environment.
|
||||
|
||||
#### File or HTTPS-based discovery
|
||||
|
||||
This provides an out-of-band way to establish a root of trust between the control-plane node
|
||||
and bootstrapping nodes. Consider using this mode if you are building automated provisioning
|
||||
using kubeadm.
|
||||
and bootstrapping nodes. Consider using this mode if you are building automated provisioning
|
||||
using kubeadm. The format of the discovery file is a regular Kubernetes
|
||||
[kubeconfig](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) file.
|
||||
|
||||
In case the discovery file does not contain credentials, the TLS discovery token will be used.
|
||||
|
||||
**Example `kubeadm join` commands:**
|
||||
|
||||
|
|
@ -215,7 +218,7 @@ NAME AGE REQUESTOR
|
|||
node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ 1m system:bootstrap:878f07 Approved,Issued
|
||||
```
|
||||
|
||||
Only after `kubectl certificate approve` has been run, `kubeadm join` can proceed.
|
||||
This forces the workflow that `kubeadm join` will only succeed if `kubectl certificate approve` has been run.
|
||||
|
||||
#### Turning off public access to the cluster-info ConfigMap
|
||||
|
||||
|
|
|
|||
|
|
@ -2,8 +2,9 @@
|
|||
title: kubeadm reset phase
|
||||
weight: 90
|
||||
---
|
||||
In v1.15.0, kubeadm introduces the `kubeadm reset phase` command with the aim of making kubeadm more modular. This modularity enables you to invoke atomic sub-steps of the reset process.
|
||||
Hence, you can let kubeadm do some parts and fill in yourself where you need customizations.
|
||||
`kubeadm reset phase` enables you to invoke atomic steps of the node reset process.
|
||||
Hence, you can let kubeadm do some of the work and you can fill in the gaps
|
||||
if you wish to apply customization.
|
||||
|
||||
`kubeadm reset phase` is consistent with the [kubeadm reset workflow](/docs/reference/setup-tools/kubeadm/kubeadm-reset/#reset-workflow),
|
||||
and behind the scene both use the same code.
|
||||
|
|
|
|||
|
|
@ -8,26 +8,18 @@ content_template: templates/concept
|
|||
weight: 40
|
||||
---
|
||||
{{% 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.
|
||||
`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.
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## kubeadm upgrade guidance
|
||||
|
||||
Every upgrade process might be a bit different, so we've documented each minor upgrade process individually.
|
||||
For more version-specific upgrade guidance, see the following resources:
|
||||
The steps for performing a upgrade using kubeadm are outlined in [this document](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/).
|
||||
For older versions of kubeadm, please refer to older documentation sets of the Kubernetes website.
|
||||
|
||||
* [1.12 to 1.13 upgrades](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-13/)
|
||||
* [1.13 to 1.14 upgrades](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-14/)
|
||||
* [1.14 to 1.15 upgrades](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-15/)
|
||||
|
||||
_For older versions, please refer to older documentation sets on the Kubernetes website._
|
||||
|
||||
In Kubernetes v1.11.0 and later, you can use `kubeadm upgrade diff` to see the changes that would be
|
||||
applied to static pod manifests.
|
||||
You can use `kubeadm upgrade diff` to see the changes that would be applied to static pod manifests.
|
||||
|
||||
To use kube-dns with upgrades in Kubernetes v1.13.0 and later please follow [this guide](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-addon).
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue