update bootstrap-token links (#9456)
This commit is contained in:
Bob Killen
k8s-ci-robot
parent
bf109b4dfa
commit
78eafc7c22
|
|
@ -16,7 +16,7 @@ For users who want to scale beyond 5,000 nodes or spread across multiple regions
|
|||
|
||||
**Security and Setup** : Users concerned with security will find that [RBAC](https://kubernetes.io//docs/admin/authorization/rbac), now _beta_ adds a significant security benefit through more tightly scoped default roles for system components. The default RBAC policies in 1.6 grant scoped permissions to control-plane components, nodes, and controllers. RBAC allows cluster administrators to selectively grant particular users or service accounts fine-grained access to specific resources on a per-namespace basis. RBAC users upgrading from 1.5 to 1.6 should view the guidance [here](https://kubernetes.io//docs/admin/authorization/rbac.md#upgrading-from-15).
|
||||
|
||||
Users looking for an easy way to provision a secure cluster on physical or cloud servers can use [kubeadm](https://kubernetes.io/docs/getting-started-guides/kubeadm/), which is now _beta_. kubeadm has been enhanced with a set of command line flags and a base feature set that includes RBAC setup, use of the [Bootstrap Token system](http://kubernetes.io/docs/admin/bootstrap-tokens/) and an enhanced [Certificates API](https://kubernetes.io/docs/tasks/tls/managing-tls-in-a-cluster/).
|
||||
Users looking for an easy way to provision a secure cluster on physical or cloud servers can use [kubeadm](https://kubernetes.io/docs/getting-started-guides/kubeadm/), which is now _beta_. kubeadm has been enhanced with a set of command line flags and a base feature set that includes RBAC setup, use of the [Bootstrap Token system](http://kubernetes.io/docs/reference/access-authn-authz/bootstrap-tokens/) and an enhanced [Certificates API](https://kubernetes.io/docs/tasks/tls/managing-tls-in-a-cluster/).
|
||||
|
||||
**Advanced Scheduling** : This release adds a set of [powerful and versatile scheduling constructs](https://kubernetes.io/docs/user-guide/node-selection/) to give you greater control over how pods are scheduled, including rules to restrict pods to particular nodes in heterogeneous clusters, and rules to spread or pack pods across failure domains such as nodes, racks, and zones.
|
||||
|
||||
|
|
|
|||
|
|
@ -149,7 +149,7 @@ bootstrapping. The user names and group can be used (and are used by `kubeadm`)
|
|||
to craft the appropriate authorization policies to support bootstrapping a
|
||||
cluster.
|
||||
|
||||
Please see [Bootstrap Tokens](/docs/admin/bootstrap-tokens/) for in depth
|
||||
Please see [Bootstrap Tokens](/docs/reference/access-authn-authz/bootstrap-tokens/) for in depth
|
||||
documentation on the Bootstrap Token authenticator and controllers along with
|
||||
how to manage these tokens with `kubeadm`.
|
||||
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ controller. As this feature matures, you should ensure tokens are bound to a Rol
|
|||
|
||||
While any authentication strategy can be used for the kubelet's initial bootstrap credentials, the following two authenticators are recommended for ease of provisioning.
|
||||
|
||||
1. [Bootstrap Tokens](/docs/admin/bootstrap-tokens/) - __alpha__
|
||||
1. [Bootstrap Tokens](/docs/reference/access-authn-authz/bootstrap-tokens/) - __alpha__
|
||||
2. [Token authentication file](#token-authentication-file)
|
||||
|
||||
Using bootstrap tokens is currently __alpha__ and will simplify the management of bootstrap token management especially in a HA scenario.
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ What is a bootstrap token more exactly?
|
|||
- 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/
|
||||
https://kubernetes.io/docs/reference/access-authn-authz/bootstrap-tokens/
|
||||
|
||||
|
||||
```
|
||||
|
|
|
|||
|
|
@ -375,7 +375,7 @@ Please note that:
|
|||
|
||||
### Configure TLS-Bootstrapping for node joining
|
||||
|
||||
Kubeadm uses [Authenticating with Bootstrap Tokens](/docs/admin/bootstrap-tokens/) for joining new nodes to an
|
||||
Kubeadm uses [Authenticating with Bootstrap Tokens](/docs/reference/access-authn-authz/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
|
||||
|
|
@ -505,7 +505,7 @@ Similarly to `kubeadm init`, also `kubeadm join` internal workflow consists of a
|
|||
|
||||
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).
|
||||
see [Authenticating with Bootstrap Tokens](/docs/reference/access-authn-authz/bootstrap-tokens/) or the corresponding [design proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/cluster-lifecycle/bootstrap-discovery.md).
|
||||
|
||||
### Preflight checks
|
||||
|
||||
|
|
|
|||
|
|
@ -67,7 +67,7 @@ following steps:
|
|||
[kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token/) docs.
|
||||
|
||||
1. Makes all the necessary configurations for allowing node joining with the
|
||||
[Bootstrap Tokens](/docs/admin/bootstrap-tokens/) and
|
||||
[Bootstrap Tokens](/docs/reference/access-authn-authz/bootstrap-tokens/) and
|
||||
[TLS Bootstrap](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)
|
||||
mechanism:
|
||||
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ weight: 70
|
|||
{{% 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/).
|
||||
the cluster and a master node, as described in [authenticating with bootstrap tokens](/docs/reference/access-authn-authz/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.
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ content_template: templates/task
|
|||
{{% capture overview %}}
|
||||
|
||||
<img src="https://raw.githubusercontent.com/cncf/artwork/master/kubernetes/certified-kubernetes/versionless/color/certified-kubernetes-color.png" align="right" width="150px">**kubeadm** helps you bootstrap a minimum viable Kubernetes cluster that conforms to best practices. With kubeadm, your cluster should pass [Kubernetes Conformance tests](https://kubernetes.io/blog/2017/10/software-conformance-certification). Kubeadm also supports other cluster
|
||||
lifecycle functions, such as upgrades, downgrade, and managing [bootstrap tokens](/docs/admin/bootstrap-tokens/).
|
||||
lifecycle functions, such as upgrades, downgrade, and managing [bootstrap tokens](/docs/reference/access-authn-authz/bootstrap-tokens/).
|
||||
|
||||
Because you can install kubeadm on various types of machine (e.g. laptop, server,
|
||||
Raspberry Pi, etc.), it's well suited for integration with provisioning systems
|
||||
|
|
|
|||
Loading…
Reference in New Issue