kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Merge branch 'master' into replace-scheduler-command

pull/2111/head
tanshanshan 2017-01-04 08:36:53 +08:00 committed by GitHub
parent a95cfcddf2 c66c8b8df5
commit 42eba1866a
11 changed files with 142 additions and 24 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
OWNERS
View File

@ -1,5 +1,4 @@
assignees:
- lavalamp
- smarterclayton
- janetkuo
- pwittrock

3
_data/support.yml
View File

@ -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

6
_includes/tree.html
View File

@ -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 %}

2
docs/admin/dns.md
View File

@ -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/).

3
docs/admin/kubeadm.md
View File

@ -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.

106
docs/deprecation-policy.md
View File

@ -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<br> * v2beta2 is deprecated, "action required" relnote<br> * 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 |
<table>
<thead>
<tr>
<th>Release</th>
<th>API Versions</th>
<th>Notes</th>
</tr>
</thead>
<tbody>
<tr>
<td>X</td>
<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**

5
docs/getting-started-guides/kubeadm.md
View File

@ -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.

4
docs/user-guide/kubectl-overview.md
View File

@ -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`

2
docs/user-guide/kubectl/kubectl_config.md
View File

@ -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.
```

1
docs/user-guide/replicasets.md
View File

@ -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.

33
docs/user-guide/volumes.md
View File

@ -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