From 17b21265f6096043166e39be29fc599c29b1f199 Mon Sep 17 00:00:00 2001 From: Matt Moyer Date: Wed, 13 Sep 2017 15:41:42 -0500 Subject: [PATCH] Fix some typos. --- docs/admin/kubeadm.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/admin/kubeadm.md b/docs/admin/kubeadm.md index 8d81ac77ceb2e..8ce7084946178 100644 --- a/docs/admin/kubeadm.md +++ b/docs/admin/kubeadm.md @@ -220,7 +220,7 @@ There are two main schemes for discovery: Only one form can be used. If the discovery information is loaded from a URL, HTTPS must be used and the host installed CA bundle is used to verify the connection. For details on the security tradeoffs of these mechanisms, see the -[security-model](#security-model) section below. +[security model](#security-model) section below. 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 @@ -559,8 +559,8 @@ _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` but you should consider using -one of the other modes if possible. +`--discovery-token-unsafe-skip-ca-verification` flag, but you should consider +using one of the other modes if possible. **Example `kubeadm join` command:**