whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge branch 'master' of https://github.com/kubernetes/website into release-1.9

Browse Source 
* 'master' of https://github.com/kubernetes/website: (549 commits)
  Update service.md (#7810)
  Prune inactive maintainers (#7830)
  add Amadeus to index page and add feature image (#7827)
  Update conventions.md (#7668)
  Adding Tenxcloud as KCSP and Hedvig typo (#7826)
  Update outdated documentation about secret key validation. (#7675)
  Update imperative-command.md (#7699)
  Update manage-deployment.md (#7774)
  Add the OCI runtime description. (#7769)
  fix flag (#7814)
  fix flag (#7813)
  Add files via upload (#7816)
  Remove CoreOS guide that use Kubernetes v0.15.0 (#7821)
  "Nagions" should be "Nagios“ (#7762)
  Update docker-cli-to-kubectl.md (#7748)
  adjust a note format (#7812)
  add a note when mount a configmap to pod (#7745)
  Make using sysctls a task instead of a concept (#6808)
  Partners page updates (#7802)
  Fix a missing word in endpoint reconciler section (#7804)
  ...
This commit is contained in:
Andrew Chen
2018-03-26 16:59:03 -07:00
parent ca4f9f8491 770440d20f
commit d97a9cf853
2835 changed files with 20003 additions and 677613 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/tasks/administer-cluster/access-cluster-api.md
+2 -2
View File
@@ -145,10 +145,10 @@ If the application is deployed as a Pod in the cluster, please refer to the [nex
#### Python client
To use [Python client](https://github.com/kubernetes-incubator/client-python), run the following command: `pip install kubernetes` See [Python Client Library page](https://github.com/kubernetes-incubator/client-python) for more installation options.
To use [Python client](https://github.com/kubernetes-client/python), run the following command: `pip install kubernetes` See [Python Client Library page](https://github.com/kubernetes-client/python) for more installation options.
The Python client can use the same [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)
as the kubectl CLI does to locate and authenticate to the API server. See this [example](https://github.com/kubernetes-incubator/client-python/tree/master/examples/example1.py):
as the kubectl CLI does to locate and authenticate to the API server. See this [example](https://github.com/kubernetes-client/python/tree/master/examples/example1.py):
```python
from kubernetes import client, config
docs/tasks/administer-cluster/access-cluster-services.md
+1 -1
View File
@@ -69,7 +69,7 @@ This shows the proxy-verb URL for accessing each service.
For example, this cluster has cluster-level logging enabled (using Elasticsearch), which can be reached
at `https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/` if suitable credentials are passed, or through a kubectl proxy at, for example:
`http://localhost:8080/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`.
(See [above](#accessing-the-cluster-api) for how to pass credentials or use kubectl proxy.)
(See [Access Clusters Using the Kubernetes API](/docs/tasks/administer-cluster/access-cluster-api/#accessing-the-cluster-api) for how to pass credentials or use kubectl proxy.)
#### Manually constructing apiserver proxy URLs
docs/tasks/administer-cluster/calico-network-policy.md
+30 -39
View File
@@ -1,61 +1,52 @@
---
approvers:
reviewers:
- caseydavenport
title: Use Calico for NetworkPolicy
---
{% capture overview %}
This page shows how to use Calico for NetworkPolicy.
This page shows a couple of quick ways to create a Calico cluster on Kubernetes.
{% endcapture %}
{% capture prerequisites %}
* [Install Calico for Kubernetes](https://docs.projectcalico.org/latest/getting-started/kubernetes/installation/).
Decide whether you want to deploy a [cloud](#creating-a-calico-cluster-with-google-kubernetes-engine-gke) or [local](#creating-a-local-calico-cluster-with-kubeadm) cluster.
{% endcapture %}
{% capture steps %}
## Deploying a cluster using Calico
## Creating a Calico cluster with Google Kubernetes Engine (GKE)
You can deploy a cluster using Calico for network policy in the default [GCE deployment](/docs/getting-started-guides/gce/) using the following set of commands:
**Prerequisite**: [gcloud](https://cloud.google.com/sdk/docs/quickstarts).
```shell
export NETWORK_POLICY_PROVIDER=calico
export KUBE_NODE_OS_DISTRIBUTION=debian
curl -sS https://get.k8s.io | bash
```
1. To launch a GKE cluster with Calico, just include the `--enable-network-policy` flag.
**Syntax**
```shell
gcloud container clusters create [CLUSTER_NAME] --enable-network-policy
```
**Example**
```shell
gcloud container clusters create my-calico-cluster --enable-network-policy
```
1. To verify the deployment, use the following command.
```shell
kubectl get pods --namespace=kube-system
```
The Calico pods begin with `calico`. Check to make sure each one has a status of `Running`.
## Creating a local Calico cluster with kubeadm
To get a local single-host Calico cluster in fifteen minutes using kubeadm, refer to the
[Calico Quickstart](https://docs.projectcalico.org/latest/getting-started/kubernetes/).
See the [Calico documentation](http://docs.projectcalico.org/) for more options to deploy Calico with Kubernetes.
{% endcapture %}
{% capture discussion %}
## Understanding Calico components
Deploying a cluster with Calico adds Pods that support Kubernetes NetworkPolicy. These Pods run in 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 READY STATUS RESTARTS AGE
calico-node-kubernetes-minion-group-jck6 1/1 Running 0 46m
calico-node-kubernetes-minion-group-k9jy 1/1 Running 0 46m
calico-node-kubernetes-minion-group-szgr 1/1 Running 0 46m
calico-policy-controller-65rw1 1/1 Running 0 46m
...
```
There are two main components to be aware of:
- One `calico-node` Pod runs on each node in your cluster and enforces network policy on the traffic to/from Pods on that machine by configuring iptables.
- The `calico-policy-controller` Pod reads the policy and label information from the Kubernetes API and configures Calico appropriately.
{% endcapture %}
{% capture whatsnext %}
Once your cluster is running, you can follow the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) to try out Kubernetes NetworkPolicy.
{% endcapture %}
{% include templates/task.md %}
{% include templates/task.md %}
docs/tasks/administer-cluster/cilium-network-policy.md
+1 -1
View File
@@ -1,5 +1,5 @@
---
approvers:
reviewers:
- danwent
title: Use Cilium for NetworkPolicy
---
docs/tasks/administer-cluster/cluster-management.md
+15 -1
View File
@@ -1,5 +1,5 @@
---
approvers:
reviewers:
- lavalamp
- thockin
title: Cluster Management
@@ -23,6 +23,11 @@ The current state of cluster upgrades is provider dependent, and some releases m
* [Upgrading to 1.6](/docs/admin/upgrade-1-6)
### Upgrading an Azure Kubernetes Service (AKS) cluster
Azure Kubernetes Service enables easy self-service upgrades of the control plane and nodes in your cluster. The process is
currently user-initiated and is described in the [Azure AKS documentation](https://docs.microsoft.com/en-us/azure/aks/upgrade-cluster).
### Upgrading Google Compute Engine clusters
Google Compute Engine Open Source (GCE-OSS) support master upgrades by deleting and
@@ -77,6 +82,11 @@ Instance Group will take care of putting appropriate image on new machines and s
In other environments you may need to configure the machine yourself and tell the Kubelet on which machine API server is running.
### Resizing an Azure Kubernetes Service (AKS) cluster
Azure Kubernetes Service enables user-initiated resizing of the cluster from either the CLI or the Azure Portal and is described in the [Azure AKS documentation](https://docs.microsoft.com/en-us/azure/aks/scale-cluster).
### Cluster autoscaling
If you are using GCE or Google Kubernetes Engine, you can configure your cluster so that it is automatically rescaled based on
@@ -124,6 +134,10 @@ gcloud container clusters update mytestcluster --enable-autoscaling --min-nodes=
**Cluster autoscaler expects that nodes have not been manually modified (e.g. by adding labels via kubectl) as those properties would not be propagated to the new nodes within the same instance group.**
For more details about how the cluster autoscaler decides whether, when and how
to scale a cluster, please refer to the [FAQ](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md)
documentation from the autoscaler project.
## Maintenance on a Node
If you need to reboot a node (such as for a kernel upgrade, libc upgrade, hardware repair, etc.), and the downtime is
docs/tasks/administer-cluster/configure-multiple-schedulers.md
+1 -1
View File
@@ -1,5 +1,5 @@
---
approvers:
reviewers:
- davidopp
- madhusudancs
title: Configure Multiple Schedulers
docs/tasks/administer-cluster/configure-upgrade-etcd.md
+5 -5
View File
@@ -1,11 +1,11 @@
---
approvers:
reviewers:
- mml
- wojtek-t
title: Operating etcd clusters for Kubernetes
---
etcd is a strong, consistent, and highly-available key value store which Kubernetes uses for persistent storage of all of its API objects. This documentation provides specific instruction on operating, upgrading, and rolling back etcd clusters for Kubernetes. For in-depth information on etcd, see [etcd documentation](https://github.com/coreos/etcd/blob/master/Documentation/docs.md).
{% glossary_definition term_id="etcd" length="all" prepend="etcd is a "%}
<!-- TODO(mml): Write this doc.
@@ -40,7 +40,7 @@ Use a single-node etcd cluster only for testing purpose.
1. Run the following:
./etcd --client-listen-urls=http://$PRIVATE_IP:2379 --client-advertise-urls=http://$PRIVATE_IP:2379
./etcd --listen-client-urls=http://$PRIVATE_IP:2379 --advertise-client-urls=http://$PRIVATE_IP:2379
2. Start Kubernetes API server with the flag `--etcd-servers=$PRIVATE_IP:2379`.
@@ -56,7 +56,7 @@ For an example, consider a five-member etcd cluster running with the following c
1. Run the following:
./etcd --client-listen-urls=http://$IP1:2379, http://$IP2:2379, http://$IP3:2379, http://$IP4:2379, http://$IP5:2379 --client-advertise-urls=http://$IP1:2379, http://$IP2:2379, http://$IP3:2379, http://$IP4:2379, http://$IP5:2379
./etcd --listen-client-urls=http://$IP1:2379, http://$IP2:2379, http://$IP3:2379, http://$IP4:2379, http://$IP5:2379 --advertise-client-urls=http://$IP1:2379, http://$IP2:2379, http://$IP3:2379, http://$IP4:2379, http://$IP5:2379
2. Start Kubernetes API servers with the flag `--etcd-servers=$IP1:2379, $IP2:2379, $IP3:2379, $IP4:2379, $IP5:2379`.
@@ -374,7 +374,7 @@ STORAGE_MEDIA_TYPE=application/json
### Default configuration
The default setup scripts use kubelet's file-based static pods feature to run etcd in a
[pod](http://releases.k8s.io/{{page.githubbranch}}/cluster/saltbase/salt/etcd/etcd.manifest). This manifest should only
[pod](http://releases.k8s.io/{{page.githubbranch}}/cluster/gce/manifests/etcd.manifest). This manifest should only
be run on master VMs. The default location that kubelet scans for manifests is
`/etc/kubernetes/manifests/`.
docs/tasks/administer-cluster/coredns.md
+1 -1
View File
@@ -1,5 +1,5 @@
---
approvers:
reviewers:
- johnbelamaric
title: Using CoreDNS for Service Discovery
min-kubernetes-server-version: v1.9
docs/tasks/administer-cluster/cpu-management-policies.md
+1 -1
View File
@@ -1,6 +1,6 @@
---
title: Control CPU Management Policies on the Node
approvers:
reviewers:
- sjenning
- ConnorDoyle
- balajismaniam
docs/tasks/administer-cluster/declare-network-policy.md
+1 -1
View File
@@ -1,5 +1,5 @@
---
approvers:
reviewers:
- caseydavenport
- danwinship
title: Declare Network Policy
docs/tasks/administer-cluster/developing-cloud-controller-manager.md
+4 -4
View File
@@ -1,5 +1,5 @@
---
approvers:
reviewers:
- luxas
- thockin
- wlan0
@@ -8,14 +8,14 @@ title: Developing Cloud Controller Manager
**Cloud Controller Manager is an alpha feature in 1.8. In upcoming releases it will
be the preferred way to integrate Kubernetes with any cloud. This will ensure cloud providers
can develop their features independantly from the core Kubernetes release cycles.**
can develop their features independently from the core Kubernetes release cycles.**
* TOC
{:toc}
## Background
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 satisifed.
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.
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.
@@ -26,7 +26,7 @@ To dive a little deeper into implementation details, all cloud controller manage
To build an out-of-tree cloud-controller-manager for your cloud, follow these steps:
1. Create a go package with an implementation that satisfies [cloudprovider.Interface](https://git.k8s.io/kubernetes/pkg/cloudprovider/cloud.go).
2. Use [main.go in cloud-controller-manager](https://github.com/kubernetes/kubernetes/blob/master/cmd/cloud-controller-manager/controller-manager.go) from Kubernestes core as a template for your main.go. As mentioned above, the only difference should be the cloud package that will be imported.
2. Use [main.go in cloud-controller-manager](https://github.com/kubernetes/kubernetes/blob/master/cmd/cloud-controller-manager/controller-manager.go) from Kubernetes core as a template for your main.go. As mentioned above, the only difference should be the cloud package that will be imported.
3. Import your cloud package in `main.go`, ensure your package has an `init` block to run [cloudprovider.RegisterCloudProvider](https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/plugins.go#L42-L52).
Using existing out-of-tree cloud providers as an example may be helpful. You can find the list [here](/docs/tasks/administer-cluster/running-cloud-controller.md#examples).
docs/tasks/administer-cluster/dns-custom-nameservers.md
+4 -178
View File
@@ -1,13 +1,13 @@
---
approvers:
reviewers:
- bowei
- zihongz
title: Configure DNS Service
title: Customizing DNS Service
---
{% capture overview %}
This page provides hints on configuring DNS Pod and guidance on customizing the
DNS resolution process and diagnosing DNS problems.
DNS resolution process.
{% endcapture %}
{% capture prerequisites %}
@@ -183,182 +183,8 @@ data:
["172.16.0.1"]
```
## Debugging DNS resolution
### Create a simple Pod to use as a test environment
Create a file named busybox.yaml with the following contents:
{% include code.html language="yaml" file="busybox.yaml" ghlink="/docs/tasks/administer-cluster/busybox.yaml" %}
Then create a pod using this file and verify its status:
```shell
$ kubectl create -f busybox.yaml
pod "busybox" created
$ kubectl get pods busybox
NAME READY STATUS RESTARTS AGE
busybox 1/1 Running 0 <some-time>
```
Once that pod is running, you can exec `nslookup` in that environment.
If you see something like the following, DNS is working correctly.
```shell
$ kubectl exec -ti busybox -- nslookup kubernetes.default
Server: 10.0.0.10
Address 1: 10.0.0.10
Name: kubernetes.default
Address 1: 10.0.0.1
```
If the `nslookup` command fails, check the following:
### Check the local DNS configuration first
Take a look inside the resolv.conf file.
(See [Inheriting DNS from the node](#inheriting-dns-from-the-node) and
[Known issues](#known-issues) below for more information)
```shell
$ kubectl exec busybox cat /etc/resolv.conf
```
Verify that the search path and name server are set up like the following
(note that search path may vary for different cloud providers):
```
search default.svc.cluster.local svc.cluster.local cluster.local google.internal c.gce_project_id.internal
nameserver 10.0.0.10
options ndots:5
```
Errors such as the following indicate a problem with the kube-dns add-on or
associated Services:
```
$ kubectl exec -ti busybox -- nslookup kubernetes.default
Server: 10.0.0.10
Address 1: 10.0.0.10
nslookup: can't resolve 'kubernetes.default'
```
or
```
$ kubectl exec -ti busybox -- nslookup kubernetes.default
Server: 10.0.0.10
Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local
nslookup: can't resolve 'kubernetes.default'
```
### Check if the DNS pod is running
Use the `kubectl get pods` command to verify that the DNS pod is running.
```shell
$ kubectl get pods --namespace=kube-system -l k8s-app=kube-dns
NAME READY STATUS RESTARTS AGE
...
kube-dns-v19-ezo1y 3/3 Running 0 1h
...
```
If you see that no pod is running or that the pod has failed/completed, the DNS
add-on may not be deployed by default in your current environment and you will
have to deploy it manually.
### Check for Errors in the DNS pod
Use `kubectl logs` command to see logs for the DNS daemons.
```shell
$ kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name) -c kubedns
$ kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name) -c dnsmasq
$ kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name) -c sidecar
```
See if there is any suspicious log. Letter '`W`', '`E`', '`F`' at the beginning
represent Warning, Error and Failure. Please search for entries that have these
as the logging level and use
[kubernetes issues](https://github.com/kubernetes/kubernetes/issues)
to report unexpected errors.
### Is DNS service up?
Verify that the DNS service is up by using the `kubectl get service` command.
```shell
$ kubectl get svc --namespace=kube-system
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
...
kube-dns 10.0.0.10 <none> 53/UDP,53/TCP 1h
...
```
If you have created the service or in the case it should be created by default
but it does not appear, see
[debugging services](/docs/tasks/debug-application-cluster/debug-service/) for
more information.
### Are DNS endpoints exposed?
You can verify that DNS endpoints are exposed by using the `kubectl get endpoints`
command.
```shell
$ kubectl get ep kube-dns --namespace=kube-system
NAME ENDPOINTS AGE
kube-dns 10.180.3.17:53,10.180.3.17:53 1h
```
If you do not see the endpoints, see endpoints section in the
[debugging services](/docs/tasks/debug-application-cluster/debug-service/) documentation.
For additional Kubernetes DNS examples, see the
[cluster-dns examples](https://github.com/kubernetes/examples/tree/master/staging/cluster-dns)
in the Kubernetes GitHub repository.
## Known issues
Kubernetes installs do not configure the nodes' resolv.conf files to use the
cluster DNS by default, because that process is inherently distro-specific.
This should probably be implemented eventually.
Linux's libc is impossibly stuck ([see this bug from
2005](https://bugzilla.redhat.com/show_bug.cgi?id=168253)) with limits of just
3 DNS `nameserver` records and 6 DNS `search` records. Kubernetes needs to
consume 1 `nameserver` record and 3 `search` records. This means that if a
local installation already uses 3 `nameserver`s or uses more than 3 `search`es,
some of those settings will be lost. As a partial workaround, the node can run
`dnsmasq` which will provide more `nameserver` entries, but not more `search`
entries. You can also use kubelet's `--resolv-conf` flag.
If you are using Alpine version 3.3 or earlier as your base image, DNS may not
work properly owing to a known issue with Alpine.
Check [here](https://github.com/kubernetes/kubernetes/issues/30215)
for more information.
## Kubernetes Federation (Multiple Zone support)
Release 1.3 introduced Cluster Federation support for multi-site Kubernetes
installations. This required some minor (backward-compatible) changes to the
way the Kubernetes cluster DNS server processes DNS queries, to facilitate
the lookup of federated services (which span multiple Kubernetes clusters).
See the [Cluster Federation Administrators' Guide](/docs/concepts/cluster-administration/federation/)
for more details on Cluster Federation and multi-site support.
## References
- [DNS for Services and Pods](/docs/concepts/services-networking/dns-pod-service/)
- [Docs for the DNS cluster addon](http://releases.k8s.io/{{page.githubbranch}}/cluster/addons/dns/README.md)
## What's next
- [Autoscaling the DNS Service in a Cluster](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/).
- [Debugging DNS Resolution](/docs/tasks/administer-cluster/dns-debugging-resolution/).
{% endcapture %}
docs/tasks/administer-cluster/dns-debugging-resolution.md
+197
View File
@@ -0,0 +1,197 @@
---
approvers:
- bowei
- zihongz
title: Debugging DNS Resolution
---
{% capture overview %}
This page provides hints on diagnosing DNS problems.
{% endcapture %}
{% capture prerequisites %}
* {% include task-tutorial-prereqs.md %}
* Kubernetes version 1.6 and above.
* The cluster must be configured to use the `kube-dns` addon.
{% endcapture %}
{% capture steps %}
### Create a simple Pod to use as a test environment
Create a file named busybox.yaml with the following contents:
{% include code.html language="yaml" file="busybox.yaml" ghlink="/docs/tasks/administer-cluster/busybox.yaml" %}
Then create a pod using this file and verify its status:
```shell
$ kubectl create -f busybox.yaml
pod "busybox" created
$ kubectl get pods busybox
NAME READY STATUS RESTARTS AGE
busybox 1/1 Running 0 <some-time>
```
Once that pod is running, you can exec `nslookup` in that environment.
If you see something like the following, DNS is working correctly.
```shell
$ kubectl exec -ti busybox -- nslookup kubernetes.default
Server: 10.0.0.10
Address 1: 10.0.0.10
Name: kubernetes.default
Address 1: 10.0.0.1
```
If the `nslookup` command fails, check the following:
### Check the local DNS configuration first
Take a look inside the resolv.conf file.
(See [Inheriting DNS from the node](#inheriting-dns-from-the-node) and
[Known issues](#known-issues) below for more information)
```shell
$ kubectl exec busybox cat /etc/resolv.conf
```
Verify that the search path and name server are set up like the following
(note that search path may vary for different cloud providers):
```
search default.svc.cluster.local svc.cluster.local cluster.local google.internal c.gce_project_id.internal
nameserver 10.0.0.10
options ndots:5
```
Errors such as the following indicate a problem with the kube-dns add-on or
associated Services:
```
$ kubectl exec -ti busybox -- nslookup kubernetes.default
Server: 10.0.0.10
Address 1: 10.0.0.10
nslookup: can't resolve 'kubernetes.default'
```
or
```
$ kubectl exec -ti busybox -- nslookup kubernetes.default
Server: 10.0.0.10
Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local
nslookup: can't resolve 'kubernetes.default'
```
### Check if the DNS pod is running
Use the `kubectl get pods` command to verify that the DNS pod is running.
```shell
$ kubectl get pods --namespace=kube-system -l k8s-app=kube-dns
NAME READY STATUS RESTARTS AGE
...
kube-dns-v19-ezo1y 3/3 Running 0 1h
...
```
If you see that no pod is running or that the pod has failed/completed, the DNS
add-on may not be deployed by default in your current environment and you will
have to deploy it manually.
### Check for Errors in the DNS pod
Use `kubectl logs` command to see logs for the DNS daemons.
```shell
$ kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name) -c kubedns
$ kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name) -c dnsmasq
$ kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name) -c sidecar
```
See if there is any suspicious log. Letter '`W`', '`E`', '`F`' at the beginning
represent Warning, Error and Failure. Please search for entries that have these
as the logging level and use
[kubernetes issues](https://github.com/kubernetes/kubernetes/issues)
to report unexpected errors.
### Is DNS service up?
Verify that the DNS service is up by using the `kubectl get service` command.
```shell
$ kubectl get svc --namespace=kube-system
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
...
kube-dns 10.0.0.10 <none> 53/UDP,53/TCP 1h
...
```
If you have created the service or in the case it should be created by default
but it does not appear, see
[debugging services](/docs/tasks/debug-application-cluster/debug-service/) for
more information.
### Are DNS endpoints exposed?
You can verify that DNS endpoints are exposed by using the `kubectl get endpoints`
command.
```shell
$ kubectl get ep kube-dns --namespace=kube-system
NAME ENDPOINTS AGE
kube-dns 10.180.3.17:53,10.180.3.17:53 1h
```
If you do not see the endpoints, see endpoints section in the
[debugging services](/docs/tasks/debug-application-cluster/debug-service/) documentation.
For additional Kubernetes DNS examples, see the
[cluster-dns examples](https://github.com/kubernetes/examples/tree/master/staging/cluster-dns)
in the Kubernetes GitHub repository.
## Known issues
Kubernetes installs do not configure the nodes' resolv.conf files to use the
cluster DNS by default, because that process is inherently distro-specific.
This should probably be implemented eventually.
Linux's libc is impossibly stuck ([see this bug from
2005](https://bugzilla.redhat.com/show_bug.cgi?id=168253)) with limits of just
3 DNS `nameserver` records and 6 DNS `search` records. Kubernetes needs to
consume 1 `nameserver` record and 3 `search` records. This means that if a
local installation already uses 3 `nameserver`s or uses more than 3 `search`es,
some of those settings will be lost. As a partial workaround, the node can run
`dnsmasq` which will provide more `nameserver` entries, but not more `search`
entries. You can also use kubelet's `--resolv-conf` flag.
If you are using Alpine version 3.3 or earlier as your base image, DNS may not
work properly owing to a known issue with Alpine.
Check [here](https://github.com/kubernetes/kubernetes/issues/30215)
for more information.
## Kubernetes Federation (Multiple Zone support)
Release 1.3 introduced Cluster Federation support for multi-site Kubernetes
installations. This required some minor (backward-compatible) changes to the
way the Kubernetes cluster DNS server processes DNS queries, to facilitate
the lookup of federated services (which span multiple Kubernetes clusters).
See the [Cluster Federation Administrators' Guide](/docs/concepts/cluster-administration/federation/)
for more details on Cluster Federation and multi-site support.
## References
- [DNS for Services and Pods](/docs/concepts/services-networking/dns-pod-service/)
- [Docs for the DNS cluster addon](http://releases.k8s.io/{{page.githubbranch}}/cluster/addons/dns/README.md)
## What's next
- [Autoscaling the DNS Service in a Cluster](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/).
{% endcapture %}
{% include templates/task.md %}
docs/tasks/administer-cluster/dns-horizontal-autoscaler.yaml
+5 -2
View File
@@ -1,4 +1,4 @@
apiVersion: apps/v1beta1
apiVersion: apps/v1
kind: Deployment
metadata:
name: kube-dns-autoscaler
@@ -6,6 +6,9 @@ metadata:
labels:
k8s-app: kube-dns-autoscaler
spec:
selector:
matchLabels:
k8s-app: kube-dns-autoscaler
template:
metadata:
labels:
@@ -13,7 +16,7 @@ spec:
spec:
containers:
- name: autoscaler
image: k8s.gcr.io/cluster-proportional-autoscaler-amd64:1.0.0
image: k8s.gcr.io/cluster-proportional-autoscaler-amd64:1.1.1
resources:
requests:
cpu: "20m"
docs/tasks/administer-cluster/encrypt-data.md
+3 -3
View File
@@ -1,5 +1,5 @@
---
approvers:
reviewers:
- smarterclayton
title: Encrypting Secret Data at Rest
---
@@ -167,7 +167,7 @@ the presence of a highly available deployment where multiple `kube-apiserver` pr
2. Restart all `kube-apiserver` processes to ensure each server can decrypt using the new key
3. Make the new key the first entry in the `keys` array so that it is used for encryption in the config
4. Restart all `kube-apiserver` processes to ensure each server now encrypts using the new key
5. Run `kubectl get secrets -o json | kubectl replace -f -` to encrypt all existing secrets with the new key
5. Run `kubectl get secrets --all-namespaces -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.
@@ -191,7 +191,7 @@ resources:
secret: <BASE 64 ENCODED SECRET>
```
and restart all `kube-apiserver` processes. Then run the command `kubectl get secrets -o json | kubectl replace -f -`
and restart all `kube-apiserver` processes. Then run the command `kubectl get secrets --all-namespaces -o json | kubectl replace -f -`
to force all secrets to be decrypted.
{% endcapture %}
docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods.md
+19 -11
View File
@@ -1,5 +1,5 @@
---
approvers:
reviewers:
- davidopp
- filipg
- piosz
@@ -19,6 +19,12 @@ and becomes pending (for example when the cluster is highly utilized and either
vacated by the evicted critical add-on pod or the amount of resources available on the node changed for some other reason).
## Rescheduler: guaranteed scheduling of critical add-ons
**Rescheduler is deprecated as of Kubernetes 1.10 and will be removed in version 1.11 in
accordance with the [deprecation policy](/docs/reference/deprecation-policy) for beta features.**
**To avoid eviction of critical pods, you must
[enable priorities in scheduler](/docs/concepts/configuration/pod-priority-preemption/)
before upgrading to Kubernetes 1.10 or higher.**
Rescheduler ensures that critical add-ons are always scheduled
(assuming the cluster has enough resources to run the critical add-on pods in the absence of regular pods).
@@ -35,22 +41,24 @@ while the other pods shouldn't tolerate the taint. The taint is removed once the
*Warning:* currently there is no guarantee which node is chosen and which pods are being killed
in order to schedule critical pods, so if rescheduler is enabled your pods might be occasionally
killed for this purpose.
killed for this purpose. Please ensure that rescheduler is not enabled along with priorities & preemptions in default-scheduler as rescheduler is oblivious to priorities and it may evict high priority pods, instead of low priority ones.
## Config
Rescheduler should be [enabled by default as a static pod](https://git.k8s.io/kubernetes/cluster/saltbase/salt/rescheduler/rescheduler.manifest).
It doesn't have any user facing configuration (component config) or API and can be disabled:
Rescheduler doesn't have any user facing configuration (component config) or API.
* during cluster setup by setting `ENABLE_RESCHEDULER` flag to `false`
* on running cluster by deleting its manifest from master node
(default path `/etc/kubernetes/manifests/rescheduler.manifest`)
### Marking pod as critical when using Rescheduler.
** Marking pod as critical when using Rescheduler.
### Marking add-on as critical
To be critical an add-on has to run in `kube-system` namespace (configurable via flag) and
To be considered critical, the pod has to run in the `kube-system` namespace (configurable via flag) and
* have the `scheduler.alpha.kubernetes.io/critical-pod` annotation set to empty string, and
* have the PodSpec's `tolerations` field set to `[{"key":"CriticalAddonsOnly", "operator":"Exists"}]`
* have the PodSpec's `tolerations` field set to `[{"key":"CriticalAddonsOnly", "operator":"Exists"}]`.
The first one marks a pod a critical. The second one is required by Rescheduler algorithm.
### Marking pod as critical when priorites are enabled.
To be considered critical, the pod has to run in the `kube-system` namespace (configurable via flag) and
* Have the priorityClass set as "system-cluster-critical" or "system-node-critical", the latter being the highest for entire cluster and `scheduler.alpha.kubernetes.io/critical-pod` annotation set to empty string(This will be deprecated too).
docs/tasks/administer-cluster/highly-available-master.md
+1 -1
View File
@@ -1,5 +1,5 @@
---
approvers:
reviewers:
- jszczepkowski
title: Set up High-Availability Kubernetes Masters
---
docs/tasks/administer-cluster/kube-router-network-policy.md
+1 -1
View File
@@ -1,5 +1,5 @@
---
approvers:
reviewers:
- murali-reddy
title: Use Kube-router for NetworkPolicy
---
docs/tasks/administer-cluster/kubeadm-upgrade-1-7.md
+1 -1
View File
@@ -1,5 +1,5 @@
---
approvers:
reviewers:
- pipejakob
title: Upgrading kubeadm clusters from 1.6 to 1.7
---
docs/tasks/administer-cluster/kubeadm-upgrade-1-8.md
+29 -19
View File
@@ -1,5 +1,5 @@
---
approvers:
reviewers:
- pipejakob
- luxas
- roberthbailey
@@ -36,10 +36,10 @@ You have to carry out the following steps by executing these commands on your ma
1. Install the most recent version of `kubeadm` using `curl` like so:
```shell
$ export VERSION=$(curl -sSL https://dl.k8s.io/release/stable.txt) # or manually specify a released Kubernetes version
$ export ARCH=amd64 # or: arm, arm64, ppc64le, s390x
$ curl -sSL https://dl.k8s.io/release/${VERSION}/bin/linux/${ARCH}/kubeadm > /usr/bin/kubeadm
$ chmod a+rx /usr/bin/kubeadm
export VERSION=$(curl -sSL https://dl.k8s.io/release/stable.txt) # or manually specify a released Kubernetes version
export ARCH=amd64 # or: arm, arm64, ppc64le, s390x
curl -sSL https://dl.k8s.io/release/${VERSION}/bin/linux/${ARCH}/kubeadm > /usr/bin/kubeadm
chmod a+rx /usr/bin/kubeadm
```
**Caution:** Upgrading the `kubeadm` package on your system prior to
upgrading the control plane causes a failed upgrade. Even though
@@ -51,7 +51,7 @@ this limitation.
Verify that this download of kubeadm works, and has the expected version:
```shell
$ kubeadm version
kubeadm version
```
2. If this the first time you use `kubeadm upgrade`, in order to preserve the configuration for future upgrades, do:
@@ -61,7 +61,7 @@ Note that for below you will need to recall what CLI args you passed to `kubeadm
If you used flags, do:
```shell
$ kubeadm config upload from-flags [flags]
kubeadm config upload from-flags [flags]
```
Where `flags` can be empty.
@@ -69,7 +69,7 @@ Where `flags` can be empty.
If you used a config file, do:
```shell
$ kubeadm config upload from-file --config [config]
kubeadm config upload from-file --config [config]
```
Where the `config` is mandatory.
@@ -77,7 +77,12 @@ Where the `config` is mandatory.
3. On the master node, run the following:
```shell
$ kubeadm upgrade plan
kubeadm upgrade plan
```
You should see output similar to this:
```shell
[preflight] Running pre-flight checks
[upgrade] Making sure the cluster is healthy:
[upgrade/health] Checking API Server health: Healthy
@@ -115,7 +120,7 @@ Components that must be upgraded manually after you've upgraded the control plan
COMPONENT CURRENT AVAILABLE
Kubelet 1 x v1.7.1 v1.8.0
Upgrade to the latest experimental version:
Upgrade to the latest stable version:
COMPONENT CURRENT AVAILABLE
API Server v1.7.1 v1.8.0
@@ -138,7 +143,12 @@ The `kubeadm upgrade plan` checks that your cluster is in an upgradeable state a
4. Pick a version to upgrade to and run, for example, `kubeadm upgrade apply` as follows:
```shell
$ kubeadm upgrade apply v1.8.0
kubeadm upgrade apply v1.8.0
```
You should see output similar to this:
```shell
[preflight] Running pre-flight checks
[upgrade] Making sure the cluster is healthy:
[upgrade/health] Checking API Server health: Healthy
@@ -211,7 +221,7 @@ $ kubeadm upgrade apply v1.8.0
6. Add RBAC permissions for automated certificate rotation. In the future, kubeadm will perform this step automatically:
```shell
$ kubectl create clusterrolebinding kubeadm:node-autoapprove-certificate-rotation --clusterrole=system:certificates.k8s.io:certificatesigningrequests:selfnodeclient --group=system:nodes
kubectl create clusterrolebinding kubeadm:node-autoapprove-certificate-rotation --clusterrole=system:certificates.k8s.io:certificatesigningrequests:selfnodeclient --group=system:nodes
```
## Upgrading your master and node packages
@@ -221,7 +231,7 @@ For each host (referred to as `$HOST` below) in your cluster, upgrade `kubelet`
1. Prepare the host for maintenance, marking it unschedulable and evicting the workload:
```shell
$ kubectl drain $HOST --ignore-daemonsets
kubectl drain $HOST --ignore-daemonsets
```
When running this command against the master host, this error is expected and can be safely ignored (since there are static pods running on the master):
@@ -236,32 +246,32 @@ error: pods not managed by ReplicationController, ReplicaSet, Job, DaemonSet or
If the host is running a Debian-based distro such as Ubuntu, run:
```shell
$ apt-get update
$ apt-get upgrade
apt-get update
apt-get upgrade
```
If the host is running CentOS or the like, run:
```shell
$ yum update
yum update
```
Now the new version of the `kubelet` should be running on the host. Verify this using the following command on `$HOST`:
```shell
$ systemctl status kubelet
systemctl status kubelet
```
3. Bring the host back online by marking it schedulable:
```shell
$ kubectl uncordon $HOST
kubectl uncordon $HOST
```
4. After upgrading `kubelet` on each host in your cluster, verify that all nodes are available again by executing the following (from anywhere, for example, from outside the cluster):
```shell
$ kubectl get nodes
kubectl get nodes
```
If the `STATUS` column of the above command shows `Ready` for all of your hosts, you are done.
docs/tasks/administer-cluster/kubeadm-upgrade-1-9.md
+30 -16
View File
@@ -1,5 +1,5 @@
---
approvers:
reviewers:
- pipejakob
- luxas
- roberthbailey
@@ -23,6 +23,9 @@ Before proceeding:
- `kubeadm upgrade` now allows you to upgrade etcd. `kubeadm upgrade` will also upgrade of etcd to 3.1.10 as part of upgrading from v1.8 to v1.9 by default. This is due to the fact that etcd 3.1.10 is the officially validated etcd version for Kubernetes v1.9. The upgrade is handled automatically by kubeadm for you.
- Note that `kubeadm upgrade` will not touch any of your workloads, only Kubernetes-internal components. As a best-practice you should back up what's important to you. For example, any app-level state, such as a database an app might depend on (like MySQL or MongoDB) must be backed up beforehand.
**Caution:** All the containers will get restarted after the upgrade, due to container spec hash value gets changed.
{: .caution}
Also, note that only one minor version upgrade is supported. For example, you can only upgrade from 1.8 to 1.9, not from 1.7 to 1.9.
{% endcapture %}
@@ -36,10 +39,10 @@ Execute these commands on your master node:
1. Install the most recent version of `kubeadm` using `curl` like so:
```shell
$ export VERSION=$(curl -sSL https://dl.k8s.io/release/stable.txt) # or manually specify a released Kubernetes version
$ export ARCH=amd64 # or: arm, arm64, ppc64le, s390x
$ curl -sSL https://dl.k8s.io/release/${VERSION}/bin/linux/${ARCH}/kubeadm > /usr/bin/kubeadm
$ chmod a+rx /usr/bin/kubeadm
export VERSION=$(curl -sSL https://dl.k8s.io/release/stable.txt) # or manually specify a released Kubernetes version
export ARCH=amd64 # or: arm, arm64, ppc64le, s390x
curl -sSL https://dl.k8s.io/release/${VERSION}/bin/linux/${ARCH}/kubeadm > /usr/bin/kubeadm
chmod a+rx /usr/bin/kubeadm
```
**Caution:** Upgrading the `kubeadm` package on your system prior to upgrading the control plane causes a failed upgrade.
@@ -50,13 +53,18 @@ team is working on fixing this limitation.
Verify that this download of kubeadm works and has the expected version:
```shell
$ kubeadm version
kubeadm version
```
2. On the master node, run the following:
```shell
$ kubeadm upgrade plan
kubeadm upgrade plan
```
You should see output similar to this:
```shell
[preflight] Running pre-flight checks
[upgrade] Making sure the cluster is healthy:
[upgrade/health] Checking API Server health: Healthy
@@ -94,7 +102,7 @@ Components that must be upgraded manually after you've upgraded the control plan
COMPONENT CURRENT AVAILABLE
Kubelet 1 x v1.8.1 v1.9.0
Upgrade to the latest experimental version:
Upgrade to the latest stable version:
COMPONENT CURRENT AVAILABLE
API Server v1.8.1 v1.9.0
@@ -119,7 +127,12 @@ To check CoreDNS version, include the `--feature-gates=CoreDNS=true` flag to ver
3. Pick a version to upgrade to and run. For example:
```shell
$ kubeadm upgrade apply v1.9.0
kubeadm upgrade apply v1.9.0
```
You should see output similar to this:
```shell
[preflight] Running pre-flight checks.
[upgrade] Making sure the cluster is healthy:
[upgrade/config] Making sure the configuration is correct:
@@ -175,6 +188,7 @@ To upgrade the cluster with CoreDNS as the default internal DNS, invoke `kubeadm
- Makes sure the control plane images are available or available to pull to the machine.
- Upgrades the control plane components or rollbacks if any of them fails to come up.
- Applies the new `kube-dns` and `kube-proxy` manifests and enforces that all necessary RBAC rules are created.
- Creates new certificate and key files of apiserver and backs up old files if they're about to expire in 180 days.
4. Manually upgrade your Software Defined Network (SDN).
@@ -190,7 +204,7 @@ For each host (referred to as `$HOST` below) in your cluster, upgrade `kubelet`
1. Prepare the host for maintenance, marking it unschedulable and evicting the workload:
```shell
$ kubectl drain $HOST --ignore-daemonsets
kubectl drain $HOST --ignore-daemonsets
```
When running this command against the master host, this error is expected and can be safely ignored (since there are static pods running on the master):
@@ -205,32 +219,32 @@ error: pods not managed by ReplicationController, ReplicaSet, Job, DaemonSet or
If the host is running a Debian-based distro such as Ubuntu, run:
```shell
$ apt-get update
$ apt-get upgrade
apt-get update
apt-get upgrade
```
If the host is running CentOS or the like, run:
```shell
$ yum update
yum update
```
Now the new version of the `kubelet` should be running on the host. Verify this using the following command on `$HOST`:
```shell
$ systemctl status kubelet
systemctl status kubelet
```
3. Bring the host back online by marking it schedulable:
```shell
$ kubectl uncordon $HOST
kubectl uncordon $HOST
```
4. After upgrading `kubelet` on each host in your cluster, verify that all nodes are available again by executing the following (from anywhere, for example, from outside the cluster):
```shell
$ kubectl get nodes
kubectl get nodes
```
If the `STATUS` column of the above command shows `Ready` for all of your hosts, you are done.
docs/tasks/administer-cluster/kubeadm-upgrade-ha.md
+133
View File
@@ -0,0 +1,133 @@
---
reviewers:
- jamiehannaford
- luxas
- timothysc
- jbeda
title: Upgrading kubeadm HA clusters from 1.9.x to 1.9.y
---
{% capture overview %}
This guide is for upgrading `kubeadm` HA clusters from version 1.9.x to 1.9.y where `y > x`. The term "`kubeadm` HA clusters" refers to clusters of more than one master node created with `kubeadm`. To set up an HA cluster for Kubernetes version 1.9.x `kubeadm` requires additional manual steps. See [Creating HA clusters with kubeadm](/docs/setup/independent/high-availability/) for instructions on how to do this. The upgrade procedure described here targets clusters created following those very instructions. See [Upgrading/downgrading kubeadm clusters between v1.8 to v1.9](/docs/tasks/administer-cluster/kubeadm-upgrade-1-9/) for more instructions on how to create an HA cluster with `kubeadm`.
{% endcapture %}
{% capture prerequisites %}
Before proceeding:
- You need to have a functional `kubeadm` HA cluster running version 1.9.0 or higher in order to use the process described here.
- Make sure you read the [release notes](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.9.md) carefully.
- Note that `kubeadm upgrade` will not touch any of your workloads, only Kubernetes-internal components. As a best-practice you should back up anything important to you. For example, any application-level state, such as a database and application might depend on (like MySQL or MongoDB) should be backed up beforehand.
- Read [Upgrading/downgrading kubeadm clusters between v1.8 to v1.9](/docs/tasks/administer-cluster/kubeadm-upgrade-1-9/) to learn about the relevant prerequisites.
{% endcapture %}
{% capture steps %}
## Preparation
Some preparation is needed prior to starting the upgrade. First download the version of `kubeadm` that matches the version of Kubernetes that you are upgrading to:
```shell
# Use the latest stable release or manually specify a
# released Kubernetes version
export VERSION=$(curl -sSL https://dl.k8s.io/release/stable.txt)
export ARCH=amd64 # or: arm, arm64, ppc64le, s390x
curl -sSL https://dl.k8s.io/release/${VERSION}/bin/linux/${ARCH}/kubeadm > /tmp/kubeadm
chmod a+rx /tmp/kubeadm
```
Copy this file to `/tmp` on your primary master if necessary. Run this command for checking prerequisites and determining the versions you will receive:
```shell
/tmp/kubeadm upgrade plan
```
If the prerequisites are met you'll get a summary of the software versions kubeadm will upgrade to, like this:
Upgrade to the latest stable version:
COMPONENT CURRENT AVAILABLE
API Server v1.9.0 v1.9.2
Controller Manager v1.9.0 v1.9.2
Scheduler v1.9.0 v1.9.2
Kube Proxy v1.9.0 v1.9.2
Kube DNS 1.14.5 1.14.7
Etcd 3.2.7 3.1.11
**Caution:** Currently the only supported configuration for kubeadm HA clusters requires the use of an externally managed etcd cluster. Upgrading etcd is not supported as a part of the upgrade. If necessary you will have to upgrade the etcd cluster according to [etcd's upgrade instructions](/docs/tasks/administer-cluster/configure-upgrade-etcd/), which is beyond the scope of these instructions.
{: .caution}
## Upgrading your control plane
The following procedure must be applied on a single master node and repeated for each subsequent master node sequentially.
Before initiating the upgrade with `kubeadm` `configmap/kubeadm-config` needs to be modified for the current master host. Replace any hard reference to a master host name with the current master hosts' name:
```shell
kubectl get configmap -n kube-system kubeadm-config -o yaml >/tmp/kubeadm-config-cm.yaml
sed -i 's/^\([ \t]*nodeName:\).*/\1 <CURRENT-MASTER-NAME>/' /tmp/kubeadm-config-cm.yaml
kubectl apply -f /tmp/kubeadm-config-cm.yaml --force
```
Now the upgrade process can start. Use the target version determined in the preparation step and run the following command (press “y” when prompted):
```shell
/tmp/kubeadm upgrade apply v<YOUR-CHOSEN-VERSION-HERE>
```
If the operation was successful you’ll get a message like this:
[upgrade/successful] SUCCESS! Your cluster was upgraded to "v1.9.2". Enjoy!
To upgrade the cluster with CoreDNS as the default internal DNS, invoke `kubeadm upgrade apply` with the `--feature-gates=CoreDNS=true` flag.
Next, manually upgrade your CNI provider
Your Container Network Interface (CNI) provider may have its own upgrade instructions to follow. Check the [addons](/docs/concepts/cluster-administration/addons/) page to find your CNI provider and see if there are additional upgrade steps necessary.
**Note:** The `kubeadm upgrade apply` step has been known to fail when run initially on the secondary masters (timed out waiting for the restarted static pods to come up). It should succeed if retried after a minute or two.
{: .note}
## Upgrade base software packages
At this point all the static pod manifests in your cluster, for example API Server, Controller Manager, Scheduler, Kube Proxy have been upgraded, however the base software, for example `kubelet`, `kubectl`, `kubeadm` installed on your nodes’ OS are still of the old version. For upgrading the base software packages we will upgrade them and restart services on all nodes one by one:
```shell
# use your distro's package manager, e.g. 'yum' on RH-based systems
# for the versions stick to kubeadm's output (see above)
yum install -y kubelet-<NEW-K8S-VERSION> kubectl-<NEW-K8S-VERSION> kubeadm-<NEW-K8S-VERSION> kubernetes-cni-<NEW-CNI-VERSION>
systemctl restart kubelet
```
In this example an _rpm_-based system is assumed and `yum` is used for installing the upgraded software. On _deb_-based systems it will be `apt-get update` and then `apt-get install <PACKAGE>=<NEW-K8S-VERSION>` for all packages.
Now the new version of the `kubelet` should be running on the host. Verify this using the following command on the respective host:
```shell
systemctl status kubelet
```
Verify that the upgraded node is available again by executing the following from wherever you run `kubectl` commands:
```shell
kubectl get nodes
```
If the `STATUS` column of the above command shows `Ready` for the upgraded host, you can continue (you may have to repeat this for a couple of time before the node gets `Ready`).
## If something goes wrong
If the upgrade fails the situation afterwards depends on the phase in which things went wrong:
1. If `/tmp/kubeadm upgrade apply` failed to upgrade the cluster it will try to perform a rollback. Hence if that happened on the first master, chances are pretty good that the cluster is still intact.
You can run `/tmp/kubeadm upgrade apply` again as it is idempotent and should eventually make sure the actual state is the desired state you are declaring. You can use `/tmp/kubeadm upgrade apply` to change a running cluster with `x.x.x --> x.x.x` with `--force`, which can be used to recover from a bad state.
2. If `/tmp/kubeadm upgrade apply` on one of the secondary masters failed you still have a working, upgraded cluster, but with the secondary masters in a somewhat undefined condition. You will have to find out what went wrong and join the secondaries manually. As mentioned above, sometimes upgrading one of the secondary masters fails waiting for the restarted static pods first, but succeeds when the operation is simply repeated after a little pause of one or two minutes.
{% endcapture %}
{% include templates/task.md %}
docs/tasks/administer-cluster/kubelet-config-file.md
+3 -3
View File
@@ -1,5 +1,5 @@
---
approvers:
reviewers:
- mtaufen
- dawnchen
title: Set Kubelet parameters via a config file
@@ -27,10 +27,10 @@ providing parameters via a config file, which simplifies node deployment.
The subset of the Kubelet's configuration that can be configured via a file
is defined by the `KubeletConfiguration` struct
[here (v1alpha1)](https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/apis/kubeletconfig/v1alpha1/types.go).
[here (v1alpha1)](https://github.com/kubernetes/kubernetes/blob/release-1.9/pkg/kubelet/apis/kubeletconfig/v1alpha1/types.go).
The configuration file must be a JSON or YAML representation of the parameters
in this struct. Note that this structure, and thus the config file API,
is still considered alpha and is not subject to stability gurarantees.
is still considered alpha and is not subject to stability guarantees.
Create a file named `kubelet` in its own directory and make sure the directory
and file are both readable by the Kubelet. You should write your intended
docs/tasks/administer-cluster/memory-available.sh
+2 -2
View File
@@ -10,7 +10,7 @@ memory_capacity_in_bytes=$((memory_capacity_in_kb * 1024))
memory_usage_in_bytes=$(cat /sys/fs/cgroup/memory/memory.usage_in_bytes)
memory_total_inactive_file=$(cat /sys/fs/cgroup/memory/memory.stat | grep total_inactive_file | awk '{print $2}')
memory_working_set=$memory_usage_in_bytes
memory_working_set=${memory_usage_in_bytes}
if [ "$memory_working_set" -lt "$memory_total_inactive_file" ];
then
memory_working_set=0
@@ -28,4 +28,4 @@ echo "memory.total_inactive_file $memory_total_inactive_file"
echo "memory.working_set $memory_working_set"
echo "memory.available_in_bytes $memory_available_in_bytes"
echo "memory.available_in_kb $memory_available_in_kb"
echo "memory.available_in_mb $memory_available_in_mb"
echo "memory.available_in_mb $memory_available_in_mb"
docs/tasks/administer-cluster/my-scheduler.yaml
+5 -1
View File
@@ -1,4 +1,4 @@
apiVersion: apps/v1beta1
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
@@ -7,6 +7,10 @@ metadata:
name: my-scheduler
namespace: kube-system
spec:
selector:
matchLabels:
component: scheduler
tier: control-plane
replicas: 1
template:
metadata:
docs/tasks/administer-cluster/namespaces-walkthrough.md
+58 -9
View File
@@ -1,5 +1,5 @@
---
approvers:
reviewers:
- derekwaynecarr
- janetkuo
title: Namespaces Walkthrough
@@ -28,7 +28,7 @@ This example assumes the following:
By default, a Kubernetes cluster will instantiate a default namespace when provisioning the cluster to hold the default set of Pods,
Services, and Deployments used by the cluster.
Assuming you have a fresh cluster, you can introspect the available namespace's by doing the following:
Assuming you have a fresh cluster, you can inspect the available namespaces by doing the following:
```shell
$ kubectl get namespaces
@@ -53,20 +53,24 @@ One pattern this organization could follow is to partition the Kubernetes cluste
Let's create two new namespaces to hold our work.
Use the file [`namespace-dev.json`](/docs/admin/namespaces/namespace-dev.json) which describes a development namespace:
Use the file [`namespace-dev.json`](/docs/tasks/administer-cluster/namespace-dev.json) which describes a development namespace:
{% include code.html language="json" file="namespace-dev.json" ghlink="/docs/tasks/administer-cluster/namespace-dev.json" %}
Create the development namespace using kubectl.
```shell
$ kubectl create -f docs/admin/namespaces/namespace-dev.json
$ kubectl create -f https://k8s.io/docs/tasks/administer-cluster/namespace-dev.json
```
Save the following contents into file [`namespace-prod.json`](/docs/tasks/administer-cluster/namespace-prod.json) which describes a production namespace:
{% include code.html language="json" file="namespace-prod.json" ghlink="/docs/tasks/administer-cluster/namespace-prod.json" %}
And then let's create the production namespace using kubectl.
```shell
$ kubectl create -f docs/tasks/administer-cluster/namespace-prod.json
$ kubectl create -f https://k8s.io/docs/tasks/administer-cluster/namespace-prod.json
```
To be sure things are right, let's list all of the namespaces in our cluster.
@@ -123,12 +127,57 @@ 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.
```shell
$ kubectl config set-context dev --namespace=development --cluster=lithe-cocoa-92103_kubernetes --user=lithe-cocoa-92103_kubernetes
$ kubectl config set-context prod --namespace=production --cluster=lithe-cocoa-92103_kubernetes --user=lithe-cocoa-92103_kubernetes
$ kubectl config set-context dev --namespace=development \
--cluster=lithe-cocoa-92103_kubernetes \
--user=lithe-cocoa-92103_kubernetes
$ kubectl config set-context prod --namespace=production \
--cluster=lithe-cocoa-92103_kubernetes \
--user=lithe-cocoa-92103_kubernetes
```
The above commands provided two request contexts you can alternate against depending on what namespace you
wish to work against.
By default, the above commands adds two contexts that are saved into file
`.kube/config`. You can now view the contexts and alternate against the two
new request contexts depending on which namespace you wish to work against.
To view the new contexts:
```shell
$ kubectl config view
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: REDACTED
server: https://130.211.122.180
name: lithe-cocoa-92103_kubernetes
contexts:
- context:
cluster: lithe-cocoa-92103_kubernetes
user: lithe-cocoa-92103_kubernetes
name: lithe-cocoa-92103_kubernetes
- context:
cluster: lithe-cocoa-92103_kubernetes
namespace: development
user: lithe-cocoa-92103_kubernetes
name: dev
- context:
cluster: lithe-cocoa-92103_kubernetes
namespace: production
user: lithe-cocoa-92103_kubernetes
name: prod
current-context: lithe-cocoa-92103_kubernetes
kind: Config
preferences: {}
users:
- name: lithe-cocoa-92103_kubernetes
user:
client-certificate-data: REDACTED
client-key-data: REDACTED
token: 65rZW78y8HbwXXtSXuUw9DbP4FLjHi4b
- name: lithe-cocoa-92103_kubernetes-basic-auth
user:
password: h5M0FtUUIflBSdI7
username: admin
```
Let's switch to operate in the development namespace.
docs/tasks/administer-cluster/namespaces.md
+4 -4
View File
@@ -1,5 +1,5 @@
---
approvers:
reviewers:
- derekwaynecarr
- janetkuo
title: Share a Cluster with Namespaces
@@ -139,14 +139,14 @@ One pattern this organization could follow is to partition the Kubernetes cluste
Let's create two new namespaces to hold our work.
Use the file [`namespace-dev.json`](/docs/admin/namespaces/namespace-dev.json) which describes a development namespace:
Use the file [`namespace-dev.json`](/docs/tasks/administer-cluster/namespace-dev.json) which describes a development namespace:
{% include code.html language="json" file="namespace-dev.json" ghlink="/docs/admin/namespaces/namespace-dev.json" %}
{% include code.html language="json" file="namespace-dev.json" ghlink="/docs/tasks/administer-cluster/namespace-dev.json" %}
Create the development namespace using kubectl.
```shell
$ kubectl create -f docs/admin/namespaces/namespace-dev.json
$ kubectl create -f docs/tasks/administer-cluster/namespace-dev.json
```
And then let's create the production namespace using kubectl.
docs/tasks/administer-cluster/out-of-resource.md
+18 -21
View File
@@ -1,5 +1,5 @@
---
approvers:
reviewers:
- derekwaynecarr
- vishh
- timstclair
@@ -80,7 +80,7 @@ where:
* `eviction-signal` is an eviction signal token as defined in the previous table.
* `operator` is the desired relational operator, such as `<` (less than).
* `quantity` is the eviction threshhold quantity, such as `1Gi`. These tokens must
* `quantity` is the eviction threshold quantity, such as `1Gi`. These tokens must
match the quantity representation used by Kubernetes. An eviction threshold can also
be expressed as a percentage using the `%` token.
@@ -147,7 +147,7 @@ The following node conditions are defined that correspond to the specified evict
| Node Condition | Eviction Signal | Description |
|-------------------------|-------------------------------|--------------------------------------------|
| `MemoryPressure` | `memory.available` | Available memory on the node has satisfied an eviction threshold |
| `DiskPressure` | `nodefs.available`, `nodefs.inodesFree`, `imagefs.available`, or `imagefs.inodesFree` | Available disk space and inodes on either the node's root filesytem or image filesystem has satisfied an eviction threshold |
| `DiskPressure` | `nodefs.available`, `nodefs.inodesFree`, `imagefs.available`, or `imagefs.inodesFree` | Available disk space and inodes on either the node's root filesystem or image filesystem has satisfied an eviction threshold |
The `kubelet` continues to report node status updates at the frequency specified by
`--node-status-update-frequency` which defaults to `10s`.
@@ -196,25 +196,22 @@ If `nodefs` filesystem has met eviction thresholds, `kubelet` frees up disk spac
If the `kubelet` is unable to reclaim sufficient resource on the node, `kubelet` begins evicting Pods.
The `kubelet` ranks Pods for eviction first by their quality of service, and then by the consumption
of the starved compute resource relative to the Pods' scheduling requests.
The `kubelet` ranks Pods for eviction first by whether or not their usage of the starved resource exceeds requests,
then by [Priority](https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/), and then by the consumption of the starved compute resource relative to the Pods' scheduling requests.
As a result, `kubectl` ranks and evicts Pods in the following order:
As a result, `kubelet` ranks and evicts Pods in the following order:
* `BestEffort` Pods consume the most of the starved resource are failed first.
Local disk is a `BestEffort` resource.
* `Burstable` Pods consume the greatest amount of the starved resource
relative to their request for that resource are killed first. If no Pod
has exceeded its request, the strategy targets the largest consumer of the
starved resource.
* `Guaranteed` Pods are guaranteed only when requests and limits are specified
for all the containers and they are equal. A `Guaranteed` Pod is guaranteed to
never be evicted because of another Pod's resource consumption. If a system
daemon (such as `kubelet`, `docker`, and `journald`) is consuming more resources
than were reserved via `system-reserved` or `kube-reserved` allocations, and the
node only has `Guaranteed` Pods remaining, then the node must choose to evict a
`Guaranteed` Pod in order to preserve node stability and to limit the impact
of the unexpected consumption to other `Guaranteed` Pods.
* `BestEffort` or `Burstable` Pods whose usage of a starved resource exceeds its request.
Such pods are ranked by Priority, and then usage above request.
* `Guaranteed` pods and `Burstable` pods whose usage is beneath requests are evicted last.
`Guaranteed` Pods are guaranteed only when requests and limits are specified for all
the containers and they are equal. Such pods are guaranteed to never be evicted because
of another Pod's resource consumption. If a system daemon (such as `kubelet`, `docker`,
and `journald`) is consuming more resources than were reserved via `system-reserved` or
`kube-reserved` allocations, and the node only has `Guaranteed` or `Burstable` Pods using
less than requests remaining, then the node must choose to evict such a Pod in order to
preserve node stability and to limit the impact of the unexpected consumption to other Pods.
In this case, it will choose to evict pods of Lowest Priority first.
If necessary, `kubelet` evicts Pods one at a time to reclaim disk when `DiskPressure`
is encountered. If the `kubelet` is responding to `inode` starvation, it reclaims
@@ -315,7 +312,7 @@ To facilitate this scenario, the `kubelet` would be launched as follows:
Implicit in this configuration is the understanding that "System reserved" should include the amount of memory
covered by the eviction threshold.
To reach that capacity, either some Pod is using more than its request, or the system is using more than `500Mi`.
To reach that capacity, either some Pod is using more than its request, or the system is using more than `1.5Gi - 500Mi = 1Gi`.
This configuration ensures that the scheduler does not place Pods on a node that immediately induce memory pressure
and trigger eviction assuming those Pods use less than their configured request.
docs/tasks/administer-cluster/pvc-protection.md
+1 -1
View File
@@ -1,5 +1,5 @@
---
approvers:
reviewers:
- msau42
- jsafrane
title: Persistent Volume Claim Protection
docs/tasks/administer-cluster/quota-pod-deployment.yaml
+4 -1
View File
@@ -1,8 +1,11 @@
apiVersion: apps/v1beta1
apiVersion: apps/v1
kind: Deployment
metadata:
name: pod-quota-demo
spec:
selector:
matchLabels:
purpose: quota-demo
replicas: 3
template:
metadata:
docs/tasks/administer-cluster/reconfigure-kubelet.md
+3 -3
View File
@@ -1,5 +1,5 @@
---
approvers:
reviewers:
- mtaufen
- dawnchen
title: Reconfigure a Node's Kubelet in a Live Cluster
@@ -290,7 +290,7 @@ configSource:
### Observe that the Kubelet is using the new configuration
Once more, retrieve the Node with `kubectl get node ${NODE_NAME} -o yaml`, and
look for the `ConfigOK` condition in `status.conditions`. You should the message
look for the `ConfigOK` condition in `status.conditions`. You should see the message
`Using current (UID: NEW_CONFIG_MAP_UID)` when the Kubelet starts using the
new configuration.
@@ -333,7 +333,7 @@ condition's message reverts to either `using current (default)` or
### Deauthorize your Node fom reading the old ConfigMap
Once you know your Node is using the default configuraiton again, it is a good
Once you know your Node is using the default configuration again, it is a good
idea to deauthorize the node from reading the old ConfigMap. Run the following
commands to remove the RoleBinding and Role:
docs/tasks/administer-cluster/reserve-compute-resources.md
+1 -1
View File
@@ -1,5 +1,5 @@
---
approvers:
reviewers:
- vishh
- derekwaynecarr
- dashpole
docs/tasks/administer-cluster/romana-network-policy.md
+1 -1
View File
@@ -1,5 +1,5 @@
---
approvers:
reviewers:
- chrismarino
title: Romana for NetworkPolicy
---
docs/tasks/administer-cluster/running-cloud-controller.md
+5 -5
View File
@@ -1,21 +1,21 @@
---
approvers:
reviewers:
- luxas
- thockin
- wlan0
title: Kubernetes Cloud Controller Manager
---
**Cloud Controller Manager is an alpha feature in 1.8. In upcoming releases it will be the preferred way to integrate Kubernetes with any cloud. This will ensure cloud providers can develop their features independantly from the core Kubernetes release cycles.**
{% include feature-state-alpha.md %}
* TOC
{:toc}
## Cloud Controller Manager
Kubernetes v1.6 contains 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.
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 satisifies [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://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.
## Administration
@@ -25,7 +25,7 @@ Every cloud has their own set of requirements for running their own cloud provid
* cloud authentication/authorization: your cloud may require a token or IAM rules to allow access to their APIs
* kubernetes authentication/authorization: cloud-controller-manager may need RBAC rules set to speak to the kubernetes apiserver
* high availabilty: like kube-controller-manager, you may want a high available setup for cloud controller manager using leader election (on by default).
* high availability: like kube-controller-manager, you may want a high available setup for cloud controller manager using leader election (on by default).
### Running cloud-controller-manager
docs/tasks/administer-cluster/safely-drain-node.md
+3 -4
View File
@@ -1,5 +1,5 @@
---
approvers:
reviewers:
- davidopp
- mml
- foxish
@@ -33,9 +33,8 @@ This task assumes that you have met the following prerequisites:
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/tasks/#lifecycle-hooks-and-termination-notice) and
will respect the `PodDisruptionBudgets` you have specified.
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
that cannot be killed; see
docs/tasks/administer-cluster/securing-a-cluster.md
+2 -2
View File
@@ -1,5 +1,5 @@
---
approvers:
reviewers:
- smarterclayton
- liggitt
- ericchiang
@@ -39,7 +39,7 @@ potentially unsecured traffic.
Choose an authentication mechanism for the API servers to use that matches the common access patterns
when you install a cluster. For instance, small single user clusters may wish to use a simple certificate
or static Bearer token approach. Larger clusters may wish to integrate an existing or OIDC or LDAP server that
or static Bearer token approach. Larger clusters may wish to integrate an existing OIDC or LDAP server that
allow users to be subdivided into groups.
All API clients must be authenticated, even those that are part of the infrastructure like nodes,
docs/tasks/administer-cluster/static-pod.md
+1 -1
View File
@@ -1,5 +1,5 @@
---
approvers:
reviewers:
- jsafrane
title: Static Pods
---
docs/tasks/administer-cluster/sysctl-cluster.md
+166
View File
@@ -0,0 +1,166 @@
---
title: Using Sysctls in a Kubernetes Cluster
reviewers:
- sttts
---
{% capture overview %}
This document describes how sysctls are used within a Kubernetes cluster.
{% endcapture %}
{% capture prerequisites %}
{% include task-tutorial-prereqs.md %}
{% endcapture %}
{% capture steps %}
## Listing all Sysctl Parameters
In Linux, the sysctl interface allows an administrator to modify kernel
parameters at runtime. Parameters are available via the `/proc/sys/` virtual
process file system. The parameters cover various subsystems such as:
- kernel (common prefix: `kernel.`)
- networking (common prefix: `net.`)
- virtual memory (common prefix: `vm.`)
- MDADM (common prefix: `dev.`)
- More subsystems are described in [Kernel docs](https://www.kernel.org/doc/Documentation/sysctl/README).
To get a list of all parameters, you can run
```shell
$ sudo sysctl -a
```
## Enabling Unsafe Sysctls
Sysctls are grouped into _safe_ and _unsafe_ sysctls. In addition to proper
namespacing a _safe_ sysctl must be properly _isolated_ between pods on the same
node. This means that setting a _safe_ sysctl for one pod
- must not have any influence on any other pod on the node
- must not allow to harm the node's health
- must not allow to gain CPU or memory resources outside of the resource limits
of a pod.
By far, most of the _namespaced_ sysctls are not necessarily considered _safe_.
The following sysctls are supported in the _safe_ set:
- `kernel.shm_rmid_forced`,
- `net.ipv4.ip_local_port_range`,
- `net.ipv4.tcp_syncookies`.
**Note**: 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
supports better isolation mechanisms.
All _safe_ sysctls are enabled by default.
All _unsafe_ sysctls are disabled by default and must be allowed manually by the
cluster admin on a per-node basis. Pods with disabled unsafe sysctls will be
scheduled, but will fail to launch.
With the warning above in mind, the cluster admin can allow certain _unsafe_
sysctls for very special situations like e.g. high-performance or real-time
application tuning. _Unsafe_ sysctls are enabled on a node-by-node basis with a
flag of the kubelet, e.g.:
```shell
$ kubelet --experimental-allowed-unsafe-sysctls \
'kernel.msg*,net.ipv4.route.min_pmtu' ...
```
For minikube, this can be done via the `extra-config` flag:
```shell
$ minikube start --extra-config="kubelet.AllowedUnsafeSysctls=kernel.msg*,net.ipv4.route.min_pmtu"...
```
Only _namespaced_ sysctls can be enabled this way.
## Setting Sysctls for a Pod
A number of sysctls are _namespaced_ in today's Linux kernels. This means that
they can be set independently for each pod on a node. Being namespaced is a
requirement for sysctls to be accessible in a pod context within Kubernetes.
The following sysctls are known to be _namespaced_:
- `kernel.shm*`,
- `kernel.msg*`,
- `kernel.sem`,
- `fs.mqueue.*`,
- `net.*`.
Sysctls which are not namespaced are called _node-level_ and must be set
manually by the cluster admin, either by means of the underlying Linux
distribution of the nodes (e.g. via `/etc/sysctls.conf`) or using a DaemonSet
with privileged containers.
The sysctl feature is an alpha API. Therefore, sysctls are set using annotations
on pods. They apply to all containers in the same pod.
Here is an example, with different annotations for _safe_ and _unsafe_ sysctls:
```yaml
apiVersion: v1
kind: Pod
metadata:
name: sysctl-example
annotations:
security.alpha.kubernetes.io/sysctls: kernel.shm_rmid_forced=1
security.alpha.kubernetes.io/unsafe-sysctls: net.ipv4.route.min_pmtu=1000,kernel.msgmax=1 2 3
spec:
...
```
{% endcapture %}
{% capture discussion %}
**Warning**: 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}
It is good practice to consider nodes with special sysctl settings as
_tainted_ within a cluster, and only schedule pods onto them which need those
sysctl settings. It is suggested to use the Kubernetes [_taints and toleration_
feature](/docs/user-guide/kubectl/{{page.version}}/#taint) to implement this.
A pod with the _unsafe_ sysctls will fail to launch on any node which has not
enabled those two _unsafe_ sysctls explicitly. As with _node-level_ sysctls it
is recommended to use
[_taints and toleration_ feature](/docs/user-guide/kubectl/{{page.version}}/#taint) or
[taints on nodes](/docs/concepts/configuration/taint-and-toleration/)
to schedule those pods onto the right nodes.
## PodSecurityPolicy Annotations
The use of sysctl in pods can be controlled via annotation on the PodSecurityPolicy.
Sysctl annotation represents a whitelist of allowed safe and unsafe sysctls
in a pod spec. It's a comma-separated list of plain sysctl names or sysctl patterns
(which end in `*`). The string `*` matches all sysctls.
Here is an example, it authorizes binding user creating pod with corresponding sysctls.
```yaml
apiVersion: extensions/v1beta1
kind: PodSecurityPolicy
metadata:
name: sysctl-psp
annotations:
security.alpha.kubernetes.io/sysctls: 'net.ipv4.route.*,kernel.msg*'
spec:
...
```
{% endcapture %}
{% include templates/task.md %}
docs/tasks/administer-cluster/upgrade-1-6.md
+1 -1
View File
@@ -1,5 +1,5 @@
---
approvers:
reviewers:
- mml
title: Cluster Management Guide for Version 1.6
---
docs/tasks/administer-cluster/weave-network-policy.md
+5 -131
View File
@@ -1,5 +1,5 @@
---
approvers:
reviewers:
- bboreham
title: Weave Net for NetworkPolicy
---
@@ -12,7 +12,7 @@ This page shows how to use Weave Net for NetworkPolicy.
{% capture prerequisites %}
Complete steps 1, 2, and 3 of the [kubeadm getting started guide](/docs/getting-started-guides/kubeadm/).
You need to have a Kubernetes cluster. Follow the [kubeadm getting started guide](/docs/getting-started-guides/kubeadm/) to bootstrap one.
{% endcapture %}
@@ -24,84 +24,9 @@ Follow the [Integrating Kubernetes via the Addon](https://www.weave.works/docs/n
The Weave Net addon for Kubernetes comes with a [Network Policy Controller](https://www.weave.works/docs/net/latest/kube-addon/#npc) that automatically monitors Kubernetes for any NetworkPolicy annotations on all namespaces and configures `iptables` rules to allow or block traffic as directed by the policies.
## Namespace isolation example
1. Create a Namespace with `DefaultDeny`.
```yaml
kind: Namespace
apiVersion: v1
metadata:
name: myns
annotations:
net.beta.kubernetes.io/network-policy: |
{
"ingress": {
"isolation": "DefaultDeny"
}
}
```
2. Create 2 Pods inside this Namespace.
```yaml
kind: Pod
apiVersion: v1
metadata:
name: pod1
namespace: myns
labels:
inns: "yes"
spec:
containers:
- name: pod1
image: nginx
---
kind: Pod
apiVersion: v1
metadata:
name: pod2
namespace: myns
labels:
inns: "yes"
spec:
containers:
- name: pod2
image: nginx
```
3. Get the IP addresses of the Pods.
```shell
kubectl get po -n myns -o wide
```
**Note:** If your cURL requests to Pods are forbidden, try making cURL requests to other Pods from within a Pod.
{: .note}
4. Create a Kubernetes NetworkPolicy that allows Pods within the same Namespace to connect with each other.
```yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: aaa
namespace: myns
spec:
podSelector:
matchExpressions:
- {key: inns, operator: In, values: ["yes"]}
ingress:
- from:
- podSelector:
matchExpressions:
- {key: inns, operator: In, values: ["yes"]}
```
**Caution:** After applying the network policy, pods outside the namespace you specify may be unable to connect with pods inside the namespace.
{. :caution}
## Test the installation
1. Verify that the weave works.
Verify that the weave works.
Enter the following command:
@@ -113,7 +38,7 @@ The output is similar to this:
```
NAME READY STATUS RESTARTS AGE IP NODE
weave-net-1t1qg 2/2 Running 0 9d 192.168.2.10 workndoe3
weave-net-1t1qg 2/2 Running 0 9d 192.168.2.10 worknode3
weave-net-231d7 2/2 Running 1 7d 10.2.0.17 worknodegpu
weave-net-7nmwt 2/2 Running 3 9d 192.168.2.131 masternode
weave-net-pmw8w 2/2 Running 0 9d 192.168.2.216 worknode2
@@ -121,62 +46,11 @@ weave-net-pmw8w 2/2 Running 0 9d
Each Node has a weave Pod, and all Pods are `Running` and `2/2 READY`. (`2/2` means that each Pod has `weave` and `weave-npc`.)
2. Create a Network Policy.
For more information, see "[Declare Network Policy](https://kubernetes.io/docs/tasks/administer-cluster/declare-network-policy/)".
3. Check the logs.
After creating a NetworkPolicy, check the logs:
```shell
kubectl logs -f weave-net-pmw8w weave-npc -n kube-system
```
Log output looks like this:
```log
INFO: 2017/08/14 02:22:32.511992 EVENT AddNetworkPolicy {"metadata":{"name":"aaa","namespace":"myns","selfLink":"/apis/extensions/v1beta1/namespaces/myns/networkpolicies/aaa","uid":"67b229fd-8097-11e7-92f3-005056a3bc75","resourceVersion":"1507955","generation":1,"creationTimestamp":"2017-08-14T02:22:22Z"},"spec":{"podSelector":{"matchExpressions":[{"key":"inns","operator":"In","values":["yes"]}]},"ingress":[{"from":[{"podSelector":{"matchExpressions":[{"key":"inns","operator":"In","values":["yes"]}]}}]}]}}
INFO: 2017/08/14 02:22:32.512103 creating ipset: &npc.selectorSpec{key:"inns in (yes)", selector:labels.internalSelector{labels.Requirement{key:"inns", operator:"in", strValues:[]string{"yes"}}}, ipsetType:"hash:ip", ipsetName:"weave-[T]a=ETzaKA{o*muaFe:2IX(t"}
INFO: 2017/08/14 02:22:32.538003 adding rule: [-m set --match-set weave-[T]a=ETzaKA{o*muaFe:2IX(t src -m set --match-set weave-[T]a=ETzaKA{o*muaFe:2IX(t dst -j ACCEPT]
^[^C
```
4. Finally, check the logs for iptables.
```shell
iptables -L
```
The output is similar to this:
```iptables
Chain WEAVE-NPC (1 references)
target prot opt source destination
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT all -- anywhere base-address.mcast.net/4
WEAVE-NPC-DEFAULT all -- anywhere anywhere state NEW
WEAVE-NPC-INGRESS all -- anywhere anywhere state NEW
ACCEPT all -- anywhere anywhere ! match-set weave-local-pods dst
Chain WEAVE-NPC-DEFAULT (1 references)
target prot opt source destination
ACCEPT all -- anywhere anywhere match-set weave-iuZcey(5DeXbzgRFs8Szo]+@p dst
ACCEPT all -- anywhere anywhere match-set weave-k?Z;25^M}|1s7P3|H9i;*;MhG dst
ACCEPT all -- anywhere anywhere match-set weave-4vtqMI+kx/2]jD%_c0S%thO%V dst
Chain WEAVE-NPC-INGRESS (1 references)
target prot opt source destination
ACCEPT all -- anywhere anywhere match-set weave-[T]a=ETzaKA{o*muaFe:2IX(t src match-set weave-[T]a=ETzaKA{o*muaFe:2IX(t dst
```
The match-set labels have been applied to iptables, so the weave is working correctly.
{% endcapture %}
{% capture whatsnext %}
Once you have installed the Weave Net addon, you can follow the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) to try out Kubernetes NetworkPolicy.
Once you have installed the Weave Net addon, you can follow the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) to try out Kubernetes NetworkPolicy. If you have any question, contact us at [#weave-community on Slack or Weave User Group](https://github.com/weaveworks/weave#getting-help).
{% endcapture %}