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: (140 commits)
  Update configure-multiple-schedulers.md (#6877)
  Explicitly specify the components that need a change (#6873)
  Updates to partner page (#6797)
  Add steps for extension api-server setup (#6667)
  securing a cluster: add recommendations about cloud metadata APIs (#6659)
  Namespace glossary term (#6607)
  Update device plugin doc with upgrade suggestions and known limitations. (#6501)
  Add Kubermatic to pick-right-solution.md (#6459)
  extra word
  typo
  Fix concepts/configuration/secret
  Link to extended resources instead of deprecated opaque integer resources
  Fix CI issue
  Corrected the group in runtime-config of ValidatingAdmissionWebhook and MutatingAdmissionWebhook. It should be admissionregistration.k8s.io (was admissionregistration).
  Correct references in Jekyll data files
  Update scheduling-hugepages.md
  Drop reference to outdated FAQ
  Follow sig list to kubernetes/community
  Update scheduling-hugepages.md
  Fix references to ConfigMap for the CN website
  ...

# Conflicts:
#	docs/concepts/policy/pod-security-policy.md
This commit is contained in:
Andrew Chen
2018-01-08 18:24:38 -08:00
parent 3013651535 96648cfc1d
commit b09f1b94f2
270 changed files with 2961 additions and 2071 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/tasks/access-application-cluster/access-cluster.md
+4 -6
View File
@@ -154,7 +154,7 @@ the `kubernetes` DNS name, which resolves to a Service IP which in turn
will be routed to an apiserver.
The recommended way to authenticate to the apiserver is with a
[service account](/docs/tasks/configure-pod-container/configure-service-account/) credential. By kube-system, a pod
[service account](/docs/tasks/configure-pod-container/configure-service-account/) credential. By kube-system, a pod
is associated with a service account, and a credential (token) for that
service account is placed into the filesystem tree of each container in that pod,
at `/var/run/secrets/kubernetes.io/serviceaccount/token`.
@@ -168,17 +168,15 @@ at `/var/run/secrets/kubernetes.io/serviceaccount/namespace` in each container.
From within a pod the recommended ways to connect to API are:
- run a kubectl proxy as one of the containers in the pod, or as a background
process within a container. This proxies the
- run `kubectl proxy` in a sidecar container in the pod, or as a background
process within the container. This proxies the
Kubernetes API to the localhost interface of the pod, so that other processes
in any container of the pod can access it. See this [example of using kubectl proxy
in a pod](https://github.com/kubernetes/examples/tree/{{page.githubbranch}}/staging/kubectl-container/).
in any container of the pod can access it.
- use the Go client library, and create a client using the `rest.InClusterConfig()` and `kubernetes.NewForConfig()` functions.
They handle locating and authenticating to the apiserver. [example](https://git.k8s.io/client-go/examples/in-cluster-client-configuration/main.go)
In each case, the credentials of the pod are used to communicate securely with the apiserver.
## Accessing services running on the cluster
The previous section was about connecting the Kubernetes API server. This section is about
docs/tasks/access-application-cluster/connecting-frontend-backend.md
+2 -2
View File
@@ -149,7 +149,7 @@ service "frontend" created
**Note**: The nginx configuration is baked into the
[container image](/docs/tasks/access-application-cluster/frontend/Dockerfile).
A better way to do this would be to use a
[ConfigMap](/docs/tasks/configure-pod-container/configmap/), so
[ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/), so
that you can change the configuration more easily.
### Interact with the frontend Service
@@ -197,7 +197,7 @@ The output shows the message generated by the backend:
{% capture whatsnext %}
* Learn more about [Services](/docs/concepts/services-networking/service/)
* Learn more about [ConfigMaps](/docs/tasks/configure-pod-container/configmap/)
* Learn more about [ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/)
{% endcapture %}
docs/tasks/access-application-cluster/create-external-load-balancer.md
+9 -3
View File
@@ -8,9 +8,15 @@ title: Create an External Load Balancer
This page shows how to create an External Load Balancer.
When creating a service, you have the option of automatically creating a
cloud network load balancer. This provides an
externally-accessible IP address that sends traffic to the correct port on your
cluster nodes _provided your cluster runs in a supported environment and is configured with the correct cloud load balancer provider package_.
cloud network load balancer. This provides an externally-accessible IP address
that sends traffic to the correct port on your cluster nodes
_provided your cluster runs in a supported environment and is configured with
the correct cloud load balancer provider package_.
For information on provisioning and using an Ingress resource that can give
services externally-reachable URLs, load balance the traffic, terminate SSL etc.,
please check the [Ingress](/docs/concepts/services-networking/ingress/)
documentation.
{% endcapture %}
docs/tasks/access-application-cluster/port-forward-access-application-cluster.md
+5
View File
@@ -83,6 +83,11 @@ Connections made to local port 6379 are forwarded to port 6379 of the pod that
is running the Redis server. With this connection in place you can use your
local workstation to debug the database that is running in the pod.
**Warning**: Due to known limitations, port forward today only works for TCP protocol.
The support to UDP protocol is being tracked in
[issue 47862](https://github.com/kubernetes/kubernetes/issues/47862).
{: .warning}
{% endcapture %}
docs/tasks/access-application-cluster/redis-master.yaml
+1 -1
View File
@@ -9,7 +9,7 @@ metadata:
spec:
containers:
- name: master
image: gcr.io/google_containers/redis:v1
image: k8s.gcr.io/redis:v1
env:
- name: MASTER
value: "true"
docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions.md
+19 -5
View File
@@ -74,6 +74,10 @@ This endpoint URL can then be used to create and manage custom objects.
The `kind` of these objects will be `CronTab` from the spec of the
CustomResourceDefinition object you created above.
Please note that it might take a few seconds for the endpoint to be created.
You can watch the `Established` condition of your CustomResourceDefinition
to be true or watch the discovery information of the API server for your
resource to show up.
## Create custom objects
@@ -188,12 +192,22 @@ metadata:
- finalizer.stable.example.com
```
The first delete request on an object with finalizers merely sets a value for the
`metadata.deletionTimestamp` field instead of deleting it.
This triggers controllers watching the object to execute any finalizers they handle.
Finalizers are arbitrary string values, that when present ensure that a hard delete
of a resource is not possible while they exist.
Each controller then removes its finalizer from the list and issues the delete request again.
This request only deletes the object if the list of finalizers is now empty,
The first delete request on an object with finalizers merely sets a value for the
`metadata.deletionTimestamp` field instead of deleting it. Once this value is set,
entries in the `finalizer` list can only be removed.
This triggers controllers watching the object to execute any finalizers they handle.
This will be represented via polling update requests for that
object, until all finalizers have been removed and the resource is deleted.
The time period of polling update can be controlled by `metadata.deletionGracePeriodSeconds`.
It is the responsibility of each controller to removes its finalizer from the list.
Kubernetes will only finally delete the object if the list of finalizers is empty,
meaning all finalizers are done.
### Validation
docs/tasks/access-kubernetes-api/setup-extension-api-server.md
+3 -1
View File
@@ -37,7 +37,9 @@ Alternatively, you can use an existing 3rd party solution, such as [apiserver-bu
1. Make sure that your extension-apiserver loads those certs from that volume and that they are used in the HTTPS handshake.
1. Create a Kubernetes service account in your namespace.
1. Create a Kubernetes cluster role for the operations you want to allow on your resources.
1. Create a Kubernetes cluster role binding from the default service account in your namespace to the cluster role you just created.
1. Create a Kubernetes cluster role binding from the service account in your namespace to the cluster role you just created.
1. Create a Kubernetes cluster role binding from the service account in your namespace to the `system:auth-delegator` cluster role to delegate auth decisions to the Kubernetes core API server.
1. Create a Kubernetes role binding from the service account in your namespace to the `extension-apiserver-authentication-reader` role. This allows your extension api-server to access the `extension-apiserver-authentication` configmap.
1. Create a Kubernetes apiservice. The CA cert above should be base64 encoded, stripped of new lines and used as the spec.caBundle in the apiservice. This should not be namespaced. If using the [kube-aggregator API](https://github.com/kubernetes/kube-aggregator/), only pass in the PEM encoded CA bundle because the base 64 encoding is done for you.
1. Use kubectl to get your resource. It should return "No resources found." Which means that everything worked but you currently have no objects of that resource type created yet.
docs/tasks/administer-cluster/cilium-network-policy.md
+29 -15
View File
@@ -7,7 +7,7 @@ title: Use Cilium for NetworkPolicy
{% capture overview %}
This page shows how to use Cilium for NetworkPolicy.
For background on Cilium, read the [Introduction to Cilium](http://cilium.readthedocs.io/en/latest/intro/).
For background on Cilium, read the [Introduction to Cilium](https://cilium.readthedocs.io/en/latest/intro).
{% endcapture %}
{% capture prerequisites %}
@@ -20,37 +20,41 @@ For background on Cilium, read the [Introduction to Cilium](http://cilium.readth
## Deploying Cilium on Minikube for Basic Testing
To get familiar with Cilium easily you can follow the
[Cilium Kubernetes Getting Started Guide](http://www.cilium.io/try)
[Cilium Kubernetes Getting Started Guide](https://docs.cilium.io/en/latest/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 and a key-value store
(consul) as well as appropriate RBAC settings:
file that includes DaemonSet configurations for Cilium, to connect
to the minikube's etcd instance as well as appropriate RBAC settings:
```shell
$ kubectl create -f https://raw.githubusercontent.com/cilium/cilium/master/examples/minikube/cilium-ds.yaml
clusterrole "cilium" created
$ 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-consul" created
daemonset "cilium" created
clusterrole "cilium" created
```
The remainder of the Getting Started Guide explains how to enforce both L3/L4 (i.e., IP address + port) security
policies, as well as L7 (e.g., HTTP) security policies using an example application.
The remainder of the Getting Started Guide explains how to enforce both L3/L4
(i.e., IP address + port) security policies, as well as L7 (e.g., HTTP) security
policies using an example application.
## Deploying Cilium for Production Use
For detailed instructions around deploying Cilium for production, see:
[Cilium Administrator Guide](http://cilium.readthedocs.io/en/latest/admin/) This
documentation includes detailed requirements, instructions and example production DaemonSet files.
[Cilium Kubernetes Installation Guide](https://cilium.readthedocs.io/en/latest/kubernetes/install/)
This documentation includes detailed requirements, instructions and example
production DaemonSet files.
{% endcapture %}
{% capture discussion %}
## Understanding Cilium components
Deploying a cluster with Cilium adds Pods to the `kube-system` namespace. To see this list of Pods run:
Deploying a cluster with Cilium adds Pods to the `kube-system` namespace. To see
this list of Pods run:
```shell
kubectl get pods --namespace=kube-system
@@ -66,13 +70,23 @@ cilium 1 1 1 <none> 2m
There are two main components to be aware of:
- One `cilium` Pod runs on each node in your cluster and enforces network policy on the traffic to/from Pods on that node using Linux BPF.
- For production deployments, Cilium should leverage the key-value store cluster (e.g., etcd) used by Kubernetes, which typically runs on the Kubernetes master nodes. The [Cilium Administrator Guide](http://cilium.readthedocs.io/en/latest/admin/) includes an example DaemonSet which can be customized to point to this key-value store cluster. The simple ''all-in-one'' DaemonSet for minikube requires no such configuration because it automatically deploys a `cilium-consul` Pod to provide a key-value store.
- 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.
{% 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 with Cilium. Have fun, and if you have questions, contact us using the [Cilium Slack Channel](https://cilium.herokuapp.com/).
Once your cluster is running, you can follow the
[Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/)
to try out Kubernetes NetworkPolicy with Cilium.
Have fun, and if you have questions, contact us using the
[Cilium Slack Channel](https://cilium.herokuapp.com/).
{% endcapture %}
{% include templates/task.md %}
docs/tasks/administer-cluster/cloud-controller-manager-daemonset-example.yaml
+2 -2
View File
@@ -42,9 +42,9 @@ spec:
serviceAccountName: cloud-controller-manager
containers:
- name: cloud-controller-manager
# for in-tree providers we use gcr.io/google_containers/cloud-controller-manager
# for in-tree providers we use k8s.gcr.io/cloud-controller-manager
# this can be replaced with any other image for out-of-tree providers
image: gcr.io/google_containers/cloud-controller-manager:v1.8.0
image: k8s.gcr.io/cloud-controller-manager:v1.8.0
command:
- /usr/local/bin/cloud-controller-manager
- --cloud-provider=<YOUR_CLOUD_PROVIDER> # Add your own cloud provider here!
docs/tasks/administer-cluster/configure-multiple-schedulers.md
+1 -1
View File
@@ -13,7 +13,7 @@ learn how to run multiple schedulers in Kubernetes with an example.
A detailed description of how to implement a scheduler is outside the scope of this
document. Please refer to the kube-scheduler implementation in
[plugin/pkg/scheduler](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/plugin/pkg/scheduler)
[pkg/scheduler](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/pkg/scheduler)
in the Kubernetes source directory for a canonical example.
### 1. Package the scheduler
docs/tasks/administer-cluster/coredns.md
+1 -1
View File
@@ -35,7 +35,7 @@ This installs CoreDNS instead of kube-dns.
You can configure [CoreDNS](https://coredns.io) to support many more use cases than
kube-dns by modifying the `Corefile`. For more information, see the
[CoreDNS site]https://coredns.io/2017/05/08/custom-dns-entries-for-kubernetes/).
[CoreDNS site](https://coredns.io/2017/05/08/custom-dns-entries-for-kubernetes/).
{% endcapture %}
docs/tasks/administer-cluster/cpu-management-policies.md
+6
View File
@@ -1,7 +1,13 @@
---
title: Control CPU Management Policies on the Node
approvers:
- sjenning
- ConnorDoyle
- balajismaniam
---
{% include feature-state-beta.md %}
* TOC
{:toc}
docs/tasks/administer-cluster/dns-custom-nameservers.md
+4 -4
View File
@@ -73,9 +73,9 @@ metadata:
namespace: kube-system
data:
stubDomains: |
{“acme.local”: [“1.2.3.4”]}
{"acme.local": ["1.2.3.4"]}
upstreamNameservers: |
[“8.8.8.8”, “8.8.4.4”]
["8.8.8.8", "8.8.4.4"]
```
As specified, DNS requests with the “.acme.local” suffix
@@ -158,7 +158,7 @@ metadata:
namespace: kube-system
data:
stubDomains: |
{“consul.local”: [“10.150.0.1”]}
{"consul.local": ["10.150.0.1"]}
```
Note that the cluster administrator did not wish to override the node’s
@@ -180,7 +180,7 @@ metadata:
namespace: kube-system
data:
upstreamNameservers: |
[“172.16.0.1”]
["172.16.0.1"]
```
## Debugging DNS resolution
docs/tasks/administer-cluster/dns-horizontal-autoscaler.yaml
+1 -1
View File
@@ -13,7 +13,7 @@ spec:
spec:
containers:
- name: autoscaler
image: gcr.io/google_containers/cluster-proportional-autoscaler-amd64:1.0.0
image: k8s.gcr.io/cluster-proportional-autoscaler-amd64:1.0.0
resources:
requests:
cpu: "20m"
docs/tasks/administer-cluster/encrypt-data.md
+1 -1
View File
@@ -1,7 +1,7 @@
---
approvers:
- smarterclayton
title: Encrypting data at rest
title: Encrypting Secret Data at Rest
---
{% capture overview %}
docs/tasks/administer-cluster/ip-masq-agent.md
+1 -1
View File
@@ -71,7 +71,7 @@ kubectl label nodes my-node beta.kubernetes.io/masq-agent-ds-ready=true
More information can be found in the ip-masq-agent documentation [here](https://github.com/kubernetes-incubator/ip-masq-agent)
In most cases, the default set of rules should be sufficient; however, if this is not the case for your cluster, you can create and apply a [ConfigMap](/docs/tasks/configure-pod-container/configmap/) to customize the IP ranges that are affected. For example, to allow only 10.0.0.0/8 to be considered by the ip-masq-agent, you can create the following [ConfigMap](/docs/tasks/configure-pod-container/configmap/) in a file called "config".
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:
```
docs/tasks/administer-cluster/kubeadm-upgrade-1-9.md
+3
View File
@@ -114,6 +114,8 @@ _____________________________________________________________________
The `kubeadm upgrade plan` checks that your cluster is upgradeable and fetches the versions available to upgrade to in an user-friendly way.
To check CoreDNS version, include the `--feature-gates=CoreDNS=true` flag to verify the CoreDNS version which will be installed in place of kube-dns.
3. Pick a version to upgrade to and run. For example:
```shell
@@ -162,6 +164,7 @@ $ kubeadm upgrade apply v1.9.0
[upgrade/kubelet] Now that your control plane is upgraded, please proceed with upgrading your kubelets in turn.
```
To upgrade the cluster with CoreDNS as the default internal DNS, invoke `kubeadm upgrade apply` with the `--feature-gates=CoreDNS=true` flag.
`kubeadm upgrade apply` does the following:
- Checks that your cluster is in an upgradeable state:
docs/tasks/administer-cluster/memory-available.sh
+31
View File
@@ -0,0 +1,31 @@
#!/bin/bash
#!/usr/bin/env bash
# This script reproduces what the kubelet does
# to calculate memory.available relative to root cgroup.
# current memory usage
memory_capacity_in_kb=$(cat /proc/meminfo | grep MemTotal | awk '{print $2}')
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
if [ "$memory_working_set" -lt "$memory_total_inactive_file" ];
then
memory_working_set=0
else
memory_working_set=$((memory_usage_in_bytes - memory_total_inactive_file))
fi
memory_available_in_bytes=$((memory_capacity_in_bytes - memory_working_set))
memory_available_in_kb=$((memory_available_in_bytes / 1024))
memory_available_in_mb=$((memory_available_in_kb / 1024))
echo "memory.capacity_in_bytes $memory_capacity_in_bytes"
echo "memory.usage_in_bytes $memory_usage_in_bytes"
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"
docs/tasks/administer-cluster/namespace-prod.json
+10
View File
@@ -0,0 +1,10 @@
{
"kind": "Namespace",
"apiVersion": "v1",
"metadata": {
"name": "production",
"labels": {
"name": "production"
}
}
}
docs/tasks/administer-cluster/namespaces-walkthrough.md
+1 -1
View File
@@ -66,7 +66,7 @@ $ kubectl create -f docs/admin/namespaces/namespace-dev.json
And then let's create the production namespace using kubectl.
```shell
$ kubectl create -f docs/admin/namespaces/namespace-prod.json
$ kubectl create -f docs/tasks/administer-cluster/namespace-prod.json
```
To be sure things are right, let's list all of the namespaces in our cluster.
docs/tasks/administer-cluster/namespaces.md
+1 -1
View File
@@ -152,7 +152,7 @@ $ kubectl create -f docs/admin/namespaces/namespace-dev.json
And then let's create the production namespace using kubectl.
```shell
$ kubectl create -f docs/admin/namespaces/namespace-prod.json
$ kubectl create -f docs/tasks/administer-cluster/namespace-prod.json
```
To be sure things are right, list all of the namespaces in our cluster.
docs/tasks/administer-cluster/out-of-resource.md
-7
View File
@@ -370,10 +370,3 @@ to prevent system OOMs, and promote eviction of workloads so cluster state can r
The Pod eviction may evict more Pods than needed due to stats collection timing gap. This can be mitigated by adding
the ability to get root container stats on an on-demand basis [(https://github.com/google/cadvisor/issues/1247)](https://github.com/google/cadvisor/issues/1247) in the future.
### How kubelet ranks Pods for eviction in response to inode exhaustion
At this time, it is not possible to know how many inodes were consumed by a particular container. If the `kubelet` observes
inode exhaustion, it evicts Pods by ranking them by quality of service. The following issue has been opened in cadvisor
to track per container inode consumption [(https://github.com/google/cadvisor/issues/1422)](https://github.com/google/cadvisor/issues/1422) which would allow us to rank Pods
by inode consumption. For example, this would let us identify a container that created large numbers of 0 byte files, and evict that Pod over others.
docs/tasks/administer-cluster/pod1.yaml
+1 -1
View File
@@ -7,4 +7,4 @@ metadata:
spec:
containers:
- name: pod-with-no-annotation-container
image: gcr.io/google_containers/pause:2.0
image: k8s.gcr.io/pause:2.0
docs/tasks/administer-cluster/pod2.yaml
+1 -1
View File
@@ -8,4 +8,4 @@ spec:
schedulerName: default-scheduler
containers:
- name: pod-with-default-annotation-container
image: gcr.io/google_containers/pause:2.0
image: k8s.gcr.io/pause:2.0
docs/tasks/administer-cluster/pod3.yaml
+1 -1
View File
@@ -8,4 +8,4 @@ spec:
schedulerName: my-scheduler
containers:
- name: pod-with-second-annotation-container
image: gcr.io/google_containers/pause:2.0
image: k8s.gcr.io/pause:2.0
docs/tasks/administer-cluster/pvc-protection.md
+1 -1
View File
@@ -94,7 +94,7 @@ metadata:
spec:
containers:
- name: test-pod
image: gcr.io/google_containers/busybox:1.24
image: k8s.gcr.io/busybox:1.24
command:
- "/bin/sh"
args:
docs/tasks/administer-cluster/reconfigure-kubelet.md
+1 -1
View File
@@ -27,7 +27,7 @@ from alpha.
running, with the `DynamicKubeletConfig` feature gate enabled and the Kubelet's
`--dynamic-config-dir` flag set to a writeable directory on the Node.
This flag must be set to enable Dynamic Kubelet Configuration.
- The kubectl command-line tool must be also be v1.8 or higher, and must be
- The kubectl command-line tool must be also v1.8 or higher, and must be
configured to communicate with the cluster.
{% endcapture %}
docs/tasks/administer-cluster/running-cloud-controller.md
+1
View File
@@ -61,6 +61,7 @@ For cloud controller managers not in Kubernetes core, you can find the respectiv
* [DigitalOcean](https://github.com/digitalocean/digitalocean-cloud-controller-manager)
* [keepalived](https://github.com/munnerz/keepalived-cloud-provider)
* [Oracle Cloud Infrastructure](https://github.com/oracle/oci-cloud-controller-manager)
* [Rancher](https://github.com/rancher/rancher-cloud-controller-manager)
For providers already in Kubernetes core, you can run the in-tree cloud controller manager as a Daemonset in your cluster, use the following as a guideline:
docs/tasks/administer-cluster/safely-drain-node.md
+8 -8
View File
@@ -98,8 +98,8 @@ You should first be familiar with using [Kubernetes language clients](/docs/task
The eviction subresource of a
pod can be thought of as a kind of policy-controlled DELETE operation on the pod
itself. To attempt an eviction (perhaps more REST-precisely, to attempt to
*create* an eviction), you POST an attempted operation. Here's an example:
itself. To attempt an eviction (perhaps more REST-precisely, to attempt to
*create* an eviction), you POST an attempted operation. Here's an example:
```json
{
@@ -123,7 +123,7 @@ The API can respond in one of three ways:
- If the eviction is granted, then the pod is deleted just as if you had sent
a `DELETE` request to the pod's URL and you get back `200 OK`.
- If the current state of affairs wouldn't allow an eviction by the rules set
forth in the budget, you get back `429 Too Many Requests`. This is
forth in the budget, you get back `429 Too Many Requests`. This is
typically used for generic rate limiting of *any* requests, but here we mean
that this request isn't allowed *right now* but it may be allowed later.
Currently, callers do not get any `Retry-After` advice, but they may in
@@ -131,21 +131,21 @@ The API can respond in one of three ways:
- If there is some kind of misconfiguration, like multiple budgets pointing at
the same pod, you will get `500 Internal Server Error`.
For a given eviction request, there are two cases.
For a given eviction request, there are two cases:
- There is no budget that matches this pod. In this case, the server always
- There is no budget that matches this pod. In this case, the server always
returns `200 OK`.
- There is at least one budget. In this case, any of the three above responses may
- There is at least one budget. In this case, any of the three above responses may
apply.
In some cases, an application may reach a broken state where it will never return anything
other than 429 or 500. This can happen, for example, if the replacement pod created by the
other than 429 or 500. This can happen, for example, if the replacement pod created by the
application's controller does not become ready, or if the last pod evicted has a very long
termination grace period.
In this case, there are two potential solutions:
- Abort or pause the automated operation. Investigate the reason for the stuck application, and restart the automation.
- Abort or pause the automated operation. Investigate the reason for the stuck application, and restart the automation.
- After a suitably long wait, `DELETE` the pod instead of using the eviction API.
Kubernetes does not specify what the behavior should be in this case; it is up to the
docs/tasks/administer-cluster/securing-a-cluster.md
+12 -4
View File
@@ -73,11 +73,9 @@ Consult the [authorization reference section](/docs/admin/authorization/) for mo
## Controlling access to the Kubelet
Kubelets expose HTTPS endpoints which give access to data of varying sensitivity, and allow performing operations with varying levels of power on the node and within containers.
Kubelets expose HTTPS endpoints which grant powerful control over the node and containers. By default Kubelets allow unauthenticated access to this API.
By default, Kubelets allow full access to those endpoints.
To secure access to those endpoints, enable Kubelet authentication and authorization.
Production clusters should enable Kubelet authentication and authorization.
Consult the [Kubelet authentication/authorization reference](/docs/admin/kubelet-authentication-authorization) for more information.
@@ -130,6 +128,16 @@ Additional protections may be available that control network rules on a per plug
environment basis, such as per-node firewalls, physically separating cluster nodes to
prevent cross talk, or advanced networking policy.
### Restricting cloud metadata API access
Cloud platforms (AWS, Azure, GCE, etc.) often expose metadata services locally to instances.
By default these APIs are accessible by pods running on an instance and can contain cloud
credentials for that node, or provisioning data such as kubelet credentials. These credentials
can be used to escalate within the cluster or to other cloud services under the same account.
When running Kubernetes on a cloud platform limit permissions given to instance credentials, use
[network policies](/docs/tasks/administer-cluster/declare-network-policy/) to restrict pod access
to the metadata API, and avoid using provisioning data to deliver secrets.
### Controlling which nodes pods may access
docs/tasks/administer-federation/configmap.md
+2 -2
View File
@@ -7,7 +7,7 @@ title: Federated ConfigMap
This guide explains how to use ConfigMaps in a Federation control plane.
Federated ConfigMaps are very similar to the traditional [Kubernetes
ConfigMaps](/docs/tasks/configure-pod-container/configmap/) and provide the same functionality.
ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/) and provide the same functionality.
Creating them in the federation control plane ensures that they are synchronized
across all the clusters in federation.
@@ -18,7 +18,7 @@ across all the clusters in federation.
* {% include federated-task-tutorial-prereqs.md %}
* You should also have a basic
[working knowledge of Kubernetes](/docs/setup/pick-right-solution/) in
general and [ConfigMaps](/docs/tasks/configure-pod-container/configmap/) in particular.
general and [ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/) in particular.
{% endcapture %}
docs/tasks/administer-federation/replicaset.md
+30 -4
View File
@@ -60,11 +60,37 @@ By default, replicas are spread equally in all the underlying clusters. For exam
if you have 3 registered clusters and you create a federated ReplicaSet with
`spec.replicas = 9`, then each ReplicaSet in the 3 clusters will have
`spec.replicas=3`.
To modify the number of replicas in each cluster, you can specify
[FederatedReplicaSetPreference](https://github.com/kubernetes/federation/blob/{{page.githubbranch}}/apis/federation/types.go)
as an annotation with key `federation.kubernetes.io/replica-set-preferences`
on the federated ReplicaSet.
To modify the number of replicas in each cluster, you can add an annotation with
key `federation.kubernetes.io/replica-set-preferences` to the federated ReplicaSet.
The value of the annoation is a serialized JSON that contains fields shown in
the following example:
```
{
"rebalance": true,
"clusters": {
"foo": {
"minReplicas": 10,
"maxReplicas": 50,
"weight": 100
},
"bar": {
"minReplicas": 10,
"maxReplicas": 100,
"weight": 200
}
}
}
```
The `rebalance` boolean field specifies whether replicas already scheduled and running
may be moved in order to match current state to the specified preferences.
The `clusters` object field contains a map where users can specify the constraints
for replica placement across the clusters (`foo` and `bar` in the example).
For each cluster, you can specify the minimum number of replicas that should be
assigned to it (default is zero), the maximum number of replicas the cluster can
accept (default is unbounded) and a number expressing the relative weight of
preferences to place additional replicas to that cluster.
## Updating a Federated ReplicaSet
docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md
+3 -3
View File
@@ -85,9 +85,9 @@ unless the Pod's grace period expires. For more details, see
### Reference
* [Lifecycle](/docs/resources-reference/{{page.version}}/#lifecycle-v1-core)
* [Container](/docs/resources-reference/{{page.version}}/#container-v1-core)
* See `terminationGracePeriodSeconds` in [PodSpec](/docs/resources-reference/{{page.version}}/#podspec-v1-core)
* [Lifecycle](/docs/api-reference/{{page.version}}/#lifecycle-v1-core)
* [Container](/docs/api-reference/{{page.version}}/#container-v1-core)
* See `terminationGracePeriodSeconds` in [PodSpec](/docs/api-reference/{{page.version}}/#podspec-v1-core)
{% endcapture %}
docs/tasks/configure-pod-container/configmap.md
-258
View File
@@ -1,258 +0,0 @@
---
approvers:
- eparis
- pmorie
title: Configure Containers Using a ConfigMap
---
{% capture overview %}
This page shows you how to configure an application using a ConfigMap. ConfigMaps allow you to decouple configuration artifacts from image content to keep containerized applications portable.
{% endcapture %}
{% capture prerequisites %}
* {% include task-tutorial-prereqs.md %}
{% endcapture %}
{% capture steps %}
## Use kubectl to create a ConfigMap
Use the `kubectl create configmap` command to create configmaps from [directories](#create-configmaps-from-directories), [files](#create-configmaps-from-files), or [literal values](#create-configmaps-from-literal-values):
```shell
kubectl create configmap <map-name> <data-source>
```
where \<map-name> is the name you want to assign to the ConfigMap and \<data-source> is the directory, file, or literal value to draw the data from.
The data source corresponds to a key-value pair in the ConfigMap, where
* key = the file name or the key you provided on the command line, and
* value = the file contents or the literal value you provided on the command line.
You can use [`kubectl describe`](/docs/user-guide/kubectl/{{page.version}}/#describe) or
[`kubectl get`](/docs/user-guide/kubectl/{{page.version}}/#get) to retrieve information
about a ConfigMap.
### Create ConfigMaps from directories
You can use `kubectl create configmap` to create a ConfigMap from multiple files in the same directory.
For example:
```shell
kubectl create configmap game-config --from-file=docs/user-guide/configmap/kubectl
```
combines the contents of the `docs/user-guide/configmap/kubectl/` directory
```shell
ls docs/user-guide/configmap/kubectl/
game.properties
ui.properties
```
into the following ConfigMap:
```shell
kubectl describe configmaps game-config
Name: game-config
Namespace: default
Labels: <none>
Annotations: <none>
Data
====
game.properties: 158 bytes
ui.properties: 83 bytes
```
The `game.properties` and `ui.properties` files in the `docs/user-guide/configmap/kubectl/` directory are represented in the `data` section of the ConfigMap.
```shell
kubectl get configmaps game-config -o yaml
```
```yaml
apiVersion: v1
data:
game.properties: |
enemies=aliens
lives=3
enemies.cheat=true
enemies.cheat.level=noGoodRotten
secret.code.passphrase=UUDDLRLRBABAS
secret.code.allowed=true
secret.code.lives=30
ui.properties: |
color.good=purple
color.bad=yellow
allow.textmode=true
how.nice.to.look=fairlyNice
kind: ConfigMap
metadata:
creationTimestamp: 2016-02-18T18:52:05Z
name: game-config
namespace: default
resourceVersion: "516"
selfLink: /api/v1/namespaces/default/configmaps/game-config-2
uid: b4952dc3-d670-11e5-8cd0-68f728db1985
```
### Create ConfigMaps from files
You can use `kubectl create configmap` to create a ConfigMap from an individual file, or from multiple files.
For example,
```shell
kubectl create configmap game-config-2 --from-file=docs/user-guide/configmap/kubectl/game.properties
```
would produce the following ConfigMap:
```shell
kubectl describe configmaps game-config-2
Name: game-config-2
Namespace: default
Labels: <none>
Annotations: <none>
Data
====
game.properties: 158 bytes
```
You can pass in the `--from-file` argument multiple times to create a ConfigMap from multiple data sources.
```shell
kubectl create configmap game-config-2 --from-file=docs/user-guide/configmap/kubectl/game.properties --from-file=docs/user-guide/configmap/kubectl/ui.properties
```
```shell
kubectl describe configmaps game-config-2
Name: game-config-2
Namespace: default
Labels: <none>
Annotations: <none>
Data
====
game.properties: 158 bytes
ui.properties: 83 bytes
```
#### Define the key to use when creating a ConfigMap from a file
You can define a key other than the file name to use in the `data` section of your ConfigMap when using the `--from-file` argument:
```shell
kubectl create configmap game-config-3 --from-file=<my-key-name>=<path-to-file>
```
where `<my-key-name>` is the key you want to use in the ConfigMap and `<path-to-file>` is the location of the data source file you want the key to represent.
For example:
```shell
kubectl create configmap game-config-3 --from-file=game-special-key=docs/user-guide/configmap/kubectl/game.properties
kubectl get configmaps game-config-3 -o yaml
```
```yaml
apiVersion: v1
data:
game-special-key: |
enemies=aliens
lives=3
enemies.cheat=true
enemies.cheat.level=noGoodRotten
secret.code.passphrase=UUDDLRLRBABAS
secret.code.allowed=true
secret.code.lives=30
kind: ConfigMap
metadata:
creationTimestamp: 2016-02-18T18:54:22Z
name: game-config-3
namespace: default
resourceVersion: "530"
selfLink: /api/v1/namespaces/default/configmaps/game-config-3
uid: 05f8da22-d671-11e5-8cd0-68f728db1985
```
### Create ConfigMaps from literal values
You can use `kubectl create configmap` with the `--from-literal` argument to define a literal value from the command line:
```shell
kubectl create configmap special-config --from-literal=special.how=very --from-literal=special.type=charm
```
You can pass in multiple key-value pairs. Each pair provided on the command line is represented as a separate entry in the `data` section of the ConfigMap.
```shell
kubectl get configmaps special-config -o yaml
```
```yaml
apiVersion: v1
data:
special.how: very
special.type: charm
kind: ConfigMap
metadata:
creationTimestamp: 2016-02-18T19:14:38Z
name: special-config
namespace: default
resourceVersion: "651"
selfLink: /api/v1/namespaces/default/configmaps/special-config
uid: dadce046-d673-11e5-8cd0-68f728db1985
```
{% endcapture %}
{% capture discussion %}
## Understanding ConfigMaps
ConfigMaps allow you to decouple configuration artifacts from image content to keep containerized applications portable.
The ConfigMap API resource stores configuration data as key-value pairs. The data can be consumed in pods or provide the configurations for system components such as controllers. ConfigMap is similar to [Secrets](/docs/concepts/configuration/secret/), but provides a means of working with strings that don't contain sensitive information. Users and system components alike can store configuration data in ConfigMap.
**Note:** ConfigMaps should reference properties files, not replace them. Think of the ConfigMap as representing something similar to the Linux `/etc` directory and its contents. For example, if you create a [Kubernetes Volume](/docs/concepts/storage/volumes/) from a ConfigMap, each data item in the ConfigMap is represented by an individual file in the volume.
{: .note}
The ConfigMap's `data` field contains the configuration data. As shown in the example below, this can be simple -- like individual properties defined using `--from-literal` -- or complex -- like configuration files or JSON blobs defined using `--from-file`.
```yaml
kind: ConfigMap
apiVersion: v1
metadata:
creationTimestamp: 2016-02-18T19:14:38Z
name: example-config
namespace: default
data:
# example of a simple property defined using --from-literal
example.property.1: hello
example.property.2: world
# example of a complex property defined using --from-file
example.property.file: |-
property.1=value-1
property.2=value-2
property.3=value-3
```
{% endcapture %}
{% capture whatsnext %}
* See [Using ConfigMap Data in Pods](/docs/tasks/configure-pod-container/configure-pod-configmap).
* Follow a real world example of [Configuring Redis using a ConfigMap](/docs/tutorials/configuration/configure-redis-using-configmap/).
{% endcapture %}
{% include templates/task.md %}
docs/tasks/configure-pod-container/configure-liveness-readiness-probes.md
+6 -6
View File
@@ -34,7 +34,7 @@ broken states, and cannot recover except by being restarted. Kubernetes provides
liveness probes to detect and remedy such situations.
In this exercise, you create a Pod that runs a Container based on the
`gcr.io/google_containers/busybox` image. Here is the configuration file for the Pod:
`k8s.gcr.io/busybox` image. Here is the configuration file for the Pod:
{% include code.html language="yaml" file="exec-liveness.yaml" ghlink="/docs/tasks/configure-pod-container/exec-liveness.yaml" %}
@@ -75,8 +75,8 @@ The output indicates that no liveness probes have failed yet:
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
24s 24s 1 {default-scheduler } Normal Scheduled Successfully assigned liveness-exec to worker0
23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Pulling pulling image "gcr.io/google_containers/busybox"
23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Pulled Successfully pulled image "gcr.io/google_containers/busybox"
23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Pulling pulling image "k8s.gcr.io/busybox"
23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Pulled Successfully pulled image "k8s.gcr.io/busybox"
23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Created Created container with docker id 86849c15382e; Security:[seccomp=unconfined]
23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Started Started container with docker id 86849c15382e
```
@@ -94,8 +94,8 @@ probes have failed, and the containers have been killed and recreated.
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
37s 37s 1 {default-scheduler } Normal Scheduled Successfully assigned liveness-exec to worker0
36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Pulling pulling image "gcr.io/google_containers/busybox"
36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Pulled Successfully pulled image "gcr.io/google_containers/busybox"
36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Pulling pulling image "k8s.gcr.io/busybox"
36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Pulled Successfully pulled image "k8s.gcr.io/busybox"
36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Created Created container with docker id 86849c15382e; Security:[seccomp=unconfined]
36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Started Started container with docker id 86849c15382e
2s 2s 1 {kubelet worker0} spec.containers{liveness} Warning Unhealthy Liveness probe failed: cat: can't open '/tmp/healthy': No such file or directory
@@ -117,7 +117,7 @@ liveness-exec 1/1 Running 1 1m
## Define a liveness HTTP request
Another kind of liveness probe uses an HTTP GET request. Here is the configuration
file for a Pod that runs a container based on the `gcr.io/google_containers/liveness`
file for a Pod that runs a container based on the `k8s.gcr.io/liveness`
image.
{% include code.html language="yaml" file="http-liveness.yaml" ghlink="/docs/tasks/configure-pod-container/http-liveness.yaml" %}
docs/tasks/configure-pod-container/configure-persistent-volume-storage.md
+4 -4
View File
@@ -200,10 +200,10 @@ PersistentVolume are not present on the Pod resource itself.
### Reference
* [PersistentVolume](/docs/resources-reference/{{page.version}}/#persistentvolume-v1-core)
* [PersistentVolumeSpec](/docs/resources-reference/{{page.version}}/#persistentvolumespec-v1-core)
* [PersistentVolumeClaim](/docs/resources-reference/{{page.version}}/#persistentvolumeclaim-v1-core)
* [PersistentVolumeClaimSpec](/docs/resources-reference/{{page.version}}/#persistentvolumeclaimspec-v1-core)
* [PersistentVolume](/docs/api-reference/{{page.version}}/#persistentvolume-v1-core)
* [PersistentVolumeSpec](/docs/api-reference/{{page.version}}/#persistentvolumespec-v1-core)
* [PersistentVolumeClaim](/docs/api-reference/{{page.version}}/#persistentvolumeclaim-v1-core)
* [PersistentVolumeClaimSpec](/docs/api-reference/{{page.version}}/#persistentvolumeclaimspec-v1-core)
{% endcapture %}
docs/tasks/configure-pod-container/configure-pod-configmap.md
+235 -14
View File
@@ -1,19 +1,217 @@
---
title: Use ConfigMap Data in Pods
title: Configure a Pod to Use a ConfigMap
---
{% capture overview %}
This page provides a series of usage examples demonstrating how to configure Pods using data stored in ConfigMaps.
ConfigMaps allow you to decouple configuration artifacts from image content to keep containerized applications portable. This page provides a series of usage examples demonstrating how to create ConfigMaps and configure Pods using data stored in ConfigMaps.
{% endcapture %}
{% capture prerequisites %}
* {% include task-tutorial-prereqs.md %}
* [Create a ConfigMap](/docs/tasks/configure-pod-container/configmap/)
{% include task-tutorial-prereqs.md %}
{% endcapture %}
{% capture steps %}
## Create a ConfigMap
Use the `kubectl create configmap` command to create configmaps from [directories](#create-configmaps-from-directories), [files](#create-configmaps-from-files), or [literal values](#create-configmaps-from-literal-values):
```shell
kubectl create configmap <map-name> <data-source>
```
where \<map-name> is the name you want to assign to the ConfigMap and \<data-source> is the directory, file, or literal value to draw the data from.
The data source corresponds to a key-value pair in the ConfigMap, where
* key = the file name or the key you provided on the command line, and
* value = the file contents or the literal value you provided on the command line.
You can use [`kubectl describe`](/docs/user-guide/kubectl/{{page.version}}/#describe) or
[`kubectl get`](/docs/user-guide/kubectl/{{page.version}}/#get) to retrieve information
about a ConfigMap.
### Create ConfigMaps from directories
You can use `kubectl create configmap` to create a ConfigMap from multiple files in the same directory.
For example:
```shell
kubectl create configmap game-config --from-file=docs/user-guide/configmap/kubectl
```
combines the contents of the `docs/user-guide/configmap/kubectl/` directory
```shell
ls docs/user-guide/configmap/kubectl/
game.properties
ui.properties
```
into the following ConfigMap:
```shell
kubectl describe configmaps game-config
Name: game-config
Namespace: default
Labels: <none>
Annotations: <none>
Data
====
game.properties: 158 bytes
ui.properties: 83 bytes
```
The `game.properties` and `ui.properties` files in the `docs/user-guide/configmap/kubectl/` directory are represented in the `data` section of the ConfigMap.
```shell
kubectl get configmaps game-config -o yaml
```
```yaml
apiVersion: v1
data:
game.properties: |
enemies=aliens
lives=3
enemies.cheat=true
enemies.cheat.level=noGoodRotten
secret.code.passphrase=UUDDLRLRBABAS
secret.code.allowed=true
secret.code.lives=30
ui.properties: |
color.good=purple
color.bad=yellow
allow.textmode=true
how.nice.to.look=fairlyNice
kind: ConfigMap
metadata:
creationTimestamp: 2016-02-18T18:52:05Z
name: game-config
namespace: default
resourceVersion: "516"
selfLink: /api/v1/namespaces/default/configmaps/game-config
uid: b4952dc3-d670-11e5-8cd0-68f728db1985
```
### Create ConfigMaps from files
You can use `kubectl create configmap` to create a ConfigMap from an individual file, or from multiple files.
For example,
```shell
kubectl create configmap game-config-2 --from-file=docs/user-guide/configmap/kubectl/game.properties
```
would produce the following ConfigMap:
```shell
kubectl describe configmaps game-config-2
Name: game-config-2
Namespace: default
Labels: <none>
Annotations: <none>
Data
====
game.properties: 158 bytes
```
You can pass in the `--from-file` argument multiple times to create a ConfigMap from multiple data sources.
```shell
kubectl create configmap game-config-2 --from-file=docs/user-guide/configmap/kubectl/game.properties --from-file=docs/user-guide/configmap/kubectl/ui.properties
```
```shell
kubectl describe configmaps game-config-2
Name: game-config-2
Namespace: default
Labels: <none>
Annotations: <none>
Data
====
game.properties: 158 bytes
ui.properties: 83 bytes
```
#### Define the key to use when creating a ConfigMap from a file
You can define a key other than the file name to use in the `data` section of your ConfigMap when using the `--from-file` argument:
```shell
kubectl create configmap game-config-3 --from-file=<my-key-name>=<path-to-file>
```
where `<my-key-name>` is the key you want to use in the ConfigMap and `<path-to-file>` is the location of the data source file you want the key to represent.
For example:
```shell
kubectl create configmap game-config-3 --from-file=game-special-key=docs/user-guide/configmap/kubectl/game.properties
kubectl get configmaps game-config-3 -o yaml
```
```yaml
apiVersion: v1
data:
game-special-key: |
enemies=aliens
lives=3
enemies.cheat=true
enemies.cheat.level=noGoodRotten
secret.code.passphrase=UUDDLRLRBABAS
secret.code.allowed=true
secret.code.lives=30
kind: ConfigMap
metadata:
creationTimestamp: 2016-02-18T18:54:22Z
name: game-config-3
namespace: default
resourceVersion: "530"
selfLink: /api/v1/namespaces/default/configmaps/game-config-3
uid: 05f8da22-d671-11e5-8cd0-68f728db1985
```
### Create ConfigMaps from literal values
You can use `kubectl create configmap` with the `--from-literal` argument to define a literal value from the command line:
```shell
kubectl create configmap special-config --from-literal=special.how=very --from-literal=special.type=charm
```
You can pass in multiple key-value pairs. Each pair provided on the command line is represented as a separate entry in the `data` section of the ConfigMap.
```shell
kubectl get configmaps special-config -o yaml
```
```yaml
apiVersion: v1
data:
special.how: very
special.type: charm
kind: ConfigMap
metadata:
creationTimestamp: 2016-02-18T19:14:38Z
name: special-config
namespace: default
resourceVersion: "651"
selfLink: /api/v1/namespaces/default/configmaps/special-config
uid: dadce046-d673-11e5-8cd0-68f728db1985
```
## Define Pod environment variables using ConfigMap data
### Define a Pod environment variable with data from a single ConfigMap
@@ -38,7 +236,7 @@ This page provides a series of usage examples demonstrating how to configure Pod
spec:
containers:
- name: test-container
image: gcr.io/google_containers/busybox
image: k8s.gcr.io/busybox
command: [ "/bin/sh", "-c", "env" ]
env:
# Define the environment variable
@@ -88,7 +286,7 @@ This page provides a series of usage examples demonstrating how to configure Pod
spec:
containers:
- name: test-container
image: gcr.io/google_containers/busybox
image: k8s.gcr.io/busybox
command: [ "/bin/sh", "-c", "env" ]
env:
- name: SPECIAL_LEVEL_KEY
@@ -134,7 +332,7 @@ This page provides a series of usage examples demonstrating how to configure Pod
spec:
containers:
- name: test-container
image: gcr.io/google_containers/busybox
image: k8s.gcr.io/busybox
command: [ "/bin/sh", "-c", "env" ]
envFrom:
- configMapRef:
@@ -161,7 +359,7 @@ metadata:
spec:
containers:
- name: test-container
image: gcr.io/google_containers/busybox
image: k8s.gcr.io/busybox
command: [ "/bin/sh", "-c", "echo $(SPECIAL_LEVEL_KEY) $(SPECIAL_TYPE_KEY)" ]
env:
- name: SPECIAL_LEVEL_KEY
@@ -185,7 +383,7 @@ very charm
## Add ConfigMap data to a Volume
As explained in [Configure Containers Using a ConfigMap](/docs/tasks/configure-pod-container/configmap/), when you create a ConfigMap using ``--from-file``, the filename becomes a key stored in the `data` section of the ConfigMap. The file contents become the key's value.
As explained in [Create ConfigMaps from files](#create-configmaps-from-files), when you create a ConfigMap using ``--from-file``, the filename becomes a key stored in the `data` section of the ConfigMap. The file contents become the key's value.
The examples in this section refer to a ConfigMap named special-config, shown below.
@@ -214,7 +412,7 @@ metadata:
spec:
containers:
- name: test-container
image: gcr.io/google_containers/busybox
image: k8s.gcr.io/busybox
command: [ "/bin/sh", "-c", "ls /etc/config/" ]
volumeMounts:
- name: config-volume
@@ -248,7 +446,7 @@ metadata:
spec:
containers:
- name: test-container
image: gcr.io/google_containers/busybox
image: k8s.gcr.io/busybox
command: [ "/bin/sh","-c","cat /etc/config/keys" ]
volumeMounts:
- name: config-volume
@@ -284,6 +482,31 @@ When a ConfigMap already being consumed in a volume is updated, projected keys a
## Understanding ConfigMaps and Pods
The ConfigMap API resource stores configuration data as key-value pairs. The data can be consumed in pods or provide the configurations for system components such as controllers. ConfigMap is similar to [Secrets](/docs/concepts/configuration/secret/), but provides a means of working with strings that don't contain sensitive information. Users and system components alike can store configuration data in ConfigMap.
**Note:** ConfigMaps should reference properties files, not replace them. Think of the ConfigMap as representing something similar to the Linux `/etc` directory and its contents. For example, if you create a [Kubernetes Volume](/docs/concepts/storage/volumes/) from a ConfigMap, each data item in the ConfigMap is represented by an individual file in the volume.
{: .note}
The ConfigMap's `data` field contains the configuration data. As shown in the example below, this can be simple -- like individual properties defined using `--from-literal` -- or complex -- like configuration files or JSON blobs defined using `--from-file`.
```yaml
kind: ConfigMap
apiVersion: v1
metadata:
creationTimestamp: 2016-02-18T19:14:38Z
name: example-config
namespace: default
data:
# example of a simple property defined using --from-literal
example.property.1: hello
example.property.2: world
# example of a complex property defined using --from-file
example.property.file: |-
property.1=value-1
property.2=value-2
property.3=value-3
```
### Restrictions
1. You must create a ConfigMap before referencing it in a Pod specification (unless you mark the ConfigMap as "optional"). If you reference a ConfigMap that doesn't exist, the Pod won't start. Likewise, references to keys that don't exist in the ConfigMap will prevent the pod from starting.
@@ -299,8 +522,7 @@ When a ConfigMap already being consumed in a volume is updated, projected keys a
1. ConfigMaps reside in a specific [namespace](/docs/concepts/overview/working-with-objects/namespaces/). A ConfigMap can only be referenced by pods residing in the same namespace.
1. Kubelet doesn't support the use of ConfigMaps for pods not found on the API server.
This includes every pod created using kubectl or indirectly via a replication controller.
It does not include pods created via the Kubelet's `--manifest-url` flag, `--config` flag, or the Kubelet REST API.
This includes pods created via the Kubelet's --manifest-url flag, --config flag, or the Kubelet REST API.
**Note:** These are not commonly-used ways to create pods.
{: .note}
@@ -308,7 +530,6 @@ When a ConfigMap already being consumed in a volume is updated, projected keys a
{% endcapture %}
{% capture whatsnext %}
* Learn more about [ConfigMaps](/docs/tasks/configure-pod-container/configmap/).
* Follow a real world example of [Configuring Redis using a ConfigMap](/docs/tutorials/configuration/configure-redis-using-configmap/).
{% endcapture %}
docs/tasks/configure-pod-container/exec-liveness.yaml
+1 -1
View File
@@ -7,7 +7,7 @@ metadata:
spec:
containers:
- name: liveness
image: gcr.io/google_containers/busybox
image: k8s.gcr.io/busybox
args:
- /bin/sh
- -c
docs/tasks/configure-pod-container/extended-resource-pod-2.yaml
+2
View File
@@ -9,3 +9,5 @@ spec:
resources:
requests:
example.com/dongle: 2
limits:
example.com/dongle: 2
docs/tasks/configure-pod-container/extended-resource-pod.yaml
+2
View File
@@ -9,3 +9,5 @@ spec:
resources:
requests:
example.com/dongle: 3
limits:
example.com/dongle: 3
docs/tasks/configure-pod-container/extended-resource.md
+2
View File
@@ -59,6 +59,8 @@ kubectl describe pod extended-resource-demo
The output shows dongle requests:
```yaml
Limits:
example.com/dongle: 3
Requests:
example.com/dongle: 3
```
docs/tasks/configure-pod-container/http-liveness.yaml
+1 -1
View File
@@ -7,7 +7,7 @@ metadata:
spec:
containers:
- name: liveness
image: gcr.io/google_containers/liveness
image: k8s.gcr.io/liveness
args:
- /server
livenessProbe:
docs/tasks/configure-pod-container/tcp-liveness-readiness.yaml
+1 -1
View File
@@ -7,7 +7,7 @@ metadata:
spec:
containers:
- name: goproxy
image: gcr.io/google_containers/goproxy:0.1
image: k8s.gcr.io/goproxy:0.1
ports:
- containerPort: 8080
readinessProbe:
docs/tasks/debug-application-cluster/debug-service.md
+2 -2
View File
@@ -66,7 +66,7 @@ probably debugging your own `Service` you can substitute your own details, or yo
can follow along and get a second data point.
```shell
$ kubectl run hostnames --image=gcr.io/google_containers/serve_hostname \
$ kubectl run hostnames --image=k8s.gcr.io/serve_hostname \
--labels=app=hostnames \
--port=9376 \
--replicas=3
@@ -93,7 +93,7 @@ spec:
spec:
containers:
- name: hostnames
image: gcr.io/google_containers/serve_hostname
image: k8s.gcr.io/serve_hostname
ports:
- containerPort: 9376
protocol: TCP
docs/tasks/debug-application-cluster/event-exporter-deploy.yaml
+1 -2
View File
@@ -10,7 +10,6 @@ apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: event-exporter-rb
namespace: default
labels:
app: event-exporter
roleRef:
@@ -42,4 +41,4 @@ spec:
image: gcr.io/google-containers/event-exporter:v0.1.0
command:
- '/event-exporter'
terminationGracePeriodSeconds: 30
terminationGracePeriodSeconds: 30
docs/tasks/debug-application-cluster/monitor-node-health.md
+3 -3
View File
@@ -77,7 +77,7 @@ spec:
hostNetwork: true
containers:
- name: node-problem-detector
image: gcr.io/google_containers/node-problem-detector:v0.1
image: k8s.gcr.io/node-problem-detector:v0.1
securityContext:
privileged: true
resources:
@@ -120,7 +120,7 @@ Just create `node-problem-detector.yaml`, and put it under the addon pods direct
The [default configuration](https://github.com/kubernetes/node-problem-detector/tree/v0.1/config)
is embedded when building the docker image of node problem detector.
However, you can use [ConfigMap](/docs/tasks/configure-pod-container/configmap/) to overwrite it
However, you can use [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) to overwrite it
following the steps:
* **Step 1:** Change the config files in `config/`.
@@ -149,7 +149,7 @@ spec:
hostNetwork: true
containers:
- name: node-problem-detector
image: gcr.io/google_containers/node-problem-detector:v0.1
image: k8s.gcr.io/node-problem-detector:v0.1
securityContext:
privileged: true
resources:
docs/tasks/federation/federation-service-discovery.md
+2 -1
View File
@@ -109,6 +109,7 @@ $kubectl --context=federation-cluster describe services nginx
Name: nginx
Namespace: default
Labels: run=nginx
Annotations: <none>
Selector: run=nginx
Type: LoadBalancer
IP: 10.63.250.98
@@ -116,7 +117,7 @@ LoadBalancer Ingress: 104.197.246.190, 130.211.57.243, 104.196.14.231, 104.199
Port: http 80/TCP
Endpoints: <none>
Session Affinity: None
No events.
Events: <none>
```
Note the 'LoadBalancer Ingress' addresses of your Federated Service
docs/tasks/inject-data-application/dapi-envars-container.yaml
+1 -1
View File
@@ -5,7 +5,7 @@ metadata:
spec:
containers:
- name: test-container
image: gcr.io/google_containers/busybox:1.24
image: k8s.gcr.io/busybox:1.24
command: [ "sh", "-c"]
args:
- while true; do
docs/tasks/inject-data-application/dapi-envars-pod.yaml
+1 -1
View File
@@ -5,7 +5,7 @@ metadata:
spec:
containers:
- name: test-container
image: gcr.io/google_containers/busybox
image: k8s.gcr.io/busybox
command: [ "sh", "-c"]
args:
- while true; do
docs/tasks/inject-data-application/dapi-volume-resources.yaml
+1 -1
View File
@@ -5,7 +5,7 @@ metadata:
spec:
containers:
- name: client-container
image: gcr.io/google_containers/busybox:1.24
image: k8s.gcr.io/busybox:1.24
command: ["sh", "-c"]
args:
- while true; do
docs/tasks/inject-data-application/dapi-volume.yaml
+1 -1
View File
@@ -12,7 +12,7 @@ metadata:
spec:
containers:
- name: client-container
image: gcr.io/google_containers/busybox
image: k8s.gcr.io/busybox
command: ["sh", "-c"]
args:
- while true; do
docs/tasks/inject-data-application/define-command-argument-container.md
+1 -1
View File
@@ -73,7 +73,7 @@ you can define arguments by using environment variables:
This means you can define an argument for a Pod using any of
the techniques available for defining environment variables, including
[ConfigMaps](/docs/tasks/configure-pod-container/configmap/)
[ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/)
and
[Secrets](/docs/concepts/configuration/secret/).
docs/tasks/inject-data-application/define-environment-variable-container.md
+1
View File
@@ -60,6 +60,7 @@ Pod:
HOSTNAME=envar-demo
...
DEMO_GREETING=Hello from the environment
DEMO_FAREWELL=Such a sweet sorrow
1. To exit the shell, enter `exit`.
docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md
+6 -6
View File
@@ -40,7 +40,7 @@ In the configuration file, you can see that the Pod has a `downwardAPI` Volume,
and the Container mounts the Volume at `/etc`.
Look at the `items` array under `downwardAPI`. Each element of the array is a
[DownwardAPIVolumeFile](/docs/resources-reference/{{page.version}}/#downwardapivolumefile-v1-core).
[DownwardAPIVolumeFile](/docs/api-reference/{{page.version}}/#downwardapivolumefile-v1-core).
The first element specifies that the value of the Pod's
`metadata.labels` field should be stored in a file named `labels`.
The second element specifies that the value of the Pod's `annotations`
@@ -234,11 +234,11 @@ inject the Pod's name into the well-known environment variable.
{% capture whatsnext %}
* [PodSpec](/docs/resources-reference/{{page.version}}/#podspec-v1-core)
* [Volume](/docs/resources-reference/{{page.version}}/#volume-v1-core)
* [DownwardAPIVolumeSource](/docs/resources-reference/{{page.version}}/#downwardapivolumesource-v1-core)
* [DownwardAPIVolumeFile](/docs/resources-reference/{{page.version}}/#downwardapivolumefile-v1-core)
* [ResourceFieldSelector](/docs/resources-reference/{{page.version}}/#resourcefieldselector-v1-core)
* [PodSpec](/docs/api-reference/{{page.version}}/#podspec-v1-core)
* [Volume](/docs/api-reference/{{page.version}}/#volume-v1-core)
* [DownwardAPIVolumeSource](/docs/api-reference/{{page.version}}/#downwardapivolumesource-v1-core)
* [DownwardAPIVolumeFile](/docs/api-reference/{{page.version}}/#downwardapivolumefile-v1-core)
* [ResourceFieldSelector](/docs/api-reference/{{page.version}}/#resourcefieldselector-v1-core)
{% endcapture %}
docs/tasks/inject-data-application/envars.yaml
+2
View File
@@ -11,3 +11,5 @@ spec:
env:
- name: DEMO_GREETING
value: "Hello from the environment"
- name: DEMO_FAREWELL
value: "Such a sweet sorrow"
docs/tasks/inject-data-application/environment-variable-expose-pod-information.md
+9 -9
View File
@@ -25,7 +25,7 @@ Pod fields and Container fields.
There are two ways to expose Pod and Container fields to a running Container:
* Environment variables
* [DownwardAPIVolumeFiles](/docs/resources-reference/{{page.version}}/#downwardapivolumefile-v1-core)
* [DownwardAPIVolumeFiles](/docs/api-reference/{{page.version}}/#downwardapivolumefile-v1-core)
Together, these two ways of exposing Pod and Container fields are called the
*Downward API*.
@@ -40,7 +40,7 @@ configuration file for the Pod:
In the configuration file, you can see five environment variables. The `env`
field is an array of
[EnvVars](/docs/resources-reference/{{page.version}}/#envvar-v1-core).
[EnvVars](/docs/api-reference/{{page.version}}/#envvar-v1-core).
The first element in the array specifies that the `MY_NODE_NAME` environment
variable gets its value from the Pod's `spec.nodeName` field. Similarly, the
other environment variables get their names from Pod fields.
@@ -118,7 +118,7 @@ container:
In the configuration file, you can see four environment variables. The `env`
field is an array of
[EnvVars](/docs/resources-reference/{{page.version}}/#envvar-v1-core).
[EnvVars](/docs/api-reference/{{page.version}}/#envvar-v1-core).
The first element in the array specifies that the `MY_CPU_REQUEST` environment
variable gets its value from the `requests.cpu` field of a Container named
`test-container`. Similarly, the other environment variables get their values
@@ -156,12 +156,12 @@ The output shows the values of selected environment variables:
{% capture whatsnext %}
* [Defining Environment Variables for a Container](/docs/tasks/inject-data-application/define-environment-variable-container/)
* [PodSpec](/docs/resources-reference/{{page.version}}/#podspec-v1-core)
* [Container](/docs/resources-reference/{{page.version}}/#container-v1-core)
* [EnvVar](/docs/resources-reference/{{page.version}}/#envvar-v1-core)
* [EnvVarSource](/docs/resources-reference/{{page.version}}/#envvarsource-v1-core)
* [ObjectFieldSelector](/docs/resources-reference/{{page.version}}/#objectfieldselector-v1-core)
* [ResourceFieldSelector](/docs/resources-reference/{{page.version}}/#resourcefieldselector-v1-core)
* [PodSpec](/docs/api-reference/{{page.version}}/#podspec-v1-core)
* [Container](/docs/api-reference/{{page.version}}/#container-v1-core)
* [EnvVar](/docs/api-reference/{{page.version}}/#envvar-v1-core)
* [EnvVarSource](/docs/api-reference/{{page.version}}/#envvarsource-v1-core)
* [ObjectFieldSelector](/docs/api-reference/{{page.version}}/#objectfieldselector-v1-core)
* [ResourceFieldSelector](/docs/api-reference/{{page.version}}/#resourcefieldselector-v1-core)
{% endcapture %}
docs/tasks/inject-data-application/podpreset-allow-db-merged.yaml
+1 -1
View File
@@ -28,7 +28,7 @@ spec:
value: $(REPLACE_ME)
envFrom:
- configMapRef:
name: etcd-env-config
name: etcd-env-config
volumes:
- name: cache-volume
emptyDir: {}
docs/tasks/inject-data-application/podpreset-allow-db.yaml
+1 -1
View File
@@ -8,7 +8,7 @@ spec:
role: frontend
env:
- name: DB_PORT
value: 6379
value: "6379"
- name: duplicate_key
value: FROM_ENV
- name: expansion
docs/tasks/inject-data-application/podpreset-conflict-pod.yaml
+1 -1
View File
@@ -13,7 +13,7 @@ spec:
- mountPath: /cache
name: cache-volume
ports:
- containerPort: 80
volumes:
- name: cache-volume
emptyDir: {}
- containerPort: 80
docs/tasks/inject-data-application/podpreset-replicaset-merged.yaml
+1
View File
@@ -1,6 +1,7 @@
apiVersion: v1
kind: Pod
metadata:
name: frontend
labels:
app: guestbook
tier: frontend
docs/tasks/manage-gpus/scheduling-gpus.md
+173 -116
View File
@@ -4,154 +4,211 @@ approvers:
title: Schedule GPUs
---
{% capture overview %}
Kubernetes includes **experimental** support for managing NVIDIA GPUs spread
across nodes. The support for NVIDIA GPUs was added in v1.6 and has gone through
multiple backwards incompatible iterations. This page describes how users can
consume GPUs across different Kubernetes versions and the current limitations.
Kubernetes includes **experimental** support for managing NVIDIA GPUs spread across nodes.
This page describes how users can consume GPUs and the current limitations.
## v1.6 and v1.7
To enable GPU support in 1.6 and 1.7, a special **alpha** feature gate
`Accelerators` has to be set to true across the system:
`--feature-gates="Accelerators=true"`. It also requires using the Docker
Engine as the container runtime.
{% endcapture %}
Further, the Kubernetes nodes have to be pre-installed with NVIDIA drivers.
Kubelet will not detect NVIDIA GPUs otherwise.
{% capture prerequisites %}
1. Kubernetes nodes have to be pre-installed with Nvidia drivers. Kubelet will not detect Nvidia GPUs otherwise. Try to re-install Nvidia drivers if kubelet fails to expose Nvidia GPUs as part of Node Capacity. After installing the driver, run `nvidia-docker-plugin` to confirm that all drivers have been loaded.
2. A special **alpha** feature gate `Accelerators` has to be set to true across the system: `--feature-gates="Accelerators=true"`.
3. Nodes must be using `docker engine` as the container runtime.
The nodes will automatically discover and expose all Nvidia GPUs as a schedulable resource.
{% endcapture %}
{% capture steps %}
## API
Nvidia GPUs can be consumed via container level resource requirements using the resource name `alpha.kubernetes.io/nvidia-gpu`.
```yaml
apiVersion: v1
kind: Pod
metadata:
name: gpu-pod
spec:
containers:
-
name: gpu-container-1
image: gcr.io/google_containers/pause:2.0
resources:
limits:
alpha.kubernetes.io/nvidia-gpu: 2 # requesting 2 GPUs
-
name: gpu-container-2
image: gcr.io/google_containers/pause:2.0
resources:
limits:
alpha.kubernetes.io/nvidia-gpu: 3 # requesting 3 GPUs
```
When you start Kubernetes components after all the above conditions are true,
Kubernetes will expose `alpha.kubernetes.io/nvidia-gpu` as a schedulable
resource.
You can consume these GPUs from your containers by requesting
`alpha.kubernetes.io/nvidia-gpu` just like you request `cpu` or `memory`.
However, there are some limitations in how you specify the resource requirements
when using GPUs:
- GPUs are only supposed to be specified in the `limits` section, which means:
* You can specify GPU `limits` without specifying `requests` because Kubernetes
will use the limit as the request value by default.
* You can specify GPU in both `limits` and `requests` but these two values must equal.
* You can specify GPU `limits` without specifying `requests` because
Kubernetes will use the limit as the request value by default.
* You can specify GPU in both `limits` and `requests` but these two values
must be equal.
* You cannot specify GPU `requests` without specifying `limits`.
- Containers (and pods) do not share GPUs.
- Each container can request one or more GPUs.
- It is not possible to request a portion of a GPU.
- Nodes are expected to be homogenous, i.e. run the same GPU hardware.
- Containers (and pods) do not share GPUs. There's no overcommitting of GPUs.
- Each container can request one or more GPUs. It is not possible to request a
fraction of a GPU.
If your nodes are running different versions of GPUs, then use Node Labels and Node Selectors to schedule pods to appropriate GPUs.
Following is an illustration of this workflow:
When using `alpha.kubernetes.io/nvidia-gpu` as the resource, you also have to
mount host directories containing NVIDIA libraries (libcuda.so, libnvidia.so
etc.) to the container.
As part of your Node bootstrapping, identify the GPU hardware type on your nodes and expose it as a node label.
```shell
NVIDIA_GPU_NAME=$(nvidia-smi --query-gpu=gpu_name --format=csv,noheader --id=0 | sed -e 's/ /-/g')
source /etc/default/kubelet
KUBELET_OPTS="$KUBELET_OPTS --node-labels='alpha.kubernetes.io/nvidia-gpu-name=$NVIDIA_GPU_NAME'"
echo "KUBELET_OPTS=$KUBELET_OPTS" > /etc/default/kubelet
```
Specify the GPU types a pod can use via [Node Affinity](/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity) rules.
Here's an example:
```yaml
kind: pod
apiVersion: v1
kind: Pod
metadata:
annotations:
scheduler.alpha.kubernetes.io/affinity: >
{
"nodeAffinity": {
"requiredDuringSchedulingIgnoredDuringExecution": {
"nodeSelectorTerms": [
{
"matchExpressions": [
{
"key": "alpha.kubernetes.io/nvidia-gpu-name",
"operator": "In",
"values": ["Tesla K80", "Tesla P100"]
}
]
}
]
}
}
}
name: cuda-vector-add
spec:
restartPolicy: OnFailure
containers:
-
name: gpu-container-1
- name: cuda-vector-add
# https://github.com/kubernetes/kubernetes/blob/v1.7.11/test/images/nvidia-cuda/Dockerfile
image: "k8s.gcr.io/cuda-vector-add:v0.1"
resources:
limits:
alpha.kubernetes.io/nvidia-gpu: 2
alpha.kubernetes.io/nvidia-gpu: 1 # requesting 1 GPU
volumeMounts:
- name: "nvidia-libraries"
mountPath: "/usr/local/nvidia/lib64"
volumes:
- name: "nvidia-libraries"
hostPath:
path: "/usr/lib/nvidia-375"
```
This will ensure that the pod will be scheduled to a node that has a `Tesla K80` or a `Tesla P100` Nvidia GPU.
The `Accelerators` feature gate and `alpha.kubernetes.io/nvidia-gpu` resource
works on 1.8 and 1.9 as well. It will be deprecated in 1.10 and removed in
1.11.
### Warning
## v1.8 onwards
The API presented here **will change** in an upcoming release to better support GPUs, and hardware accelerators in general, in Kubernetes.
**From 1.8 onwards, the recommended way to consume GPUs is to use [device
plugins](/docs/concepts/cluster-administration/device-plugins).**
## Access to CUDA libraries
To enable GPU support through device plugins, a special **alpha** feature gate
`DevicePlugins` has to be set to true across the system:
`--feature-gates="DevicePlugins=true"`.
As of now, CUDA libraries are expected to be pre-installed on the nodes.
Then you have to install NVIDIA drivers on the nodes and run an NVIDIA GPU device
plugin ([see below](#deploying-nvidia-gpu-device-plugin)).
To mitigate this, you can copy the libraries to a more permissive folder in ``/var/lib/`` or change the permissions directly. (Future releases will automatically perform this operation)
When the above conditions are true, Kubernetes will expose `nvidia.com/gpu` as
a schedulable resource.
Pods can access the libraries using `hostPath` volumes.
You can consume these GPUs from your containers by requesting
`nvidia.com/gpu` just like you request `cpu` or `memory`.
However, there are some limitations in how you specify the resource requirements
when using GPUs:
- GPUs are only supposed to be specified in the `limits` section, which means:
* You can specify GPU `limits` without specifying `requests` because
Kubernetes will use the limit as the request value by default.
* You can specify GPU in both `limits` and `requests` but these two values
must be equal.
* You cannot specify GPU `requests` without specifying `limits`.
- Containers (and pods) do not share GPUs. There's no overcommitting of GPUs.
- Each container can request one or more GPUs. It is not possible to request a
fraction of a GPU.
Unlike with `alpha.kubernetes.io/nvidia-gpu`, when using `nvidia.com/gpu` as
the resource, you don't have to mount any special directories in your pod
specs. The device plugin is expected to inject them automatically in the
container.
Here's an example:
```yaml
kind: Pod
apiVersion: v1
kind: Pod
metadata:
name: gpu-pod
name: cuda-vector-add
spec:
restartPolicy: OnFailure
containers:
- name: gpu-container-1
image: gcr.io/google_containers/pause:2.0
resources:
limits:
alpha.kubernetes.io/nvidia-gpu: 1
volumeMounts:
- mountPath: /usr/local/nvidia/bin
name: bin
- mountPath: /usr/lib/nvidia
name: lib
volumes:
- hostPath:
path: /usr/lib/nvidia-375/bin
name: bin
- hostPath:
path: /usr/lib/nvidia-375
name: lib
- name: cuda-vector-add
# https://github.com/kubernetes/kubernetes/blob/v1.7.11/test/images/nvidia-cuda/Dockerfile
image: "k8s.gcr.io/cuda-vector-add:v0.1"
resources:
limits:
nvidia.com/gpu: 1 # requesting 1 GPU
```
## Future
### Deploying NVIDIA GPU device plugin
- Support for hardware accelerators is in its early stages in Kubernetes.
- GPUs and other accelerators will soon be a native compute resource across the system.
There are currently two device plugin implementations for NVIDIA GPUs:
#### Official NVIDIA GPU device plugin
The [official NVIDIA GPU device plugin](https://github.com/NVIDIA/k8s-device-plugin)
has the following requirements:
- Kubernetes nodes have to be pre-installed with NVIDIA drivers.
- Kubernetes nodes have to be pre-installed with [nvidia-docker 2.0](https://github.com/NVIDIA/nvidia-docker)
- nvidia-container-runtime must be configured as the [default runtime](https://github.com/NVIDIA/k8s-device-plugin#preparing-your-gpu-nodes)
for docker instead of runc.
- NVIDIA drivers ~= 361.93
To deploy the NVIDIA device plugin once your cluster is running and the above
requirements are satisfied:
```
# For Kubernetes v1.8
kubectl create -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/v1.8/nvidia-device-plugin.yml
# For Kubernetes v1.9
kubectl create -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/v1.9/nvidia-device-plugin.yml
```
Report issues with this device plugin to [NVIDIA/k8s-device-plugin](https://github.com/NVIDIA/k8s-device-plugin).
#### NVIDIA GPU device plugin used by GKE/GCE
The [NVIDIA GPU device plugin used by GKE/GCE](https://github.com/GoogleCloudPlatform/container-engine-accelerators/tree/master/cmd/nvidia_gpu)
doesn't require using nvidia-docker and should work with any container runtime
that is compatible the Kubernetes Container Runtime Interface (CRI). It's tested
on [Container-Optimized OS](https://cloud.google.com/container-optimized-os/)
and has experimental code for Ubuntu from 1.9 onwards.
On your 1.9 cluster, you can use the following commands to install the NVIDIA drivers and device plugin:
```
# Install NVIDIA drivers on Container-Optimized OS:
kubectl create -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/k8s-1.9/daemonset.yaml
# Install NVIDIA drivers on Ubuntu (experimental):
kubectl create -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/k8s-1.9/nvidia-driver-installer/ubuntu/daemonset.yaml
# Install the device plugin:
kubectl create -f https://raw.githubusercontent.com/kubernetes/kubernetes/release-1.9/cluster/addons/device-plugins/nvidia-gpu/daemonset.yaml
```
Report issues with this device plugin and installation method to [GoogleCloudPlatform/container-engine-accelerators](https://github.com/GoogleCloudPlatform/container-engine-accelerators).
## Clusters containing different types of NVIDIA GPUs
If different nodes in your cluster have different types of NVIDIA GPUs, then you
can use [Node Labels and Node Selectors](/docs/tasks/configure-pod-container/assign-pods-nodes/)
to schedule pods to appropriate nodes.
For example:
```shell
# Label your nodes with the accelerator type they have.
kubectl label nodes <node-with-k80> accelerator=nvidia-tesla-k80
kubectl label nodes <node-with-p100> accelerator=nvidia-tesla-p100
```
Specify the GPU type in the pod spec:
```yaml
apiVersion: v1
kind: Pod
metadata:
name: cuda-vector-add
spec:
restartPolicy: OnFailure
containers:
- name: cuda-vector-add
# https://github.com/kubernetes/kubernetes/blob/v1.7.11/test/images/nvidia-cuda/Dockerfile
image: "k8s.gcr.io/cuda-vector-add:v0.1"
resources:
limits:
nvidia.com/gpu: 1
nodeSelector:
accelerator: nvidia-tesla-p100 # or nvidia-tesla-k80 etc.
```
This will ensure that the pod will be scheduled to a node that has the GPU type
you specified.
## Future
- Support for hardware accelerators in Kubernetes is still in alpha.
- Better APIs will be introduced to provision and consume accelerators in a scalable manner.
- Kubernetes will automatically ensure that applications consuming GPUs get the best possible performance.
- Key usability problems like access to CUDA libraries will be addressed.
{% endcapture %}
{% include templates/task.md %}
docs/tasks/manage-hugepages/scheduling-hugepages.md
+3 -1
View File
@@ -68,12 +68,14 @@ spec:
than the pod request.
- Applications that consume huge pages via `shmget()` with `SHM_HUGETLB` must
run with a supplemental group that matches `proc/sys/vm/hugetlb_shm_group`.
- Huge page usage in a namespace is controllable via ResourceQuota similar
to other compute resources like `cpu` or `memory` using the `hugepages-<size>`
token.
## Future
- Support container isolation of huge pages in addition to pod isolation.
- NUMA locality guarantees as a feature of quality of service.
- ResourceQuota support.
- LimitRange support.
{% endcapture %}
docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
+1 -1
View File
@@ -35,7 +35,7 @@ It defines an [index.php](/docs/user-guide/horizontal-pod-autoscaling/image/inde
First, we will start a deployment running the image and expose it as a service:
```shell
$ kubectl run php-apache --image=gcr.io/google_containers/hpa-example --requests=cpu=200m --expose --port=80
$ kubectl run php-apache --image=k8s.gcr.io/hpa-example --requests=cpu=200m --expose --port=80
service "php-apache" created
deployment "php-apache" created
```
docs/tasks/run-application/horizontal-pod-autoscale.md
+2 -2
View File
@@ -98,9 +98,9 @@ The detailed documentation of `kubectl autoscale` can be found [here](/docs/user
## Autoscaling during rolling update
Currently in Kubernetes, it is possible to perform a [rolling update](/docs/tasks/run-application/rolling-update-replication-controller/) by managing replication controllers directly,
or by using the deployment object, which manages the underlying replication controllers for you.
or by using the deployment object, which manages the underlying replica sets for you.
Horizontal Pod Autoscaler only supports the latter approach: the Horizontal Pod Autoscaler is bound to the deployment object,
it sets the size for the deployment object, and the deployment is responsible for setting sizes of underlying replication controllers.
it sets the size for the deployment object, and the deployment is responsible for setting sizes of underlying replica sets.
Horizontal Pod Autoscaler does not work with rolling update using direct manipulation of replication controllers,
i.e. you cannot bind a Horizontal Pod Autoscaler to a replication controller and do rolling update (e.g. using `kubectl rolling-update`).
docs/tasks/run-application/run-replicated-stateful-application.md
+1 -1
View File
@@ -31,7 +31,7 @@ on general patterns for running stateful applications in Kubernetes.
and [StatefulSets](/docs/concepts/workloads/controllers/statefulset/),
as well as other core concepts like [Pods](/docs/concepts/workloads/pods/pod/),
[Services](/docs/concepts/services-networking/service/), and
[ConfigMaps](/docs/tasks/configure-pod-container/configmap/).
[ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/).
* Some familiarity with MySQL helps, but this tutorial aims to present
general patterns that should be useful for other systems.
docs/tasks/service-catalog/install-service-catalog-using-helm.md
+2 -2
View File
@@ -5,7 +5,7 @@ approvers:
---
{% capture overview %}
{% glossary_definition term_id="service-catalog" length="long" %}
{% glossary_definition term_id="service-catalog" length="all" prepend="Service Catalog is" %}
Use [Helm](https://helm.sh/) to install Service Catalog on your Kubernetes cluster. Up to date information on this process can be found at the [kubernetes-incubator/service-catalog](https://github.com/kubernetes-incubator/service-catalog/blob/master/docs/install.md) repo.
@@ -97,4 +97,4 @@ helm install svc-cat/catalog \
{% endcapture %}
{% include templates/task.md %}
{% include templates/task.md %}
docs/tasks/service-catalog/install-service-catalog-using-sc.md
+5 -5
View File
@@ -5,7 +5,7 @@ approvers:
---
{% capture overview %}
{% glossary_definition term_id="service-catalog" length="long" %}
{% glossary_definition term_id="service-catalog" length="all" prepend="Service Catalog is" %}
Use the [Service Catalog Installer](https://github.com/GoogleCloudPlatform/k8s-service-catalog#installation) tool to easily install or uninstall Service Catalog on your Kubernetes cluster. This CLI tool is installed as `sc` in your local environment.
@@ -15,7 +15,7 @@ Use the [Service Catalog Installer](https://github.com/GoogleCloudPlatform/k8s-s
{% capture prerequisites %}
* Understand the key concepts of [Service Catalog](/docs/concepts/service-catalog/).
* Install [Go 1.6+](https://golang.org/dl/) and set the `GOPATH`.
* Install the [cfssl](https://github.com/cloudflare/cfssl) tool needed for generating SSL artifacts.
* Install the [cfssl](https://github.com/cloudflare/cfssl) tool needed for generating SSL artifacts.
* Service Catalog requires Kubernetes version 1.7+.
* [Install and setup kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/) so that it is configured to connect to a Kubernetes v1.7+ cluster.
* The kubectl user must be bound to the *cluster-admin* role for it to install Service Catalog. To ensure that this is true, run the following command:
@@ -44,11 +44,11 @@ First, verify that all dependencies have been installed. Run:
sc check
```
If the check is successful, it should return:
If the check is successful, it should return:
```
Dependency check passed. You are good to go.
```
```
Next, run the install command and specify the `storageclass` that you want to use for the backup:
@@ -74,4 +74,4 @@ sc uninstall
{% endcapture %}
{% include templates/task.md %}
{% include templates/task.md %}
docs/tasks/tools/install-minikube.md
+2 -1
View File
@@ -23,7 +23,8 @@ If you do not already have a hypervisor installed, install one now.
* For OS X, install
[xhyve driver](https://git.k8s.io/minikube/docs/drivers.md#xhyve-driver),
[VirtualBox](https://www.virtualbox.org/wiki/Downloads), or
[VMware Fusion](https://www.vmware.com/products/fusion).
[VMware Fusion](https://www.vmware.com/products/fusion), or
[HyperKit](https://github.com/moby/hyperkit).
* For Linux, install
[VirtualBox](https://www.virtualbox.org/wiki/Downloads) or