diff --git a/OWNERS b/OWNERS index 247d39ea5e..055a328273 100644 --- a/OWNERS +++ b/OWNERS @@ -1,5 +1,4 @@ assignees: -- lavalamp - smarterclayton - janetkuo - pwittrock diff --git a/_data/support.yml b/_data/support.yml index efb049ccb1..8647d1456d 100644 --- a/_data/support.yml +++ b/_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 diff --git a/_includes/tree.html b/_includes/tree.html index 4aeaeb0176..78505504f1 100644 --- a/_includes/tree.html +++ b/_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 title = page.title %} - {% assign path = page.url %} + {% assign found_page = site.pages | where: "path", item | first %} + {% assign title = found_page.title %} + {% assign path = found_page.url %} {% endif %} {% endcapture %} diff --git a/docs/admin/dns.md b/docs/admin/dns.md index 01f54d9167..0ee1fca395 100644 --- a/docs/admin/dns.md +++ b/docs/admin/dns.md @@ -384,7 +384,7 @@ for more information. ## References -- [Docs for the DNS cluster addon](http://releases.k8s.io/{{page.githubbranch}}/build-tools/kube-dns/README.md) +- [Docs for the DNS cluster addon](http://releases.k8s.io/{{page.githubbranch}}/build/kube-dns/README.md) ## What's next - [Autoscaling the DNS Service in a Cluster](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/). diff --git a/docs/admin/kubeadm.md b/docs/admin/kubeadm.md index 71095d0577..1014ee1ab6 100644 --- a/docs/admin/kubeadm.md +++ b/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. diff --git a/docs/deprecation-policy.md b/docs/deprecation-policy.md index 14db737d13..d349e6c0b9 100644 --- a/docs/deprecation-policy.md +++ b/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 | -|---------|--------------|-------| -| X | v1 | | -| X+1 | v1, v2alpha1 | | -| X+2 | v1, v2alpha2 | * v2alpha1 is removed, "action required" relnote | -| X+3 | v1, v2beta1 | * v2alpha2 is removed, "action required" relnote | -| X+4 | v1, v2beta1, v2beta2 | * v2beta1 is deprecated, "action required" relnote | -| X+5 | v1, v2, v2beta2 | * v2beta1 is removed, "action required" relnote
* v2beta2 is deprecated, "action required" relnote
* v1 is deprecated, "action required" relnote | -| X+6 | v1, v2 | * v2beta2 is removed, "action required" relnote | -| X+7 | v1, v2 | | -| X+8 | v1, v2 | | -| X+9 | v2 | * v1 is removed, "action required" relnote | + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ReleaseAPI VersionsNotes
Xv1
X+1v1, v2alpha1
X+2v1, v2alpha2 +
    +
  • v2alpha1 is removed, "action required" relnote
    • +
+
X+3v1, v2beta1 +
    +
  • v2alpha2 is removed, "action required" relnote
    • +
+
X+4v1, v2beta1, v2beta2 +
    +
  • v2beta1 is deprecated, "action required" relnote
    • +
+
X+5v1, v2, v2beta2 +
    +
  • v2beta1 is removed, "action required" relnote
    • +
  • v2beta2 is deprecated, "action required" relnote
    • +
  • v1 is deprecated, "action required" relnote
    • +
+
X+6v1, v2 +
    +
  • v2beta2 is removed, "action required" relnote
    • +
+
X+7v1, v2
X+8v1, v2
X+9v1, v2 +
    +
  • v1 is removed, "action required" relnote
    • +
+
### 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** diff --git a/docs/getting-started-guides/kubeadm.md b/docs/getting-started-guides/kubeadm.md index d3ae5a2cad..74d2f18906 100644 --- a/docs/getting-started-guides/kubeadm.md +++ b/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 -`--cloud-config=/etc/kubernetes/cloud-config` to the kubelet arguments. +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. +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. diff --git a/docs/user-guide/kubectl-overview.md b/docs/user-guide/kubectl-overview.md index 2fa249c5f6..987e154703 100644 --- a/docs/user-guide/kubectl-overview.md +++ b/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` diff --git a/docs/user-guide/kubectl/kubectl_config.md b/docs/user-guide/kubectl/kubectl_config.md index 441db2334a..c19e98d381 100644 --- a/docs/user-guide/kubectl/kubectl_config.md +++ b/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. ``` diff --git a/docs/user-guide/replicasets.md b/docs/user-guide/replicasets.md index 769ea58c02..ea3e7bde14 100644 --- a/docs/user-guide/replicasets.md +++ b/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. diff --git a/docs/user-guide/volumes.md b/docs/user-guide/volumes.md index f2b5ff88a0..762518fc8f 100644 --- a/docs/user-guide/volumes.md +++ b/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