whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

kubeadm: update reference documentation for 1.16 (#16014)

Browse Source
This commit is contained in:
Lubomir I. Ivanov
2019-09-07 01:35:19 +03:00
committed by Kubernetes Prow Robot
parent 420afb2d9f
commit bd9a46b1b9
7 changed files with 49 additions and 88 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md
+19 -53
View File
@@ -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: