Merge branch 'master' into release-1.8
This commit is contained in:
@@ -100,11 +100,11 @@ If you haven't specified a name for your port, you don't have to specify *port_n
|
||||
|
||||
#### Using web browsers to access services running on the cluster
|
||||
|
||||
You may be able to put an apiserver proxy url into the address bar of a browser. However:
|
||||
You may be able to put an apiserver proxy URL into the address bar of a browser. However:
|
||||
|
||||
- Web browsers cannot usually pass tokens, so you may need to use basic (password) auth. Apiserver can be configured to accept basic auth,
|
||||
but your cluster may not be configured to accept basic auth.
|
||||
- Some web apps may not work, particularly those with client side javascript that construct urls in a
|
||||
- Some web apps may not work, particularly those with client side javascript that construct URLs in a
|
||||
way that is unaware of the proxy path prefix.
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
@@ -43,7 +43,7 @@ the corresponding `PersistentVolume` is not be deleted. Instead, it is moved to
|
||||
This list also includes the name of the claims that are bound to each volume
|
||||
for easier identification of dynamically provisioned volumes.
|
||||
|
||||
1. Chose one of your PersistentVolumes and change its reclaim policy:
|
||||
1. Choose one of your PersistentVolumes and change its reclaim policy:
|
||||
|
||||
kubectl patch pv <your-pv-name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'
|
||||
|
||||
|
||||
@@ -0,0 +1,78 @@
|
||||
---
|
||||
assignees:
|
||||
- danwent
|
||||
title: Use Cilium for NetworkPolicy
|
||||
---
|
||||
|
||||
{% capture overview %}
|
||||
This page shows how to use Cilium for NetworkPolicy.
|
||||
|
||||
For background on Cilium, read the [Introduction to Cilium](http://cilium.readthedocs.io/en/latest/intro/).
|
||||
{% endcapture %}
|
||||
|
||||
{% capture prerequisites %}
|
||||
|
||||
{% include task-tutorial-prereqs.md %}
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
{% capture steps %}
|
||||
## Deploying Cilium on Minikube for Basic Testing
|
||||
|
||||
To get familiar with Cilium easily you can follow the
|
||||
[Cilium Kubernetes Getting Started Guide](http://www.cilium.io/try)
|
||||
to perform a basic DaemonSet installation of Cilium in minikube.
|
||||
|
||||
Installation in a minikube setup uses a simple ''all-in-one'' YAML
|
||||
file that includes DaemonSet configurations for Cilium and a key-value store
|
||||
(consul) as well as appropriate RBAC settings:
|
||||
|
||||
```shell
|
||||
$ kubectl create -f https://raw.githubusercontent.com/cilium/cilium/master/examples/minikube/cilium-ds.yaml
|
||||
clusterrole "cilium" created
|
||||
serviceaccount "cilium" created
|
||||
clusterrolebinding "cilium" created
|
||||
daemonset "cilium-consul" created
|
||||
daemonset "cilium" created
|
||||
```
|
||||
|
||||
The remainder of the Getting Started Guide explains how to enforce both L3/L4 (i.e., IP address + port) security
|
||||
policies, as well as L7 (e.g., HTTP) security policies using an example application.
|
||||
|
||||
## Deploying Cilium for Production Use
|
||||
|
||||
For detailed instructions around deploying Cilium for production, see:
|
||||
[Cilium Administrator Guide](http://cilium.readthedocs.io/en/latest/admin/) This
|
||||
documentation includes detailed requirements, instructions and example production DaemonSet files.
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
{% capture discussion %}
|
||||
## Understanding Cilium components
|
||||
|
||||
Deploying a cluster with Cilium adds Pods to the `kube-system` namespace. To see this list of Pods run:
|
||||
|
||||
```shell
|
||||
kubectl get pods --namespace=kube-system
|
||||
```
|
||||
|
||||
You'll see a list of Pods similar to this:
|
||||
|
||||
```console
|
||||
NAME DESIRED CURRENT READY NODE-SELECTOR AGE
|
||||
cilium 1 1 1 <none> 2m
|
||||
...
|
||||
```
|
||||
|
||||
There are two main components to be aware of:
|
||||
|
||||
- One `cilium` Pod runs on each node in your cluster and enforces network policy on the traffic to/from Pods on that node using Linux BPF.
|
||||
- For production deployments, Cilium should leverage the key-value store cluster (e.g., etcd) used by Kubernetes, which typically runs on the Kubernetes master nodes. The [Cilium Administrator Guide](http://cilium.readthedocs.io/en/latest/admin/) includes an example DaemonSet which can be customized to point to this key-value store cluster. The simple ''all-in-one'' DaemonSet for minikube requires no such configuration because it automatically deploys a `cilium-consul` Pod to provide a key-value store.
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
{% capture whatsnext %}
|
||||
Once your cluster is running, you can follow the [NetworkPolicy getting started guide](/docs/getting-started-guides/network-policy/walkthrough) to try out Kubernetes NetworkPolicy with Cilium. Have fun, and if you have questions, contact us using the [Cilium Slack Channel](https://cilium.herokuapp.com/).
|
||||
{% endcapture %}
|
||||
|
||||
{% include templates/task.md %}
|
||||
@@ -194,7 +194,7 @@ If the majority of etcd members have permanently failed, the etcd cluster is con
|
||||
|
||||
The upgrade procedure described in this document assumes that either:
|
||||
|
||||
1. The etcd cluster has only a single node
|
||||
1. The etcd cluster has only a single node.
|
||||
2. The etcd cluster has multiple nodes.
|
||||
|
||||
In this case, the upgrade procedure requires shutting down the
|
||||
|
||||
@@ -243,7 +243,7 @@ kubectl delete namespace constraints-cpu-example
|
||||
|
||||
* [Configure Default Memory Requests and Limits for a Namespace](/docs/tasks/administer-cluster/memory-default-namespace/)
|
||||
|
||||
* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/default-cpu-request-limit/)
|
||||
* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/cpu-default-namespace/)
|
||||
|
||||
* [Configure Minimum and Maximum Memory Constraints for a Namespace](/docs/tasks/administer-cluster/memory-constraint-namespace/)
|
||||
|
||||
|
||||
@@ -5,13 +5,14 @@ approvers:
|
||||
title: Declare Network Policy
|
||||
---
|
||||
{% capture overview %}
|
||||
This document helps you get started using using the Kubernetes [NetworkPolicy API](/docs/concepts/services-networking/network-policies/) to declare network policies that govern how pods communicate with each other.
|
||||
This document helps you get started using the Kubernetes [NetworkPolicy API](/docs/concepts/services-networking/network-policies/) to declare network policies that govern how pods communicate with each other.
|
||||
{% endcapture %}
|
||||
|
||||
{% capture prerequisites %}
|
||||
You'll need to have a Kubernetes cluster in place, with network policy support. There are a number of network providers that support NetworkPolicy, including:
|
||||
|
||||
* [Calico](/docs/tasks/configure-pod-container/calico-network-policy/)
|
||||
* [Cilium](/docs/tasks/configure-pod-container/cilium-network-policy/)
|
||||
* [Romana](/docs/tasks/configure-pod-container/romana-network-policy/)
|
||||
* [Weave Net](/docs/tasks/configure-pod-container/weave-network-policy/)
|
||||
|
||||
|
||||
@@ -93,7 +93,7 @@ routed according to the following flow:
|
||||
|
||||
## ConfigMap options
|
||||
|
||||
Options for the kube-dns `kube-system:kube-dns` ConfigMap
|
||||
Options for the kube-dns `kube-system:kube-dns` ConfigMap:
|
||||
|
||||
| Field | Format | Description |
|
||||
| ----- | ------ | ----------- |
|
||||
@@ -107,7 +107,7 @@ Options for the kube-dns `kube-system:kube-dns` ConfigMap
|
||||
In this example, the user has a Consul DNS service discovery system that they wish to
|
||||
integrate with kube-dns. The consul domain server is located at 10.150.0.1, and
|
||||
all consul names have the suffix “.consul.local”. To configure Kubernetes, the
|
||||
cluster administrator simply creates a ConfigMap object as shown below.
|
||||
cluster administrator simply creates a ConfigMap object as shown below.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
|
||||
@@ -83,7 +83,7 @@ is the first provider, the first key is used for encryption.
|
||||
|
||||
## Encrypting your data
|
||||
|
||||
Create a new encryption config file
|
||||
Create a new encryption config file:
|
||||
|
||||
```yaml
|
||||
kind: EncryptionConfig
|
||||
@@ -107,9 +107,9 @@ To create a new secret perform the following steps:
|
||||
head -c 32 /dev/urandom | base64
|
||||
```
|
||||
|
||||
2. Place that value in the secret field.
|
||||
3. Set the `--experimental-encryption-provider-config` flag on the `kube-apiserver` to point to the location of the config file
|
||||
4. Restart your API server.
|
||||
2. Place that value in the secret field.
|
||||
3. Set the `--experimental-encryption-provider-config` flag on the `kube-apiserver` to point to the location of the config file.
|
||||
4. Restart your API server.
|
||||
|
||||
**IMPORTANT:** Your config file contains keys that can decrypt content in etcd, so you must properly restrict permissions on your masters so only the user who runs the kube-apiserver can read it.
|
||||
|
||||
@@ -168,7 +168,7 @@ the presence of a highly available deployment where multiple `kube-apiserver` pr
|
||||
5. Run `kubectl get secrets -o json | kubectl replace -f -` to encrypt all existing secrets with the new key
|
||||
6. Remove the old decryption key from the config after you back up etcd with the new key in use and update all secrets
|
||||
|
||||
With a single `kube-apiserver`, step 2 may be skipped
|
||||
With a single `kube-apiserver`, step 2 may be skipped.
|
||||
|
||||
|
||||
## Decrypting all data
|
||||
|
||||
@@ -7,7 +7,7 @@ This page shows how to configure and enable the ip-masq-agent.
|
||||
{% endcapture %}
|
||||
|
||||
{% capture prerequisites %}
|
||||
Kubernetes 1.7
|
||||
|
||||
{% include task-tutorial-prereqs.md %}
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
@@ -195,7 +195,7 @@ resources:
|
||||
```
|
||||
|
||||
Because your Container did not specify its own memory request and limit, it was given the
|
||||
[default memory request and limit](/docs/tasks/administer-cluster/default-memory-request-limit/)
|
||||
[default memory request and limit](/docs/tasks/administer-cluster/memory-default-namespace/)
|
||||
from the LimitRange.
|
||||
|
||||
At this point, your Container might be running or it might not be running. Recall that a prerequisite
|
||||
@@ -245,7 +245,7 @@ kubectl delete namespace constraints-mem-example
|
||||
|
||||
* [Configure Default Memory Requests and Limits for a Namespace](/docs/tasks/administer-cluster/memory-default-namespace/)
|
||||
|
||||
* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/default-cpu-request-limit/)
|
||||
* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/cpu-default-namespace/)
|
||||
|
||||
* [Configure Minimum and Maximum CPU Constraints for a Namespace](/docs/tasks/administer-cluster/cpu-constraint-namespace/)
|
||||
|
||||
|
||||
@@ -166,7 +166,7 @@ it can be allowed to run in a namespace that is restricted by a quota.
|
||||
|
||||
### For cluster administrators
|
||||
|
||||
* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/default-cpu-request-limit/)
|
||||
* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/cpu-default-namespace/)
|
||||
|
||||
* [Configure Minimum and Maximum Memory Constraints for a Namespace](/docs/tasks/administer-cluster/memory-constraint-namespace/)
|
||||
|
||||
|
||||
@@ -205,7 +205,7 @@ $ kubectl config current-context
|
||||
lithe-cocoa-92103_kubernetes
|
||||
```
|
||||
|
||||
The next step is to define a context for the kubectl client to work in each namespace. The value of "cluster" and "user" fields are copied from the current context.
|
||||
The next step is to define a context for the kubectl client to work in each namespace. The values of "cluster" and "user" fields are copied from the current context.
|
||||
|
||||
```shell
|
||||
$ kubectl config set-context dev --namespace=development --cluster=lithe-cocoa-92103_kubernetes --user=lithe-cocoa-92103_kubernetes
|
||||
|
||||
@@ -205,7 +205,7 @@ it will begin evicting pods.
|
||||
|
||||
The `kubelet` ranks pods for eviction as follows:
|
||||
|
||||
* by their quality of service
|
||||
* by their quality of service.
|
||||
* by the consumption of the starved compute resource relative to the pods scheduling request.
|
||||
|
||||
As a result, pod eviction occurs in the following order:
|
||||
|
||||
@@ -147,7 +147,7 @@ kubectl delete namespace quota-object-example
|
||||
|
||||
* [Configure Default Memory Requests and Limits for a Namespace](/docs/tasks/administer-cluster/memory-default-namespace/)
|
||||
|
||||
* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/default-cpu-request-limit/)
|
||||
* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/cpu-default-namespace/)
|
||||
|
||||
* [Configure Minimum and Maximum Memory Constraints for a Namespace](/docs/tasks/administer-cluster/memory-constraint-namespace/)
|
||||
|
||||
|
||||
@@ -152,7 +152,7 @@ kubectl delete namespace quota-mem-cpu-example
|
||||
|
||||
* [Configure Default Memory Requests and Limits for a Namespace](/docs/tasks/administer-cluster/memory-default-namespace/)
|
||||
|
||||
* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/default-cpu-request-limit/)
|
||||
* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/cpu-default-namespace/)
|
||||
|
||||
* [Configure Minimum and Maximum Memory Constraints for a Namespace](/docs/tasks/administer-cluster/memory-constraint-namespace/)
|
||||
|
||||
|
||||
@@ -113,7 +113,7 @@ kubectl delete namespace quota-pod-example
|
||||
|
||||
* [Configure Default Memory Requests and Limits for a Namespace](/docs/tasks/administer-cluster/memory-default-namespace/)
|
||||
|
||||
* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/default-cpu-request-limit/)
|
||||
* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/cpu-default-namespace/)
|
||||
|
||||
* [Configure Minimum and Maximum Memory Constraints for a Namespace](/docs/tasks/administer-cluster/memory-constraint-namespace/)
|
||||
|
||||
|
||||
@@ -16,8 +16,8 @@ In future Kubernetes releases, cloud vendors should link code that satisfies the
|
||||
|
||||
To build cloud-controller-manager for your cloud, follow these steps:
|
||||
|
||||
* Write a cloudprovider that satisfies the [cloudprovider.Interface](https://git.k8s.io/kubernetes/pkg/cloudprovider/cloud.go).
|
||||
* Link the cloudprovider to cloud-controller-manager
|
||||
1. Write a cloudprovider that satisfies the [cloudprovider.Interface](https://git.k8s.io/kubernetes/pkg/cloudprovider/cloud.go).
|
||||
2. Link the cloudprovider to cloud-controller-manager.
|
||||
|
||||
The methods in [cloudprovider.Interface](https://git.k8s.io/kubernetes/pkg/cloudprovider/cloud.go) are self-explanatory. All of the
|
||||
[existing providers](https://git.k8s.io/kubernetes/pkg/cloudprovider/providers) satisfy this interface. If your cloud is already a part
|
||||
|
||||
@@ -34,7 +34,7 @@ You can use `kubectl drain` to safely evict all of your pods from a
|
||||
node before you perform maintenance on the node (e.g. kernel upgrade,
|
||||
hardware maintenance, etc.). Safe evictions allow the pod's containers
|
||||
to
|
||||
[gracefully terminate](/docs/user-guide/production-pods.md#lifecycle-hooks-and-termination-notice) and
|
||||
[gracefully terminate](/docs/tasks/#lifecycle-hooks-and-termination-notice) and
|
||||
will respect the `PodDisruptionBudgets` you have specified.
|
||||
|
||||
**Note:** By default `kubectl drain` will ignore certain system pods on the node
|
||||
|
||||
@@ -107,7 +107,7 @@ policy.
|
||||
|
||||
The [network policies](/docs/tasks/administer-cluster/declare-network-policy/) for a namespace
|
||||
allows application authors to restrict which pods in other namespaces may access pods and ports
|
||||
within their namespace. Many of the supported [Kubernetes networking providers](/docs/concepts/cluster-administration/networking/)
|
||||
within their namespaces. Many of the supported [Kubernetes networking providers](/docs/concepts/cluster-administration/networking/)
|
||||
now respect network policy.
|
||||
|
||||
Quota and limit ranges can also be used to control whether users may request node ports or
|
||||
|
||||
@@ -94,7 +94,7 @@ $ export KUBECONFIG=/path/to/standalone/.kube/config
|
||||
|
||||
* The ca_file, key_file, and cert_file referenced above are generated on the
|
||||
kube master at cluster turnup. They can be found on the master under
|
||||
`/srv/kubernetes`. Bearer token/basic auth are also generated on the kube master.
|
||||
`/srv/kubernetes`. Bearer token/basic auth is also generated on the kube master.
|
||||
|
||||
For more details on `kubeconfig` see [Authenticating Across Clusters with kubeconfig](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/),
|
||||
and/or run `kubectl config -h`.
|
||||
|
||||
@@ -84,7 +84,6 @@ If we look at our Kubernetes API server (running on host `my-master`), we see th
|
||||
[joe@my-master ~] $ kubectl get pods
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
static-web-my-node1 1/1 Running 0 2m
|
||||
|
||||
```
|
||||
|
||||
Labels from the static pod are propagated into the mirror-pod and can be used as usual for filtering.
|
||||
@@ -97,7 +96,6 @@ pods/static-web-my-node1
|
||||
[joe@my-master ~] $ kubectl get pods
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
static-web-my-node1 1/1 Running 0 12s
|
||||
|
||||
```
|
||||
|
||||
Back to our `my-node1` host, we can try to stop the container manually and see, that kubelet automatically restarts it in a while:
|
||||
|
||||
Reference in New Issue
Block a user