Merge master into dev-1.21 to keep in sync

2021-03-26 21:26:43 +01:00
parent 9442bf8bbd 3db583a9cd
commit ca046d9b1f
200 changed files with 4310 additions and 2439 deletions
@@ -231,7 +231,7 @@ You have several options for connecting to nodes, pods and services from outside
    - Use a service with type `NodePort` or `LoadBalancer` to make the service reachable outside
      the cluster.  See the [services](/docs/concepts/services-networking/service/) and
      [kubectl expose](/docs/reference/generated/kubectl/kubectl-commands/#expose) documentation.
-    - Depending on your cluster environment, this may just expose the service to your corporate network,
+    - Depending on your cluster environment, this may only expose the service to your corporate network,
      or it may expose it to the internet.  Think about whether the service being exposed is secure.
      Does it do its own authentication?
    - Place pods behind services.  To access one specific pod from a set of replicas, such as for debugging,
@@ -283,7 +283,7 @@ at `https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-l
 As mentioned above, you use the `kubectl cluster-info` command to retrieve the service's proxy URL. To create proxy URLs that include service endpoints, suffixes, and parameters, you append to the service's proxy URL:
 `http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`service_name[:port_name]`*`/proxy`

-If you haven't specified a name for your port, you don't have to specify *port_name* in the URL.
+If you haven't specified a name for your port, you don't have to specify *port_name* in the URL. You can also use the port number in place of the *port_name* for both named and unnamed ports.

 By default, the API server proxies to your service using http. To use https, prefix the service name with `https:`:
 `http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`https:service_name:[port_name]`*`/proxy`
@@ -291,9 +291,9 @@ By default, the API server proxies to your service using http. To use https, pre
 The supported formats for the name segment of the URL are:

 * `<service_name>` - proxies to the default or unnamed port using http
-* `<service_name>:<port_name>` - proxies to the specified port using http
+* `<service_name>:<port_name>` - proxies to the specified port name or port number using http
 * `https:<service_name>:` - proxies to the default or unnamed port using https (note the trailing colon)
-* `https:<service_name>:<port_name>` - proxies to the specified port using https
+* `https:<service_name>:<port_name>` - proxies to the specified port name or port number using https

 ##### Examples

@@ -357,7 +357,7 @@ There are several different proxies you may encounter when using Kubernetes:
    - proxies UDP and TCP
    - does not understand HTTP
    - provides load balancing
-    - is just used to reach services
+    - is only used to reach services

 1.  A Proxy/Load-balancer in front of apiserver(s):

@@ -7,7 +7,7 @@ min-kubernetes-server-version: v1.10

 <!-- overview -->

-This page shows how to use `kubectl port-forward` to connect to a Redis
+This page shows how to use `kubectl port-forward` to connect to a MongoDB
 server running in a Kubernetes cluster. This type of connection can be useful
 for database debugging.

@@ -19,25 +19,25 @@ for database debugging.

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

-* Install [redis-cli](http://redis.io/topics/rediscli).
+* Install [MongoDB Shell](https://www.mongodb.com/try/download/shell).




 <!-- steps -->

-## Creating Redis deployment and service
+## Creating MongoDB deployment and service

-1. Create a Deployment that runs Redis:
+1. Create a Deployment that runs MongoDB:

    ```shell
-    kubectl apply -f https://k8s.io/examples/application/guestbook/redis-master-deployment.yaml
+    kubectl apply -f https://k8s.io/examples/application/guestbook/mongo-deployment.yaml
    ```

    The output of a successful command verifies that the deployment was created:

    ```
-    deployment.apps/redis-master created
+    deployment.apps/mongo created
    ```

    View the pod status to check that it is ready:
@@ -49,8 +49,8 @@ for database debugging.
    The output displays the pod created:

    ```
-    NAME                            READY     STATUS    RESTARTS   AGE
-    redis-master-765d459796-258hz   1/1       Running   0          50s
+    NAME                     READY   STATUS    RESTARTS   AGE
+    mongo-75f59d57f4-4nd6q   1/1     Running   0          2m4s
    ```

    View the Deployment's status:
@@ -62,8 +62,8 @@ for database debugging.
    The output displays that the Deployment was created:

    ```
-    NAME         READY   UP-TO-DATE   AVAILABLE   AGE
-    redis-master 1/1     1            1           55s
+    NAME    READY   UP-TO-DATE   AVAILABLE   AGE
+    mongo   1/1     1            1           2m21s
    ```

    The Deployment automatically manages a ReplicaSet.
@@ -76,50 +76,50 @@ for database debugging.
    The output displays that the ReplicaSet was created:

    ```
-    NAME                      DESIRED   CURRENT   READY     AGE
-    redis-master-765d459796   1         1         1         1m
+    NAME               DESIRED   CURRENT   READY   AGE
+    mongo-75f59d57f4   1         1         1       3m12s
    ```


-2. Create a Service to expose Redis on the network:
+2. Create a Service to expose MongoDB on the network:

    ```shell
-    kubectl apply -f https://k8s.io/examples/application/guestbook/redis-master-service.yaml
+    kubectl apply -f https://k8s.io/examples/application/guestbook/mongo-service.yaml
    ```

    The output of a successful command verifies that the Service was created:

    ```
-    service/redis-master created
+    service/mongo created
    ```

    Check the Service created:

    ```shell
-    kubectl get service redis-master
+    kubectl get service mongo
    ```

    The output displays the service created:

    ```
-    NAME           TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)    AGE
-    redis-master   ClusterIP   10.0.0.213   <none>        6379/TCP   27s
+    NAME    TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)     AGE
+    mongo   ClusterIP   10.96.41.183   <none>        27017/TCP   11s
    ```

-3. Verify that the Redis server is running in the Pod, and listening on port 6379:
+3. Verify that the MongoDB server is running in the Pod, and listening on port 27017:

    ```shell
-    # Change redis-master-765d459796-258hz to the name of the Pod
-    kubectl get pod redis-master-765d459796-258hz --template='{{(index (index .spec.containers 0).ports 0).containerPort}}{{"\n"}}'
+    # Change mongo-75f59d57f4-4nd6q to the name of the Pod
+    kubectl get pod mongo-75f59d57f4-4nd6q --template='{{(index (index .spec.containers 0).ports 0).containerPort}}{{"\n"}}'
    ```

-    The output displays the port for Redis in that Pod:
+    The output displays the port for MongoDB in that Pod:

    ```
-    6379
+    27017
    ```

-    (this is the TCP port allocated to Redis on the internet).
+    (this is the TCP port allocated to MongoDB on the internet).

 ## Forward a local port to a port on the Pod

@@ -127,39 +127,39 @@ for database debugging.


    ```shell
-    # Change redis-master-765d459796-258hz to the name of the Pod
-    kubectl port-forward redis-master-765d459796-258hz 7000:6379
+    # Change mongo-75f59d57f4-4nd6q to the name of the Pod
+    kubectl port-forward mongo-75f59d57f4-4nd6q 28015:27017
    ```

    which is the same as

    ```shell
-    kubectl port-forward pods/redis-master-765d459796-258hz 7000:6379
+    kubectl port-forward pods/mongo-75f59d57f4-4nd6q 28015:27017
    ```

    or

    ```shell
-    kubectl port-forward deployment/redis-master 7000:6379
+    kubectl port-forward deployment/mongo 28015:27017
    ```

    or

    ```shell
-    kubectl port-forward replicaset/redis-master 7000:6379
+    kubectl port-forward replicaset/mongo-75f59d57f4 28015:27017
    ```

    or

    ```shell
-    kubectl port-forward service/redis-master 7000:redis
+    kubectl port-forward service/mongo 28015:27017
    ```

    Any of the above commands works. The output is similar to this:

    ```
-    Forwarding from 127.0.0.1:7000 -> 6379
-    Forwarding from [::1]:7000 -> 6379
+    Forwarding from 127.0.0.1:28015 -> 27017
+    Forwarding from [::1]:28015 -> 27017
    ```

 {{< note >}}
@@ -168,22 +168,22 @@ for database debugging.

 {{< /note >}}

-2.  Start the Redis command line interface:
+2.  Start the MongoDB command line interface:

    ```shell
-    redis-cli -p 7000
+    mongosh --port 28015
    ```

-3.  At the Redis command line prompt, enter the `ping` command:
+3.  At the MongoDB command line prompt, enter the `ping` command:

    ```
-    ping
+    db.runCommand( { ping: 1 } )
    ```

    A successful ping request returns:

    ```
-    PONG
+    { ok: 1 }
    ```

 ### Optionally let _kubectl_ choose the local port {#let-kubectl-choose-local-port}
@@ -193,15 +193,22 @@ the local port and thus relieve you from having to manage local port conflicts,
 the slightly simpler syntax:

 ```shell
-kubectl port-forward deployment/redis-master :6379
+kubectl port-forward deployment/mongo :27017
+```
+
+The output is similar to this:
+
+```
+Forwarding from 127.0.0.1:63753 -> 27017
+Forwarding from [::1]:63753 -> 27017
 ```

 The `kubectl` tool finds a local port number that is not in use (avoiding low ports numbers,
 because these might be used by other applications). The output is similar to:

 ```
-Forwarding from 127.0.0.1:62162 -> 6379
-Forwarding from [::1]:62162 -> 6379
+Forwarding from 127.0.0.1:63753 -> 27017
+Forwarding from [::1]:63753 -> 27017
 ```


@@ -209,8 +216,8 @@ Forwarding from [::1]:62162 -> 6379

 ## Discussion

-Connections made to local port 7000 are forwarded to port 6379 of the Pod that
-is running the Redis server. With this connection in place, you can use your
+Connections made to local port 28015 are forwarded to port 27017 of the Pod that
+is running the MongoDB server. With this connection in place, you can use your
 local workstation to debug the database that is running in the Pod.

 {{< note >}}
@@ -31,7 +31,7 @@ You have several options for connecting to nodes, pods and services from outside
    - Use a service with type `NodePort` or `LoadBalancer` to make the service reachable outside
      the cluster.  See the [services](/docs/concepts/services-networking/service/) and
      [kubectl expose](/docs/reference/generated/kubectl/kubectl-commands/#expose) documentation.
-    - Depending on your cluster environment, this may just expose the service to your corporate network,
+    - Depending on your cluster environment, this may only expose the service to your corporate network,
      or it may expose it to the internet.  Think about whether the service being exposed is secure.
      Does it do its own authentication?
    - Place pods behind services.  To access one specific pod from a set of replicas, such as for debugging,
@@ -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
@@ -125,7 +125,16 @@ the URL schema.

 Similarly, to configure etcd with secure client communication, specify flags
 `--key-file=k8sclient.key` and `--cert-file=k8sclient.cert`, and use HTTPS as
-the URL schema.
+the URL schema. Here is an example on a client command that uses secure
+communication:
+
+```
+ETCDCTL_API=3 etcdctl --endpoints 10.2.0.9:2379 \
+  --cert=/etc/kubernetes/pki/etcd/server.crt \
+  --key=/etc/kubernetes/pki/etcd/server.key \
+  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
+  member list
+```

 ### Limiting access of etcd clusters

@@ -269,6 +278,24 @@ If etcd is running on a storage volume that supports backup, such as Amazon
 Elastic Block Store, back up etcd data by taking a snapshot of the storage
 volume.

+### Snapshot using etcdctl options
+
+We can also take the snapshot using various options given by etcdctl. For example 
+
+```shell
+ETCDCTL_API=3 etcdctl --h 
+``` 
+
+will list various options available from etcdctl. For example, you can take a snapshot by specifying
+the endpoint, certificates etc as shown below:
+
+```shell
+ETCDCTL_API=3 etcdctl --endpoints=[127.0.0.1:2379] \
+  --cacert=<trusted-ca-file> --cert=<cert-file> --key=<key-file> \
+  snapshot save <backup-file-location>
+```
+where `trusted-ca-file`, `cert-file` and `key-file` can be obtained from the description of the etcd Pod.
+
 ## Scaling up etcd clusters

 Scaling up etcd clusters increases availability by trading off performance.
@@ -293,6 +320,12 @@ employed to recover the data of a failed cluster.
 Before starting the restore operation, a snapshot file must be present. It can
 either be a snapshot file from a previous backup operation, or from a remaining
 [data directory]( https://etcd.io/docs/current/op-guide/configuration/#--data-dir).
+Here is an example:
+
+```shell
+ETCDCTL_API=3 etcdctl --endpoints 10.2.0.9:2379 snapshot restore snapshotdb
+```
+
 For more information and examples on restoring a cluster from a snapshot file, see
 [etcd disaster recovery documentation](https://etcd.io/docs/current/op-guide/recovery/#restoring-a-cluster).

@@ -324,4 +357,3 @@ We also recommend restarting any components (e.g. `kube-scheduler`,
 stale data. Note that in practice, the restore takes a bit of time.  During the
 restoration, critical components will lose leader lock and restart themselves.
 {{< /note >}}
-
@@ -54,7 +54,7 @@ Host: k8s-master:8080
 ```

 Note that Kubernetes does not need to know what a dongle is or what a dongle is for.
-The preceding PATCH request just tells Kubernetes that your Node has four things that
+The preceding PATCH request tells Kubernetes that your Node has four things that
 you call dongles.

 Start a proxy, so that you can easily send requests to the Kubernetes API server:
@@ -9,24 +9,17 @@ content_type: concept

 <!-- overview -->

-In addition to Kubernetes core components like api-server, scheduler, controller-manager running on a master machine
-there are a number of add-ons which, for various reasons, must run on a regular cluster node (rather than the Kubernetes master).
+Kubernetes core components such as the API server, scheduler, and controller-manager run on a control plane node. However, add-ons must run on a regular cluster node.
 Some of these add-ons are critical to a fully functional cluster, such as metrics-server, DNS, and UI.
 A cluster may stop working properly if a critical add-on is evicted (either manually or as a side effect of another operation like upgrade)
 and becomes pending (for example when the cluster is highly utilized and either there are other pending pods that schedule into the space
 vacated by the evicted critical add-on pod or the amount of resources available on the node changed for some other reason).

 Note that marking a pod as critical is not meant to prevent evictions entirely; it only prevents the pod from becoming permanently unavailable.
-For static pods, this means it can't be evicted, but for non-static pods, it just means they will always be rescheduled.
-
-
-
+A static pod marked as critical, can't be evicted. However, a non-static pods marked as critical are always rescheduled.

 <!-- body -->

-
 ### Marking pod as critical

 To mark a Pod as critical, set priorityClassName for that Pod to `system-cluster-critical` or `system-node-critical`. `system-node-critical` is the highest available priority, even higher than `system-cluster-critical`.
-
-
@@ -35,7 +35,7 @@ and kubeadm will use this CA for signing the rest of the certificates.

 ## External CA mode {#external-ca-mode}

-It is also possible to provide just the `ca.crt` file and not the
+It is also possible to provide only the `ca.crt` file and not the
 `ca.key` file (this is only available for the root CA file, not other cert pairs).
 If all other certificates and kubeconfig files are in place, kubeadm recognizes
 this condition and activates the "External CA" mode. kubeadm will proceed without the
@@ -170,7 +170,7 @@ controllerManager:

 ### Create certificate signing requests (CSR)

-See [Create CertificateSigningRequest](https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/#create-certificatesigningrequest) for creating CSRs with the Kubernetes API.
+See [Create CertificateSigningRequest](/docs/reference/access-authn-authz/certificate-signing-requests/#create-certificatesigningrequest) for creating CSRs with the Kubernetes API.

 ## Renew certificates with external CA

@@ -37,7 +37,7 @@ The upgrade workflow at high level is the following:

 ### Additional information

- [Draining nodes](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/) before kubelet MINOR version
+- [Draining nodes](/docs/tasks/administer-cluster/safely-drain-node/) before kubelet MINOR version
  upgrades is required. In the case of control plane nodes, they could be running CoreDNS Pods or other critical workloads.
 - All containers are restarted after upgrade, because the container spec hash value is changed.

@@ -50,7 +50,7 @@ and scheduling of Pods; on each node, the {{< glossary_tooltip text="kubelet" te
 uses the container runtime interface as an abstraction so that you can use any compatible
 container runtime.

-In its earliest releases, Kubernetes offered compatibility with just one container runtime: Docker.
+In its earliest releases, Kubernetes offered compatibility with one container runtime: Docker.
 Later in the Kubernetes project's history, cluster operators wanted to adopt additional container runtimes.
 The CRI was designed to allow this kind of flexibility - and the kubelet began supporting CRI. However,
 because Docker existed before the CRI specification was invented, the Kubernetes project created an
@@ -75,7 +75,7 @@ or execute something inside container using `docker exec`.

 If you're running workloads via Kubernetes, the best way to stop a container is through
 the Kubernetes API rather than directly through the container runtime (this advice applies
-for all container runtimes, not just Docker).
+for all container runtimes, not only Docker).

 {{< /note >}}

@@ -232,7 +232,7 @@ Apply the manifest to create a Deployment
 ```shell
 kubectl apply -f https://k8s.io/examples/admin/snowflake-deployment.yaml
 ```
-We have just created a deployment whose replica size is 2 that is running the pod called `snowflake` with a basic container that just serves the hostname.
+We have created a deployment whose replica size is 2 that is running the pod called `snowflake` with a basic container that serves the hostname.

 ```shell
 kubectl get deployment
@@ -196,7 +196,7 @@ This delete is asynchronous, so for a time you will see the namespace in the `Te
    ```shell
    kubectl create deployment snowflake --image=k8s.gcr.io/serve_hostname  -n=development --replicas=2
    ```
-    We have just created a deployment whose replica size is 2 that is running the pod called `snowflake` with a basic container that just serves the hostname.
+    We have created a deployment whose replica size is 2 that is running the pod called `snowflake` with a basic container that serves the hostname.

    ```shell
    kubectl get deployment -n=development
@@ -302,7 +302,7 @@ Use cases include:

 When you create a [Service](/docs/concepts/services-networking/service/), it creates a corresponding [DNS entry](/docs/concepts/services-networking/dns-pod-service/).
 This entry is of the form `<service-name>.<namespace-name>.svc.cluster.local`, which means
-that if a container just uses `<service-name>` it will resolve to the service which
+that if a container uses `<service-name>` it will resolve to the service which
 is local to a namespace.  This is useful for using the same configuration across
 multiple namespaces such as Development, Staging and Production.  If you want to reach
 across namespaces, you need to use the fully qualified domain name (FQDN).
@@ -20,7 +20,7 @@ Decide whether you want to deploy a [cloud](#creating-a-calico-cluster-with-goog

 **Prerequisite**: [gcloud](https://cloud.google.com/sdk/docs/quickstarts).

-1.  To launch a GKE cluster with Calico, just include the `--enable-network-policy` flag.
+1.  To launch a GKE cluster with Calico, include the `--enable-network-policy` flag.

    **Syntax**
    ```shell
@@ -128,8 +128,8 @@ curl -v -H 'Content-type: application/json' https://your-cluster-api-endpoint.ex

 The API can respond in one of three ways:

- If the eviction is granted, then the Pod is deleted just as if you had sent
-  a `DELETE` request to the Pod's URL and you get back `200 OK`.
+- If the eviction is granted, then the Pod is deleted as if you sent
+  a `DELETE` request to the Pod's URL and received back `200 OK`.
 - If the current state of affairs wouldn't allow an eviction by the rules set
  forth in the budget, you get back `429 Too Many Requests`. This is
  typically used for generic rate limiting of *any* requests, but here we mean
@@ -184,7 +184,7 @@ Where `YWRtaW5pc3RyYXRvcg==` decodes to `administrator`.

 ## Clean Up

-To delete the Secret you have just created:
+To delete the Secret you have created:

 ```shell
 kubectl delete secret mysecret
@@ -115,8 +115,7 @@ accidentally to an onlooker, or from being stored in a terminal log.

 ## Decoding the Secret  {#decoding-secret}

-To view the contents of the Secret we just created, you can run the following
-command:
+To view the contents of the Secret you created, run the following command:

 ```shell
 kubectl get secret db-user-pass -o jsonpath='{.data}'
@@ -125,10 +124,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
@@ -142,7 +141,7 @@ The output is similar to:

 ## Clean Up

-To delete the Secret you have just created:
+To delete the Secret you have created:

 ```shell
 kubectl delete secret db-user-pass
@@ -113,7 +113,7 @@ To check the actual content of the encoded data, please refer to

 ## Clean Up

-To delete the Secret you have just created:
+To delete the Secret you have created:

 ```shell
 kubectl delete secret db-user-pass-96mffmfh4k
@@ -112,7 +112,7 @@ kubectl top pod cpu-demo --namespace=cpu-example
 ```

 This example output shows that the Pod is using 974 milliCPU, which is
-just a bit less than the limit of 1 CPU specified in the Pod configuration.
+slightly less than the limit of 1 CPU specified in the Pod configuration.

 ```
 NAME                        CPU(cores)   MEMORY(bytes)
@@ -204,7 +204,7 @@ seconds.

 In addition to the readiness probe, this configuration includes a liveness probe.
 The kubelet will run the first liveness probe 15 seconds after the container
-starts. Just like the readiness probe, this will attempt to connect to the
+starts. Similar to the readiness probe, this will attempt to connect to the
 `goproxy` container on port 8080. If the liveness probe fails, the container
 will be restarted.

@@ -118,7 +118,7 @@ those secrets might also be visible to other users on your PC during the time th

 ## Inspecting the Secret `regcred`

-To understand the contents of the `regcred` Secret you just created, start by viewing the Secret in YAML format:
+To understand the contents of the `regcred` Secret you created, start by viewing the Secret in YAML format:

 ```shell
 kubectl get secret regcred --output=yaml
@@ -67,7 +67,7 @@ sudo yum -y install kompose
 {{% /tab %}}
 {{% tab name="Fedora package" %}}

-Kompose is in Fedora 24, 25 and 26 repositories. You can install it just like any other package.
+Kompose is in Fedora 24, 25 and 26 repositories. You can install it like any other package.

 ```bash
 sudo dnf -y install kompose
@@ -87,7 +87,7 @@ brew install kompose

 ## Use Kompose

-In just a few steps, we'll take you from Docker Compose to Kubernetes. All
+In a few steps, we'll take you from Docker Compose to Kubernetes. All
 you need is an existing `docker-compose.yml` file.

 1. Go to the directory containing your `docker-compose.yml` file. If you don't have one, test using this one.
@@ -177,7 +177,7 @@ kubectl describe pod nginx-deployment-1370807587-fz9sd

 Here you can see the event generated by the scheduler saying that the Pod failed to schedule for reason `FailedScheduling` (and possibly others).  The message tells us that there were not enough resources for the Pod on any of the nodes.

-To correct this situation, you can use `kubectl scale` to update your Deployment to specify four or fewer replicas. (Or you could just leave the one Pod pending, which is harmless.)
+To correct this situation, you can use `kubectl scale` to update your Deployment to specify four or fewer replicas. (Or you could leave the one Pod pending, which is harmless.)

 Events such as the ones you saw at the end of `kubectl describe pod` are persisted in etcd and provide high-level information on what is happening in the cluster. To list all events you can use

@@ -57,7 +57,7 @@ case you can try several things:
  will never be scheduled.

    You can check node capacities with the `kubectl get nodes -o <format>`
-    command. Here are some example command lines that extract just the necessary
+    command. Here are some example command lines that extract the necessary
    information:

    ```shell
@@ -178,7 +178,7 @@ kubectl expose deployment hostnames --port=80 --target-port=9376
 service/hostnames exposed
 ```

-And read it back, just to be sure:
+And read it back:

 ```shell
 kubectl get svc hostnames
@@ -427,8 +427,7 @@ hostnames-632524106-ly40y   1/1       Running   0          1h
 hostnames-632524106-tlaok   1/1       Running   0          1h
 ```

-The `-l app=hostnames` argument is a label selector - just like our Service
-has.
+The `-l app=hostnames` argument is a label selector configured on the Service.

 The "AGE" column says that these Pods are about an hour old, which implies that
 they are running fine and not crashing.
@@ -607,7 +606,7 @@ iptables-save | grep hostnames
 -A KUBE-PORTALS-HOST -d 10.0.1.175/32 -p tcp -m comment --comment "default/hostnames:default" -m tcp --dport 80 -j DNAT --to-destination 10.240.115.247:48577
 ```

-There should be 2 rules for each port of your Service (just one in this
+There should be 2 rules for each port of your Service (only one in this
 example) - a "KUBE-PORTALS-CONTAINER" and a "KUBE-PORTALS-HOST".

 Almost nobody should be using the "userspace" mode any more, so you won't spend
@@ -294,9 +294,9 @@ a running cluster in the [Deploying section](#deploying).

 ### Changing `DaemonSet` parameters

-When you have the Stackdriver Logging `DaemonSet` in your cluster, you can just modify the
-`template` field in its spec, daemonset controller will update the pods for you. For example,
-let's assume you've just installed the Stackdriver Logging as described above. Now you want to
+When you have the Stackdriver Logging `DaemonSet` in your cluster, you can modify the
+`template` field in its spec. The DaemonSet controller manages the pods for you.
+For example, assume you've installed the Stackdriver Logging as described above. Now you want to
 change the memory limit to give fluentd more memory to safely process more logs.

 Get the spec of `DaemonSet` running in your cluster:
@@ -12,7 +12,7 @@ weight: 20
 Kubernetes ships with a default scheduler that is described
 [here](/docs/reference/command-line-tools-reference/kube-scheduler/).
 If the default scheduler does not suit your needs you can implement your own scheduler.
-Not just that, you can even run multiple schedulers simultaneously alongside the default
+Moreover, you can even run multiple schedulers simultaneously alongside the default
 scheduler and instruct Kubernetes what scheduler to use for each of your pods. Let's
 learn how to run multiple schedulers in Kubernetes with an example.

@@ -30,7 +30,7 @@ in the Kubernetes source directory for a canonical example.
 ## Package the scheduler

 Package your scheduler binary into a container image. For the purposes of this example,
-let's just use the default scheduler (kube-scheduler) as our second scheduler as well.
+you can use the default scheduler (kube-scheduler) as your second scheduler.
 Clone the [Kubernetes source code from GitHub](https://github.com/kubernetes/kubernetes)
 and build the source.

@@ -61,9 +61,9 @@ gcloud docker -- push gcr.io/my-gcp-project/my-kube-scheduler:1.0

 ## Define a Kubernetes Deployment for the scheduler

-Now that we have our scheduler in a container image, we can just create a pod
-config for it and run it in our Kubernetes cluster. But instead of creating a pod
-directly in the cluster, let's use a [Deployment](/docs/concepts/workloads/controllers/deployment/)
+Now that you have your scheduler in a container image, create a pod
+configuration for it and run it in your Kubernetes cluster. But instead of creating a pod
+directly in the cluster, you can use a [Deployment](/docs/concepts/workloads/controllers/deployment/)
 for this example. A [Deployment](/docs/concepts/workloads/controllers/deployment/) manages a
 [Replica Set](/docs/concepts/workloads/controllers/replicaset/) which in turn manages the pods,
 thereby making the scheduler resilient to failures. Here is the deployment
@@ -83,7 +83,7 @@ detailed description of other command line arguments.

 ## Run the second scheduler in the cluster

-In order to run your scheduler in a Kubernetes cluster, just create the deployment
+In order to run your scheduler in a Kubernetes cluster, create the deployment
 specified in the config above in a Kubernetes cluster:

 ```shell
@@ -132,9 +132,9 @@ kubectl edit clusterrole system:kube-scheduler

 ## Specify schedulers for pods

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

 - Pod spec without any scheduler name
@@ -196,7 +196,7 @@ while the other two pods get scheduled. Once we submit the scheduler deployment
 and our new scheduler starts running, the `annotation-second-scheduler` pod gets
 scheduled as well.

-Alternatively, one could just look at the "Scheduled" entries in the event logs to
+Alternatively, you can look at the "Scheduled" entries in the event logs to
 verify that the pods were scheduled by the desired schedulers.

 ```shell
@@ -404,7 +404,7 @@ how to [authenticate API servers](/docs/reference/access-authn-authz/extensible-
 A conversion webhook must not mutate anything inside of `metadata` of the converted object
 other than `labels` and `annotations`.
 Attempted changes to `name`, `UID` and `namespace` are rejected and fail the request
-which caused the conversion. All other changes are just ignored.  
+which caused the conversion. All other changes are ignored.  

 ### Deploy the conversion webhook service

@@ -520,7 +520,7 @@ CustomResourceDefinition and migrating your objects from one version to another.
 ### Finalizers

 *Finalizers* allow controllers to implement asynchronous pre-delete hooks.
-Custom objects support finalizers just like built-in objects.
+Custom objects support finalizers similar to built-in objects.

 You can add a finalizer to a custom object like this:

@@ -41,7 +41,7 @@ Alternatively, you can use an existing 3rd party solution, such as [apiserver-bu
 1. Make sure that your extension-apiserver loads those certs from that volume and that they are used in the HTTPS handshake.
 1. Create a Kubernetes service account in your namespace.
 1. Create a Kubernetes cluster role for the operations you want to allow on your resources.
-1. Create a Kubernetes cluster role binding from the service account in your namespace to the cluster role you just created.
+1. Create a Kubernetes cluster role binding from the service account in your namespace to the cluster role you created.
 1. Create a Kubernetes cluster role binding from the service account in your namespace to the `system:auth-delegator` cluster role to delegate auth decisions to the Kubernetes core API server.
 1. Create a Kubernetes role binding from the service account in your namespace to the `extension-apiserver-authentication-reader` role. This allows your extension api-server to access the `extension-apiserver-authentication` configmap.
 1. Create a Kubernetes apiservice. The CA cert above should be base64 encoded, stripped of new lines and used as the spec.caBundle in the apiservice. This should not be namespaced. If using the [kube-aggregator API](https://github.com/kubernetes/kube-aggregator/), only pass in the PEM encoded CA bundle because the base 64 encoding is done for you.
@@ -19,7 +19,7 @@ Here is an overview of the steps in this example:
 1. **Start a message queue service.**  In this example, we use RabbitMQ, but you could use another
   one.  In practice you would set up a message queue service once and reuse it for many jobs.
 1. **Create a queue, and fill it with messages.**  Each message represents one task to be done.  In
-   this example, a message is just an integer that we will do a lengthy computation on.
+   this example, a message is an integer that we will do a lengthy computation on.
 1. **Start a Job that works on tasks from the queue**.  The Job starts several pods.  Each pod takes
   one task from the message queue, processes it, and repeats until the end of the queue is reached.

@@ -141,13 +141,12 @@ root@temp-loe07:/#
 ```

 In the last command, the `amqp-consume` tool takes one message (`-c 1`)
-from the queue, and passes that message to the standard input of an arbitrary command.  In this case, the program `cat` is just printing
-out what it gets on the standard input, and the echo is just to add a carriage
+from the queue, and passes that message to the standard input of an arbitrary command.  In this case, the program `cat` prints out the characters read from standard input, and the echo adds a carriage
 return so the example is readable.

 ## Filling the Queue with tasks

-Now let's fill the queue with some "tasks".  In our example, our tasks are just strings to be
+Now let's fill the queue with some "tasks".  In our example, our tasks are strings to be
 printed.

 In a practice, the content of the messages might be:
@@ -21,7 +21,7 @@ Here is an overview of the steps in this example:
   detect when a finite-length work queue is empty.  In practice you would set up a store such
   as Redis once and reuse it for the work queues of many jobs, and other things.
 1. **Create a queue, and fill it with messages.**  Each message represents one task to be done.  In
-   this example, a message is just an integer that we will do a lengthy computation on.
+   this example, a message is an integer that we will do a lengthy computation on.
 1. **Start a Job that works on tasks from the queue**.  The Job starts several pods.  Each pod takes
   one task from the message queue, processes it, and repeats until the end of the queue is reached.

@@ -55,7 +55,7 @@ You could also download the following files directly:

 ## Filling the Queue with tasks

-Now let's fill the queue with some "tasks".  In our example, our tasks are just strings to be
+Now let's fill the queue with some "tasks".  In our example, our tasks are strings to be
 printed.

 Start a temporary interactive pod for running the Redis CLI.
@@ -25,7 +25,7 @@ You should already know how to [perform a rolling update on a

 ### Step 1: Find the DaemonSet revision you want to roll back to

-You can skip this step if you just want to roll back to the last revision.
+You can skip this step if you only want to roll back to the last revision.

 List all revisions of a DaemonSet:

@@ -111,7 +111,7 @@ kubectl edit ds/fluentd-elasticsearch -n kube-system

 ##### Updating only the container image

-If you just need to update the container image in the DaemonSet template, i.e.
+If you only need to update the container image in the DaemonSet template, i.e.
 `.spec.template.spec.containers[*].image`, use `kubectl set image`:

 ```shell
@@ -167,7 +167,7 @@ If the recent DaemonSet template update is broken, for example, the container is
 crash looping, or the container image doesn't exist (often due to a typo),
 DaemonSet rollout won't progress.

-To fix this, just update the DaemonSet template again. New rollout won't be
+To fix this, update the DaemonSet template again. New rollout won't be
 blocked by previous unhealthy rollouts.

 #### Clock skew
@@ -37,7 +37,7 @@ When the above conditions are true, Kubernetes will expose `amd.com/gpu` or
 `nvidia.com/gpu` as a schedulable resource.

 You can consume these GPUs from your containers by requesting
-`<vendor>.com/gpu` just like you request `cpu` or `memory`.
+`<vendor>.com/gpu` the same way you request `cpu` or `memory`.
 However, there are some limitations in how you specify the resource requirements
 when using GPUs:

@@ -43,8 +43,8 @@ You may need to delete the associated headless service separately after the Stat
 kubectl delete service <service-name>
 ```

-Deleting a StatefulSet through kubectl will scale it down to 0, thereby deleting all pods that are a part of it. 
-If you want to delete just the StatefulSet and not the pods, use `--cascade=false`.
+When deleting a StatefulSet through `kubectl`, the StatefulSet scales down to 0. All Pods that are part of this workload are also deleted. If you want to delete only the StatefulSet and not the Pods, use `--cascade=false`.
+For example:

 ```shell
 kubectl delete -f <file.yaml> --cascade=false
@@ -44,7 +44,7 @@ for StatefulSet Pods. Graceful deletion is safe and will ensure that the Pod
 [shuts down gracefully](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)
 before the kubelet deletes the name from the apiserver.

-Kubernetes (versions 1.5 or newer) will not delete Pods just because a Node is unreachable.
+A Pod is not deleted automatically when a node is unreachable.
 The Pods running on an unreachable Node enter the 'Terminating' or 'Unknown' state after a
 [timeout](/docs/concepts/architecture/nodes/#condition).
 Pods may also enter these states when the user attempts graceful deletion of a Pod
@@ -382,7 +382,7 @@ with *external metrics*.

 Using external metrics requires knowledge of your monitoring system; the setup is
 similar to that required when using custom metrics. External metrics allow you to autoscale your cluster
-based on any metric available in your monitoring system. Just provide a `metric` block with a
+based on any metric available in your monitoring system. Provide a `metric` block with a
 `name` and `selector`, as above, and use the `External` metric type instead of `Object`.
 If multiple time series are matched by the `metricSelector`,
 the sum of their values is used by the HorizontalPodAutoscaler.
@@ -23,9 +23,7 @@ Pod Autoscaling does not apply to objects that can't be scaled, for example, Dae

 The Horizontal Pod Autoscaler is implemented as a Kubernetes API resource and a controller.
 The resource determines the behavior of the controller.
-The controller periodically adjusts the number of replicas in a replication controller or deployment
-to match the observed average CPU utilization to the target specified by user.
-
+The controller periodically adjusts the number of replicas in a replication controller or deployment to match the observed metrics such as average CPU utilisation, average memory utilisation or any other custom metric to the target specified by the user.



@@ -162,7 +160,7 @@ can be fetched, scaling is skipped. This means that the HPA is still capable
 of scaling up if one or more metrics give a `desiredReplicas` greater than
 the current value.

-Finally, just before HPA scales the target, the scale recommendation is recorded.  The
+Finally, right before HPA scales the target, the scale recommendation is recorded.  The
 controller considers all recommendations within a configurable window choosing the
 highest recommendation from within that window. This value can be configured using the `--horizontal-pod-autoscaler-downscale-stabilization` flag, which defaults to 5 minutes.
 This means that scaledowns will occur gradually, smoothing out the impact of rapidly
@@ -39,6 +39,7 @@ on general patterns for running stateful applications in Kubernetes.
  [ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/).
 * Some familiarity with MySQL helps, but this tutorial aims to present
  general patterns that should be useful for other systems.
+* You are using the default namespace or another namespace that does not contain any conflicting objects.



@@ -534,10 +535,9 @@ kubectl delete pvc data-mysql-4
 * Learn more about [debugging a StatefulSet](/docs/tasks/debug-application-cluster/debug-stateful-set/).
 * Learn more about [deleting a StatefulSet](/docs/tasks/run-application/delete-stateful-set/).
 * Learn more about [force deleting StatefulSet Pods](/docs/tasks/run-application/force-delete-stateful-set-pod/).
-* Look in the [Helm Charts repository](https://github.com/kubernetes/charts)
+* Look in the [Helm Charts repository](https://artifacthub.io/)
  for other stateful application examples.




-
@@ -12,10 +12,7 @@ You can use the GCP [Service Catalog Installer](https://github.com/GoogleCloudPl
 tool to easily install or uninstall Service Catalog on your Kubernetes cluster, linking it to
 Google Cloud projects.

-Service Catalog itself can work with any kind of managed service, not just Google Cloud.
-
-
-
+Service Catalog can work with any kind of managed service, not only Google Cloud.

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

@@ -17,9 +17,9 @@ and view logs. For more information including a complete list of kubectl operati
 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)
+- [Install kubectl on Linux](/docs/tasks/tools/install-kubectl-linux)
+- [Install kubectl on macOS](/docs/tasks/tools/install-kubectl-macos)
+- [Install kubectl on Windows](/docs/tasks/tools/install-kubectl-windows)

 ## kind