merge upstream master
This commit is contained in:
Zach Arnold
@@ -251,11 +251,11 @@ rules:
|
||||
|
||||
The following cloud providers have implemented CCMs:
|
||||
|
||||
* Digital Ocean
|
||||
* [Digital Ocean](https://github.com/digitalocean/digitalocean-cloud-controller-manager)
|
||||
* [Oracle](https://github.com/oracle/oci-cloud-controller-manager)
|
||||
* Azure
|
||||
* GCE
|
||||
* AWS
|
||||
* [Azure](https://github.com/kubernetes/kubernetes/tree/master/pkg/cloudprovider/providers/azure)
|
||||
* [GCE](https://github.com/kubernetes/kubernetes/tree/master/pkg/cloudprovider/providers/gce)
|
||||
* [AWS](https://github.com/kubernetes/kubernetes/tree/master/pkg/cloudprovider/providers/aws)
|
||||
|
||||
## Cluster Administration
|
||||
|
||||
|
||||
@@ -32,8 +32,6 @@ Before choosing a guide, here are some considerations:
|
||||
|
||||
Note: Not all distros are actively maintained. Choose distros which have been tested with a recent version of Kubernetes.
|
||||
|
||||
-If you are using a guide involving Salt, see [Configuring Kubernetes with Salt](/docs/setup/salt/).
|
||||
|
||||
## Managing a cluster
|
||||
|
||||
* [Managing a cluster](/docs/tasks/administer-cluster/cluster-management/) describes several topics related to the lifecycle of a cluster: creating a new cluster, upgrading your cluster’s master and worker nodes, performing node maintenance (e.g. kernel upgrades), and upgrading the Kubernetes API version of a running cluster.
|
||||
|
||||
@@ -71,15 +71,29 @@ A desired state of an object is described by a Deployment, and if changes to tha
|
||||
|
||||
## Container Images
|
||||
|
||||
- The default [imagePullPolicy](/docs/concepts/containers/images/#updating-images) for a container is `IfNotPresent`, which causes the [kubelet](/docs/admin/kubelet/) to pull an image only if it does not already exist locally. If you want the image to be pulled every time Kubernetes starts the container, specify `imagePullPolicy: Always`.
|
||||
The [imagePullPolicy](/docs/concepts/containers/images/#updating-images) and the tag of the image affect when the [kubelet](/docs/admin/kubelet/) attempts to pull the specified image.
|
||||
|
||||
An alternative, but deprecated way to have Kubernetes always pull the image is to use the `:latest` tag, which will implicitly set the `imagePullPolicy` to `Always`.
|
||||
- `imagePullPolicy: IfNotPresent`: the image is pulled only if it is not already present locally.
|
||||
|
||||
- `imagePullPolicy: Always`: the image is pulled every time the pod is started.
|
||||
|
||||
- `imagePullPolicy` is omitted and either the image tag is `:latest` or it is omitted: `Always` is applied.
|
||||
|
||||
- `imagePullPolicy` is omitted and the image tag is present but not `:latest`: `IfNotPresent` is applied.
|
||||
|
||||
- `imagePullPolicy: Never`: the image is assumed to exist locally. No attempt is made to pull the image.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** You should avoid using the `:latest` tag when deploying containers in production, because this makes it hard to track which version of the image is running and hard to roll back.
|
||||
**Note:** To make sure the container always uses the same version of the image, you can specify its [digest](https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier), for example `sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2`. The digest uniquely identifies a specific version of the image, so it is never updated by Kubernetes unless you change the digest value.
|
||||
{{< /note >}}
|
||||
|
||||
- To make sure the container always uses the same version of the image, you can specify its [digest](https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier) (for example `sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2`). This uniquely identifies a specific version of the image, so it will never be updated by Kubernetes unless you change the digest value.
|
||||
{{< note >}}
|
||||
**Note:** You should avoid using the `:latest` tag when deploying containers in production as it is harder to track which version of the image is running and more difficult to roll back properly.
|
||||
{{< /note >}}
|
||||
|
||||
{{< note >}}
|
||||
**Note:** The caching semantics of the underlying image provider make even `imagePullPolicy: Always` efficient. With Docker, for example, if the image already exists, the pull attempt is fast because all image layers are cached and no image download is needed.
|
||||
{{< /note >}}
|
||||
|
||||
## Using kubectl
|
||||
|
||||
|
||||
@@ -25,13 +25,11 @@ The default pull policy is `IfNotPresent` which causes the Kubelet to skip
|
||||
pulling an image if it already exists. If you would like to always force a pull,
|
||||
you can do one of the following:
|
||||
|
||||
- set the `imagePullPolicy` of the container to `Always`;
|
||||
- use `:latest` as the tag for the image to use;
|
||||
- set the `imagePullPolicy` of the container to `Always`.
|
||||
- omit the `imagePullPolicy` and use `:latest` as the tag for the image to use.
|
||||
- omit the `imagePullPolicy` and the tag for the image to use.
|
||||
- enable the [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) admission controller.
|
||||
|
||||
If you did not specify tag of your image, it will be assumed as `:latest`, with
|
||||
pull image policy of `Always` correspondingly.
|
||||
|
||||
Note that you should avoid using `:latest` tag, see [Best Practices for Configuration](/docs/concepts/configuration/overview/#container-images) for more information.
|
||||
|
||||
## Using a Private Registry
|
||||
|
||||
@@ -95,6 +95,8 @@ In order for the Ingress resource to work, the cluster must have an Ingress cont
|
||||
* [Traefik](https://github.com/containous/traefik) is a fully featured ingress controller
|
||||
([Let's Encrypt](https://letsencrypt.org), secrets, http2, websocket...), and it also comes with commercial support by [Containous](https://containo.us/services)
|
||||
* [NGINX, Inc.](https://www.nginx.com/) offers support and maintenance for the [NGINX Ingress Controller for Kubernetes](https://www.nginx.com/products/nginx/kubernetes-ingress-controller)
|
||||
* [HAProxy](http://www.haproxy.org/) based ingress controller [jcmoraisjr/haproxy-ingress](https://github.com/jcmoraisjr/haproxy-ingress) which is mentioned on this blog post [HAProxy Ingress Controller for Kubernetes](https://www.haproxy.com/blog/haproxy_ingress_controller_for_kubernetes/)
|
||||
* [Istio](https://istio.io/) based ingress controller [Control Ingress Traffic](https://istio.io/docs/tasks/traffic-management/ingress/)
|
||||
|
||||
{{< note >}}
|
||||
**Note:** Review the documentation for your controller to find its specific support policy.
|
||||
|
||||
@@ -92,13 +92,70 @@ __egress__: Each `NetworkPolicy` may include a list of whitelist `egress` rules.
|
||||
So, the example NetworkPolicy:
|
||||
|
||||
1. isolates "role=db" pods in the "default" namespace for both ingress and egress traffic (if they weren't already isolated)
|
||||
2. allows connections to TCP port 6379 of "role=db" pods in the "default" namespace from any pod in the "default" namespace with the label "role=frontend"
|
||||
3. allows connections to TCP port 6379 of "role=db" pods in the "default" namespace from any pod in a namespace with the label "project=myproject"
|
||||
4. allows connections to TCP port 6379 of "role=db" pods in the "default" namespace from IP addresses that are in CIDR 172.17.0.0/16 and not in 172.17.1.0/24
|
||||
5. allows connections from any pod in the "default" namespace with the label "role=db" to CIDR 10.0.0.0/24 on TCP port 5978
|
||||
2. allows connections to TCP port 6379 of "role=db" pods in the "default" namespace from:
|
||||
* any pod in the "default" namespace with the label "role=frontend"
|
||||
* any pod in a namespace with the label "project=myproject"
|
||||
* IP addresses in the ranges 172.17.0.0–172.17.0.255 and 172.17.2.0–172.17.255.255 (ie, all of 172.17.0.0/16 except 172.17.1.0/24)
|
||||
3. allows connections from any pod in the "default" namespace with the label "role=db" to CIDR 10.0.0.0/24 on TCP port 5978
|
||||
|
||||
See the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) walkthrough for further examples.
|
||||
|
||||
## Behavior of `to` and `from` selectors
|
||||
|
||||
There are four kinds of selectors that can be specified in an `ingress` `from` section or `egress` `to` section:
|
||||
|
||||
__podSelector__: This selects particular Pods in the same namespace as the `NetworkPolicy` which should be allowed as ingress sources or egress destinations.
|
||||
|
||||
__namespaceSelector__: This selects particular namespaces for which all Pods should be allowed as ingress sources or egress destinations.
|
||||
|
||||
__namespaceSelector__ *and* __podSelector__: A single `to`/`from` entry that specifies both `namespaceSelector` and `podSelector` selects particular Pods within particular namespaces. Be careful to use correct YAML syntax; this policy:
|
||||
|
||||
```yaml
|
||||
...
|
||||
ingress:
|
||||
- from:
|
||||
- namespaceSelector:
|
||||
matchLabels:
|
||||
user: alice
|
||||
podSelector:
|
||||
matchLabels:
|
||||
role: client
|
||||
...
|
||||
```
|
||||
|
||||
contains a single `from` element allowing connections from Pods with the label `role=client` in namespaces with the label `user=alice`. But *this* policy:
|
||||
|
||||
```yaml
|
||||
...
|
||||
ingress:
|
||||
- from:
|
||||
- namespaceSelector:
|
||||
matchLabels:
|
||||
user: alice
|
||||
- podSelector:
|
||||
matchLabels:
|
||||
role: client
|
||||
...
|
||||
```
|
||||
|
||||
contains two elements in the `from` array, and allows connections from Pods in the local Namespace with the label `role=client`, *or* from any Pod in any namespace with the label `user=alice`.
|
||||
|
||||
When in doubt, use `kubectl describe` to see how Kubernetes has interpreted the policy.
|
||||
|
||||
__ipBlock__: This selects particular IP CIDR ranges to allow as ingress sources or egress destinations. These should be cluster-external IPs, since Pod IPs are ephemeral and unpredictable.
|
||||
|
||||
Cluster ingress and egress mechanisms often require rewriting the source or destination IP
|
||||
of packets. In cases where this happens, it is not defined whether this happens before or
|
||||
after NetworkPolicy processing, and the behavior may be different for different
|
||||
combinations of network plugin, cloud provider, `Service` implementation, etc.
|
||||
|
||||
In the case of ingress, this means that in some cases you may be able to filter incoming
|
||||
packets based on the actual original source IP, while in other cases, the "source IP" that
|
||||
the NetworkPolicy acts on may be the IP of a `LoadBalancer` or of the Pod's node, etc.
|
||||
|
||||
For egress, this means that connections from pods to `Service` IPs that get rewritten to
|
||||
cluster-external IPs may or may not be subject to `ipBlock`-based policies.
|
||||
|
||||
## Default policies
|
||||
|
||||
By default, if no policies exist in a namespace, then all ingress and egress traffic is allowed to and from pods in that namespace. The following examples let you change the default behavior
|
||||
|
||||
@@ -383,18 +383,19 @@ A Kubernetes administrator can specify additional mount options for when a Persi
|
||||
|
||||
The following volume types support mount options:
|
||||
|
||||
* GCEPersistentDisk
|
||||
* AWSElasticBlockStore
|
||||
* AzureFile
|
||||
* AzureDisk
|
||||
* NFS
|
||||
* iSCSI
|
||||
* RBD (Ceph Block Device)
|
||||
* AzureFile
|
||||
* CephFS
|
||||
* Cinder (OpenStack block storage)
|
||||
* GCEPersistentDisk
|
||||
* Glusterfs
|
||||
* VsphereVolume
|
||||
* NFS
|
||||
* Quobyte Volumes
|
||||
* RBD (Ceph Block Device)
|
||||
* StorageOS
|
||||
* VsphereVolume
|
||||
* iSCSI
|
||||
|
||||
Mount options are not validated, so mount will simply fail if one is invalid.
|
||||
|
||||
@@ -514,7 +515,7 @@ metadata:
|
||||
spec:
|
||||
containers:
|
||||
- name: myfrontend
|
||||
image: dockerfile/nginx
|
||||
image: nginx
|
||||
volumeMounts:
|
||||
- mountPath: "/var/www/html"
|
||||
name: mypd
|
||||
|
||||
@@ -972,7 +972,7 @@ spec:
|
||||
For more information including Dynamic Provisioning and Persistent Volume Claims, please see the
|
||||
[StorageOS examples](https://github.com/kubernetes/examples/blob/master/staging/volumes/storageos).
|
||||
|
||||
### vsphereVolume {#vsphereVolume}
|
||||
### vsphereVolume {#vspherevolume}
|
||||
|
||||
{{< note >}}
|
||||
**Prerequisite:** Kubernetes with vSphere Cloud Provider configured. For cloudprovider
|
||||
|
||||
@@ -21,7 +21,7 @@ Some typical uses of a DaemonSet are:
|
||||
- running a cluster storage daemon, such as `glusterd`, `ceph`, on each node.
|
||||
- running a logs collection daemon on every node, such as `fluentd` or `logstash`.
|
||||
- running a node monitoring daemon on every node, such as [Prometheus Node Exporter](
|
||||
https://github.com/prometheus/node_exporter), `collectd`, Dynatrace OneAgent, Datadog agent, New Relic agent, or Ganglia `gmond`.
|
||||
https://github.com/prometheus/node_exporter), `collectd`, Dynatrace OneAgent, Datadog agent, New Relic agent, Ganglia `gmond` or Instana agent.
|
||||
|
||||
In a simple case, one DaemonSet, covering all nodes, would be used for each type of daemon.
|
||||
A more complex setup might use multiple DaemonSets for a single type of daemon, but with
|
||||
|
||||
Reference in New Issue
Block a user