Merge branch 'master' of git://github.com/kubernetes/website into release-1.12
* 'master' of git://github.com/kubernetes/website: (222 commits) Add temporary owners for 1.13 release (#11453) fix Minikube 404 error. (#11461) Resolve conflicts against dev-1.13 for /ko contents (#11439) replace `run` with `create deployment` (#11392) Updated list all pods with -o wide comment (#11394) fix broken link for KubeletConfiguration (#11423) Update on pod-priority-preemption.md (#11418) Add guidelines for working with localized content (#11415) Update what-is-kubernetes.md (#11399) Remove redundant close tags and little bit formatting (#11389) Add SysEleven MetaKube as hosted solution (#11393) Add rui to sig-docs-zh team (#11391) fix Improper translation (#11384) Add pigletfly(WangBing) as a sig-docs-zh-reviewer (#11370) update link to CloudProvider Interface (#11228) Fix the "my-scheduler-as-kube-scheduler" ClusterRoleBinding. (#11112) fix non-existing "CloudProvider Interface" link (#10953) Updated ingress.md (#11213) Further updates to TLS Bootstrapping (#11258) Updated 'exec' description (#11365) ...
This commit is contained in:
Rui Chen
@@ -105,7 +105,7 @@ For example, consider key pairs `k8sclient.key` and `k8sclient.cert` that are tr
|
||||
Once etcd is configured correctly, only clients with valid certificates can access it. To give Kubernetes API server the access, configure it with the flags `--etcd-certfile=k8sclient.cert`,`--etcd-keyfile=k8sclient.key` and `--etcd-cafile=ca.cert`.
|
||||
|
||||
{{< note >}}
|
||||
**Note**: etcd authentication is not currently supported by Kubernetes. For more information, see the related issue [Support Basic Auth for Etcd v2](https://github.com/kubernetes/kubernetes/issues/23398).
|
||||
etcd authentication is not currently supported by Kubernetes. For more information, see the related issue [Support Basic Auth for Etcd v2](https://github.com/kubernetes/kubernetes/issues/23398).
|
||||
{{< /note >}}
|
||||
|
||||
## Replacing a failed etcd member
|
||||
@@ -212,7 +212,7 @@ The upgrade procedure described in this document assumes that either:
|
||||
etcd cluster. During the time the etcd cluster is shut down, the Kubernetes API Server will be read only.
|
||||
|
||||
{{< warning >}}
|
||||
**Warning**: Deviations from the assumptions are untested by continuous
|
||||
Deviations from the assumptions are untested by continuous
|
||||
integration, and deviations might create undesirable consequences. Additional information about operating an etcd cluster is available [from the etcd maintainers](https://github.com/coreos/etcd/tree/master/Documentation).
|
||||
{{< /warning >}}
|
||||
|
||||
@@ -264,7 +264,7 @@ but the rollback tool has these limitations:
|
||||
* Rollback doesn’t preserve resource versions of objects stored in etcd.
|
||||
|
||||
{{< warning >}}
|
||||
**Warning**: If the data is not kept in `application/json` format (see [Upgrade
|
||||
If the data is not kept in `application/json` format (see [Upgrade
|
||||
Procedure](#upgrade-procedure)), you will lose the option to roll back to etcd
|
||||
2.2.
|
||||
{{< /warning >}}
|
||||
@@ -276,7 +276,7 @@ resource versions. Since both the kubelet and kube-proxy use the watch API, a
|
||||
rollback might require restarting all Kubernetes components on all nodes.
|
||||
|
||||
{{< note >}}
|
||||
**Note**: At the time of writing, both Kubelet and KubeProxy are using “resource
|
||||
At the time of writing, both Kubelet and KubeProxy are using “resource
|
||||
version” only for watching (i.e. are not using resource versions for anything
|
||||
else). And both are using reflector and/or informer frameworks for watching
|
||||
(i.e. they don’t send watch requests themselves). Both those frameworks if they
|
||||
@@ -390,7 +390,7 @@ STORAGE_MEDIA_TYPE=application/json
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
**Note:** This procedure upgrades from 2.x to 3.x. Version `3.0.17` is not recommended for running in production (see [prerequisites](#prerequisites) for minimum recommended etcd versions).
|
||||
This procedure upgrades from 2.x to 3.x. Version `3.0.17` is not recommended for running in production (see [prerequisites](#prerequisites) for minimum recommended etcd versions).
|
||||
{{< /note >}}
|
||||
|
||||
## Notes for etcd Version 2.2.1
|
||||
|
||||
@@ -52,7 +52,7 @@ your existing Corefile will be retained.
|
||||
## Installing kube-dns instead of CoreDNS with kubeadm
|
||||
|
||||
{{< note >}}
|
||||
**Note:** In Kubernetes 1.11, CoreDNS has graduated to General Availability (GA)
|
||||
In Kubernetes 1.11, CoreDNS has graduated to General Availability (GA)
|
||||
and is installed by default.
|
||||
{{< /note >}}
|
||||
|
||||
@@ -63,6 +63,11 @@ value to `false`:
|
||||
kubeadm init --feature-gates=CoreDNS=false
|
||||
```
|
||||
|
||||
## Tuning CoreDNS
|
||||
|
||||
When resource utilisation is a concern, it may be useful to tune the configuration of CoreDNS. For more details, check out the
|
||||
[documentation on scaling CoreDNS]((https://github.com/coredns/deployment/blob/master/kubernetes/Scaling_CoreDNS.md)).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
@@ -75,16 +75,16 @@ The `static` policy allows containers in `Guaranteed` pods with integer CPU
|
||||
using the [cpuset cgroup controller](https://www.kernel.org/doc/Documentation/cgroup-v1/cpusets.txt).
|
||||
|
||||
{{< note >}}
|
||||
**Note:** System services such as the container runtime and the kubelet itself can continue to run on these exclusive CPUs. The exclusivity only extends to other pods.
|
||||
System services such as the container runtime and the kubelet itself can continue to run on these exclusive CPUs. The exclusivity only extends to other pods.
|
||||
{{< /note >}}
|
||||
|
||||
{{< note >}}
|
||||
**Note:** The alpha version of this policy does not guarantee static
|
||||
The alpha version of this policy does not guarantee static
|
||||
exclusive allocations across Kubelet restarts.
|
||||
{{< /note >}}
|
||||
|
||||
{{< note >}}
|
||||
**Note:** CPU Manager doesn't support offlining and onlining of
|
||||
CPU Manager doesn't support offlining and onlining of
|
||||
CPUs at runtime. Also, if the set of online CPUs changes on the node,
|
||||
the node must be drained and CPU manager manually reset by deleting the
|
||||
state file `cpu_manager_state` in the kubelet root directory.
|
||||
@@ -102,7 +102,7 @@ both part of a `Guaranteed` pod and have integer CPU `requests` are assigned
|
||||
exclusive CPUs.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** The kubelet requires a CPU reservation greater than zero be made
|
||||
The kubelet requires a CPU reservation greater than zero be made
|
||||
using either `--kube-reserved` and/or `--system-reserved` when the static
|
||||
policy is enabled. This is because zero CPU reservation would allow the shared
|
||||
pool to become empty.
|
||||
|
||||
@@ -21,7 +21,9 @@ Make sure you've configured a network provider with network policy support. Ther
|
||||
* [Romana](/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy/)
|
||||
* [Weave Net](/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy/)
|
||||
|
||||
**Note**: The above list is sorted alphabetically by product name, not by recommendation or preference. This example is valid for a Kubernetes cluster using any of these providers.
|
||||
{{< note >}}
|
||||
The above list is sorted alphabetically by product name, not by recommendation or preference. This example is valid for a Kubernetes cluster using any of these providers.
|
||||
{{< /note >}}
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
@@ -16,9 +16,9 @@ can develop their features independently from the core Kubernetes release cycles
|
||||
|
||||
{{< feature-state for_k8s_version="1.8" state="alpha" >}}
|
||||
|
||||
Before going into how to build your own cloud controller manager, some background on how it works under the hood is helpful. The cloud controller manager is code from `kube-controller-manager` utilizing Go interfaces to allow implementations from any cloud to be plugged in. Most of the scaffolding and generic controller implementations will be in core, but it will always exec out to the cloud interfaces it is provided, so long as the [cloud provider interface](https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/cloud.go#L29-L50) is satisfied.
|
||||
Before going into how to build your own cloud controller manager, some background on how it works under the hood is helpful. The cloud controller manager is code from `kube-controller-manager` utilizing Go interfaces to allow implementations from any cloud to be plugged in. Most of the scaffolding and generic controller implementations will be in core, but it will always exec out to the cloud interfaces it is provided, so long as the [cloud provider interface](https://github.com/kubernetes/cloud-provider/blob/master/cloud.go#L42-L62) is satisfied.
|
||||
|
||||
To dive a little deeper into implementation details, all cloud controller managers will import packages from Kubernetes core, the only difference being each project will register their own cloud providers by calling [cloudprovider.RegisterCloudProvider](https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/plugins.go#L42-L52) where a global variable of available cloud providers is updated.
|
||||
To dive a little deeper into implementation details, all cloud controller managers will import packages from Kubernetes core, the only difference being each project will register their own cloud providers by calling [cloudprovider.RegisterCloudProvider](https://github.com/kubernetes/cloud-provider/blob/master/plugins.go#L56-L66) where a global variable of available cloud providers is updated.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -103,10 +103,10 @@ The Corefile configuration includes the following [plugins](https://coredns.io/p
|
||||
* [proxy](https://coredns.io/plugins/proxy/): Any queries that are not within the cluster domain of Kubernetes will be forwarded to predefined resolvers (/etc/resolv.conf).
|
||||
* [cache](https://coredns.io/plugins/cache/): This enables a frontend cache.
|
||||
* [loop](https://coredns.io/plugins/loop/): Detects simple forwarding loops and halts the CoreDNS process if a loop is found.
|
||||
* [reload](https://coredns.io/plugins/reload): Allows automatic reload of a changed Corefile.
|
||||
* [loadbalance](https://coredns.io/plugins/loadbalance): This is a round-robin DNS loadbalancer by randomizing the order of A, AAAA, and MX records in the answer.
|
||||
* [reload](https://coredns.io/plugins/reload): Allows automatic reload of a changed Corefile. After you edit the ConfigMap configuration, allow two minutes for your changes to take effect.
|
||||
* [loadbalance](https://coredns.io/plugins/loadbalance): This is a round-robin DNS loadbalancer that randomizes the order of A, AAAA, and MX records in the answer.
|
||||
|
||||
We can modify the default behavior by modifying this configmap.
|
||||
You can modify the default CoreDNS behavior by modifying the ConfigMap.
|
||||
|
||||
### Configuration of Stub-domain and upstream nameserver using CoreDNS
|
||||
|
||||
@@ -132,7 +132,7 @@ proxy . 172.16.0.1
|
||||
upstream 172.16.0.1
|
||||
```
|
||||
|
||||
So, the final ConfigMap along with the default `Corefile` configuration will look like:
|
||||
The final ConfigMap along with the default `Corefile` configuration looks like:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
@@ -307,9 +307,9 @@ data:
|
||||
|
||||
## CoreDNS configuration equivalent to kube-dns
|
||||
|
||||
CoreDNS supports all the functionalities and more that is provided by kube-dns.
|
||||
CoreDNS supports the features of kube-dns and more.
|
||||
A ConfigMap created for kube-dns to support `StubDomains`and `upstreamNameservers` translates to the `proxy` plugin in CoreDNS.
|
||||
Similarly, the `Federation` plugin translates to the `federation` plugin in CoreDNS.
|
||||
Similarly, the `Federations` plugin in kube-dns translates to the `federation` plugin in CoreDNS.
|
||||
|
||||
### Example
|
||||
|
||||
@@ -356,7 +356,7 @@ The complete Corefile with the default plugins:
|
||||
.:53 {
|
||||
errors
|
||||
health
|
||||
kubernetes cluster.local in-addr.arpa ip6.arpa {
|
||||
kubernetes cluster.local in-addr.arpa ip6.arpa {
|
||||
upstream 8.8.8.8 8.8.4.4
|
||||
pods insecure
|
||||
fallthrough in-addr.arpa ip6.arpa
|
||||
@@ -380,12 +380,10 @@ The complete Corefile with the default plugins:
|
||||
}
|
||||
```
|
||||
|
||||
In Kubernetes version 1.10 and later, kubeadm supports automatic translation of the CoreDNS ConfigMap from the kube-dns ConfigMap.
|
||||
|
||||
## Migration to CoreDNS
|
||||
|
||||
To migrate from kube-dns to CoreDNS, [a detailed blog](https://coredns.io/2018/05/21/migration-from-kube-dns-to-coredns/) is available to help users adapt CoreDNS in place of kube-dns.
|
||||
A cluster administrator can also migrate using [the deploy script](https://github.com/coredns/deployment/blob/master/kubernetes/deploy.sh), which will also help you translate the kube-dns configmap to the equivalent CoreDNS one.
|
||||
A cluster administrator can also migrate using [the deploy script](https://github.com/coredns/deployment/blob/master/kubernetes/deploy.sh).
|
||||
|
||||
## What's next
|
||||
- [Debugging DNS Resolution](/docs/tasks/administer-cluster/dns-debugging-resolution/).
|
||||
@@ -252,7 +252,7 @@ Some Linux distributions (e.g. Ubuntu), use a local DNS resolver by default (sys
|
||||
Systemd-resolved moves and replaces `/etc/resolv.conf` with a stub file that can cause a fatal forwarding
|
||||
loop when resolving names in upstream servers. This can be fixed manually by using kubelet's `--resolv-conf` flag
|
||||
to point to the correct `resolv.conf` (With `systemd-resolved`, this is `/run/systemd/resolve/resolv.conf`).
|
||||
kubeadm 1.11 automatically detects `systemd-resolved`, and adjusts the kubelet flags accordingly.
|
||||
kubeadm (>= 1.11) automatically detects `systemd-resolved`, and adjusts the kubelet flags accordingly.
|
||||
|
||||
Kubernetes installs do not configure the nodes' `resolv.conf` files to use the
|
||||
cluster DNS by default, because that process is inherently distribution-specific.
|
||||
|
||||
@@ -66,9 +66,11 @@ resources from storage each provider that matches the stored data attempts to de
|
||||
order. If no provider can read the stored data due to a mismatch in format or secret key, an error
|
||||
is returned which prevents clients from accessing that resource.
|
||||
|
||||
**IMPORTANT:** If any resource is not readable via the encryption config (because keys were changed),
|
||||
{{< caution >}}
|
||||
If any resource is not readable via the encryption config (because keys were changed),
|
||||
the only recourse is to delete that key from the underlying etcd directly. Calls that attempt to
|
||||
read that resource will fail until it is deleted or a valid decryption key is provided.
|
||||
{{< /caution >}}
|
||||
|
||||
### Providers:
|
||||
|
||||
@@ -113,7 +115,9 @@ To create a new secret perform the following steps:
|
||||
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.
|
||||
{{< caution >}}
|
||||
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.
|
||||
{{< /caution >}}
|
||||
|
||||
|
||||
## Verifying that data is encrypted
|
||||
@@ -142,7 +146,8 @@ program to retrieve the contents of your secret.
|
||||
kubectl describe secret secret1 -n default
|
||||
```
|
||||
|
||||
should match `mykey: mydata`
|
||||
should match `mykey: bXlkYXRh`, mydata is encoded, check [decoding a secret](/docs/concepts/configuration/secret#decoding-a-secret) to
|
||||
completely decode the secret.
|
||||
|
||||
|
||||
## Ensure all secrets are encrypted
|
||||
|
||||
@@ -74,10 +74,12 @@ curl --header "Content-Type: application/json-patch+json" \
|
||||
http://localhost:8001/api/v1/nodes/<your-node-name>/status
|
||||
```
|
||||
|
||||
**Note**: In the preceding request, `~1` is the encoding for the character / in
|
||||
{{< note >}}
|
||||
In the preceding request, `~1` is the encoding for the character / in
|
||||
the patch path. The operation path value in JSON-Patch is interpreted as a
|
||||
JSON-Pointer. For more details, see
|
||||
[IETF RFC 6901](https://tools.ietf.org/html/rfc6901), section 3.
|
||||
{{< /note >}}
|
||||
|
||||
The output shows that the Node has a capacity of 4 dongles:
|
||||
|
||||
@@ -110,7 +112,7 @@ number of dongles. See
|
||||
## Discussion
|
||||
|
||||
Extended resources are similar to memory and CPU resources. For example,
|
||||
just as a Node has a certain amount of memory and CPU to be shared by all components
|
||||
just as a Node has a certain amount of memory and CPU to be shared by all components
|
||||
running on the Node, it can have a certain number of dongles to be shared
|
||||
by all components running on the Node. And just as application developers
|
||||
can create Pods that request a certain amount of memory and CPU, they can
|
||||
|
||||
@@ -4,7 +4,7 @@ content_template: templates/task
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
This page shows how to configure and enable the ip-masq-agent.
|
||||
This page shows how to configure and enable the ip-masq-agent.
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
@@ -23,7 +23,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**
|
||||
@@ -73,14 +73,16 @@ 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/configure-pod-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/configure-pod-configmap/) in a file called "config".
|
||||
**Note:** It is important that the file is called config since, by default, that will be used as the key for lookup by the ip-masq-agent:
|
||||
|
||||
{{< note >}}
|
||||
It is important that the file is called config since, by default, that will be used as the key for lookup by the ip-masq-agent:
|
||||
|
||||
```
|
||||
nonMasqueradeCIDRs:
|
||||
- 10.0.0.0/8
|
||||
resyncInterval: 60s
|
||||
|
||||
```
|
||||
{{< /note >}}
|
||||
|
||||
Run the following command to add the config map to your cluster:
|
||||
|
||||
@@ -88,13 +90,13 @@ Run the following command to add the config map to your cluster:
|
||||
kubectl create configmap ip-masq-agent --from-file=config --namespace=kube-system
|
||||
```
|
||||
|
||||
This will update a file located at */etc/config/ip-masq-agent* which is periodically checked every *resyscInterval* and applied to the cluster node.
|
||||
This will update a file located at */etc/config/ip-masq-agent* which is periodically checked every *resyncInterval* and applied to the cluster node.
|
||||
After the resync interval has expired, you should see the iptables rules reflect your changes:
|
||||
|
||||
```
|
||||
iptables -t nat -L IP-MASQ-AGENT
|
||||
Chain IP-MASQ-AGENT (1 references)
|
||||
target prot opt source destination
|
||||
target prot opt source destination
|
||||
RETURN all -- anywhere 169.254.0.0/16 /* ip-masq-agent: cluster-local traffic should not be subject to MASQUERADE */ ADDRTYPE match dst-type !LOCAL
|
||||
RETURN all -- anywhere 10.0.0.0/8 /* ip-masq-agent: cluster-local
|
||||
MASQUERADE all -- anywhere anywhere /* ip-masq-agent: outbound traffic should be subject to MASQUERADE (this match must come after cluster-local CIDR matches) */ ADDRTYPE match dst-type !LOCAL
|
||||
|
||||
@@ -40,13 +40,13 @@ This page explains how to upgrade a Kubernetes cluster created with `kubeadm` fr
|
||||
{{< tabs name="k8s_install" >}}
|
||||
{{% tab name="Ubuntu, Debian or HypriotOS" %}}
|
||||
apt-get update
|
||||
apt-get upgrade -y kubelet kubeadm
|
||||
apt-get upgrade -y kubeadm
|
||||
{{% /tab %}}
|
||||
{{% tab name="CentOS, RHEL or Fedora" %}}
|
||||
yum upgrade -y kubeadm --disableexcludes=kubernetes
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
|
||||
1. Verify that the download works and has the expected version:
|
||||
|
||||
```shell
|
||||
@@ -227,7 +227,7 @@ This page explains how to upgrade a Kubernetes cluster created with `kubeadm` fr
|
||||
|
||||
1. Upgrade the Kubernetes package version on each `$NODE` node by running the Linux package manager for your distribution:
|
||||
|
||||
{{< tabs name="k8s_install" >}}
|
||||
{{< tabs name="k8s_upgrade" >}}
|
||||
{{% tab name="Ubuntu, Debian or HypriotOS" %}}
|
||||
apt-get update
|
||||
apt-get upgrade -y kubelet kubeadm
|
||||
|
||||
+3
-2
@@ -24,8 +24,7 @@ Before proceeding:
|
||||
- Check the prerequisites for [Upgrading/downgrading kubeadm clusters between v1.11 to v1.12](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-12/).
|
||||
|
||||
{{< note >}}
|
||||
**Note**: All commands on any control plane or etcd node should be
|
||||
run as root.
|
||||
All commands on any control plane or etcd node should be run as root.
|
||||
{{< /note >}}
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -177,6 +176,8 @@ Get a copy of the kubeadm config used to create this cluster. The config should
|
||||
kubectl get configmap -n kube-system kubeadm-config -o jsonpath={.data.MasterConfiguration} > kubeadm-config.yaml
|
||||
```
|
||||
|
||||
Open the file in an editor and set `api.advertiseAddress` to the local node's IP address.
|
||||
|
||||
Now run the upgrade on each control plane node one at a time.
|
||||
|
||||
```
|
||||
+1
-1
@@ -82,7 +82,7 @@ CPU request and limit to the Container.
|
||||
* Verify that the Container specifies a CPU limit that is less than or equal to 800 millicpu.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** When creating a `LimitRange` object, you can specify limits on huge-pages
|
||||
When creating a `LimitRange` object, you can specify limits on huge-pages
|
||||
or GPUs as well. However, when both `default` and `defaultRequest` are specified
|
||||
on these resources, the two values must be the same.
|
||||
{{< /note >}}
|
||||
|
||||
@@ -106,7 +106,9 @@ More information on `finalizers` can be found in the namespace [design doc](http
|
||||
$ kubectl delete namespaces <insert-some-namespace-name>
|
||||
```
|
||||
|
||||
**WARNING, this deletes _everything_ under the namespace!**
|
||||
{{< warning >}}
|
||||
This deletes _everything_ under the namespace!
|
||||
{{< /warning >}}
|
||||
|
||||
This delete is asynchronous, so for a time you will see the namespace in the `Terminating` state.
|
||||
|
||||
|
||||
+26
-20
@@ -1,6 +1,7 @@
|
||||
---
|
||||
reviewers:
|
||||
- danwent
|
||||
- aanm
|
||||
title: Use Cilium for NetworkPolicy
|
||||
content_template: templates/task
|
||||
weight: 20
|
||||
@@ -9,7 +10,7 @@ weight: 20
|
||||
{{% capture overview %}}
|
||||
This page shows how to use Cilium for NetworkPolicy.
|
||||
|
||||
For background on Cilium, read the [Introduction to Cilium](https://cilium.readthedocs.io/en/latest/intro).
|
||||
For background on Cilium, read the [Introduction to Cilium](https://cilium.readthedocs.io/en/stable/intro).
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
@@ -22,21 +23,28 @@ For background on Cilium, read the [Introduction to Cilium](https://cilium.readt
|
||||
## Deploying Cilium on Minikube for Basic Testing
|
||||
|
||||
To get familiar with Cilium easily you can follow the
|
||||
[Cilium Kubernetes Getting Started Guide](https://docs.cilium.io/en/latest/gettingstarted/minikube/)
|
||||
[Cilium Kubernetes Getting Started Guide](https://cilium.readthedocs.io/en/stable/gettingstarted/minikube/)
|
||||
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, to connect
|
||||
to the minikube's etcd instance as well as appropriate RBAC settings:
|
||||
As Cilium requires a standalone etcd instance, for minikube you can deploy it
|
||||
by running:
|
||||
|
||||
```shell
|
||||
$ kubectl create -f https://raw.githubusercontent.com/cilium/cilium/master/examples/kubernetes/cilium.yaml
|
||||
configmap "cilium-config" created
|
||||
secret "cilium-etcd-secrets" created
|
||||
serviceaccount "cilium" created
|
||||
clusterrolebinding "cilium" created
|
||||
daemonset "cilium" created
|
||||
clusterrole "cilium" created
|
||||
kubectl create -n kube-system -f https://raw.githubusercontent.com/cilium/cilium/v1.3/examples/kubernetes/addons/etcd/standalone-etcd.yaml
|
||||
```
|
||||
|
||||
After etcd is up and running you can deploy Cilium Kubernetes descriptor which
|
||||
is a simple ''all-in-one'' YAML file that includes DaemonSet configurations for
|
||||
Cilium, to connect to the etcd instance previously deployed as well as
|
||||
appropriate RBAC settings:
|
||||
|
||||
```shell
|
||||
$ kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.3/examples/kubernetes/1.12/cilium.yaml
|
||||
configmap/cilium-config created
|
||||
daemonset.apps/cilium created
|
||||
clusterrolebinding.rbac.authorization.k8s.io/cilium created
|
||||
clusterrole.rbac.authorization.k8s.io/cilium created
|
||||
serviceaccount/cilium created
|
||||
```
|
||||
|
||||
The remainder of the Getting Started Guide explains how to enforce both L3/L4
|
||||
@@ -65,8 +73,8 @@ 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
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
cilium-6rxbd 1/1 Running 0 1m
|
||||
...
|
||||
```
|
||||
|
||||
@@ -74,12 +82,10 @@ 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 Kubernetes Installation Guide](https://cilium.readthedocs.io/en/latest/kubernetes/install/)
|
||||
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 connects to the minikube's etcd instance.
|
||||
- For production deployments, Cilium should leverage a key-value store
|
||||
(e.g., etcd). The [Cilium Kubernetes Installation Guide](https://cilium.readthedocs.io/en/latest/kubernetes/install/)
|
||||
will provide the necessary steps on how to install this required key-value
|
||||
store as well how to configure it in Cilium.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
+1
-1
@@ -14,7 +14,7 @@ This page shows how to use Romana for NetworkPolicy.
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
Complete steps 1, 2, and 3 of the [kubeadm getting started guide](/docs/getting-started-guides/kubeadm/).
|
||||
Complete steps 1, 2, and 3 of the [kubeadm getting started guide](/docs/getting-started-guides/kubeadm/).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -14,7 +14,7 @@ allows you to change the configuration of each Kubelet in a live Kubernetes
|
||||
cluster by deploying a ConfigMap and configuring each Node to use it.
|
||||
|
||||
{{< warning >}}
|
||||
**Warning:** All Kubelet configuration parameters can be changed dynamically,
|
||||
All Kubelet configuration parameters can be changed dynamically,
|
||||
but this is unsafe for some parameters. Before deciding to change a parameter
|
||||
dynamically, you need a strong understanding of how that change will affect your
|
||||
cluster's behavior. Always carefully test configuration changes on a small set
|
||||
@@ -69,7 +69,7 @@ This document only describes a single Node consuming each ConfigMap. Keep in
|
||||
mind that it is also valid for multiple Nodes to consume the same ConfigMap.
|
||||
|
||||
{{< warning >}}
|
||||
**Warning:** While it is *possible* to change the configuration by
|
||||
While it is *possible* to change the configuration by
|
||||
updating the ConfigMap in-place, this causes all Kubelets configured with
|
||||
that ConfigMap to update simultaneously. It is much safer to treat ConfigMaps
|
||||
as immutable by convention, aided by `kubectl`'s `--append-hash` option,
|
||||
|
||||
@@ -13,7 +13,7 @@ content_template: templates/concept
|
||||
|
||||
Kubernetes v1.6 introduced a new binary called `cloud-controller-manager`. `cloud-controller-manager` is a daemon that embeds cloud-specific control loops. These cloud-specific control loops were originally in the `kube-controller-manager`. Since cloud providers develop and release at a different pace compared to the Kubernetes project, abstracting the provider-specific code to the `cloud-controller-manager` binary allows cloud vendors to evolve independently from the core Kubernetes code.
|
||||
|
||||
The `cloud-controller-manager` can be linked to any cloud provider that satisfies [cloudprovider.Interface](https://git.k8s.io/kubernetes/pkg/cloudprovider/cloud.go). For backwards compatibility, the [cloud-controller-manager](https://github.com/kubernetes/kubernetes/tree/master/cmd/cloud-controller-manager) provided in the core Kubernetes project uses the same cloud libraries as `kube-controller-manager`. Cloud providers already supported in Kubernetes core are expected to use the in-tree cloud-controller-manager to transition out of Kubernetes core. In future Kubernetes releases, all cloud controller managers will be developed outside of the core Kubernetes project managed by sig leads or cloud vendors.
|
||||
The `cloud-controller-manager` can be linked to any cloud provider that satisfies [cloudprovider.Interface](https://github.com/kubernetes/cloud-provider/blob/master/cloud.go). For backwards compatibility, the [cloud-controller-manager](https://github.com/kubernetes/kubernetes/tree/master/cmd/cloud-controller-manager) provided in the core Kubernetes project uses the same cloud libraries as `kube-controller-manager`. Cloud providers already supported in Kubernetes core are expected to use the in-tree cloud-controller-manager to transition out of Kubernetes core. In future Kubernetes releases, all cloud controller managers will be developed outside of the core Kubernetes project managed by sig leads or cloud vendors.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -37,10 +37,12 @@ hardware maintenance, etc.). Safe evictions allow the pod's containers
|
||||
to [gracefully terminate](/docs/concepts/workloads/pods/pod/#termination-of-pods)
|
||||
and will respect the `PodDisruptionBudgets` you have specified.
|
||||
|
||||
**Note:** By default `kubectl drain` will ignore certain system pods on the node
|
||||
{{< note >}}
|
||||
By default `kubectl drain` will ignore certain system pods on the node
|
||||
that cannot be killed; see
|
||||
the [kubectl drain](/docs/reference/generated/kubectl/kubectl-commands/#drain)
|
||||
documentation for more details.
|
||||
{{< /note >}}
|
||||
|
||||
When `kubectl drain` returns successfully, that indicates that all of
|
||||
the pods (except the ones excluded as described in the previous paragraph)
|
||||
|
||||
@@ -165,10 +165,12 @@ credentials from the API servers to their etcd server, such as mutual auth via T
|
||||
and it is often recommended to isolate the etcd servers behind a firewall that only the API servers
|
||||
may access.
|
||||
|
||||
**CAUTION:** Allowing other components within the cluster to access the master etcd instance with
|
||||
{{< caution >}}
|
||||
Allowing other components within the cluster to access the master etcd instance with
|
||||
read or write access to the full keyspace is equivalent to granting cluster-admin access. Using
|
||||
separate etcd instances for non-master components or using etcd ACLs to restrict read and write
|
||||
access to a subset of the keyspace is strongly recommended.
|
||||
{{< /caution >}}
|
||||
|
||||
### Enable audit logging
|
||||
|
||||
|
||||
@@ -100,11 +100,10 @@ Labels from the static pod are propagated into the mirror-pod and can be used as
|
||||
|
||||
Notice we cannot delete the pod with the API server (e.g. via [`kubectl`](/docs/user-guide/kubectl/) command), kubelet simply won't remove it.
|
||||
|
||||
{{<note>}}
|
||||
**Note**: Make sure the kubelet has permission to create the mirror pod in the API server.
|
||||
If not, the creation request is rejected by the API server. See
|
||||
{{< note >}}
|
||||
Make sure the kubelet has permission to create the mirror pod in the API server. If not, the creation request is rejected by the API server. See
|
||||
[PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/).
|
||||
{{</note>}}
|
||||
{{< /note >}}
|
||||
|
||||
```shell
|
||||
[joe@my-master ~] $ kubectl delete pod static-web-my-node1
|
||||
|
||||
@@ -58,7 +58,7 @@ The following sysctls are supported in the _safe_ set:
|
||||
- `net.ipv4.tcp_syncookies`.
|
||||
|
||||
{{< note >}}
|
||||
**Note**: The example `net.ipv4.tcp_syncookies` is not namespaced on Linux kernel version 4.4 or lower.
|
||||
The example `net.ipv4.tcp_syncookies` is not namespaced on Linux kernel version 4.4 or lower.
|
||||
{{< /note >}}
|
||||
|
||||
This list will be extended in future Kubernetes versions when the kubelet
|
||||
@@ -141,7 +141,7 @@ spec:
|
||||
{{% capture discussion %}}
|
||||
|
||||
{{< warning >}}
|
||||
**Warning**: Due to their nature of being _unsafe_, the use of _unsafe_ sysctls
|
||||
Due to their nature of being _unsafe_, the use of _unsafe_ sysctls
|
||||
is at-your-own-risk and can lead to severe problems like wrong behavior of
|
||||
containers, resource shortage or complete breakage of a node.
|
||||
{{< /warning >}}
|
||||
@@ -184,7 +184,7 @@ Do not configure these two fields such that there is overlap, meaning that a
|
||||
given sysctl is both allowed and forbidden.
|
||||
|
||||
{{< warning >}}
|
||||
**Warning**: If you whitelist unsafe sysctls via the `allowedUnsafeSysctls` field
|
||||
If you whitelist unsafe sysctls via the `allowedUnsafeSysctls` field
|
||||
in a PodSecurityPolicy, any pod using such a sysctl will fail to start
|
||||
if the sysctl is not whitelisted via the `--allowed-unsafe-sysctls` kubelet
|
||||
flag as well on that node.
|
||||
|
||||
Reference in New Issue
Block a user