Merge branch 'master' into patch-1

Author: iamhesir

OWNERS_ALIASES

@@ -10,6 +10,7 @@ aliases:
     - kbarnard10
     - mrbobbytables
     - onlydole
+    - sftim
   sig-docs-de-owners: # Admins for German content
     - bene2k1
     - mkorbi

content/en/blog/_posts/2020-12-02-dockershim-faq.md

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

content/en/docs/concepts/cluster-administration/_index.md

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

content/en/docs/concepts/cluster-administration/certificates.md

@@ -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/).

content/en/docs/concepts/configuration/secret.md

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

content/en/docs/concepts/containers/container-environment.md

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

content/en/docs/concepts/overview/components.md

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

content/en/docs/concepts/overview/working-with-objects/labels.md

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

content/en/docs/concepts/services-networking/service.md

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

content/en/docs/concepts/workloads/pods/disruptions.md

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