Merge branch 'master' of github.com:kubernetes/website

2021-03-19 09:10:29 +00:00
parent 06f1e784b8 d79edc1438
commit a94ff065fc
369 changed files with 9514 additions and 8068 deletions
@@ -10,6 +10,7 @@ aliases:
    - kbarnard10
    - mrbobbytables
    - onlydole
+    - sftim
  sig-docs-de-owners: # Admins for German content
    - bene2k1
    - mkorbi
@@ -175,14 +176,20 @@ aliases:
    # zhangxiaoyu-zidif
  sig-docs-pt-owners: # Admins for Portuguese content
    - femrtnz
+    - jailton
    - jcjesus
    - devlware
    - jhonmike
+    - rikatz
+    - yagonobre
  sig-docs-pt-reviews: # PR reviews for Portugese content
    - femrtnz
+    - jailton
    - jcjesus
    - devlware
    - jhonmike
+    - rikatz
+    - yagonobre
  sig-docs-vi-owners: # Admins for Vietnamese content
    - huynguyennovem
    - ngtuna
@@ -91,7 +91,7 @@ blog = "/:section/:year/:month/:day/:slug/"
 [outputs]
 home = [ "HTML", "RSS", "HEADERS" ]
 page = [ "HTML"]
-section = [ "HTML"]
+section = [ "HTML", "print" ]

 # Add a "text/netlify" media type for auto-generating the _headers file
 [mediaTypes]
@@ -176,7 +176,7 @@ Cluster-distributed stateful services (e.g., Cassandra) can benefit from splitti

 [Logs](/docs/concepts/cluster-administration/logging/) and [metrics](/docs/tasks/debug-application-cluster/resource-usage-monitoring/) (if collected and persistently retained) are valuable to diagnose outages, but given the variety of technologies available it will not be addressed in this blog. If Internet connectivity is available, it may be desirable to retain logs and metrics externally at a central location.

-Your production deployment should utilize an automated installation, configuration and update tool (e.g., [Ansible](https://github.com/kubernetes-incubator/kubespray), [BOSH](https://github.com/cloudfoundry-incubator/kubo-deployment), [Chef](https://github.com/chef-cookbooks/kubernetes), [Juju](/docs/getting-started-guides/ubuntu/installation/), [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/), [Puppet](https://forge.puppet.com/puppetlabs/kubernetes), etc.). A manual process will have repeatability issues, be labor intensive, error prone, and difficult to scale. [Certified distributions](https://www.cncf.io/certification/software-conformance/#logos) are likely to include a facility for retaining configuration settings across updates, but if you implement your own install and config toolchain, then retention, backup and recovery of the configuration artifacts is essential. Consider keeping your deployment components and settings under a version control system such as Git.
+Your production deployment should utilize an automated installation, configuration and update tool (e.g., [Ansible](https://github.com/kubernetes-incubator/kubespray), [BOSH](https://github.com/cloudfoundry-incubator/kubo-deployment), [Chef](https://github.com/chef-cookbooks/kubernetes), [Juju](/docs/getting-started-guides/ubuntu/installation/), [kubeadm](/docs/reference/setup-tools/kubeadm/), [Puppet](https://forge.puppet.com/puppetlabs/kubernetes), etc.). A manual process will have repeatability issues, be labor intensive, error prone, and difficult to scale. [Certified distributions](https://www.cncf.io/certification/software-conformance/#logos) are likely to include a facility for retaining configuration settings across updates, but if you implement your own install and config toolchain, then retention, backup and recovery of the configuration artifacts is essential. Consider keeping your deployment components and settings under a version control system such as Git.

 ## Outage recovery

@@ -17,7 +17,7 @@ Let’s dive into the key features of this release:

 ## Simplified Kubernetes Cluster Management with kubeadm in GA

-Most people who have gotten hands-on with Kubernetes have at some point been hands-on with kubeadm. It's an essential tool for managing the cluster lifecycle, from creation to configuration to upgrade; and now kubeadm is officially GA. [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) handles the bootstrapping of production clusters on existing hardware and configuring the core Kubernetes components in a best-practice-manner to providing a secure yet easy joining flow for new nodes and supporting easy upgrades. What’s notable about this GA release are the now graduated advanced features, specifically around pluggability and configurability. The scope of kubeadm is to be a toolbox for both admins and automated, higher-level system and this release is a significant step in that direction.
+Most people who have gotten hands-on with Kubernetes have at some point been hands-on with kubeadm. It's an essential tool for managing the cluster lifecycle, from creation to configuration to upgrade; and now kubeadm is officially GA. [kubeadm](/docs/reference/setup-tools/kubeadm/) handles the bootstrapping of production clusters on existing hardware and configuring the core Kubernetes components in a best-practice-manner to providing a secure yet easy joining flow for new nodes and supporting easy upgrades. What’s notable about this GA release are the now graduated advanced features, specifically around pluggability and configurability. The scope of kubeadm is to be a toolbox for both admins and automated, higher-level system and this release is a significant step in that direction.

 ## Container Storage Interface (CSI) Goes GA

@@ -114,7 +114,7 @@ will have strictly better performance and less overhead. However, we encourage y
 to explore all the options from the [CNCF landscape] in case another would be an
 even better fit for your environment.

-[CNCF landscape]: https://landscape.cncf.io/category=container-runtime&format=card-mode&grouping=category
+[CNCF landscape]: https://landscape.cncf.io/card-mode?category=container-runtime&grouping=category


 ### What should I look out for when changing CRI implementations?
@@ -0,0 +1,63 @@
+---
+layout: blog
+title: "The Evolution of Kubernetes Dashboard"
+date: 2021-03-09
+slug: the-evolution-of-kubernetes-dashboard
+---
+
+Authors: Marcin Maciaszczyk, Kubermatic & Sebastian Florek, Kubermatic
+
+In October 2020, the Kubernetes Dashboard officially turned five. As main project maintainers, we can barely believe that so much time has passed since our very first commits to the project. However, looking back with a bit of nostalgia, we realize that quite a lot has happened since then. Now it’s due time to celebrate “our baby” with a short recap.
+
+## How It All Began
+
+The initial idea behind the Kubernetes Dashboard project was to provide a web interface for Kubernetes. We wanted to reflect the kubectl functionality through an intuitive web UI. The main benefit from using the UI is to be able to quickly see things that do not work as expected (monitoring and troubleshooting). Also, the Kubernetes Dashboard is a great starting point for users that are new to the Kubernetes ecosystem.
+
+The very [first commit](https://github.com/kubernetes/dashboard/commit/5861187fa807ac1cc2d9b2ac786afeced065076c) to the Kubernetes Dashboard was made by Filip Grządkowski from Google on 16th October 2015 – just a few months from the initial commit to the Kubernetes repository. Our initial commits go back to November 2015 ([Sebastian committed on 16 November 2015](https://github.com/kubernetes/dashboard/commit/09e65b6bb08c49b926253de3621a73da05e400fd); [Marcin committed on 23 November 2015](https://github.com/kubernetes/dashboard/commit/1da4b1c25ef040818072c734f71333f9b4733f55)). Since that time, we’ve become regular contributors to the project. For the next two years, we worked closely with the Googlers, eventually becoming main project maintainers ourselves.
+
+{{< figure src="first-ui.png" caption="The First Version of the User Interface" >}}
+
+{{< figure src="along-the-way-ui.png" caption="Prototype of the New User Interface" >}}
+
+{{< figure src="current-ui.png" caption="The Current User Interface" >}}
+
+As you can see, the initial look and feel of the project were completely different from the current one. We have changed the design multiple times. The same has happened with the code itself.
+
+## Growing Up - The Big Migration
+
+At [the beginning of 2018](https://github.com/kubernetes/dashboard/pull/2727), we reached a point where AngularJS was getting closer to the end of its life, while the new Angular versions were published quite often. A lot of the libraries and the modules that we were using were following the trend. That forced us to spend a lot of the time rewriting the frontend part of the project to make it work with newer technologies.
+
+The migration came with many benefits like being able to refactor a lot of the code, introduce design patterns, reduce code complexity, and benefit from the new modules. However, you can imagine that the scale of the migration was huge. Luckily, there were a number of contributions from the community helping us with the resource support, new Kubernetes version support, i18n, and much more. After many long days and nights, we finally released the [first beta version](https://github.com/kubernetes/dashboard/releases/tag/v2.0.0-beta1) in July 2019, followed by the [2.0 release](https://github.com/kubernetes/dashboard/releases/tag/v2.0.0) in April 2020 — our baby had grown up.
+
+## Where Are We Standing in 2021?
+
+Due to limited resources, unfortunately, we were not able to offer extensive support for many different Kubernetes versions. So, we’ve decided to always try and support the latest Kubernetes version available at the time of the Kubernetes Dashboard release. The latest release, [Dashboard v2.2.0](https://github.com/kubernetes/dashboard/releases/tag/v2.2.0) provides support for Kubernetes v1.20.
+
+On top of that, we put in a great deal of effort into [improving resource support](https://github.com/kubernetes/dashboard/issues/5232). Meanwhile, we do offer support for most of the Kubernetes resources. Also, the Kubernetes Dashboard supports multiple languages: English, German, French, Japanese, Korean, Chinese (Traditional, Simplified, Traditional Hong Kong). Persian and Russian localizations are currently in progress. Moreover, we are working on the support for 3rd party themes and the design of the app in general. As you can see, quite a lot of things are going on.
+
+Luckily, we do have regular contributors with domain knowledge who are taking care of the project, updating the Helm charts, translations, Go modules, and more. But as always, there could be many more hands on deck. So if you are thinking about contributing to Kubernetes, keep us in mind ;)
+
+## What’s Next
+
+The Kubernetes Dashboard has been growing and prospering for more than 5 years now. It provides the community with an intuitive Web UI, thereby decreasing the complexity of Kubernetes and increasing its accessibility to new community members. We are proud of what the project has achieved so far, but this is by far not the end. These are our priorities for the future:
+
+*   Keep providing support for the new Kubernetes versions
+*   Keep improving the support for the existing resources
+*   Keep working on auth system improvements
+*   [Rewrite the API to use gRPC and shared informers](https://github.com/kubernetes/dashboard/pull/5449): This will allow us to improve the performance of the application but, most importantly, to support live updates coming from the Kubernetes project. It is one of the most requested features from the community.
+*   Split the application into two containers, one with the UI and the second with the API running inside.
+
+## The Kubernetes Dashboard in Numbers
+
+* Initial commit made on October 16, 2015
+* Over 100 million pulls from Dockerhub since the v2 release
+* 8 supported languages and the next 2 in progress
+* Over 3360 closed PRs
+* Over 2260 closed issues
+* 100% coverage of the supported core Kubernetes resources
+* Over 9000 stars on GitHub
+* Over 237 000 lines of code
+
+## Join Us
+
+As mentioned earlier, we are currently looking for more people to help us further develop and grow the project. We are open to contributions in multiple areas, i.e., [issues with help wanted label](https://github.com/kubernetes/dashboard/issues?q=is%3Aissue+is%3Aopen+label%3A%22help+wanted%22). Please feel free to reach out via GitHub or the #sig-ui channel in the [Kubernetes Slack](https://slack.k8s.io/).
@@ -24,7 +24,7 @@ One or more forms of [authorization](/docs/reference/access-authn-authz/authoriz
 Nodes should be provisioned with the public root certificate for the cluster such that they can connect securely to the apiserver along with valid client credentials. A good approach is that the client credentials provided to the kubelet are in the form of a client certificate. See [kubelet TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) for automated provisioning of kubelet client certificates.

 Pods that wish to connect to the apiserver can do so securely by leveraging a service account so that Kubernetes will automatically inject the public root certificate and a valid bearer token into the pod when it is instantiated.
-The `kubernetes` service (in all namespaces) is configured with a virtual IP address that is redirected (via kube-proxy) to the HTTPS endpoint on the apiserver.
+The `kubernetes` service (in `default` namespace) is configured with a virtual IP address that is redirected (via kube-proxy) to the HTTPS endpoint on the apiserver.

 The control plane components also communicate with the cluster apiserver over the secure port.

@@ -31,7 +31,7 @@ The [components](/docs/concepts/overview/components/#node-components) on a node
 There are two main ways to have Nodes added to the {{< glossary_tooltip text="API server" term_id="kube-apiserver" >}}:

 1. The kubelet on a node self-registers to the control plane
-2. You, or another human user, manually add a Node object
+2. You (or another human user) manually add a Node object

 After you create a Node object, or the kubelet on a node self-registers, the
 control plane checks whether the new Node object is valid. For example, if you
@@ -52,8 +52,8 @@ try to create a Node from the following JSON manifest:

 Kubernetes creates a Node object internally (the representation). Kubernetes checks
 that a kubelet has registered to the API server that matches the `metadata.name`
-field of the Node. If the node is healthy (if all necessary services are running),
-it is eligible to run a Pod. Otherwise, that node is ignored for any cluster activity
+field of the Node. If the node is healthy (i.e. all necessary services are running),
+then it is eligible to run a Pod. Otherwise, that node is ignored for any cluster activity
 until it becomes healthy.

 {{< note >}}
@@ -96,14 +96,14 @@ You can create and modify Node objects using
 When you want to create Node objects manually, set the kubelet flag `--register-node=false`.

 You can modify Node objects regardless of the setting of `--register-node`.
-For example, you can set labels on an existing Node, or mark it unschedulable.
+For example, you can set labels on an existing Node or mark it unschedulable.

 You can use labels on Nodes in conjunction with node selectors on Pods to control
 scheduling. For example, you can constrain a Pod to only be eligible to run on
 a subset of the available nodes.

 Marking a node as unschedulable prevents the scheduler from placing new pods onto
-that Node, but does not affect existing Pods on the Node. This is useful as a
+that Node but does not affect existing Pods on the Node. This is useful as a
 preparatory step before a node reboot or other maintenance.

 To mark a Node unschedulable, run:
@@ -179,14 +179,14 @@ The node condition is represented as a JSON object. For example, the following s
 ]
 ```

-If the Status of the Ready condition remains `Unknown` or `False` for longer than the `pod-eviction-timeout` (an argument passed to the {{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}}), all the Pods on the node are scheduled for deletion by the node controller. The default eviction timeout duration is **five minutes**. In some cases when the node is unreachable, the API server is unable to communicate with the kubelet on the node. The decision to delete the pods cannot be communicated to the kubelet until communication with the API server is re-established. In the meantime, the pods that are scheduled for deletion may continue to run on the partitioned node.
+If the Status of the Ready condition remains `Unknown` or `False` for longer than the `pod-eviction-timeout` (an argument passed to the {{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}}), then all the Pods on the node are scheduled for deletion by the node controller. The default eviction timeout duration is **five minutes**. In some cases when the node is unreachable, the API server is unable to communicate with the kubelet on the node. The decision to delete the pods cannot be communicated to the kubelet until communication with the API server is re-established. In the meantime, the pods that are scheduled for deletion may continue to run on the partitioned node.

 The node controller does not force delete pods until it is confirmed that they have stopped
 running in the cluster. You can see the pods that might be running on an unreachable node as
 being in the `Terminating` or `Unknown` state. In cases where Kubernetes cannot deduce from the
 underlying infrastructure if a node has permanently left a cluster, the cluster administrator
-may need to delete the node object by hand.  Deleting the node object from Kubernetes causes
-all the Pod objects running on the node to be deleted from the API server, and frees up their
+may need to delete the node object by hand. Deleting the node object from Kubernetes causes
+all the Pod objects running on the node to be deleted from the API server and frees up their
 names.

 The node lifecycle controller automatically creates
@@ -199,7 +199,7 @@ for more details.

 ### Capacity and Allocatable {#capacity}

-Describes the resources available on the node: CPU, memory and the maximum
+Describes the resources available on the node: CPU, memory, and the maximum
 number of pods that can be scheduled onto the node.

 The fields in the capacity block indicate the total amount of resources that a
@@ -225,18 +225,19 @@ CIDR block to the node when it is registered (if CIDR assignment is turned on).

 The second is keeping the node controller's internal list of nodes up to date with
 the cloud provider's list of available machines. When running in a cloud
-environment, whenever a node is unhealthy, the node controller asks the cloud
+environment and whenever a node is unhealthy, the node controller asks the cloud
 provider if the VM for that node is still available. If not, the node
 controller deletes the node from its list of nodes.

 The third is monitoring the nodes' health. The node controller is
-responsible for updating the NodeReady condition of NodeStatus to
-ConditionUnknown when a node becomes unreachable (i.e. the node controller stops
-receiving heartbeats for some reason, for example due to the node being down), and then later evicting
-all the pods from the node (using graceful termination) if the node continues
-to be unreachable. (The default timeouts are 40s to start reporting
-ConditionUnknown and 5m after that to start evicting pods.) The node controller
-checks the state of each node every `--node-monitor-period` seconds.
+responsible for:
+- Updating the NodeReady condition of NodeStatus to ConditionUnknown when a node
+  becomes unreachable, as the node controller stops receiving heartbeats for some
+  reason such as the node being down.
+- Evicting all the pods from the node using graceful termination if
+  the node continues to be unreachable. The default timeouts are 40s to start
+  reporting ConditionUnknown and 5m after that to start evicting pods.
+The node controller checks the state of each node every `--node-monitor-period` seconds.

 #### Heartbeats

@@ -252,13 +253,14 @@ of the node heartbeats as the cluster scales.
 The kubelet is responsible for creating and updating the `NodeStatus` and
 a Lease object.

- The kubelet updates the `NodeStatus` either when there is change in status,
+- The kubelet updates the `NodeStatus` either when there is change in status
  or if there has been no update for a configured interval. The default interval
-  for `NodeStatus` updates is 5 minutes (much longer than the 40 second default
-  timeout for unreachable nodes).
+  for `NodeStatus` updates is 5 minutes, which is much longer than the 40 second default
+  timeout for unreachable nodes.
 - The kubelet creates and then updates its Lease object every 10 seconds
  (the default update interval). Lease updates occur independently from the
-  `NodeStatus` updates. If the Lease update fails, the kubelet retries with exponential backoff starting at 200 milliseconds and capped at 7 seconds.
+  `NodeStatus` updates. If the Lease update fails, the kubelet retries with
+  exponential backoff starting at 200 milliseconds and capped at 7 seconds.

 #### Reliability

@@ -269,23 +271,24 @@ from more than 1 node per 10 seconds.
 The node eviction behavior changes when a node in a given availability zone
 becomes unhealthy. The node controller checks what percentage of nodes in the zone
 are unhealthy (NodeReady condition is ConditionUnknown or ConditionFalse) at
-the same time. If the fraction of unhealthy nodes is at least
-`--unhealthy-zone-threshold` (default 0.55) then the eviction rate is reduced:
-if the cluster is small (i.e. has less than or equal to
-`--large-cluster-size-threshold` nodes - default 50) then evictions are
-stopped, otherwise the eviction rate is reduced to
-`--secondary-node-eviction-rate` (default 0.01) per second. The reason these
-policies are implemented per availability zone is because one availability zone
-might become partitioned from the master while the others remain connected. If
-your cluster does not span multiple cloud provider availability zones, then
-there is only one availability zone (the whole cluster).
+the same time:
+- If the fraction of unhealthy nodes is at least `--unhealthy-zone-threshold` 
+  (default 0.55), then the eviction rate is reduced.
+- If the cluster is small (i.e. has less than or equal to
+  `--large-cluster-size-threshold` nodes - default 50), then evictions are stopped.
+- Otherwise, the eviction rate is reduced to `--secondary-node-eviction-rate`
+  (default 0.01) per second.
+The reason these policies are implemented per availability zone is because one
+availability zone might become partitioned from the master while the others remain
+connected. If your cluster does not span multiple cloud provider availability zones,
+then there is only one availability zone (i.e. the whole cluster).

 A key reason for spreading your nodes across availability zones is so that the
 workload can be shifted to healthy zones when one entire zone goes down.
-Therefore, if all nodes in a zone are unhealthy then the node controller evicts at
+Therefore, if all nodes in a zone are unhealthy, then the node controller evicts at
 the normal rate of `--node-eviction-rate`.  The corner case is when all zones are
 completely unhealthy (i.e. there are no healthy nodes in the cluster). In such a
-case, the node controller assumes that there's some problem with master
+case, the node controller assumes that there is some problem with master
 connectivity and stops all evictions until some connectivity is restored.

 The node controller is also responsible for evicting pods running on nodes with
@@ -303,8 +306,8 @@ eligible for, effectively removing incoming load balancer traffic from the cordo

 ### Node capacity

-Node objects track information about the Node's resource capacity (for example: the amount
-of memory available, and the number of CPUs).
+Node objects track information about the Node's resource capacity: for example, the amount
+of memory available and the number of CPUs.
 Nodes that [self register](#self-registration-of-nodes) report their capacity during
 registration. If you [manually](#manual-node-administration) add a Node, then
 you need to set the node's capacity information when you add it.
@@ -338,7 +341,7 @@ for more information.
 If you have enabled the `GracefulNodeShutdown` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/), then the kubelet attempts to detect the node system shutdown and terminates pods running on the node.
 Kubelet ensures that pods follow the normal [pod termination process](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination) during the node shutdown.

-When the `GracefulNodeShutdown` feature gate is enabled, kubelet uses [systemd inhibitor locks](https://www.freedesktop.org/wiki/Software/systemd/inhibit/) to delay the node shutdown with a given duration. During a shutdown kubelet terminates pods in two phases:
+When the `GracefulNodeShutdown` feature gate is enabled, kubelet uses [systemd inhibitor locks](https://www.freedesktop.org/wiki/Software/systemd/inhibit/) to delay the node shutdown with a given duration. During a shutdown, kubelet terminates pods in two phases:

 1. Terminate regular pods running on the node.
 2. Terminate [critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical) running on the node.
@@ -45,7 +45,7 @@ Before choosing a guide, here are some considerations:

 ## Securing a cluster

-* [Certificates](/docs/concepts/cluster-administration/certificates/) describes the steps to generate certificates using different tool chains.
+* [Generate Certificates](/docs/tasks/administer-cluster/certificates/) describes the steps to generate certificates using different tool chains.

 * [Kubernetes Container Environment](/docs/concepts/containers/container-environment/) describes the environment for Kubelet managed containers on a Kubernetes node.

@@ -4,249 +4,6 @@ content_type: concept
 weight: 20
 ---

-
 <!-- overview -->

-When using client certificate authentication, you can generate certificates
-manually through `easyrsa`, `openssl` or `cfssl`.
-
-
-
-
-<!-- body -->
-
-### easyrsa
-
-**easyrsa** can manually generate certificates for your cluster.
-
-1.  Download, unpack, and initialize the patched version of easyrsa3.
-
-        curl -LO https://storage.googleapis.com/kubernetes-release/easy-rsa/easy-rsa.tar.gz
-        tar xzf easy-rsa.tar.gz
-        cd easy-rsa-master/easyrsa3
-        ./easyrsa init-pki
-1.  Generate a new certificate authority (CA). `--batch` sets automatic mode;
-    `--req-cn` specifies the Common Name (CN) for the CA's new root certificate.
-
-        ./easyrsa --batch "--req-cn=${MASTER_IP}@`date +%s`" build-ca nopass
-1.  Generate server certificate and key.
-    The argument `--subject-alt-name` sets the possible IPs and DNS names the API server will
-    be accessed with. The `MASTER_CLUSTER_IP` is usually the first IP from the service CIDR
-    that is specified as the `--service-cluster-ip-range` argument for both the API server and
-    the controller manager component. The argument `--days` is used to set the number of days
-    after which the certificate expires.
-    The sample below also assumes that you are using `cluster.local` as the default
-    DNS domain name.
-
-        ./easyrsa --subject-alt-name="IP:${MASTER_IP},"\
-        "IP:${MASTER_CLUSTER_IP},"\
-        "DNS:kubernetes,"\
-        "DNS:kubernetes.default,"\
-        "DNS:kubernetes.default.svc,"\
-        "DNS:kubernetes.default.svc.cluster,"\
-        "DNS:kubernetes.default.svc.cluster.local" \
-        --days=10000 \
-        build-server-full server nopass
-1.  Copy `pki/ca.crt`, `pki/issued/server.crt`, and `pki/private/server.key` to your directory.
-1.  Fill in and add the following parameters into the API server start parameters:
-
-        --client-ca-file=/yourdirectory/ca.crt
-        --tls-cert-file=/yourdirectory/server.crt
-        --tls-private-key-file=/yourdirectory/server.key
-
-### openssl
-
-**openssl** can manually generate certificates for your cluster.
-
-1.  Generate a ca.key with 2048bit:
-
-        openssl genrsa -out ca.key 2048
-1.  According to the ca.key generate a ca.crt (use -days to set the certificate effective time):
-
-        openssl req -x509 -new -nodes -key ca.key -subj "/CN=${MASTER_IP}" -days 10000 -out ca.crt
-1.  Generate a server.key with 2048bit:
-
-        openssl genrsa -out server.key 2048
-1.  Create a config file for generating a Certificate Signing Request (CSR).
-    Be sure to substitute the values marked with angle brackets (e.g. `<MASTER_IP>`)
-    with real values before saving this to a file (e.g. `csr.conf`).
-    Note that the value for `MASTER_CLUSTER_IP` is the service cluster IP for the
-    API server as described in previous subsection.
-    The sample below also assumes that you are using `cluster.local` as the default
-    DNS domain name.
-
-        [ req ]
-        default_bits = 2048
-        prompt = no
-        default_md = sha256
-        req_extensions = req_ext
-        distinguished_name = dn
-
-        [ dn ]
-        C = <country>
-        ST = <state>
-        L = <city>
-        O = <organization>
-        OU = <organization unit>
-        CN = <MASTER_IP>
-
-        [ req_ext ]
-        subjectAltName = @alt_names
-
-        [ alt_names ]
-        DNS.1 = kubernetes
-        DNS.2 = kubernetes.default
-        DNS.3 = kubernetes.default.svc
-        DNS.4 = kubernetes.default.svc.cluster
-        DNS.5 = kubernetes.default.svc.cluster.local
-        IP.1 = <MASTER_IP>
-        IP.2 = <MASTER_CLUSTER_IP>
-
-        [ v3_ext ]
-        authorityKeyIdentifier=keyid,issuer:always
-        basicConstraints=CA:FALSE
-        keyUsage=keyEncipherment,dataEncipherment
-        extendedKeyUsage=serverAuth,clientAuth
-        subjectAltName=@alt_names
-1.  Generate the certificate signing request based on the config file:
-
-        openssl req -new -key server.key -out server.csr -config csr.conf
-1.  Generate the server certificate using the ca.key, ca.crt and server.csr:
-
-        openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \
-        -CAcreateserial -out server.crt -days 10000 \
-        -extensions v3_ext -extfile csr.conf
-1.  View the certificate:
-
-        openssl x509  -noout -text -in ./server.crt
-
-Finally, add the same parameters into the API server start parameters.
-
-### cfssl
-
-**cfssl** is another tool for certificate generation.
-
-1.  Download, unpack and prepare the command line tools as shown below.
-    Note that you may need to adapt the sample commands based on the hardware
-    architecture and cfssl version you are using.
-
-        curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssl_1.5.0_linux_amd64 -o cfssl
-        chmod +x cfssl
-        curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssljson_1.5.0_linux_amd64 -o cfssljson
-        chmod +x cfssljson
-        curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssl-certinfo_1.5.0_linux_amd64 -o cfssl-certinfo
-        chmod +x cfssl-certinfo
-1.  Create a directory to hold the artifacts and initialize cfssl:
-
-        mkdir cert
-        cd cert
-        ../cfssl print-defaults config > config.json
-        ../cfssl print-defaults csr > csr.json
-1.  Create a JSON config file for generating the CA file, for example, `ca-config.json`:
-
-        {
-          "signing": {
-            "default": {
-              "expiry": "8760h"
-            },
-            "profiles": {
-              "kubernetes": {
-                "usages": [
-                  "signing",
-                  "key encipherment",
-                  "server auth",
-                  "client auth"
-                ],
-                "expiry": "8760h"
-              }
-            }
-          }
-        }
-1.  Create a JSON config file for CA certificate signing request (CSR), for example,
-    `ca-csr.json`. Be sure to replace the values marked with angle brackets with
-    real values you want to use.
-
-        {
-          "CN": "kubernetes",
-          "key": {
-            "algo": "rsa",
-            "size": 2048
-          },
-          "names":[{
-            "C": "<country>",
-            "ST": "<state>",
-            "L": "<city>",
-            "O": "<organization>",
-            "OU": "<organization unit>"
-          }]
-        }
-1.  Generate CA key (`ca-key.pem`) and certificate (`ca.pem`):
-
-        ../cfssl gencert -initca ca-csr.json | ../cfssljson -bare ca
-1.  Create a JSON config file for generating keys and certificates for the API
-    server, for example, `server-csr.json`. Be sure to replace the values in angle brackets with
-    real values you want to use. The `MASTER_CLUSTER_IP` is the service cluster
-    IP for the API server as described in previous subsection.
-    The sample below also assumes that you are using `cluster.local` as the default
-    DNS domain name.
-
-        {
-          "CN": "kubernetes",
-          "hosts": [
-            "127.0.0.1",
-            "<MASTER_IP>",
-            "<MASTER_CLUSTER_IP>",
-            "kubernetes",
-            "kubernetes.default",
-            "kubernetes.default.svc",
-            "kubernetes.default.svc.cluster",
-            "kubernetes.default.svc.cluster.local"
-          ],
-          "key": {
-            "algo": "rsa",
-            "size": 2048
-          },
-          "names": [{
-            "C": "<country>",
-            "ST": "<state>",
-            "L": "<city>",
-            "O": "<organization>",
-            "OU": "<organization unit>"
-          }]
-        }
-1.  Generate the key and certificate for the API server, which are by default
-    saved into file `server-key.pem` and `server.pem` respectively:
-
-        ../cfssl gencert -ca=ca.pem -ca-key=ca-key.pem \
-        --config=ca-config.json -profile=kubernetes \
-        server-csr.json | ../cfssljson -bare server
-
-
-## Distributing Self-Signed CA Certificate
-
-A client node may refuse to recognize a self-signed CA certificate as valid.
-For a non-production deployment, or for a deployment that runs behind a company
-firewall, you can distribute a self-signed CA certificate to all clients and
-refresh the local list for valid certificates.
-
-On each client, perform the following operations:
-
-```bash
-sudo cp ca.crt /usr/local/share/ca-certificates/kubernetes.crt
-sudo update-ca-certificates
-```
-
-```
-Updating certificates in /etc/ssl/certs...
-1 added, 0 removed; done.
-Running hooks in /etc/ca-certificates/update.d....
-done.
-```
-
-## Certificates API
-
-You can use the `certificates.k8s.io` API to provision
-x509 certificates to use for authentication as documented
-[here](/docs/tasks/tls/managing-tls-in-a-cluster).
-
-
+To learn how to generate certificates for your cluster, see [Certificates](/docs/tasks/administer-cluster/certificates/).
@@ -47,7 +47,7 @@ kubectl apply -f https://k8s.io/examples/application/nginx/

 It is a recommended practice to put resources related to the same microservice or application tier into the same file, and to group all of the files associated with your application in the same directory. If the tiers of your application bind to each other using DNS, you can deploy all of the components of your stack together.

-A URL can also be specified as a configuration source, which is handy for deploying directly from configuration files checked into github:
+A URL can also be specified as a configuration source, which is handy for deploying directly from configuration files checked into GitHub:

 ```shell
 kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/application/nginx/nginx-deployment.yaml
@@ -43,7 +43,7 @@ Kubernetes objects that have a `spec`, a ConfigMap has `data` and `binaryData`
 fields. These fields accept key-value pairs as their values.  Both the `data`
 field and the `binaryData` are optional. The `data` field is designed to
 contain UTF-8 byte sequences while the `binaryData` field is designed to
-contain binary data.
+contain binary data as base64-encoded strings.

 The name of a ConfigMap must be a valid
 [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
@@ -81,9 +81,9 @@ The [imagePullPolicy](/docs/concepts/containers/images/#updating-images) and the

 - `imagePullPolicy: Always`: every time the kubelet launches a container, the kubelet queries the container image registry to resolve the name to an image digest. If the kubelet has a container image with that exact digest cached locally, the kubelet uses its cached image; otherwise, the kubelet downloads (pulls) the image with the resolved digest, and uses that image to launch the container.

- `imagePullPolicy` is omitted and either the image tag is `:latest` or it is omitted: `Always` is applied.
+- `imagePullPolicy` is omitted and either the image tag is `:latest` or it is omitted: `imagePullPolicy` is automatically set to `Always`. Note that this will _not_ be updated to `IfNotPresent` if the tag changes value.

- `imagePullPolicy` is omitted and the image tag is present but not `:latest`: `IfNotPresent` is applied.
+- `imagePullPolicy` is omitted and the image tag is present but not `:latest`: `imagePullPolicy` is automatically set to `IfNotPresent`. Note that this will _not_ be updated to `Always` if the tag is later removed or changed to `:latest`.

 - `imagePullPolicy: Never`: the image is assumed to exist locally. No attempt is made to pull the image.

@@ -96,7 +96,7 @@ You should avoid using the `:latest` tag when deploying containers in production
 {{< /note >}}

 {{< note >}}
-The caching semantics of the underlying image provider make even `imagePullPolicy: Always` efficient. With Docker, for example, if the image already exists, the pull attempt is fast because all image layers are cached and no image download is needed.
+The caching semantics of the underlying image provider make even `imagePullPolicy: Always` efficient, as long as the registry is reliably accessible. With Docker, for example, if the image already exists, the pull attempt is fast because all image layers are cached and no image download is needed.
 {{< /note >}}

 ## Using kubectl
@@ -718,7 +718,7 @@ spec:

 #### Consuming Secret Values from environment variables

-Inside a container that consumes a secret in an environment variables, the secret keys appear as
+Inside a container that consumes a secret in the environment variables, the secret keys appear as
 normal environment variables containing the base64 decoded values of the secret data.
 This is the result of commands executed inside the container from the example above:

@@ -40,6 +40,7 @@ as are any environment variables specified statically in the Docker image.
 ### Cluster information

 A list of all services that were running when a Container was created is available to that Container as environment variables.
+This list is limited to services within the same namespace as the new Container's Pod and Kubernetes control plane services.
 Those environment variables match the syntax of Docker links.

 For a service named *foo* that maps to a Container named *bar*,
@@ -49,16 +49,32 @@ Instead, specify a meaningful tag such as `v1.42.0`.

 ## Updating images

-The default pull policy is `IfNotPresent` which causes the
-{{< glossary_tooltip text="kubelet" term_id="kubelet" >}} to skip
-pulling an image if it already exists. If you would like to always force a pull,
-you can do one of the following:
+When you first create a {{< glossary_tooltip text="Deployment" term_id="deployment" >}},
+{{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}, Pod, or other
+object that includes a Pod template, then by default the pull policy of all
+containers in that pod will be set to `IfNotPresent` if it is not explicitly
+specified. This policy causes the
+{{< glossary_tooltip text="kubelet" term_id="kubelet" >}} to skip pulling an
+image if it already exists.
+
+If you would like to always force a pull, you can do one of the following:

 - set the `imagePullPolicy` of the container to `Always`.
- omit the `imagePullPolicy` and use `:latest` as the tag for the image to use.
+- omit the `imagePullPolicy` and use `:latest` as the tag for the image to use;
+  Kubernetes will set the policy to `Always`.
 - omit the `imagePullPolicy` and the tag for the image to use.
 - enable the [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) admission controller.

+{{< note >}}
+The value of `imagePullPolicy` of the container is always set when the object is
+first _created_, and is not updated if the image's tag later changes.
+
+For example, if you create a Deployment with an image whose tag is _not_
+`:latest`, and later update that Deployment's image to a `:latest` tag, the
+`imagePullPolicy` field will _not_ change to `Always`. You must manually change
+the pull policy of any object after its initial creation.
+{{< /note >}}
+
 When `imagePullPolicy` is defined without a specific value, it is also set to `Always`.

 ## Multi-architecture images with image indexes
@@ -28,9 +28,7 @@ The most common way to implement the APIService is to run an *extension API serv
 Extension API servers should have low latency networking to and from the kube-apiserver.
 Discovery requests are required to round-trip from the kube-apiserver in five seconds or less.

-If your extension API server cannot achieve that latency requirement, consider making changes that let you meet it. You can also set the
-`EnableAggregatedDiscoveryTimeout=false` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) on the kube-apiserver
-to disable the timeout restriction. This deprecated feature gate will be removed in a future release.
+If your extension API server cannot achieve that latency requirement, consider making changes that let you meet it.

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

@@ -103,26 +103,27 @@ as well as keeping the existing service in good shape.
 ## Writing your own Operator {#writing-operator}

 If there isn't an Operator in the ecosystem that implements the behavior you
-want, you can code your own. In [What's next](#what-s-next) you'll find a few
-links to libraries and tools you can use to write your own cloud native
-Operator.
+want, you can code your own. 

 You also implement an Operator (that is, a Controller) using any language / runtime
 that can act as a [client for the Kubernetes API](/docs/reference/using-api/client-libraries/).

+Following are a few libraries and tools you can use to write your own cloud native
+Operator.

+{{% thirdparty-content %}}
+
+* [kubebuilder](https://book.kubebuilder.io/)
+* [KUDO](https://kudo.dev/) (Kubernetes Universal Declarative Operator)
+* [Metacontroller](https://metacontroller.app/) along with WebHooks that
+  you implement yourself
+* [Operator Framework](https://operatorframework.io)

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


 * Learn more about [Custom Resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
 * Find ready-made operators on [OperatorHub.io](https://operatorhub.io/) to suit your use case
-* Use existing tools to write your own operator, eg:
-  * using [KUDO](https://kudo.dev/) (Kubernetes Universal Declarative Operator)
-  * using [kubebuilder](https://book.kubebuilder.io/)
-  * using [Metacontroller](https://metacontroller.app/) along with WebHooks that
-    you implement yourself
-  * using the [Operator Framework](https://operatorframework.io)
 * [Publish](https://operatorhub.io/) your operator for other people to use
 * Read [CoreOS' original article](https://web.archive.org/web/20170129131616/https://coreos.com/blog/introducing-operators.html) that introduced the Operator pattern (this is an archived version of the original article).
 * Read an [article](https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-building-kubernetes-operators-and-stateful-apps) from Google Cloud about best practices for building Operators
@@ -51,11 +51,11 @@ the same machine, and do not run user containers on this machine. See

 {{< glossary_definition term_id="kube-controller-manager" length="all" >}}

-These controllers include:
+Some types of these controllers are:

  * Node controller: Responsible for noticing and responding when nodes go down.
-  * Replication controller: Responsible for maintaining the correct number of pods for every replication
-  controller object in the system.
+  * Job controller: Watches for Job objects that represent one-off tasks, then creates
+    Pods to run those tasks to completion.
  * Endpoints controller: Populates the Endpoints object (that is, joins Services & Pods).
  * Service Account & Token controllers: Create default accounts and API access tokens for new namespaces.

@@ -52,7 +52,10 @@ If the prefix is omitted, the label Key is presumed to be private to the user. A

 The `kubernetes.io/` and `k8s.io/` prefixes are reserved for Kubernetes core components.

-Valid label values must be 63 characters or less and must be empty or begin and end with an alphanumeric character (`[a-z0-9A-Z]`) with dashes (`-`), underscores (`_`), dots (`.`), and alphanumerics between.
+Valid label value:
+* must be 63 characters or less (cannot be empty),
+* must begin and end with an alphanumeric character (`[a-z0-9A-Z]`),
+* could contain dashes (`-`), underscores (`_`), dots (`.`), and alphanumerics between.

 For example, here's the configuration file for a Pod that has two labels `environment: production` and `app: nginx` :

@@ -5,7 +5,7 @@ reviewers:
 - bsalamat
 title: Assigning Pods to Nodes
 content_type: concept
-weight: 50
+weight: 20
 ---


@@ -5,7 +5,7 @@ reviewers:
 - ahg-g
 title: Resource Bin Packing for Extended Resources
 content_type: concept
-weight: 50
+weight: 30
 ---

 <!-- overview -->
@@ -7,8 +7,8 @@ content_type: concept
 weight: 20
 ---
 <!-- overview -->
-This page provides an overview of DNS support by Kubernetes.
-
+Kubernetes creates DNS records for services and pods. You can contact
+services with consistent DNS names instead of IP addresses. 

 <!-- body -->

@@ -18,19 +18,47 @@ Kubernetes DNS schedules a DNS Pod and Service on the cluster, and configures
 the kubelets to tell individual containers to use the DNS Service's IP to
 resolve DNS names.

-### What things get DNS names?
-
 Every Service defined in the cluster (including the DNS server itself) is
-assigned a DNS name.  By default, a client Pod's DNS search list will
-include the Pod's own namespace and the cluster's default domain.  This is best
-illustrated by example:
+assigned a DNS name. By default, a client Pod's DNS search list includes the 
+Pod's own namespace and the cluster's default domain. 

-Assume a Service named `foo` in the Kubernetes namespace `bar`. A Pod running
-in namespace `bar` can look up this service by querying a DNS service for
-`foo`. A Pod running in namespace `quux` can look up this service by doing a
-DNS query for `foo.bar`.
+### Namespaces of Services 

-The following sections detail the supported record types and layout that is
+A DNS query may return different results based on the namespace of the pod making 
+it. DNS queries that don't specify a namespace are limited to the pod's 
+namespace. Access services in other namespaces by specifying it in the DNS query. 
+
+For example, consider a pod in a `test` namespace. A `data` service is in 
+the `prod` namespace. 
+
+A query for `data` returns no results, because it uses the pod's `test` namespace. 
+
+A query for `data.prod` returns the intended result, because it specifies the 
+namespace. 
+
+DNS queries may be expanded using the pod's `/etc/resolv.conf`. Kubelet 
+sets this file for each pod. For example, a query for just `data` may be 
+expanded to `data.test.cluster.local`. The values of the `search` option 
+are used to expand queries. To learn more about DNS queries, see 
+[the `resolv.conf` manual page.](https://www.man7.org/linux/man-pages/man5/resolv.conf.5.html) 
+
+```
+nameserver 10.32.0.10
+search <namespace>.svc.cluster.local svc.cluster.local cluster.local
+options ndots:5
+```
+
+In summary, a pod in the _test_ namespace can successfully resolve either 
+`data.prod` or `data.prod.cluster.local`.
+
+### DNS Records
+
+What objects get DNS records?
+
+1. Services
+2. Pods
+
+The following sections detail the supported DNS record types and layout that is
 supported.  Any other layout or names or queries that happen to work are
 considered implementation details and are subject to change without warning.
 For more up-to-date specification, see
@@ -74,8 +74,8 @@ a new instance.
 The name of a Service object must be a valid
 [DNS label name](/docs/concepts/overview/working-with-objects/names#dns-label-names).

-For example, suppose you have a set of Pods that each listen on TCP port 9376
-and carry a label `app=MyApp`:
+For example, suppose you have a set of Pods where each listens on TCP port 9376
+and contains a label `app=MyApp`:

 ```yaml
 apiVersion: v1
@@ -80,7 +80,7 @@ parameters:
 Users request dynamically provisioned storage by including a storage class in
 their `PersistentVolumeClaim`. Before Kubernetes v1.6, this was done via the
 `volume.beta.kubernetes.io/storage-class` annotation. However, this annotation
-is deprecated since v1.6. Users now can and should instead use the
+is deprecated since v1.9. Users now can and should instead use the
 `storageClassName` field of the `PersistentVolumeClaim` object. The value of
 this field must match the name of a `StorageClass` configured by the
 administrator (see [below](#enabling-dynamic-provisioning)).
@@ -34,8 +34,9 @@ Kubernetes supports many types of volumes. A {{< glossary_tooltip term_id="pod"
 can use any number of volume types simultaneously.
 Ephemeral volume types have a lifetime of a pod, but persistent volumes exist beyond
 the lifetime of a pod. Consequently, a volume outlives any containers
-that run within the pod, and data is preserved across container restarts. When a
-pod ceases to exist, the volume is destroyed.
+that run within the pod, and data is preserved across container restarts. When a pod
+ceases to exist, Kubernetes destroys ephemeral volumes; however, Kubernetes does not
+destroy persistent volumes.

 At its core, a volume is just a directory, possibly with some data in it, which
 is accessible to the containers in a pod. How that directory comes to be, the
@@ -54,7 +54,7 @@ In this example:
  {{< note >}}
  The `.spec.selector.matchLabels` field is a map of {key,value} pairs.
  A single {key,value} in the `matchLabels` map is equivalent to an element of `matchExpressions`,
-  whose key field is "key" the operator is "In", and the values array contains only "value".
+  whose `key` field is "key", the `operator` is "In", and the `values` array contains only "value".
  All of the requirements, from both `matchLabels` and `matchExpressions`, must be satisfied in order to match.
  {{< /note >}}

@@ -75,7 +75,7 @@ Here are some ways to mitigate involuntary disruptions:
  and [stateful](/docs/tasks/run-application/run-replicated-stateful-application/) applications.)
 - For even higher availability when running replicated applications,
  spread applications across racks (using
-  [anti-affinity](/docs/user-guide/node-selection/#inter-pod-affinity-and-anti-affinity-beta-feature))
+  [anti-affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity))
  or across zones (if using a
  [multi-zone cluster](/docs/setup/multiple-zones).)

@@ -104,7 +104,7 @@ ensure that the number of replicas serving load never falls below a certain
 percentage of the total.

 Cluster managers and hosting providers should use tools which
-respect PodDisruptionBudgets by calling the [Eviction API](/docs/tasks/administer-cluster/safely-drain-node/#the-eviction-api)
+respect PodDisruptionBudgets by calling the [Eviction API](/docs/tasks/administer-cluster/safely-drain-node/#eviction-api)
 instead of directly deleting pods or deployments.

 For example, the `kubectl drain` subcommand lets you mark a node as going out of
@@ -61,7 +61,7 @@ Members of `@kubernetes/sig-docs-**-owners` can approve PRs that change content

 For each localization, The `@kubernetes/sig-docs-**-reviews` team automates review assignment for new PRs.

-Members of `@kubernetes/website-maintainers` can create new development branches to coordinate translation efforts.
+Members of `@kubernetes/website-maintainers` can create new localization branches to coordinate translation efforts.

 Members of `@kubernetes/website-milestone-maintainers` can use the `/milestone` [Prow command](https://prow.k8s.io/command-help) to assign a milestone to issues or PRs.

@@ -205,14 +205,20 @@ To ensure accuracy in grammar and meaning, members of your localization team sho

 ### Source files

-Localizations must be based on the English files from the most recent release, {{< latest-version >}}.
+Localizations must be based on the English files from a specific release targeted by the localization team.
+Each localization team can decide which release to target which is referred to as the _target version_ below.

-To find source files for the most recent release:
+To find source files for your target version:

 1. Navigate to the Kubernetes website repository at https://github.com/kubernetes/website.
-2. Select the `release-1.X` branch for the most recent version.
+2. Select a branch for your target version from the following table:
+    Target version | Branch
+    -----|-----
+    Next version | [`dev-{{< skew nextMinorVersion >}}`](https://github.com/kubernetes/website/tree/dev-{{< skew nextMinorVersion >}})
+    Latest version | [`master`](https://github.com/kubernetes/website/tree/master)
+    Previous version | `release-*.**`

-The latest version is {{< latest-version >}}, so the most recent release branch is [`{{< release-branch >}}`](https://github.com/kubernetes/website/tree/{{< release-branch >}}).
+The `master` branch holds content for the current release `{{< latest-version >}}`. The release team will create `{{< release-branch >}}` branch shortly before the next release: v{{< skew nextMinorVersion >}}.

 ### Site strings in i18n

@@ -239,11 +245,11 @@ Some language teams have their own language-specific style guide and glossary. F

 ## Branching strategy

-Because localization projects are highly collaborative efforts, we encourage teams to work in shared development branches.
+Because localization projects are highly collaborative efforts, we encourage teams to work in shared localization branches.

-To collaborate on a development branch:
+To collaborate on a localization branch:

-1. A team member of [@kubernetes/website-maintainers](https://github.com/orgs/kubernetes/teams/website-maintainers) opens a development branch from a source branch on https://github.com/kubernetes/website.
+1. A team member of [@kubernetes/website-maintainers](https://github.com/orgs/kubernetes/teams/website-maintainers) opens a localization branch from a source branch on https://github.com/kubernetes/website.

    Your team approvers joined the `@kubernetes/website-maintainers` team when you [added your localization team](#add-your-localization-team-in-github) to the [`kubernetes/org`](https://github.com/kubernetes/org) repository.

@@ -251,25 +257,31 @@ To collaborate on a development branch:

    `dev-<source version>-<language code>.<team milestone>`

-    For example, an approver on a German localization team opens the development branch `dev-1.12-de.1` directly against the k/website repository, based on the source branch for Kubernetes v1.12.
+    For example, an approver on a German localization team opens the localization branch `dev-1.12-de.1` directly against the k/website repository, based on the source branch for Kubernetes v1.12.

-2. Individual contributors open feature branches based on the development branch.
+2. Individual contributors open feature branches based on the localization branch.

    For example, a German contributor opens a pull request with changes to `kubernetes:dev-1.12-de.1` from `username:local-branch-name`.

-3. Approvers review and merge feature branches into the development branch.
+3. Approvers review and merge feature branches into the localization branch.

-4. Periodically, an approver merges the development branch to its source branch by opening and approving a new pull request. Be sure to squash the commits before approving the pull request.
+4. Periodically, an approver merges the localization branch to its source branch by opening and approving a new pull request. Be sure to squash the commits before approving the pull request.

-Repeat steps 1-4 as needed until the localization is complete. For example, subsequent German development branches would be: `dev-1.12-de.2`, `dev-1.12-de.3`, etc.
+Repeat steps 1-4 as needed until the localization is complete. For example, subsequent German localization branches would be: `dev-1.12-de.2`, `dev-1.12-de.3`, etc.

-Teams must merge localized content into the same release branch from which the content was sourced. For example, a development branch sourced from {{< release-branch >}} must be based on {{< release-branch >}}.
+Teams must merge localized content into the same branch from which the content was sourced.

-An approver must maintain a development branch by keeping it current with its source branch and resolving merge conflicts. The longer a development branch stays open, the more maintenance it typically requires. Consider periodically merging development branches and opening new ones, rather than maintaining one extremely long-running development branch.
+For example:
+- a localization branch sourced from `master` must be merged into `master`.
+- a localization branch sourced from `release-1.19` must be merged into `release-1.19`.

-At the beginning of every team milestone, it's helpful to open an issue comparing upstream changes between the previous development branch and the current development branch. There are two scripts for comparing upstream changes. [`upstream_changes.py`](https://github.com/kubernetes/website/tree/master/scripts#upstream_changespy) is useful for checking the changes made to a specific file. And [`diff_l10n_branches.py`](https://github.com/kubernetes/website/tree/master/scripts#diff_l10n_branchespy) is useful for creating a list of outdated files for a specific localization branch.
+{{< note >}}
+If your localization branch was created from `master` branch but it is not merged into `master` before new release branch `{{< release-branch >}}` created, merge it into both `master` and new release branch `{{< release-branch >}}`. To merge your localization branch into new release branch `{{< release-branch >}}`, you need to switch upstream branch of your localization branch to `{{< release-branch >}}`.
+{{< /note >}}

- While only approvers can open a new development branch and merge pull requests, anyone can open a pull request for a new development branch. No special permissions are required.
+At the beginning of every team milestone, it's helpful to open an issue comparing upstream changes between the previous localization branch and the current localization branch. There are two scripts for comparing upstream changes. [`upstream_changes.py`](https://github.com/kubernetes/website/tree/master/scripts#upstream_changespy) is useful for checking the changes made to a specific file. And [`diff_l10n_branches.py`](https://github.com/kubernetes/website/tree/master/scripts#diff_l10n_branchespy) is useful for creating a list of outdated files for a specific localization branch.
+
+While only approvers can open a new localization branch and merge pull requests, anyone can open a pull request for a new localization branch. No special permissions are required.

 For more information about working from forks or directly from the repository, see ["fork and clone the repo"](#fork-and-clone-the-repo).

@@ -290,5 +302,3 @@ Once a localization meets requirements for workflow and minimum output, SIG docs

 - Enable language selection on the website
 - Publicize the localization's availability through [Cloud Native Computing Foundation](https://www.cncf.io/about/) (CNCF) channels, including the [Kubernetes blog](https://kubernetes.io/blog/).
-
-
@@ -17,8 +17,6 @@ Changes to the style guide are made by SIG Docs as a group. To propose a change
 or addition, [add it to the agenda](https://docs.google.com/document/d/1ddHwLK3kUMX1wVFIwlksjTk0MsqitBnWPe1LRa1Rx5A/edit) for an upcoming SIG Docs meeting, and attend the meeting to participate in the
 discussion.

-
-
 <!-- body -->

 {{< note >}}
@@ -50,10 +48,9 @@ When you are generally discussing an API object, use [sentence-style capitalizat

 You may use the word "resource", "API", or "object" to clarify a Kubernetes resource type in a sentence.

-Don't split the API object name into separate words. For example, use
-PodTemplateList, not Pod Template List.
+Don't split an API object name into separate words. For example, use PodTemplateList, not Pod Template List.

-The following examples focus on capitalization. Review the related guidance on [Code Style](#code-style-inline-code) for more information on formatting API objects. 
+The following examples focus on capitalization. For more information about formatting API object names, review the related guidance on [Code Style](#code-style-inline-code).

 {{< table caption = "Do and Don't - Use Pascal case for API objects" >}}
 Do | Don't
@@ -65,17 +62,18 @@ Every ConfigMap object is part of a namespace. | Every configMap object is part
 For managing confidential data, consider using the Secret API. | For managing confidential data, consider using the secret API.
 {{< /table >}}

-
 ### Use angle brackets for placeholders

 Use angle brackets for placeholders. Tell the reader what a placeholder
-represents.
+represents, for example:

-1. Display information about a pod:
+Display information about a pod:

-        kubectl describe pod <pod-name> -n <namespace>
+```shell
+kubectl describe pod <pod-name> -n <namespace>
+```

-    If the namespace of the pod is `default`, you can omit the '-n' parameter.
+If the namespace of the pod is `default`, you can omit the '-n' parameter.

 ### Use bold for user interface elements

@@ -189,7 +187,6 @@ Set the value of `image` to nginx:1.16. | Set the value of `image` to `nginx:1.1
 Set the value of the `replicas` field to 2. | Set the value of the `replicas` field to `2`.
 {{< /table >}}

-
 ## Code snippet formatting

 ### Don't include the command prompt
@@ -200,17 +197,20 @@ Do | Don't
 kubectl get pods | $ kubectl get pods
 {{< /table >}}

-
 ### Separate commands from output

 Verify that the pod is running on your chosen node:

-    kubectl get pods --output=wide
+```shell
+kubectl get pods --output=wide
+```

 The output is similar to this:

-    NAME     READY     STATUS    RESTARTS   AGE    IP           NODE
-    nginx    1/1       Running   0          13s    10.200.0.4   worker0
+```console
+NAME     READY     STATUS    RESTARTS   AGE    IP           NODE
+nginx    1/1       Running   0          13s    10.200.0.4   worker0
+```

 ### Versioning Kubernetes examples

@@ -263,17 +263,17 @@ Hugo [Shortcodes](https://gohugo.io/content-management/shortcodes) help create d

 2. Use the following syntax to apply a style:

-    ```
-    {{</* note */>}}
-    No need to include a prefix; the shortcode automatically provides one. (Note:, Caution:, etc.)
-    {{</* /note */>}}
-    ```
+   ```none
+   {{</* note */>}}
+   No need to include a prefix; the shortcode automatically provides one. (Note:, Caution:, etc.)
+   {{</* /note */>}}
+   ```

-The output is:
+   The output is:

-{{< note >}}
-The prefix you choose is the same text for the tag.
-{{< /note >}}
+   {{< note >}}
+   The prefix you choose is the same text for the tag.
+   {{< /note >}}

 ### Note

@@ -403,7 +403,7 @@ The output is:

 1. Prepare the batter, and pour into springform pan.

-    {{< note >}}Grease the pan for best results.{{< /note >}}
+   {{< note >}}Grease the pan for best results.{{< /note >}}

 1. Bake for 20-25 minutes or until set.

@@ -417,13 +417,14 @@ Shortcodes inside include statements will break the build. You must insert them
 {{</* /note */>}}
 ```

-
 ## Markdown elements

 ### Line breaks
+
 Use a single newline to separate block-level content like headings, lists, images, code blocks, and others. The exception is second-level headings, where it should be two newlines. Second-level headings follow the first-level (or the title) without any preceding paragraphs or texts. A two line spacing helps visualize the overall structure of content in a code editor better.

 ### Headings
+
 People accessing this documentation may use a screen reader or other assistive technology (AT). [Screen readers](https://en.wikipedia.org/wiki/Screen_reader) are linear output devices, they output items on a page one at a time. If there is a lot of content on a page, you can use headings to give the page an internal structure. A good page structure helps all readers to easily navigate the page or filter topics of interest.

 {{< table caption = "Do and Don't - Headings" >}}
@@ -453,24 +454,24 @@ Write hyperlinks that give you context for the content they link to. For example
 Write Markdown-style links: `[link text](URL)`. For example: `[Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/#table-captions)` and the output is [Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/#table-captions). | Write HTML-style links: `<a href="/media/examples/link-element-example.css" target="_blank">Visit our tutorial!</a>`, or create links that open in new tabs or windows. For example: `[example website](https://example.com){target="_blank"}`
 {{< /table >}}

-
 ### Lists
+
 Group items in a list that are related to each other and need to appear in a specific order or to indicate a correlation between multiple items. When a screen reader comes across a list—whether it is an ordered or unordered list—it will be announced to the user that there is a group of list items. The user can then use the arrow keys to move up and down between the various items in the list.
 Website navigation links can also be marked up as list items; after all they are nothing but a group of related links.

- - End each item in a list with a period if one or more items in the list are complete sentences. For the sake of consistency, normally either all items or none should be complete sentences.
+- End each item in a list with a period if one or more items in the list are complete sentences. For the sake of consistency, normally either all items or none should be complete sentences.

-   {{< note >}} Ordered lists that are part of an incomplete introductory sentence can be in lowercase and punctuated as if each item was a part of the introductory sentence.{{< /note >}}
+  {{< note >}} Ordered lists that are part of an incomplete introductory sentence can be in lowercase and punctuated as if each item was a part of the introductory sentence.{{< /note >}}

- - Use the number one (`1.`) for ordered lists.
+- Use the number one (`1.`) for ordered lists.

- - Use (`+`), (`*`), or (`-`) for unordered lists.
+- Use (`+`), (`*`), or (`-`) for unordered lists.

- - Leave a blank line after each list.
+- Leave a blank line after each list.

- - Indent nested lists with four spaces (for example, ⋅⋅⋅⋅).
+- Indent nested lists with four spaces (for example, ⋅⋅⋅⋅).

- - List items may consist of multiple paragraphs. Each subsequent paragraph in a list item must be indented by either four spaces or one tab.
+- List items may consist of multiple paragraphs. Each subsequent paragraph in a list item must be indented by either four spaces or one tab.

 ### Tables

@@ -490,7 +491,6 @@ Do | Don't
 This command starts a proxy. | This command will start a proxy.
 {{< /table >}}

-
 Exception: Use future or past tense if it is required to convey the correct
 meaning.

@@ -503,7 +503,6 @@ You can explore the API using a browser. | The API can be explored using a brows
 The YAML file specifies the replica count. | The replica count is specified in the YAML file.
 {{< /table >}}

-
 Exception: Use passive voice if active voice leads to an awkward construction.

 ### Use simple and direct language
@@ -527,7 +526,6 @@ You can create a Deployment by ... | We'll create a Deployment by ...
 In the preceding output, you can see... | In the preceding output, we can see ...
 {{< /table >}}

-
 ### Avoid Latin phrases

 Prefer English terms over Latin abbreviations.
@@ -539,7 +537,6 @@ For example, ... | e.g., ...
 That is, ...| i.e., ...
 {{< /table >}}

-
 Exception: Use "etc." for et cetera.

 ## Patterns to avoid
@@ -557,7 +554,6 @@ Kubernetes provides a new feature for ... | We provide a new feature ...
 This page teaches you how to use pods. | In this page, we are going to learn about pods.
 {{< /table >}}

-
 ### Avoid jargon and idioms

 Some readers speak English as a second language. Avoid jargon and idioms to help them understand better.
@@ -569,7 +565,6 @@ Internally, ... | Under the hood, ...
 Create a new cluster. | Turn up a new cluster.
 {{< /table >}}

-
 ### Avoid statements about the future

 Avoid making promises or giving hints about the future. If you need to talk about
@@ -592,6 +587,18 @@ In version 1.4, ... | In the current version, ...
 The Federation feature provides ... | The new Federation feature provides ...
 {{< /table >}}

+### Avoid words that assume a specific level of understanding
+
+Avoid words such as "just", "simply", "easy", "easily", or "simple". These words do not add value.
+
+{{< table caption = "Do and Don't - Avoid insensitive words" >}}
+Do | Don't
+:--| :-----
+Include one command in ... | Include just one command in ...
+Run the container ... | Simply run the container ...
+You can easily remove ... | You can remove ...
+These simple steps ... | These steps ...
+{{< /table >}}

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

@@ -6,8 +6,10 @@ linkTitle: "Reference"
 main_menu: true
 weight: 70
 content_type: concept
+no_list: true
 ---

+
 <!-- overview -->

 This section of the Kubernetes documentation contains references.
@@ -18,11 +20,17 @@ This section of the Kubernetes documentation contains references.

 ## API Reference

+* [Glossary](/docs/reference/glossary/) -  a comprehensive, standardized list of Kubernetes terminology
+
+
+
 * [Kubernetes API Reference](/docs/reference/kubernetes-api/)
 * [One-page API Reference for Kubernetes {{< param "version" >}}](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
 * [Using The Kubernetes API](/docs/reference/using-api/) - overview of the API for Kubernetes.
+* [API access control](/docs/reference/access-authn-authz/) - details on how Kubernetes controls API access
+* [Well-Known Labels, Annotations and Taints](/docs/reference/kubernetes-api/labels-annotations-taints/)

-## API Client Libraries
+## Officially supported client libraries

 To call the Kubernetes API from a programming language, you can use
 [client libraries](/docs/reference/using-api/client-libraries/). Officially supported
@@ -32,22 +40,28 @@ client libraries:
 - [Kubernetes Python client library](https://github.com/kubernetes-client/python)
 - [Kubernetes Java client library](https://github.com/kubernetes-client/java)
 - [Kubernetes JavaScript client library](https://github.com/kubernetes-client/javascript)
+- [Kubernetes Dotnet client library](https://github.com/kubernetes-client/csharp)
+- [Kubernetes Haskell Client library](https://github.com/kubernetes-client/haskell)

-## CLI Reference
+## CLI

 * [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](https://goessner.net/articles/JsonPath/) with kubectl.
 * [kubeadm](/docs/reference/setup-tools/kubeadm/) - CLI tool to easily provision a secure Kubernetes cluster.

-## Components Reference
+## Components

 * [kubelet](/docs/reference/command-line-tools-reference/kubelet/) - The primary *node agent* that runs on each node. The kubelet takes a set of PodSpecs and ensures that the described containers are running and healthy.
 * [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/) - REST API that validates and configures data for API objects such as  pods, services, replication controllers.
 * [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/) - Daemon that embeds the core control loops shipped with Kubernetes.
 * [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) - Can do simple TCP/UDP stream forwarding or round-robin TCP/UDP forwarding across a set of back-ends.
 * [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/) - Scheduler that manages availability, performance, and capacity.  
-  * [kube-scheduler Policies](/docs/reference/scheduling/policies)
-  * [kube-scheduler Profiles](/docs/reference/scheduling/config#profiles)
+  
+## Scheduling
+
+* [Scheduler Policies](/docs/reference/scheduling/policies)
+* [Scheduler Profiles](/docs/reference/scheduling/config#profiles)
+

 ## Design Docs

@@ -1,6 +1,6 @@
 ---
 title: API Access Control
-weight: 20
+weight: 15
 no_list: true
 ---

@@ -565,6 +565,8 @@ Starting from 1.11, this admission controller is disabled by default.

 ### PodNodeSelector {#podnodeselector}

+{{< feature-state for_k8s_version="v1.5" state="alpha" >}}
+
 This admission controller defaults and limits what node selectors may be used within a namespace by reading a namespace annotation and a global configuration.

 #### Configuration File Format
@@ -675,6 +677,8 @@ for more information.

 ### PodTolerationRestriction {#podtolerationrestriction}

+{{< feature-state for_k8s_version="v1.7" state="alpha" >}}
+
 The PodTolerationRestriction admission controller verifies any conflict between tolerations of a pod and the tolerations of its namespace.
 It rejects the pod request if there is a conflict.
 It then merges the tolerations annotated on the namespace into the tolerations of the pod.
@@ -99,7 +99,7 @@ openssl req -new -key jbeda.pem -out jbeda-csr.pem -subj "/CN=jbeda/O=app1/O=app

 This would create a CSR for the username "jbeda", belonging to two groups, "app1" and "app2".

-See [Managing Certificates](/docs/concepts/cluster-administration/certificates/) for how to generate a client cert.
+See [Managing Certificates](/docs/tasks/administer-cluster/certificates/) for how to generate a client cert.

 ### Static Token File

@@ -328,7 +328,7 @@ Since all of the data needed to validate who you are is in the `id_token`, Kuber

 1. Kubernetes has no "web interface" to trigger the authentication process.  There is no browser or interface to collect credentials which is why you need to authenticate to your identity provider first.
 2. The `id_token` can't be revoked, it's like a certificate so it should be short-lived (only a few minutes) so it can be very annoying to have to get a new token every few minutes.
-3. To authenticate to the Kubernetes dashboard, you must the `kubectl proxy` command or a reverse proxy that injects the `id_token`.
+3. To authenticate to the Kubernetes dashboard, you must use the `kubectl proxy` command or a reverse proxy that injects the `id_token`.

 #### Configuring the API Server

@@ -1,4 +1,4 @@
 ---
-title: Command line tools reference
+title: Component tools
 weight: 60
 ---
@@ -242,6 +242,7 @@ different Kubernetes components.
 | `DynamicProvisioningScheduling` | - | Deprecated| 1.12 | - |
 | `DynamicVolumeProvisioning` | `true` | Alpha | 1.3 | 1.7 |
 | `DynamicVolumeProvisioning` | `true` | GA | 1.8 | - |
+| `EnableAggregatedDiscoveryTimeout` | `true` | Deprecated | 1.16 | - |
 | `EnableEquivalenceClassCache` | `false` | Alpha | 1.8 | 1.14 |
 | `EnableEquivalenceClassCache` | - | Deprecated | 1.15 | - |
 | `ExperimentalCriticalPodAnnotation` | `false` | Alpha | 1.5 | 1.12 |
@@ -728,7 +729,7 @@ Each feature gate is designed for enabling/disabling a specific feature:
  [ServiceTopology](/docs/concepts/services-networking/service-topology/)
  for more details.
 - `SizeMemoryBackedVolumes`: Enables kubelet support to size memory backed volumes.
-  See [volumes](docs/concepts/storage/volumes) for more details.
+  See [volumes](/docs/concepts/storage/volumes) for more details.
 - `SetHostnameAsFQDN`: Enable the ability of setting Fully Qualified Domain
  Name(FQDN) as the hostname of a pod. See
  [Pod's `setHostnameAsFQDN` field](/docs/concepts/services-networking/dns-pod-service/#pod-sethostnameasfqdn-field).
@@ -302,7 +302,7 @@ kubelet [flags]
 <td colspan="2">--enable-cadvisor-json-endpoints&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `false`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Enable cAdvisor json `/spec` and `/stats/*` endpoints. (DEPRECATED: will be removed in a future version)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Enable cAdvisor json `/spec` and `/stats/*` endpoints. This flag has no effect on the /stats/summary endpoint. (DEPRECATED: will be removed in a future version)</td>
 </tr>

 <tr>
@@ -2,7 +2,7 @@
 approvers:
 - chenopis
 - abiogenesis-now
-title: Standardized Glossary
+title: Glossary
 layout: glossary
 noedit: true
 default_active_tag: fundamental
@@ -1,4 +1,4 @@
 ---
 title: Kubernetes Issues and Security
-weight: 10
+weight: 40
 ---
@@ -1,5 +1,5 @@
 ---
-title: "kubectl CLI"
+title: "kubectl"
 weight: 60
 ---

@@ -320,6 +320,18 @@ kubectl top pod POD_NAME --containers               # Show metrics for a given p
 kubectl top pod POD_NAME --sort-by=cpu              # Show metrics for a given pod and sort it by 'cpu' or 'memory'
 ```

+## Interacting with Deployments and Services
+```bash
+kubectl logs deploy/my-deployment                         # dump Pod logs for a Deployment (single-container case)
+kubectl logs deploy/my-deployment -c my-container         # dump Pod logs for a Deployment (multi-container case)
+
+kubectl port-forward svc/my-service 5000                  # listen on local port 5000 and forward to port 5000 on Service backend
+kubectl port-forward svc/my-service 5000:my-service-port  # listen on local port 5000 and forward to Service target port with name <my-service-port>
+
+kubectl port-forward deploy/my-deployment 5000:6000       # listen on local port 5000 and forward to port 6000 on a Pod created by <my-deployment>
+kubectl exec deploy/my-deployment -- ls                   # run command in first Pod and first container in Deployment (single- or multi-container cases)
+```
+
 ## Interacting with Nodes and cluster

 ```bash
@@ -7,7 +7,7 @@ reviewers:
 ---

 <!-- overview -->
-You can use the Kubernetes command line tool kubectl to interact with the API Server. Using kubectl is straightforward if you are familiar with the Docker command line tool. However, there are a few differences between the docker commands and the kubectl commands. The following sections show a docker sub-command and describe the equivalent kubectl command.
+You can use the Kubernetes command line tool `kubectl` to interact with the API Server. Using kubectl is straightforward if you are familiar with the Docker command line tool. However, there are a few differences between the Docker commands and the kubectl commands. The following sections show a Docker sub-command and describe the equivalent `kubectl` command.


 <!-- body -->
@@ -19,7 +19,7 @@ files by setting the KUBECONFIG environment variable or by setting the
 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/).
+For installation instructions see [installing kubectl](/docs/tasks/tools/).

 <!-- body -->

@@ -181,8 +181,6 @@ that are not enabled by default:
 - `RequestedToCapacityRatio`: Favor nodes according to a configured function of
  the allocated resources.
  Extension points: `Score`.
- `NodeResourceLimits`: Favors nodes that satisfy the Pod resource limits.
-  Extension points: `PreScore`, `Score`.
 - `CinderVolume`: Checks that OpenStack Cinder volume limits can be satisfied
  for the node.
  Extension points: `Filter`.
@@ -1,4 +1,4 @@
 ---
-title: Setup tools reference
+title: Setup tools
 weight: 50
 ---
@@ -1,8 +1,10 @@
 ---
+title: Other Tools
 reviewers:
 - janetkuo
-title: Tools
 content_type: concept
+weight: 80
+no_list: true
 ---

 <!-- overview -->
@@ -10,13 +12,6 @@ Kubernetes contains several built-in tools to help you work with the Kubernetes


 <!-- body -->
-## Kubectl
-
-[`kubectl`](/docs/tasks/tools/install-kubectl/) is the command line tool for Kubernetes. It controls the Kubernetes cluster manager.
-
-## Kubeadm
-
-[`kubeadm`](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/) is the command line tool for easily provisioning a secure Kubernetes cluster on top of physical or cloud servers or virtual machines (currently in alpha).

 ## Minikube

@@ -1,11 +1,12 @@
 ---
-title: Kubernetes API Overview
+title: API Overview
 reviewers:
 - erictune
 - lavalamp
 - jbeda
 content_type: concept
 weight: 10
+no_list: true
 card:
  name: reference
  weight: 50
@@ -67,12 +67,13 @@ their authors, not the Kubernetes team.
 | Python               | [github.com/fiaas/k8s](https://github.com/fiaas/k8s) |
 | Python               | [github.com/mnubo/kubernetes-py](https://github.com/mnubo/kubernetes-py) |
 | Python               | [github.com/tomplus/kubernetes_asyncio](https://github.com/tomplus/kubernetes_asyncio) |
+| Python               | [github.com/Frankkkkk/pykorm](https://github.com/Frankkkkk/pykorm) |
 | Ruby                 | [github.com/abonas/kubeclient](https://github.com/abonas/kubeclient) |
 | Ruby                 | [github.com/Ch00k/kuber](https://github.com/Ch00k/kuber) |
 | Ruby                 | [github.com/kontena/k8s-client](https://github.com/kontena/k8s-client) |
 | Rust                 | [github.com/clux/kube-rs](https://github.com/clux/kube-rs) |
 | Rust                 | [github.com/ynqa/kubernetes-rust](https://github.com/ynqa/kubernetes-rust) |
-| Scala                | [github.com/doriordan/skuber](https://github.com/doriordan/skuber) |
+| Scala                | [github.com/hagay3/skuber](https://github.com/hagay3/skuber) |
 | Scala                | [github.com/joan38/kubernetes-client](https://github.com/joan38/kubernetes-client) |
 | Swift                | [github.com/swiftkube/client](https://github.com/swiftkube/client) |
 | DotNet               | [github.com/tonnyeremin/kubernetes_gen](https://github.com/tonnyeremin/kubernetes_gen) |
@@ -9,7 +9,7 @@ weight: 40
 <!-- overview -->

 Kubernetes requires PKI certificates for authentication over TLS.
-If you install Kubernetes with [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/), the certificates that your cluster requires are automatically generated.
+If you install Kubernetes with [kubeadm](/docs/reference/setup-tools/kubeadm/), the certificates that your cluster requires are automatically generated.
 You can also generate your own certificates -- for example, to keep your private keys more secure by not storing them on the API server.
 This page explains the certificates that your cluster requires.

@@ -74,7 +74,7 @@ Required certificates:
 | kube-apiserver-kubelet-client | kubernetes-ca             | system:masters | client                                 |                                             |
 | front-proxy-client            | kubernetes-front-proxy-ca |                | client                                 |                                             |

-[1]: any other IP or DNS name you contact your cluster on (as used by [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/)
+[1]: any other IP or DNS name you contact your cluster on (as used by [kubeadm](/docs/reference/setup-tools/kubeadm/)
 the load balancer stable IP and/or DNS name, `kubernetes`, `kubernetes.default`, `kubernetes.default.svc`,
 `kubernetes.default.svc.cluster`, `kubernetes.default.svc.cluster.local`)

@@ -100,7 +100,7 @@ For kubeadm users only:

 ### Certificate paths

-Certificates should be placed in a recommended path (as used by [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/)).
+Certificates should be placed in a recommended path (as used by [kubeadm](/docs/reference/setup-tools/kubeadm/)).
 Paths should be specified using the given argument regardless of location.

 | Default CN                   | recommended key path         | recommended cert path       | command        | key argument                 | cert argument                             |
@@ -59,7 +59,7 @@ When nodes start up, the kubelet on each node automatically adds
 {{< glossary_tooltip text="labels" term_id="label" >}} to the Node object
 that represents that specific kubelet in the Kubernetes API.
 These labels can include
-[zone information](/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesiozone).
+[zone information](/docs/reference/labels-annotations-taints/#topologykubernetesiozone).

 If your cluster spans multiple zones or regions, you can use node labels
 in conjunction with
@@ -63,7 +63,7 @@ configuration, or reinstall it using automation.

 ### containerd

-This section contains the necessary steps to use `containerd` as CRI runtime.
+This section contains the necessary steps to use containerd as CRI runtime.

 Use the following commands to install Containerd on your system:

@@ -92,161 +92,62 @@ sudo sysctl --system
 Install containerd:

 {{< tabs name="tab-cri-containerd-installation" >}}
-{{% tab name="Ubuntu 16.04" %}}
+{{% tab name="Linux" %}}

-```shell
-# (Install containerd)
-## Set up the repository
-### Install packages to allow apt to use a repository over HTTPS
-sudo apt-get update && sudo apt-get install -y apt-transport-https ca-certificates curl software-properties-common
-```
+1. Install the `containerd.io` package from the official Docker repositories. Instructions for setting up the Docker repository for your respective Linux distribution and installing the `containerd.io` package can be found at [Install Docker Engine](https://docs.docker.com/engine/install/#server).

-```shell
-## Add Docker's official GPG key
-curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key --keyring /etc/apt/trusted.gpg.d/docker.gpg add -
-```
+2. Configure containerd:

-```shell
-## Add Docker apt repository.
-sudo add-apt-repository \
-    "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
-    $(lsb_release -cs) \
-    stable"
-```
+   ```shell
+   sudo mkdir -p /etc/containerd
+   containerd config default | sudo tee /etc/containerd/config.toml
+   ```

-```shell
-## Install containerd
-sudo apt-get update && sudo apt-get install -y containerd.io
-```
+3. Restart containerd:

-```shell
-# Configure containerd
-sudo mkdir -p /etc/containerd
-containerd config default | sudo tee /etc/containerd/config.toml
-```
+   ```shell
+   sudo systemctl restart containerd
+   ```

-```shell
-# Restart containerd
-sudo systemctl restart containerd
-```
-{{% /tab %}}
-{{% tab name="Ubuntu 18.04/20.04" %}}
-
-```shell
-# (Install containerd)
-sudo apt-get update && sudo apt-get install -y containerd
-```
-
-```shell
-# Configure containerd
-sudo mkdir -p /etc/containerd
-containerd config default | sudo tee /etc/containerd/config.toml
-```
-
-```shell
-# Restart containerd
-sudo systemctl restart containerd
-```
-{{% /tab %}}
-{{% tab name="Debian 9+" %}}
-
-```shell
-# (Install containerd)
-## Set up the repository
-### Install packages to allow apt to use a repository over HTTPS
-sudo apt-get update && sudo apt-get install -y apt-transport-https ca-certificates curl software-properties-common
-```
-
-```shell
-## Add Docker's official GPG key
-curl -fsSL https://download.docker.com/linux/debian/gpg | sudo apt-key --keyring /etc/apt/trusted.gpg.d/docker.gpg add -
-```
-
-```shell
-## Add Docker apt repository.
-sudo add-apt-repository \
-   "deb [arch=amd64] https://download.docker.com/linux/debian \
-   $(lsb_release -cs) \
-   stable"
-```
-
-```shell
-## Install containerd
-sudo apt-get update && sudo apt-get install -y containerd.io
-```
-
-```shell
-# Set default containerd configuration
-sudo mkdir -p /etc/containerd
-containerd config default | sudo tee /etc/containerd/config.toml
-```
-
-```shell
-# Restart containerd
-sudo systemctl restart containerd
-```
-{{% /tab %}}
-{{% tab name="CentOS/RHEL 7.4+" %}}
-
-```shell
-# (Install containerd)
-## Set up the repository
-### Install required packages
-sudo yum install -y yum-utils device-mapper-persistent-data lvm2
-```
-
-```shell
-## Add docker repository
-sudo yum-config-manager \
-    --add-repo \
-    https://download.docker.com/linux/centos/docker-ce.repo
-```
-
-```shell
-## Install containerd
-sudo yum update -y && sudo yum install -y containerd.io
-```
-
-```shell
-## Configure containerd
-sudo mkdir -p /etc/containerd
-containerd config default | sudo tee /etc/containerd/config.toml
-```
-
-```shell
-# Restart containerd
-sudo systemctl restart containerd
-```
 {{% /tab %}}
 {{% tab name="Windows (PowerShell)" %}}
-```powershell
-# (Install containerd)
-# download containerd
-cmd /c curl -OL https://github.com/containerd/containerd/releases/download/v1.4.1/containerd-1.4.1-windows-amd64.tar.gz
-cmd /c tar xvf .\containerd-1.4.1-windows-amd64.tar.gz
-```

-```powershell
-# extract and configure
-Copy-Item -Path ".\bin\" -Destination "$Env:ProgramFiles\containerd" -Recurse -Force
-cd $Env:ProgramFiles\containerd\
-.\containerd.exe config default | Out-File config.toml -Encoding ascii
+Start a Powershell session, set `$Version` to the desired version (ex: `$Version=1.4.3`), and then run the following commands:

-# review the configuration. depending on setup you may want to adjust:
-# - the sandbox_image (kubernetes pause image)
-# - cni bin_dir and conf_dir locations
-Get-Content config.toml
-```
+1. Download containerd:
+
+   ```powershell
+   curl.exe -L https://github.com/containerd/containerd/releases/download/v$Version/containerd-$Version-windows-amd64.tar.gz -o containerd-windows-amd64.tar.gz
+   tar.exe xvf .\containerd-windows-amd64.tar.gz
+   ```
+
+2. Extract and configure:
+
+   ```powershell
+   Copy-Item -Path ".\bin\" -Destination "$Env:ProgramFiles\containerd" -Recurse -Force
+   cd $Env:ProgramFiles\containerd\
+   .\containerd.exe config default | Out-File config.toml -Encoding ascii
+
+   # Review the configuration. Depending on setup you may want to adjust:
+   # - the sandbox_image (Kubernetes pause image)
+   # - cni bin_dir and conf_dir locations
+   Get-Content config.toml
+
+   # (Optional - but highly recommended) Exclude containerd from Windows Defender Scans
+   Add-MpPreference -ExclusionProcess "$Env:ProgramFiles\containerd\containerd.exe"
+   ```
+
+3. Start containerd:
+
+   ```powershell
+   .\containerd.exe --register-service
+   Start-Service containerd
+   ```

-```powershell
-# start containerd
-.\containerd.exe --register-service
-Start-Service containerd
-```
 {{% /tab %}}
 {{< /tabs >}}

-#### systemd {#containerd-systemd}
+#### Using the `systemd` cgroup driver {#containerd-systemd}

 To use the `systemd` cgroup driver in `/etc/containerd/config.toml` with `runc`, set

@@ -257,6 +158,12 @@ To use the `systemd` cgroup driver in `/etc/containerd/config.toml` with `runc`,
    SystemdCgroup = true
 ```

+If you apply this change make sure to restart containerd again:
+
+```shell
+sudo systemctl restart containerd
+```
+
 When using kubeadm, manually configure the
 [cgroup driver for kubelet](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#configure-cgroup-driver-used-by-kubelet-on-control-plane-node).

@@ -446,138 +353,38 @@ in sync.

 ### Docker

-On each of your nodes, install Docker CE.
+1. On each of your nodes, install the Docker for your Linux distribution as per [Install Docker Engine](https://docs.docker.com/engine/install/#server). You can find the latest validated version of Docker in this [dependencies](https://git.k8s.io/kubernetes/build/dependencies.yaml) file.

-The Kubernetes release notes list which versions of Docker are compatible
-with that version of Kubernetes.
+2. Configure the Docker daemon, in particular to use systemd for the management of the container’s cgroups.

-Use the following commands to install Docker on your system:
+   ```shell
+   sudo mkdir /etc/docker
+   cat <<EOF | sudo tee /etc/docker/daemon.json
+   {
+     "exec-opts": ["native.cgroupdriver=systemd"],
+     "log-driver": "json-file",
+     "log-opts": {
+       "max-size": "100m"
+     },
+     "storage-driver": "overlay2"
+   }
+   EOF
+   ```

-{{< tabs name="tab-cri-docker-installation" >}}
-{{% tab name="Ubuntu 16.04+" %}}
+   {{< note >}}
+   `overlay2` is the preferred storage driver for systems running Linux kernel version 4.0 or higher, or RHEL or CentOS using version 3.10.0-514 and above.
+   {{< /note >}}

-```shell
-# (Install Docker CE)
-## Set up the repository:
-### Install packages to allow apt to use a repository over HTTPS
-sudo apt-get update && sudo apt-get install -y \
-  apt-transport-https ca-certificates curl software-properties-common gnupg2
-```
+3. Restart Docker and enable on boot:

-```shell
-# Add Docker's official GPG key:
-curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key --keyring /etc/apt/trusted.gpg.d/docker.gpg add -
-```
+   ```shell
+   sudo systemctl enable docker
+   sudo systemctl daemon-reload
+   sudo systemctl restart docker
+   ```

-```shell
-# Add the Docker apt repository:
-sudo add-apt-repository \
-  "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
-  $(lsb_release -cs) \
-  stable"
-```
-
-```shell
-# Install Docker CE
-sudo apt-get update && sudo apt-get install -y \
-  containerd.io=1.2.13-2 \
-  docker-ce=5:19.03.11~3-0~ubuntu-$(lsb_release -cs) \
-  docker-ce-cli=5:19.03.11~3-0~ubuntu-$(lsb_release -cs)
-```
-
-```shell
-## Create /etc/docker
-sudo mkdir /etc/docker
-```
-
-```shell
-# Set up the Docker daemon
-cat <<EOF | sudo tee /etc/docker/daemon.json
-{
-  "exec-opts": ["native.cgroupdriver=systemd"],
-  "log-driver": "json-file",
-  "log-opts": {
-    "max-size": "100m"
-  },
-  "storage-driver": "overlay2"
-}
-EOF
-```
-
-```shell
-# Create /etc/systemd/system/docker.service.d
-sudo mkdir -p /etc/systemd/system/docker.service.d
-```
-
-```shell
-# Restart Docker
-sudo systemctl daemon-reload
-sudo systemctl restart docker
-```
-{{% /tab %}}
-{{% tab name="CentOS/RHEL 7.4+" %}}
-
-```shell
-# (Install Docker CE)
-## Set up the repository
-### Install required packages
-sudo yum install -y yum-utils device-mapper-persistent-data lvm2
-```
-
-```shell
-## Add the Docker repository
-sudo yum-config-manager --add-repo \
-  https://download.docker.com/linux/centos/docker-ce.repo
-```
-
-```shell
-# Install Docker CE
-sudo yum update -y && sudo yum install -y \
-  containerd.io-1.2.13 \
-  docker-ce-19.03.11 \
-  docker-ce-cli-19.03.11
-```
-
-```shell
-## Create /etc/docker
-sudo mkdir /etc/docker
-```
-
-```shell
-# Set up the Docker daemon
-cat <<EOF | sudo tee /etc/docker/daemon.json
-{
-  "exec-opts": ["native.cgroupdriver=systemd"],
-  "log-driver": "json-file",
-  "log-opts": {
-    "max-size": "100m"
-  },
-  "storage-driver": "overlay2",
-  "storage-opts": [
-    "overlay2.override_kernel_check=true"
-  ]
-}
-EOF
-```
-
-```shell
-# Create /etc/systemd/system/docker.service.d
-sudo mkdir -p /etc/systemd/system/docker.service.d
-```
-
-```shell
-# Restart Docker
-sudo systemctl daemon-reload
-sudo systemctl restart docker
-```
-{{% /tab %}}
-{{< /tabs >}}
-
-If you want the `docker` service to start on boot, run the following command:
-
-```shell
-sudo systemctl enable docker
-```
-
-Refer to the [official Docker installation guides](https://docs.docker.com/engine/installation/)
-for more information.
+{{< note >}}
+For more information refer to
+  - [Configure the Docker daemon](https://docs.docker.com/config/daemon/)
+  - [Control Docker with systemd](https://docs.docker.com/config/daemon/systemd/)
+{{< /note >}}
@@ -23,7 +23,7 @@ kops is an automated provisioning system:
 ## {{% heading "prerequisites" %}}


-* You must have [kubectl](/docs/tasks/tools/install-kubectl/) installed.
+* You must have [kubectl](/docs/tasks/tools/) installed.

 * You must [install](https://github.com/kubernetes/kops#installing) `kops` on a 64-bit (AMD64 and Intel 64) device architecture.

@@ -137,7 +137,7 @@ is not supported by kubeadm.

 ### More information

-For more information about `kubeadm init` arguments, see the [kubeadm reference guide](/docs/reference/setup-tools/kubeadm/kubeadm/).
+For more information about `kubeadm init` arguments, see the [kubeadm reference guide](/docs/reference/setup-tools/kubeadm/).

 To configure `kubeadm init` with a configuration file see [Using kubeadm init with a configuration file](/docs/reference/setup-tools/kubeadm/kubeadm-init/#config-file).

@@ -18,14 +18,7 @@ For information how to create a cluster with kubeadm once you have performed thi
 ## {{% heading "prerequisites" %}}


-* One or more machines running one of:
-  - Ubuntu 16.04+
-  - Debian 9+
-  - CentOS 7+
-  - Red Hat Enterprise Linux (RHEL) 7+
-  - Fedora 25+
-  - HypriotOS v1.0.1+
-  - Flatcar Container Linux (tested with 2512.3.0)
+* A compatible Linux host. The Kubernetes project provides generic instructions for Linux distributions based on Debian and Red Hat, and those distributions without a package manager.
 * 2 GB or more of RAM per machine (any less will leave little room for your apps).
 * 2 CPUs or more.
 * Full network connectivity between all machines in the cluster (public or private network is fine).
@@ -122,7 +115,7 @@ The following table lists container runtimes and their associated socket paths:
 {{< table caption = "Container runtimes and their socket paths" >}}
 | Runtime    | Path to Unix domain socket        |
 |------------|-----------------------------------|
-| Docker     | `/var/run/docker.sock`            |
+| Docker     | `/var/run/dockershim.sock`        |
 | containerd | `/run/containerd/containerd.sock` |
 | CRI-O      | `/var/run/crio/crio.sock`         |
 {{< /table >}}
@@ -167,7 +160,7 @@ kubelet and the control plane is supported, but the kubelet version may never ex
 server version. For example, the kubelet running 1.7.0 should be fully compatible with a 1.8.0 API server,
 but not vice versa.

-For information about installing `kubectl`, see [Install and set up kubectl](/docs/tasks/tools/install-kubectl/).
+For information about installing `kubectl`, see [Install and set up kubectl](/docs/tasks/tools/).

 {{< warning >}}
 These instructions exclude all Kubernetes packages from any system upgrades.
@@ -181,19 +174,37 @@ For more information on version skews, see:
 * Kubeadm-specific [version skew policy](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#version-skew-policy)

 {{< tabs name="k8s_install" >}}
-{{% tab name="Ubuntu, Debian or HypriotOS" %}}
-```bash
-sudo apt-get update && sudo apt-get install -y apt-transport-https curl
-curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
-cat <<EOF | sudo tee /etc/apt/sources.list.d/kubernetes.list
-deb https://apt.kubernetes.io/ kubernetes-xenial main
-EOF
-sudo apt-get update
-sudo apt-get install -y kubelet kubeadm kubectl
-sudo apt-mark hold kubelet kubeadm kubectl
-```
+{{% tab name="Debian-based distributions" %}}
+
+1. Update the `apt` package index and install packages needed to use the Kubernetes `apt` repository:
+
+   ```shell
+   sudo apt-get update
+   sudo apt-get install -y apt-transport-https ca-certificates curl
+   ```
+
+2. Download the Google Cloud public signing key:
+
+   ```shell
+   sudo curl -fsSLo /usr/share/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.gpg
+   ```
+
+3. Add the Kubernetes `apt` repository:
+
+   ```shell
+   echo "deb [signed-by=/usr/share/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list
+   ```
+
+4. Update `apt` package index, install kubelet, kubeadm and kubectl, and pin their version:
+
+   ```shell
+   sudo apt-get update
+   sudo apt-get install -y kubelet kubeadm kubectl
+   sudo apt-mark hold kubelet kubeadm kubectl
+   ```
+
 {{% /tab %}}
-{{% tab name="CentOS, RHEL or Fedora" %}}
+{{% tab name="Red Hat-based distributions" %}}
 ```bash
 cat <<EOF | sudo tee /etc/yum.repos.d/kubernetes.repo
 [kubernetes]
@@ -224,7 +235,7 @@ sudo systemctl enable --now kubelet
  - You can leave SELinux enabled if you know how to configure it but it may require settings that are not supported by kubeadm.

 {{% /tab %}}
-{{% tab name="Fedora CoreOS or Flatcar Container Linux" %}}
+{{% tab name="Without a package manager" %}}
 Install CNI plugins (required for most pod network):

 ```bash
@@ -138,10 +138,10 @@ Right after `kubeadm init` there should not be any pods in these states.

 - If there are pods in one of these states _right after_ `kubeadm init`, please open an
  issue in the kubeadm repo. `coredns` (or `kube-dns`) should be in the `Pending` state
-  until you have deployed the network solution.
+  until you have deployed the network add-on.
 - If you see Pods in the `RunContainerError`, `CrashLoopBackOff` or `Error` state
-  after deploying the network solution and nothing happens to `coredns` (or `kube-dns`),
-  it's very likely that the Pod Network solution that you installed is somehow broken.
+  after deploying the network add-on and nothing happens to `coredns` (or `kube-dns`),
+  it's very likely that the Pod Network add-on that you installed is somehow broken.
  You might have to grant it more RBAC privileges or use a newer version. Please file
  an issue in the Pod Network providers' issue tracker and get the issue triaged there.
 - If you install a version of Docker older than 1.12.1, remove the `MountFlags=slave` option
@@ -152,14 +152,14 @@ Right after `kubeadm init` there should not be any pods in these states.
 ## `coredns` (or `kube-dns`) is stuck in the `Pending` state

 This is **expected** and part of the design. kubeadm is network provider-agnostic, so the admin
-should [install the pod network solution](/docs/concepts/cluster-administration/addons/)
+should [install the pod network add-on](/docs/concepts/cluster-administration/addons/)
 of choice. You have to install a Pod Network
 before CoreDNS may be deployed fully. Hence the `Pending` state before the network is set up.

 ## `HostPort` services do not work

 The `HostPort` and `HostIP` functionality is available depending on your Pod Network
-provider. Please contact the author of the Pod Network solution to find out whether
+provider. Please contact the author of the Pod Network add-on to find out whether
 `HostPort` and `HostIP` functionality are available.

 Calico, Canal, and Flannel CNI providers are verified to support HostPort.
@@ -23,7 +23,7 @@ Kubespray is a composition of [Ansible](https://docs.ansible.com/) playbooks, [i
 * continuous integration tests

 To choose a tool which best fits your use case, read [this comparison](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/comparisons.md) to
-[kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) and [kops](/docs/setup/production-environment/tools/kops/).
+[kubeadm](/docs/reference/setup-tools/kubeadm/) and [kops](/docs/setup/production-environment/tools/kops/).

 <!-- body -->

@@ -221,7 +221,7 @@ On Windows, you can use the following settings to configure Services and load ba

 #### IPv4/IPv6 dual-stack

-You can enable IPv4/IPv6 dual-stack networking for `l2bridge` networks using the `IPv6DualStack` [feature gate](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/). See [enable IPv4/IPv6 dual stack](/docs/concepts/services-networking/dual-stack#enable-ipv4ipv6-dual-stack) for more details.
+You can enable IPv4/IPv6 dual-stack networking for `l2bridge` networks using the `IPv6DualStack` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/). See [enable IPv4/IPv6 dual stack](/docs/concepts/services-networking/dual-stack#enable-ipv4ipv6-dual-stack) for more details.

 {{< note >}}
 On Windows, using IPv6 with Kubernetes require Windows Server, version 2004 (kernel version 10.0.19041.610) or later.
@@ -237,7 +237,7 @@ Overlay (VXLAN) networks on Windows do not support dual-stack networking today.

 Windows is only supported as a worker node in the Kubernetes architecture and component matrix. This means that a Kubernetes cluster must always include Linux master nodes, zero or more Linux worker nodes, and zero or more Windows worker nodes.

-#### Compute {compute-limitations}
+#### Compute {#compute-limitations}

 ##### Resource management and process isolation

@@ -297,7 +297,7 @@ As a result, the following storage functionality is not supported on Windows nod
 * NFS based storage/volume support
 * Expanding the mounted volume (resizefs)

-#### Networking {networking-limitations}
+#### Networking {#networking-limitations}

 Windows Container Networking differs in some important ways from Linux networking. The [Microsoft documentation for Windows Container Networking](https://docs.microsoft.com/en-us/virtualization/windowscontainers/container-networking/architecture) contains additional details and background.

@@ -1906,7 +1906,7 @@ filename | sha512 hash
 - Promote SupportNodePidsLimit to GA to provide node to pod pid isolation
  Promote SupportPodPidsLimit to GA to provide ability to limit pids per pod ([#94140](https://github.com/kubernetes/kubernetes/pull/94140), [@derekwaynecarr](https://github.com/derekwaynecarr)) [SIG Node and Testing]
 - Rename pod_preemption_metrics to preemption_metrics. ([#93256](https://github.com/kubernetes/kubernetes/pull/93256), [@ahg-g](https://github.com/ahg-g)) [SIG Instrumentation and Scheduling]
- Server-side apply behavior has been regularized in the case where a field is removed from the applied configuration. Removed fields which have no other owners are deleted from the live object, or reset to their default value if they have one. Safe ownership transfers, such as the transfer of a `replicas` field from a user to an HPA without resetting to the default value are documented in [Transferring Ownership](https://kubernetes.io/docs/reference/using-api/api-concepts/&#35;transferring-ownership) ([#92661](https://github.com/kubernetes/kubernetes/pull/92661), [@jpbetz](https://github.com/jpbetz)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation and Testing]
+- Server-side apply behavior has been regularized in the case where a field is removed from the applied configuration. Removed fields which have no other owners are deleted from the live object, or reset to their default value if they have one. Safe ownership transfers, such as the transfer of a `replicas` field from a user to an HPA without resetting to the default value are documented in [Transferring Ownership](/docs/reference/using-api/server-side-apply/#transferring-ownership) ([#92661](https://github.com/kubernetes/kubernetes/pull/92661), [@jpbetz](https://github.com/jpbetz)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation and Testing]
 - Set CSIMigrationvSphere feature gates to beta.
  Users should enable CSIMigration + CSIMigrationvSphere features and install the vSphere CSI Driver (https://github.com/kubernetes-sigs/vsphere-csi-driver) to move workload from the in-tree vSphere plugin "kubernetes.io/vsphere-volume" to vSphere CSI Driver.
  
@@ -192,7 +192,7 @@ func main() {
 }
 ```

-If the application is deployed as a Pod in the cluster, see [Accessing the API from within a Pod](#accessing-the-api-from-within-a-pod).
+If the application is deployed as a Pod in the cluster, see [Accessing the API from within a Pod](/docs/tasks/access-application-cluster/access-cluster/#accessing-the-api-from-a-pod).

 #### Python client

@@ -352,102 +352,6 @@ exampleWithKubeConfig = do
        >>= print
 ```

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

-### Accessing the API from within a Pod
-
-When accessing the API from within a Pod, locating and authenticating
-to the API server are slightly different to the external client case described above.
-
-The easiest way to use the Kubernetes API from a Pod is to use
-one of the official [client libraries](/docs/reference/using-api/client-libraries/). These
-libraries can automatically discover the API server and authenticate.
-
-#### Using Official Client Libraries
-
-From within a Pod, the recommended ways to connect to the Kubernetes API are:
-
-  - For a Go client, use the official [Go client library](https://github.com/kubernetes/client-go/).
-    The `rest.InClusterConfig()` function handles API host discovery and authentication automatically.
-    See [an example here](https://git.k8s.io/client-go/examples/in-cluster-client-configuration/main.go).
-
-  - For a Python client, use the official [Python client library](https://github.com/kubernetes-client/python/).
-    The `config.load_incluster_config()` function handles API host discovery and authentication automatically.
-    See [an example here](https://github.com/kubernetes-client/python/blob/master/examples/in_cluster_config.py).
-
-  - There are a number of other libraries available, please refer to the [Client Libraries](/docs/reference/using-api/client-libraries/) page.
-
-In each case, the service account credentials of the Pod are used to communicate
-securely with the API server.
-
-#### Directly accessing the REST API
-
-While running in a Pod, the Kubernetes apiserver is accessible via a Service named
-`kubernetes` in the `default` namespace. Therefore, Pods can use the
-`kubernetes.default.svc` hostname to query the API server. Official client libraries
-do this automatically.
-
-The recommended way to authenticate to the API server is with a
-[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`.
-
-If available, a certificate bundle is placed into the filesystem tree of each
-container at `/var/run/secrets/kubernetes.io/serviceaccount/ca.crt`, and should be
-used to verify the serving certificate of the API server.
-
-Finally, the default namespace to be used for namespaced API operations is placed in a file
-at `/var/run/secrets/kubernetes.io/serviceaccount/namespace` in each container.
-
-#### Using kubectl proxy
-
-If you would like to query the API without an official client library, you can run `kubectl proxy`
-as the [command](/docs/tasks/inject-data-application/define-command-argument-container/)
-of a new sidecar container in the Pod. This way, `kubectl proxy` will authenticate
-to the API and expose it on the `localhost` interface of the Pod, so that other containers
-in the Pod can use it directly.
-
-#### Without using a proxy
-
-It is possible to avoid using the kubectl proxy by passing the authentication token
-directly to the API server.  The internal certificate secures the connection.
-
-```shell
-# Point to the internal API server hostname
-APISERVER=https://kubernetes.default.svc
-
-# Path to ServiceAccount token
-SERVICEACCOUNT=/var/run/secrets/kubernetes.io/serviceaccount
-
-# Read this Pod's namespace
-NAMESPACE=$(cat ${SERVICEACCOUNT}/namespace)
-
-# Read the ServiceAccount bearer token
-TOKEN=$(cat ${SERVICEACCOUNT}/token)
-
-# Reference the internal certificate authority (CA)
-CACERT=${SERVICEACCOUNT}/ca.crt
-
-# Explore the API with TOKEN
-curl --cacert ${CACERT} --header "Authorization: Bearer ${TOKEN}" -X GET ${APISERVER}/api
-```
-
-The output will be similar to this:
-
-```json
-{
-  "kind": "APIVersions",
-  "versions": [
-    "v1"
-  ],
-  "serverAddressByClientCIDRs": [
-    {
-      "clientCIDR": "0.0.0.0/0",
-      "serverAddress": "10.0.1.149:443"
-    }
-  ]
-}
-```
-
-
-
+* [Accessing the Kubernetes API from a Pod](/docs/tasks/run-application/access-api-from-pod/)
@@ -0,0 +1,252 @@
+---
+title: Certificates
+content_type: task
+weight: 20
+---
+
+
+<!-- overview -->
+
+When using client certificate authentication, you can generate certificates
+manually through `easyrsa`, `openssl` or `cfssl`.
+
+
+
+
+<!-- body -->
+
+### easyrsa
+
+**easyrsa** can manually generate certificates for your cluster.
+
+1.  Download, unpack, and initialize the patched version of easyrsa3.
+
+        curl -LO https://storage.googleapis.com/kubernetes-release/easy-rsa/easy-rsa.tar.gz
+        tar xzf easy-rsa.tar.gz
+        cd easy-rsa-master/easyrsa3
+        ./easyrsa init-pki
+1.  Generate a new certificate authority (CA). `--batch` sets automatic mode;
+    `--req-cn` specifies the Common Name (CN) for the CA's new root certificate.
+
+        ./easyrsa --batch "--req-cn=${MASTER_IP}@`date +%s`" build-ca nopass
+1.  Generate server certificate and key.
+    The argument `--subject-alt-name` sets the possible IPs and DNS names the API server will
+    be accessed with. The `MASTER_CLUSTER_IP` is usually the first IP from the service CIDR
+    that is specified as the `--service-cluster-ip-range` argument for both the API server and
+    the controller manager component. The argument `--days` is used to set the number of days
+    after which the certificate expires.
+    The sample below also assumes that you are using `cluster.local` as the default
+    DNS domain name.
+
+        ./easyrsa --subject-alt-name="IP:${MASTER_IP},"\
+        "IP:${MASTER_CLUSTER_IP},"\
+        "DNS:kubernetes,"\
+        "DNS:kubernetes.default,"\
+        "DNS:kubernetes.default.svc,"\
+        "DNS:kubernetes.default.svc.cluster,"\
+        "DNS:kubernetes.default.svc.cluster.local" \
+        --days=10000 \
+        build-server-full server nopass
+1.  Copy `pki/ca.crt`, `pki/issued/server.crt`, and `pki/private/server.key` to your directory.
+1.  Fill in and add the following parameters into the API server start parameters:
+
+        --client-ca-file=/yourdirectory/ca.crt
+        --tls-cert-file=/yourdirectory/server.crt
+        --tls-private-key-file=/yourdirectory/server.key
+
+### openssl
+
+**openssl** can manually generate certificates for your cluster.
+
+1.  Generate a ca.key with 2048bit:
+
+        openssl genrsa -out ca.key 2048
+1.  According to the ca.key generate a ca.crt (use -days to set the certificate effective time):
+
+        openssl req -x509 -new -nodes -key ca.key -subj "/CN=${MASTER_IP}" -days 10000 -out ca.crt
+1.  Generate a server.key with 2048bit:
+
+        openssl genrsa -out server.key 2048
+1.  Create a config file for generating a Certificate Signing Request (CSR).
+    Be sure to substitute the values marked with angle brackets (e.g. `<MASTER_IP>`)
+    with real values before saving this to a file (e.g. `csr.conf`).
+    Note that the value for `MASTER_CLUSTER_IP` is the service cluster IP for the
+    API server as described in previous subsection.
+    The sample below also assumes that you are using `cluster.local` as the default
+    DNS domain name.
+
+        [ req ]
+        default_bits = 2048
+        prompt = no
+        default_md = sha256
+        req_extensions = req_ext
+        distinguished_name = dn
+
+        [ dn ]
+        C = <country>
+        ST = <state>
+        L = <city>
+        O = <organization>
+        OU = <organization unit>
+        CN = <MASTER_IP>
+
+        [ req_ext ]
+        subjectAltName = @alt_names
+
+        [ alt_names ]
+        DNS.1 = kubernetes
+        DNS.2 = kubernetes.default
+        DNS.3 = kubernetes.default.svc
+        DNS.4 = kubernetes.default.svc.cluster
+        DNS.5 = kubernetes.default.svc.cluster.local
+        IP.1 = <MASTER_IP>
+        IP.2 = <MASTER_CLUSTER_IP>
+
+        [ v3_ext ]
+        authorityKeyIdentifier=keyid,issuer:always
+        basicConstraints=CA:FALSE
+        keyUsage=keyEncipherment,dataEncipherment
+        extendedKeyUsage=serverAuth,clientAuth
+        subjectAltName=@alt_names
+1.  Generate the certificate signing request based on the config file:
+
+        openssl req -new -key server.key -out server.csr -config csr.conf
+1.  Generate the server certificate using the ca.key, ca.crt and server.csr:
+
+        openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \
+        -CAcreateserial -out server.crt -days 10000 \
+        -extensions v3_ext -extfile csr.conf
+1.  View the certificate:
+
+        openssl x509  -noout -text -in ./server.crt
+
+Finally, add the same parameters into the API server start parameters.
+
+### cfssl
+
+**cfssl** is another tool for certificate generation.
+
+1.  Download, unpack and prepare the command line tools as shown below.
+    Note that you may need to adapt the sample commands based on the hardware
+    architecture and cfssl version you are using.
+
+        curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssl_1.5.0_linux_amd64 -o cfssl
+        chmod +x cfssl
+        curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssljson_1.5.0_linux_amd64 -o cfssljson
+        chmod +x cfssljson
+        curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssl-certinfo_1.5.0_linux_amd64 -o cfssl-certinfo
+        chmod +x cfssl-certinfo
+1.  Create a directory to hold the artifacts and initialize cfssl:
+
+        mkdir cert
+        cd cert
+        ../cfssl print-defaults config > config.json
+        ../cfssl print-defaults csr > csr.json
+1.  Create a JSON config file for generating the CA file, for example, `ca-config.json`:
+
+        {
+          "signing": {
+            "default": {
+              "expiry": "8760h"
+            },
+            "profiles": {
+              "kubernetes": {
+                "usages": [
+                  "signing",
+                  "key encipherment",
+                  "server auth",
+                  "client auth"
+                ],
+                "expiry": "8760h"
+              }
+            }
+          }
+        }
+1.  Create a JSON config file for CA certificate signing request (CSR), for example,
+    `ca-csr.json`. Be sure to replace the values marked with angle brackets with
+    real values you want to use.
+
+        {
+          "CN": "kubernetes",
+          "key": {
+            "algo": "rsa",
+            "size": 2048
+          },
+          "names":[{
+            "C": "<country>",
+            "ST": "<state>",
+            "L": "<city>",
+            "O": "<organization>",
+            "OU": "<organization unit>"
+          }]
+        }
+1.  Generate CA key (`ca-key.pem`) and certificate (`ca.pem`):
+
+        ../cfssl gencert -initca ca-csr.json | ../cfssljson -bare ca
+1.  Create a JSON config file for generating keys and certificates for the API
+    server, for example, `server-csr.json`. Be sure to replace the values in angle brackets with
+    real values you want to use. The `MASTER_CLUSTER_IP` is the service cluster
+    IP for the API server as described in previous subsection.
+    The sample below also assumes that you are using `cluster.local` as the default
+    DNS domain name.
+
+        {
+          "CN": "kubernetes",
+          "hosts": [
+            "127.0.0.1",
+            "<MASTER_IP>",
+            "<MASTER_CLUSTER_IP>",
+            "kubernetes",
+            "kubernetes.default",
+            "kubernetes.default.svc",
+            "kubernetes.default.svc.cluster",
+            "kubernetes.default.svc.cluster.local"
+          ],
+          "key": {
+            "algo": "rsa",
+            "size": 2048
+          },
+          "names": [{
+            "C": "<country>",
+            "ST": "<state>",
+            "L": "<city>",
+            "O": "<organization>",
+            "OU": "<organization unit>"
+          }]
+        }
+1.  Generate the key and certificate for the API server, which are by default
+    saved into file `server-key.pem` and `server.pem` respectively:
+
+        ../cfssl gencert -ca=ca.pem -ca-key=ca-key.pem \
+        --config=ca-config.json -profile=kubernetes \
+        server-csr.json | ../cfssljson -bare server
+
+
+## Distributing Self-Signed CA Certificate
+
+A client node may refuse to recognize a self-signed CA certificate as valid.
+For a non-production deployment, or for a deployment that runs behind a company
+firewall, you can distribute a self-signed CA certificate to all clients and
+refresh the local list for valid certificates.
+
+On each client, perform the following operations:
+
+```bash
+sudo cp ca.crt /usr/local/share/ca-certificates/kubernetes.crt
+sudo update-ca-certificates
+```
+
+```
+Updating certificates in /etc/ssl/certs...
+1 added, 0 removed; done.
+Running hooks in /etc/ca-certificates/update.d....
+done.
+```
+
+## Certificates API
+
+You can use the `certificates.k8s.io` API to provision
+x509 certificates to use for authentication as documented
+[here](/docs/tasks/tls/managing-tls-in-a-cluster).
+
+
@@ -70,7 +70,7 @@ for details about addon manager and how to disable individual addons.

 1. Mark a StorageClass as default:

-      Similarly to the previous step, you need to add/set the annotation
+      Similar to the previous step, you need to add/set the annotation
      `storageclass.kubernetes.io/is-default-class=true`.

      ```bash
@@ -34,7 +34,7 @@ If your cluster was deployed using the `kubeadm` tool, refer to
 for detailed information on how to upgrade the cluster.

 Once you have upgraded the cluster, remember to
-[install the latest version of `kubectl`](/docs/tasks/tools/install-kubectl/).
+[install the latest version of `kubectl`](/docs/tasks/tools/).

 ### Manual deployments

@@ -52,7 +52,7 @@ You should manually update the control plane following this sequence:
 - cloud controller manager, if you use one

 At this point you should
-[install the latest version of `kubectl`](/docs/tasks/tools/install-kubectl/).
+[install the latest version of `kubectl`](/docs/tasks/tools/).

 For each node in your cluster, [drain](/docs/tasks/administer-cluster/safely-drain-node/)
 that node and then either replace it with a new node that uses the {{< skew latestVersion >}}
@@ -25,6 +25,12 @@ kube-dns.

 {{< codenew file="admin/dns/dnsutils.yaml" >}}

+{{< note >}}
+This example creates a pod in the `default` namespace. DNS name resolution for 
+services depends on the namespace of the pod. For more information, review
+[DNS for Services and Pods](/docs/concepts/services-networking/dns-pod-service/#what-things-get-dns-names). 
+{{< /note >}}
+
 Use that manifest to create a Pod:

 ```shell
@@ -247,6 +253,27 @@ linux/amd64, go1.10.3, 2e322f6
 172.17.0.18:41675 - [07/Sep/2018:15:29:11 +0000] 59925 "A IN kubernetes.default.svc.cluster.local. udp 54 false 512" NOERROR qr,aa,rd,ra 106 0.000066649s
 ```

+### Are you in the right namespace for the service?
+
+DNS queries that don't specify a namespace are limited to the pod's 
+namespace. 
+
+If the namespace of the pod and service differ, the DNS query must include 
+the namespace of the service.
+
+This query is limited to the pod's namespace:
+```shell
+kubectl exec -i -t dnsutils -- nslookup <service-name>
+```
+
+This query specifies the namespace:
+```shell
+kubectl exec -i -t dnsutils -- nslookup <service-name>.<namespace>
+```
+
+To learn more about name resolution, see 
+[DNS for Services and Pods](/docs/concepts/services-networking/dns-pod-service/#what-things-get-dns-names). 
+
 ## Known issues

 Some Linux distributions (e.g. Ubuntu) use a local DNS resolver by default (systemd-resolved).
@@ -170,36 +170,7 @@ controllerManager:

 ### Create certificate signing requests (CSR)

-You can create the certificate signing requests for the Kubernetes certificates API with `kubeadm certs renew --use-api`.
-
-If you set up an external signer such as [cert-manager](https://github.com/jetstack/cert-manager), certificate signing requests (CSRs) are automatically approved.
-Otherwise, you must manually approve certificates with the [`kubectl certificate`](/docs/setup/best-practices/certificates/) command.
-The following kubeadm command outputs the name of the certificate to approve, then blocks and waits for approval to occur:
-
-```shell
-sudo kubeadm certs renew apiserver --use-api &
-```
-The output is similar to this:
-```
-[1] 2890
-[certs] certificate request "kubeadm-cert-kube-apiserver-ld526" created
-```
-
-### Approve certificate signing requests (CSR)
-
-If you set up an external signer, certificate signing requests (CSRs) are automatically approved.
-
-Otherwise, you must manually approve certificates with the [`kubectl certificate`](/docs/setup/best-practices/certificates/) command. e.g.
-
-```shell
-kubectl certificate approve kubeadm-cert-kube-apiserver-ld526
-```
-The output is similar to this:
-```shell
-certificatesigningrequest.certificates.k8s.io/kubeadm-cert-kube-apiserver-ld526 approved
-```
-
-You can view a list of pending certificates with `kubectl get csr`.
+See [Create CertificateSigningRequest](https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/#create-certificatesigningrequest) for creating CSRs with the Kubernetes API.

 ## Renew certificates with external CA

@@ -125,10 +125,10 @@ kubectl get secret db-user-pass -o jsonpath='{.data}'
 The output is similar to:

 ```json
-{"password.txt":"MWYyZDFlMmU2N2Rm","username.txt":"YWRtaW4="}
+{"password":"MWYyZDFlMmU2N2Rm","username":"YWRtaW4="}
 ```

-Now you can decode the `password.txt` data:
+Now you can decode the `password` data:

 ```shell
 echo 'MWYyZDFlMmU2N2Rm' | base64 --decode
@@ -92,7 +92,7 @@ kubectl describe secrets/db-user-pass-96mffmfh4k
 The output is similar to:

 ```
-Name:            db-user-pass
+Name:            db-user-pass-96mffmfh4k
 Namespace:       default
 Labels:          <none>
 Annotations:     <none>
@@ -293,6 +293,10 @@ Services.
 Readiness probes runs on the container during its whole lifecycle.
 {{< /note >}}

+{{< caution >}}
+Liveness probes *do not* wait for readiness probes to succeed. If you want to wait before executing a liveness probe you should use initialDelaySeconds or a startupProbe.
+{{< /caution >}}
+
 Readiness probes are configured similarly to liveness probes. The only difference
 is that you use the `readinessProbe` field instead of the `livenessProbe` field.

@@ -99,7 +99,7 @@ kubectl run ephemeral-demo --image=k8s.gcr.io/pause:3.1 --restart=Never
 ```

 The examples in this section use the `pause` container image because it does not
-contain userland debugging utilities, but this method works with all container
+contain debugging utilities, but this method works with all container
 images.

 If you attempt to use `kubectl exec` to create a shell you will see an error
@@ -202,4 +202,7 @@ verify that the pods were scheduled by the desired schedulers.
 ```shell
 kubectl get events
 ```
+You can also use a [custom scheduler configuration](/docs/reference/scheduling/config/#multiple-profiles)
+or a custom container image for the cluster's main scheduler by modifying its static pod manifest
+on the relevant control plane nodes.

@@ -1129,8 +1129,6 @@ resources that have the scale subresource enabled.

 ### Categories

-{{< feature-state state="beta" for_k8s_version="v1.10" >}}
-
 Categories is a list of grouped resources the custom resource belongs to (eg. `all`).
 You can use `kubectl get <category-name>` to list the resources belonging to the category.

@@ -70,8 +70,9 @@ override any environment variables specified in the container image.
 {{< /note >}}

 {{< note >}}
-The environment variables can reference each other, and cycles are possible,
-pay attention to the order before using
+Environment variables may reference each other, however ordering is important.
+Variables making use of others defined in the same context must come later in
+the list. Similarly, avoid circular references.
 {{< /note >}}

 ## Using environment variables inside of your config
@@ -16,7 +16,7 @@ preview of what changes `apply` will make.
 ## {{% heading "prerequisites" %}}


-Install [`kubectl`](/docs/tasks/tools/install-kubectl/).
+Install [`kubectl`](/docs/tasks/tools/).

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

@@ -12,7 +12,7 @@ explains how those commands are organized and how to use them to manage live obj

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

-Install [`kubectl`](/docs/tasks/tools/install-kubectl/).
+Install [`kubectl`](/docs/tasks/tools/).

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

@@ -13,7 +13,7 @@ This document explains how to define and manage objects using configuration file
 ## {{% heading "prerequisites" %}}


-Install [`kubectl`](/docs/tasks/tools/install-kubectl/).
+Install [`kubectl`](/docs/tasks/tools/).

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

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

 [Kustomize](https://github.com/kubernetes-sigs/kustomize) is a standalone tool
 to customize Kubernetes objects
-through a [kustomization file](https://kubernetes-sigs.github.io/kustomize/api-reference/glossary/#kustomization).
+through a [kustomization file](https://kubectl.docs.kubernetes.io/references/kustomize/glossary/#kustomization).

 Since 1.14, Kubectl also
 supports the management of Kubernetes objects using a kustomization file.
@@ -29,7 +29,7 @@ kubectl apply -k <kustomization_directory>
 ## {{% heading "prerequisites" %}}


-Install [`kubectl`](/docs/tasks/tools/install-kubectl/).
+Install [`kubectl`](/docs/tasks/tools/).

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

@@ -0,0 +1,111 @@
+---
+title: Accessing the Kubernetes API from a Pod
+content_type: task
+weight: 120
+---
+
+<!-- overview -->
+
+This guide demonstrates how to access the Kubernetes API from within a pod.
+
+## {{% heading "prerequisites" %}}
+
+{{< include "task-tutorial-prereqs.md" >}}
+
+<!-- steps -->
+
+## Accessing the API from within a Pod
+
+When accessing the API from within a Pod, locating and authenticating
+to the API server are slightly different to the external client case.
+
+The easiest way to use the Kubernetes API from a Pod is to use
+one of the official [client libraries](/docs/reference/using-api/client-libraries/). These
+libraries can automatically discover the API server and authenticate.
+
+### Using Official Client Libraries
+
+From within a Pod, the recommended ways to connect to the Kubernetes API are:
+
+  - For a Go client, use the official [Go client library](https://github.com/kubernetes/client-go/).
+    The `rest.InClusterConfig()` function handles API host discovery and authentication automatically.
+    See [an example here](https://git.k8s.io/client-go/examples/in-cluster-client-configuration/main.go).
+
+  - For a Python client, use the official [Python client library](https://github.com/kubernetes-client/python/).
+    The `config.load_incluster_config()` function handles API host discovery and authentication automatically.
+    See [an example here](https://github.com/kubernetes-client/python/blob/master/examples/in_cluster_config.py).
+
+  - There are a number of other libraries available, please refer to the [Client Libraries](/docs/reference/using-api/client-libraries/) page.
+
+In each case, the service account credentials of the Pod are used to communicate
+securely with the API server.
+
+### Directly accessing the REST API
+
+While running in a Pod, the Kubernetes apiserver is accessible via a Service named
+`kubernetes` in the `default` namespace. Therefore, Pods can use the
+`kubernetes.default.svc` hostname to query the API server. Official client libraries
+do this automatically.
+
+The recommended way to authenticate to the API server is with a
+[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`.
+
+If available, a certificate bundle is placed into the filesystem tree of each
+container at `/var/run/secrets/kubernetes.io/serviceaccount/ca.crt`, and should be
+used to verify the serving certificate of the API server.
+
+Finally, the default namespace to be used for namespaced API operations is placed in a file
+at `/var/run/secrets/kubernetes.io/serviceaccount/namespace` in each container.
+
+### Using kubectl proxy
+
+If you would like to query the API without an official client library, you can run `kubectl proxy`
+as the [command](/docs/tasks/inject-data-application/define-command-argument-container/)
+of a new sidecar container in the Pod. This way, `kubectl proxy` will authenticate
+to the API and expose it on the `localhost` interface of the Pod, so that other containers
+in the Pod can use it directly.
+
+### Without using a proxy
+
+It is possible to avoid using the kubectl proxy by passing the authentication token
+directly to the API server.  The internal certificate secures the connection.
+
+```shell
+# Point to the internal API server hostname
+APISERVER=https://kubernetes.default.svc
+
+# Path to ServiceAccount token
+SERVICEACCOUNT=/var/run/secrets/kubernetes.io/serviceaccount
+
+# Read this Pod's namespace
+NAMESPACE=$(cat ${SERVICEACCOUNT}/namespace)
+
+# Read the ServiceAccount bearer token
+TOKEN=$(cat ${SERVICEACCOUNT}/token)
+
+# Reference the internal certificate authority (CA)
+CACERT=${SERVICEACCOUNT}/ca.crt
+
+# Explore the API with TOKEN
+curl --cacert ${CACERT} --header "Authorization: Bearer ${TOKEN}" -X GET ${APISERVER}/api
+```
+
+The output will be similar to this:
+
+```json
+{
+  "kind": "APIVersions",
+  "versions": [
+    "v1"
+  ],
+  "serverAddressByClientCIDRs": [
+    {
+      "clientCIDR": "0.0.0.0/0",
+      "serverAddress": "10.0.1.149:443"
+    }
+  ]
+}
+```
@@ -19,7 +19,7 @@ Up to date information on this process can be found at the
 * You must have a Kubernetes cluster with cluster DNS enabled.
    * If you are using a cloud-based Kubernetes cluster or {{< glossary_tooltip text="Minikube" term_id="minikube" >}}, you may already have cluster DNS enabled.
    * If you are using `hack/local-up-cluster.sh`, ensure that the `KUBE_ENABLE_CLUSTER_DNS` environment variable is set, then run the install script.
-* [Install and setup kubectl](/docs/tasks/tools/install-kubectl/) v1.7 or higher. Make sure it is configured to connect to the Kubernetes cluster.
+* [Install and setup kubectl](/docs/tasks/tools/) v1.7 or higher. Make sure it is configured to connect to the Kubernetes cluster.
 * Install [Helm](https://helm.sh/) v2.7.0 or newer.
    * Follow the [Helm install instructions](https://helm.sh/docs/intro/install/).
    * If you already have an appropriate version of Helm installed, execute `helm init` to install Tiller, the server-side component of Helm.
@@ -23,7 +23,7 @@ Service Catalog itself can work with any kind of managed service, not just Googl
 * Install [Go 1.6+](https://golang.org/dl/) and set the `GOPATH`.
 * Install the [cfssl](https://github.com/cloudflare/cfssl) tool needed for generating SSL artifacts.
 * Service Catalog requires Kubernetes version 1.7+.
-* [Install and setup kubectl](/docs/tasks/tools/install-kubectl/) so that it is configured to connect to a Kubernetes v1.7+ cluster.
+* [Install and setup kubectl](/docs/tasks/tools/) so that it is configured to connect to a Kubernetes v1.7+ cluster.
 * The kubectl user must be bound to the *cluster-admin* role for it to install Service Catalog. To ensure that this is true, run the following command:

        kubectl create clusterrolebinding cluster-admin-binding --clusterrole=cluster-admin --user=<user-name>
@@ -69,8 +69,9 @@ write that to disk, in the location specified by `--cert-dir`. Then the kubelet
 will use the new certificate to connect to the Kubernetes API.

 As the expiration of the signed certificate approaches, the kubelet will
-automatically issue a new certificate signing request, using the Kubernetes
-API. Again, the controller manager will automatically approve the certificate
+automatically issue a new certificate signing request, using the Kubernetes API. 
+This can happen at any point between 30% and 10% of the time remaining on the 
+certificate. Again, the controller manager will automatically approve the certificate
 request and attach a signed certificate to the certificate signing request. The
 kubelet will retrieve the new signed certificate from the Kubernetes API and
 write that to disk. Then it will update the connections it has to the
@@ -105,8 +105,8 @@ Configurations with a single API server will experience unavailability while the
      * Make sure control plane components logs no TLS errors.

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

   1. Annotate any Daemonsets and Deployments to trigger pod replacement in a safer rolling fashion.
@@ -7,19 +7,20 @@ no_list: true

 ## kubectl

-The Kubernetes command-line tool, `kubectl`, allows you to run commands against
-Kubernetes clusters. You can use `kubectl` to deploy applications, inspect and
-manage cluster resources, and view logs.
-
-See [Install and Set Up `kubectl`](/docs/tasks/tools/install-kubectl/) for
-information about how to download and install `kubectl` and set it up for
-accessing your cluster.
-
-<a class="btn btn-primary" href="/docs/tasks/tools/install-kubectl/" role="button" aria-label="View kubectl Install and Set Up Guide">View kubectl Install and Set Up Guide</a>
-
-You can also read the
+<!-- overview -->
+The Kubernetes command-line tool, [kubectl](/docs/reference/kubectl/kubectl/), allows
+you to run commands against Kubernetes clusters.
+You can use kubectl to deploy applications, inspect and manage cluster resources,
+and view logs. For more information including a complete list of kubectl operations, see the
 [`kubectl` reference documentation](/docs/reference/kubectl/).

+kubectl is installable on a variety of Linux platforms, macOS and Windows. 
+Find your preferred operating system below.
+
+- [Install kubectl on Linux](install-kubectl-linux)
+- [Install kubectl on macOS](install-kubectl-macos)
+- [Install kubectl on Windows](install-kubectl-windows)
+
 ## kind

 [`kind`](https://kind.sigs.k8s.io/docs/) lets you run Kubernetes on
@@ -0,0 +1,6 @@
+---
+title: "Tools Included"
+description: "Snippets to be included in the main kubectl-installs-*.md pages."
+headless: true
+toc_hide: true
+---
@@ -0,0 +1,21 @@
+---
+title: "gcloud kubectl install"
+description: "How to install kubectl with gcloud snippet for inclusion in each OS-specific tab."
+headless: true
+---
+
+You can install kubectl as part of the Google Cloud SDK.
+
+1. Install the [Google Cloud SDK](https://cloud.google.com/sdk/).
+
+1. Run the `kubectl` installation command:
+
+   ```shell
+   gcloud components install kubectl
+   ```
+
+1. Test to ensure the version you installed is up-to-date:
+
+   ```shell
+   kubectl version --client
+   ```
@@ -0,0 +1,12 @@
+---
+title: "What's next?"
+description: "What's next after installing kubectl."
+headless: true
+---
+
+* [Install Minikube](https://minikube.sigs.k8s.io/docs/start/)
+* 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/).
+* Read the [kubectl reference docs](/docs/reference/kubectl/kubectl/)
@@ -0,0 +1,54 @@
+---
+title: "bash auto-completion on Linux"
+description: "Some optional configuration for bash auto-completion on Linux."
+headless: true
+---
+
+### Introduction
+
+The kubectl completion script for Bash can be generated with the command `kubectl completion bash`. Sourcing the completion script in your shell enables kubectl autocompletion.
+
+However, the completion script depends on [**bash-completion**](https://github.com/scop/bash-completion), which means that you have to install this software first (you can test if you have bash-completion already installed by running `type _init_completion`).
+
+### Install bash-completion
+
+bash-completion is provided by many package managers (see [here](https://github.com/scop/bash-completion#installation)). You can install it with `apt-get install bash-completion` or `yum install bash-completion`, etc.
+
+The above commands create `/usr/share/bash-completion/bash_completion`, which is the main script of bash-completion. Depending on your package manager, you have to manually source this file in your `~/.bashrc` file.
+
+To find out, reload your shell and run `type _init_completion`. If the command succeeds, you're already set, otherwise add the following to your `~/.bashrc` file:
+
+```bash
+source /usr/share/bash-completion/bash_completion
+```
+
+Reload your shell and verify that bash-completion is correctly installed by typing `type _init_completion`.
+
+### Enable kubectl autocompletion
+
+You now need to ensure that the kubectl completion script gets sourced in all your shell sessions. There are two ways in which you can do this:
+
+- Source the completion script in your `~/.bashrc` file:
+
+   ```bash
+   echo 'source <(kubectl completion bash)' >>~/.bashrc
+   ```
+
+- Add the completion script to the `/etc/bash_completion.d` directory:
+
+   ```bash
+   kubectl completion bash >/etc/bash_completion.d/kubectl
+   ```
+
+If you have an alias for kubectl, you can extend shell completion to work with that alias:
+
+```bash
+echo 'alias k=kubectl' >>~/.bashrc
+echo 'complete -F __start_kubectl k' >>~/.bashrc
+```
+
+{{< note >}}
+bash-completion sources all completion scripts in `/etc/bash_completion.d`.
+{{< /note >}}
+
+Both approaches are equivalent. After reloading your shell, kubectl autocompletion should be working.
@@ -0,0 +1,89 @@
+---
+title: "bash auto-completion on macOS"
+description: "Some optional configuration for bash auto-completion on macOS."
+headless: true
+---
+
+### Introduction
+
+The kubectl completion script for Bash can be generated with `kubectl completion bash`. Sourcing this script in your shell enables kubectl completion.
+
+However, the kubectl completion script depends on [**bash-completion**](https://github.com/scop/bash-completion) which you thus have to previously install.
+
+{{< warning>}}
+There are two versions of bash-completion, v1 and v2. V1 is for Bash 3.2 (which is the default on macOS), and v2 is for Bash 4.1+. The kubectl completion script **doesn't work** correctly with bash-completion v1 and Bash 3.2. It requires **bash-completion v2** and **Bash 4.1+**. Thus, to be able to correctly use kubectl completion on macOS, you have to install and use Bash 4.1+ ([*instructions*](https://itnext.io/upgrading-bash-on-macos-7138bd1066ba)). The following instructions assume that you use Bash 4.1+ (that is, any Bash version of 4.1 or newer).
+{{< /warning >}}
+
+### Upgrade Bash
+
+The instructions here assume you use Bash 4.1+. You can check your Bash's version by running:
+
+```bash
+echo $BASH_VERSION
+```
+
+If it is too old, you can install/upgrade it using Homebrew:
+
+```bash
+brew install bash
+```
+
+Reload your shell and verify that the desired version is being used:
+
+```bash
+echo $BASH_VERSION $SHELL
+```
+
+Homebrew usually installs it at `/usr/local/bin/bash`.
+
+### Install bash-completion
+
+{{< note >}}
+As mentioned, these instructions assume you use Bash 4.1+, which means you will install bash-completion v2 (in contrast to Bash 3.2 and bash-completion v1, in which case kubectl completion won't work).
+{{< /note >}}
+
+You can test if you have bash-completion v2 already installed with `type _init_completion`. If not, you can install it with Homebrew:
+
+```bash
+brew install bash-completion@2
+```
+
+As stated in the output of this command, add the following to your `~/.bash_profile` file:
+
+```bash
+export BASH_COMPLETION_COMPAT_DIR="/usr/local/etc/bash_completion.d"
+[[ -r "/usr/local/etc/profile.d/bash_completion.sh" ]] && . "/usr/local/etc/profile.d/bash_completion.sh"
+```
+
+Reload your shell and verify that bash-completion v2 is correctly installed with `type _init_completion`.
+
+### Enable kubectl autocompletion
+
+You now have to ensure that the kubectl completion script gets sourced in all your shell sessions. There are multiple ways to achieve this:
+
+- Source the completion script in your `~/.bash_profile` file:
+
+    ```bash
+    echo 'source <(kubectl completion bash)' >>~/.bash_profile
+    ```
+
+- Add the completion script to the `/usr/local/etc/bash_completion.d` directory:
+
+    ```bash
+    kubectl completion bash >/usr/local/etc/bash_completion.d/kubectl
+    ```
+
+- If you have an alias for kubectl, you can extend shell completion to work with that alias:
+
+    ```bash
+    echo 'alias k=kubectl' >>~/.bash_profile
+    echo 'complete -F __start_kubectl k' >>~/.bash_profile
+    ```
+
+- If you installed kubectl with Homebrew (as explained [here](/docs/tasks/tools/install-kubectl-macos/#install-with-homebrew-on-macos)), then the kubectl completion script should already be in `/usr/local/etc/bash_completion.d/kubectl`. In that case, you don't need to do anything.
+
+   {{< note >}}
+   The Homebrew installation of bash-completion v2 sources all the files in the `BASH_COMPLETION_COMPAT_DIR` directory, that's why the latter two methods work.
+   {{< /note >}}
+
+In any case, after reloading your shell, kubectl completion should be working.
@@ -0,0 +1,29 @@
+---
+title: "zsh auto-completion"
+description: "Some optional configuration for zsh auto-completion."
+headless: true
+---
+
+The kubectl completion script for Zsh can be generated with the command `kubectl completion zsh`. Sourcing the completion script in your shell enables kubectl autocompletion.
+
+To do so in all your shell sessions, add the following to your `~/.zshrc` file:
+
+```zsh
+source <(kubectl completion zsh)
+```
+
+If you have an alias for kubectl, you can extend shell completion to work with that alias:
+
+```zsh
+echo 'alias k=kubectl' >>~/.zshrc
+echo 'complete -F __start_kubectl k' >>~/.zshrc
+```
+
+After reloading your shell, kubectl autocompletion should be working.
+
+If you get an error like `complete:13: command not found: compdef`, then add the following to the beginning of your `~/.zshrc` file:
+
+```zsh
+autoload -Uz compinit
+compinit
+```
@@ -0,0 +1,34 @@
+---
+title: "verify kubectl install"
+description: "How to verify kubectl."
+headless: true
+---
+
+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:
+
+```shell
+kubectl cluster-info
+```
+
+If you see a URL response, kubectl is correctly configured to access your cluster.
+
+If you see a message similar to the following, kubectl is not configured correctly or is not able to connect to a Kubernetes cluster.
+
+```
+The connection to the server <server-name:port> was refused - did you specify the right host or port?
+```
+
+For example, if you are intending to run a Kubernetes cluster on your laptop (locally), you will need a tool like Minikube to be installed first and then re-run the commands stated above.
+
+If kubectl cluster-info returns the url response but you can't access your cluster, to check whether it is configured properly, use:
+
+```shell
+kubectl cluster-info dump
+```
@@ -0,0 +1,195 @@
+---
+reviewers:
+- mikedanese
+title: Install and Set Up kubectl on Linux
+content_type: task
+weight: 10
+card:
+  name: tasks
+  weight: 20
+  title: Install kubectl on Linux
+---
+
+## {{% heading "prerequisites" %}}
+
+You must use a kubectl version that is within one minor version difference of your cluster.
+For example, a v1.2 client should work with v1.1, v1.2, and v1.3 master.
+Using the latest version of kubectl helps avoid unforeseen issues.
+
+## Install kubectl on Linux
+
+The following methods exist for installing kubectl on Linux:
+
+- [Install kubectl binary with curl on Linux](#install-kubectl-binary-with-curl-on-linux)
+- [Install using native package management](#install-using-native-package-management)
+- [Install using other package management](#install-using-other-package-management)
+- [Install on Linux as part of the Google Cloud SDK](#install-on-linux-as-part-of-the-google-cloud-sdk)
+
+### Install kubectl binary with curl on Linux
+
+1. Download the latest release with the command:
+
+   ```bash
+   curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
+   ```
+
+   {{< note >}}
+To download a specific version, replace the `$(curl -L -s https://dl.k8s.io/release/stable.txt)` portion of the command with the specific version.
+
+For example, to download version {{< param "fullversion" >}} on Linux, type:
+
+   ```bash
+   curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/linux/amd64/kubectl
+   ```
+   {{< /note >}}
+
+1. Validate the binary (optional)
+
+   Download the kubectl checksum file:
+
+   ```bash
+   curl -LO "https://dl.k8s.io/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl.sha256"
+   ```
+
+   Validate the kubectl binary against the checksum file:
+
+   ```bash
+   echo "$(<kubectl.sha256) kubectl" | sha256sum --check
+   ```
+
+   If valid, the output is:
+
+   ```console
+   kubectl: OK
+   ```
+
+   If the check fails, `sha256` exits with nonzero status and prints output similar to:
+
+   ```bash
+   kubectl: FAILED
+   sha256sum: WARNING: 1 computed checksum did NOT match
+   ```
+
+   {{< note >}}
+   Download the same version of the binary and checksum.
+   {{< /note >}}
+
+1. Install kubectl
+
+   ```bash
+   sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl
+   ```
+
+   {{< note >}}
+   If you do not have root access on the target system, you can still install kubectl to the `~/.local/bin` directory:
+
+   ```bash
+   mkdir -p ~/.local/bin/kubectl
+   mv ./kubectl ~/.local/bin/kubectl
+   # and then add ~/.local/bin/kubectl to $PATH
+   ```
+
+   {{< /note >}}
+
+1. Test to ensure the version you installed is up-to-date:
+
+   ```bash
+   kubectl version --client
+   ```
+
+### Install using native package management
+
+{{< tabs name="kubectl_install" >}}
+{{% tab name="Debian-based distributions" %}}
+
+1. Update the `apt` package index and install packages needed to use the Kubernetes `apt` repository:
+
+   ```shell
+   sudo apt-get update
+   sudo apt-get install -y apt-transport-https ca-certificates curl
+   ```
+
+2. Download the Google Cloud public signing key:
+
+   ```shell
+   sudo curl -fsSLo /usr/share/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.gpg
+   ```
+
+3. Add the Kubernetes `apt` repository:
+
+   ```shell
+   echo "deb [signed-by=/usr/share/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list
+   ```
+
+4. Update `apt` package index with the new repository and install kubectl:
+
+   ```shell
+   sudo apt-get update
+   sudo apt-get install -y kubectl
+   ```
+
+{{% /tab %}}
+
+{{< tab name="Red Hat-based distributions" codelang="bash" >}}
+cat <<EOF > /etc/yum.repos.d/kubernetes.repo
+[kubernetes]
+name=Kubernetes
+baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
+enabled=1
+gpgcheck=1
+repo_gpgcheck=1
+gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
+EOF
+yum install -y kubectl
+{{< /tab >}}
+{{< /tabs >}}
+
+### Install using other package management
+
+{{< tabs name="other_kubectl_install" >}}
+{{% tab name="Snap" %}}
+If you are on Ubuntu or another Linux distribution that support [snap](https://snapcraft.io/docs/core/install) package manager, kubectl is available as a [snap](https://snapcraft.io/) application.
+
+```shell
+snap install kubectl --classic
+kubectl version --client
+```
+
+{{% /tab %}}
+
+{{% tab name="Homebrew" %}}
+If you are on Linux and using [Homebrew](https://docs.brew.sh/Homebrew-on-Linux) package manager, kubectl is available for [installation](https://docs.brew.sh/Homebrew-on-Linux#install).
+
+```shell
+brew install kubectl
+kubectl version --client
+```
+
+{{% /tab %}}
+
+{{< /tabs >}}
+
+### Install on Linux as part of the Google Cloud SDK
+
+{{< include "included/install-kubectl-gcloud.md" >}}
+
+## Verify kubectl configuration
+
+{{< include "included/verify-kubectl.md" >}}
+
+## Optional kubectl configurations
+
+### Enable shell autocompletion
+
+kubectl provides autocompletion support for Bash and Zsh, which can save you a lot of typing.
+
+Below are the procedures to set up autocompletion for Bash and Zsh.
+
+{{< tabs name="kubectl_autocompletion" >}}
+{{< tab name="Bash" include="included/optional-kubectl-configs-bash-linux.md" />}}
+{{< tab name="Zsh" include="included/optional-kubectl-configs-zsh.md" />}}
+{{< /tabs >}}
+
+## {{% heading "whatsnext" %}}
+
+{{< include "included/kubectl-whats-next.md" >}}
@@ -0,0 +1,160 @@
+---
+reviewers:
+- mikedanese
+title: Install and Set Up kubectl on macOS
+content_type: task
+weight: 10
+card:
+  name: tasks
+  weight: 20
+  title: Install kubectl on macOS
+---
+
+## {{% heading "prerequisites" %}}
+
+You must use a kubectl version that is within one minor version difference of your cluster.
+For example, a v1.2 client should work with v1.1, v1.2, and v1.3 master.
+Using the latest version of kubectl helps avoid unforeseen issues.
+
+## Install kubectl on macOS
+
+The following methods exist for installing kubectl on macOS:
+
+- [Install kubectl binary with curl on macOS](#install-kubectl-binary-with-curl-on-macos)
+- [Install with Homebrew on macOS](#install-with-homebrew-on-macos)
+- [Install with Macports on macOS](#install-with-macports-on-macos)
+- [Install on macOS as part of the Google Cloud SDK](#install-on-macos-as-part-of-the-google-cloud-sdk)
+
+### Install kubectl binary with curl on macOS
+
+1. Download the latest release:
+
+   ```bash
+   curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl"
+   ```
+
+   {{< note >}}
+   To download a specific version, replace the `$(curl -L -s https://dl.k8s.io/release/stable.txt)` portion of the command with the specific version.
+
+   For example, to download version {{< param "fullversion" >}} on macOS, type:
+
+   ```bash
+   curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl
+   ```
+
+   {{< /note >}}
+
+1. Validate the binary (optional)
+
+   Download the kubectl checksum file:
+
+   ```bash
+   curl -LO "https://dl.k8s.io/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl.sha256"
+   ```
+
+   Validate the kubectl binary against the checksum file:
+
+   ```bash
+   echo "$(<kubectl.sha256)  kubectl" | shasum -a 256 --check
+   ```
+
+   If valid, the output is:
+
+   ```console
+   kubectl: OK
+   ```
+
+   If the check fails, `shasum` exits with nonzero status and prints output similar to:
+
+   ```bash
+   kubectl: FAILED
+   shasum: WARNING: 1 computed checksum did NOT match
+   ```
+
+   {{< note >}}
+   Download the same version of the binary and checksum.
+   {{< /note >}}
+
+1. Make the kubectl binary executable.
+
+   ```bash
+   chmod +x ./kubectl
+   ```
+
+1. Move the kubectl binary to a file location on your system `PATH`.
+
+   ```bash
+   sudo mv ./kubectl /usr/local/bin/kubectl
+   sudo chown root: /usr/local/bin/kubectl
+   ```
+
+1. Test to ensure the version you installed is up-to-date:
+
+   ```bash
+   kubectl version --client
+   ```
+
+### Install with Homebrew on macOS
+
+If you are on macOS and using [Homebrew](https://brew.sh/) package manager, you can install kubectl with Homebrew.
+
+1. Run the installation command:
+
+   ```bash
+   brew install kubectl 
+   ```
+
+   or
+
+   ```bash
+   brew install kubernetes-cli
+   ```
+
+1. Test to ensure the version you installed is up-to-date:
+
+   ```bash
+   kubectl version --client
+   ```
+
+### Install with Macports on macOS
+
+If you are on macOS and using [Macports](https://macports.org/) package manager, you can install kubectl with Macports.
+
+1. Run the installation command:
+
+   ```bash
+   sudo port selfupdate
+   sudo port install kubectl
+   ```
+
+1. Test to ensure the version you installed is up-to-date:
+
+   ```bash
+   kubectl version --client
+   ```
+
+
+### Install on macOS as part of the Google Cloud SDK
+
+{{< include "included/install-kubectl-gcloud.md" >}}
+
+## Verify kubectl configuration
+
+{{< include "included/verify-kubectl.md" >}}
+
+## Optional kubectl configurations
+
+### Enable shell autocompletion
+
+kubectl provides autocompletion support for Bash and Zsh, which can save you a lot of typing.
+
+Below are the procedures to set up autocompletion for Bash and Zsh.
+
+{{< tabs name="kubectl_autocompletion" >}}
+{{< tab name="Bash" include="included/optional-kubectl-configs-bash-mac.md" />}}
+{{< tab name="Zsh" include="included/optional-kubectl-configs-zsh.md" />}}
+{{< /tabs >}}
+
+## {{% heading "whatsnext" %}}
+
+{{< include "included/kubectl-whats-next.md" >}}
@@ -0,0 +1,179 @@
+---
+reviewers:
+- mikedanese
+title: Install and Set Up kubectl on Windows
+content_type: task
+weight: 10
+card:
+  name: tasks
+  weight: 20
+  title: Install kubectl on Windows
+---
+
+## {{% heading "prerequisites" %}}
+
+You must use a kubectl version that is within one minor version difference of your cluster.
+For example, a v1.2 client should work with v1.1, v1.2, and v1.3 master.
+Using the latest version of kubectl helps avoid unforeseen issues.
+
+## Install kubectl on Windows
+
+The following methods exist for installing kubectl on Windows:
+
+- [Install kubectl binary with curl on Windows](#install-kubectl-binary-with-curl-on-windows)
+- [Install with PowerShell from PSGallery](#install-with-powershell-from-psgallery)
+- [Install on Windows using Chocolatey or Scoop](#install-on-windows-using-chocolatey-or-scoop)
+- [Install on Windows as part of the Google Cloud SDK](#install-on-windows-as-part-of-the-google-cloud-sdk)
+
+
+### Install kubectl binary with curl on Windows
+
+1. Download the [latest release {{< param "fullversion" >}}](https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe).
+
+   Or if you have `curl` installed, use this command:
+
+   ```powershell
+   curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe
+   ```
+
+   {{< note >}}
+   To find out the latest stable version (for example, for scripting), take a look at [https://dl.k8s.io/release/stable.txt](https://dl.k8s.io/release/stable.txt).
+   {{< /note >}}
+
+1. Validate the binary (optional)
+
+   Download the kubectl checksum file:
+
+   ```powershell
+   curl -LO https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe.sha256
+   ```
+
+   Validate the kubectl binary against the checksum file:
+
+   - Using Command Prompt to manually compare `CertUtil`'s output to the checksum file downloaded:
+
+     ```cmd
+     CertUtil -hashfile kubectl.exe SHA256
+     type kubectl.exe.sha256
+     ```
+
+   - Using PowerShell to automate the verification using the `-eq` operator to get a `True` or `False` result:
+
+     ```powershell
+     $($(CertUtil -hashfile .\kubectl.exe SHA256)[1] -replace " ", "") -eq $(type .\kubectl.exe.sha256)
+     ```
+
+1. Add the binary in to your `PATH`.
+
+1. Test to ensure the version of `kubectl` is the same as downloaded:
+
+   ```cmd
+   kubectl version --client
+   ```
+
+{{< note >}}
+[Docker Desktop for Windows](https://docs.docker.com/docker-for-windows/#kubernetes) adds its own version of `kubectl` to `PATH`.
+If you have installed Docker Desktop before, you may need to place your `PATH` entry before the one added by the Docker Desktop installer or remove the Docker Desktop's `kubectl`.
+{{< /note >}}
+
+### Install with PowerShell from PSGallery
+
+If you are on Windows and using the [PowerShell Gallery](https://www.powershellgallery.com/) package manager, you can install and update kubectl with PowerShell.
+
+1. Run the installation commands (making sure to specify a `DownloadLocation`):
+
+   ```powershell
+   Install-Script -Name 'install-kubectl' -Scope CurrentUser -Force
+   install-kubectl.ps1 [-DownloadLocation <path>]
+   ```
+
+   {{< note >}}
+   If you do not specify a `DownloadLocation`, `kubectl` will be installed in the user's `temp` Directory.
+   {{< /note >}}
+
+   The installer creates `$HOME/.kube` and instructs it to create a config file.
+
+1. Test to ensure the version you installed is up-to-date:
+
+   ```powershell
+   kubectl version --client
+   ```
+
+{{< note >}}
+Updating the installation is performed by rerunning the two commands listed in step 1.
+{{< /note >}}
+
+### Install on Windows using Chocolatey or Scoop
+
+1. To install kubectl on Windows you can use either [Chocolatey](https://chocolatey.org) package manager or [Scoop](https://scoop.sh) command-line installer.
+
+   {{< tabs name="kubectl_win_install" >}}
+   {{% tab name="choco" %}}
+   ```powershell
+   choco install kubernetes-cli
+   ```
+   {{% /tab %}}
+   {{% tab name="scoop" %}}
+   ```powershell
+   scoop install kubectl
+   ```
+   {{% /tab %}}
+   {{< /tabs >}}
+
+
+1. Test to ensure the version you installed is up-to-date:
+
+   ```powershell
+   kubectl version --client
+   ```
+
+1. Navigate to your home directory:
+
+   ```powershell
+   # If you're using cmd.exe, run: cd %USERPROFILE%
+   cd ~
+   ```
+
+1. Create the `.kube` directory:
+
+   ```powershell
+   mkdir .kube
+   ```
+
+1. Change to the `.kube` directory you just created:
+
+   ```powershell
+   cd .kube
+   ```
+
+1. Configure kubectl to use a remote Kubernetes cluster:
+
+   ```powershell
+   New-Item config -type file
+   ```
+
+{{< note >}}
+Edit the config file with a text editor of your choice, such as Notepad.
+{{< /note >}}
+
+### Install on Windows as part of the Google Cloud SDK
+
+{{< include "included/install-kubectl-gcloud.md" >}}
+
+## Verify kubectl configuration
+
+{{< include "included/verify-kubectl.md" >}}
+
+## Optional kubectl configurations
+
+### Enable shell autocompletion
+
+kubectl provides autocompletion support for Bash and Zsh, which can save you a lot of typing.
+
+Below are the procedures to set up autocompletion for Zsh, if you are running that on Windows.
+
+{{< include "included/optional-kubectl-configs-zsh.md" >}}
+
+## {{% heading "whatsnext" %}}
+
+{{< include "included/kubectl-whats-next.md" >}}
@@ -1,634 +0,0 @@
---
-reviewers:
- mikedanese
-title: Install and Set Up kubectl
-content_type: task
-weight: 10
-card:
-  name: tasks
-  weight: 20
-  title: Install kubectl
---
-
-<!-- overview -->
-The Kubernetes command-line tool, [kubectl](/docs/reference/kubectl/kubectl/), allows
-you to run commands against Kubernetes clusters.
-You can use kubectl to deploy applications, inspect and manage cluster resources,
-and view logs. For a complete list of kubectl operations, see
-[Overview of kubectl](/docs/reference/kubectl/overview/).
-
-
-## {{% heading "prerequisites" %}}
-
-You must use a kubectl version that is within one minor version difference of your cluster.
-For example, a v1.2 client should work with v1.1, v1.2, and v1.3 master.
-Using the latest version of kubectl helps avoid unforeseen issues.
-
-<!-- steps -->
-
-## Install kubectl on Linux
-
-### Install kubectl binary with curl on Linux
-
-1. Download the latest release with the command:
-
-   ```bash
-   curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
-   ```
-
-   {{< note >}}
-To download a specific version, replace the `$(curl -L -s https://dl.k8s.io/release/stable.txt)` portion of the command with the specific version.
-
-For example, to download version {{< param "fullversion" >}} on Linux, type:
-
-   ```bash
-   curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/linux/amd64/kubectl
-   ```
-   {{< /note >}}
-
-1. Validate the binary (optional)
-
-   Download the kubectl checksum file:
-
-   ```bash
-   curl -LO "https://dl.k8s.io/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl.sha256"
-   ```
-
-   Validate the kubectl binary against the checksum file:
-
-   ```bash
-   echo "$(<kubectl.sha256) kubectl" | sha256sum --check
-   ```
-
-   If valid, the output is:
-
-   ```bash
-   kubectl: OK
-   ```
-
-   If the check fails, `sha256` exits with nonzero status and prints output similar to:
-
-   ```bash
-   kubectl: FAILED
-   sha256sum: WARNING: 1 computed checksum did NOT match
-   ```
-
-   {{< note >}}
-   Download the same version of the binary and checksum.
-   {{< /note >}}
-
-1. Install kubectl
-
-   ```bash
-   sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl
-   ```
-
-   {{< note >}}
-   If you do not have root access on the target system, you can still install kubectl to the `~/.local/bin` directory:
-
-   ```bash
-   mkdir -p ~/.local/bin/kubectl
-   mv ./kubectl ~/.local/bin/kubectl
-   # and then add ~/.local/bin/kubectl to $PATH
-   ```
-
-   {{< /note >}}
-
-1. Test to ensure the version you installed is up-to-date:
-
-   ```bash
-   kubectl version --client
-   ```
-
-### Install using native package management
-
-{{< tabs name="kubectl_install" >}}
-{{< tab name="Ubuntu, Debian or HypriotOS" codelang="bash" >}}
-sudo apt-get update && sudo apt-get install -y apt-transport-https gnupg2 curl
-curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
-echo "deb https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee -a /etc/apt/sources.list.d/kubernetes.list
-sudo apt-get update
-sudo apt-get install -y kubectl
-{{< /tab >}}
-
-{{< tab name="CentOS, RHEL or Fedora" codelang="bash" >}}cat <<EOF > /etc/yum.repos.d/kubernetes.repo
-[kubernetes]
-name=Kubernetes
-baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
-enabled=1
-gpgcheck=1
-repo_gpgcheck=1
-gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
-EOF
-yum install -y kubectl
-{{< /tab >}}
-{{< /tabs >}}
-
-### Install using other package management
-
-{{< tabs name="other_kubectl_install" >}}
-{{% tab name="Snap" %}}
-If you are on Ubuntu or another Linux distribution that support [snap](https://snapcraft.io/docs/core/install) package manager, kubectl is available as a [snap](https://snapcraft.io/) application.
-
-```shell
-snap install kubectl --classic
-
-kubectl version --client
-```
-
-{{% /tab %}}
-
-{{% tab name="Homebrew" %}}
-If you are on Linux and using [Homebrew](https://docs.brew.sh/Homebrew-on-Linux) package manager, kubectl is available for [installation](https://docs.brew.sh/Homebrew-on-Linux#install).
-
-```shell
-brew install kubectl
-
-kubectl version --client
-```
-
-{{% /tab %}}
-
-{{< /tabs >}}
-
-
-## Install kubectl on macOS
-
-### Install kubectl binary with curl on macOS
-
-1. Download the latest release:
-
-   ```bash
-   curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl"
-   ```
-
-   {{< note >}}
-   To download a specific version, replace the `$(curl -L -s https://dl.k8s.io/release/stable.txt)` portion of the command with the specific version.
-
-   For example, to download version {{< param "fullversion" >}} on macOS, type:
-
-   ```bash
-   curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl
-   ```
-
-   {{< /note >}}
-
-1. Validate the binary (optional)
-
-   Download the kubectl checksum file:
-
-   ```bash
-   curl -LO "https://dl.k8s.io/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl.sha256"
-   ```
-
-   Validate the kubectl binary against the checksum file:
-
-   ```bash
-   echo "$(<kubectl.sha256)  kubectl" | shasum -a 256 --check
-   ```
-
-   If valid, the output is:
-
-   ```bash
-   kubectl: OK
-   ```
-
-   If the check fails, `shasum` exits with nonzero status and prints output similar to:
-
-   ```bash
-   kubectl: FAILED
-   shasum: WARNING: 1 computed checksum did NOT match
-   ```
-
-   {{< note >}}
-   Download the same version of the binary and checksum.
-   {{< /note >}}
-
-1. Make the kubectl binary executable.
-
-   ```bash
-   chmod +x ./kubectl
-   ```
-
-1. Move the kubectl binary to a file location on your system `PATH`.
-
-   ```bash
-   sudo mv ./kubectl /usr/local/bin/kubectl && \
-   sudo chown root: /usr/local/bin/kubectl
-   ```
-
-1. Test to ensure the version you installed is up-to-date:
-
-   ```bash
-   kubectl version --client
-   ```
-
-### Install with Homebrew on macOS
-
-If you are on macOS and using [Homebrew](https://brew.sh/) package manager, you can install kubectl with Homebrew.
-
-1. Run the installation command:
-
-   ```bash
-   brew install kubectl 
-   ```
-
-   or
-
-   ```bash
-   brew install kubernetes-cli
-   ```
-
-1. Test to ensure the version you installed is up-to-date:
-
-   ```bash
-   kubectl version --client
-   ```
-
-### Install with Macports on macOS
-
-If you are on macOS and using [Macports](https://macports.org/) package manager, you can install kubectl with Macports.
-
-1. Run the installation command:
-
-   ```bash
-   sudo port selfupdate
-   sudo port install kubectl
-   ```
-
-1. Test to ensure the version you installed is up-to-date:
-
-   ```bash
-   kubectl version --client
-   ```
-
-## Install kubectl on Windows
-
-### Install kubectl binary with curl on Windows
-
-1. Download the [latest release {{< param "fullversion" >}}](https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe).
-
-   Or if you have `curl` installed, use this command:
-
-   ```powershell
-   curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe
-   ```
-
-   {{< note >}}
-   To find out the latest stable version (for example, for scripting), take a look at [https://dl.k8s.io/release/stable.txt](https://dl.k8s.io/release/stable.txt).
-   {{< /note >}}
-
-1. Validate the binary (optional)
-
-   Download the kubectl checksum file:
-
-   ```powershell
-   curl -LO https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe.sha256
-   ```
-
-   Validate the kubectl binary against the checksum file:
-
-   - Using Command Prompt to manually compare `CertUtil`'s output to the checksum file downloaded:
-
-     ```cmd
-     CertUtil -hashfile kubectl.exe SHA256
-     type kubectl.exe.sha256
-     ```
-
-   - Using PowerShell to automate the verification using the `-eq` operator to get a `True` or `False` result:
-
-     ```powershell
-     $($(CertUtil -hashfile .\kubectl.exe SHA256)[1] -replace " ", "") -eq $(type .\kubectl.exe.sha256)
-     ```
-
-1. Add the binary in to your `PATH`.
-
-1. Test to ensure the version of `kubectl` is the same as downloaded:
-
-   ```cmd
-   kubectl version --client
-   ```
-
-{{< note >}}
-[Docker Desktop for Windows](https://docs.docker.com/docker-for-windows/#kubernetes) adds its own version of `kubectl` to `PATH`.
-If you have installed Docker Desktop before, you may need to place your `PATH` entry before the one added by the Docker Desktop installer or remove the Docker Desktop's `kubectl`.
-{{< /note >}}
-
-### Install with PowerShell from PSGallery
-
-If you are on Windows and using the [PowerShell Gallery](https://www.powershellgallery.com/) package manager, you can install and update kubectl with PowerShell.
-
-1. Run the installation commands (making sure to specify a `DownloadLocation`):
-
-   ```powershell
-   Install-Script -Name 'install-kubectl' -Scope CurrentUser -Force
-   install-kubectl.ps1 [-DownloadLocation <path>]
-   ```
-
-   {{< note >}}
-   If you do not specify a `DownloadLocation`, `kubectl` will be installed in the user's `temp` Directory.
-   {{< /note >}}
-
-   The installer creates `$HOME/.kube` and instructs it to create a config file.
-
-1. Test to ensure the version you installed is up-to-date:
-
-   ```powershell
-   kubectl version --client
-   ```
-
-{{< note >}}
-Updating the installation is performed by rerunning the two commands listed in step 1.
-{{< /note >}}
-
-### Install on Windows using Chocolatey or Scoop
-
-1. To install kubectl on Windows you can use either [Chocolatey](https://chocolatey.org) package manager or [Scoop](https://scoop.sh) command-line installer.
-
-   {{< tabs name="kubectl_win_install" >}}
-   {{% tab name="choco" %}}
-   ```powershell
-   choco install kubernetes-cli
-   ```
-   {{% /tab %}}
-   {{% tab name="scoop" %}}
-   ```powershell
-   scoop install kubectl
-   ```
-   {{% /tab %}}
-   {{< /tabs >}}
-
-
-1. Test to ensure the version you installed is up-to-date:
-
-   ```powershell
-   kubectl version --client
-   ```
-
-1. Navigate to your home directory:
-
-   ```powershell
-   # If you're using cmd.exe, run: cd %USERPROFILE%
-   cd ~
-   ```
-
-1. Create the `.kube` directory:
-
-   ```powershell
-   mkdir .kube
-   ```
-
-1. Change to the `.kube` directory you just created:
-
-   ```powershell
-   cd .kube
-   ```
-
-1. Configure kubectl to use a remote Kubernetes cluster:
-
-   ```powershell
-   New-Item config -type file
-   ```
-
-{{< note >}}
-Edit the config file with a text editor of your choice, such as Notepad.
-{{< /note >}}
-
-## Download as part of the Google Cloud SDK
-
-You can install kubectl as part of the Google Cloud SDK.
-
-1. Install the [Google Cloud SDK](https://cloud.google.com/sdk/).
-
-1. Run the `kubectl` installation command:
-
-   ```shell
-   gcloud components install kubectl
-   ```
-
-1. Test to ensure the version you installed is up-to-date:
-
-   ```shell
-   kubectl version --client
-   ```
-
-## Verifying kubectl configuration
-
-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:
-
-```shell
-kubectl cluster-info
-```
-
-If you see a URL response, kubectl is correctly configured to access your cluster.
-
-If you see a message similar to the following, kubectl is not configured correctly or is not able to connect to a Kubernetes cluster.
-
-```
-The connection to the server <server-name:port> was refused - did you specify the right host or port?
-```
-
-For example, if you are intending to run a Kubernetes cluster on your laptop (locally), you will need a tool like Minikube to be installed first and then re-run the commands stated above.
-
-If kubectl cluster-info returns the url response but you can't access your cluster, to check whether it is configured properly, use:
-
-```shell
-kubectl cluster-info dump
-```
-
-## Optional kubectl configurations
-
-### Enabling shell autocompletion
-
-kubectl provides autocompletion support for Bash and Zsh, which can save you a lot of typing.
-
-Below are the procedures to set up autocompletion for Bash (including the difference between Linux and macOS) and Zsh.
-
-{{< tabs name="kubectl_autocompletion" >}}
-
-{{% tab name="Bash on Linux" %}}
-
-### Introduction
-
-The kubectl completion script for Bash can be generated with the command `kubectl completion bash`. Sourcing the completion script in your shell enables kubectl autocompletion.
-
-However, the completion script depends on [**bash-completion**](https://github.com/scop/bash-completion), which means that you have to install this software first (you can test if you have bash-completion already installed by running `type _init_completion`).
-
-### Install bash-completion
-
-bash-completion is provided by many package managers (see [here](https://github.com/scop/bash-completion#installation)). You can install it with `apt-get install bash-completion` or `yum install bash-completion`, etc.
-
-The above commands create `/usr/share/bash-completion/bash_completion`, which is the main script of bash-completion. Depending on your package manager, you have to manually source this file in your `~/.bashrc` file.
-
-To find out, reload your shell and run `type _init_completion`. If the command succeeds, you're already set, otherwise add the following to your `~/.bashrc` file:
-
-```bash
-source /usr/share/bash-completion/bash_completion
-```
-
-Reload your shell and verify that bash-completion is correctly installed by typing `type _init_completion`.
-
-### Enable kubectl autocompletion
-
-You now need to ensure that the kubectl completion script gets sourced in all your shell sessions. There are two ways in which you can do this:
-
- Source the completion script in your `~/.bashrc` file:
-
-   ```bash
-   echo 'source <(kubectl completion bash)' >>~/.bashrc
-   ```
-
- Add the completion script to the `/etc/bash_completion.d` directory:
-
-   ```bash
-   kubectl completion bash >/etc/bash_completion.d/kubectl
-   ```
-
-If you have an alias for kubectl, you can extend shell completion to work with that alias:
-
-```bash
-echo 'alias k=kubectl' >>~/.bashrc
-echo 'complete -F __start_kubectl k' >>~/.bashrc
-```
-
-{{< note >}}
-bash-completion sources all completion scripts in `/etc/bash_completion.d`.
-{{< /note >}}
-
-Both approaches are equivalent. After reloading your shell, kubectl autocompletion should be working.
-
-{{% /tab %}}
-
-
-{{% tab name="Bash on macOS" %}}
-
-
-### Introduction
-
-The kubectl completion script for Bash can be generated with `kubectl completion bash`. Sourcing this script in your shell enables kubectl completion.
-
-However, the kubectl completion script depends on [**bash-completion**](https://github.com/scop/bash-completion) which you thus have to previously install.
-
-{{< warning>}}
-There are two versions of bash-completion, v1 and v2. V1 is for Bash 3.2 (which is the default on macOS), and v2 is for Bash 4.1+. The kubectl completion script **doesn't work** correctly with bash-completion v1 and Bash 3.2. It requires **bash-completion v2** and **Bash 4.1+**. Thus, to be able to correctly use kubectl completion on macOS, you have to install and use Bash 4.1+ ([*instructions*](https://itnext.io/upgrading-bash-on-macos-7138bd1066ba)). The following instructions assume that you use Bash 4.1+ (that is, any Bash version of 4.1 or newer).
-{{< /warning >}}
-
-### Upgrade Bash
-
-The instructions here assume you use Bash 4.1+. You can check your Bash's version by running:
-
-```bash
-echo $BASH_VERSION
-```
-
-If it is too old, you can install/upgrade it using Homebrew:
-
-```bash
-brew install bash
-```
-
-Reload your shell and verify that the desired version is being used:
-
-```bash
-echo $BASH_VERSION $SHELL
-```
-
-Homebrew usually installs it at `/usr/local/bin/bash`.
-
-### Install bash-completion
-
-{{< note >}}
-As mentioned, these instructions assume you use Bash 4.1+, which means you will install bash-completion v2 (in contrast to Bash 3.2 and bash-completion v1, in which case kubectl completion won't work).
-{{< /note >}}
-
-You can test if you have bash-completion v2 already installed with `type _init_completion`. If not, you can install it with Homebrew:
-
-```bash
-brew install bash-completion@2
-```
-
-As stated in the output of this command, add the following to your `~/.bash_profile` file:
-
-```bash
-export BASH_COMPLETION_COMPAT_DIR="/usr/local/etc/bash_completion.d"
-[[ -r "/usr/local/etc/profile.d/bash_completion.sh" ]] && . "/usr/local/etc/profile.d/bash_completion.sh"
-```
-
-Reload your shell and verify that bash-completion v2 is correctly installed with `type _init_completion`.
-
-### Enable kubectl autocompletion
-
-You now have to ensure that the kubectl completion script gets sourced in all your shell sessions. There are multiple ways to achieve this:
-
- Source the completion script in your `~/.bash_profile` file:
-
-    ```bash
-    echo 'source <(kubectl completion bash)' >>~/.bash_profile
-    ```
-
- Add the completion script to the `/usr/local/etc/bash_completion.d` directory:
-
-    ```bash
-    kubectl completion bash >/usr/local/etc/bash_completion.d/kubectl
-    ```
-
- If you have an alias for kubectl, you can extend shell completion to work with that alias:
-
-    ```bash
-    echo 'alias k=kubectl' >>~/.bash_profile
-    echo 'complete -F __start_kubectl k' >>~/.bash_profile
-    ```
-
- If you installed kubectl with Homebrew (as explained [above](#install-with-homebrew-on-macos)), then the kubectl completion script should already be in `/usr/local/etc/bash_completion.d/kubectl`. In that case, you don't need to do anything.
-
-   {{< note >}}
-   The Homebrew installation of bash-completion v2 sources all the files in the `BASH_COMPLETION_COMPAT_DIR` directory, that's why the latter two methods work.
-   {{< /note >}}
-
-In any case, after reloading your shell, kubectl completion should be working.
-{{% /tab %}}
-
-{{% tab name="Zsh" %}}
-
-The kubectl completion script for Zsh can be generated with the command `kubectl completion zsh`. Sourcing the completion script in your shell enables kubectl autocompletion.
-
-To do so in all your shell sessions, add the following to your `~/.zshrc` file:
-
-```zsh
-source <(kubectl completion zsh)
-```
-
-If you have an alias for kubectl, you can extend shell completion to work with that alias:
-
-```zsh
-echo 'alias k=kubectl' >>~/.zshrc
-echo 'complete -F __start_kubectl k' >>~/.zshrc
-```
-
-After reloading your shell, kubectl autocompletion should be working.
-
-If you get an error like `complete:13: command not found: compdef`, then add the following to the beginning of your `~/.zshrc` file:
-
-```zsh
-autoload -Uz compinit
-compinit
-```
-{{% /tab %}}
-{{< /tabs >}}
-
-## {{% heading "whatsnext" %}}
-
-* [Install Minikube](https://minikube.sigs.k8s.io/docs/start/)
-* 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/).
-* Read the [kubectl reference docs](/docs/reference/kubectl/kubectl/)
-
@@ -37,7 +37,7 @@ profiles that give only the necessary privileges to your container processes.

 In order to complete all steps in this tutorial, you must install
 [kind](https://kind.sigs.k8s.io/docs/user/quick-start/) and
-[kubectl](/docs/tasks/tools/install-kubectl/). This tutorial will show examples
+[kubectl](/docs/tasks/tools/). This tutorial will show examples
 with both alpha (pre-v1.19) and generally available seccomp functionality, so
 make sure that your cluster is [configured
 correctly](https://kind.sigs.k8s.io/docs/user/quick-start/#setting-kubernetes-version)
--- a/Show More
+++ b/Show More