Merge pull request #1 from kubernetes/master

sync to head

_data/support.yml

@@ -39,3 +39,6 @@ toc:
     path: https://github.com/kubernetes/kubernetes/releases/
   - title: Release Roadmap
     path: https://github.com/kubernetes/kubernetes/milestones/
+  
+- title: Deprecation Policy
+  path: /docs/deprecation-policy.md

_includes/tree.html

@@ -12,9 +12,9 @@
         {% assign path   = item.path %}
         {% assign title  = item.title %}
       {% else %}
-        {% assign page  = site.pages | where: "path", item | first %}
+        {% assign found_page = site.pages | where: "path", item | first %}
-        {% assign title = page.title %}
+        {% assign title = found_page.title %}
-        {% assign path  = page.url %}
+        {% assign path  = found_page.url %}
       {% endif %}
     {% endcapture %}
 

docs/admin/kubeadm.md

@@ -84,6 +84,9 @@ Valid values are the ones supported by `controller-manager`, namely `"aws"`,
 the cloud provider, you should create a `/etc/kubernetes/cloud-config`
 file manually, before running `kubeadm init`. `kubeadm` automatically
 picks those settings up and ensures other nodes are configured correctly.
+The exact format and content of the file `/etc/kubernetes/cloud-config` depends
+on the type you specified for `--cloud-provider`; see the appropriate documentation
+for your cloud provider for details.
 You must also set the `--cloud-provider` and `--cloud-config` parameters
 yourself by editing the `/etc/systemd/system/kubelet.service.d/10-kubeadm.conf`
 file appropriately.

docs/deprecation-policy.md

@@ -3,11 +3,9 @@ assignees:
 - bgrant0607
 - lavalamp
 - thockin
-
+title: Kubernetes Deprecation Policy
 ---
 
-# Kubernetes Deprecation Policy
-
 Kubernetes is a large system with many components and many contributors.  As
 with any such software, the feature set naturally evolves over time, and
 sometimes a feature may need to be removed. This could include an API, a flag,
@@ -75,6 +73,7 @@ version.  Beta API versions *may not* replace GA API versions.
 **Rule #4: Other than the most recent API version in each track, older API
 versions must be supported after their announced deprecation for a duration of
 no less than:**
+
    * **GA: 1 year or 2 releases (whichever is longer)**
    * **Beta: 3 months or 1 release (whichever is longer)**
    * **Alpha: 0 releases**
@@ -84,18 +83,93 @@ which supports a particular API group.  A new Kubernetes release is made every
 approximately 3 months (4 per year).  The following table describes which API
 versions are supported in a series of subsequent releases.
 
-| Release | API versions | Notes |
+<table>
-|---------|--------------|-------|
+  <thead>
-| X       | v1           |       |
+    <tr>
-| X+1     | v1, v2alpha1 |       |
+      <th>Release</th>
-| X+2     | v1, v2alpha2 | * v2alpha1 is removed, "action required" relnote |
+      <th>API Versions</th>
-| X+3     | v1, v2beta1  | * v2alpha2 is removed, "action required" relnote |
+      <th>Notes</th>
-| X+4     | v1, v2beta1, v2beta2 | * v2beta1 is deprecated, "action required" relnote |
+    </tr>
-| X+5     | v1, v2, v2beta2      | * v2beta1 is removed, "action required" relnote<br> * v2beta2 is deprecated, "action required" relnote<br> * v1 is deprecated, "action required" relnote |
+  </thead>
-| X+6     | v1, v2               | * v2beta2 is removed, "action required" relnote |
+  <tbody>
-| X+7     | v1, v2               | |
+    <tr>
-| X+8     | v1, v2               | |
+      <td>X</td>
-| X+9     | v2                   | * v1 is removed, "action required" relnote |
+      <td>v1</td>
+      <td></td>
+    </tr>
+    <tr>
+      <td>X+1</td>
+      <td>v1, v2alpha1</td>
+      <td></td>
+    </tr>
+    <tr>
+      <td>X+2</td>
+      <td>v1, v2alpha2</td>
+      <td>
+        <ul>
+           <li>v2alpha1 is removed, "action required" relnote</li>
+        </ul>
+      </td>
+    </tr>
+    <tr>
+      <td>X+3</td>
+      <td>v1, v2beta1</td>
+      <td>
+        <ul>
+          <li>v2alpha2 is removed, "action required" relnote</li>
+        </ul>
+      </td>
+    </tr>
+    <tr>
+      <td>X+4</td>
+      <td>v1, v2beta1, v2beta2</td>
+      <td>
+        <ul>
+          <li>v2beta1 is deprecated, "action required" relnote</li>
+        </ul>
+      </td>
+    </tr>
+    <tr>
+      <td>X+5</td>
+      <td>v1, v2, v2beta2</td>
+      <td>
+        <ul>
+          <li>v2beta1 is removed, "action required" relnote</li>
+          <li>v2beta2 is deprecated, "action required" relnote</li>
+          <li>v1 is deprecated, "action required" relnote</li>
+        </ul>
+      </td>
+    </tr>
+    <tr>
+      <td>X+6</td>
+      <td>v1, v2</td>
+      <td>
+        <ul>
+          <li>v2beta2 is removed, "action required" relnote</li>
+        </ul>
+      </td>
+    </tr>
+    <tr>
+      <td>X+7</td>
+      <td>v1, v2</td>
+      <td></td>
+    </tr>
+    <tr>
+      <td>X+8</td>
+      <td>v1, v2</td>
+      <td></td>
+    </tr>
+    <tr>
+      <td>X+9</td>
+      <td>v1, v2</td>
+      <td>
+        <ul>
+          <li>v1 is removed, "action required" relnote</li>
+        </ul>
+      </td>
+    </tr>
+  </tbody>
+</table>
 
 ### REST resources (aka API objects)
 
@@ -147,12 +221,14 @@ follows:
 
 **Rule #5a: CLI elements of user-facing components (e.g. kubectl) must function
 after their announced deprecation for no less than:**
+
    * **GA: 1 year or 2 releases (whichever is longer)**
    * **Beta: 3 months or 1 release (whichever is longer)**
    * **Alpha: 0 releases**
 
 **Rule #5b: CLI elements of admin-facing components (e.g. kubelet) must function
 after their announced deprecation for no less than:**
+
    * **GA: 6 months or 1 release (whichever is longer)**
    * **Beta: 3 months or 1 release (whichever is longer)**
    * **Alpha: 0 releases**

docs/getting-started-guides/kubeadm.md

@@ -319,8 +319,9 @@ edit the `kubeadm` dropin for the `kubelet` service (`/etc/systemd/system/kubele
 If your cloud provider requires any extra packages installed on host, for example for volume mounting/unmounting, install those packages.
 
 Specify the `--cloud-provider` flag to kubelet and set it to the cloud of your choice. If your cloudprovider requires a configuration
-file, create the file `/etc/kubernetes/cloud-config` on every node and set the values your cloud requires. Also append
+file, create the file `/etc/kubernetes/cloud-config` on every node. The exact format and content of that file depends on the requirements imposed by your cloud provider.
-`--cloud-config=/etc/kubernetes/cloud-config` to the kubelet arguments.
+If you use the `/etc/kubernetes/cloud-config` file, you must append it to the `kubelet` arguments as follows:
+`--cloud-config=/etc/kubernetes/cloud-config`
 
 Lastly, run `kubeadm init --cloud-provider=xxx` to bootstrap your cluster with cloud provider features.
 

docs/user-guide/kubectl-overview.md

@@ -84,6 +84,8 @@ The following table includes a list of all the supported resource types and thei
 Resource type	| Abbreviated alias
 -------------------- | --------------------
 `clusters` |
+`clusterrolebindings` |
+`clusterroles` |
 `componentstatuses` |`cs`
 `configmaps` |`cm`
 `daemonsets` |`ds`
@@ -106,6 +108,8 @@ Resource type	| Abbreviated alias
 `replicasets` |`rs`
 `replicationcontrollers` |`rc`
 `resourcequotas` |`quota`
+`rolebindings` |
+`roles` |
 `secrets` |
 `serviceaccounts` |`sa`
 `services` |`svc`

docs/user-guide/kubectl/kubectl_config.md

@@ -14,7 +14,7 @@ Modify kubeconfig files using subcommands like "kubectl config set current-conte
 The loading order follows these rules:
 
   1. If the --kubeconfig flag is set, then only that file is loaded.  The flag may only be set once and no merging takes place.
-  2. If $KUBECONFIG environment variable is set, then it is used a list of paths (normal path delimitting rules for your system).  These paths are merged.  When a value is modified, it is modified in the file that defines the stanza.  When a value is created, it is created in the first file that exists.  If no files in the chain exist, then it creates the last file in the list.
+  2. If $KUBECONFIG environment variable is set, then it is used as a list of paths (normal path delimitting rules for your system).  These paths are merged.  When a value is modified, it is modified in the file that defines the stanza.  When a value is created, it is created in the first file that exists.  If no files in the chain exist, then it creates the last file in the list.
   3. Otherwise, ${HOME}/.kube/config is used and no merging takes place.
 
 ```

docs/user-guide/replicasets.md

@@ -37,7 +37,6 @@ their ReplicaSets.
 
 A ReplicaSet ensures that a specified number of pod “replicas” are running at any given
 time. However, a Deployment is a higher-level concept that manages ReplicaSets and
-
 provides declarative updates to pods along with a lot of other useful features.
 Therefore, we recommend using Deployments instead of directly using ReplicaSets, unless
 you require custom update orchestration or don't require updates at all.

docs/user-guide/volumes.md

@@ -531,6 +531,39 @@ before you can use it__
 
 See the [Quobyte example](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/volumes/quobyte) for more details.
 
+## Using subPath
+
+Sometimes, it is useful to share one volume for multiple uses in a single pod. The `volumeMounts.subPath`
+property can be used to specify a sub-path inside the referenced volume instead of its root.
+
+Here is an example of a pod with a LAMP stack (Linux Apache Mysql PHP) using a single, shared volume.
+The HTML contents are mapped to its `html` folder, and the databases will be stored in its `mysql` folder:
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: my-lamp-site
+spec:
+    containers:
+    - name: mysql
+      image: mysql
+      volumeMounts:
+      - mountPath: /var/lib/mysql
+        name: site-data
+        subPath: mysql
+    - name: php
+      image: php
+      volumeMounts:
+      - mountPath: /var/www/html
+        name: site-data
+        subPath: html
+    volumes:
+    - name: site-data
+      persistentVolumeClaim:
+        claimName: my-lamp-site-data
+```
+
 ## Resources
 
 The storage media (Disk, SSD, etc.) of an `emptyDir` volume is determined by the