Merge master into dev-1.19 to keep in sync

2020-08-11 08:32:19 -05:00
parent d9784dc5b4 6b784ad586
commit 09d0f598fa
358 changed files with 16526 additions and 6800 deletions
@@ -162,6 +162,31 @@ are built in and may not be overwritten:
  that only matches the `catch-all` FlowSchema will be rejected with an HTTP 429
  error.

+## Health check concurrency exemption
+
+The suggested configuration gives no special treatment to the health
+check requests on kube-apiservers from their local kubelets --- which
+tend to use the secured port but supply no credentials.  With the
+suggested config, these requests get assigned to the `global-default`
+FlowSchema and the corresponding `global-default` priority level,
+where other traffic can crowd them out.
+
+If you add the following additional FlowSchema, this exempts those
+requests from rate limiting.
+
+{{< caution >}}
+
+Making this change also allows any hostile party to then send
+health-check requests that match this FlowSchema, at any volume they
+like.  If you have a web traffic filter or similar external security
+mechanism to protect your cluster's API server from general internet
+traffic, you can configure rules to block any health check requests
+that originate from outside your cluster.
+
+{{< /caution >}}
+
+{{< codenew file="priority-and-fairness/health-for-strangers.yaml" >}}
+
 ## Resources
 The flow control API involves two kinds of resources.
 [PriorityLevelConfigurations](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io)
@@ -259,7 +259,7 @@ EOF
 This needs to be done for each pod that is using a private registry.

 However, setting of this field can be automated by setting the imagePullSecrets
-in a [ServiceAccount](/docs/tasks/configure-pod-container/configure-service-accounts/) resource.
+in a [ServiceAccount](/docs/tasks/configure-pod-container/configure-service-account/) resource.

 Check [Add ImagePullSecrets to a Service Account](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account) for detailed instructions.

@@ -97,7 +97,7 @@ This diagram shows the extension points in a Kubernetes system.
 1. Users often interact with the Kubernetes API using `kubectl`. [Kubectl plugins](/docs/tasks/extend-kubectl/kubectl-plugins/) extend the kubectl binary. They only affect the individual user's local environment, and so cannot enforce site-wide policies.
 2. The apiserver handles all requests. Several types of extension points in the apiserver allow authenticating requests, or blocking them based on their content, editing content, and handling deletion. These are described in the [API Access Extensions](/docs/concepts/extend-kubernetes/#api-access-extensions) section.
 3. The apiserver serves various kinds of *resources*. *Built-in resource kinds*, like `pods`, are defined by the Kubernetes project and can't be changed. You can also add resources that you define, or that other projects have defined, called *Custom Resources*, as explained in the [Custom Resources](/docs/concepts/extend-kubernetes/#user-defined-types) section. Custom Resources are often used with API Access Extensions.
-4. The Kubernetes scheduler decides which nodes to place pods on. There are several ways to extend scheduling. These are described in the [Scheduler Extensions](/docs/concepts/overview/extending#scheduler-extensions) section.
+4. The Kubernetes scheduler decides which nodes to place pods on. There are several ways to extend scheduling. These are described in the [Scheduler Extensions](/docs/concepts/extend-kubernetes/#scheduler-extensions) section.
 5. Much of the behavior of Kubernetes is implemented by programs called Controllers which are clients of the API-Server. Controllers are often used in conjunction with Custom Resources.
 6. The kubelet runs on servers, and helps pods appear like virtual servers with their own IPs on the cluster network. [Network Plugins](/docs/concepts/extend-kubernetes/#network-plugins) allow for different implementations of pod networking.
 7. The kubelet also mounts and unmounts volumes for containers. New types of storage can be supported via [Storage Plugins](/docs/concepts/extend-kubernetes/#storage-plugins).
@@ -8,8 +8,6 @@ content_type: concept
 weight: 50
 ---

-{{< toc >}}
-
 <!-- overview -->
 A network policy is a specification of how groups of {{< glossary_tooltip text="pods" term_id="pod">}} are allowed to communicate with each other and other network endpoints.

@@ -254,6 +254,16 @@ FlexVolume resize is possible only when the underlying driver supports resize.
 Expanding EBS volumes is a time-consuming operation. Also, there is a per-volume quota of one modification every 6 hours.
 {{< /note >}}

+#### Recovering from Failure when Expanding Volumes
+
+If expanding underlying storage fails, the cluster administrator can manually recover the Persistent Volume Claim (PVC) state and cancel the resize requests. Otherwise, the resize requests are continuously retried by the controller without administrator intervention.
+
+1. Mark the PersistentVolume(PV) that is bound to the PersistentVolumeClaim(PVC) with `Retain` reclaim policy.
+2. Delete the PVC. Since PV has `Retain` reclaim policy - we will not loose any data when we recreate the PVC.
+3. Delete the `claimRef` entry from PV specs, so as new PVC can bind to it. This should make the PV `Available`.
+4. Re-create the PVC with smaller size than PV and set `volumeName` field of the PVC to the name of the PV. This should bind new PVC to existing PV.
+5. Don't forget to restore the reclaim policy of the PV.
+

 ## Types of Persistent Volumes

@@ -19,7 +19,7 @@ A _Pod_ (as in a pod of whales or pea pod) is a group of one or more
 for how to run the containers. A Pod's contents are always co-located and
 co-scheduled, and run in a shared context. A Pod models an
 application-specific "logical host": it contains one or more application
-containers which are relatively tightly coupled. 
+containers which are relatively tightly coupled.
 In non-cloud contexts, applications executed on the same physical or virtual machine are analogous to cloud applications executed on the same logical host.

 As well as application containers, a Pod can contain
@@ -51,7 +51,7 @@ with shared namespaces and shared filesystem volumes.

 Usually you don't need to create Pods directly, even singleton Pods. Instead, create them using workload resources such as {{< glossary_tooltip text="Deployment"
 term_id="deployment" >}} or {{< glossary_tooltip text="Job" term_id="job" >}}.
-If your Pods need to track state, consider the 
+If your Pods need to track state, consider the
 {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}} resource.

 Pods in a Kubernetes cluster are used in two main ways:
@@ -65,7 +65,7 @@ Pods in a Kubernetes cluster are used in two main ways:
  tightly coupled and need to share resources. These co-located containers
  form a single cohesive unit of service—for example, one container serving data
  stored in a shared volume to the public, while a separate _sidecar_ container
-  refreshes or updates those files.  
+  refreshes or updates those files.
  The Pod wraps these containers, storage resources, and an ephemeral network
  identity together as a single unit.

@@ -190,7 +190,7 @@ changing existing code.
 ## Resource sharing and communication

 Pods enable data sharing and communication among their constituent
-containters.
+containers.

 ### Storage in Pods {#pod-storage}

@@ -257,8 +257,8 @@ but cannot be controlled from there.
 * Lean about [RuntimeClass](/docs/concepts/containers/runtime-class/) and how you can use it to
  configure different Pods with different container runtime configurations.
 * Read about [Pod topology spread constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/).
-* Read about [PodDisruptionBudget](https://kubernetes.io/docs/concepts/workloads/pods/disruptions/) and how you can use it to manage application availability during disruptions.
-* Pod is a top-level resource in the Kubernetes REST API.  
+* Read about [PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions/) and how you can use it to manage application availability during disruptions.
+* Pod is a top-level resource in the Kubernetes REST API.
  The [Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)
  object definition describes the object in detail.
 * [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns) explains common layouts for Pods with more than one container.
@@ -78,7 +78,7 @@ Here are the possible values for `phase`:

 Value | Description
 :-----|:-----------
-`Pending` | The Pod has been accepted by the Kubernetes cluster, but one or more of the containers has not been set up and made ready to run. This includes time a Pod spends waiting to bescheduled as well as the time spent downloading container images over the network.
+`Pending` | The Pod has been accepted by the Kubernetes cluster, but one or more of the containers has not been set up and made ready to run. This includes time a Pod spends waiting to be scheduled as well as the time spent downloading container images over the network.
 `Running` | The Pod has been bound to a node, and all of the containers have been created. At least one container is still running, or is in the process of starting or restarting.
 `Succeeded` | All containers in the Pod have terminated in success, and will not be restarted.
 `Failed` | All containers in the Pod have terminated, and at least one container has terminated in failure. That is, the container either exited with non-zero status or was terminated by the system.
@@ -392,7 +392,7 @@ An example flow:
 ### Forced Pod termination {#pod-termination-forced}

 {{< caution >}}
-Forced deletions can be potentially disruptiove for some workloads and their Pods.
+Forced deletions can be potentially disruptive for some workloads and their Pods.
 {{< /caution >}}

 By default, all deletes are graceful within 30 seconds. The `kubectl delete` command supports
@@ -160,10 +160,10 @@ There are some implicit conventions worth noting here:

 - Nodes without `topologySpreadConstraints[*].topologyKey` present will be bypassed. It implies that:

-  1. the Pods located on those nodes do not impact `maxSkew` calculation - in the above example, suppose "node1" does not have label "zone", then the 2 Pods will be disregarded, hence the incomingPod will be scheduled into "zoneA".
+  1. the Pods located on those nodes do not impact `maxSkew` calculation - in the above example, suppose "node1" does not have label "zone", then the 2 Pods will be disregarded, hence the incoming Pod will be scheduled into "zoneA".
  2. the incoming Pod has no chances to be scheduled onto this kind of nodes - in the above example, suppose a "node5" carrying label `{zone-typo: zoneC}` joins the cluster, it will be bypassed due to the absence of label key "zone".

- Be aware of what will happen if the incomingPod’s `topologySpreadConstraints[*].labelSelector` doesn’t match its own labels. In the above example, if we remove the incoming Pod’s labels, it can still be placed onto "zoneB" since the constraints are still satisfied. However, after the placement, the degree of imbalance of the cluster remains unchanged - it’s still zoneA having 2 Pods which hold label {foo:bar}, and zoneB having 1 Pod which holds label {foo:bar}. So if this is not what you expect, we recommend the workload’s `topologySpreadConstraints[*].labelSelector` to match its own labels.
+- Be aware of what will happen if the incoming Pod’s `topologySpreadConstraints[*].labelSelector` doesn’t match its own labels. In the above example, if we remove the incoming Pod’s labels, it can still be placed onto "zoneB" since the constraints are still satisfied. However, after the placement, the degree of imbalance of the cluster remains unchanged - it’s still zoneA having 2 Pods which hold label {foo:bar}, and zoneB having 1 Pod which holds label {foo:bar}. So if this is not what you expect, we recommend the workload’s `topologySpreadConstraints[*].labelSelector` to match its own labels.

 - If the incoming Pod has `spec.nodeSelector` or `spec.affinity.nodeAffinity` defined, nodes not matching them will be bypassed.

@@ -53,7 +53,7 @@ roles and permissions.

 - Read the [Contribution overview](/docs/contribute/new-content/overview/) to
  learn about the different ways you can contribute.
- Check [kubernetes/website issues list](/https://github.com/kubernetes/website/issues/)
+- Check [`kubernetes/website` issues list](https://github.com/kubernetes/website/issues/)
  for issues that make good entry points.
 - [Open a pull request using GitHub](/docs/contribute/new-content/open-a-pr/#changes-using-github)
  to existing documentation and learn more about filing issues in GitHub.
@@ -35,7 +35,7 @@ client libraries:
 ## CLI Reference

 * [kubectl](/docs/reference/kubectl/overview/) - Main CLI tool for running commands and managing Kubernetes clusters.
-    * [JSONPath](/docs/reference/kubectl/jsonpath/) - Syntax guide for using [JSONPath expressions](http://goessner.net/articles/JsonPath/) with kubectl.
+    * [JSONPath](/docs/reference/kubectl/jsonpath/) - Syntax guide for using [JSONPath expressions](https://goessner.net/articles/JsonPath/) with kubectl.
 * [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) - CLI tool to easily provision a secure Kubernetes cluster.

 ## Components Reference
@@ -50,6 +50,8 @@ client libraries:

 ## Design Docs

-An archive of the design docs for Kubernetes functionality. Good starting points are [Kubernetes Architecture](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md) and [Kubernetes Design Overview](https://git.k8s.io/community/contributors/design-proposals).
+An archive of the design docs for Kubernetes functionality. Good starting points are
+[Kubernetes Architecture](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md) and
+[Kubernetes Design Overview](https://git.k8s.io/community/contributors/design-proposals).


@@ -1,5 +1,4 @@
 ---
 title: Accessing the API
 weight: 20
-toc-hide: true
 ---
@@ -18,7 +18,7 @@ Attribute-based access control (ABAC) defines an access control paradigm whereby

 To enable `ABAC` mode, specify `--authorization-policy-file=SOME_FILENAME` and `--authorization-mode=ABAC` on startup.

-The file format is [one JSON object per line](http://jsonlines.org/).  There
+The file format is [one JSON object per line](https://jsonlines.org/).  There
 should be no enclosing list or map, just one map per line.

 Each line is a "policy object", where each such object is a map with the following
@@ -127,7 +127,7 @@ up the verbosity:
    {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"group": "system:unauthenticated", "readonly": true, "nonResourcePath": "*"}}
    ```

-[Complete file example](http://releases.k8s.io/{{< param "githubbranch" >}}/pkg/auth/authorizer/abac/example_policy_file.jsonl)
+[Complete file example](https://releases.k8s.io/{{< param "githubbranch" >}}/pkg/auth/authorizer/abac/example_policy_file.jsonl)

 ## A quick note on service accounts

@@ -25,8 +25,8 @@ is authenticated and authorized.  The controllers consist of the
 `kube-apiserver` binary, and may only be configured by the cluster
 administrator. In that list, there are two special controllers:
 MutatingAdmissionWebhook and ValidatingAdmissionWebhook.  These execute the
-mutating and validating (respectively) [admission control
-webhooks](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)
+mutating and validating (respectively)
+[admission control webhooks](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)
 which are configured in the API.

 Admission controllers may be "validating", "mutating", or both. Mutating
@@ -351,7 +351,10 @@ plugins:
 {{% /tab %}}
 {{< /tabs >}}

-The ImagePolicyWebhook config file must reference a [kubeconfig](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/) formatted file which sets up the connection to the backend. It is required that the backend communicate over TLS.
+The ImagePolicyWebhook config file must reference a
+[kubeconfig](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
+formatted file which sets up the connection to the backend.
+It is required that the backend communicate over TLS.

 The kubeconfig file's cluster field must point to the remote service, and the user field must contain the returned authorizer.

@@ -371,7 +374,8 @@ users:
    client-key: /path/to/key.pem          # key matching the cert
 ```

-For additional HTTP configuration, refer to the [kubeconfig](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/) documentation.
+For additional HTTP configuration, refer to the
+[kubeconfig](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) documentation.

 #### Request Payloads

@@ -454,7 +458,8 @@ your Kubernetes deployment, you MUST use this admission controller to enforce th
 be used to apply default resource requests to Pods that don't specify any; currently, the default LimitRanger
 applies a 0.1 CPU requirement to all Pods in the `default` namespace.

-See the [limitRange design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md) and the [example of Limit Range](/docs/tasks/configure-pod-container/limit-range/) for more details.
+See the [limitRange design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md)
+and the [example of Limit Range](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/) for more details.

 ### MutatingAdmissionWebhook {#mutatingadmissionwebhook}

@@ -731,16 +736,30 @@ for more information.

 ### SecurityContextDeny {#securitycontextdeny}

-This admission controller will deny any pod that attempts to set certain escalating [SecurityContext](/docs/user-guide/security-context) fields. This should be enabled if a cluster doesn't utilize [pod security policies](/docs/user-guide/pod-security-policy) to restrict the set of values a security context can take.
+This admission controller will deny any pod that attempts to set certain escalating
+[SecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#securitycontext-v1-core)
+fields, as shown in the
+[Configure a Security Context for a Pod or Container](/docs/tasks/configure-pod-container/security-context/)
+task.
+This should be enabled if a cluster doesn't utilize 
+[pod security policies](/docs/concepts/policy/pod-security-policy/)
+to restrict the set of values a security context can take.

 ### ServiceAccount {#serviceaccount}

-This admission controller implements automation for [serviceAccounts](/docs/user-guide/service-accounts).
+This admission controller implements automation for
+[serviceAccounts](/docs/tasks/configure-pod-container/configure-service-account/).
 We strongly recommend using this admission controller if you intend to make use of Kubernetes `ServiceAccount` objects.

 ### StorageObjectInUseProtection

-The `StorageObjectInUseProtection` plugin adds the `kubernetes.io/pvc-protection` or `kubernetes.io/pv-protection` finalizers to newly created Persistent Volume Claims (PVCs) or Persistent Volumes (PV). In case a user deletes a PVC or PV the PVC or PV is not removed until the finalizer is removed from the PVC or PV by PVC or PV Protection Controller. Refer to the [Storage Object in Use Protection](/docs/concepts/storage/persistent-volumes/#storage-object-in-use-protection) for more detailed information.
+The `StorageObjectInUseProtection` plugin adds the `kubernetes.io/pvc-protection` or `kubernetes.io/pv-protection`
+finalizers to newly created Persistent Volume Claims (PVCs) or Persistent Volumes (PV).
+In case a user deletes a PVC or PV the PVC or PV is not removed until the finalizer is removed
+from the PVC or PV by PVC or PV Protection Controller. 
+Refer to the
+[Storage Object in Use Protection](/docs/concepts/storage/persistent-volumes/#storage-object-in-use-protection)
+for more detailed information.

 ### TaintNodesByCondition {#taintnodesbycondition}

@@ -20,13 +20,24 @@ This page provides an overview of authenticating.
 All Kubernetes clusters have two categories of users: service accounts managed
 by Kubernetes, and normal users.

-Normal users are assumed to be managed by an outside, independent service. An
-admin distributing private keys, a user store like Keystone or Google Accounts,
-even a file with a list of usernames and passwords. In this regard, _Kubernetes
-does not have objects which represent normal user accounts._ Normal users
-cannot be added to a cluster through an API call.
+It is assumed that a cluster-independent service manages normal users in the following ways:

-Even though normal user cannot be added via an API call, but any user that presents a valid certificate signed by the cluster’s certificate authority (CA) is considered authenticated. In this configuration, Kubernetes determines the username from the common name field in the ‘subject’ of the cert (e.g., “/CN=bob”). From there, the role based access control (RBAC) sub-system would determine whether the user is authorized to perform a specific operation on a resource. You can refer to [creating user certificate request](/docs/reference/access-authn-authz/certificate-signing-requests/#user-csr) for more details about this.
+- an administrator distributing private keys
+- a user store like Keystone or Google Accounts
+- a file with a list of usernames and passwords
+
+In this regard, _Kubernetes does not have objects which represent normal user
+accounts._ Normal users cannot be added to a cluster through an API call.
+
+Even though normal user cannot be added via an API call, but any user that
+presents a valid certificate signed by the cluster’s certificate authority
+(CA) is considered authenticated. In this configuration, Kubernetes determines
+the username from the common name field in the ‘subject’ of the cert (e.g.,
+“/CN=bob”). From there, the role based access control (RBAC) sub-system would
+determine whether the user is authorized to perform a specific operation on a
+resource. For more details, refer to the normal users topic in
+[certificate request](/docs/reference/access-authn-authz/certificate-signing-requests/#normal-user)
+for more details about this.

 In contrast, service accounts are users managed by the Kubernetes API. They are
 bound to specific namespaces, and created automatically by the API server or
@@ -315,8 +326,12 @@ wish to utilize multiple OAuth clients should explore providers which support th
 tokens on behalf of another.

 Kubernetes does not provide an OpenID Connect Identity Provider.
-You can use an existing public OpenID Connect Identity Provider (such as Google, or [others](http://connect2id.com/products/nimbus-oauth-openid-connect-sdk/openid-connect-providers)).
-Or, you can run your own Identity Provider, such as CoreOS [dex](https://github.com/coreos/dex), [Keycloak](https://github.com/keycloak/keycloak), CloudFoundry [UAA](https://github.com/cloudfoundry/uaa), or Tremolo Security's [OpenUnison](https://github.com/tremolosecurity/openunison).
+You can use an existing public OpenID Connect Identity Provider (such as Google, or
+[others](https://connect2id.com/products/nimbus-oauth-openid-connect-sdk/openid-connect-providers)).
+Or, you can run your own Identity Provider, such as CoreOS [dex](https://github.com/coreos/dex),
+[Keycloak](https://github.com/keycloak/keycloak), 
+CloudFoundry [UAA](https://github.com/cloudfoundry/uaa), or
+Tremolo Security's [OpenUnison](https://github.com/tremolosecurity/openunison).

 For an identity provider to work with Kubernetes it must:

@@ -400,7 +415,7 @@ Webhook authentication is a hook for verifying bearer tokens.
 * `--authentication-token-webhook-config-file` a configuration file describing how to access the remote webhook service.
 * `--authentication-token-webhook-cache-ttl` how long to cache authentication decisions. Defaults to two minutes.

-The configuration file uses the [kubeconfig](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)
+The configuration file uses the [kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
 file format. Within the file, `clusters` refers to the remote service and
 `users` refers to the API server webhook. An example would be:

@@ -138,8 +138,6 @@ field of the returned object is the result of the query.

 ```bash
 kubectl create -f - -o yaml << EOF
-```
-```
 apiVersion: authorization.k8s.io/v1
 kind: SelfSubjectAccessReview
 spec:
@@ -149,7 +147,10 @@ spec:
    verb: create
    namespace: dev
 EOF
+```

+The generated `SelfSubjectAccessReview` is:
+```
 apiVersion: authorization.k8s.io/v1
 kind: SelfSubjectAccessReview
 metadata:
@@ -589,7 +589,7 @@ Example of a response to forbid a request, customizing the HTTP status code and
 When allowing a request, a mutating admission webhook may optionally modify the incoming object as well.
 This is done using the `patch` and `patchType` fields in the response.
 The only currently supported `patchType` is `JSONPatch`.
-See [JSON patch](http://jsonpatch.com/) documentation for more details.
+See [JSON patch](https://jsonpatch.com/) documentation for more details.
 For `patchType: JSONPatch`, the `patch` field contains a base64-encoded array of JSON patch operations.

 As an example, a single patch operation that would set `spec.replicas` would be `[{"op": "add", "path": "/spec/replicas", "value": 3}]`
@@ -10,8 +10,8 @@ weight: 50
 ---

 <!-- overview -->
-This is a Cluster Administrator guide to service accounts. It assumes knowledge of
-the [User Guide to Service Accounts](/docs/user-guide/service-accounts).
+This is a Cluster Administrator guide to service accounts. You should be familiar with 
+[configuring Kubernetes service accounts](/docs/tasks/configure-pod-container/configure-service-account/).

 Support for authorization and user accounts is planned but incomplete.  Sometimes
 incomplete features are referred to in order to better describe service accounts.
@@ -1,5 +1,4 @@
 ---
 title: Command line tools reference
 weight: 60
-toc-hide: true
 ---
@@ -417,11 +417,11 @@ Each feature gate is designed for enabling/disabling a specific feature:
 - `CustomResourceDefaulting`: Enable CRD support for default values in OpenAPI v3 validation schemas.
 - `CustomResourcePublishOpenAPI`: Enables publishing of CRD OpenAPI specs.
 - `CustomResourceSubresources`: Enable `/status` and `/scale` subresources
-  on resources created from [CustomResourceDefinition](/docs/concepts/api-extension/custom-resources/).
+  on resources created from [CustomResourceDefinition](/docs/concepts/extend-kubernetes/api-extension/custom-resources/).
 - `CustomResourceValidation`: Enable schema based validation on resources created from
-  [CustomResourceDefinition](/docs/concepts/api-extension/custom-resources/).
+  [CustomResourceDefinition](/docs/concepts/extend-kubernetes/api-extension/custom-resources/).
 - `CustomResourceWebhookConversion`: Enable webhook-based conversion
-  on resources created from [CustomResourceDefinition](/docs/concepts/api-extension/custom-resources/).
+  on resources created from [CustomResourceDefinition](/docs/concepts/extend-kubernetes/api-extension/custom-resources/).
  troubleshoot a running Pod.
 - `DisableAcceleratorUsageMetrics`: [Disable accelerator metrics collected by the kubelet](/docs/concepts/cluster-administration/monitoring.md).
 - `DevicePlugins`: Enable the [device-plugins](/docs/concepts/cluster-administration/device-plugins/)
@@ -475,6 +475,9 @@ Each feature gate is designed for enabling/disabling a specific feature:
 - `LegacyNodeRoleBehavior`: When disabled, legacy behavior in service load balancers and node disruption will ignore the `node-role.kubernetes.io/master` label in favor of the feature-specific labels provided by `NodeDisruptionExclusion` and `ServiceNodeExclusion`.
 - `LocalStorageCapacityIsolation`: Enable the consumption of [local ephemeral storage](/docs/concepts/configuration/manage-compute-resources-container/) and also the `sizeLimit` property of an [emptyDir volume](/docs/concepts/storage/volumes/#emptydir).
 - `LocalStorageCapacityIsolationFSQuotaMonitoring`: When `LocalStorageCapacityIsolation` is enabled for [local ephemeral storage](/docs/concepts/configuration/manage-compute-resources-container/) and the backing filesystem for [emptyDir volumes](/docs/concepts/storage/volumes/#emptydir) supports project quotas and they are enabled, use project quotas to monitor [emptyDir volume](/docs/concepts/storage/volumes/#emptydir) storage consumption rather than filesystem walk for better performance and accuracy.
+  [local ephemeral storage](/docs/concepts/configuration/manage-resources-containers/) and the backing filesystem for
+  [emptyDir volumes](/docs/concepts/storage/volumes/#emptydir) supports project quotas and they are enabled, use project quotas to monitor
+  [emptyDir volume](/docs/concepts/storage/volumes/#emptydir) storage consumption rather than filesystem walk for better performance and accuracy.
 - `MountContainers`: Enable using utility containers on host as the volume mounter.
 - `MountPropagation`: Enable sharing volume mounted by one container to other containers or pods.
  For more details, please see [mount propagation](/docs/concepts/storage/volumes/#mount-propagation).
@@ -17,7 +17,7 @@ A tool that lets you use OCI container runtimes with Kubernetes CRI.
 CRI-O is an implementation of the {{< glossary_tooltip term_id="cri" >}}
 to enable using {{< glossary_tooltip text="container" term_id="container" >}}
 runtimes that are compatible with the Open Container Initiative (OCI)
-[runtime spec](http://www.github.com/opencontainers/runtime-spec).
+[runtime spec](https://www.github.com/opencontainers/runtime-spec).

 Deploying CRI-O allows Kubernetes to use any OCI-compliant runtime as the container
 runtime for running {{< glossary_tooltip text="Pods" term_id="pod" >}}, and to fetch
@@ -14,4 +14,9 @@ tags:

 <!--more--> 

-Some examples of Managed Services are AWS EC2, Azure SQL Database, and GCP Pub/Sub, but they can be any software offering that can be used by an application. [Service Catalog](/docs/concepts/service-catalog/) provides a way to list, provision, and bind with Managed Services offered by {{< glossary_tooltip text="Service Brokers" term_id="service-broker" >}}.
+Some examples of Managed Services are AWS EC2, Azure SQL Database, and
+GCP Pub/Sub, but they can be any software offering that can be used by an application.
+[Service Catalog](/docs/concepts/extend-kubernetes/service-catalog/) provides a way to
+list, provision, and bind with Managed Services offered by
+{{< glossary_tooltip text="Service Brokers" term_id="service-broker" >}}.
+
@@ -14,5 +14,10 @@ tags:

 <!--more--> 

-A platform developer may, for example, use [Custom Resources](/docs/concepts/api-extension/custom-resources/) or [Extend the Kubernetes API with the aggregation layer](/docs/concepts/api-extension/apiserver-aggregation/) to add functionality to their instance of Kubernetes, specifically for their application.  Some Platform Developers are also {{< glossary_tooltip text="contributors" term_id="contributor" >}} and develop extensions which are contributed to the Kubernetes community.  Others develop closed-source commercial or site-specific extensions.
+A platform developer may, for example, use [Custom Resources](/docs/concepts/extend-Kubernetes/api-extension/custom-resources/) or
+[Extend the Kubernetes API with the aggregation layer](/docs/concepts/extend-Kubernetes/api-extension/apiserver-aggregation/)
+to add functionality to their instance of Kubernetes, specifically for their application.
+Some Platform Developers are also {{< glossary_tooltip text="contributors" term_id="contributor" >}} and
+develop extensions which are contributed to the Kubernetes community.
+Others develop closed-source commercial or site-specific extensions.

@@ -14,4 +14,9 @@ tags:

 <!--more--> 

-{{< glossary_tooltip text="Service Brokers" term_id="service-broker" >}} implement the [Open Service Broker API spec](https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md) and provide a standard interface for applications to use their Managed Services. [Service Catalog](/docs/concepts/service-catalog/) provides a way to list, provision, and bind with Managed Services offered by Service Brokers.
+{{< glossary_tooltip text="Service Brokers" term_id="service-broker" >}} implement the
+[Open Service Broker API spec](https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md)
+and provide a standard interface for applications to use their Managed Services.
+[Service Catalog](/docs/concepts/extend-kubernetes/service-catalog/) provides a way to
+list, provision, and bind with Managed Services offered by Service Brokers.
+
@@ -1,5 +1,4 @@
 ---
 title: Kubernetes Issues and Security
 weight: 10
-toc-hide: true
 ---
@@ -204,6 +204,13 @@ kubectl get events --sort-by=.metadata.creationTimestamp

 # Compares the current state of the cluster against the state that the cluster would be in if the manifest was applied.
 kubectl diff -f ./my-manifest.yaml
+
+# Produce a period-delimited tree of all keys returned for nodes
+# Helpful when locating a key within a complex nested JSON structure
+kubectl get nodes -o json | jq -c 'path(..)|[.[]|tostring]|join(".")'
+
+# Produce a period-delimited tree of all keys returned for pods, etc
+kubectl get pods -o json | jq -c 'path(..)|[.[]|tostring]|join(".")'
 ```

 ## Updating Resources
@@ -10,11 +10,16 @@ card:
 ---

 <!-- overview -->
-The kubectl command line tool lets you control Kubernetes clusters. For configuration, `kubectl` looks for a file named `config` in the `$HOME/.kube` directory. You can specify other [kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) files by setting the KUBECONFIG environment variable or by setting the [`--kubeconfig`](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) flag.
-
-This overview covers `kubectl` syntax, describes the command operations, and provides common examples. For details about each command, including all the supported flags and subcommands, see the [kubectl](/docs/reference/generated/kubectl/kubectl-commands/) reference documentation. For installation instructions see [installing kubectl](/docs/tasks/kubectl/install/).
-
+The kubectl command line tool lets you control Kubernetes clusters.
+For configuration, `kubectl` looks for a file named `config` in the `$HOME/.kube` directory.
+You can specify other [kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
+files by setting the KUBECONFIG environment variable or by setting the
+[`--kubeconfig`](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) flag.

+This overview covers `kubectl` syntax, describes the command operations, and provides common examples.
+For details about each command, including all the supported flags and subcommands, see the
+[kubectl](/docs/reference/generated/kubectl/kubectl-commands/) reference documentation.
+For installation instructions see [installing kubectl](/docs/tasks/tools/install-kubectl/).

 <!-- body -->

@@ -28,9 +33,12 @@ kubectl [command] [TYPE] [NAME] [flags]

 where `command`, `TYPE`, `NAME`, and `flags` are:

-* `command`: Specifies the operation that you want to perform on one or more resources, for example `create`, `get`, `describe`, `delete`.
+* `command`: Specifies the operation that you want to perform on one or more resources, 
+for example `create`, `get`, `describe`, `delete`.

-* `TYPE`: Specifies the [resource type](#resource-types). Resource types are case-insensitive and you can specify the singular, plural, or abbreviated forms. For example, the following commands produce the same output:
+* `TYPE`: Specifies the [resource type](#resource-types). Resource types are case-insensitive and
+  you can specify the singular, plural, or abbreviated forms.
+  For example, the following commands produce the same output:

   ```shell
   kubectl get pod pod1
@@ -208,11 +216,13 @@ In this example, the following command outputs the details for a single pod as a
 kubectl get pod web-pod-13je7 -o yaml
 ```

-Remember: See the [kubectl](/docs/user-guide/kubectl/) reference documentation for details about which output format is supported by each command.
+Remember: See the [kubectl](/docs/reference/kubectl/kubectl/) reference documentation
+for details about which output format is supported by each command.

 #### Custom columns

-To define custom columns and output only the details that you want into a table, you can use the `custom-columns` option. You can choose to define the custom columns inline or use a template file: `-o custom-columns=<spec>` or `-o custom-columns-file=<filename>`.
+To define custom columns and output only the details that you want into a table, you can use the `custom-columns` option.
+You can choose to define the custom columns inline or use a template file: `-o custom-columns=<spec>` or `-o custom-columns-file=<filename>`.

 ##### Examples

@@ -496,12 +506,8 @@ kubectl whoami
 Current user: plugins-user
 ```

-
-
-
 ## {{% heading "whatsnext" %}}

-
 * Start using the [kubectl](/docs/reference/generated/kubectl/kubectl-commands/) commands.

 * To find out more about plugins, take a look at the [example cli plugin](https://github.com/kubernetes/sample-cli-plugin).
@@ -1,5 +1,4 @@
 ---
 title: Setup tools reference
 weight: 50
-toc-hide: true
 ---
@@ -1,5 +1,30 @@
 ---
 title: "Kubeadm"
 weight: 10
-toc-hide: true
+no_list: true
+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.
+
+Instead, we expect higher-level and more tailored tooling to be built on top of kubeadm, and ideally, using kubeadm as the basis of all deployments will make it easier to create conformant clusters.
+
+## How to install
+
+To install kubeadm, see the [installation guide](/docs/setup/production-environment/tools/kubeadm/install-kubeadm).
+
+## {{% 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
+* [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade) to upgrade a Kubernetes cluster to a newer version
+* [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`
+* [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`
+* [kubeadm version](/docs/reference/setup-tools/kubeadm/kubeadm-version) to print the kubeadm version
+* [kubeadm alpha](/docs/reference/setup-tools/kubeadm/kubeadm-alpha) to preview a set of features made available for gathering feedback from the community
@@ -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" >}}
-
@@ -1,30 +0,0 @@
---
-reviewers:
- luxas
- jbeda
-title: Overview of kubeadm
-weight: 10
-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.
-
-Instead, we expect higher-level and more tailored tooling to be built on top of kubeadm, and ideally, using kubeadm as the basis of all deployments will make it easier to create conformant clusters.
-
-## How to install
-
-To install kubeadm, see the [installation guide](/docs/setup/production-environment/tools/kubeadm/install-kubeadm).
-
-## 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 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 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`
-* [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`
-* [kubeadm version](/docs/reference/setup-tools/kubeadm/kubeadm-version) to print the kubeadm version
-* [kubeadm alpha](/docs/reference/setup-tools/kubeadm/kubeadm-alpha) to preview a set of features made available for gathering feedback from the community
@@ -1,5 +1,4 @@
 ---
 title: Using the Kubernetes API
 weight: 10
-toc-hide: true
 ---
@@ -84,7 +84,7 @@ Currently, there are several API groups in use:
 *  The named groups are at REST path `/apis/$GROUP_NAME/$VERSION`, and use `apiVersion: $GROUP_NAME/$VERSION`
   (for example, `apiVersion: batch/v1`). You can find the full list of supported API groups in [Kubernetes API reference](/docs/reference/).

-The two paths that support extending the API with [custom resources](/docs/concepts/api-extension/custom-resources/) are:
+The two paths that support extending the API with [custom resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/) are:

 - [CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)
   for basic CRUD needs.
@@ -19,13 +19,13 @@ You can use a client library for the programming language you are using.
 Client libraries often handle common tasks such as authentication for you.
 Most client libraries can discover and use the Kubernetes Service Account to
 authenticate if the API client is running inside the Kubernetes cluster, or can
-understand the [kubeconfig file](/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig/)
+understand the [kubeconfig file](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
 format to read the credentials and the API Server address.

 ## Officially-supported Kubernetes client libraries

-The following client libraries are officially maintained by [Kubernetes SIG API
-Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery).
+The following client libraries are officially maintained by
+[Kubernetes SIG API Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery).


 | Language | Client Library | Sample Programs |
@@ -289,8 +289,7 @@ API versions are supported in a series of subsequent releases.
 ### REST resources (aka API objects)

 Consider a hypothetical REST resource named Widget, which was present in API v1
-in the above timeline, and which needs to be deprecated.  We
-[document](/docs/reference/deprecation-policy/) and
+in the above timeline, and which needs to be deprecated.  We document and
 [announce](https://groups.google.com/forum/#!forum/kubernetes-announce) the
 deprecation in sync with release X+1.  The Widget resource still exists in API
 version v1 (deprecated) but not in v2alpha1.  The Widget resource continues to
@@ -29,6 +29,9 @@ when using kubeadm to set up a kubernetes cluster.
  document assumes these default ports. However, they are configurable through
  the kubeadm config file.
 * Each host must [have docker, kubelet, and kubeadm installed](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/).
+* Each host should have access to the Kubernetes container image registry (`k8s.gcr.io`) or list/pull the required etcd image using
+`kubeadm config images list/pull`. This guide will setup etcd instances as
+[static pods](/docs/tasks/configure-pod-container/static-pod/) managed by a kubelet.
 * Some infrastructure to copy files between hosts. For example `ssh` and `scp`
  can satisfy this requirement.

@@ -122,7 +122,7 @@ kube-system   kube-ui       ClusterIP        10.0.0.3         <none>
 ...
 ```

-Similarly, you can take a look at the set of [pods](/docs/concepts/workloads/pods/pod/) that were created during cluster startup.
+Similarly, you can take a look at the set of [pods](/docs/concepts/workloads/pods/) that were created during cluster startup.
 You can do this via the

 ```shell
@@ -8,9 +8,6 @@ content_type: concept

 This topic discusses multiple ways to interact with clusters.

-
-
-
 <!-- body -->

 ## Accessing for the first time with kubectl
@@ -29,8 +26,9 @@ Check the location and credentials that kubectl knows about with this command:
 kubectl config view
 ```

-Many of the [examples](/docs/user-guide/kubectl-cheatsheet) provide an introduction to using
-kubectl and complete documentation is found in the [kubectl manual](/docs/user-guide/kubectl-overview).
+Many of the [examples](/docs/reference/kubectl/cheatsheet/) provide an introduction to using
+kubectl and complete documentation is found in the
+[kubectl manual](/docs/reference/kubectl/overview/).

 ## Directly accessing the REST API

@@ -165,7 +163,7 @@ client libraries.
 * To get the library, run the following command: `go get k8s.io/client-go@kubernetes-<kubernetes-version-number>`, see [INSTALL.md](https://github.com/kubernetes/client-go/blob/master/INSTALL.md#for-the-casual-user) for detailed installation instructions. See [https://github.com/kubernetes/client-go](https://github.com/kubernetes/client-go#compatibility-matrix) to see which versions are supported.
 * Write an application atop of the client-go clients. Note that client-go defines its own API objects, so if needed, please import API definitions from client-go rather than from the main repository, e.g., `import "k8s.io/client-go/kubernetes"` is correct.

-The Go client can use the same [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)
+The Go client can use the same [kubeconfig file](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
 as the kubectl CLI does to locate and authenticate to the apiserver. See this [example](https://git.k8s.io/client-go/examples/out-of-cluster-client-configuration/main.go).

 If the application is deployed as a Pod in the cluster, please refer to the [next section](#accessing-the-api-from-a-pod).
@@ -174,7 +172,7 @@ If the application is deployed as a Pod in the cluster, please refer to the [nex

 To use [Python client](https://github.com/kubernetes-client/python), run the following command: `pip install kubernetes`. See [Python Client Library page](https://github.com/kubernetes-client/python) for more installation options.

-The Python client can use the same [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)
+The Python client can use the same [kubeconfig file](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
 as the kubectl CLI does to locate and authenticate to the apiserver. See this [example](https://github.com/kubernetes-client/python/tree/master/examples).

 ### Other languages
@@ -219,7 +217,9 @@ In each case, the credentials of the pod are used to communicate securely with t

 The previous section was about connecting the Kubernetes API server.  This section is about
 connecting to other services running on Kubernetes cluster.  In Kubernetes, the
-[nodes](/docs/admin/node), [pods](/docs/user-guide/pods) and [services](/docs/user-guide/services) all have
+[nodes](/docs/concepts/architecture/nodes/),
+[pods](/docs/concepts/workloads/pods/) and
+[services](/docs/concepts/services-networking/service/) all have
 their own IPs.  In many cases, the node IPs, pod IPs, and some service IPs on a cluster will not be
 routable, so they will not be reachable from a machine outside the cluster,
 such as your desktop machine.
@@ -230,7 +230,7 @@ You have several options for connecting to nodes, pods and services from outside

  - Access services through public IPs.
    - Use a service with type `NodePort` or `LoadBalancer` to make the service reachable outside
-      the cluster.  See the [services](/docs/user-guide/services) and
+      the cluster.  See the [services](/docs/concepts/services-networking/service/) and
      [kubectl expose](/docs/reference/generated/kubectl/kubectl-commands/#expose) documentation.
    - Depending on your cluster environment, this may just expose the service to your corporate network,
      or it may expose it to the internet.  Think about whether the service being exposed is secure.
@@ -7,19 +7,14 @@ weight: 110
 <!-- overview -->

 This page shows how to use a Volume to communicate between two Containers running
-in the same Pod. See also how to allow processes to communicate by [sharing process namespace](/docs/tasks/configure-pod-container/share-process-namespace/) between containers.
-
-
-
+in the same Pod. See also how to allow processes to communicate by
+[sharing process namespace](/docs/tasks/configure-pod-container/share-process-namespace/)
+between containers.

 ## {{% heading "prerequisites" %}}

-
 {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}

-
-
-
 <!-- steps -->

 ##  Creating a Pod that runs two Containers
@@ -103,14 +98,15 @@ The output is similar to this:
 Recall that the debian Container created the `index.html` file in the nginx root
 directory. Use `curl` to send a GET request to the nginx server:

-    root@two-containers:/# curl localhost
+```
+root@two-containers:/# curl localhost
+```

 The output shows that nginx serves a web page written by the debian container:

-    Hello from the debian container
-
-
-
+```
+Hello from the debian container
+```

 <!-- discussion -->

@@ -128,20 +124,14 @@ The Volume in this exercise provides a way for Containers to communicate during
 the life of the Pod. If the Pod is deleted and recreated, any data stored in
 the shared Volume is lost.

-
-
-
 ## {{% heading "whatsnext" %}}


-* Learn more about
-[patterns for composite containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns).
+* Learn more about [patterns for composite containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns).

-* Learn about
-[composite containers for modular architecture](http://www.slideshare.net/Docker/slideshare-burns).
+* Learn about [composite containers for modular architecture](https://www.slideshare.net/Docker/slideshare-burns).

-* See
-[Configuring a Pod to Use a Volume for Storage](/docs/tasks/configure-pod-container/configure-volume-storage/).
+* See [Configuring a Pod to Use a Volume for Storage](/docs/tasks/configure-pod-container/configure-volume-storage/).

 * See [Configure a Pod to share process namespace between containers in a Pod](/docs/tasks/configure-pod-container/share-process-namespace/)

@@ -149,7 +139,3 @@ the shared Volume is lost.

 * See [Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core).

-
-
-
-
@@ -11,33 +11,21 @@ microservice. The backend microservice is a hello greeter. The
 frontend and backend are connected using a Kubernetes
 {{< glossary_tooltip term_id="service" >}} object.

-
-
-
 ## {{% heading "objectives" %}}

-
 * Create and run a microservice using a {{< glossary_tooltip term_id="deployment" >}} object.
 * Route traffic to the backend using a frontend.
 * Use a Service object to connect the frontend application to the
  backend application.

-
-
-
 ## {{% heading "prerequisites" %}}

+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}

-* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-
-* This task uses
-  [Services with external load balancers](/docs/tasks/access-application-cluster/create-external-load-balancer/), which
-  require a supported environment. If your environment does not
-  support this, you can use a Service of type
-  [NodePort](/docs/concepts/services-networking/service/#nodeport) instead.
-
-
-
+This task uses
+[Services with external load balancers](/docs/tasks/access-application-cluster/create-external-load-balancer/), which
+require a supported environment. If your environment does not support this, you can use a Service of type
+[NodePort](/docs/concepts/services-networking/service/#nodeport) instead.

 <!-- lessoncontent -->

@@ -153,8 +141,8 @@ service/frontend created
 ```

 {{< note >}}
-The nginx configuration is baked into the [container
-image](/examples/service/access/Dockerfile). A better way to do this would
+The nginx configuration is baked into the
+[container image](/examples/service/access/Dockerfile). A better way to do this would
 be to use a
 [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/),
 so that you can change the configuration more easily.
@@ -203,27 +191,22 @@ The output shows the message generated by the backend:
 {"message":"Hello"}
 ```

-
-
 ## {{% heading "cleanup" %}}

-
 To delete the Services, enter this command:

-    kubectl delete services frontend hello
+```shell
+kubectl delete services frontend hello
+```

 To delete the Deployments, the ReplicaSets and the Pods that are running the backend and frontend applications, enter this command:

-    kubectl delete deployment frontend hello
-
-
+```shell
+kubectl delete deployment frontend hello
+```

 ## {{% heading "whatsnext" %}}

-
 * Learn more about [Services](/docs/concepts/services-networking/service/)
 * Learn more about [ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/)

-
-
-
@@ -6,7 +6,7 @@ weight: 100

 <!-- overview -->

-An [Ingress](/docs/concepts/services-networking/ingress/) is an API object that defines rules which allow external access 
+An [Ingress](/docs/concepts/services-networking/ingress/) is an API object that defines rules which allow external access
 to services in a cluster. An [Ingress controller](/docs/concepts/services-networking/ingress-controllers/) fulfills the rules set in the Ingress.

 This page shows you how to set up a simple Ingress which routes requests to Service web or web2 depending on the HTTP URI.
@@ -41,7 +41,7 @@ This page shows you how to set up a simple Ingress which routes requests to Serv
    ```shell
    minikube addons enable ingress
    ```
-      
+
 1. Verify that the NGINX Ingress controller is running

    ```shell
@@ -71,31 +71,31 @@ This page shows you how to set up a simple Ingress which routes requests to Serv
    ```

    Output:
-    
+
    ```shell
    deployment.apps/web created
    ```

-1. Expose the Deployment: 
+1. Expose the Deployment:

    ```shell
    kubectl expose deployment web --type=NodePort --port=8080
    ```
-    
-    Output: 
-    
+
+    Output:
+
    ```shell
    service/web exposed
    ```
-    
+
 1. Verify the Service is created and is available on a node port:

    ```shell
    kubectl get service web
-    ``` 
-    
+    ```
+
    Output:
-    
+
    ```shell
    NAME      TYPE       CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
    web       NodePort   10.104.133.249   <none>        8080:31637/TCP   12m
@@ -106,24 +106,24 @@ This page shows you how to set up a simple Ingress which routes requests to Serv
    ```shell
    minikube service web --url
    ```
-    
+
    Output:
-    
+
    ```shell
    http://172.17.0.15:31637
    ```
-    
+
    {{< note >}}Katacoda environment only: at the top of the terminal panel, click the plus sign, and then click **Select port to view on Host 1**. Enter the NodePort, in this case `31637`, and then click **Display Port**.{{< /note >}}
-    
+
    Output:
-    
+
    ```shell
    Hello, world!
    Version: 1.0.0
    Hostname: web-55b8c6998d-8k564
    ```
-    
-    You can now access the sample app via the Minikube IP address and NodePort. The next step lets you access 
+
+    You can now access the sample app via the Minikube IP address and NodePort. The next step lets you access
    the app using the Ingress resource.

 ## Create an Ingress resource
@@ -132,37 +132,39 @@ The following file is an Ingress resource that sends traffic to your Service via

 1. Create `example-ingress.yaml` from the following file:

-        apiVersion: networking.k8s.io/v1beta1
-        kind: Ingress
-        metadata:
-          name: example-ingress
-          annotations:
-            nginx.ingress.kubernetes.io/rewrite-target: /$1
-        spec:
-          rules:
-          - host: hello-world.info
-            http:
-              paths:
-              - path: /
-                backend:
-                  serviceName: web
-                  servicePort: 8080
+    ```yaml
+    apiVersion: networking.k8s.io/v1beta1
+    kind: Ingress
+    metadata:
+      name: example-ingress
+      annotations:
+        nginx.ingress.kubernetes.io/rewrite-target: /$1
+    spec:
+      rules:
+      - host: hello-world.info
+        http:
+          paths:
+          - path: /
+        backend:
+          serviceName: web
+          servicePort: 8080
+    ```

 1. Create the Ingress resource by running the following command:
-    
+
    ```shell
    kubectl apply -f example-ingress.yaml
    ```
-    
+
    Output:
-    
+
    ```shell
    ingress.networking.k8s.io/example-ingress created
    ```

-1. Verify the IP address is set: 
+1. Verify the IP address is set:

-    ```shell 
+    ```shell
    kubectl get ingress
    ```

@@ -173,7 +175,7 @@ The following file is an Ingress resource that sends traffic to your Service via
    example-ingress   hello-world.info   172.17.0.15   80        38s
    ```

-1. Add the following line to the bottom of the `/etc/hosts` file. 
+1. Add the following line to the bottom of the `/etc/hosts` file.

    {{< note >}}If you are running Minikube locally, use `minikube ip` to get the external IP. The IP address displayed within the ingress list will be the internal IP.{{< /note >}}

@@ -190,7 +192,7 @@ The following file is an Ingress resource that sends traffic to your Service via
    ```

    Output:
-    
+
    ```shell
    Hello, world!
    Version: 1.0.0
@@ -207,26 +209,26 @@ The following file is an Ingress resource that sends traffic to your Service via
    kubectl create deployment web2 --image=gcr.io/google-samples/hello-app:2.0
    ```
    Output:
-    
+
    ```shell
    deployment.apps/web2 created
    ```
-    
+
 1. Expose the Deployment:

    ```shell
    kubectl expose deployment web2 --port=8080 --type=NodePort
    ```

-    Output: 
-    
+    Output:
+
    ```shell
    service/web2 exposed
    ```
-    
+
 ## Edit Ingress

-1. Edit the existing `example-ingress.yaml` and add the following lines:  
+1. Edit the existing `example-ingress.yaml` and add the following lines:

    ```yaml
          - path: /v2
@@ -241,7 +243,8 @@ The following file is an Ingress resource that sends traffic to your Service via
    kubectl apply -f example-ingress.yaml
    ```

-    Output: 
+    Output:
+
    ```shell
    ingress.networking/example-ingress configured
    ```
@@ -255,6 +258,7 @@ The following file is an Ingress resource that sends traffic to your Service via
    ```

    Output:
+
    ```shell
    Hello, world!
    Version: 1.0.0
@@ -268,6 +272,7 @@ The following file is an Ingress resource that sends traffic to your Service via
    ```

    Output:
+
    ```shell
    Hello, world!
    Version: 2.0.0
@@ -9,15 +9,10 @@ weight: 100
 This page shows how to use kubectl to list all of the Container images
 for Pods running in a cluster.

-
-
 ## {{% heading "prerequisites" %}}

-
 {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}

-
-
 <!-- steps -->

 In this exercise you will use kubectl to fetch all of the Pods
@@ -30,14 +25,14 @@ of Containers for each.
 - Format the output to include only the list of Container image names
  using `-o jsonpath={..image}`.  This will recursively parse out the
  `image` field from the returned json.
-  - See the [jsonpath reference](/docs/user-guide/jsonpath/)
+  - See the [jsonpath reference](/docs/reference/kubectl/jsonpath/)
    for further information on how to use jsonpath.
 - Format the output using standard tools: `tr`, `sort`, `uniq`
  - Use `tr` to replace spaces with newlines
  - Use `sort` to sort the results
  - Use `uniq` to aggregate image counts

-```sh
+```shell
 kubectl get pods --all-namespaces -o jsonpath="{..image}" |\
 tr -s '[[:space:]]' '\n' |\
 sort |\
@@ -52,7 +47,7 @@ field within the Pod.  This ensures the correct field is retrieved
 even when the field name is repeated,
 e.g. many fields are called `name` within a given item:

-```sh
+```shell
 kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}"
 ```

@@ -74,7 +69,7 @@ Pod is returned instead of a list of items.
 The formatting can be controlled further by using the `range` operation to
 iterate over elements individually.

-```sh
+```shell
 kubectl get pods --all-namespaces -o=jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\
 sort
 ```
@@ -84,7 +79,7 @@ sort
 To target only Pods matching a specific label, use the -l flag.  The
 following matches only Pods with labels matching `app=nginx`.

-```sh
+```shell
 kubectl get pods --all-namespaces -o=jsonpath="{..image}" -l app=nginx
 ```

@@ -93,7 +88,7 @@ kubectl get pods --all-namespaces -o=jsonpath="{..image}" -l app=nginx
 To target only pods in a specific namespace, use the namespace flag. The
 following matches only Pods in the `kube-system` namespace.

-```sh
+```shell
 kubectl get pods --namespace kube-system -o jsonpath="{..image}"
 ```

@@ -102,27 +97,14 @@ kubectl get pods --namespace kube-system -o jsonpath="{..image}"
 As an alternative to jsonpath, Kubectl supports using [go-templates](https://golang.org/pkg/text/template/)
 for formatting the output:

-
-```sh
+```shell
 kubectl get pods --all-namespaces -o go-template --template="{{range .items}}{{range .spec.containers}}{{.image}} {{end}}{{end}}"
 ```

-
-
-
-
-<!-- discussion -->
-
-
-
 ## {{% heading "whatsnext" %}}

-
 ### Reference

-* [Jsonpath](/docs/user-guide/jsonpath/) reference guide
+* [Jsonpath](/docs/reference/kubectl/jsonpath/) reference guide
 * [Go template](https://golang.org/pkg/text/template/) reference guide

-
-
-
@@ -14,15 +14,19 @@ card:

 <!-- overview -->

-Dashboard is a web-based Kubernetes user interface. You can use Dashboard to deploy containerized applications to a Kubernetes cluster, troubleshoot your containerized application, and manage the cluster resources. You can use Dashboard to get an overview of applications running on your cluster, as well as for creating or modifying individual Kubernetes resources (such as Deployments, Jobs, DaemonSets, etc). For example, you can scale a Deployment, initiate a rolling update, restart a pod or deploy new applications using a deploy wizard.
+Dashboard is a web-based Kubernetes user interface.
+You can use Dashboard to deploy containerized applications to a Kubernetes cluster,
+troubleshoot your containerized application, and manage the cluster resources.
+You can use Dashboard to get an overview of applications running on your cluster,
+as well as for creating or modifying individual Kubernetes resources
+(such as Deployments, Jobs, DaemonSets, etc).
+For example, you can scale a Deployment, initiate a rolling update, restart a pod
+or deploy new applications using a deploy wizard.

 Dashboard also provides information on the state of Kubernetes resources in your cluster and on any errors that may have occurred.

 ![Kubernetes Dashboard UI](/images/docs/ui-dashboard.png)

-
-
-
 <!-- body -->

 ## Deploying the Dashboard UI
@@ -35,8 +39,10 @@ kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0/a

 ## Accessing the Dashboard UI

-
-To protect your cluster data, Dashboard deploys with a minimal RBAC configuration by default. Currently, Dashboard only supports logging in with a Bearer Token. To create a token for this demo, you can follow our guide on [creating a sample user](https://github.com/kubernetes/dashboard/blob/master/docs/user/access-control/creating-sample-user.md).
+To protect your cluster data, Dashboard deploys with a minimal RBAC configuration by default.
+Currently, Dashboard only supports logging in with a Bearer Token.
+To create a token for this demo, you can follow our guide on
+[creating a sample user](https://github.com/kubernetes/dashboard/blob/master/docs/user/access-control/creating-sample-user.md).

 {{< warning >}}
 The sample user created in the tutorial will have administrative privileges and is for educational purposes only.
@@ -59,13 +65,17 @@ Kubeconfig Authentication method does NOT support external identity providers or

 ## Welcome view

-When you access Dashboard on an empty cluster, you'll see the welcome page. This page contains a link to this document as well as a button to deploy your first application. In addition, you can view which system applications are running by default in the `kube-system` [namespace](/docs/tasks/administer-cluster/namespaces/) of your cluster, for example the Dashboard itself.
+When you access Dashboard on an empty cluster, you'll see the welcome page.
+This page contains a link to this document as well as a button to deploy your first application.
+In addition, you can view which system applications are running by default in the `kube-system`
+[namespace](/docs/tasks/administer-cluster/namespaces/) of your cluster, for example the Dashboard itself.

 ![Kubernetes Dashboard welcome page](/images/docs/ui-dashboard-zerostate.png)

 ## Deploying containerized applications

-Dashboard lets you create and deploy a containerized application as a Deployment and optional Service with a simple wizard. You can either manually specify application details, or upload a YAML or JSON file containing application configuration.
+Dashboard lets you create and deploy a containerized application as a Deployment and optional Service with a simple wizard.
+You can either manually specify application details, or upload a YAML or JSON file containing application configuration.

 Click the **CREATE** button in the upper right corner of any page to begin.

@@ -73,17 +83,29 @@ Click the **CREATE** button in the upper right corner of any page to begin.

 The deploy wizard expects that you provide the following information:

- **App name** (mandatory): Name for your application. A [label](/docs/concepts/overview/working-with-objects/labels/) with the name will be added to the Deployment and Service, if any, that will be deployed.
+- **App name** (mandatory): Name for your application.
+  A [label](/docs/concepts/overview/working-with-objects/labels/) with the name will be
+  added to the Deployment and Service, if any, that will be deployed.

-  The application name must be unique within the selected Kubernetes [namespace](/docs/tasks/administer-cluster/namespaces/). It must start with a lowercase character, and end with a lowercase character or a number, and contain only lowercase letters, numbers and dashes (-). It is limited to 24 characters. Leading and trailing spaces are ignored.
+  The application name must be unique within the selected Kubernetes [namespace](/docs/tasks/administer-cluster/namespaces/).
+  It must start with a lowercase character, and end with a lowercase character or a number,
+  and contain only lowercase letters, numbers and dashes (-). It is limited to 24 characters.
+  Leading and trailing spaces are ignored.

- **Container image** (mandatory): The URL of a public Docker [container image](/docs/concepts/containers/images/) on any registry, or a private image (commonly hosted on the Google Container Registry or Docker Hub). The container image specification must end with a colon.
+- **Container image** (mandatory):
+  The URL of a public Docker [container image](/docs/concepts/containers/images/) on any registry,
+  or a private image (commonly hosted on the Google Container Registry or Docker Hub).
+  The container image specification must end with a colon.

- **Number of pods** (mandatory): The target number of Pods you want your application to be deployed in. The value must be a positive integer.
+- **Number of pods** (mandatory): The target number of Pods you want your application to be deployed in.
+  The value must be a positive integer.

-  A [Deployment](/docs/concepts/workloads/controllers/deployment/) will be created to maintain the desired number of Pods across your cluster.
+  A [Deployment](/docs/concepts/workloads/controllers/deployment/) will be created to
+  maintain the desired number of Pods across your cluster.

- **Service** (optional): For some parts of your application (e.g. frontends) you may want to expose a [Service](/docs/concepts/services-networking/service/) onto an external, maybe public IP address outside of your cluster (external Service).
+- **Service** (optional): For some parts of your application (e.g. frontends) you may want to expose a
+  [Service](/docs/concepts/services-networking/service/) onto an external,
+  maybe public IP address outside of your cluster (external Service).

  {{< note >}}
  For external Services, you may need to open up one or more ports to do so.
@@ -91,13 +113,22 @@ The deploy wizard expects that you provide the following information:

  Other Services that are only visible from inside the cluster are called internal Services.

-  Irrespective of the Service type, if you choose to create a Service and your container listens on a port (incoming), you need to specify two ports. The Service will be created mapping the port (incoming) to the target port seen by the container. This Service will route to your deployed Pods. Supported protocols are TCP and UDP. The internal DNS name for this Service will be the value you specified as application name above.
+  Irrespective of the Service type, if you choose to create a Service and your container listens
+  on a port (incoming), you need to specify two ports.
+  The Service will be created mapping the port (incoming) to the target port seen by the container.
+  This Service will route to your deployed Pods. Supported protocols are TCP and UDP.
+  The internal DNS name for this Service will be the value you specified as application name above.

 If needed, you can expand the **Advanced options** section where you can specify more settings:

- **Description**: The text you enter here will be added as an [annotation](/docs/concepts/overview/working-with-objects/annotations/) to the Deployment and displayed in the application's details.
+- **Description**: The text you enter here will be added as an
+  [annotation](/docs/concepts/overview/working-with-objects/annotations/)
+  to the Deployment and displayed in the application's details.

- **Labels**: Default [labels](/docs/concepts/overview/working-with-objects/labels/) to be used for your application are application name and version. You can specify additional labels to be applied to the Deployment, Service (if any), and Pods, such as release, environment, tier, partition, and release track.
+- **Labels**: Default [labels](/docs/concepts/overview/working-with-objects/labels/) to be used
+  for your application are application name and version.
+  You can specify additional labels to be applied to the Deployment, Service (if any), and Pods,
+  such as release, environment, tier, partition, and release track.

  Example:

@@ -108,66 +139,111 @@ If needed, you can expand the **Advanced options** section where you can specify
  track=stable
  ```

- **Namespace**: Kubernetes supports multiple virtual clusters backed by the same physical cluster. These virtual clusters are called [namespaces](/docs/tasks/administer-cluster/namespaces/). They let you partition resources into logically named groups.
+- **Namespace**: Kubernetes supports multiple virtual clusters backed by the same physical cluster.
+  These virtual clusters are called [namespaces](/docs/tasks/administer-cluster/namespaces/).
+  They let you partition resources into logically named groups.

-  Dashboard offers all available namespaces in a dropdown list, and allows you to create a new namespace. The namespace name may contain a maximum of 63 alphanumeric characters and dashes (-) but can not contain capital letters.
-  Namespace names should not consist of only numbers. If the name is set as a number, such as 10, the pod will be put in the default namespace.
+  Dashboard offers all available namespaces in a dropdown list, and allows you to create a new namespace.
+  The namespace name may contain a maximum of 63 alphanumeric characters and dashes (-) but can not contain capital letters.
+  Namespace names should not consist of only numbers.
+  If the name is set as a number, such as 10, the pod will be put in the default namespace.

-  In case the creation of the namespace is successful, it is selected by default. If the creation fails, the first namespace is selected.
+  In case the creation of the namespace is successful, it is selected by default.
+  If the creation fails, the first namespace is selected.

- **Image Pull Secret**: In case the specified Docker container image is private, it may require [pull secret](/docs/concepts/configuration/secret/) credentials.
+- **Image Pull Secret**:
+  In case the specified Docker container image is private, it may require
+  [pull secret](/docs/concepts/configuration/secret/) credentials.

-  Dashboard offers all available secrets in a dropdown list, and allows you to create a new secret. The secret name must follow the DNS domain name syntax, for example `new.image-pull.secret`. The content of a secret must be base64-encoded and specified in a  [`.dockercfg`](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod) file. The secret name may consist of a maximum of 253 characters.
+  Dashboard offers all available secrets in a dropdown list, and allows you to create a new secret.
+  The secret name must follow the DNS domain name syntax, for example `new.image-pull.secret`.
+  The content of a secret must be base64-encoded and specified in a
+  [`.dockercfg`](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod) file.
+  The secret name may consist of a maximum of 253 characters.

  In case the creation of the image pull secret is successful, it is selected by default. If the creation fails, no secret is applied.

- **CPU requirement (cores)** and **Memory requirement (MiB)**: You can specify the minimum [resource limits](/docs/tasks/configure-pod-container/limit-range/) for the container. By default, Pods run with unbounded CPU and memory limits.
+- **CPU requirement (cores)** and **Memory requirement (MiB)**:
+  You can specify the minimum [resource limits](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)
+  for the container. By default, Pods run with unbounded CPU and memory limits.

- **Run command** and **Run command arguments**: By default, your containers run the specified Docker image's default [entrypoint command](/docs/tasks/inject-data-application/define-command-argument-container/). You can use the command options and arguments to override the default.
+- **Run command** and **Run command arguments**:
+  By default, your containers run the specified Docker image's default
+  [entrypoint command](/docs/tasks/inject-data-application/define-command-argument-container/).
+  You can use the command options and arguments to override the default.

- **Run as privileged**: This setting determines whether processes in [privileged containers](/docs/user-guide/pods/#privileged-mode-for-pod-containers) are equivalent to processes running as root on the host. Privileged containers can make use of capabilities like manipulating the network stack and accessing devices.
+- **Run as privileged**: This setting determines whether processes in
+  [privileged containers](/docs/concepts/workloads/pods/#privileged-mode-for-containers)
+  are equivalent to processes running as root on the host.
+  Privileged containers can make use of capabilities like manipulating the network stack and accessing devices.

- **Environment variables**: Kubernetes exposes Services through [environment variables](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/). You can compose environment variable or pass arguments to your commands using the values of environment variables. They can be used in applications to find a Service. Values can reference other variables using the `$(VAR_NAME)` syntax.
+- **Environment variables**: Kubernetes exposes Services through
+  [environment variables](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/).
+  You can compose environment variable or pass arguments to your commands using the values of environment variables.
+  They can be used in applications to find a Service.
+  Values can reference other variables using the `$(VAR_NAME)` syntax.

 ### Uploading a YAML or JSON file

-Kubernetes supports declarative configuration. In this style, all configuration is stored in YAML or JSON configuration files using the Kubernetes [API](/docs/concepts/overview/kubernetes-api/) resource schemas.
+Kubernetes supports declarative configuration.
+In this style, all configuration is stored in YAML or JSON configuration files
+using the Kubernetes [API](/docs/concepts/overview/kubernetes-api/) resource schemas.

-As an alternative to specifying application details in the deploy wizard, you can define your application in YAML or JSON files, and upload the files using Dashboard.
+As an alternative to specifying application details in the deploy wizard,
+you can define your application in YAML or JSON files, and upload the files using Dashboard.

 ## Using Dashboard
 Following sections describe views of the Kubernetes Dashboard UI; what they provide and how can they be used.

 ### Navigation

-When there are Kubernetes objects defined in the cluster, Dashboard shows them in the initial view. By default only objects from the _default_ namespace are shown and this can be changed using the namespace selector located in the navigation menu.
+When there are Kubernetes objects defined in the cluster, Dashboard shows them in the initial view.
+By default only objects from the _default_ namespace are shown and
+this can be changed using the namespace selector located in the navigation menu.

 Dashboard shows most Kubernetes object kinds and groups them in a few menu categories.

 #### Admin Overview
-For cluster and namespace administrators, Dashboard lists Nodes, Namespaces and Persistent Volumes and has detail views for them. Node list view contains CPU and memory usage metrics aggregated across all Nodes. The details view shows the metrics for a Node, its specification, status, allocated resources, events and pods running on the node.
+For cluster and namespace administrators, Dashboard lists Nodes, Namespaces and Persistent Volumes and has detail views for them.
+Node list view contains CPU and memory usage metrics aggregated across all Nodes.
+The details view shows the metrics for a Node, its specification, status,
+allocated resources, events and pods running on the node.

 #### Workloads
-Shows all applications running in the selected namespace. The view lists applications by workload kind (e.g., Deployments, Replica Sets, Stateful Sets, etc.) and each workload kind can be viewed separately. The lists summarize actionable information about the workloads, such as the number of ready pods for a Replica Set or current memory usage for a Pod.

-Detail views for workloads show status and specification information and surface relationships between objects. For example, Pods that Replica Set is controlling or New Replica Sets and Horizontal Pod Autoscalers for Deployments.
+Shows all applications running in the selected namespace.
+The view lists applications by workload kind (e.g., Deployments, Replica Sets, Stateful Sets, etc.)
+and each workload kind can be viewed separately.
+The lists summarize actionable information about the workloads,
+such as the number of ready pods for a Replica Set or current memory usage for a Pod.
+
+Detail views for workloads show status and specification information and
+surface relationships between objects.
+For example, Pods that Replica Set is controlling or New Replica Sets and Horizontal Pod Autoscalers for Deployments.

 #### Services
-Shows Kubernetes resources that allow for exposing services to external world and discovering them within a cluster. For that reason, Service and Ingress views show Pods targeted by them, internal endpoints for cluster connections and external endpoints for external users.
+
+Shows Kubernetes resources that allow for exposing services to external world and
+discovering them within a cluster.
+For that reason, Service and Ingress views show Pods targeted by them,
+internal endpoints for cluster connections and external endpoints for external users.

 #### Storage
+
 Storage view shows Persistent Volume Claim resources which are used by applications for storing data.

 #### Config Maps and Secrets
-Shows all Kubernetes resources that are used for live configuration of applications running in clusters. The view allows for editing and managing config objects and displays secrets hidden by default.
+
+Shows all Kubernetes resources that are used for live configuration of applications running in clusters.
+The view allows for editing and managing config objects and displays secrets hidden by default.

 #### Logs viewer
-Pod lists and detail pages link to a logs viewer that is built into Dashboard. The viewer allows for drilling down logs from containers belonging to a single Pod.
+
+Pod lists and detail pages link to a logs viewer that is built into Dashboard.
+The viewer allows for drilling down logs from containers belonging to a single Pod.

 ![Logs viewer](/images/docs/ui-dashboard-logs-view.png)

-
-
 ## {{% heading "whatsnext" %}}


@@ -6,13 +6,10 @@ content_type: task
 <!-- overview -->
 This page shows how to access clusters using the Kubernetes API.

-
 ## {{% heading "prerequisites" %}}

-
 {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}

-
 <!-- steps -->

 ## Accessing the Kubernetes API
@@ -170,7 +167,7 @@ client-go defines its own API objects, so if needed, import API definitions from

 {{< /note >}}

-The Go client can use the same [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)
+The Go client can use the same [kubeconfig file](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
 as the kubectl CLI does to locate and authenticate to the API server. See this [example](https://git.k8s.io/client-go/examples/out-of-cluster-client-configuration/main.go):

 ```golang
@@ -199,7 +196,7 @@ If the application is deployed as a Pod in the cluster, see [Accessing the API f

 To use [Python client](https://github.com/kubernetes-client/python), run the following command: `pip install kubernetes` See [Python Client Library page](https://github.com/kubernetes-client/python) for more installation options.

-The Python client can use the same [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)
+The Python client can use the same [kubeconfig file](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
 as the kubectl CLI does to locate and authenticate to the API server. See this [example](https://github.com/kubernetes-client/python/blob/master/examples/out_of_cluster_config.py):

 ```python
@@ -229,7 +226,7 @@ mvn install

 See [https://github.com/kubernetes-client/java/releases](https://github.com/kubernetes-client/java/releases) to see which versions are supported.

-The Java client can use the same [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)
+The Java client can use the same [kubeconfig file](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
 as the kubectl CLI does to locate and authenticate to the API server. See this [example](https://github.com/kubernetes-client/java/blob/master/examples/src/main/java/io/kubernetes/client/examples/KubeConfigFileClientExample.java):

 ```java
@@ -283,7 +280,7 @@ public class KubeConfigFileClientExample {

 To use [dotnet client](https://github.com/kubernetes-client/csharp), run the following command: `dotnet add package KubernetesClient --version 1.6.1` See [dotnet Client Library page](https://github.com/kubernetes-client/csharp) for more installation options. See [https://github.com/kubernetes-client/csharp/releases](https://github.com/kubernetes-client/csharp/releases) to see which versions are supported.

-The dotnet client can use the same [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)
+The dotnet client can use the same [kubeconfig file](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
 as the kubectl CLI does to locate and authenticate to the API server. See this [example](https://github.com/kubernetes-client/csharp/blob/master/examples/simple/PodList.cs):

 ```csharp
@@ -318,7 +315,7 @@ namespace simple

 To install [JavaScript client](https://github.com/kubernetes-client/javascript), run the following command: `npm install @kubernetes/client-node`. See [https://github.com/kubernetes-client/javascript/releases](https://github.com/kubernetes-client/javascript/releases) to see which versions are supported.

-The JavaScript client can use the same [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)
+The JavaScript client can use the same [kubeconfig file](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
 as the kubectl CLI does to locate and authenticate to the API server. See this [example](https://github.com/kubernetes-client/javascript/blob/master/examples/example.js):

 ```javascript
@@ -338,7 +335,7 @@ k8sApi.listNamespacedPod('default').then((res) => {

 See [https://github.com/kubernetes-client/haskell/releases](https://github.com/kubernetes-client/haskell/releases) to see which versions are supported.

-The [Haskell client](https://github.com/kubernetes-client/haskell) can use the same [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)
+The [Haskell client](https://github.com/kubernetes-client/haskell) can use the same [kubeconfig file](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
 as the kubectl CLI does to locate and authenticate to the API server. See this [example](https://github.com/kubernetes-client/haskell/blob/master/kubernetes-client/example/App.hs):

 ```haskell
@@ -388,7 +385,7 @@ While running in a Pod, the Kubernetes apiserver is accessible via a Service nam
 do this automatically.

 The recommended way to authenticate to the API server is with a
-[service account](/docs/user-guide/service-accounts) credential. By default, a Pod
+[service account](/docs/tasks/configure-pod-container/configure-service-account/) credential. By default, a Pod
 is associated with a service account, and a credential (token) for that
 service account is placed into the filesystem tree of each container in that Pod,
 at `/var/run/secrets/kubernetes.io/serviceaccount/token`.
@@ -17,7 +17,8 @@ This page shows how to connect to services running on the Kubernetes cluster.

 ## Accessing services running on the cluster

-In Kubernetes, [nodes](/docs/admin/node), [pods](/docs/user-guide/pods) and [services](/docs/user-guide/services) all have
+In Kubernetes, [nodes](/docs/concepts/architecture/nodes/),
+[pods](/docs/concepts/workloads/pods/) and [services](/docs/concepts/services-networking/service/) all have
 their own IPs.  In many cases, the node IPs, pod IPs, and some service IPs on a cluster will not be
 routable, so they will not be reachable from a machine outside the cluster,
 such as your desktop machine.
@@ -28,7 +29,7 @@ You have several options for connecting to nodes, pods and services from outside

  - Access services through public IPs.
    - Use a service with type `NodePort` or `LoadBalancer` to make the service reachable outside
-      the cluster.  See the [services](/docs/user-guide/services) and
+      the cluster.  See the [services](/docs/concepts/services-networking/service/) and
      [kubectl expose](/docs/reference/generated/kubectl/kubectl-commands/#expose) documentation.
    - Depending on your cluster environment, this may just expose the service to your corporate network,
      or it may expose it to the internet.  Think about whether the service being exposed is secure.
@@ -13,9 +13,6 @@ upgrading your cluster's
 master and worker nodes, performing node maintenance (e.g. kernel upgrades), and upgrading the Kubernetes API version of a
 running cluster.

-
-
-
 <!-- body -->

 ## Creating and configuring a Cluster
@@ -81,24 +78,33 @@ Different providers, and tools, will manage upgrades differently.  It is recomme
 * [Digital Rebar](https://provision.readthedocs.io/en/tip/doc/content-packages/krib.html)
 * ...

-To upgrade a cluster on a platform not mentioned in the above list, check the order of component upgrade on the [Skewed versions](/docs/setup/release/version-skew-policy/#supported-component-upgrade-order) page.
+To upgrade a cluster on a platform not mentioned in the above list, check the order of component upgrade on the
+[Skewed versions](/docs/setup/release/version-skew-policy/#supported-component-upgrade-order) page.

 ## Resizing a cluster

-If your cluster runs short on resources you can easily add more machines to it if your cluster is running in [Node self-registration mode](/docs/admin/node/#self-registration-of-nodes).
-If you're using GCE or Google Kubernetes Engine it's done by resizing the Instance Group managing your Nodes. It can be accomplished by modifying number of instances on `Compute > Compute Engine > Instance groups > your group > Edit group` [Google Cloud Console page](https://console.developers.google.com) or using gcloud CLI:
+If your cluster runs short on resources you can easily add more machines to it if your cluster
+is running in [Node self-registration mode](/docs/concepts/architecture/nodes/#self-registration-of-nodes).
+If you're using GCE or Google Kubernetes Engine it's done by resizing the Instance Group managing your Nodes.
+It can be accomplished by modifying number of instances on
+`Compute > Compute Engine > Instance groups > your group > Edit group`
+[Google Cloud Console page](https://console.developers.google.com) or using gcloud CLI:

 ```shell
 gcloud compute instance-groups managed resize kubernetes-node-pool --size=42 --zone=$ZONE
 ```

-The Instance Group will take care of putting appropriate image on new machines and starting them, while the Kubelet will register its Node with the API server to make it available for scheduling. If you scale the instance group down, system will randomly choose Nodes to kill.
+The Instance Group will take care of putting appropriate image on new machines and starting them,
+while the Kubelet will register its Node with the API server to make it available for scheduling.
+If you scale the instance group down, system will randomly choose Nodes to kill.

 In other environments you may need to configure the machine yourself and tell the Kubelet on which machine API server is running.

 ### Resizing an Azure Kubernetes Service (AKS) cluster

-Azure Kubernetes Service enables user-initiated resizing of the cluster from either the CLI or the Azure Portal and is described in the [Azure AKS documentation](https://docs.microsoft.com/en-us/azure/aks/scale-cluster).
+Azure Kubernetes Service enables user-initiated resizing of the cluster from either the CLI or
+the Azure Portal and is described in the
+[Azure AKS documentation](https://docs.microsoft.com/en-us/azure/aks/scale-cluster).


 ### Cluster autoscaling
@@ -106,7 +112,8 @@ Azure Kubernetes Service enables user-initiated resizing of the cluster from eit
 If you are using GCE or Google Kubernetes Engine, you can configure your cluster so that it is automatically rescaled based on
 pod needs.

-As described in [Compute Resource](/docs/concepts/configuration/manage-compute-resources-container/), users can reserve how much CPU and memory is allocated to pods.
+As described in [Compute Resource](/docs/concepts/configuration/manage-resources-containers/),
+users can reserve how much CPU and memory is allocated to pods.
 This information is used by the Kubernetes scheduler to find a place to run the pod. If there is
 no node that has enough free capacity (or doesn't match other pod requirements) then the pod has
 to wait until some pods are terminated or a new node is added.
@@ -185,7 +192,8 @@ kubectl uncordon $NODENAME

 If you deleted the node's VM instance and created a new one, then a new schedulable node resource will
 be created automatically (if you're using a cloud provider that supports
-node discovery; currently this is only Google Compute Engine, not including CoreOS on Google Compute Engine using kube-register). See [Node](/docs/admin/node) for more details.
+node discovery; currently this is only Google Compute Engine, not including CoreOS on Google Compute Engine using kube-register).
+See [Node](/docs/concepts/architecture/nodes/) for more details.

 ## Advanced Topics

@@ -50,7 +50,7 @@ and more. For more information, see [DNS for Services and Pods](/docs/concepts/s
 If a Pod's `dnsPolicy` is set to `default`, it inherits the name resolution
 configuration from the node that the Pod runs on. The Pod's DNS resolution
 should behave the same as the node.
-But see [Known issues](/docs/tasks/debug-application-cluster/dns-debugging-resolution/#known-issues).
+But see [Known issues](/docs/tasks/administer-cluster/dns-debugging-resolution/#known-issues).

 If you don't want this, or if you want a different DNS config for pods, you can
 use the kubelet's `--resolv-conf` flag.  Set this flag to "" to prevent Pods from
@@ -27,11 +27,8 @@ The upgrade workflow at high level is the following:
 1. Upgrade additional control plane nodes.
 1. Upgrade worker nodes.

-
-
 ## {{% heading "prerequisites" %}}

-
 - You need to have a kubeadm Kubernetes cluster running version 1.18.0 or later.
 - [Swap must be disabled](https://serverfault.com/questions/684771/best-way-to-disable-swap-in-linux).
 - The cluster should use a static control plane and etcd pods or external etcd.
@@ -46,8 +43,6 @@ The upgrade workflow at high level is the following:
  or between PATCH versions of the same MINOR. That is, you cannot skip MINOR versions when you upgrade.
  For example, you can upgrade from 1.y to 1.y+1, but not from 1.y to 1.y+2.

-
-
 <!-- steps -->

 ## Determine which version to upgrade to
@@ -10,14 +10,9 @@ weight: 40

 This page shows how to use Romana for NetworkPolicy.

-
-
 ## {{% heading "prerequisites" %}}

-
-Complete steps 1, 2, and 3 of the [kubeadm getting started guide](/docs/getting-started-guides/kubeadm/).
-
-
+Complete steps 1, 2, and 3 of the [kubeadm getting started guide](/docs/reference/setup-tools/kubeadm/kubeadm/).

 <!-- steps -->

@@ -33,13 +28,10 @@ To apply network policies use one of the following:
    * [Example of Romana network policy](https://github.com/romana/core/blob/master/doc/policy.md).
 * The NetworkPolicy API.

-
-
 ## {{% heading "whatsnext" %}}

-
-Once you have installed Romana, you can follow the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) to try out Kubernetes NetworkPolicy.
-
-
+Once you have installed Romana, you can follow the
+[Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/)
+to try out Kubernetes NetworkPolicy.


@@ -10,14 +10,10 @@ weight: 50

 This page shows how to use Weave Net for NetworkPolicy.

-
-
 ## {{% heading "prerequisites" %}}

-
-You need to have a Kubernetes cluster. Follow the [kubeadm getting started guide](/docs/getting-started-guides/kubeadm/) to bootstrap one.
-
-
+You need to have a Kubernetes cluster. Follow the
+[kubeadm getting started guide](/docs/reference/setup-tools/kubeadm/kubeadm/) to bootstrap one.

 <!-- steps -->

@@ -25,7 +21,10 @@ You need to have a Kubernetes cluster. Follow the [kubeadm getting started guide

 Follow the [Integrating Kubernetes via the Addon](https://www.weave.works/docs/net/latest/kube-addon/) guide.

-The Weave Net addon for Kubernetes comes with a [Network Policy Controller](https://www.weave.works/docs/net/latest/kube-addon/#npc) that automatically monitors Kubernetes for any NetworkPolicy annotations on all namespaces and configures `iptables` rules to allow or block traffic as directed by the policies.
+The Weave Net addon for Kubernetes comes with a
+[Network Policy Controller](https://www.weave.works/docs/net/latest/kube-addon/#npc)
+that automatically monitors Kubernetes for any NetworkPolicy annotations on all
+namespaces and configures `iptables` rules to allow or block traffic as directed by the policies.

 ## Test the installation

@@ -49,13 +48,10 @@ weave-net-pmw8w                         2/2       Running   0          9d

 Each Node has a weave Pod, and all Pods are `Running` and `2/2 READY`. (`2/2` means that each Pod has `weave` and `weave-npc`.)

-
-
 ## {{% heading "whatsnext" %}}

-
-Once you have installed the Weave Net addon, you can follow the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) to try out Kubernetes NetworkPolicy. If you have any question, contact us at [#weave-community on Slack or Weave User Group](https://github.com/weaveworks/weave#getting-help).
-
-
-
+Once you have installed the Weave Net addon, you can follow the
+[Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/)
+to try out Kubernetes NetworkPolicy. If you have any question, contact us at
+[#weave-community on Slack or Weave User Group](https://github.com/weaveworks/weave#getting-help).

@@ -16,9 +16,6 @@ are low. This is especially important when dealing with incompressible
 compute resources, such as memory or disk space. If such resources are exhausted,
 nodes become unstable.

-
-
-
 <!-- body -->

 ## Eviction Policy
@@ -53,8 +50,7 @@ like `free -m`. This is important because `free -m` does not work in a
 container, and if users use the [node
 allocatable](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) feature, out of resource decisions
 are made local to the end user Pod part of the cgroup hierarchy as well as the
-root node. This
-[script](/docs/tasks/administer-cluster/out-of-resource/memory-available.sh)
+root node. This [script](/docs/tasks/administer-cluster/memory-available.sh)
 reproduces the same set of steps that the `kubelet` performs to calculate
 `memory.available`. The `kubelet` excludes inactive_file (i.e. # of bytes of
 file-backed memory on inactive LRU list) from its calculation as it assumes that
@@ -56,7 +56,9 @@ an integrated [Role-Based Access Control (RBAC)](/docs/reference/access-authn-au
 set of permissions bundled into roles. These permissions combine verbs (get, create, delete) with
 resources (pods, services, nodes) and can be namespace or cluster scoped. A set of out of the box
 roles are provided that offer reasonable default separation of responsibility depending on what
-actions a client might want to perform. It is recommended that you use the [Node](/docs/reference/access-authn-authz/node/) and [RBAC](/docs/reference/access-authn-authz/rbac/) authorizers together, in combination with the
+actions a client might want to perform. It is recommended that you use the
+[Node](/docs/reference/access-authn-authz/node/) and
+[RBAC](/docs/reference/access-authn-authz/rbac/) authorizers together, in combination with the
 [NodeRestriction](/docs/reference/access-authn-authz/admission-controllers/#noderestriction) admission plugin.

 As with authentication, simple and broad roles may be appropriate for smaller clusters, but as
@@ -79,7 +81,7 @@ Kubelets expose HTTPS endpoints which grant powerful control over the node and c

 Production clusters should enable Kubelet authentication and authorization.

-Consult the [Kubelet authentication/authorization reference](/docs/admin/kubelet-authentication-authorization) for more information.
+Consult the [Kubelet authentication/authorization reference](/docs/reference/command-line-tools-reference/kubelet-authentication-authorization) for more information.

 ## Controlling the capabilities of a workload or user at runtime

@@ -252,9 +254,8 @@ are not encrypted or an attacker gains read access to etcd.
 ### Receiving alerts for security updates and reporting vulnerabilities

 Join the [kubernetes-announce](https://groups.google.com/forum/#!forum/kubernetes-announce)
-group for emails about security announcements. See the [security reporting](/security/)
+group for emails about security announcements. See the
+[security reporting](/docs/reference/issues-security/security/)
 page for more on how to report vulnerabilities.


-
-
@@ -8,7 +8,7 @@ weight: 110

 This page shows how to configure liveness, readiness and startup probes for containers.

-The [kubelet](/docs/admin/kubelet/) uses liveness probes to know when to
+The [kubelet](/docs/reference/command-line-tools-reference/kubelet/) uses liveness probes to know when to
 restart a container. For example, liveness probes could catch a deadlock,
 where an application is running, but unable to make progress. Restarting a
 container in such a state can help to make the application more available
@@ -29,13 +29,11 @@ PersistentVolume.
 {{< glossary_tooltip text="kubectl" term_id="kubectl" >}}
 command-line tool must be configured to communicate with your cluster. If you
 do not already have a single-node cluster, you can create one by using
-[Minikube](/docs/getting-started-guides/minikube).
+[Minikube](/docs/setup/learning-environment/minikube/).

 * Familiarize yourself with the material in
 [Persistent Volumes](/docs/concepts/storage/persistent-volumes/).

-
-
 <!-- steps -->

 ## Create an index.html file on your Node
@@ -39,10 +39,14 @@ When they do, they are authenticated as a particular Service Account (for exampl

 When you create a pod, if you do not specify a service account, it is
 automatically assigned the `default` service account in the same namespace.
-If you get the raw json or yaml for a pod you have created (for example, `kubectl get pods/<podname> -o yaml`), you can see the `spec.serviceAccountName` field has been [automatically set](/docs/user-guide/working-with-resources/#resources-are-automatically-modified).
+If you get the raw json or yaml for a pod you have created (for example, `kubectl get pods/<podname> -o yaml`),
+you can see the `spec.serviceAccountName` field has been
+[automatically set](/docs/concepts/overview/working-with-objects/object-management/).

-You can access the API from inside a pod using automatically mounted service account credentials, as described in [Accessing the Cluster](/docs/user-guide/accessing-the-cluster/#accessing-the-api-from-a-pod).
-The API permissions of the service account depend on the [authorization plugin and policy](/docs/reference/access-authn-authz/authorization/#authorization-modules) in use.
+You can access the API from inside a pod using automatically mounted service account credentials, as described in
+[Accessing the Cluster](/docs/tasks/access-application-cluster/access-cluster).
+The API permissions of the service account depend on the
+[authorization plugin and policy](/docs/reference/access-authn-authz/authorization/#authorization-modules) in use.

 In version 1.6+, you can opt out of automounting API credentials for a service account by setting `automountServiceAccountToken: false` on the service account:

@@ -243,7 +243,7 @@ exit

 ## Set capabilities for a Container

-With [Linux capabilities](http://man7.org/linux/man-pages/man7/capabilities.7.html),
+With [Linux capabilities](https://man7.org/linux/man-pages/man7/capabilities.7.html),
 you can grant certain privileges to a process without granting all the privileges
 of the root user. To add or remove Linux capabilities for a Container, include the
 `capabilities` field in the `securityContext` section of the Container manifest.
@@ -9,7 +9,8 @@ weight: 20

 <!-- overview -->

-Kubernetes ships with a default scheduler that is described [here](/docs/admin/kube-scheduler/).
+Kubernetes ships with a default scheduler that is described
+[here](/docs/reference/command-line-tools-reference/kube-scheduler/).
 If the default scheduler does not suit your needs you can implement your own scheduler.
 Not just that, you can even run multiple schedulers simultaneously alongside the default
 scheduler and instruct Kubernetes what scheduler to use for each of your pods. Let's
@@ -20,16 +21,10 @@ document. Please refer to the kube-scheduler implementation in
 [pkg/scheduler](https://github.com/kubernetes/kubernetes/tree/{{< param "githubbranch" >}}/pkg/scheduler)
 in the Kubernetes source directory for a canonical example.

-
-
-
 ## {{% heading "prerequisites" %}}

-
 {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}

-
-
 <!-- steps -->

 ## Package the scheduler
@@ -83,7 +78,7 @@ Note also that we created a dedicated service account `my-scheduler` and bind th
 `system:kube-scheduler` to it so that it can acquire the same privileges as `kube-scheduler`.

 Please see the
-[kube-scheduler documentation](/docs/admin/kube-scheduler/) for
+[kube-scheduler documentation](/docs/reference/command-line-tools-reference/kube-scheduler/) for
 detailed description of other command line arguments.

 ## Run the second scheduler in the cluster
@@ -100,6 +95,7 @@ Verify that the scheduler pod is running:
 ```shell
 kubectl get pods --namespace=kube-system
 ```
+
 ```
 NAME                                           READY     STATUS    RESTARTS   AGE
 ....
@@ -125,8 +121,10 @@ The control plane creates the lock objects for you, but the namespace must alrea
 You can use the `kube-system` namespace.
 {{< /note >}}

-If RBAC is enabled on your cluster, you must update the `system:kube-scheduler` cluster role. Add your scheduler name to the resourceNames of the rule applied for `endpoints` and `leases` resources, as in the following example:
-```
+If RBAC is enabled on your cluster, you must update the `system:kube-scheduler` cluster role.
+Add your scheduler name to the resourceNames of the rule applied for `endpoints` and `leases` resources, as in the following example:
+
+```shell
 kubectl edit clusterrole system:kube-scheduler
 ```

@@ -134,10 +132,11 @@ kubectl edit clusterrole system:kube-scheduler

 ## Specify schedulers for pods

-Now that our second scheduler is running, let's create some pods, and direct them to be scheduled by either the default scheduler or the one we just deployed. In order to schedule a given pod using a specific scheduler, we specify the name of the
+Now that our second scheduler is running, let's create some pods, and direct them
+to be scheduled by either the default scheduler or the one we just deployed.
+In order to schedule a given pod using a specific scheduler, we specify the name of the
 scheduler in that pod spec. Let's look at three examples.

-
 - Pod spec without any scheduler name

  {{< codenew file="admin/sched/pod1.yaml" >}}
@@ -147,9 +146,9 @@ scheduler in that pod spec. Let's look at three examples.

  Save this file as `pod1.yaml` and submit it to the Kubernetes cluster.

-```shell
-kubectl create -f pod1.yaml
-```
+  ```shell
+  kubectl create -f pod1.yaml
+  ```

 - Pod spec with `default-scheduler`

@@ -160,9 +159,9 @@ kubectl create -f pod1.yaml

  Save this file as `pod2.yaml` and submit it to the Kubernetes cluster.

-```shell
-kubectl create -f pod2.yaml
-```
+  ```shell
+  kubectl create -f pod2.yaml
+  ```

 - Pod spec with `my-scheduler`

@@ -174,17 +173,15 @@ kubectl create -f pod2.yaml

  Save this file as `pod3.yaml` and submit it to the Kubernetes cluster.

-```shell
-kubectl create -f pod3.yaml
-```
+  ```shell
+  kubectl create -f pod3.yaml
+  ```

  Verify that all three pods are running.

-```shell
-kubectl get pods
-```
-
-
+  ```shell
+  kubectl get pods
+  ```

 <!-- discussion -->

@@ -206,4 +203,3 @@ verify that the pods were scheduled by the desired schedulers.
 kubectl get events
 ```

-
@@ -13,19 +13,15 @@ This page explains how to add versioning information to
 [CustomResourceDefinitions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#customresourcedefinition-v1beta1-apiextensions), to indicate the stability
 level of your CustomResourceDefinitions or advance your API to a new version with conversion between API representations. It also describes how to upgrade an object from one version to another.

-
-
 ## {{% heading "prerequisites" %}}


 {{< include "task-tutorial-prereqs.md" >}}

-You should have a initial understanding of [custom resources](/docs/concepts/api-extension/custom-resources/).
+You should have a initial understanding of [custom resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/).

 {{< version-check >}}

-
-
 <!-- steps -->

 ## Overview
@@ -374,7 +370,9 @@ conversions that call an external service in case a conversion is required. For
 * Watch is created in one version but the changed object is stored in another version.
 * custom resource PUT request is in a different version than storage version.

-To cover all of these cases and to optimize conversion by the API server, the conversion requests may contain multiple objects in order to minimize the external calls. The webhook should perform these conversions independently.
+To cover all of these cases and to optimize conversion by the API server, 
+the conversion requests may contain multiple objects in order to minimize the external calls.
+The webhook should perform these conversions independently.

 ### Write a conversion webhook server

@@ -385,7 +383,12 @@ that is validated in a Kubernetes e2e test. The webhook handles the
 results wrapped in `ConversionResponse`. Note that the request
 contains a list of custom resources that need to be converted independently without
 changing the order of objects.
-The example server is organized in a way to be reused for other conversions. Most of the common code are located in the [framework file](https://github.com/kubernetes/kubernetes/tree/v1.15.0/test/images/crd-conversion-webhook/converter/framework.go) that leaves only [one function](https://github.com/kubernetes/kubernetes/blob/v1.15.0/test/images/crd-conversion-webhook/converter/example_converter.go#L29-L80) to be implemented for different conversions.
+The example server is organized in a way to be reused for other conversions.
+Most of the common code are located in the
+[framework file](https://github.com/kubernetes/kubernetes/tree/v1.15.0/test/images/crd-conversion-webhook/converter/framework.go)
+that leaves only
+[one function](https://github.com/kubernetes/kubernetes/blob/v1.15.0/test/images/crd-conversion-webhook/converter/example_converter.go#L29-L80)
+to be implemented for different conversions.

 {{< note >}}
 The example conversion webhook server leaves the `ClientAuth` field
@@ -398,12 +401,17 @@ how to [authenticate API servers](/docs/reference/access-authn-authz/extensible-

 #### Permissible mutations

-A conversion webhook must not mutate anything inside of `metadata` of the converted object other than `labels` and `annotations`. Attempted changes to `name`, `UID` and `namespace` are rejected and fail the request which caused the conversion. All other changes are just ignored.  
+A conversion webhook must not mutate anything inside of `metadata` of the converted object
+other than `labels` and `annotations`.
+Attempted changes to `name`, `UID` and `namespace` are rejected and fail the request
+which caused the conversion. All other changes are just ignored.  

 ### Deploy the conversion webhook service

-Documentation for deploying the conversion webhook is the same as for the [admission webhook example service](/docs/reference/access-authn-authz/extensible-admission-controllers/#deploy_the_admission_webhook_service).
-The assumption for next sections is that the conversion webhook server is deployed to a service named `example-conversion-webhook-server` in `default` namespace and serving traffic on path `/crdconvert`.
+Documentation for deploying the conversion webhook is the same as for the
+[admission webhook example service](/docs/reference/access-authn-authz/extensible-admission-controllers/#deploy_the_admission_webhook_service).
+The assumption for next sections is that the conversion webhook server is deployed to a service
+named `example-conversion-webhook-server` in `default` namespace and serving traffic on path `/crdconvert`.

 {{< note >}}
 When the webhook server is deployed into the Kubernetes cluster as a
@@ -639,7 +647,7 @@ at the subpath "/my-path", and to verify the TLS connection against the ServerNa
 {{< tabs name="CustomResourceDefinition_versioning_example_4" >}}
 {{% tab name="apiextensions.k8s.io/v1" %}}
 ```yaml
-apiVersion: apiextensions.k8s.io/v1b
+apiVersion: apiextensions.k8s.io/v1
 kind: CustomResourceDefinition
 ...
 spec:
@@ -16,7 +16,6 @@ This page shows how to install a
 into the Kubernetes API by creating a
 [CustomResourceDefinition](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#customresourcedefinition-v1beta1-apiextensions).

-
 ## {{% heading "prerequisites" %}}


@@ -24,9 +23,7 @@ into the Kubernetes API by creating a

 * Make sure your Kubernetes cluster has a master version of 1.16.0 or higher to use `apiextensions.k8s.io/v1`, or 1.7.0 or higher for `apiextensions.k8s.io/v1beta1`.

-* Read about [custom resources](/docs/concepts/api-extension/custom-resources/).
-
-
+* Read about [custom resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/).

 <!-- steps -->

@@ -427,7 +424,9 @@ spec:

 The field `someRandomField` has been pruned.

-Note that the `kubectl create` call uses `--validate=false` to skip client-side validation. Because the [OpenAPI validation schemas are also published](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#publish-validation-schema-in-openapi-v2) to kubectl, it will also check for unknown fields and reject those objects long before they are sent to the API server.
+Note that the `kubectl create` call uses `--validate=false` to skip client-side validation.
+Because the [OpenAPI validation schemas are also published](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#publish-validation-schema-in-openapi-v2)
+to kubectl, it will also check for unknown fields and reject those objects long before they are sent to the API server.

 ### Controlling pruning

@@ -533,11 +532,14 @@ allOf:

 With one of those specification, both an integer and a string validate.

-In [Validation Schema Publishing](/docs/tasks/extend-kubernetes/custom-resources/extend-api-custom-resource-definitions/#publish-validation-schema-in-openapi-v2), `x-kubernetes-int-or-string: true` is unfolded to one of the two patterns shown above.
+In [Validation Schema Publishing](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#publish-validation-schema-in-openapi-v2),
+`x-kubernetes-int-or-string: true` is unfolded to one of the two patterns shown above.

 ### RawExtension

-RawExtensions (as in `runtime.RawExtension` defined in [k8s.io/apimachinery](https://github.com/kubernetes/apimachinery/blob/03ac7a9ade429d715a1a46ceaa3724c18ebae54f/pkg/runtime/types.go#L94)) holds complete Kubernetes objects, i.e. with `apiVersion` and `kind` fields.
+RawExtensions (as in `runtime.RawExtension` defined in
+[k8s.io/apimachinery](https://github.com/kubernetes/apimachinery/blob/03ac7a9ade429d715a1a46ceaa3724c18ebae54f/pkg/runtime/types.go#L94))
+holds complete Kubernetes objects, i.e. with `apiVersion` and `kind` fields.

 It is possible to specify those embedded objects (both completely without constraints or partially specified) by setting `x-kubernetes-embedded-resource: true`. For example:

@@ -569,8 +571,6 @@ See [Custom resource definition versioning](/docs/tasks/extend-kubernetes/custom
 for more information about serving multiple versions of your
 CustomResourceDefinition and migrating your objects from one version to another.

-
-
 <!-- discussion -->
 ## Advanced topics

@@ -9,17 +9,10 @@ weight: 20
 This page shows how to define environment variables for a container
 in a Kubernetes Pod.

-
-
-
 ## {{% heading "prerequisites" %}}

-
 {{< include "task-tutorial-prereqs.md" >}}

-
-
-
 <!-- steps -->

 ## Define an environment variable for a container
@@ -123,13 +116,10 @@ spec:

 Upon creation, the command `echo Warm greetings to The Most Honorable Kubernetes` is run on the container.

-
-
 ## {{% heading "whatsnext" %}}

-
 * Learn more about [environment variables](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/).
-* Learn about [using secrets as environment variables](/docs/user-guide/secrets/#using-secrets-as-environment-variables).
+* Learn about [using secrets as environment variables](/docs/concepts/configuration/secret/#using-secrets-as-environment-variables).
 * See [EnvVarSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvarsource-v1-core).


@@ -128,8 +128,8 @@ You can read more about removing jobs in [garbage collection](/docs/concepts/wor
 ## Writing a Cron Job Spec

 As with all other Kubernetes configs, a cron job needs `apiVersion`, `kind`, and `metadata` fields. For general
-information about working with config files, see [deploying applications](/docs/user-guide/deploying-applications),
-and [using kubectl to manage resources](/docs/user-guide/working-with-resources) documents.
+information about working with config files, see [deploying applications](/docs/tasks/run-application/run-stateless-application-deployment/),
+and [using kubectl to manage resources](/docs/concepts/overview/working-with-objects/object-management/) documents.

 A cron job config also needs a [`.spec` section](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status).

@@ -142,7 +142,8 @@ All modifications to a cron job, especially its `.spec`, are applied only to the
 The `.spec.schedule` is a required field of the `.spec`.
 It takes a [Cron](https://en.wikipedia.org/wiki/Cron) format string, such as `0 * * * *` or `@hourly`, as schedule time of its jobs to be created and executed.

-The format also includes extended `vixie cron` step values. As explained in the [FreeBSD manual](https://www.freebsd.org/cgi/man.cgi?crontab%285%29):
+The format also includes extended `vixie cron` step values. As explained in the
+[FreeBSD manual](https://www.freebsd.org/cgi/man.cgi?crontab%285%29):

 > Step values can be	used in	conjunction with ranges.  Following a range
 > with `/<number>` specifies skips	of the number's	value through the
@@ -17,25 +17,20 @@ from a task queue, completes it, deletes it from the queue, and exits.
 Here is an overview of the steps in this example:

 1. **Start a message queue service.**  In this example, we use RabbitMQ, but you could use another
-  one.  In practice you would set up a message queue service once and reuse it for many jobs.
+   one.  In practice you would set up a message queue service once and reuse it for many jobs.
 1. **Create a queue, and fill it with messages.**  Each message represents one task to be done.  In
-  this example, a message is just an integer that we will do a lengthy computation on.
+   this example, a message is just an integer that we will do a lengthy computation on.
 1. **Start a Job that works on tasks from the queue**.  The Job starts several pods.  Each pod takes
-  one task from the message queue, processes it, and repeats until the end of the queue is reached.
-
-
-
+   one task from the message queue, processes it, and repeats until the end of the queue is reached.

 ## {{% heading "prerequisites" %}}


 Be familiar with the basic,
-non-parallel, use of [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/).
+non-parallel, use of [Job](/docs/concepts/workloads/controllers/job/).

 {{< include "task-tutorial-prereqs.md" >}}

-
-
 <!-- steps -->

 ## Starting a message queue service
@@ -304,7 +299,7 @@ do not need to modify your "worker" program to be aware that there is a work que

 It does require that you run a message queue service.
 If running a queue service is inconvenient, you may
-want to consider one of the other [job patterns](/docs/concepts/jobs/run-to-completion-finite-workloads/#job-patterns).
+want to consider one of the other [job patterns](/docs/concepts/workloads/controllers/job/#job-patterns).

 This approach creates a pod for every work item.  If your work items only take a few seconds,
 though, creating a Pod for every work item may add a lot of overhead.  Consider another
@@ -16,31 +16,24 @@ from a task queue, processes it, and repeats until the end of the queue is reach
 Here is an overview of the steps in this example:

 1. **Start a storage service to hold the work queue.**  In this example, we use Redis to store
-  our work items.  In the previous example, we used RabbitMQ.  In this example, we use Redis and
-  a custom work-queue client library because AMQP does not provide a good way for clients to
-  detect when a finite-length work queue is empty.  In practice you would set up a store such
-  as Redis once and reuse it for the work queues of many jobs, and other things.
+   our work items.  In the previous example, we used RabbitMQ.  In this example, we use Redis and
+   a custom work-queue client library because AMQP does not provide a good way for clients to
+   detect when a finite-length work queue is empty.  In practice you would set up a store such
+   as Redis once and reuse it for the work queues of many jobs, and other things.
 1. **Create a queue, and fill it with messages.**  Each message represents one task to be done.  In
-  this example, a message is just an integer that we will do a lengthy computation on.
+   this example, a message is just an integer that we will do a lengthy computation on.
 1. **Start a Job that works on tasks from the queue**.  The Job starts several pods.  Each pod takes
-  one task from the message queue, processes it, and repeats until the end of the queue is reached.
-
-
-
+   one task from the message queue, processes it, and repeats until the end of the queue is reached.

 ## {{% heading "prerequisites" %}}


 {{< include "task-tutorial-prereqs.md" >}}

-
-
 <!-- steps -->

 Be familiar with the basic,
-non-parallel, use of [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/).
-
-
+non-parallel, use of [Job](/docs/concepts/workloads/controllers/job/).

 <!-- steps -->

@@ -227,14 +220,13 @@ Working on lemon

 As you can see, one of our pods worked on several work units.

-
-
 <!-- discussion -->

 ## Alternatives

 If running a queue service or modifying your containers to use a work queue is inconvenient, you may
-want to consider one of the other [job patterns](/docs/concepts/jobs/run-to-completion-finite-workloads/#job-patterns).
+want to consider one of the other
+[job patterns](/docs/concepts/workloads/controllers/job/#job-patterns).

 If you have a continuous stream of background processing work to run, then
 consider running your background workers with a `ReplicaSet` instead,
@@ -17,12 +17,10 @@ The sample Jobs process each item simply by printing a string then pausing.
 See [using Jobs in real workloads](#using-jobs-in-real-workloads) to learn about how
 this pattern fits more realistic use cases.

-
 ## {{% heading "prerequisites" %}}

-
 You should be familiar with the basic,
-non-parallel, use of [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/).
+non-parallel, use of [Job](/docs/concepts/workloads/controllers/job/).

 {{< include "task-tutorial-prereqs.md" >}}

@@ -33,12 +31,11 @@ To follow the advanced templating example, you need a working installation of
 library for Python.

 Once you have Python set up, you can install Jinja2 by running:
+
 ```shell
 pip install --user jinja2
 ```

-
-
 <!-- steps -->

 ## Create Jobs based on a template
@@ -305,7 +302,7 @@ If you plan to create a large number of Job objects, you may find that:
  on Jobs: the API server permanently rejects some of your requests
  when you create a great deal of work in one batch.

-There are other [job patterns](/docs/concepts/jobs/run-to-completion-finite-workloads/#job-patterns)
+There are other [job patterns](/docs/concepts/workloads/controllers/job/#job-patterns)
 that you can use to process large amounts of work without creating very many Job
 objects.

@@ -10,17 +10,10 @@ weight: 10

 This page shows how to perform a rolling update on a DaemonSet.

-
-
-
 ## {{% heading "prerequisites" %}}

-
 * The DaemonSet rolling update feature is only supported in Kubernetes version 1.6 or later.

-
-
-
 <!-- steps -->

 ## DaemonSet Update Strategy
@@ -164,7 +157,7 @@ make room for new DaemonSet pods.

 {{< note >}}
 This will cause service disruption when deleted pods are not controlled by any controllers or pods are not
-replicated. This does not respect [PodDisruptionBudget](/docs/tasks/configure-pod-container/configure-pod-disruption-budget/)
+replicated. This does not respect [PodDisruptionBudget](/docs/tasks/run-application/configure-pdb/)
 either.
 {{< /note >}}

@@ -14,53 +14,54 @@ This page shows how to manually rotate the certificate authority (CA) certificat


 - For more information about authentication in Kubernetes, see [Authenticating](/docs/reference/access-authn-authz/authentication).
- For more information about best practices for CA certificates, see [Single root CA](docs/setup/best-practices/certificates/#single-root-ca).
+- For more information about best practices for CA certificates, see [Single root CA](/docs/setup/best-practices/certificates/#single-root-ca).

 <!-- steps -->

 ## Rotate the CA certificates manually

 {{< caution >}}
-
 Make sure to back up your certificate directory along with configuration files and any other necessary files.

-This approach assumes operation of the Kubernetes control plane in a HA configuration with multiple API servers. Graceful termination of the API server is also assumed so clients can cleanly disconnect from one API server and reconnect to another.
+This approach assumes operation of the Kubernetes control plane in a HA configuration with multiple API servers.
+Graceful termination of the API server is also assumed so clients can cleanly disconnect from one API server and reconnect to another.

 Configurations with a single API server will experience unavailability while the API server is being restarted.
-
 {{< /caution >}}

-1. Distribute the new CA certificates and private keys (ex: `ca.crt`, `ca.key`, `front-proxy-ca.crt`, and `front-proxy-ca.key`) to all your control plane nodes in the Kubernetes certificates directory.
+1. Distribute the new CA certificates and private keys
+   (ex: `ca.crt`, `ca.key`, `front-proxy-ca.crt`, and `front-proxy-ca.key`)
+   to all your control plane nodes in the Kubernetes certificates directory.

 1. Update *Kubernetes controller manager's* `--root-ca-file` to include both old and new CA and restart controller manager.

-    Any service account created after this point will get secrets that include both old and new CAs.
+   Any service account created after this point will get secrets that include both old and new CAs.

-    {{< note >}}
-
-    Remove the flag `--client-ca-file` from the *Kubernetes controller manager* configuration. You can also replace the existing client CA file or change this configuration item to reference a new, updated CA. [Issue 1350](https://github.com/kubernetes/kubeadm/issues/1350) tracks an issue with *Kubernetes controller manager* being unable to accept a CA bundle.
-
-    {{< /note >}}
+   {{< note >}}
+   Remove the flag `--client-ca-file` from the *Kubernetes controller manager* configuration.
+   You can also replace the existing client CA file or change this configuration item to reference a new, updated CA.
+   [Issue 1350](https://github.com/kubernetes/kubeadm/issues/1350) tracks an issue with *Kubernetes controller manager* being unable to accept a CA bundle.
+   {{< /note >}}

 1. Update all service account tokens to include both old and new CA certificates.

-    If any pods are started before new CA is used by API servers, they will get this update and trust both old and new CAs.
+   If any pods are started before new CA is used by API servers, they will get this update and trust both old and new CAs.

-    ```shell
-    base64_encoded_ca="$(base64 <path to file containing both old and new CAs>)"
+   ```shell
+   base64_encoded_ca="$(base64 <path to file containing both old and new CAs>)"

-    for namespace in $(kubectl get ns --no-headers | awk '{print $1}'); do
-        for token in $(kubectl get secrets --namespace "$namespace" --field-selector type=kubernetes.io/service-account-token -o name); do
-            kubectl get $token --namespace "$namespace" -o yaml | \
-              /bin/sed "s/\(ca.crt:\).*/\1 ${base64_encoded_ca}" | \
-              kubectl apply -f -
-        done
-    done
-    ```
+   for namespace in $(kubectl get ns --no-headers | awk '{print $1}'); do
+       for token in $(kubectl get secrets --namespace "$namespace" --field-selector type=kubernetes.io/service-account-token -o name); do
+           kubectl get $token --namespace "$namespace" -o yaml | \
+             /bin/sed "s/\(ca.crt:\).*/\1 ${base64_encoded_ca}" | \
+             kubectl apply -f -
+       done
+   done
+   ```

 1. Restart all pods using in-cluster configs (ex: kube-proxy, coredns, etc) so they can use the updated certificate authority data from *ServiceAccount* secrets.

-    *   Make sure coredns, kube-proxy and other pods using in-cluster configs are working as expected.
+   * Make sure coredns, kube-proxy and other pods using in-cluster configs are working as expected.

 1. Append the both old and new CA to the file against `--client-ca-file` and `--kubelet-certificate-authority` flag in the `kube-apiserver` configuration.

@@ -68,77 +69,88 @@ Configurations with a single API server will experience unavailability while the

 1. Update certificates for user accounts by replacing the content of `client-certificate-data` and `client-key-data` respectively.

-    For information about creating certificates for individual user accounts, see [Configure certificates for user accounts](/docs/setup/best-practices/certificates/#configure-certificates-for-user-accounts).
+   For information about creating certificates for individual user accounts, see
+   [Configure certificates for user accounts](/docs/setup/best-practices/certificates/#configure-certificates-for-user-accounts).

-    Additionally, update the `certificate-authority-data` section in the kubeconfig files, respectively with Base64-encoded old and new certificate authority data
+   Additionally, update the `certificate-authority-data` section in the kubeconfig files,
+   respectively with Base64-encoded old and new certificate authority data

 1. Follow below steps in a rolling fashion.

-    1. Restart any other *[aggregated api servers](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)* or *webhook handlers* to trust the new CA certificates.
+   1. Restart any other *[aggregated api servers](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)*
+      or *webhook handlers* to trust the new CA certificates.

-    1. Restart the kubelet by update the file against `clientCAFile` in kubelet configuration and `certificate-authority-data` in kubelet.conf to use both the old and new CA on all nodes.
+   1. Restart the kubelet by update the file against `clientCAFile` in kubelet configuration and
+      `certificate-authority-data` in kubelet.conf to use both the old and new CA on all nodes.

-        If your kubelet is not using client certificate rotation update `client-certificate-data` and `client-key-data` in kubelet.conf on all nodes along with the kubelet client certificate file usually found in `/var/lib/kubelet/pki`.
+      If your kubelet is not using client certificate rotation update `client-certificate-data` and
+      `client-key-data` in kubelet.conf on all nodes along with the kubelet client certificate file
+      usually found in `/var/lib/kubelet/pki`.


-    1. Restart API servers with the certificates (`apiserver.crt`, `apiserver-kubelet-client.crt` and `front-proxy-client.crt`) signed by new CA. You can use the existing private keys or new private keys. If you changed the private keys then update these in the Kubernetes certificates directory as well.
+   1. Restart API servers with the certificates (`apiserver.crt`, `apiserver-kubelet-client.crt` and
+      `front-proxy-client.crt`) signed by new CA.
+      You can use the existing private keys or new private keys.
+      If you changed the private keys then update these in the Kubernetes certificates directory as well.

-        Since the pod trusts both old and new CAs, there will be a momentarily disconnection after which the pod's kube client will reconnect to the new API server that uses the certificate signed by the new CA.
+      Since the pod trusts both old and new CAs, there will be a momentarily disconnection
+      after which the pod's kube client will reconnect to the new API server
+      that uses the certificate signed by the new CA.

-        *    Restart Scheduler to use the new CAs.
+      * Restart Scheduler to use the new CAs.

-        *    Make sure control plane components logs no TLS errors.
+      * Make sure control plane components logs no TLS errors.

-        {{< note >}}
+      {{< note >}}
+      To generate certificates and private keys for your cluster using the `openssl` command line tool, see [Certificates (`openssl`)](/docs/concepts/cluster-administration/certificates/#openssl).
+      You can also use [`cfssl`](/docs/concepts/cluster-administration/certificates/#cfssl).
+      {{< /note >}}

-        To generate certificates and private keys for your cluster using the `openssl` command line tool, see [Certificates (`openssl`)](/docs/concepts/cluster-administration/certificates/#openssl).
-        You can also use [`cfssl`](/docs/concepts/cluster-administration/certificates/#cfssl).
+   1. Annotate any Daemonsets and Deployments to trigger pod replacement in a safer rolling fashion.

-        {{< /note >}}
+      Example:

-    1. Annotate any Daemonsets and Deployments to trigger pod replacement in a safer rolling fashion.
+      ```shell
+      for namespace in $(kubectl get namespace -o jsonpath='{.items[*].metadata.name}'); do
+          for name in $(kubectl get deployments -n $namespace -o jsonpath='{.items[*].metadata.name}'); do
+              kubectl patch deployment -n ${namespace} ${name} -p '{"spec":{"template":{"metadata":{"annotations":{"ca-rotation": "1"}}}}}';
+          done
+          for name in $(kubectl get daemonset -n $namespace -o jsonpath='{.items[*].metadata.name}'); do
+              kubectl patch daemonset -n ${namespace} ${name} -p '{"spec":{"template":{"metadata":{"annotations":{"ca-rotation": "1"}}}}}';
+          done
+      done
+      ```

-        Example:
-
-        ```shell
-        for namespace in $(kubectl get namespace -o jsonpath='{.items[*].metadata.name}'); do
-            for name in $(kubectl get deployments -n $namespace -o jsonpath='{.items[*].metadata.name}'); do
-                kubectl patch deployment -n ${namespace} ${name} -p '{"spec":{"template":{"metadata":{"annotations":{"ca-rotation": "1"}}}}}';
-            done
-            for name in $(kubectl get daemonset -n $namespace -o jsonpath='{.items[*].metadata.name}'); do
-                kubectl patch daemonset -n ${namespace} ${name} -p '{"spec":{"template":{"metadata":{"annotations":{"ca-rotation": "1"}}}}}';
-            done
-        done
-        ```
-
-        {{< note >}}
-
-        To limit the number of concurrent disruptions that your application experiences, see [configure pod disruption budget](docs/tasks/run-application/configure-pdb/).
-
-        {{< /note >}}
+      {{< note >}}
+      To limit the number of concurrent disruptions that your application experiences,
+      see [configure pod disruption budget](/docs/tasks/run-application/configure-pdb/).
+      {{< /note >}}

 1. If your cluster is using bootstrap tokens to join nodes, update the ConfigMap `cluster-info` in the `kube-public` namespace with new CA.

-    ```shell
-    base64_encoded_ca="$(base64 /etc/kubernetes/pki/ca.crt)"
+   ```shell
+   base64_encoded_ca="$(base64 /etc/kubernetes/pki/ca.crt)"

-    kubectl get cm/cluster-info --namespace kube-public -o yaml | \
-        /bin/sed "s/\(certificate-authority-data:\).*/\1 ${base64_encoded_ca}" | \
-        kubectl apply -f -
-    ```
+   kubectl get cm/cluster-info --namespace kube-public -o yaml | \
+       /bin/sed "s/\(certificate-authority-data:\).*/\1 ${base64_encoded_ca}" | \
+       kubectl apply -f -
+   ```

 1. Verify the cluster functionality.

-    1. Validate the logs from control plane components, along with the kubelet and the kube-proxy are not throwing any tls errors, see [looking at the logs](/docs/tasks/debug-application-cluster/debug-cluster/#looking-at-logs).
+   1. Validate the logs from control plane components, along with the kubelet and the
+      kube-proxy are not throwing any tls errors, see
+      [looking at the logs](/docs/tasks/debug-application-cluster/debug-cluster/#looking-at-logs).

-    1. Validate logs from any aggregated api servers and pods using in-cluster config.
+   1. Validate logs from any aggregated api servers and pods using in-cluster config.

 1. Once the cluster functionality is successfully verified:

-    1. Update all service account tokens to include new CA certificate only.
+   1. Update all service account tokens to include new CA certificate only.

-        *    All pods using an in-cluster kubeconfig will eventually need to be restarted to pick up the new SA secret for the old CA to be completely untrusted.
+      * All pods using an in-cluster kubeconfig will eventually need to be restarted to pick up the new SA secret for the old CA to be completely untrusted.

-    1. Restart the control plane components by removing the old CA from the kubeconfig files and the files against `--client-ca-file`, `--root-ca-file` flags resp.
+   1. Restart the control plane components by removing the old CA from the kubeconfig files and the files against `--client-ca-file`, `--root-ca-file` flags resp.
+
+   1. Restart kubelet by removing the old CA from file against the `clientCAFile` flag and kubelet kubeconfig file.

-    1. Restart kubelet by removing the old CA from file against the `clientCAFile` flag and kubelet kubeconfig file.
@@ -310,7 +310,12 @@ You can install kubectl as part of the Google Cloud SDK.

 ## Verifying kubectl configuration

-In order for kubectl to find and access a Kubernetes cluster, it needs a [kubeconfig file](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/), which is created automatically when you create a cluster using [kube-up.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/kube-up.sh) or successfully deploy a Minikube cluster. By default, kubectl configuration is located at `~/.kube/config`.
+In order for kubectl to find and access a Kubernetes cluster, it needs a
+[kubeconfig file](/docs/concepts/configuration/organize-cluster-access-kubeconfig/),
+which is created automatically when you create a cluster using
+[kube-up.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/kube-up.sh)
+or successfully deploy a Minikube cluster.
+By default, kubectl configuration is located at `~/.kube/config`.

 Check that kubectl is properly configured by getting the cluster state:

@@ -518,5 +523,7 @@ compinit
 * [Install Minikube](/docs/tasks/tools/install-minikube/)
 * See the [getting started guides](/docs/setup/) for more about creating clusters.
 * [Learn how to launch and expose your application.](/docs/tasks/access-application-cluster/service-access-application-cluster/)
-* If you need access to a cluster you didn't create, see the [Sharing Cluster Access document](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/).
+* If you need access to a cluster you didn't create, see the
+  [Sharing Cluster Access document](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/).
 * Read the [kubectl reference docs](/docs/reference/kubectl/kubectl/)
+
@@ -118,7 +118,7 @@ Pod runs a Container based on the provided Docker image.
    ```

 {{< note >}}
-    For more information about `kubectl`commands, see the [kubectl overview](/docs/user-guide/kubectl-overview/).
+For more information about `kubectl` commands, see the [kubectl overview](/docs/reference/kubectl/overview/).
 {{< /note >}}

 ## Create a Service
@@ -412,7 +412,7 @@ protocol between the loadbalancer and backend to communicate the true client IP
 such as the HTTP [Forwarded](https://tools.ietf.org/html/rfc7239#section-5.2)
 or [X-FORWARDED-FOR](https://en.wikipedia.org/wiki/X-Forwarded-For)
 headers, or the
-[proxy protocol](http://www.haproxy.org/download/1.5/doc/proxy-protocol.txt).
+[proxy protocol](https://www.haproxy.org/download/1.5/doc/proxy-protocol.txt).
 Load balancers in the second category can leverage the feature described above
 by creating an HTTP health check pointing at the port stored in
 the `service.spec.healthCheckNodePort` field on the Service.
@@ -7,9 +7,13 @@ weight: 30
 ---

 <!-- overview -->
-This tutorial shows you how to run [Apache Cassandra](http://cassandra.apache.org/) on Kubernetes. Cassandra, a database, needs persistent storage to provide data durability (application _state_). In this example, a custom Cassandra seed provider lets the database discover new Cassandra instances as they join the Cassandra cluster.
+This tutorial shows you how to run [Apache Cassandra](https://cassandra.apache.org/) on Kubernetes.
+Cassandra, a database, needs persistent storage to provide data durability (application _state_).
+In this example, a custom Cassandra seed provider lets the database discover new Cassandra instances as they join the Cassandra cluster.

-*StatefulSets* make it easier to deploy stateful applications into your Kubernetes cluster. For more information on the features used in this tutorial, see [StatefulSet](/docs/concepts/workloads/controllers/statefulset/).
+*StatefulSets* make it easier to deploy stateful applications into your Kubernetes cluster.
+For more information on the features used in this tutorial, see
+[StatefulSet](/docs/concepts/workloads/controllers/statefulset/).

 {{< note >}}
 Cassandra and Kubernetes both use the term _node_ to mean a member of a cluster. In this
@@ -38,12 +42,17 @@ new Cassandra Pods as they appear inside your Kubernetes cluster.

 {{< include "task-tutorial-prereqs.md" >}}

-To complete this tutorial, you should already have a basic familiarity with {{< glossary_tooltip text="Pods" term_id="pod" >}}, {{< glossary_tooltip text="Services" term_id="service" >}}, and {{< glossary_tooltip text="StatefulSets" term_id="StatefulSet" >}}.
+To complete this tutorial, you should already have a basic familiarity with
+{{< glossary_tooltip text="Pods" term_id="pod" >}},
+{{< glossary_tooltip text="Services" term_id="service" >}}, and
+{{< glossary_tooltip text="StatefulSets" term_id="StatefulSet" >}}.

 ### Additional Minikube setup instructions

 {{< caution >}}
-[Minikube](/docs/getting-started-guides/minikube/) defaults to 1024MiB of memory and 1 CPU. Running Minikube with the default resource configuration results in insufficient resource errors during this tutorial. To avoid these errors, start Minikube with the following settings:
+[Minikube](/docs/setup/learning-environment/minikube/) defaults to 1024MiB of memory and 1 CPU.
+Running Minikube with the default resource configuration results in insufficient resource
+errors during this tutorial. To avoid these errors, start Minikube with the following settings:

 ```shell
 minikube start --memory 5120 --cpus=4
@@ -51,11 +60,11 @@ minikube start --memory 5120 --cpus=4
 {{< /caution >}}


-
 <!-- lessoncontent -->
 ## Creating a headless Service for Cassandra {#creating-a-cassandra-headless-service}

-In Kubernetes, a {{< glossary_tooltip text="Service" term_id="service" >}} describes a set of {{< glossary_tooltip text="Pods" term_id="pod" >}} that perform the same task.
+In Kubernetes, a {{< glossary_tooltip text="Service" term_id="service" >}} describes a set of
+{{< glossary_tooltip text="Pods" term_id="pod" >}} that perform the same task.

 The following Service is used for DNS lookups between Cassandra Pods and clients within your cluster:

@@ -83,14 +92,17 @@ NAME        TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)    AGE
 cassandra   ClusterIP   None         <none>        9042/TCP   45s
 ```

-If you don't see a Service named `cassandra`, that means creation failed. Read [Debug Services](/docs/tasks/debug-application-cluster/debug-service/) for help troubleshooting common issues.
+If you don't see a Service named `cassandra`, that means creation failed. Read
+[Debug Services](/docs/tasks/debug-application-cluster/debug-service/)
+for help troubleshooting common issues.

 ## Using a StatefulSet to create a Cassandra ring

 The StatefulSet manifest, included below, creates a Cassandra ring that consists of three Pods.

 {{< note >}}
-This example uses the default provisioner for Minikube. Please update the following StatefulSet for the cloud you are working with.
+This example uses the default provisioner for Minikube.
+Please update the following StatefulSet for the cloud you are working with.
 {{< /note >}}

 {{< codenew file="application/cassandra/cassandra-statefulset.yaml" >}}
@@ -182,7 +194,8 @@ Use `kubectl edit` to modify the size of a Cassandra StatefulSet.
    kubectl edit statefulset cassandra
    ```

-    This command opens an editor in your terminal. The line you need to change is the `replicas` field. The following sample is an excerpt of the StatefulSet file:
+    This command opens an editor in your terminal. The line you need to change is the `replicas` field.
+    The following sample is an excerpt of the StatefulSet file:

    ```yaml
    # Please edit the object below. Lines beginning with a '#' will be ignored,
@@ -225,10 +238,12 @@ Use `kubectl edit` to modify the size of a Cassandra StatefulSet.

 ## {{% heading "cleanup" %}}

-Deleting or scaling a StatefulSet down does not delete the volumes associated with the StatefulSet. This setting is for your safety because your data is more valuable than automatically purging all related StatefulSet resources.
+Deleting or scaling a StatefulSet down does not delete the volumes associated with the StatefulSet.
+This setting is for your safety because your data is more valuable than automatically purging all related StatefulSet resources.

 {{< warning >}}
-Depending on the storage class and reclaim policy, deleting the *PersistentVolumeClaims* may cause the associated volumes to also be deleted. Never assume you’ll be able to access data if its volume claims are deleted.
+Depending on the storage class and reclaim policy, deleting the *PersistentVolumeClaims* may cause the associated volumes
+to also be deleted. Never assume you’ll be able to access data if its volume claims are deleted.
 {{< /warning >}}

 1. Run the following commands (chained together into a single command) to delete everything in the Cassandra StatefulSet:
@@ -15,25 +15,23 @@ weight: 40
 <!-- overview -->
 This tutorial demonstrates running [Apache Zookeeper](https://zookeeper.apache.org) on
 Kubernetes using [StatefulSets](/docs/concepts/workloads/controllers/statefulset/),
-[PodDisruptionBudgets](/docs/concepts/workloads/pods/disruptions/#specifying-a-poddisruptionbudget),
-and [PodAntiAffinity](/docs/user-guide/node-selection/#inter-pod-affinity-and-anti-affinity-beta-feature).
-
+[PodDisruptionBudgets](/docs/concepts/workloads/pods/disruptions/#pod-disruption-budget),
+and [PodAntiAffinity](/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity).

 ## {{% heading "prerequisites" %}}

-
 Before starting this tutorial, you should be familiar with the following
 Kubernetes concepts.

-   [Pods](/docs/user-guide/pods/single-container/)
+-   [Pods](/docs/concepts/workloads/pods/)
 -   [Cluster DNS](/docs/concepts/services-networking/dns-pod-service/)
 -   [Headless Services](/docs/concepts/services-networking/service/#headless-services)
 -   [PersistentVolumes](/docs/concepts/storage/volumes/)
 -   [PersistentVolume Provisioning](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/)
 -   [StatefulSets](/docs/concepts/workloads/controllers/statefulset/)
-   [PodDisruptionBudgets](/docs/concepts/workloads/pods/disruptions/#specifying-a-poddisruptionbudget)
-   [PodAntiAffinity](/docs/user-guide/node-selection/#inter-pod-affinity-and-anti-affinity-beta-feature)
-   [kubectl CLI](/docs/user-guide/kubectl/)
+-   [PodDisruptionBudgets](/docs/concepts/workloads/pods/disruptions/#pod-disruption-budget)
+-   [PodAntiAffinity](/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)
+-   [kubectl CLI](/docs/reference/kubectl/kubectl/)

 You will require a cluster with at least four nodes, and each node requires at least 2 CPUs and 4 GiB of memory. In this tutorial you will cordon and drain the cluster's nodes. **This means that the cluster will terminate and evict all Pods on its nodes, and the nodes will temporarily become unschedulable.** You should use a dedicated cluster for this tutorial, or you should ensure that the disruption you cause will not interfere with other tenants.

@@ -75,7 +73,7 @@ ZooKeeper servers keep their entire state machine in memory, and write every mut
 The manifest below contains a
 [Headless Service](/docs/concepts/services-networking/service/#headless-services),
 a [Service](/docs/concepts/services-networking/service/),
-a [PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions//#specifying-a-poddisruptionbudget),
+a [PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions/#pod-disruption-budgets),
 and a [StatefulSet](/docs/concepts/workloads/controllers/statefulset/).

 {{< codenew file="application/zookeeper/zookeeper.yaml" >}}
@@ -127,7 +125,7 @@ zk-2      1/1       Running   0         40s
 ```

 The StatefulSet controller creates three Pods, and each Pod has a container with
-a [ZooKeeper](http://www-us.apache.org/dist/zookeeper/stable/) server.
+a [ZooKeeper](https://www-us.apache.org/dist/zookeeper/stable/) server.

 ### Facilitating Leader Election

@@ -502,7 +500,7 @@ The command used to start the ZooKeeper servers passed the configuration as comm
 ### Configuring Logging

 One of the files generated by the `zkGenConfig.sh` script controls ZooKeeper's logging.
-ZooKeeper uses [Log4j](http://logging.apache.org/log4j/2.x/), and, by default,
+ZooKeeper uses [Log4j](https://logging.apache.org/log4j/2.x/), and, by default,
 it uses a time and size based rolling file appender for its logging configuration.

 Use the command below to get the logging configuration from one of Pods in the `zk` `StatefulSet`.
@@ -524,7 +522,10 @@ log4j.appender.CONSOLE.layout=org.apache.log4j.PatternLayout
 log4j.appender.CONSOLE.layout.ConversionPattern=%d{ISO8601} [myid:%X{myid}] - %-5p [%t:%C{1}@%L] - %m%n
 ```

-This is the simplest possible way to safely log inside the container. Because the applications write logs to standard out, Kubernetes will handle log rotation for you. Kubernetes also implements a sane retention policy that ensures application logs written to standard out and standard error do not exhaust local storage media.
+This is the simplest possible way to safely log inside the container. 
+Because the applications write logs to standard out, Kubernetes will handle log rotation for you.
+Kubernetes also implements a sane retention policy that ensures application logs written to
+standard out and standard error do not exhaust local storage media.

 Use [`kubectl logs`](/docs/reference/generated/kubectl/kubectl-commands/#logs) to retrieve the last 20 log lines from one of the Pods.

@@ -679,7 +680,7 @@ statefulset.apps/zk rolled back

 ### Handling Process Failure

-[Restart Policies](/docs/user-guide/pod-states/#restartpolicy) control how
+[Restart Policies](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) control how
 Kubernetes handles process failures for the entry point of the container in a Pod.
 For Pods in a `StatefulSet`, the only appropriate `RestartPolicy` is Always, and this
 is the default value. For stateful applications you should **never** override
@@ -832,7 +833,9 @@ domains to ensure availability. To avoid an outage, due to the loss of an
 individual machine, best practices preclude co-locating multiple instances of the
 application on the same machine.

-By default, Kubernetes may co-locate Pods in a `StatefulSet` on the same node. For the three server ensemble you created, if two servers are on the same node, and that node fails, the clients of your ZooKeeper service will experience an outage until at least one of the Pods can be rescheduled.
+By default, Kubernetes may co-locate Pods in a `StatefulSet` on the same node.
+For the three server ensemble you created, if two servers are on the same node, and that node fails,
+the clients of your ZooKeeper service will experience an outage until at least one of the Pods can be rescheduled.

 You should always provision additional capacity to allow the processes of critical
 systems to be rescheduled in the event of node failures. If you do so, then the
@@ -978,7 +981,8 @@ pod "zk-1" deleted
 node "kubernetes-node-ixsl" drained
 ```

-The `zk-1` Pod cannot be scheduled because the `zk` `StatefulSet` contains a `PodAntiAffinity` rule preventing co-location of the Pods, and as only two nodes are schedulable, the Pod will remain in a Pending state.
+The `zk-1` Pod cannot be scheduled because the `zk` `StatefulSet` contains a `PodAntiAffinity` rule preventing
+co-location of the Pods, and as only two nodes are schedulable, the Pod will remain in a Pending state.

 ```shell
 kubectl get pods -w -l app=zk
@@ -1119,9 +1123,10 @@ kubectl uncordon kubernetes-node-ixsl
 node "kubernetes-node-ixsl" uncordoned
 ```

-You can use `kubectl drain` in conjunction with `PodDisruptionBudgets` to ensure that your services remain available during maintenance. If drain is used to cordon nodes and evict pods prior to taking the node offline for maintenance, services that express a disruption budget will have that budget respected. You should always allocate additional capacity for critical services so that their Pods can be immediately rescheduled.
-
-
+You can use `kubectl drain` in conjunction with `PodDisruptionBudgets` to ensure that your services remain available during maintenance.
+If drain is used to cordon nodes and evict pods prior to taking the node offline for maintenance,
+services that express a disruption budget will have that budget respected.
+You should always allocate additional capacity for critical services so that their Pods can be immediately rescheduled.

 ## {{% heading "cleanup" %}}

@@ -365,7 +365,7 @@ Deleting the Deployments and Services also deletes any running Pods. Use labels

 ## {{% heading "whatsnext" %}}

-* Add [ELK logging and monitoring](../guestbook-logs-metrics-with-elk/) to your Guestbook application
+* Add [ELK logging and monitoring](/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk/) to your Guestbook application
 * Complete the [Kubernetes Basics](/docs/tutorials/kubernetes-basics/) Interactive Tutorials
 * Use Kubernetes to create a blog using [Persistent Volumes for MySQL and Wordpress](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/#visit-your-new-wordpress-blog)
 * Read more about [connecting applications](/docs/concepts/services-networking/connect-applications-service/)