whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge branch 'master' into release-1.8

Browse Source
This commit is contained in:
steveperry-53
2017-09-22 12:57:53 -07:00
parent 96a4aa7a3e 8f9677227d
commit 29a7b6df2e
17 changed files with 481 additions and 72 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/concepts/architecture/nodes.md
-1
View File
@@ -205,7 +205,6 @@ register itself with the API server. This is the preferred pattern, used by mos
For self-registration, the kubelet is started with the following options:
- `--api-servers` - Location of the apiservers.
- `--kubeconfig` - Path to credentials to authenticate itself to the apiserver.
- `--cloud-provider` - How to talk to a cloud provider to read metadata about itself.
- `--register-node` - Automatically register with the API server.
docs/concepts/cluster-administration/networking.md
+1 -1
View File
@@ -170,7 +170,7 @@ traffic to the internet.
### Kube-router
[Kube-router](https://github.com/cloudnativelabs/kube-router) is a purpose-built networking solution for Kubernetes that aims to provide high performance and operational simplicity. Kube-router provides a Linux [LVS/IPVS](http://www.linuxvirtualserver.org/software/ipvs.html)-based service proxy, a Linux kernel forwarding-based pod-to-pod networking solution with no overlays, and iptables/ipset-based network policy enforcer.
[Kube-router](https://github.com/cloudnativelabs/kube-router) is a purpose-built networking solution for Kubernetes that aims to provide high performance and operational simplicity. Kube-router provides a Linux [LVS/IPVS](http://www.linuxvirtualserver.org/software/ipvs.html)-based service proxy, a Linux kernel forwarding-based pod-to-pod networking solution with no overlays, and iptables/ipset-based network policy enforcer.
### L2 networks and linux bridging
docs/concepts/configuration/secret.md
+1 -1
View File
@@ -442,7 +442,7 @@ that are considered invalid environment variable names will have those keys
skipped. The pod will be allowed to start. There will be an event whose
reason is `InvalidVariableNames` and the message will contain the list of
invalid keys that were skipped. The example shows a pod which refers to the
default/mysecret ConfigMap that contains 2 invalid keys, 1badkey and 2alsobad.
default/mysecret that contains 2 invalid keys, 1badkey and 2alsobad.
```shell
$ kubectl get events
docs/reference/deprecation-policy.md
+123 -24
View File
@@ -70,41 +70,124 @@ API version at least as stable is released.**
GA API versions can replace GA API versions as well as beta and alpha API
versions. Beta API versions *may not* replace GA API versions.
**Rule #4: Other than the most recent API versions in each track, older API
**Rule #4a: Other than the most recent API versions 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)**
* **Beta: 6 months or 2 releases (whichever is longer)**
* **Alpha: 0 releases**
This is best illustrated by example. Imagine a Kubernetes release, version X,
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.
NOTE: Until [#52185](https://github.com/kubernetes/kubernetes/issues/52185) is
resolved, no API versions may be removed.
**Rule #4b: The "preferred" API version and the "storage version" for a given
group may not advance util after a release has been made that supports both the
new version and the previous version**
Users must be able to upgrade to a new release of Kubernetes and then roll back
to a previous release, without converting anything to the new API version or
suffering breakages (unless they explicitly used features only available in the
newer version). This is particularly evident in the stored representation of
objects.
All of this is best illustrated by examples. Imagine a Kubernetes release,
version X, which introduces a new 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.
<table>
<thead>
<tr>
<th>Release</th>
<th>API Versions</th>
<th>Preferred/Storage Version</th>
<th>Notes</th>
</tr>
</thead>
<tbody>
<tr>
<td>X</td>
<td>v1</td>
<td>v1alpha1</td>
<td>v1alpha1</td>
<td></td>
</tr>
<tr>
<td>X+1</td>
<td>v1, v2alpha1</td>
<td></td>
<td>v1alpha2</td>
<td>v1alpha2</td>
<td>
<ul>
<li>v1alpha1 is removed, "action required" relnote</li>
</ul>
</td>
</tr>
<tr>
<td>X+2</td>
<td>v1, v2alpha2</td>
<td>v1beta1</td>
<td>v1beta1</td>
<td>
<ul>
<li>v1alpha2 is removed, "action required" relnote</li>
</ul>
</td>
</tr>
<tr>
<td>X+3</td>
<td>v1beta2, v1beta1 (deprecated)</td>
<td>v1beta1</td>
<td>
<ul>
<li>v1beta1 is deprecated, "action required" relnote</li>
</ul>
</td>
</tr>
<tr>
<td>X+4</td>
<td>v1beta2, v1beta1 (deprecated)</td>
<td>v1beta2</td>
<td></td>
</tr>
<tr>
<td>X+5</td>
<td>v1, v1beta2 (deprecated)</td>
<td>v1beta2</td>
<td>
<ul>
<li>v1beta1 is removed, "action required" relnote</li>
<li>v1beta2 is deprecated, "action required" relnote</li>
</ul>
</td>
</tr>
<tr>
<td>X+6</td>
<td>v1, v1beta2 (deprecated)</td>
<td>v1</td>
<td>
<ul>
</ul>
</td>
</tr>
<tr>
<td>X+7</td>
<td>v1</td>
<td>v1</td>
<td>
<ul>
<li>v1beta2 is removed, "action required" relnote</li>
</ul>
</td>
</tr>
<tr>
<td>X+8</td>
<td>v2alpha1, v1</td>
<td>v1</td>
<td></td>
</tr>
<tr>
<td>X+9</td>
<td>v2alpha2, v1</td>
<td>v1</td>
<td>
<ul>
<li>v2alpha1 is removed, "action required" relnote</li>
@@ -112,8 +195,9 @@ versions are supported in a series of subsequent releases.
</td>
</tr>
<tr>
<td>X+3</td>
<td>v1, v2beta1</td>
<td>X+10</td>
<td>v2beta1, v1</td>
<td>v1</td>
<td>
<ul>
<li>v2alpha2 is removed, "action required" relnote</li>
@@ -121,8 +205,9 @@ versions are supported in a series of subsequent releases.
</td>
</tr>
<tr>
<td>X+4</td>
<td>v1, v2beta1, v2beta2</td>
<td>X+11</td>
<td>v2beta2, v2beta1 (deprecated), v1</td>
<td>v1</td>
<td>
<ul>
<li>v2beta1 is deprecated, "action required" relnote</li>
@@ -130,19 +215,30 @@ versions are supported in a series of subsequent releases.
</td>
</tr>
<tr>
<td>X+5</td>
<td>v1, v2, v2beta2</td>
<td>X+12</td>
<td>v2, v2beta2 (deprecated), v2beta1 (deprecated), v1 (deprecated)</td>
<td>v1</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>X+13</td>
<td>v2, v2beta2 (deprecated), v1 (deprecated)</td>
<td>v2</td>
<td>
<ul>
<li>v2beta1 is removed, "action required" relnote</li>
</ul>
</td>
</tr>
<tr>
<td>X+14</td>
<td>v2, v1 (deprecated)</td>
<td>v2</td>
<td>
<ul>
<li>v2beta2 is removed, "action required" relnote</li>
@@ -150,17 +246,20 @@ versions are supported in a series of subsequent releases.
</td>
</tr>
<tr>
<td>X+7</td>
<td>v1, v2</td>
<td>X+15</td>
<td>v2, v1 (deprecated)</td>
<td>v2</td>
<td></td>
</tr>
<tr>
<td>X+8</td>
<td>v1, v2</td>
<td>X+16</td>
<td>v2, v1 (deprecated)</td>
<td>v2</td>
<td></td>
</tr>
<tr>
<td>X+9</td>
<td>X+17</td>
<td>v2</td>
<td>v2</td>
<td>
<ul>
docs/tasks/access-application-cluster/access-cluster.md
+10
View File
@@ -246,6 +246,16 @@ As mentioned above, you use the `kubectl cluster-info` command to retrieve the s
If you haven't specified a name for your port, you don't have to specify *port_name* in the URL.
By default, the API server proxies to your service using http. To use https, prefix the service name with `https:`:
`http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`https:service_name:[port_name]`*`/proxy`
The supported formats for the name segment of the URL are:
* `<service_name>` - proxies to the default or unnamed port using http
* `<service_name>:<port_name>` - proxies to the specified port using http
* `https:<service_name>:` - proxies to the default or unnamed port using https (note the trailing colon)
* `https:<service_name>:<port_name>` - proxies to the specified port using https
##### Examples
* To access the Elasticsearch service endpoint `_search?q=user:kimchy`, you would use: `http://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_search?q=user:kimchy`
docs/tasks/administer-cluster/encrypt-data.md
+2
View File
@@ -14,6 +14,8 @@ This page shows how to enable and configure encryption of secret data at rest.
* Kubernetes version 1.7.0 or later is required
* etcd v3 or later is required
* Encryption at rest is alpha in 1.7.0 which means it may change without notice. Users may be required to decrypt their data prior to upgrading to 1.8.0.
{% endcapture %}
docs/tasks/administer-cluster/highly-available-master.md
+1 -2
View File
@@ -154,5 +154,4 @@ To make such deployment secure, communication between etcd instances is authoriz
## Additional reading
[Automated HA master deployment - design doc](https://git.k8s.io/community/contributors/design-proposals/ha_master.md)
[Automated HA master deployment - design doc](https://git.k8s.io/community/contributors/design-proposals/cluster-lifecycle/ha_master.md)
docs/tasks/administer-cluster/memory-constraint-namespace.md
+1 -1
View File
@@ -123,7 +123,7 @@ kubectl delete pod constraints-mem-demo --namespace=constraints-mem-example
## Attempt to create a Pod that exceeds the maximum memory constraint
Here's the configuration file for a Pod that has one Container. The Container specifies a
memory request of 700 MiB and a memory limit of 1.5 GiB.
memory request of 800 MiB and a memory limit of 1.5 GiB.
{% include code.html language="yaml" file="memory-constraints-pod-2.yaml" ghlink="/docs/tasks/administer-cluster/memory-constraints-pod-2.yaml" %}
docs/tasks/administer-cluster/namespaces.md
+4 -4
View File
@@ -63,7 +63,7 @@ to define *Hard* resource usage limits that a *Namespace* may consume.
A limit range defines min/max constraints on the amount of resources a single entity can consume in
a *Namespace*.
See [Admission control: Limit Range](https://git.k8s.io/community/contributors/design-proposals/admission_control_limit_range.md)
See [Admission control: Limit Range](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md)
A namespace can be in one of two phases:
@@ -236,9 +236,9 @@ Let's create some contents.
```shell
$ kubectl run snowflake --image=kubernetes/serve_hostname --replicas=2
```
We have just created a deployment whose replica size is 2 that is running the pod called snowflake with a basic container that just serves the hostname.
We have just created a deployment whose replica size is 2 that is running the pod called snowflake with a basic container that just serves the hostname.
Note that `kubectl run` creates deployments only on Kubernetes cluster >= v1.2. If you are running older versions, it creates replication controllers instead.
If you want to obtain the old behavior, use `--generator=run/v1` to create replication controllers. See [`kubectl run`](/docs/user-guide/kubectl/v1.7/#run) for more details.
If you want to obtain the old behavior, use `--generator=run/v1` to create replication controllers. See [`kubectl run`](/docs/user-guide/kubectl/v1.7/#run) for more details.
```shell
$ kubectl get deployment
@@ -322,7 +322,7 @@ The Namespace provides a unique scope for:
2. delegated management authority to trusted users
3. ability to limit community resource consumption
Use cases include:
Use cases include:
1. As a cluster operator, I want to support multiple user communities on a single cluster.
2. As a cluster operator, I want to delegate authority to partitions of the cluster to trusted users
docs/tasks/debug-application-cluster/debug-stateful-set.md
-1
View File
@@ -18,7 +18,6 @@ This task shows you how to debug a StatefulSet.
{% capture prerequisites %}
* You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster.
* You should have a StatefulSet running that you want to investigate.
docs/tutorials/stateful-application/basic-stateful-set.md
+9 -15
View File
@@ -22,14 +22,14 @@ following Kubernetes concepts.
* [Pods](/docs/user-guide/pods/single-container/)
* [Cluster DNS](/docs/concepts/services-networking/dns-pod-service/)
* [Headless Services](/docs/concepts/services-networking/service/#headless-services)
* [PersistentVolumes](/docs/concepts/storage/volumes/)
* [PersistentVolumes](/docs/concepts/storage/persistent-volumes/)
* [PersistentVolume Provisioning](https://github.com/kubernetes/examples/tree/{{page.githubbranch}}/staging/persistent-volume-provisioning/)
* [StatefulSets](/docs/concepts/abstractions/controllers/statefulsets/)
* [kubectl CLI](/docs/user-guide/kubectl)
This tutorial assumes that your cluster is configured to dynamically provision
PersistentVolumes. If your cluster is not configured to do so, you
will have to manually provision five 1 GiB volumes prior to starting this
will have to manually provision two 1 GiB volumes prior to starting this
tutorial.
{% endcapture %}
@@ -37,7 +37,7 @@ tutorial.
StatefulSets are intended to be used with stateful applications and distributed
systems. However, the administration of stateful applications and
distributed systems on Kubernetes is a broad, complex topic. In order to
demonstrate the basic features of a StatefulSet, and to not conflate the former
demonstrate the basic features of a StatefulSet, and not to conflate the former
topic with the latter, you will deploy a simple web application using a StatefulSet.
After this tutorial, you will be familiar with the following.
@@ -262,8 +262,7 @@ www-web-0 Bound pvc-15c268c7-b507-11e6-932f-42010a800002 1Gi RWO
www-web-1 Bound pvc-15c79307-b507-11e6-932f-42010a800002 1Gi RWO 48s
```
The StatefulSet controller created two PersistentVolumeClaims that are
bound to two [PersistentVolumes](/docs/concepts/storage/volumes/). As the
cluster used in this tutorial is configured to dynamically provision
bound to two [PersistentVolumes](/docs/concepts/storage/persistent-volumes/). As the cluster used in this tutorial is configured to dynamically provision
PersistentVolumes, the PersistentVolumes were created and bound automatically.
The NGINX webservers, by default, will serve an index file at
@@ -330,7 +329,7 @@ web-1
Even though `web-0` and `web-1` were rescheduled, they continue to serve their
hostnames because the PersistentVolumes associated with their
PersistentVolumeClaims are remounted to their `volumeMount`s. No matter what
PersistentVolumeClaims are remounted to their `volumeMounts`. No matter what
node `web-0`and `web-1` are scheduled on, their PersistentVolumes will be
mounted to the appropriate mount points.
@@ -338,8 +337,7 @@ mounted to the appropriate mount points.
Scaling a StatefulSet refers to increasing or decreasing the number of replicas.
This is accomplished by updating the `replicas` field. You can use either
[`kubectl scale`](/docs/user-guide/kubectl/{{page.version}}/#scale) or
[`kubectl patch`](/docs/user-guide/kubectl/{{page.version}}/#patch) to scale a Stateful
Set.
[`kubectl patch`](/docs/user-guide/kubectl/{{page.version}}/#patch) to scale a StatefulSet.
### Scaling Up
@@ -440,10 +438,7 @@ www-web-4 Bound pvc-e11bb5f8-b508-11e6-932f-42010a800002 1Gi RWO
```
There are still five PersistentVolumeClaims and five PersistentVolumes.
When exploring a Pod's [stable storage](#stable-storage), we saw that the
PersistentVolumes mounted to the Pods of a StatefulSet are not deleted when
the StatefulSet's Pods are deleted. This is still true when Pod deletion is
caused by scaling the StatefulSet down.
When exploring a Pod's [stable storage](#writing-to-stable-storage), we saw that the PersistentVolumes mounted to the Pods of a StatefulSet are not deleted whenthe StatefulSet's Pods are deleted. This is still true when Pod deletion is caused by scaling the StatefulSet down.
## Updating StatefulSets
@@ -721,8 +716,7 @@ automatically update Pods when a modification is made to the StatefulSet's
## Deleting StatefulSets
StatefulSet supports both Non-Cascading and Cascading deletion. In a
Non-Cascading Delete, the StatefulSet's Pods are not deleted when the Stateful
Set is deleted. In a Cascading Delete, both the StatefulSet and its Pods are
Non-Cascading Delete, the StatefulSet's Pods are not deleted when the StatefulSet is deleted. In a Cascading Delete, both the StatefulSet and its Pods are
deleted.
### Non-Cascading Delete
@@ -866,7 +860,7 @@ web-1 0/1 Terminating 0 29m
```
As you saw in the [Scaling Down](#ordered-pod-termination) section, the Pods
As you saw in the [Scaling Down](#scaling-down) section, the Pods
are terminated one at a time, with respect to the reverse order of their ordinal
indices. Before terminating a Pod, the StatefulSet controller waits for
the Pod's successor to be completely terminated.
docs/user-guide/pod-security-policy/OWNERS.txt
-2
View File
@@ -1,2 +0,0 @@
approvers:
- pweil-
docs/user-guide/pod-security-policy/psp.yaml
-18
View File
@@ -1,18 +0,0 @@
apiVersion: extensions/v1beta1
kind: PodSecurityPolicy
metadata:
name: permissive
spec:
seLinux:
rule: RunAsAny
supplementalGroups:
rule: RunAsAny
runAsUser:
rule: RunAsAny
fsGroup:
rule: RunAsAny
hostPorts:
- min: 8000
max: 8080
volumes:
- '*'