add content_type param, kubeadm pages
add no_list, clean up toc-hide paramspull/23048/head
Karen Bradshaw
parent
14b7c1115c
commit
1e0c500571
|
|
@ -1,5 +1,4 @@
|
|||
---
|
||||
title: Accessing the API
|
||||
weight: 20
|
||||
toc-hide: true
|
||||
---
|
||||
|
|
@ -1,5 +1,4 @@
|
|||
---
|
||||
title: Command line tools reference
|
||||
weight: 60
|
||||
toc-hide: true
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,5 +1,4 @@
|
|||
---
|
||||
title: Kubernetes Issues and Security
|
||||
weight: 10
|
||||
toc-hide: true
|
||||
---
|
||||
|
|
@ -1,5 +1,4 @@
|
|||
---
|
||||
title: Setup tools reference
|
||||
weight: 50
|
||||
toc-hide: true
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: "Kubeadm"
|
||||
weight: 10
|
||||
toc-hide: true
|
||||
no_list: true
|
||||
---
|
||||
|
|
|
|||
|
|
@ -15,7 +15,6 @@ However, it might not be obvious _how_ kubeadm does that.
|
|||
|
||||
This document provides additional details on what happen under the hood, with the aim of sharing knowledge on Kubernetes cluster best practices.
|
||||
|
||||
|
||||
<!-- body -->
|
||||
## Core design principles
|
||||
|
||||
|
|
@ -518,6 +517,7 @@ Please note that:
|
|||
- The automatic CSR approval is managed by the csrapprover controller, according with configuration done the `kubeadm init` process
|
||||
|
||||
### (optional) Write init kubelet configuration
|
||||
|
||||
{{< feature-state for_k8s_version="v1.9" state="alpha" >}}
|
||||
|
||||
If kubeadm is invoked with `--feature-gates=DynamicKubeletConfig`:
|
||||
|
|
@ -530,5 +530,3 @@ If kubeadm is invoked with `--feature-gates=DynamicKubeletConfig`:
|
|||
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`
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -3,8 +3,10 @@ reviewers:
|
|||
- luxas
|
||||
- jbeda
|
||||
title: kubeadm alpha
|
||||
content_type: concept
|
||||
weight: 90
|
||||
---
|
||||
|
||||
{{< 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!
|
||||
|
|
@ -67,7 +69,6 @@ Use the following command to enable the DynamicKubeletConfiguration feature.
|
|||
{{< tab name="enable-dynamic" include="generated/kubeadm_alpha_kubelet_config_enable-dynamic.md" />}}
|
||||
{{< /tabs >}}
|
||||
|
||||
|
||||
## kubeadm alpha selfhosting pivot {#cmd-selfhosting}
|
||||
|
||||
The subcommand `pivot` can be used to convert a static Pod-hosted control plane into a self-hosted one.
|
||||
|
|
@ -79,8 +80,8 @@ The subcommand `pivot` can be used to convert a static Pod-hosted control plane
|
|||
{{< tab name="pivot" include="generated/kubeadm_alpha_selfhosting_pivot.md" />}}
|
||||
{{< /tabs >}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
## What's next
|
||||
* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/) to bootstrap a Kubernetes control-plane node
|
||||
* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) to connect a node to the cluster
|
||||
* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) to revert any changes made to this host by `kubeadm init` or `kubeadm join`
|
||||
|
|
|
|||
|
|
@ -6,6 +6,7 @@ title: kubeadm config
|
|||
content_type: concept
|
||||
weight: 50
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
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
|
||||
|
|
@ -19,30 +20,31 @@ In Kubernetes v1.13.0 and later to list/pull kube-dns images instead of the Core
|
|||
the `--config` method described [here](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-addon)
|
||||
has to be used.
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
## kubeadm config view {#cmd-config-view}
|
||||
|
||||
{{< include "generated/kubeadm_config_view.md" >}}
|
||||
|
||||
## kubeadm config print init-defaults {#cmd-config-print-init-defaults}
|
||||
|
||||
{{< include "generated/kubeadm_config_print_init-defaults.md" >}}
|
||||
|
||||
## kubeadm config print join-defaults {#cmd-config-print-join-defaults}
|
||||
|
||||
{{< include "generated/kubeadm_config_print_join-defaults.md" >}}
|
||||
|
||||
## kubeadm config migrate {#cmd-config-migrate}
|
||||
|
||||
{{< include "generated/kubeadm_config_migrate.md" >}}
|
||||
|
||||
## kubeadm config images list {#cmd-config-images-list}
|
||||
|
||||
{{< include "generated/kubeadm_config_images_list.md" >}}
|
||||
|
||||
## kubeadm config images pull {#cmd-config-images-pull}
|
||||
|
||||
{{< include "generated/kubeadm_config_images_pull.md" >}}
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade/) to upgrade a Kubernetes cluster to a newer version
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,9 @@
|
|||
---
|
||||
title: kubeadm init phase
|
||||
weight: 90
|
||||
content_type: concept
|
||||
---
|
||||
|
||||
`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.
|
||||
|
|
@ -80,7 +82,6 @@ Use the following phase to create a local etcd instance based on a static Pod fi
|
|||
{{< tab name="local" include="generated/kubeadm_init_phase_etcd_local.md" />}}
|
||||
{{< /tabs >}}
|
||||
|
||||
|
||||
## kubeadm init phase upload-config {#cmd-phase-upload-config}
|
||||
|
||||
You can use this command to upload the kubeadm configuration to your cluster.
|
||||
|
|
@ -93,7 +94,6 @@ Alternatively, you can use [kubeadm config](/docs/reference/setup-tools/kubeadm/
|
|||
{{< tab name="kubelet" include="generated/kubeadm_init_phase_upload-config_kubelet.md" />}}
|
||||
{{< /tabs >}}
|
||||
|
||||
|
||||
## kubeadm init phase upload-certs {#cmd-phase-upload-certs}
|
||||
|
||||
Use the following phase to upload control-plane certificates to the cluster.
|
||||
|
|
@ -103,7 +103,6 @@ By default the certs and encryption key expire after two hours.
|
|||
{{< tab name="upload-certs" include="generated/kubeadm_init_phase_upload-certs.md" />}}
|
||||
{{< /tabs >}}
|
||||
|
||||
|
||||
## kubeadm init phase mark-control-plane {#cmd-phase-mark-control-plane}
|
||||
|
||||
Use the following phase to label and taint the node with the `node-role.kubernetes.io/master=""` key-value pair.
|
||||
|
|
@ -112,7 +111,6 @@ Use the following phase to label and taint the node with the `node-role.kubernet
|
|||
{{< tab name="mark-control-plane" include="generated/kubeadm_init_phase_mark-control-plane.md" />}}
|
||||
{{< /tabs >}}
|
||||
|
||||
|
||||
## kubeadm init phase bootstrap-token {#cmd-phase-bootstrap-token}
|
||||
|
||||
Use the following phase to configure bootstrap tokens.
|
||||
|
|
@ -156,7 +154,8 @@ Please note that kube-dns usage with kubeadm is deprecated as of v1.18 and will
|
|||
For more details on each field in the `v1beta2` configuration you can navigate to our
|
||||
[API reference pages.] (https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2)
|
||||
|
||||
## What's next
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/) to bootstrap a Kubernetes control-plane node
|
||||
* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) to connect a node to the cluster
|
||||
* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) to revert any changes made to this host by `kubeadm init` or `kubeadm join`
|
||||
|
|
|
|||
|
|
@ -9,12 +9,12 @@ weight: 20
|
|||
<!-- overview -->
|
||||
This command initializes a Kubernetes control-plane node.
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
{{< include "generated/kubeadm_init.md" >}}
|
||||
|
||||
### Init workflow {#init-workflow}
|
||||
|
||||
`kubeadm init` bootstraps a Kubernetes control-plane node by executing the
|
||||
following steps:
|
||||
|
||||
|
|
@ -166,7 +166,7 @@ to download the certificates when additional control-plane nodes are joining, by
|
|||
|
||||
The following phase command can be used to re-upload the certificates after expiration:
|
||||
|
||||
```
|
||||
```shell
|
||||
kubeadm init phase upload-certs --upload-certs --certificate-key=SOME_VALUE --config=SOME_YAML_FILE
|
||||
```
|
||||
|
||||
|
|
@ -175,7 +175,7 @@ If the flag `--certificate-key` is not passed to `kubeadm init` and
|
|||
|
||||
The following command can be used to generate a new key on demand:
|
||||
|
||||
```
|
||||
```shell
|
||||
kubeadm alpha certs certificate-key
|
||||
```
|
||||
|
||||
|
|
@ -226,26 +226,26 @@ 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,
|
||||
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:
|
||||
`[a-z0-9]{6}\.[a-z0-9]{16}`.
|
||||
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:
|
||||
kubeadm can generate a token for you:
|
||||
|
||||
```shell
|
||||
```shell
|
||||
kubeadm token generate
|
||||
```
|
||||
```
|
||||
|
||||
1. Start both the control-plane 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`.
|
||||
1. Start both the control-plane 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`.
|
||||
|
||||
1. Similar can be done for `--certificate-key` when joining additional control-plane
|
||||
nodes. The key can be generated using:
|
||||
1. Similar can be done for `--certificate-key` when joining additional control-plane
|
||||
nodes. The key can be generated using:
|
||||
|
||||
```shell
|
||||
kubeadm alpha certs certificate-key
|
||||
```
|
||||
```shell
|
||||
kubeadm alpha certs certificate-key
|
||||
```
|
||||
|
||||
Once the cluster is up, you can grab the admin credentials from the control-plane node
|
||||
at `/etc/kubernetes/admin.conf` and use that to talk to the cluster.
|
||||
|
|
@ -255,8 +255,6 @@ 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](/docs/reference/setup-tools/kubeadm/kubeadm-join/).
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* [kubeadm init phase](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/) to understand more about
|
||||
|
|
@ -264,4 +262,3 @@ provisioned). For details, see the [kubeadm join](/docs/reference/setup-tools/ku
|
|||
* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) to bootstrap a Kubernetes worker node and join it to the cluster
|
||||
* [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade/) to upgrade a Kubernetes cluster to a newer version
|
||||
* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) to revert any changes made to this host by `kubeadm init` or `kubeadm join`
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,9 @@
|
|||
---
|
||||
title: kubeadm join phase
|
||||
weight: 90
|
||||
content_type: concept
|
||||
---
|
||||
|
||||
`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.
|
||||
|
|
@ -56,7 +58,8 @@ Using this phase you can join a node as a control-plane instance.
|
|||
{{< tab name="mark-control-plane" include="generated/kubeadm_join_phase_control-plane-join_mark-control-plane.md" />}}
|
||||
{{< /tabs >}}
|
||||
|
||||
## What's next
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/) to bootstrap a Kubernetes control-plane node
|
||||
* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) to connect a node to the cluster
|
||||
* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) to revert any changes made to this host by `kubeadm init` or `kubeadm join`
|
||||
|
|
|
|||
|
|
@ -9,7 +9,6 @@ weight: 30
|
|||
<!-- overview -->
|
||||
This command initializes a Kubernetes worker node and joins it to the cluster.
|
||||
|
||||
|
||||
<!-- body -->
|
||||
{{< include "generated/kubeadm_join.md" >}}
|
||||
|
||||
|
|
@ -105,18 +104,18 @@ if the `kubeadm init` command was called with `--upload-certs`.
|
|||
|
||||
**Advantages:**
|
||||
|
||||
- Allows bootstrapping nodes to securely discover a root of trust for the
|
||||
control-plane node even if other worker nodes or the network are compromised.
|
||||
- Allows bootstrapping nodes to securely discover a root of trust for the
|
||||
control-plane node 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.
|
||||
- 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 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.
|
||||
- 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.
|
||||
|
||||
#### Token-based discovery without CA pinning
|
||||
|
||||
|
|
@ -134,18 +133,18 @@ kubeadm join --token abcdef.1234567890abcdef --discovery-token-unsafe-skip-ca-ve
|
|||
|
||||
**Advantages:**
|
||||
|
||||
- Still protects against many network-level attacks.
|
||||
- Still protects against many network-level attacks.
|
||||
|
||||
- The token can be generated ahead of time and shared with the control-plane node and
|
||||
worker nodes, which can then bootstrap in parallel without coordination. This
|
||||
allows it to be used in many provisioning scenarios.
|
||||
- The token can be generated ahead of time and shared with the control-plane node 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
|
||||
control-plane node to other bootstrapping nodes. This may or may not be an appropriate
|
||||
tradeoff in your environment.
|
||||
- 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
|
||||
control-plane node to other bootstrapping nodes. This may or may not be an appropriate
|
||||
tradeoff in your environment.
|
||||
|
||||
#### File or HTTPS-based discovery
|
||||
|
||||
|
|
@ -158,21 +157,21 @@ In case the discovery file does not contain credentials, the TLS discovery token
|
|||
|
||||
**Example `kubeadm join` commands:**
|
||||
|
||||
- `kubeadm join --discovery-file path/to/file.conf` (local file)
|
||||
- `kubeadm join --discovery-file path/to/file.conf` (local file)
|
||||
|
||||
- `kubeadm join --discovery-file https://url/file.conf` (remote HTTPS URL)
|
||||
- `kubeadm join --discovery-file https://url/file.conf` (remote HTTPS URL)
|
||||
|
||||
**Advantages:**
|
||||
|
||||
- Allows bootstrapping nodes to securely discover a root of trust for the
|
||||
control-plane node even if the network or other worker nodes are compromised.
|
||||
- Allows bootstrapping nodes to securely discover a root of trust for the
|
||||
control-plane node even if the network or other worker nodes are compromised.
|
||||
|
||||
**Disadvantages:**
|
||||
|
||||
- Requires that you have some way to carry the discovery information from
|
||||
the control-plane node to the bootstrapping nodes. If the discovery file contains credentials
|
||||
you must keep it secret and transfer it over a secure channel. This might be possible with your
|
||||
cloud provider or provisioning tool.
|
||||
- Requires that you have some way to carry the discovery information from
|
||||
the control-plane node to the bootstrapping nodes. If the discovery file contains credentials
|
||||
you must keep it secret and transfer it over a secure channel. This might be possible with your
|
||||
cloud provider or provisioning tool.
|
||||
|
||||
### Securing your installation even more {#securing-more}
|
||||
|
||||
|
|
@ -194,7 +193,9 @@ After that, `kubeadm join` will block until the admin has manually approved the
|
|||
```shell
|
||||
kubectl get csr
|
||||
```
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
```
|
||||
NAME AGE REQUESTOR CONDITION
|
||||
node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ 18s system:bootstrap:878f07 Pending
|
||||
|
|
@ -203,7 +204,9 @@ node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ 18s system:bootstra
|
|||
```shell
|
||||
kubectl certificate approve node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ
|
||||
```
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
```
|
||||
certificatesigningrequest "node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ" approved
|
||||
```
|
||||
|
|
@ -211,7 +214,9 @@ certificatesigningrequest "node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ"
|
|||
```shell
|
||||
kubectl get csr
|
||||
```
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
```
|
||||
NAME AGE REQUESTOR CONDITION
|
||||
node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ 1m system:bootstrap:878f07 Approved,Issued
|
||||
|
|
@ -232,7 +237,9 @@ it off regardless. Doing so will disable the ability to use the `--discovery-tok
|
|||
```shell
|
||||
kubectl -n kube-public get cm cluster-info -o yaml | grep "kubeconfig:" -A11 | grep "apiVersion" -A10 | sed "s/ //" | tee cluster-info.yaml
|
||||
```
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
```
|
||||
apiVersion: v1
|
||||
kind: Config
|
||||
|
|
@ -276,11 +283,8 @@ kubeadm config print join-defaults
|
|||
|
||||
For details on individual fields in `JoinConfiguration` see [the godoc](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm#JoinConfiguration).
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/) to bootstrap a Kubernetes control-plane node
|
||||
* [kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token/) to manage tokens for `kubeadm join`
|
||||
* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) to revert any changes made to this host by `kubeadm init` or `kubeadm join`
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,9 @@
|
|||
---
|
||||
title: kubeadm reset phase
|
||||
weight: 90
|
||||
content_type: concept
|
||||
---
|
||||
|
||||
`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.
|
||||
|
|
@ -47,7 +49,8 @@ Using this phase you can perform cleanup on this node.
|
|||
{{< tab name="cleanup-node" include="generated/kubeadm_reset_phase_cleanup-node.md" />}}
|
||||
{{< /tabs >}}
|
||||
|
||||
## What's next
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/) to bootstrap a Kubernetes control-plane node
|
||||
* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) to connect a node to the cluster
|
||||
* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) to revert any changes made to this host by `kubeadm init` or `kubeadm join`
|
||||
|
|
|
|||
|
|
@ -9,7 +9,6 @@ weight: 60
|
|||
<!-- overview -->
|
||||
Performs a best effort revert of changes made by `kubeadm init` or `kubeadm join`.
|
||||
|
||||
|
||||
<!-- body -->
|
||||
{{< include "generated/kubeadm_reset.md" >}}
|
||||
|
||||
|
|
@ -36,9 +35,7 @@ etcdctl del "" --prefix
|
|||
|
||||
See the [etcd documentation](https://github.com/coreos/etcd/tree/master/etcdctl) for more information.
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/) to bootstrap a Kubernetes control-plane node
|
||||
* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) to bootstrap a Kubernetes worker node and join it to the cluster
|
||||
|
||||
|
|
|
|||
|
|
@ -14,8 +14,6 @@ the cluster and a control-plane node, as described in [authenticating with boots
|
|||
`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.
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
## kubeadm token create {#cmd-token-create}
|
||||
{{< include "generated/kubeadm_token_create.md" >}}
|
||||
|
|
@ -29,8 +27,6 @@ such a token and also to create and manage new ones.
|
|||
## kubeadm token list {#cmd-token-list}
|
||||
{{< include "generated/kubeadm_token_list.md" >}}
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) to bootstrap a Kubernetes worker node and join it to the cluster
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,7 @@
|
|||
---
|
||||
title: kubeadm upgrade phase
|
||||
weight: 90
|
||||
content_type: concept
|
||||
---
|
||||
In v1.15.0, kubeadm introduced preliminary support for `kubeadm upgrade node` phases.
|
||||
Phases for other `kubeadm upgrade` sub-commands such as `apply`, could be added in the
|
||||
|
|
@ -18,7 +19,8 @@ be called on a primary control-plane node.
|
|||
{{< tab name="kubelet-config" include="generated/kubeadm_upgrade_node_phase_kubelet-config.md" />}}
|
||||
{{< /tabs >}}
|
||||
|
||||
## What's next
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/) to bootstrap a Kubernetes control-plane node
|
||||
* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) to connect a node to the cluster
|
||||
* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) to revert any changes made to this host by `kubeadm init` or `kubeadm join`
|
||||
|
|
|
|||
|
|
@ -47,8 +47,6 @@ reports of unexpected results.
|
|||
{{< include "generated/kubeadm_upgrade_node.md" >}}
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* [kubeadm config](/docs/reference/setup-tools/kubeadm/kubeadm-config/) if you initialized your cluster using kubeadm v1.7.x or lower, to configure your cluster for `kubeadm upgrade`
|
||||
|
||||
|
|
|
|||
|
|
@ -9,7 +9,5 @@ weight: 80
|
|||
<!-- overview -->
|
||||
This command prints the version of kubeadm.
|
||||
|
||||
|
||||
<!-- body -->
|
||||
{{< include "generated/kubeadm_version.md" >}}
|
||||
|
||||
|
|
|
|||
|
|
@ -4,10 +4,12 @@ reviewers:
|
|||
- jbeda
|
||||
title: Overview of kubeadm
|
||||
weight: 10
|
||||
content_type: concept
|
||||
card:
|
||||
name: reference
|
||||
weight: 40
|
||||
---
|
||||
|
||||
<img src="https://raw.githubusercontent.com/kubernetes/kubeadm/master/logos/stacked/color/kubeadm-stacked-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.
|
||||
|
|
@ -18,7 +20,7 @@ Instead, we expect higher-level and more tailored tooling to be built on top of
|
|||
|
||||
To install kubeadm, see the [installation guide](/docs/setup/production-environment/tools/kubeadm/install-kubeadm).
|
||||
|
||||
## What's next
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init) to bootstrap a Kubernetes control-plane node
|
||||
* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join) to bootstrap a Kubernetes worker node and join it to the cluster
|
||||
|
|
|
|||
|
|
@ -1,5 +1,4 @@
|
|||
---
|
||||
title: Using the Kubernetes API
|
||||
weight: 10
|
||||
toc-hide: true
|
||||
---
|
||||
Loading…
Reference in New Issue