Merge branch 'release-1.9' into kubeadmIPV6

_config.yml

@@ -18,16 +18,21 @@ defaults:
     scope:
       path: ""
     values:
-      fullversion: "v1.8.0"
-      version: "v1.8"
+      fullversion: "v1.9.0"
+      version: "v1.9"
       githubbranch: "master"
       docsbranch: "master"
       versions:
-        - fullversion: "v1.8.0"
+        - fullversion: "v1.9.0"
+          version: "v1.9"
+          githubbranch: "v1.9.0"
+          docsbranch: "release-1.9"
+          url: https://kubernetes.io/docs/home/
+        - fullversion: "v1.8.4"
           version: "v1.8"
-          githubbranch: "v1.8.0"
+          githubbranch: "v1.8.4"
           docsbranch: "release-1.8"
-          url: https://kubernetes.io/docs/home/
+          url: https://v1-8.docs.kubernetes.io/docs/home/
         - fullversion: "v1.7.6"
           version: "v1.7"
           githubbranch: "v1.7.6"
@@ -43,11 +48,6 @@ defaults:
           githubbranch: "v1.5.7"
           docsbranch: "release-1.5"
           url: https://v1-5.docs.kubernetes.io/docs/
-        - fullversion: "v1.4.12"
-          version: "v1.4"
-          githubbranch: "v1.4.12"
-          docsbranch: "release-1.4"
-          url: https://v1-4.docs.kubernetes.io/docs/
       deprecated: false
       currentUrl: https://kubernetes.io/docs/home/
       nextUrl: http://kubernetes-io-vnext-staging.netlify.com/

_data/reference.yml

@@ -60,7 +60,17 @@ toc:
 
 - title: Setup Tools Reference
   section:
-  - docs/reference/generated/kubeadm.md
+  - title: Kubeadm
+    section:
+    - docs/reference/setup-tools/kubeadm/kubeadm.md
+    - docs/reference/setup-tools/kubeadm/kubeadm-init.md
+    - docs/reference/setup-tools/kubeadm/kubeadm-join.md
+    - docs/reference/setup-tools/kubeadm/kubeadm-upgrade.md
+    - docs/reference/setup-tools/kubeadm/kubeadm-config.md
+    - docs/reference/setup-tools/kubeadm/kubeadm-reset.md
+    - docs/reference/setup-tools/kubeadm/kubeadm-token.md
+    - docs/reference/setup-tools/kubeadm/kubeadm-version.md
+    - docs/reference/setup-tools/kubeadm/kubeadm-alpha.md
   - title: Kubefed
     section:
     - docs/reference/generated/kubefed.md

_data/tasks.yml

@@ -140,9 +140,11 @@ toc:
   - docs/tasks/administer-cluster/upgrade-1-6.md
   - docs/tasks/administer-cluster/kubeadm-upgrade-1-7.md
   - docs/tasks/administer-cluster/kubeadm-upgrade-1-8.md
+  - docs/tasks/administer-cluster/kubeadm-upgrade-1-9.md
   - docs/tasks/administer-cluster/namespaces.md
   - docs/tasks/administer-cluster/namespaces-walkthrough.md
   - docs/tasks/administer-cluster/dns-horizontal-autoscaling.md
+  - docs/tasks/administer-cluster/coredns.md
   - docs/tasks/administer-cluster/safely-drain-node.md
   - docs/tasks/administer-cluster/cpu-memory-limit.md
   - docs/tasks/administer-cluster/out-of-resource.md
@@ -168,6 +170,7 @@ toc:
   - docs/tasks/administer-cluster/configure-multiple-schedulers.md
   - docs/tasks/administer-cluster/ip-masq-agent.md
   - docs/tasks/administer-cluster/dns-custom-nameservers.md
+  - docs/tasks/administer-cluster/pvc-protection.md
 
 - title: Federation - Run an App on Multiple Clusters
   section:

cn/docs/tutorials/stateful-application/web.yaml

@@ -1,3 +1,4 @@
+---
 apiVersion: v1
 kind: Service
 metadata:

cn/docs/tutorials/stateful-application/webp.yaml

@@ -1,3 +1,4 @@
+---
 apiVersion: v1
 kind: Service
 metadata:
@@ -41,4 +42,4 @@ spec:
       accessModes: [ "ReadWriteOnce" ]
       resources:
         requests:
-          storage: 1Gi
+          storage: 1Gi

cn/docs/user-guide/multi-pod.yaml

@@ -1,3 +1,4 @@
+---
 apiVersion: v1
 kind: Pod
 metadata:

docs/admin/authorization/index.md

@@ -8,20 +8,34 @@ title: Overview
 ---
 
 {% capture overview %}
-Learn more about Kubernetes authorization, including details about creating policies using the supported authorization modules.
+Learn more about Kubernetes authorization, including details about creating
+policies using the supported authorization modules.
 {% endcapture %}
 
 {% capture body %}
-In Kubernetes, you must be authenticated (logged in) before your request can be authorized (granted permission to access). For information about authentication, see [Accessing Control Overview](/docs/admin/accessing-the-api/).
+In Kubernetes, you must be authenticated (logged in) before your request can be
+authorized (granted permission to access). For information about authentication,
+see [Accessing Control Overview](/docs/admin/accessing-the-api/).
 
-Kubernetes expects attributes that are common to REST API requests. This means that Kubernetes authorization works with existing organization-wide or cloud-provider-wide access control systems which may handle other APIs besides the Kubernetes API.
+Kubernetes expects attributes that are common to REST API requests. This means
+that Kubernetes authorization works with existing organization-wide or
+cloud-provider-wide access control systems which may handle other APIs besides
+the Kubernetes API.
 
 ## Determine Whether a Request is Allowed or Denied
-Kubernetes authorizes API requests using the API server. It evaluates all of the request attributes against all policies and allows or denies the request. All parts of an API request must be allowed by some policy in order to proceed. This means that permissions are denied by default.
+Kubernetes authorizes API requests using the API server. It evaluates all of the
+request attributes against all policies and allows or denies the request. All
+parts of an API request must be allowed by some policy in order to proceed. This
+means that permissions are denied by default.
 
-(Although Kubernetes uses the API server, access controls and policies that depend on specific fields of specific kinds of objects are handled by Admission Controllers.)
+(Although Kubernetes uses the API server, access controls and policies that
+depend on specific fields of specific kinds of objects are handled by Admission
+Controllers.)
 
-When multiple authorization modules are configured, each is checked in sequence, and if any module authorizes the request, then the request can proceed. If all modules deny the request, then the request is denied (HTTP status code 403).
+When multiple authorization modules are configured, each is checked in sequence.
+If any authorizer approves or denies a request, that decision is immediately
+returned and no other authorizer is consulted. If all modules have no opinion on
+the request, then the request is denied. A deny returns an HTTP status code 403.
 
 ## Review Your Request Attributes
 Kubernetes reviews only the following API request attributes:
@@ -33,14 +47,15 @@ Kubernetes reviews only the following API request attributes:
  * **Request path** - Path to miscellaneous non-resource endpoints like `/api` or `/healthz`.
  * **API request verb** - API verbs `get`, `list`, `create`, `update`, `patch`, `watch`, `proxy`, `redirect`, `delete`, and `deletecollection` are used for resource requests. To determine the request verb for a resource API endpoint, see **Determine the request verb** below.
  * **HTTP request verb** - HTTP verbs `get`, `post`, `put`, and `delete` are used for non-resource requests.
- * **Resource** - The ID or name of the resource that is being accessed (for resource requests only)
---* For resource requests using `get`, `update`, `patch`, and `delete` verbs, you must provide the resource name.
+ * **Resource** - The ID or name of the resource that is being accessed (for resource requests only) -- For resource requests using `get`, `update`, `patch`, and `delete` verbs, you must provide the resource name.
  * **Subresource** - The subresource that is being accessed (for resource requests only).
  * **Namespace** - The namespace of the object that is being accessed (for namespaced resource requests only).
  * **API group** - The API group being accessed (for resource requests only). An empty string designates the [core API group](/docs/concepts/overview/kubernetes-api/).
 
 ## Determine the Request Verb
-To determine the request verb for a resource API endpoint, review the HTTP verb used and whether or not the request acts on an individual resource or a collection of resources:
+To determine the request verb for a resource API endpoint, review the HTTP verb
+used and whether or not the request acts on an individual resource or a
+collection of resources:
 
 HTTP verb | request verb
 ----------|---------------
@@ -87,8 +102,9 @@ $ kubectl auth can-i list secrets --namespace dev --as dave
 no
 ```
 
-`SelfSubjectAccessReview` is part of the `authorization.k8s.io` API group, which exposes the
-API server authorization to external services. Other resources in this group include:
+`SelfSubjectAccessReview` is part of the `authorization.k8s.io` API group, which
+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.
 * `LocalSubjectAccessReview` - Like `SubjectAccessReview` but restricted to a specific namespace.
@@ -121,11 +137,13 @@ spec:
     verb: create
 status:
   allowed: true
+  denied: false
 ```
 
 ## Using Flags for Your Authorization Module
 
-You must include a flag in your policy to indicate which authorization module your policies include:
+You must include a flag in your policy to indicate which authorization module
+your policies include:
 
 The following flags can be used:
 
@@ -136,12 +154,8 @@ The following flags can be used:
   * `--authorization-mode=AlwaysDeny` This flag blocks all requests. Use this flag only for testing.
   * `--authorization-mode=AlwaysAllow` This flag allows all requests. Use this flag only if you do not require authorization for your API requests.
 
-You can choose more than one authorization module. If one of the modes is `AlwaysAllow`, then it overrides the other modes and all API requests are allowed. 
-
-## Versioning
-For version 1.2, clusters created by kube-up.sh are configured so that no authorization is required for any request.
-
-As of version 1.3, clusters created by kube-up.sh are configured so that the ABAC authorization modules are enabled. However, its input file is initially set to allow all users to do all operations. The cluster administrator needs to edit that file, or configure a different authorizer to restrict what users can do.
+You can choose more than one authorization module. Modules are checked in order
+so an earlier module has higher priority to allow or deny a request.
 
 {% endcapture %}
 {% capture whatsnext %}
@@ -153,7 +167,16 @@ As of version 1.3, clusters created by kube-up.sh are configured so that the A
 
 ## Privilege escalation via pod creation
 
-Users who have ability to create pods in a namespace can potentially escalate their privileges within that namespace.  They can create pods that access secrets the user cannot themselves read, or that run under a service account with different/greater permissions.
-
-**Caution:** System administrators, use care when granting access to pod creation.  A user granted permission to create pods (or controllers that create pods) in the namespace can: read all secrets in the namespace; read all config maps in the namespace; and impersonate any service account in the namespace and take any action the account could take. This applies regardless of authorization mode.
+Users who have the ability to create pods in a namespace can potentially
+escalate their privileges within that namespace.  They can create pods that
+access their privileges within that namespace. They can create pods that access
+secrets the user cannot themselves read, or that run under a service account
+with different/greater permissions.
+
+**Caution:** System administrators, use care when granting access to pod
+creation.  A user granted permission to create pods (or controllers that create
+pods) in the namespace can: read all secrets in the namespace; read all config
+maps in the namespace; and impersonate any service account in the namespace and
+take any action the account could take. This applies regardless of authorization
+mode.
 {: .caution}

docs/admin/authorization/rbac.md

@@ -191,6 +191,76 @@ Because resource names are not present in the URL for create, list, watch, and d
 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
+
+As of 1.9, ClusterRoles can be created by combining other ClusterRoles using an `aggregationRule`. The
+permissions of aggregated ClusterRoles are controller-managed, and filled in by unioning the rules of any
+ClusterRole that matches the provided label selector. An example aggregated ClusterRole:
+
+```yaml
+kind: ClusterRole
+apiVersion: rbac.authorization.k8s.io/v1
+metadata:
+  name: monitoring
+aggregationRule:
+  clusterRoleSelectors:
+  - matchLabels:
+      rbac.example.com/aggregate-to-monitoring: "true"
+rules: [] # Rules are automatically filled in by the controller manager.
+```
+
+Creating a ClusterRole that matches the label selector will add rules to the aggregated ClusterRole. In this case
+rules can be added to the "monitoring" ClusterRole by creating another ClusterRole that has the label
+`rbac.example.com/aggregate-to-monitoring: true`.
+
+```yaml
+kind: ClusterRole
+apiVersion: rbac.authorization.k8s.io/v1
+metadata:
+  name: monitoring-endpoints
+  labels:
+    rbac.example.com/aggregate-to-monitoring: "true"
+# These rules will be added to the "monitoring" role.
+rules:
+- apiGroups: [""]
+  Resources: ["services", "endpoints", "pods"]
+  verbs: ["get", "list", "watch"]
+```
+
+The default user-facing roles (described below) use ClusterRole aggregation. This lets admins include rules
+for custom resources, such as those served by CustomResourceDefinitions or Aggregated API servers, on the
+default roles.
+
+For example, the following ClusterRoles let the "admin" and "edit" default roles manage the custom resource
+"CronTabs" and the "view" role perform read-only actions on the resource.
+
+```yaml
+kind: ClusterRole
+apiVersion: rbac.authorization.k8s.io/v1
+metadata:
+  name: aggregate-cron-tabs-edit
+  labels:
+    # Add these permissions to the "admin" and "edit" default roles.
+    rbac.authorization.k8s.io/aggregate-to-admin: "true"
+    rbac.authorization.k8s.io/aggregate-to-edit: "true"
+rules:
+- apiGroups: ["stable.example.com"]
+  resources: ["crontabs"]
+  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
+---
+kind: ClusterRole
+apiVersion: rbac.authorization.k8s.io/v1
+metadata:
+  name: aggregate-cron-tabs-view
+  labels:
+    # Add these permissions to the "view" default role.
+    rbac.authorization.k8s.io/aggregate-to-view: "true"
+rules:
+- apiGroups: ["stable.example.com"]
+  resources: ["crontabs"]
+  verbs: ["get", "list", "watch"]
+```
+
 #### Role Examples
 
 Only the `rules` section is shown in the following examples.
@@ -402,6 +472,18 @@ They include super-user roles (`cluster-admin`),
 roles intended to be granted cluster-wide using ClusterRoleBindings (`cluster-status`),
 and roles intended to be granted within particular namespaces using RoleBindings (`admin`, `edit`, `view`).
 
+As of 1.9, user-facing roles use [ClusterRole Aggregation](#aggregated-clusterroles) to allow admins to include
+rules for custom resources on these roles. To add rules to the "admin", "edit", or "view" role, create a
+ClusterRole with one or more of the following labels:
+
+```yaml
+metadata:
+  labels:
+    rbac.authorization.k8s.io/aggregate-to-admin: "true"
+    rbac.authorization.k8s.io/aggregate-to-edit: "true"
+    rbac.authorization.k8s.io/aggregate-to-view: "true"
+```
+
 <table>
 <colgroup><col width="25%"><col width="25%"><col></colgroup>
 <tr>
@@ -546,6 +628,7 @@ These roles include:
 * system:controller:node-controller
 * system:controller:persistent-volume-binder
 * system:controller:pod-garbage-collector
+* system:controller:pvc-protection-controller
 * system:controller:replicaset-controller
 * system:controller:replication-controller
 * system:controller:resourcequota-controller

docs/concepts/api-extension/custom-resources.md

@@ -48,24 +48,24 @@ When creating a new API, consider whether to [aggregate your API with the Kubern
 #### Declarative APIs
 
 In a Declarative API, typically:
- - Your API consists of a relatively small number of relatively small objects (resources).
- - The objects define configuration of applications or infrastructure.
- - The objects are updated relatively infrequently.
- - Humans often need to read and write the objects.
- - The main operations on the objects are CRUD-y (creating, reading, updating and deleting).
- - Transactions across objects are not required: the API represents a desired state, not an exact state.
+ - your API consists of a relatively small number of relatively small objects (resources).
+ - the objects define configuration of applications or infrastructure
+ - the objects are updated relatively infrequently
+ - humans often need to read and write the objects
+ - the main operations on the objects are CRUD-y (creating, reading, updating and deleting)
+ - transactions across objects are not required: the API represents a desired state, not an exact state.
 
 Imperative APIs are not declarative. 
 Signs that your API might not be declarative include:
- - The client says "do this", and then gets a synchornous response back when it is done.
- - The client says "do this", and then gets an operation ID back, and has to check a separate Operation objects to determine completion of the request.
- - You talk about Remote Procedure Calls (RPCs).
- - Directly storing large amounts of data (e.g. > a few kB per object, or >1000s of objects).
- - High bandwidth access (10s of requests per second sustained) needed.
- - Store end-user data (such as images, PII, etc) or other large-scale data processed by applications.
- - The natural operations on the objects are not CRUD-y.
- - The API is not easily modeled as objects.
- - You chose to represent pending operations with an operation ID or operation object.
+ - the client says "do this", and then gets a synchornous response back when it is done.
+ - the client says "do this", and then gets an operation ID back, and has to check a separate Operation objects to determine completion of the request.
+ - you talk about Remote Procedure Calls (RPCs)
+ - directly stoing large amounts of data (e.g. > a few kB per object, or >1000s of objects)
+ - high bandwidth access (10s of requests per second sustained) needed
+ - store end-user data (such as images, PII, etc) or other large-scale data processed by applications
+ - the natural operations on the objects are not CRUD-y.
+ - the API is not easily modeled as objects.
+ - you chose to represent pending operations with an operation ID or operation object.
 
 ### Should I use a configMap or a custom resource?
 
@@ -102,7 +102,7 @@ Aggregated APIs are subordinate APIServers that sit behind the primary API serve
 
 Custom Resource Definitions (CRDS) allow users to create new types of resources without adding another APIserver. You do not need to understand API Aggregation to use CRDs.
 
-Regardless of whether they are installed via CRDs or AA, the new resources are called Custom Resources to distinguish them from built-in Kubernetes resources (like pods).
+Regardless of whether they are installed via CRDs or AA, the new resources are called Custom Resources to distinguish them from built-in Kubernetes resources (like pods)
 
 ## CustomResourceDefinitions
 
@@ -215,9 +215,9 @@ Kubernetes [client libraries](/docs/reference/client-libraries/) can be used to
 
 When you add a custom resource, you can access it using:
   - kubectl
-  - The kubernetes dynamic client.
-  - A REST client that you write.
-  - A client generated using Kubernetes client generation tools (generating one is an advanced undertaking, but some projects may provide a client along with the CRD or AA).
+  - the kubernetes dynamic client
+  - a REST client that you write
+  - a client generated using Kubernetes client generation tools (generating one is an advanced undertaking, but some projects may provide a client along with the CRD or AA).
 
 {% endcapture %}