Merge pull request #27242 from PI-Victor/merged-master-dev-1.21

Merge master into dev-1.21
2021-03-26 16:18:44 -07:00
parent d90858eacd ca046d9b1f
commit 2fd1799846
200 changed files with 4310 additions and 2439 deletions
@@ -19,7 +19,7 @@ Attribute-based access control (ABAC) defines an access control paradigm whereby
 To enable `ABAC` mode, specify `--authorization-policy-file=SOME_FILENAME` and `--authorization-mode=ABAC` on startup.

 The file format is [one JSON object per line](https://jsonlines.org/).  There
-should be no enclosing list or map, just one map per line.
+should be no enclosing list or map, only one map per line.

 Each line is a "policy object", where each such object is a map with the following
 properties:
@@ -193,7 +193,7 @@ This admission controller will deny exec and attach commands to pods that run wi
 allow host access.  This includes pods that run as privileged, have access to the host IPC namespace, and
 have access to the host PID namespace.

-The DenyEscalatingExec admission plugin is deprecated and will be removed in v1.21.
+The DenyEscalatingExec admission plugin is deprecated.

 Use of a policy-based admission plugin (like [PodSecurityPolicy](#podsecuritypolicy) or a custom admission plugin)
 which can be targeted at specific users or Namespaces and also protects against creation of overly privileged Pods
@@ -206,7 +206,7 @@ is recommended instead.
 This admission controller will intercept all requests to exec a command in a pod if that pod has a privileged container.

 This functionality has been merged into [DenyEscalatingExec](#denyescalatingexec).
-The DenyExecOnPrivileged admission plugin is deprecated and will be removed in v1.21.
+The DenyExecOnPrivileged admission plugin is deprecated.

 Use of a policy-based admission plugin (like [PodSecurityPolicy](#podsecuritypolicy) or a custom admission plugin)
 which can be targeted at specific users or Namespaces and also protects against creation of overly privileged Pods
@@ -458,7 +458,7 @@ clusters:
  - name: name-of-remote-authn-service
    cluster:
      certificate-authority: /path/to/ca.pem         # CA for verifying the remote service.
-      server: https://authn.example.com/authenticate # URL of remote service to query. Must use 'https'.
+      server: https://authn.example.com/authenticate # URL of remote service to query. 'https' recommended for production.

 # users refers to the API server's webhook configuration.
 users:
@@ -138,7 +138,7 @@ no
 exposes the API server authorization to external services. Other resources in
 this group include:

-* `SubjectAccessReview` - Access review for any user, not just the current one. Useful for delegating authorization decisions to the API server. For example, the kubelet and extension API servers use this to determine user access to their own APIs.
+* `SubjectAccessReview` - Access review for any user, not only the current one. Useful for delegating authorization decisions to the API server. For example, the kubelet and extension API servers use this to determine user access to their own APIs.
 * `LocalSubjectAccessReview` - Like `SubjectAccessReview` but restricted to a specific namespace.
 * `SelfSubjectRulesReview` - A review which returns the set of actions a user can perform within a namespace. Useful for users to quickly summarize their own access, or for UIs to hide/show actions.

@@ -167,7 +167,7 @@ data:
    users: []
 ```

-The `kubeconfig` member of the ConfigMap is a config file with just the cluster
+The `kubeconfig` member of the ConfigMap is a config file with only the cluster
 information filled out.  The key thing being communicated here is the
 `certificate-authority-data`.  This may be expanded in the future.

@@ -196,8 +196,8 @@ O is the group that this user will belong to. You can refer to
 [RBAC](/docs/reference/access-authn-authz/rbac/) for standard groups.

 ```shell
-openssl genrsa -out john.key 2048
-openssl req -new -key john.key -out john.csr
+openssl genrsa -out myuser.key 2048
+openssl req -new -key myuser.key -out myuser.csr
 ```

 ### Create CertificateSigningRequest
@@ -209,7 +209,7 @@ cat <<EOF | kubectl apply -f -
 apiVersion: certificates.k8s.io/v1
 kind: CertificateSigningRequest
 metadata:
-  name: john
+  name: myuser
 spec:
  groups:
  - system:authenticated
@@ -224,7 +224,7 @@ Some points to note:

 - `usages` has to be '`client auth`'
 - `request` is the base64 encoded value of the CSR file content.
-  You can get the content using this command: ```cat john.csr | base64 | tr -d "\n"```
+  You can get the content using this command: ```cat myuser.csr | base64 | tr -d "\n"```

 ### Approve certificate signing request

@@ -239,7 +239,7 @@ kubectl get csr
 Approve the CSR:

 ```shell
-kubectl certificate approve john
+kubectl certificate approve myuser
 ```

 ### Get the certificate
@@ -247,11 +247,17 @@ kubectl certificate approve john
 Retrieve the certificate from the CSR:

 ```shell
-kubectl get csr/john -o yaml
+kubectl get csr/myuser -o yaml
 ```

 The certificate value is in Base64-encoded format under `status.certificate`.

+Export the issued certificate from the CertificateSigningRequest.
+
+```
+kubectl get csr myuser -o jsonpath='{.status.certificate}'| base64 -d > myuser.crt
+```
+
 ### Create Role and RoleBinding

 With the certificate created. it is time to define the Role and RoleBinding for
@@ -266,31 +272,30 @@ kubectl create role developer --verb=create --verb=get --verb=list --verb=update
 This is a sample command to create a RoleBinding for this new user:

 ```shell
-kubectl create rolebinding developer-binding-john --role=developer --user=john
+kubectl create rolebinding developer-binding-myuser --role=developer --user=myuser
 ```

 ### Add to kubeconfig

 The last step is to add this user into the kubeconfig file.
-This example assumes the key and certificate files are located at "/home/vagrant/work/".

 First, you need to add new credentials:

 ```
-kubectl config set-credentials john --client-key=/home/vagrant/work/john.key --client-certificate=/home/vagrant/work/john.crt --embed-certs=true
+kubectl config set-credentials myuser --client-key=myuser.key --client-certificate=myuser.crt --embed-certs=true

 ```

 Then, you need to add the context:

 ```
-kubectl config set-context john --cluster=kubernetes --user=john
+kubectl config set-context myuser --cluster=kubernetes --user=myuser
 ```

-To test it, change the context to `john`:
+To test it, change the context to `myuser`:

 ```
-kubectl config use-context john
+kubectl config use-context myuser
 ```

 ## Approval or rejection  {#approval-rejection}
@@ -363,7 +368,7 @@ status:

 It's usual to set `status.conditions.reason` to a machine-friendly reason
 code using TitleCase; this is a convention but you can set it to anything
-you like. If you want to add a note just for human consumption, use the
+you like. If you want to add a note for human consumption, use the
 `status.conditions.message` field.

 ## Signing
@@ -438,4 +443,3 @@ status:
 * View the source code for the kube-controller-manager built in [approver](https://github.com/kubernetes/kubernetes/blob/32ec6c212ec9415f604ffc1f4c1f29b782968ff1/pkg/controller/certificates/approver/sarapprove.go)
 * For details of X.509 itself, refer to [RFC 5280](https://tools.ietf.org/html/rfc5280#section-3.1) section 3.1
 * For information on the syntax of PKCS#10 certificate signing requests, refer to [RFC 2986](https://tools.ietf.org/html/rfc2986)
-
@@ -219,7 +219,7 @@ the role that is granted to those subjects.
 1. A binding to a different role is a fundamentally different binding.
 Requiring a binding to be deleted/recreated in order to change the `roleRef`
 ensures the full list of subjects in the binding is intended to be granted
-the new role (as opposed to enabling accidentally modifying just the roleRef
+the new role (as opposed to enabling or accidentally modifying only the roleRef
 without verifying all of the existing subjects should be given the new role's
 permissions).

@@ -333,7 +333,7 @@ as a cluster administrator, include rules for custom resources, such as those se
 or aggregated API servers, to extend the default roles.

 For example: the following ClusterRoles let the "admin" and "edit" default roles manage the custom resource
-named CronTab, whereas the "view" role can perform just read actions on CronTab resources.
+named CronTab, whereas the "view" role can perform only read actions on CronTab resources.
 You can assume that CronTab objects are named `"crontabs"` in URLs as seen by the API server.

 ```yaml
@@ -185,9 +185,9 @@ systemd unit file perhaps) to enable the token file.  See docs
 further details.

 ### Authorize kubelet to create CSR
-Now that the bootstrapping node is _authenticated_ as part of the `system:bootstrappers` group, it needs to be _authorized_ to create a certificate signing request (CSR) as well as retrieve it when done. Fortunately, Kubernetes ships with a `ClusterRole` with precisely these (and just these) permissions, `system:node-bootstrapper`.
+Now that the bootstrapping node is _authenticated_ as part of the `system:bootstrappers` group, it needs to be _authorized_ to create a certificate signing request (CSR) as well as retrieve it when done. Fortunately, Kubernetes ships with a `ClusterRole` with precisely these (and only these) permissions, `system:node-bootstrapper`.

-To do this, you just need to create a `ClusterRoleBinding` that binds the `system:bootstrappers` group to the cluster role `system:node-bootstrapper`.
+To do this, you only need to create a `ClusterRoleBinding` that binds the `system:bootstrappers` group to the cluster role `system:node-bootstrapper`.

 ```
 # enable bootstrapping nodes to create CSR
@@ -345,7 +345,7 @@ The important elements to note are:
 * `token`: the token to use

 The format of the token does not matter, as long as it matches what kube-apiserver expects. In the above example, we used a bootstrap token.
-As stated earlier, _any_ valid authentication method can be used, not just tokens.
+As stated earlier, _any_ valid authentication method can be used, not only tokens.

 Because the bootstrap `kubeconfig` _is_ a standard `kubeconfig`, you can use `kubectl` to generate it. To create the above example file:

@@ -909,7 +909,7 @@ WindowsEndpointSliceProxying=true|false (ALPHA - default=false)<br/>
 <td colspan="2">--pod-infra-container-image string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `k8s.gcr.io/pause:3.2`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">The image whose network/IPC namespaces containers in each pod will use. This docker-specific flag only works when container-runtime is set to `docker`.</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;"> Specified image will not be pruned by the image garbage collector. When container-runtime is set to `docker`, all containers in each pod will use the network/ipc namespaces from this image. Other CRI implementations have their own configuration to set this image.</td>
 </tr>

 <tr>
@@ -14,7 +14,7 @@ tags:
 A Kubernetes {{< glossary_tooltip text="control plane" term_id="control-plane" >}} component
 that embeds cloud-specific control logic. The cloud controller manager lets you link your
 cluster into your cloud provider's API, and separates out the components that interact
-with that cloud platform from components that just interact with your cluster.
+with that cloud platform from components that only interact with your cluster.

 <!--more-->

@@ -360,7 +360,7 @@ Other operations for exploring API resources:
 ```bash
 kubectl api-resources --namespaced=true      # All namespaced resources
 kubectl api-resources --namespaced=false     # All non-namespaced resources
-kubectl api-resources -o name                # All resources with simple output (just the resource name)
+kubectl api-resources -o name                # All resources with simple output (only the resource name)
 kubectl api-resources -o wide                # All resources with expanded (aka "wide") output
 kubectl api-resources --verbs=list,get       # All resources that support the "list" and "get" request verbs
 kubectl api-resources --api-group=extensions # All resources in the "extensions" API group
@@ -387,6 +387,9 @@ Examples using `-o=custom-columns`:
 # All images running in a cluster
 kubectl get pods -A -o=custom-columns='DATA:spec.containers[*].image'

+# All images running in namespace: default, grouped by Pod
+kubectl get pods --namespace default --output=custom-columns="NAME:.metadata.name,IMAGE:.spec.containers[*].image"
+
 # All images excluding "k8s.gcr.io/coredns:1.6.2"
 kubectl get pods -A -o=custom-columns='DATA:spec.containers[?(@.image!="k8s.gcr.io/coredns:1.6.2")].image'

@@ -69,7 +69,7 @@ for example `create`, `get`, `describe`, `delete`.
 Flags that you specify from the command line override default values and any corresponding environment variables.
 {{< /caution >}}

-If you need help, just run `kubectl help` from the terminal window.
+If you need help, run `kubectl help` from the terminal window.

 ## Operations

@@ -123,7 +123,7 @@ If your configuration is not using the latest version it is **recommended** that
 the [kubeadm config migrate](/docs/reference/setup-tools/kubeadm/kubeadm-config/) command.

 For more information on the fields and usage of the configuration you can navigate to our API reference
-page and pick a version from [the list](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm#pkg-subdirectories).
+page and pick a version from [the list](https://pkg.go.dev/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm#section-directories).

 ### Adding kube-proxy parameters {#kube-proxy}

@@ -116,7 +116,7 @@ The **certificates.k8s.io/v1beta1** API version of CertificateSigningRequest wil
 * All existing persisted objects are accessible via the new API
 * Notable changes in `certificates.k8s.io/v1`:
    * For API clients requesting certificates:
-        * `spec.signerName` is now required (see [known Kubernetes signers](https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/#kubernetes-signers)), and requests for `kubernetes.io/legacy-unknown` are not allowed to be created via the `certificates.k8s.io/v1` API
+        * `spec.signerName` is now required (see [known Kubernetes signers](/docs/reference/access-authn-authz/certificate-signing-requests/#kubernetes-signers)), and requests for `kubernetes.io/legacy-unknown` are not allowed to be created via the `certificates.k8s.io/v1` API
        * `spec.usages` is now required, may not contain duplicate values, and must only contain known usages
    * For API clients approving or signing certificates:
        * `status.conditions` may not contain duplicate types
@@ -327,7 +327,7 @@ supported in API v1 must exist and function until API v1 is removed.

 ### Component config structures

-Component configs are versioned and managed just like REST resources.
+Component configs are versioned and managed similar to REST resources.

 ### Future work

@@ -209,9 +209,8 @@ would have failed due to conflicting ownership.

 The merging strategy, implemented with Server Side Apply, provides a generally
 more stable object lifecycle. Server Side Apply tries to merge fields based on
-the fact who manages them instead of overruling just based on values. This way
-it is intended to make it easier and more stable for multiple actors updating
-the same object by causing less unexpected interference.
+the actor who manages them instead of overruling based on values. This way
+multiple actors can update the same object without causing unexpected interference.

 When a user sends a "fully-specified intent" object to the Server Side Apply
 endpoint, the server merges it with the live object favoring the value in the
@@ -319,7 +318,7 @@ kubectl apply -f https://k8s.io/examples/application/ssa/nginx-deployment-replic
 ```

 If the apply results in a conflict with the HPA controller, then do nothing. The
-conflict just indicates the controller has claimed the field earlier in the
+conflict indicates the controller has claimed the field earlier in the
 process than it sometimes does.

 At this point the user may remove the `replicas` field from their configuration.
@@ -436,7 +435,7 @@ Data: [{"op": "replace", "path": "/metadata/managedFields", "value": [{}]}]

 This will overwrite the managedFields with a list containing a single empty
 entry that then results in the managedFields being stripped entirely from the
-object. Note that just setting the managedFields to an empty list will not
+object. Note that setting the managedFields to an empty list will not
 reset the field. This is on purpose, so managedFields never get stripped by
 clients not aware of the field.