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
@@ -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