merge master to 1.10, with fixes (#7682)

This commit is contained in:
Jennifer Rondeau
2018-03-08 14:03:55 -05:00
committed by k8s-ci-robot
parent bb8c59a640
commit 44b51d6056
548 changed files with 11634 additions and 318622 deletions
+35 -11
View File
@@ -1,5 +1,5 @@
---
approvers:
reviewers:
- pweil-
- tallclair
title: Pod Security Policies
@@ -23,12 +23,12 @@ administrator to control the following:
| Control Aspect | Field Names |
| ----------------------------------------------------| ------------------------------------------- |
| Running of privileged containers | `privileged` |
| Running of privileged containers | [`privileged`](#privileged) |
| Usage of the root namespaces | [`hostPID`, `hostIPC`](#host-namespaces) |
| Usage of host networking and ports | [`hostNetwork`, `hostPorts`](#host-namespaces) |
| Usage of volume types | [`volumes`](#volumes-and-file-systems) |
| Usage of the host filesystem | [`allowedHostPaths`](#volumes-and-file-systems) |
| Usage of FlexVolume drivers | [`allowedFlexVolumes`](#flexvolume-drivers) |
| White list of FlexVolume drivers | [`allowedFlexVolumes`](#flexvolume-drivers) |
| Allocating an FSGroup that owns the pod's volumes | [`fsGroup`](#volumes-and-file-systems) |
| Requiring the use of a read only root file system | [`readOnlyRootFilesystem`](#volumes-and-file-systems) |
| The user and group IDs of the container | [`runAsUser`, `supplementalGroups`](#users-and-groups) |
@@ -37,6 +37,7 @@ administrator to control the following:
| The SELinux context of the container | [`seLinux`](#selinux) |
| The AppArmor profile used by containers | [annotations](#apparmor) |
| The seccomp profile used by containers | [annotations](#seccomp) |
| The sysctl profile used by containers | [annotations](#sysctl) |
## Enabling Pod Security Policies
@@ -273,7 +274,7 @@ Error from server (Forbidden): error when creating "STDIN": pods "privileged" is
Delete the pod before moving on:
```shell
$ kubectl-user delete pause
$ kubectl-user delete pod pause
```
### Run another pod
@@ -354,6 +355,15 @@ several security mechanisms.
## Policy Reference
### Privileged
**Privileged** - determines if any container in a pod can enable privileged mode.
By default a container is not allowed to access any devices on the host, but a
"privileged" container is given access to all devices on the host. This allows
the container nearly all the same access as processes running on the host.
This is useful for containers that want to use linux capabilities like
manipulating the network stack and accessing devices.
### Host namespaces
**HostPID** - Controls whether the pod containers can share the host process ID
@@ -420,16 +430,25 @@ root filesystem (i.e. no writeable layer).
### FlexVolume drivers
When the [`Volumes`](#volumes-and-file-systems) field contains `flexVolume` in
its list value, the cluster admin can further specify which driver(s) is permitted
by setting the `allowedFlexVolumes` field.
This specifies a whiltelist of flex volume drivers that are allowed to be used
by flexVolume. An empty list or nil means there is no restriction on the drivers.
Please make sure [`volumes`](#volumes-and-file-systems) field contains the
`flexVolume` volume type, no FlexVolume driver is allowed otherwise.
**AllowedFlexVolumes** - Provides a whitelist of allowed FlexVolumes. Empty or
nil indicates that all FlexVolume drivers may be used. For example, the following
setting only permits the `examle/fast_cache` driver to be used on nodes:
For example:
```yaml
allowedFlexVolumes: [ "example/fast_cache" ]
apiVersion: extensions/v1beta1
kind: PodSecurityPolicy
metadata:
name: allow-flex-volumes
spec:
# ... other spec fields
volumes:
- flexVolume
allowedFlexVolumes:
- driver: example/lvm
- driver: example/cifs
```
### Users and groups
@@ -536,3 +555,8 @@ specifies which values are allowed for the pod seccomp annotations. Specified as
a comma-delimited list of allowed values. Possible values are those listed
above, plus `*` to allow all profiles. Absence of this annotation means that the
default cannot be changed.
### Sysctl
Controlled via annotations on the PodSecurityPolicy. Refer to the [Sysctl documentation](
/docs/concepts/cluster-administration/sysctl-cluster/#podsecuritypolicy-annotations).
+71 -27
View File
@@ -1,5 +1,5 @@
---
approvers:
reviewers:
- derekwaynecarr
title: Resource Quotas
---
@@ -18,15 +18,15 @@ Resource quotas work like this:
- Different teams work in different namespaces. Currently this is voluntary, but
support for making this mandatory via ACLs is planned.
- The administrator creates one or more Resource Quota objects for each namespace.
- The administrator creates one or more `ResourceQuotas` for each namespace.
- Users create resources (pods, services, etc.) in the namespace, and the quota system
tracks usage to ensure it does not exceed hard resource limits defined in a Resource Quota.
tracks usage to ensure it does not exceed hard resource limits defined in a `ResourceQuota`.
- If creating or updating a resource violates a quota constraint, the request will fail with HTTP
status code `403 FORBIDDEN` with a message explaining the constraint that would have been violated.
- If quota is enabled in a namespace for compute resources like `cpu` and `memory`, users must specify
requests or limits for those values; otherwise, the quota system may reject pod creation. Hint: Use
the LimitRange admission controller to force defaults for pods that make no compute resource requirements.
See the [walkthrough](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/) for an example to avoid this problem.
See the [walkthrough](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/) for an example of how to avoid this problem.
Examples of policies that could be created using namespaces and quotas are:
@@ -42,13 +42,12 @@ Neither contention nor changes to quota will affect already created resources.
## Enabling Resource Quota
Resource Quota support is enabled by default for many Kubernetes distributions. It is
Resource quota support is enabled by default for many Kubernetes distributions. It is
enabled when the apiserver `--admission-control=` flag has `ResourceQuota` as
one of its arguments.
Resource Quota is enforced in a particular namespace when there is a
`ResourceQuota` object in that namespace. There should be at most one
`ResourceQuota` object in a namespace.
A resource quota is enforced in a particular namespace when there is a
`ResourceQuota` in that namespace.
## Compute Resource Quota
@@ -84,7 +83,7 @@ define a quota as follows:
* `gold.storageclass.storage.k8s.io/requests.storage: 500Gi`
* `bronze.storageclass.storage.k8s.io/requests.storage: 100Gi`
In release 1.8, quota support for local ephemeral storage is added as alpha feature
In release 1.8, quota support for local ephemeral storage is added as an alpha feature:
| Resource Name | Description |
| ------------------------------- |----------------------------------------------------------- |
@@ -93,8 +92,34 @@ In release 1.8, quota support for local ephemeral storage is added as alpha feat
## Object Count Quota
The number of objects of a given type can be restricted. The following types
are supported:
The 1.9 release added support to quota all standard namespaced resource types using the following syntax:
* `count/<resource>.<group>`
Here is an example set of resources users may want to put under object count quota:
* `count/persistentvolumeclaims`
* `count/services`
* `count/secrets`
* `count/configmaps`
* `count/replicationcontrollers`
* `count/deployments.apps`
* `count/replicasets.apps`
* `count/statefulsets.apps`
* `count/jobs.batch`
* `count/cronjobs.batch`
* `count/deployments.extensions`
When using `count/*` resource quota, an object is charged against the quota if it exists in server storage.
These types of quotas are useful to protect against exhaustion of storage resources. For example, you may
want to quota the number of secrets in a server given their large size. Too many secrets in a cluster can
actually prevent servers and controllers from starting! You may choose to quota jobs to protect against
a poorly configured cronjob creating too many jobs in a namespace causing a denial of service.
Prior to the 1.9 release, it was possible to do generic object count quota on a limited set of resources.
In addition, it is possible to further constrain quota for particular resources by their type.
The following types are supported:
| Resource Name | Description |
| ------------------------------- | ------------------------------------------------- |
@@ -109,11 +134,9 @@ are supported:
| `secrets` | The total number of secrets that can exist in the namespace. |
For example, `pods` quota counts and enforces a maximum on the number of `pods`
created in a single namespace.
You might want to set a pods quota on a namespace
to avoid the case where a user creates many small pods and exhausts the cluster's
supply of Pod IPs.
created in a single namespace that are not terminal. You might want to set a `pods`
quota on a namespace to avoid the case where a user creates many small pods and
exhausts the cluster's supply of Pod IPs.
## Quota Scopes
@@ -156,9 +179,9 @@ then it requires that every incoming container specifies an explicit limit for t
Kubectl supports creating, updating, and viewing quotas:
```shell
$ kubectl create namespace myspace
kubectl create namespace myspace
$ cat <<EOF > compute-resources.yaml
cat <<EOF > compute-resources.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
@@ -171,9 +194,9 @@ spec:
limits.cpu: "2"
limits.memory: 2Gi
EOF
$ kubectl create -f ./compute-resources.yaml --namespace=myspace
kubectl create -f ./compute-resources.yaml --namespace=myspace
$ cat <<EOF > object-counts.yaml
cat <<EOF > object-counts.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
@@ -187,14 +210,14 @@ spec:
services: "10"
services.loadbalancers: "2"
EOF
$ kubectl create -f ./object-counts.yaml --namespace=myspace
kubectl create -f ./object-counts.yaml --namespace=myspace
$ kubectl get quota --namespace=myspace
kubectl get quota --namespace=myspace
NAME AGE
compute-resources 30s
object-counts 32s
$ kubectl describe quota compute-resources --namespace=myspace
kubectl describe quota compute-resources --namespace=myspace
Name: compute-resources
Namespace: myspace
Resource Used Hard
@@ -205,7 +228,7 @@ pods 0 4
requests.cpu 0 1
requests.memory 0 1Gi
$ kubectl describe quota object-counts --namespace=myspace
kubectl describe quota object-counts --namespace=myspace
Name: object-counts
Namespace: myspace
Resource Used Hard
@@ -218,9 +241,30 @@ services 0 10
services.loadbalancers 0 2
```
Kubectl also supports object count quota for all standard namespaced resources
using the syntax `count/<resource>.<group>`:
```shell
kubectl create namespace myspace
kubectl create quota test --hard=count/deployments.extensions=2,count/replicasets.extensions=4,count/pods=3,count/secrets=4 --namespace=myspace
kubectl run nginx --image=nginx --replicas=2 --namespace=myspace
kubectl describe quota --namespace=myspace
Name: test
Namespace: myspace
Resource Used Hard
-------- ---- ----
count/deployments.extensions 1 2
count/pods 2 3
count/replicasets.extensions 1 4
count/secrets 1 4
```
## Quota and Cluster Capacity
Resource Quota objects are independent of the Cluster Capacity. They are
`ResourceQuotas` are independent of the cluster capacity. They are
expressed in absolute units. So, if you add nodes to your cluster, this does *not*
automatically give each namespace the ability to consume more resources.
@@ -231,8 +275,8 @@ Sometimes more complex policies may be desired, such as:
limit to prevent accidental resource exhaustion.
- Detect demand from one namespace, add nodes, and increase quota.
Such policies could be implemented using ResourceQuota as a building-block, by
writing a 'controller' which watches the quota usage and adjusts the quota
Such policies could be implemented using `ResourceQuotas` as building blocks, by
writing a "controller" that watches the quota usage and adjusts the quota
hard limits of each namespace according to other signals.
Note that resource quota divides up aggregate cluster resources, but it creates no