Merge branch 'master' into release-1.8
This commit is contained in:
steveperry-53
@@ -77,9 +77,9 @@ Cluster DNS is a DNS server, in addition to the other DNS server(s) in your envi
|
||||
|
||||
Containers started by Kubernetes automatically include this DNS server in their DNS searches.
|
||||
|
||||
#### User interface
|
||||
#### Web UI (Dashboard)
|
||||
|
||||
The kube-ui provides a read-only overview of the cluster state. For more information, see [Using an HTTP Proxy to Access the Kubernetes API](/docs/tasks/access-kubernetes-api/http-proxy-access-api/)
|
||||
[Dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard/) is a general purpose, web-based UI for Kubernetes clusters. It allows users to manage and troubleshoot applications running in the cluster, as well as the cluster itself.
|
||||
|
||||
|
||||
#### Container Resource Monitoring
|
||||
@@ -115,20 +115,20 @@ network rules on the host and performing connection forwarding.
|
||||
|
||||
### docker
|
||||
|
||||
docker is used for running containers.
|
||||
`docker` is used for running containers.
|
||||
|
||||
### rkt
|
||||
|
||||
rkt is supported experimentally for running containers as an alternative to docker.
|
||||
`rkt` is supported experimentally for running containers as an alternative to docker.
|
||||
|
||||
### supervisord
|
||||
|
||||
supervisord is a lightweight process monitor and control system that can be used to keep kubelet and docker
|
||||
`supervisord` is a lightweight process monitor and control system that can be used to keep kubelet and docker
|
||||
running.
|
||||
|
||||
### fluentd
|
||||
|
||||
fluentd is a daemon which helps provide [cluster-level logging](#cluster-level-logging).
|
||||
`fluentd` is a daemon which helps provide [cluster-level logging](#cluster-level-logging).
|
||||
{% endcapture %}
|
||||
|
||||
{% include templates/concept.md %}
|
||||
|
||||
@@ -123,7 +123,7 @@ Some possible patterns for communicating with pods in a DaemonSet are:
|
||||
|
||||
- **Push**: Pods in the DaemonSet are configured to send updates to another service, such
|
||||
as a stats database. They do not have clients.
|
||||
- **NodeIP and Known Port**: Pods in the DaemonSet can use a `hostPort`, so that the pods are reachable via the node IPs. Clients know the list of nodes ips somehow, and know the port by convention.
|
||||
- **NodeIP and Known Port**: Pods in the DaemonSet can use a `hostPort`, so that the pods are reachable via the node IPs. Clients know the list of node IPs somehow, and know the port by convention.
|
||||
- **DNS**: Create a [headless service](/docs/user-guide/services/#headless-services) with the same pod selector,
|
||||
and then discover DaemonSets using the `endpoints` resource or retrieve multiple A records from
|
||||
DNS.
|
||||
|
||||
@@ -15,8 +15,7 @@ PetSets feature from 1.4. Users of PetSets are referred to the 1.5
|
||||
[Upgrade Guide](/docs/tasks/manage-stateful-set/upgrade-pet-set-to-stateful-set/)
|
||||
for further information on how to upgrade existing PetSets to StatefulSets.**
|
||||
|
||||
A StatefulSet is a Controller that provides a unique identity to its Pods. It provides
|
||||
guarantees about the ordering of deployment and scaling.
|
||||
{% include templates/glossary/snippet.md term="statefulset" length="long" %}
|
||||
{% endcapture %}
|
||||
|
||||
{% capture body %}
|
||||
@@ -40,6 +39,7 @@ provides a set of stateless replicas. Controllers such as
|
||||
[ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) may be better suited to your stateless needs.
|
||||
|
||||
## Limitations
|
||||
|
||||
* StatefulSet is a beta resource, not available in any Kubernetes release prior to 1.5.
|
||||
* As with all alpha/beta resources, you can disable StatefulSet through the `--runtime-config` option passed to the apiserver.
|
||||
* The storage for a given Pod must either be provisioned by a [PersistentVolume Provisioner](http://releases.k8s.io/{{page.githubbranch}}/examples/persistent-volume-provisioning/README.md) based on the requested `storage class`, or pre-provisioned by an admin.
|
||||
|
||||
@@ -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 %}
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
|
||||
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".
|
||||
|
||||
@@ -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:
|
||||
|
||||
|
||||
@@ -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
|
||||
```
|
||||
|
||||
|
||||
|
||||
@@ -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 %}
|
||||
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
+5
-5
@@ -72,7 +72,7 @@ kubectl apply -f https://k8s.io/docs/tutorials/object-management-kubectl/simple_
|
||||
Print the live configuration using `kubectl get`:
|
||||
|
||||
```shell
|
||||
kubectl get -f http://k8s.io/docs/tutorials/object-management-kubectl/simple_deployment.yaml -o yaml
|
||||
kubectl get -f https://k8s.io/docs/tutorials/object-management-kubectl/simple_deployment.yaml -o yaml
|
||||
```
|
||||
|
||||
The output shows that the `kubectl.kubernetes.io/last-applied-configuration` annotation
|
||||
@@ -143,7 +143,7 @@ configuration file instead of a directory.
|
||||
Print the live configuration using `kubectl get`:
|
||||
|
||||
```shell
|
||||
kubectl get -f http://k8s.io/docs/tutorials/object-management-kubectl/simple_deployment.yaml -o yaml
|
||||
kubectl get -f https://k8s.io/docs/tutorials/object-management-kubectl/simple_deployment.yaml -o yaml
|
||||
```
|
||||
|
||||
The output shows that the `kubectl.kubernetes.io/last-applied-configuration` annotation
|
||||
@@ -194,7 +194,7 @@ kubectl scale deployment/nginx-deployment --replicas 2
|
||||
Print the live configuration using `kubectl get`:
|
||||
|
||||
```shell
|
||||
kubectl get -f http://k8s.io/docs/tutorials/object-management-kubectl/simple_deployment.yaml -o yaml
|
||||
kubectl get -f https://k8s.io/docs/tutorials/object-management-kubectl/simple_deployment.yaml -o yaml
|
||||
```
|
||||
|
||||
The output shows that the `replicas` field has been set to 2, and the `last-applied-configuration`
|
||||
@@ -248,7 +248,7 @@ kubectl apply -f https://k8s.io/docs/tutorials/object-management-kubectl/update_
|
||||
Print the live configuration using `kubectl get`:
|
||||
|
||||
```
|
||||
kubectl get -f http://k8s.io/docs/tutorials/object-management-kubectl/simple_deployment.yaml -o yaml
|
||||
kubectl get -f https://k8s.io/docs/tutorials/object-management-kubectl/simple_deployment.yaml -o yaml
|
||||
```
|
||||
|
||||
The output shows the following changes to the live configuration:
|
||||
@@ -679,7 +679,7 @@ kubectl apply -f https://k8s.io/docs/tutorials/object-management-kubectl/simple_
|
||||
Print the live configuration using `kubectl get`:
|
||||
|
||||
```shell
|
||||
kubectl get -f http://k8s.io/docs/tutorials/object-management-kubectl/simple_deployment.yaml -o yaml
|
||||
kubectl get -f https://k8s.io/docs/tutorials/object-management-kubectl/simple_deployment.yaml -o yaml
|
||||
```
|
||||
|
||||
The output shows that the API server set several fields to default values in the live
|
||||
|
||||
@@ -667,7 +667,7 @@ web-2 1/1 Running 0 18s
|
||||
Get the Pod's container.
|
||||
|
||||
```shell{% raw %}
|
||||
get po web-2 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'
|
||||
kubectl get po web-2 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'
|
||||
gcr.io/google_containers/nginx-slim:0.8
|
||||
{% endraw %}
|
||||
```
|
||||
@@ -738,7 +738,7 @@ web-1 1/1 Running 0 18s
|
||||
Get the `web-1` Pods container.
|
||||
|
||||
```shell{% raw %}
|
||||
get po web-1 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'
|
||||
kubectl get po web-1 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'
|
||||
gcr.io/google_containers/nginx-slim:0.8
|
||||
{% endraw %}
|
||||
```
|
||||
|
||||
Reference in New Issue
Block a user