Merge remote-tracking branch 'upstream/master' into dev-1.20

2020-11-19 17:09:49 +01:00
parent 2faaed676c 3cc410cd01
commit ba77c903ed
82 changed files with 4390 additions and 2129 deletions
@@ -31,7 +31,7 @@ This lets you fetch a container image running in the cloud and
 debug the exact same code locally if needed.

 A ConfigMap is not designed to hold large chunks of data. The data stored in a
-ConfigMap cannot exeed 1 MiB. If you need to store settings that are
+ConfigMap cannot exceed 1 MiB. If you need to store settings that are
 larger than this limit, you may want to consider mounting a volume or use a
 separate database or file service.

@@ -88,7 +88,7 @@ data:
 There are four different ways that you can use a ConfigMap to configure
 a container inside a Pod:

-1. Command line arguments to the entrypoint of a container
+1. Inside a container command and args
 1. Environment variables for a container
 1. Add a file in read-only volume, for the application to read
 1. Write code to run inside the Pod that uses the Kubernetes API to read a ConfigMap
@@ -22,6 +22,8 @@ Kubernetes as a project currently supports and maintains [GCE](https://git.k8s.i

 ## Additional controllers

+{{% thirdparty-content %}}
+
 * [AKS Application Gateway Ingress Controller](https://github.com/Azure/application-gateway-kubernetes-ingress) is an ingress controller that enables ingress to [AKS clusters](https://docs.microsoft.com/azure/aks/kubernetes-walkthrough-portal) using the [Azure Application Gateway](https://docs.microsoft.com/azure/application-gateway/overview).
 * [Ambassador](https://www.getambassador.io/) API Gateway is an [Envoy](https://www.envoyproxy.io) based ingress 
  controller with [community](https://www.getambassador.io/docs) or 
@@ -94,7 +94,7 @@ run, what volume plugin it uses (including Flex), etc. The repository
 [kubernetes-sigs/sig-storage-lib-external-provisioner](https://github.com/kubernetes-sigs/sig-storage-lib-external-provisioner)
 houses a library for writing external provisioners that implements the bulk of
 the specification. Some external provisioners are listed under the repository
-[kubernetes-sigs/external-storage](https://github.com/kubernetes-sigs/external-dns).
+[kubernetes-sigs/sig-storage-lib-external-provisioner](https://github.com/kubernetes-sigs/sig-storage-lib-external-provisioner).

 For example, NFS doesn't provide an internal provisioner, but an external
 provisioner can be used. There are also cases when 3rd party storage
@@ -150,7 +150,7 @@ remembered and reused, even after the Pod is running, for at least a few seconds
 If you need to discover Pods promptly after they are created, you have a few options:

 - Query the Kubernetes API directly (for example, using a watch) rather than relying on DNS lookups.
- Decrease the time of caching in your Kubernetes DNS provider (tpyically this means editing the config map for CoreDNS, which currently caches for 30 seconds).
+- Decrease the time of caching in your Kubernetes DNS provider (typically this means editing the config map for CoreDNS, which currently caches for 30 seconds).


 As mentioned in the [limitations](#limitations) section, you are responsible for
@@ -142,7 +142,7 @@ The `restartPolicy` applies to all containers in the Pod. `restartPolicy` only
 refers to restarts of the containers by the kubelet on the same node. After containers
 in a Pod exit, the kubelet restarts them with an exponential back-off delay (10s, 20s,
 40s, …), that is capped at five minutes. Once a container has executed for 10 minutes
-without any problems, the kubelet resets the restart backoff timer forthat container.
+without any problems, the kubelet resets the restart backoff timer for that container.

 ## Pod conditions

@@ -1,6 +1,6 @@
 ---
 content_type: concept
-title: Contribute to Kubernetes docs
+title: Contribute to K8s docs
 linktitle: Contribute
 main_menu: true
 no_list: true
@@ -8,7 +8,7 @@ weight: 80
 card:
  name: contribute
  weight: 10
-  title: Start contributing
+  title: Start contributing to K8s
 ---

 <!-- overview -->
@@ -43,7 +43,7 @@ When opening a pull request, you need to know in advance which branch to base yo
 Scenario | Branch
 :---------|:------------
 Existing or new English language content for the current release | `master`
-Content for a feature change release | The branch which corresponds to the major and minor version the feature change is in, using the pattern `dev-release-<version>`. For example, if a feature changes in the `{{< latest-version >}}` release, then add documentation changes to the ``dev-{{< release-branch >}}`` branch.
+Content for a feature change release | The branch which corresponds to the major and minor version the feature change is in, using the pattern `dev-<version>`. For example, if a feature changes in the `v{{< skew nextMinorVersion >}}` release, then add documentation changes to the ``dev-{{< skew nextMinorVersion >}}`` branch.
 Content in other languages (localizations) | Use the localization's convention. See the [Localization branching strategy](/docs/contribute/localization/#branching-strategy) for more information.


@@ -32,7 +32,7 @@ cards:
  button: "View Tutorials"
  button_path: "/docs/tutorials"
 - name: setup
-  title: "Set up a cluster"
+  title: "Set up a K8s cluster"
  description: "Get Kubernetes running based on your resources and needs."
  button: "Set up Kubernetes"
  button_path: "/docs/setup"
@@ -57,7 +57,7 @@ cards:
  button: Contribute to the docs
  button_path: /docs/contribute
 - name: release-notes
-  title: Release Notes
+  title: K8s Release Notes
  description: If you are installing Kubernetes or upgrading to the newest version, refer to the current release notes.
  button: "Download Kubernetes"
  button_path: "/docs/setup/release/notes"
@@ -143,13 +143,15 @@ different Kubernetes components.
 | `RotateKubeletServerCertificate` | `false` | Alpha | 1.7 | 1.11 |
 | `RotateKubeletServerCertificate` | `true` | Beta | 1.12 | |
 | `RunAsGroup` | `true` | Beta | 1.14 | |
-| `ServiceAppProtocol` | `false` | Alpha | 1.18 | 1.18 |
-| `ServiceAppProtocol` | `true` | Beta | 1.19 | |
+| `RuntimeClass` | `false` | Alpha | 1.12 | 1.13 |
+| `RuntimeClass` | `true` | Beta | 1.14 | |
+| `SCTPSupport` | `false` | Alpha | 1.12 | 1.18 |
+| `SCTPSupport` | `true` | Beta | 1.19 | |
 | `ServerSideApply` | `false` | Alpha | 1.14 | 1.15 |
 | `ServerSideApply` | `true` | Beta | 1.16 | |
-| `ServiceAccountIssuerDiscovery` | `false` | Alpha | 1.18 | 1.19 |
-| `ServiceAccountIssuerDiscovery` | `true` | Beta | 1.20 | |
-| `ServiceAppProtocol` | `false` | Alpha | 1.18 | |
+| `ServiceAccountIssuerDiscovery` | `false` | Alpha | 1.18 | |
+| `ServiceAppProtocol` | `false` | Alpha | 1.18 | 1.18 |
+| `ServiceAppProtocol` | `true` | Beta | 1.19 | |
 | `ServiceNodeExclusion` | `false` | Alpha | 1.8 | 1.18 |
 | `ServiceNodeExclusion` | `true` | Beta | 1.19 | |
 | `ServiceTopology` | `false` | Alpha | 1.17 | |
@@ -27,15 +27,15 @@ The following examples will show how you can interact with the health API endpoi
 For all endpoints you can use the `verbose` parameter to print out the checks and their status.
 This can be useful for a human operator to debug the current status of the Api server, it is not intended to be consumed by a machine:

-    ```shell
-    curl -k https://localhost:6443/livez?verbose
-    ```
+```shell
+curl -k https://localhost:6443/livez?verbose
+```

 or from a remote host with authentication:

-    ```shell
-    kubectl get --raw='/readyz?verbose'
-    ```
+```shell
+kubectl get --raw='/readyz?verbose'
+```

 The output will look like this:

@@ -62,9 +62,9 @@ The output will look like this:
 The Kubernetes API server also supports to exclude specific checks.
 The query parameters can also be combined like in this example:

-    ```shell
-    curl -k 'https://localhost:6443/readyz?verbose&exclude=etcd'
-    ```
+```shell
+curl -k 'https://localhost:6443/readyz?verbose&exclude=etcd'
+```

 The output show that the `etcd` check is excluded:

@@ -98,6 +98,6 @@ The schema for the individual health checks is `/livez/<healthcheck-name>` where
 The `<healthcheck-name>` path can be discovered using the `verbose` flag from above and take the path between `[+]` and `ok`.
 These individual health checks should not be consumed by machines but can be helpful for a human operator to debug a system:

-    ```shell
-    curl -k https://localhost:6443/livez/etcd
-    ```
+```shell
+curl -k https://localhost:6443/livez/etcd
+```
@@ -25,10 +25,11 @@ daemons installed:
 ## Running Node Conformance Test

 To run the node conformance test, perform the following steps:
-
-1. Point your Kubelet to localhost `--api-servers="http://localhost:8080"`,
-because the test framework starts a local master to test Kubelet. There are some
-other Kubelet flags you may care:
+1. Work out the value of the `--kubeconfig` option for the kubelet; for example:
+   `--kubeconfig=/var/lib/kubelet/config.yaml`.
+    Because the test framework starts a local control plane to test the kubelet,
+    use `http://localhost:8080` as the URL of the API server.
+    There are some other kubelet command line parameters you may want to use:
  * `--pod-cidr`: If you are using `kubenet`, you should specify an arbitrary CIDR
    to Kubelet, for example `--pod-cidr=10.180.0.0/24`.
  * `--cloud-provider`: If you are using `--cloud-provider=gce`, you should
@@ -50,7 +50,7 @@ this example.


 1. Configure the kubelet to be a service manager for etcd.
-  
+
   {{< note >}}You must do this on every host where etcd should be running.{{< /note >}}
    Since etcd was created first, you must override the service priority by creating a new unit file
    that has higher precedence than the kubeadm-provided kubelet unit file.
@@ -68,6 +68,12 @@ this example.
    systemctl restart kubelet
    ```

+    Check the kubelet status to ensure it is running.
+
+    ```sh
+    systemctl status kubelet
+    ```
+
 1. Create configuration files for kubeadm.

    Generate one kubeadm configuration file for each host that will have an etcd
@@ -140,7 +140,7 @@ curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/dow
 ### Joining a Windows worker node
 {{< note >}}
 You must install the `Containers` feature and install Docker. Instructions
-to do so are available at [Install Docker Engine - Enterprise on Windows Servers](https://docs.mirantis.com/docker-enterprise/v3.1/dockeree-products/docker-engine-enterprise/dee-windows.html).
+to do so are available at [Install Docker Engine - Enterprise on Windows Servers](https://hub.docker.com/editions/enterprise/docker-ee-server-windows).
 {{< /note >}}

 {{< note >}}
@@ -532,7 +532,7 @@ This functionality is available in Kubernetes v1.6 and later.

 ## Use ConfigMap-defined environment variables in Pod commands

-You can use ConfigMap-defined environment variables in the `command` section of the Pod specification using the `$(VAR_NAME)` Kubernetes substitution syntax.
+You can use ConfigMap-defined environment variables in the `command` and `args` of a container using the `$(VAR_NAME)` Kubernetes substitution syntax.

 For example, the following Pod specification

@@ -24,10 +24,35 @@ The following steps require an egress configuration, for example:
 You need to configure the API Server to use the Konnectivity service
 and direct the network traffic to the cluster nodes:

+1. Make sure that
+the `ServiceAccountTokenVolumeProjection` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
+is enabled. You can enable
+[service account token volume protection](/docs/tasks/configure-pod-container/configure-service-account/#service-account-token-volume-projection)
+by providing the following flags to the kube-apiserver:
+   ```
+   --service-account-issuer=api
+   --service-account-signing-key-file=/etc/kubernetes/pki/sa.key
+   --api-audiences=system:konnectivity-server
+   ```
 1. Create an egress configuration file such as `admin/konnectivity/egress-selector-configuration.yaml`.
 1. Set the `--egress-selector-config-file` flag of the API Server to the path of
 your API Server egress configuration file.

+Generate or obtain a certificate and kubeconfig for konnectivity-server.  
+For example, you can use the OpenSSL command line tool to issue a X.509 certificate,
+using the cluster CA certificate `/etc/kubernetes/pki/ca.crt` from a control-plane host.
+
+```bash
+openssl req -subj "/CN=system:konnectivity-server" -new -newkey rsa:2048 -nodes -out konnectivity.csr -keyout konnectivity.key -out konnectivity.csr
+openssl x509 -req -in konnectivity.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out konnectivity.crt -days 375 -sha256
+SERVER=$(kubectl config view -o jsonpath='{.clusters..server}')
+kubectl --kubeconfig /etc/kubernetes/konnectivity-server.conf config set-credentials system:konnectivity-server --client-certificate konnectivity.crt --client-key konnectivity.key --embed-certs=true
+kubectl --kubeconfig /etc/kubernetes/konnectivity-server.conf config set-cluster kubernetes --server "$SERVER" --certificate-authority /etc/kubernetes/pki/ca.crt --embed-certs=true
+kubectl --kubeconfig /etc/kubernetes/konnectivity-server.conf config set-context system:konnectivity-server@kubernetes --cluster kubernetes --user system:konnectivity-server
+kubectl --kubeconfig /etc/kubernetes/konnectivity-server.conf config use-context system:konnectivity-server@kubernetes
+rm -f konnectivity.crt konnectivity.key konnectivity.csr
+```
+
 Next, you need to deploy the Konnectivity server and agents.
 [kubernetes-sigs/apiserver-network-proxy](https://github.com/kubernetes-sigs/apiserver-network-proxy)
 is a reference implementation.
@@ -46,7 +46,7 @@ tutorial.
 After this tutorial, you will know the following.

 -   How to deploy a ZooKeeper ensemble using StatefulSet.
-   How to consistently configure the ensemble using ConfigMaps.
+-   How to consistently configure the ensemble.
 -   How to spread the deployment of ZooKeeper servers in the ensemble.
 -   How to use PodDisruptionBudgets to ensure service availability during planned maintenance.

@@ -770,7 +770,7 @@ In one terminal window, use the following command to watch the Pods in the `zk`
 kubectl get pod -w -l app=zk
 ```

-In another window, using the following command to delete the `zkOk.sh` script from the file system of Pod `zk-0`.
+In another window, using the following command to delete the `zookeeper-ready` script from the file system of Pod `zk-0`.

 ```shell
 kubectl exec zk-0 -- rm /usr/bin/zookeeper-ready