Merge pull request #16039 from simplytunde/merged-master-dev-1.16

Merged master into dev-1.16

OWNERS

@@ -6,5 +6,9 @@ reviewers:
 approvers:
 - sig-docs-en-owners # Defined in OWNERS_ALIASES
 
+emeritus_approvers:
+- chenopis
+- jaredbhatti
+
 labels:
 - sig/docs

OWNERS_ALIASES

@@ -50,21 +50,18 @@ aliases:
     - mistyhacks
     - rajakavitha1
     - ryanmcginnis
-    - shavidissa
+    - simplytunde
     - steveperry-53
     - stewart-yu
     - tengqm
     - tfogo
+    - xiangpengzhao
     - zacharysarah
-    - zhangxiaoyu-zidif
     - zparnold
   sig-docs-en-reviews: # PR reviews for English content
-    - jimangel
     - rajakavitha1
     - sftim
     - stewart-yu
-    - xiangpengzhao
-    - zhangxiaoyu-zidif
   sig-docs-es-owners: # Admins for Spanish content
     - raelga
     - alexbrand
@@ -114,11 +111,13 @@ aliases:
     - girikuncoro
     - irvifa
   sig-docs-it-owners: # Admins for Italian content
-    - rlenferink
+    - mattiaperi
     - micheleberardi
-  sig-docs-it-reviews: # PR reviews for Italian content
     - rlenferink
+  sig-docs-it-reviews: # PR reviews for Italian content
+    - mattiaperi
     - micheleberardi
+    - rlenferink
   sig-docs-ja-owners: # Admins for Japanese content
     - cstoku
     - nasa9084
@@ -142,11 +141,8 @@ aliases:
     - seokho-son
   sig-docs-maintainers: # Website maintainers
     - bradamant3
-    - chenopis
-    - jaredbhatti
     - jimangel
     - kbarnard10
-    - mistyhacks
     - pwittrock
     - steveperry-53
     - tengqm
@@ -181,6 +177,8 @@ aliases:
   sig-docs-pt-owners: # Admins for Portuguese content
     - femrtnz
     - jcjesus
+    - devlware
   sig-docs-pt-reviews: # PR reviews for Portugese content
     - femrtnz
     - jcjesus
+    - devlware

SECURITY_CONTACTS

@@ -10,6 +10,6 @@
 # DO NOT REPORT SECURITY VULNERABILITIES DIRECTLY TO THESE NAMES, FOLLOW THE
 # INSTRUCTIONS AT https://kubernetes.io/security/
 
-chenopis
 bradamant3
+jimangel
 zacharysarah

content/de/docs/concepts/architecture/nodes.md

@@ -152,7 +152,7 @@ Der Node Controller überprüft den Zustand jedes Nodes alle `--node-monitor-per
 
 
 In Versionen von Kubernetes vor 1.13 ist NodeStatus der Herzschlag des Nodes.
-Ab Kubernetes 1.13 wird das Node-Lease-Feature als Alpha-Feature eingeführt (Feature-Gate `NodeLease`, [KEP-0009](https://github.com/kubernetes/community/blob/master/keps/sig-node/0009-node-heartbeat.md)).
+Ab Kubernetes 1.13 wird das Node-Lease-Feature als Alpha-Feature eingeführt (Feature-Gate `NodeLease`, [KEP-0009](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/0009-node-heartbeat.md)).
 
 Wenn die Node Lease Funktion aktiviert ist, hat jeder Node ein zugeordnetes `Lease`-Objekt im `kube-node-lease`-Namespace, das vom Node regelmäßig erneuert wird. 
 Sowohl NodeStatus als auch Node Lease werden als Herzschläge vom Node aus behandelt. 

content/en/blog/_posts/2018-05-29-announcing-kustomize.md

@@ -11,7 +11,7 @@ date: 2018-05-29
 [kustomization]: https://github.com/kubernetes-sigs/kustomize/blob/master/docs/glossary.md#kustomization
 [mailing list]: https://groups.google.com/forum/#!forum/kustomize
 [open an issue]: https://github.com/kubernetes-sigs/kustomize/issues/new
-[subproject]: https://github.com/kubernetes/community/blob/master/keps/sig-cli/0008-kustomize.md
+[subproject]: https://github.com/kubernetes/enhancements/blob/master/keps/sig-cli/0008-kustomize.md
 [SIG-CLI]: https://github.com/kubernetes/community/tree/master/sig-cli
 [workflow]: https://github.com/kubernetes-sigs/kustomize/blob/master/docs/workflows.md
 

content/en/blog/_posts/2018-10-10-runtimeclass.md

@@ -42,6 +42,6 @@ RuntimeClass will be under active development at least through 2019, and we’re
 ## Learn More
 
 - Take it for a spin! As an alpha feature, there are some additional setup steps to use RuntimeClass. Refer to the [RuntimeClass documentation](/docs/concepts/containers/runtime-class/#runtime-class) for how to get it running.
-- Check out the [RuntimeClass Kubernetes Enhancement Proposal](https://github.com/kubernetes/community/blob/master/keps/sig-node/0014-runtime-class.md) for more nitty-gritty design details.
+- Check out the [RuntimeClass Kubernetes Enhancement Proposal](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/0014-runtime-class.md) for more nitty-gritty design details.
 - The [Sandbox Isolation Level Decision](https://docs.google.com/document/d/1fe7lQUjYKR0cijRmSbH_y0_l3CYPkwtQa5ViywuNo8Q/preview) documents the thought process that initially went into making RuntimeClass a pod-level choice.
 - Join the discussions and help shape the future of RuntimeClass with the [SIG-Node community](https://github.com/kubernetes/community/tree/master/sig-node)

content/en/blog/_posts/2019-06-20-Future-of-CRDs-Structural-Schemas.md

@@ -68,6 +68,8 @@ properties:
     properties
       command:
         type: string
+      shell:
+        type: string
       machines:
         type: array
         items:
@@ -92,14 +94,14 @@ properties:
       shell:
         type: string
         minLength: 1                          # value validation
-      oneOf:                                  # value validation
-      - required: [“command”]                 # value validation
-      - required: [“shell”]                   # value validation
       machines:
         type: array
         items:
           type: string
           pattern: “^[a-z0-9]+(-[a-z0-9]+)*$” # value validation
+    oneOf:                                    # value validation
+    - required: [“command”]                   # value validation
+    - required: [“shell”]                     # value validation
 required: [“spec”]                            # value validation
 ```
 
@@ -130,16 +132,20 @@ properties:
       shell:
         type: string
         minLength: 1
-      oneOf:
-      - type: string
-        required: [“command”]
-      - type: string
-        required: [“shell”]
       machines:
         type: array
         items:
           type: string
           pattern: “^[a-z0-9]+(-[a-z0-9]+)*$”
+    oneOf:
+    - properties:
+        command:
+          type: string
+      required: [“command”]
+    - properties:
+        shell:
+          type: string
+      required: [“shell”]
     not:
       properties:
         privileged: {}

content/en/blog/_posts/2019-07-18-some-apis-are-being-deprecated.md

@@ -34,8 +34,8 @@ from **extensions/v1beta1**, **apps/v1beta1**, or **apps/v1beta2** in **v1.16**.
   * Migrate to the apps/v1 API, available since v1.9. Existing persisted data
     can be retrieved/updated via the apps/v1 API.
 * Ingress: will no longer be served from **extensions/v1beta1** in **v1.18**.
-  * Migrate to the networking.k8s.io/v1beta1 API. Existing persisted data can be
-    retrieved/updated via the networking.k8s.io/v1beta1 API.
+  * Migrate to the networking.k8s.io/v1beta1 API, serving Ingress since v1.14.
+    Existing persisted data can be retrieved/updated via the networking.k8s.io/v1beta1 API.
 
 # What To Do
 

content/en/docs/concepts/architecture/master-node-communication.md

@@ -3,7 +3,7 @@ reviewers:
 - dchen1107
 - roberthbailey
 - liggitt
-title: Master-Node communication
+title: Master-Node Communication
 content_template: templates/concept
 weight: 20
 ---

content/en/docs/concepts/architecture/nodes.md

@@ -176,7 +176,7 @@ checks the state of each node every `--node-monitor-period` seconds.
 In versions of Kubernetes prior to 1.13, NodeStatus is the heartbeat from the
 node. Starting from Kubernetes 1.13, node lease feature is introduced as an
 alpha feature (feature gate `NodeLease`,
-[KEP-0009](https://github.com/kubernetes/community/blob/master/keps/sig-node/0009-node-heartbeat.md)).
+[KEP-0009](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/0009-node-heartbeat.md)).
 When node lease feature is enabled, each node has an associated `Lease` object in
 `kube-node-lease` namespace that is renewed by the node periodically, and both
 NodeStatus and node lease are treated as heartbeats from the node. Node leases

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

@@ -75,9 +75,9 @@ consult your documentation for security best practices.
 Area of Concern for Kubernetes Infrastructure | Recommendation |
 --------------------------------------------- | ------------ |
 Network access to API Server (Masters) | Ideally all access to the Kubernetes Masters is not allowed publicly on the internet and is controlled by network access control lists restricted to the set of IP addresses needed to administer the cluster.|
-Network access to Nodes (Worker Servers) | Nodes should be configured to _only_ accept connections (via network access control lists) from the masters on the specified ports, and accept connections for services in Kubernetes of type NodePort and LoadBalancer. If possible, this nodes should not exposed on the public internet entirely.
+Network access to Nodes (Worker Servers) | Nodes should be configured to _only_ accept connections (via network access control lists) from the masters on the specified ports, and accept connections for services in Kubernetes of type NodePort and LoadBalancer. If possible, these nodes should not be exposed on the public internet entirely.
 Kubernetes access to Cloud Provider API | Each cloud provider will need to grant a different set of permissions to the Kubernetes Masters and Nodes, so this recommendation will be more generic. It is best to provide the cluster with cloud provider access that follows the [principle of least privilege](https://en.wikipedia.org/wiki/Principle_of_least_privilege) for the resources it needs to administer. An example for Kops in AWS can be found here: https://github.com/kubernetes/kops/blob/master/docs/iam_roles.md#iam-roles
-Access to etcd | Access to etcd (the datastore of Kubernetes) should be limited to the masters only. Depending on your configuration you should also attempt to use etcd over TLS. More info can be found here: https://github.com/etcd-io/etcd/tree/master/Documentation#security
+Access to etcd | Access to etcd (the datastore of Kubernetes) should be limited to the masters only. Depending on your configuration, you should also attempt to use etcd over TLS. More info can be found here: https://github.com/etcd-io/etcd/tree/master/Documentation#security
 etcd Encryption | Wherever possible it's a good practice to encrypt all drives at rest, but since etcd holds the state of the entire cluster (including Secrets) its disk should especially be encrypted at rest.
 
 ## Cluster

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

@@ -15,7 +15,7 @@ weight: 40
 
 ## Terminology
 
-For the sake of clarity, this guide defines the following terms:
+For clarity, this guide defines the following terms:
 
 Node
 : A worker machine in Kubernetes, part of a cluster.

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

@@ -356,7 +356,7 @@ that are configured for a specific IP address and difficult to re-configure.
 The IP address that you choose must be a valid IPv4 or IPv6 address from within the
 `service-cluster-ip-range` CIDR range that is configured for the API server.
 If you try to create a Service with an invalid clusterIP address value, the API
-server will returns a 422 HTTP status code to indicate that there's a problem.
+server will return a 422 HTTP status code to indicate that there's a problem.
 
 ## Discovering services
 
@@ -598,7 +598,7 @@ For more information, see the [docs](https://cloud.google.com/kubernetes-engine/
 metadata:
     name: my-service
     annotations:
-        service.beta.kubernetes.io/aws-load-balancer-internal: 0.0.0.0/0
+        service.beta.kubernetes.io/aws-load-balancer-internal: "true"
 [...]
 ```
 {{% /tab %}}
@@ -685,7 +685,7 @@ In the above example, if the Service contained three ports, `80`, `443`, and
 `8443`, then `443` and `8443` would use the SSL certificate, but `80` would just
 be proxied HTTP.
 
-From Kubernetes v1.9 onwrds you can use [predefined AWS SSL policies](http://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-policy-table.html) with HTTPS or SSL listeners for your Services.
+From Kubernetes v1.9 onwards you can use [predefined AWS SSL policies](http://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-policy-table.html) with HTTPS or SSL listeners for your Services.
 To see which policies are available for use, you can use the `aws` command line tool:
 
 ```bash

content/en/docs/concepts/storage/storage-classes.md

@@ -522,11 +522,12 @@ parameters:
   Default is "default".
 * `adminSecretName`: secret that holds information about the Quobyte user and
   the password to authenticate against the API server. The provided secret
-  must have type "kubernetes.io/quobyte", e.g. created in this way:
+  must have type "kubernetes.io/quobyte" and the keys `user` and `password`,
+  e.g. created in this way:
 
     ```shell
     kubectl create secret generic quobyte-admin-secret \
-      --type="kubernetes.io/quobyte" --from-literal=key='opensesame' \
+      --type="kubernetes.io/quobyte" --from-literal=user='admin' --from-literal=password='opensesame' \
       --namespace=kube-system
     ```
 
@@ -610,13 +611,25 @@ parameters:
   group are searched to find one that matches `skuName` and `location`. If a
   storage account is provided, it must reside in the same resource group as the
   cluster, and `skuName` and `location` are ignored.
-
-During provision, a secret is created for mounting credentials. If the cluster
-has enabled both [RBAC](/docs/reference/access-authn-authz/rbac/) and
+* `secretNamespace`: the namespace of the secret that contains the Azure Storage 
+  Account Name and Key. Default is the same as the Pod.
+* `secretName`: the name of the secret that contains the Azure Storage Account Name and
+  Key. Default is `azure-storage-account-<accountName>-secret`
+* `readOnly`: a flag indicating whether the storage will be mounted as read only.
+  Defaults to false which means a read/write mount. This setting will impact the 
+  `ReadOnly` setting in VolumeMounts as well.
+
+During storage provisioning, a secret named by `secretName` is created for the 
+mounting credentials. If the cluster has enabled both 
+[RBAC](/docs/reference/access-authn-authz/rbac/) and 
 [Controller Roles](/docs/reference/access-authn-authz/rbac/#controller-roles),
 add the `create` permission of resource `secret` for clusterrole
 `system:controller:persistent-volume-binder`.
 
+In a multi-tenancy context, it is strongly recommended to set the value for 
+`secretNamespace` explicitly, otherwise the storage account credentials may
+be read by other users.
+
 ### Portworx Volume
 
 ```yaml

content/en/docs/contribute/advanced.md

@@ -177,7 +177,7 @@ SIG Docs [approvers](/docs/contribute/participating/#approvers) can serve a term
 Approvers must meet the following requirements to be a co-chair:
 
 - Have been a SIG Docs approver for at least 6 months
-- Have [led a Kubernetes docs release][coordinate-docs-for-a-kubernetes-release] or shadowed two releases
+- Have [led a Kubernetes docs release](/docs/contribute/advanced/#coordinate-docs-for-a-kubernetes-release) or shadowed two releases
 - Understand SIG Docs workflows and tooling: git, Hugo, localization, blog subproject
 - Understand how other Kubernetes SIGs and repositories affect the SIG Docs workflow, including: [teams in k/org](https://github.com/kubernetes/org/blob/master/config/kubernetes/sig-docs/teams.yaml), [process in k/community](https://github.com/kubernetes/community/tree/master/sig-docs), plugins in [k/test-infra](https://github.com/kubernetes/test-infra/), and the role of [SIG Architecture](https://github.com/kubernetes/community/tree/master/sig-architecture). 
 - Commit at least 5 hours per week (and often more) to the role for a minimum of 6 months

content/en/docs/contribute/start.md

@@ -261,11 +261,18 @@ pull request if it detects that you pushed a new branch to your fork.
     link for the `deploy/netlify` test, near the bottom of the page. It opens in
     the same browser window by default.
 
+    {{< note >}}
+    Please limit pull requests to one language per PR. For example, if you need to make an identical change to the same code sample in multiple languages, open a separate PR for each language. 
+    {{< /note >}}
+
 6.  Wait for review. Generally, reviewers are suggested by the `k8s-ci-robot`.
     If a reviewer asks you to make changes, you can go to the **Files changed**
     tab and click the pencil icon on any files that have been changed by the
     pull request. When you save the changed file, a new commit is created in
-    the branch being monitored by the pull request.
+    the branch being monitored by the pull request. If you are waiting on a 
+    reviewer to review the changes, proactively reach out to the reviewer 
+    once every 7 days. You can also drop into #sig-docs Slack channel, 
+    which is a good place to ask for help regarding PR reviews.
 
 7.  If your change is accepted, a reviewer merges your pull request, and the
     change is live on the Kubernetes website a few minutes later.

content/en/docs/reference/access-authn-authz/webhook.md

@@ -108,14 +108,37 @@ the request and respond to either allow or disallow access. The response body's
 }
 ```
 
-To disallow access, the remote service would return:
+For disallowing access there are two methods.
+
+The first method is preferred in most cases, and indicates the authorization
+webhook does not allow, or has "no opinion" about the request, but if other 
+authorizers are configured, they are given a chance to allow the request. 
+If there are no other authorizers, or none of them allow the request, the 
+request is forbidden. The webhook would return:
+
+```json
+{
+  "apiVersion": "authorization.k8s.io/v1beta1",
+  "kind": "SubjectAccessReview",
+  "status": {
+    "allowed": false,
+    "reason": "user does not have read access to the namespace"
+  }
+}
+```
+
+The second method denies immediately, short-circuiting evaluation by other 
+configured authorizers. This should only be used by webhooks that have 
+detailed knowledge of the full authorizer configuration of the cluster. 
+The webhook would return:
 
 ```json
 {
   "apiVersion": "authorization.k8s.io/v1beta1",
   "kind": "SubjectAccessReview",
   "status": {
     "allowed": false,
+    "denied": true,
     "reason": "user does not have read access to the namespace"
   }
 }

content/en/docs/reference/glossary/qos-class.md

@@ -15,7 +15,7 @@ related:
  - pod
 
 ---
- QoS Class (Quality of Service Class)) provides a way for Kubernetes to classify Pods within the cluster into several classes and make decisions about scheduling and eviction.
+ QoS Class (Quality of Service Class) provides a way for Kubernetes to classify Pods within the cluster into several classes and make decisions about scheduling and eviction.
 
 <!--more--> 
 QoS Class of a Pod is set at creation time  based on its compute resources requests and limits settings. QoS classes are used to make decisions about Pods scheduling and eviction.

content/en/docs/reference/kubectl/cheatsheet.md

@@ -205,9 +205,12 @@ As of version 1.11 `rolling-update` have been deprecated (see [CHANGELOG-1.11.md
 
 ```bash
 kubectl set image deployment/frontend www=image:v2               # Rolling update "www" containers of "frontend" deployment, updating the image
+kubectl rollout history deployment/frontend                      # Check the history of deployments including the revision 
 kubectl rollout undo deployment/frontend                         # Rollback to the previous deployment
+kubectl rollout undo deployment/frontend --to-revision=2         # Rollback to a specific revision
 kubectl rollout status -w deployment/frontend                    # Watch rolling update status of "frontend" deployment until completion
 
+
 # deprecated starting version 1.11
 kubectl rolling-update frontend-v1 -f frontend-v2.json           # (deprecated) Rolling update pods of frontend-v1
 kubectl rolling-update frontend-v1 frontend-v2 --image=image:v2  # (deprecated) Change the name of the resource and update the image