merge master to 1.10, with fixes (#7682)

2018-03-08 14:03:55 -05:00
parent bb8c59a640
commit 44b51d6056
548 changed files with 11634 additions and 318622 deletions
@@ -1,4 +1,4 @@
-approvers:
+reviewers:
 - derekwaynecarr
 - mikedanese

@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - bgrant0607
 - erictune
 - lavalamp
@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - lavalamp
 - davidopp
 - derekwaynecarr
@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - erictune
 - lavalamp
 - ericchiang
@@ -185,7 +185,7 @@ talk to the API server. Accounts may be explicitly associated with pods using th
 NOTE: `serviceAccountName` is usually omitted because this is done automatically.

 ```
-apiVersion: apps/v1beta2
+apiVersion: apps/v1 # this apiVersion is relevant as of Kubernetes 1.9
 kind: Deployment
 metadata:
  name: nginx-deployment
@@ -650,6 +650,7 @@ apiVersion: rbac.authorization.k8s.io/v1
 kind: ClusterRole
 metadata:
  name: scopes-impersonator
+rules:
 # Can set "Impersonate-Extra-scopes" header.
 - apiGroups: ["authentication.k8s.io"]
  resources: ["userextras/scopes"]
@@ -674,7 +675,7 @@ rules:
 # Can impersonate the groups "developers" and "admins"
 - apiGroups: [""]
  resources: ["groups"]
- verbs: ["impersonate"]
+  verbs: ["impersonate"]
  resourceNames: ["developers","admins"]

 # Can impersonate the extras field "scopes" with the values "view" and "development"
@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - erictune
 - lavalamp
 - deads2k
@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - erictune
 - lavalamp
 - deads2k
@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - timstclair
 - deads2k
 - liggitt
@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - erictune
 - deads2k
 - liggitt
@@ -138,7 +138,7 @@ subjects:
  apiGroup: rbac.authorization.k8s.io
 roleRef:
  kind: ClusterRole
-  name: secret-reader
+  name: secret-reader
  apiGroup: rbac.authorization.k8s.io
 ```

@@ -188,7 +188,7 @@ rules:

 Notably, if `resourceNames` are set, then the verb must not be list, watch, create, or deletecollection.
 Because resource names are not present in the URL for create, list, watch, and deletecollection API requests,
-those verbs would not be allowed by a rule with resourceNames set, since the resourceNames portion of the
+those verbs would not be allowed by a rule with `resourceNames` set, since the `resourceNames` portion of the
 rule would not match the request.

 ### Aggregated ClusterRoles
@@ -763,7 +763,7 @@ In order from most secure to least secure, the approaches are:

   If an application does not specify a `serviceAccountName`, it uses the "default" service account.

-   NOTE: Permissions given to the "default" service account are available to any pod in the namespace that does not specify a `serviceAccountName`.
+   **NOTE:** Permissions given to the "default" service account are available to any pod in the namespace that does not specify a `serviceAccountName`.

   For example, grant read-only permission within "my-namespace" to the "default" service account:
   
@@ -777,7 +777,7 @@ In order from most secure to least secure, the approaches are:
   Many [add-ons](/docs/concepts/cluster-administration/addons/) currently run as the "default" service account in the "kube-system" namespace.
   To allow those add-ons to run with super-user access, grant cluster-admin permissions to the "default" service account in the "kube-system" namespace.
   
-   NOTE: Enabling this means the "kube-system" namespace contains secrets that grant super-user access to the API.
+   **NOTE:** Enabling this means the "kube-system" namespace contains secrets that grant super-user access to the API.
   
   ```shell
   kubectl create clusterrolebinding add-on-cluster-admin \
@@ -790,7 +790,7 @@ In order from most secure to least secure, the approaches are:
   If you want all applications in a namespace to have a role, no matter what service account they use,
   you can grant a role to the service account group for that namespace.

-   For example, grant read-only permission within "my-namespace" to to all service accounts in that namespace:
+   For example, grant read-only permission within "my-namespace" to all service accounts in that namespace:
   
   ```shell
   kubectl create rolebinding serviceaccounts-view \
@@ -815,7 +815,7 @@ In order from most secure to least secure, the approaches are:

   If you don't care about partitioning permissions at all, you can grant super-user access to all service accounts.

-   WARNING: This allows any user with read access to secrets or the ability to create a pod to access super-user credentials.
+   **WARNING:** This allows any user with read access to secrets or the ability to create a pod to access super-user credentials.

   ```shell
   kubectl create clusterrolebinding serviceaccounts-cluster-admin \
@@ -856,10 +856,11 @@ in the server logs, you can remove the ABAC authorizer.

 You can replicate a permissive policy using RBAC role bindings.

-**WARNING: The following policy allows ALL service accounts to act as cluster administrators.
+**WARNING:** The following policy allows **ALL** service accounts to act as cluster administrators.
 Any application running in a container receives service account credentials automatically,
 and could perform any action against the API, including viewing secrets and modifying permissions.
-This is not a recommended policy.**
+This is not a recommended policy.
+{: .warning}

 ```
 kubectl create clusterrolebinding permissive-binding \
@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - erictune
 - lavalamp
 - deads2k
@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - jbeda
 title: Authenticating with Bootstrap Tokens
 ---
@@ -93,8 +93,8 @@ stringData:
  expiration: 2017-03-10T03:22:11Z

  # Allowed usages.
-  usage-bootstrap-authentication: true
-  usage-bootstrap-signing: true
+  usage-bootstrap-authentication: "true"
+  usage-bootstrap-signing: "true"

  # Extra groups to authenticate the token as. Must start with "system:bootstrappers:"
  auth-extra-groups: system:bootstrappers:worker,system:bootstrappers:ingress
@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - davidopp
 - lavalamp
 title: Building Large Clusters
@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - smarterclayton
 - lavalamp
 - whitlockjc
@@ -1,4 +1,4 @@
-approvers:
+reviewers:
 - madhusudancs
 - mml
 - nikhiljindal
@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - madhusudancs
 - mml
 - nikhiljindal
@@ -115,7 +115,7 @@ $ KUBE_REGISTRY="gcr.io/myrepository" federation/develop/develop.sh push
 Note: This is going to overwrite the values you might have set for
 `apiserverRegistry`, `apiserverVersion`, `controllerManagerRegistry` and
 `controllerManagerVersion` in your `${FEDERATION_OUTPUT_ROOT}/values.yaml`
-file. Hence, it is not recommend to customize these values in
+file. Hence, it is not recommended to customize these values in
 `${FEDERATION_OUTPUT_ROOT}/values.yaml` if you are building the
 images from source.

@@ -1,4 +1,4 @@
-approvers:
+reviewers:
 - davidopp
 - lavalamp

@@ -100,13 +100,13 @@ for `${NODE_IP}` on each machine.
 Once you copy this into all three nodes, you should have a clustered etcd set up.  You can validate on master with

 ```shell
-kubectl exec < pod_name > etcdctl member list
+kubectl exec <pod_name> etcdctl member list
 ```

 and

 ```shell
-kubectl exec < pod_name > etcdctl cluster-health
+kubectl exec <pod_name> etcdctl cluster-health
 ```

 You can also validate that this is working with `etcdctl set foo bar` on one node, and `etcdctl get foo`
@@ -209,13 +209,14 @@ continuously try to add itself to the list of endpoints while removing
 the other ones, causing a lot of extraneous updates in kube-proxy
 and other components.

-Starting with Kubernetes 1.9, a new reconciler implementation is available.
-It uses a *lease* that is regularly renewed by each apiserver
-replica. When a replica is down, it stops renewing its lease, and
-the other replicas notice that the lease expired and remove it
-from the list of endpoints. You can switch to the new reconciler
-by adding the flag `--endpoint-reconciler-type=lease` when starting
-your apiserver replicas.
+Starting with Kubernetes 1.9, a new alpha reconciler implementation is
+available.  It uses a *lease* that is regularly renewed by each apiserver
+replica. When a replica is down, it stops renewing its lease, and the other
+replicas notice that the lease expired and remove it from the list of
+endpoints. You can switch to the new reconciler by adding the flag
+`--endpoint-reconciler-type=lease` when starting your apiserver replicas.
+
+{% include feature-state-alpha.md %}

 If you want to know more, you can check the following resources:
 - [issue kubernetes/kuberenetes#22609](https://github.com/kubernetes/kubernetes/issues/22609),
@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - liggitt
 title: Kubelet authentication/authorization
 ---
@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - ericchiang
 - mikedanese
 - jcbsmpsn
@@ -1,4 +1,4 @@
-approvers:
+reviewers:
 - derekwaynecarr
 - janetkuo

@@ -1,4 +1,4 @@
-approvers:
+reviewers:
 - davidopp
 - madhusudancs

@@ -1,43 +0,0 @@
-apiVersion: apps/v1beta1
-kind: Deployment
-metadata:
-  labels:
-    component: scheduler
-    tier: control-plane
-  name: my-scheduler
-  namespace: kube-system
-spec:
-  replicas: 1
-  template:
-    metadata:
-      labels:
-        component: scheduler
-        tier: control-plane
-        version: second
-    spec:
-      containers:
-      - command:
-        - /usr/local/bin/kube-scheduler
-        - --address=0.0.0.0
-        - --leader-elect=false
-        - --scheduler-name=my-scheduler
-        image: gcr.io/my-gcp-project/my-kube-scheduler:1.0
-        livenessProbe:
-          httpGet:
-            path: /healthz
-            port: 10251
-          initialDelaySeconds: 15
-        name: kube-second-scheduler
-        readinessProbe:
-          httpGet:
-            path: /healthz
-            port: 10251
-        resources:
-          requests:
-            cpu: '0.1'
-        securityContext:
-          privileged: false
-        volumeMounts: []
-      hostNetwork: false
-      hostPID: false
-      volumes: []
@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - jlowdermilk
 - justinsb
 - quinton-hoole
@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - Random-Liu
 title: Validate Node Setup
 ---
@@ -1,21 +0,0 @@
---
-approvers:
- thockin
-title: Kubernetes OpenVSwitch GRE/VxLAN networking
---
-
-This document describes how OpenVSwitch is used to setup networking between pods across nodes.
-The tunnel type could be GRE or VxLAN. VxLAN is preferable when large scale isolation needs to be performed within the network.
-
-![OVS Networking](/images/docs/ovs-networking.png)
-
-The vagrant setup in Kubernetes does the following:
-
-The docker bridge is replaced with a brctl generated linux bridge (kbr0) with a 256 address space subnet. Basically, a node gets 10.244.x.0/24 subnet and docker is configured to use that bridge instead of the default docker0 bridge.
-
-Also, an OVS bridge is created(obr0) and added as a port to the kbr0 bridge. All OVS bridges across all nodes are linked with GRE tunnels. So, each node has an outgoing GRE tunnel to all other nodes. It does not need to be a complete mesh really, just meshier the better. STP (spanning tree) mode is enabled in the bridges to prevent loops.
-
-Routing rules enable any 10.244.0.0/16 target to become reachable via the OVS bridge connected with the tunnels.
-
-
-
@@ -1,3 +1,3 @@
-approvers:
+reviewers:
 - derekwaynecarr

@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - davidopp
 title: Configuring Kubernetes with Salt
 ---
@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - bprashanth
 - davidopp
 - lavalamp