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-08-25 10:30:26 -07:00
parent 9403dc361f 44f3acad1e
commit 895a6074e2
34 changed files with 311 additions and 118 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/tasks/access-application-cluster/create-external-load-balancer.md
+5 -1
View File
@@ -125,7 +125,7 @@ Service Configuration file.
"kind": "Service",
"apiVersion": "v1",
"metadata": {
"name": "example-service",
"name": "example-service"
},
"spec": {
"ports": [{
@@ -164,6 +164,10 @@ compared to the `service.spec.externalTrafficPolicy` field. The values match as
**Note that this feature is not currently implemented for all cloudproviders/environments.**
Known issues:
* AWS: [kubernetes/kubernetes#35758](https://github.com/kubernetes/kubernetes/issues/35758)
* Weave-Net: [weaveworks/weave/#2924](https://github.com/weaveworks/weave/issues/2924)
{% endcapture %}
docs/tasks/administer-cluster/cpu-constraint-namespace.md
+1 -1
View File
@@ -77,7 +77,7 @@ CPU request and limit to the Container.
* Verify that the Container specifies a CPU request that is greater than or equal to 200 millicpu.
* Verify that the Container specifies a memory limit that is less than or equal to 800 millicpu.
* Verify that the Container specifies a CPU limit that is less than or equal to 800 millicpu.
Here's the configuration file for a Pod that has one Container. The Container manifest
specifies a CPU request of 500 millicpu and a CPU limit of 800 millicpu. These satisfy the
docs/tasks/administer-cluster/declare-network-policy.md
+1
View File
@@ -86,6 +86,7 @@ spec:
## Assign the policy to the service
Use kubectl to create a NetworkPolicy from the above nginx-policy.yaml file:
```console
$ kubectl create -f nginx-policy.yaml
networkpolicy "access-nginx" created
docs/tasks/administer-cluster/dns-horizontal-autoscaler.yaml
-1
View File
@@ -22,7 +22,6 @@ spec:
- /cluster-proportional-autoscaler
- --namespace=kube-system
- --configmap=kube-dns-autoscaler
- --mode=linear
- --target=<SCALE_TARGET>
# When cluster is using large nodes(with more cores), "coresPerReplica" should dominate.
# If using small nodes, "nodesPerReplica" should dominate.
docs/tasks/administer-cluster/highly-available-master.md
+2 -2
View File
@@ -92,11 +92,11 @@ $ KUBE_GCE_ZONE=replica-zone KUBE_REPLICATE_EXISTING_MASTER=true ./cluster/kube-
## Best practices for replicating masters for HA clusters
* Try to place masters replicas in different zones. During a zone failure, all master placed inside the zone will fail.
* Try to place master replicas in different zones. During a zone failure, all masters placed inside the zone will fail.
To survive zone failure, also place nodes in multiple zones
(see [multiple-zones](/docs/admin/multiple-zones/) for details).
* Do not use a cluster with two master replicas. Consensus on a two replica cluster requires both replicas running when changing persistent state.
* Do not use a cluster with two master replicas. Consensus on a two-replica cluster requires both replicas running when changing persistent state.
As a result, both replicas are needed and a failure of any replica turns cluster into majority failure state.
A two-replica cluster is thus inferior, in terms of HA, to a single replica cluster.
docs/tasks/administer-cluster/ip-masq-agent.md
+10 -4
View File
@@ -22,7 +22,7 @@ The ip-masq-agent configures iptables rules to hide a pod's IP address behind th
* **NAT (Network Address Translation)**
Is a method of remapping one IP address to another by modifying either the source and/or destination address information in the IP header. Typically performed by a device doing IP routing.
* **Masquerading**
A form of NAT that is typically used to perform a many to one address translation, where multiple source IP addresses are masked behind a single address, which is typically the device doing the IP routing. In kubernetes this is the Node's IP address.
A form of NAT that is typically used to perform a many to one address translation, where multiple source IP addresses are masked behind a single address, which is typically the device doing the IP routing. In Kubernetes this is the Node's IP address.
* **CIDR (Classless Inter-Domain Routing)**
Based on the variable-length subnet masking, allows specifying arbitrary-length prefixes. CIDR introduced a new method of representation for IP addresses, now commonly known as **CIDR notation**, in which an address or routing prefix is written with a suffix indicating the number of bits of the prefix, such as 192.168.2.0/24.
* **Link Local**
@@ -32,10 +32,10 @@ The ip-masq-agent configures iptables rules to handle masquerading node/pod IP a
![masq/non-masq example](/images/docs/ip-masq.png)
The agent configuration file must be written in yaml or json syntax, and may contain three optional keys:
The agent configuration file must be written in YAML or JSON syntax, and may contain three optional keys:
* **nonMasqueradeCIDRs:** A list of strings in [CIDR](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing) notation that specify the non-masquerade ranges.
* **masqLinkLocal:** A boolean (true / false) which indicates whether to masquerade traffic to the link local prefix 169.254.0.0/16. False by default.
* **masqLinkLocal:** A Boolean (true / false) which indicates whether to masquerade traffic to the link local prefix 169.254.0.0/16. False by default.
* **resyncInterval:** An interval at which the agent attempts to reload config from disk. e.g. '30s' where 's' is seconds, 'ms' is milliseconds etc...
Traffic to 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16) ranges will NOT be masqueraded. Any other traffic (assumed to be internet) will be masqueraded. An example of a local destination from a pod could be its Node's IP address as well as another node's address or one of the IP addresses in Cluster's IP range. Any other traffic will be masqueraded by default. The below entries show the default set of rules that are applied by the ip-masq-agent:
@@ -50,7 +50,7 @@ MASQUERADE all -- anywhere anywhere /* ip-masq-agent:
```
By default, in GCE/GKE starting with Kubernetes version 1.7.0, the ip-masq-agent will run in your cluster. If you are running in another environment, you can add the ip-masq-agent [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) to your cluster:
By default, in GCE/GKE starting with Kubernetes version 1.7.0, if network policy is enabled or you are using a cluster CIDR not in the 10.0.0.0/8 range, the ip-masq-agent will run in your cluster. If you are running in another environment, you can add the ip-masq-agent [DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) to your cluster:
{% endcapture %}
@@ -63,6 +63,12 @@ To create an ip-masq-agent, run the following kubectl command:
kubectl create -f https://raw.githubusercontent.com/kubernetes-incubator/ip-masq-agent/master/ip-masq-agent.yaml
`
You must also apply the appropriate node label to any nodes in your cluster that you want the agent to run on.
`
kubectl label nodes my-node beta.kubernetes.io/masq-agent-ds-ready=true
`
More information can be found in the ip-masq-agent documentation [here](https://github.com/kubernetes-incubator/ip-masq-agent)
In most cases, the default set of rules should be sufficient; however, if this is not the case for your cluster, you can create and apply a [ConfigMap](/docs/tasks/configure-pod-container/configmap/) to customize the IP ranges that are affected. For example, to allow only 10.0.0.0/8 to be considered by the ip-masq-agent, you can create the following [ConfigMap](/docs/tasks/configure-pod-container/configmap/) in a file called "config".
docs/tasks/administer-federation/ingress.md
+1 -1
View File
@@ -165,7 +165,7 @@ Ingresses in the clusters comprising your federation.
To render the underlying ingress shards healthy, you need to add
backend Pods behind the service upon which the Ingress is based. There are several ways to achieve this, but
the easiest is to create a Federated Service and
Federated Replicaset. To
Federated ReplicaSet. To
create appropriately labelled pods and services in the 13 underlying clusters of
your federation:
docs/tasks/federation/set-up-cluster-federation-kubefed.md
+1 -1
View File
@@ -89,7 +89,7 @@ similar to the following:
```
CURRENT NAME CLUSTER AUTHINFO NAMESPACE
gke_myproject_asia-east1-b_gce-asia-east1 gke_myproject_asia-east1-b_gce-asia-east1 gke_myproject_asia-east1-b_gce-asia-east1
* gke_myproject_asia-east1-b_gce-asia-east1 gke_myproject_asia-east1-b_gce-asia-east1 gke_myproject_asia-east1-b_gce-asia-east1
```
docs/tasks/manage-daemon/update-daemon-set.md
+2 -2
View File
@@ -145,7 +145,7 @@ kubectl rollout status ds/<daemonset-name>
When the rollout is complete, the output is similar to this:
```shell
daemon set "<daemonset-name>" successfully rolled out
daemonset "<daemonset-name>" successfully rolled out
```
## Troubleshooting
@@ -198,7 +198,7 @@ progress.
* See [Task: Performing a rollback on a
DaemonSet](/docs/tasks/manage-daemon/rollback-daemon-set/)
* *TODO: Link to "Task: Creating a DaemonSet to adopt existing DaemonSet pods"*
* See [Concepts: Creating a DaemonSet to adopt existing DaemonSet pods](/docs/concepts/workloads/controllers/daemonset/)
{% endcapture %}
docs/tasks/run-application/run-stateless-application-deployment.md
+12 -1
View File
@@ -49,15 +49,26 @@ a Deployment that runs the nginx:1.7.9 Docker image:
Namespace: default
CreationTimestamp: Tue, 30 Aug 2016 18:11:37 -0700
Labels: app=nginx
Annotations: deployment.kubernetes.io/revision=1
Selector: app=nginx
Replicas: 2 updated | 2 total | 2 available | 0 unavailable
Replicas: 2 desired | 2 updated | 2 total | 2 available | 0 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 1 max unavailable, 1 max surge
Pod Template:
Labels: app=nginx
Containers:
nginx:
Image: nginx:1.7.9
Port: 80/TCP
Environment: <none>
Mounts: <none>
Volumes: <none>
Conditions:
Type Status Reason
---- ------ ------
Available True MinimumReplicasAvailable
Progressing True NewReplicaSetAvailable
OldReplicaSets: <none>
NewReplicaSet: nginx-deployment-1771418926 (2/2 replicas created)
No events.
docs/tasks/tls/managing-tls-in-a-cluster.md
+1 -1
View File
@@ -111,7 +111,7 @@ Notice that the `server.csr` file created in step 1 is base64 encoded
and stashed in the `.spec.request` field. We are also requesting a
certificate with the "digital signature", "key encipherment", and "server
auth" key usages. We support all key usages and extended key usages listed
[here](https://godoc.org/k8s.io/client-go/pkg/apis/certificates/v1beta1#KeyUsage)
[here](https://godoc.org/k8s.io/api/certificates/v1beta1#KeyUsage)
so you can request client certificates and other certificates using this
same API.
docs/tasks/tools/install-kubectl.md
+1 -1
View File
@@ -72,7 +72,7 @@ Here are a few methods to install kubectl.
curl -LO https://storage.googleapis.com/kubernetes-release/release/{{page.fullversion}}/bin/windows/amd64/kubectl.exe
To find out the latest stable version (for example, for scripting), take a look at https://storage.googleapis.com/kubernetes-release/release/stable.txt
To find out the latest stable version (for example, for scripting), take a look at [https://storage.googleapis.com/kubernetes-release/release/stable.txt](https://storage.googleapis.com/kubernetes-release/release/stable.txt).
2. Add the binary in to your PATH.