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

Convert site to Hugo (#8316)

Browse Source 
This commit converts content and layout to use Hugo.
This commit is contained in:
Bjørn Erik Pedersen
2018-05-05 18:00:51 +02:00
committed by k8s-ci-robot
parent 7745f0e0c5
commit 7f3b633aa0
2327 changed files with 10928 additions and 171503 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/cn/docs/concepts/policy/pod-security-policy.md
+220
View File
@@ -0,0 +1,220 @@
---
approvers:
- pweil-
title: Pod 安全策略
redirect_from:
- "/docs/user-guide/pod-security-policy/"
- "/docs/user-guide/pod-security-policy/index.html"
---
`PodSecurityPolicy` 类型的对象能够控制，是否可以向 Pod 发送请求，该 Pod 能够影响被应用到 Pod 和容器的 `SecurityContext`。
查看 [Pod 安全策略建议](https://git.k8s.io/community/contributors/design-proposals/security-context-constraints.md) 获取更多信息。
{{< toc >}}
## 什么是 Pod 安全策略？
_Pod 安全策略_ 是集群级别的资源，它能够控制 Pod 运行的行为，以及它具有访问什么的能力。
`PodSecurityPolicy` 对象定义了一组条件，指示 Pod 必须按系统所能接受的顺序运行。
它们允许管理员控制如下方面：
| 控制面 | 字段名称 |
| ------------------------------------------------------------- | --------------------------------- |
| 已授权容器的运行 | `privileged` |
| 为容器添加默认的一组能力 | `defaultAddCapabilities` |
| 为容器去掉某些能力 | `requiredDropCapabilities` |
| 容器能够请求添加某些能力 | `allowedCapabilities` |
| 控制卷类型的使用 | [`volumes`](#controlling-volumes) |
| 主机网络的使用 | [`hostNetwork`](#host-network) |
| 主机端口的使用 | `hostPorts` |
| 主机 PID namespace 的使用 | `hostPID` |
| 主机 IPC namespace 的使用 | `hostIPC` |
| 主机路径的使用 | [`allowedHostPaths`](#allowed-host-paths) |
| 容器的 SELinux 上下文 | [`seLinux`](#selinux) |
| 用户 ID | [`runAsUser`](#runasuser) |
| 配置允许的补充组 | [`supplementalGroups`](#supplementalgroups) |
| 分配拥有 Pod 数据卷的 FSGroup | [`fsGroup`](#fsgroup) |
| 必须使用一个只读的 root 文件系统 | `readOnlyRootFilesystem` |
_Pod 安全策略_ 由设置和策略组成，它们能够控制 Pod 访问的安全特征。这些设置分为如下三类：
- *基于布尔值控制*：这种类型的字段默认为最严格限制的值。
- *基于被允许的值集合控制*：这种类型的字段会与这组值进行对比，以确认值被允许。
- *基于策略控制*：设置项通过一种策略提供的机制来生成该值，这种机制能够确保指定的值落在被允许的这组值中。
### RunAsUser
- *MustRunAs* - 必须配置一个 `range`。使用该范围内的第一个值作为默认值。验证是否不在配置的该范围内。
- *MustRunAsNonRoot* - 要求提交的 Pod 具有非零 `runAsUser` 值，或在镜像中定义了 `USER` 环境变量。不提供默认值。
- *RunAsAny* - 没有提供默认值。允许指定任何 `runAsUser` 。
### SELinux
- *MustRunAs* - 如果没有使用预分配的值，必须配置 `seLinuxOptions`。默认使用 `seLinuxOptions`。验证 `seLinuxOptions`。
- *RunAsAny* - 没有提供默认值。允许任意指定的 `seLinuxOptions` ID。
### SupplementalGroups
- *MustRunAs* - 至少需要指定一个范围。默认使用第一个范围的最小值。验证所有范围的值。
- *RunAsAny* - 没有提供默认值。允许任意指定的 `supplementalGroups` ID。
### FSGroup
- *MustRunAs* - 至少需要指定一个范围。默认使用第一个范围的最小值。验证在第一个范围内的第一个 ID。
- *RunAsAny* - 没有提供默认值。允许任意指定的 `fsGroup` ID。
### 控制卷
通过设置 PSP 卷字段，能够控制具体卷类型的使用。当创建一个卷的时候，与该字段相关的已定义卷可以允许设置如下值：
1. azureFile
1. azureDisk
1. flocker
1. flexVolume
1. hostPath
1. emptyDir
1. gcePersistentDisk
1. awsElasticBlockStore
1. gitRepo
1. secret
1. nfs
1. iscsi
1. glusterfs
1. persistentVolumeClaim
1. rbd
1. cinder
1. cephFS
1. downwardAPI
1. fc
1. configMap
1. vsphereVolume
1. quobyte
1. photonPersistentDisk
1. projected
1. portworxVolume
1. scaleIO
1. storageos
1. \* (allow all volumes)
对新的 PSP，推荐允许的卷的最小集合包括：configMap、downwardAPI、emptyDir、persistentVolumeClaim、secret 和 projected。
### 主机网络
- *HostPorts*， 默认为 `empty`。`HostPortRange` 列表通过 `min`(包含) and `max`(包含) 来定义，指定了被允许的主机端口。
### 允许的主机路径
- *AllowedHostPaths* 是一个被允许的主机路径前缀的白名单。空值表示所有的主机路径都可以使用。
## 许可
包含 `PodSecurityPolicy` 的 _许可控制_，允许控制集群资源的创建和修改，基于这些资源在集群范围内被许可的能力。
许可使用如下的方式为 Pod 创建最终的安全上下文：
1. 检索所有可用的 PSP。
1. 生成在请求中没有指定的安全上下文设置的字段值。
1. 基于可用的策略，验证最终的设置。
如果某个策略能够匹配上，该 Pod 就被接受。如果请求与 PSP 不匹配，则 Pod 被拒绝。
Pod 必须基于 PSP 验证每个字段。
## 创建 Pod 安全策略
下面是一个 Pod 安全策略的例子，所有字段的设置都被允许：
{{< code file="psp.yaml" >}}
下载示例文件可以创建该策略，然后执行如下命令：
```shell
$ kubectl create -f ./psp.yaml
podsecuritypolicy "permissive" created
```
## 获取 Pod 安全策略列表
获取已存在策略列表，使用 `kubectl get`：
```shell
$ kubectl get psp
NAME PRIV CAPS SELINUX RUNASUSER FSGROUP SUPGROUP READONLYROOTFS VOLUMES
permissive false [] RunAsAny RunAsAny RunAsAny RunAsAny false [*]
privileged true [] RunAsAny RunAsAny RunAsAny RunAsAny false [*]
restricted false [] RunAsAny MustRunAsNonRoot RunAsAny RunAsAny false [emptyDir secret downwardAPI configMap persistentVolumeClaim projected]
```
## 修改 Pod 安全策略
通过交互方式修改策略，使用 `kubectl edit`：
```shell
$ kubectl edit psp permissive
```
该命令将打开一个默认文本编辑器，在这里能够修改策略。
## 删除 Pod 安全策略
一旦不再需要一个策略，很容易通过 `kubectl` 删除它：
```shell
$ kubectl delete psp permissive
podsecuritypolicy "permissive" deleted
```
## 启用 Pod 安全策略
为了能够在集群中使用 Pod 安全策略，必须确保满足如下条件：
1. 已经启用 API 类型 `extensions/v1beta1/podsecuritypolicy`（仅对 1.6 之前的版本）
1. 已经启用许可控制器 `PodSecurityPolicy`
1. 已经定义了自己的策略
## 使用 RBAC
在 Kubernetes 1.5 或更新版本，可以使用 PodSecurityPolicy 来控制，对基于用户角色和组的已授权容器的访问。访问不同的 PodSecurityPolicy 对象，可以基于认证来控制。基于 Deployment、ReplicaSet 等创建的 Pod，限制访问 PodSecurityPolicy 对象，[Controller Manager](/docs/admin/kube-controller-manager/) 必须基于安全 API 端口运行，并且不能够具有超级用户权限。
PodSecurityPolicy 认证使用所有可用的策略，包括创建 Pod 的用户，Pod 上指定的服务账户（Service Acount）。当 Pod 基于 Deployment、ReplicaSet 创建时，它是创建 Pod 的 Controller Manager，所以如果基于非安全 API 端口运行，允许所有的 PodSecurityPolicy 对象，并且不能够有效地实现细分权限。用户访问给定的 PSP 策略有效，仅当是直接部署 Pod 的情况。更多详情，查看 [PodSecurityPolicy RBAC 示例](https://git.k8s.io/kubernetes/examples/podsecuritypolicy/rbac/README.md)，当直接部署 Pod 时，应用 PodSecurityPolicy 控制基于角色和组的已授权容器的访问 。
content/cn/docs/concepts/policy/psp.yaml
+18
View File
@@ -0,0 +1,18 @@
apiVersion: extensions/v1beta1
kind: PodSecurityPolicy
metadata:
name: permissive
spec:
seLinux:
rule: RunAsAny
supplementalGroups:
rule: RunAsAny
runAsUser:
rule: RunAsAny
fsGroup:
rule: RunAsAny
hostPorts:
- min: 8000
max: 8080
volumes:
- '*'
content/cn/docs/concepts/policy/resource-quotas.md
+220
View File
@@ -0,0 +1,220 @@
---
approvers:
- derekwaynecarr
title: 资源配额
---
当多个用户或团队共享具有固定数目节点的集群时，人们会担心有人使用的资源超出应有的份额。
资源配额是帮助管理员解决这一问题的工具。
资源配额， 通过 `ResourceQuota` 对象来定义， 对每个namespace的资源消耗总量提供限制。 它可以按类型限制namespace下可以创建的对象的数量，也可以限制可被该项目以资源形式消耗的计算资源的总量。
资源配额的工作方式如下：
- 不同的团队在不同的namespace下工作。 目前这是自愿的， 但计划通过ACL (Access Control List 访问控制列表)
使其变为强制性的。
- 管理员为每个namespace创建一个或多个资源配额对象。
- 用户在namespace下创建资源 (pods、 services等)，同时配额系统会跟踪使用情况，来确保其不超过
资源配额中定义的硬性资源限额。
- 如果资源的创建或更新违反了配额约束，则请求会失败，并返回 HTTP状态码 `403 FORBIDDEN` ，以及说明违反配额
约束的信息。
- 如果namespace下的计算资源 （如 `cpu` 和 `memory`）的配额被启用，则用户必须为这些资源设定请求值（request）
和约束值（limit），否则配额系统将拒绝Pod的创建。
提示: 可使用 LimitRange 准入控制器来为没有设置计算资源需求的Pod设置默认值。
作为示例，请参考 [演练](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/) 来避免这个问题。
下面是使用namespace和配额构建策略的示例：
- 在具有 32 GiB 内存 和 16 核CPU资源的集群中， 允许A团队使用 20 GiB 内存 和 10 核的CPU资源，
允许B团队使用 10GiB 内存和 4 核的CPU资源， 并且预留 2GiB 内存和 2 核的CPU资源供将来分配。
- 限制 "testing" namespace使用 1 核CPU资源和 1GiB 内存。 允许 "production" namespace使用任意数量。
在集群容量小于各namespace配额总和的情况下，可能存在资源竞争。 Kubernetes采用先到先服务的方式处理这类问题。
无论是资源竞争还是配额的变更都不会影响已经创建的资源。
## 启用资源配额
资源配额的支持在很多Kubernetes版本中是默认开启的。 当 apiserver 的
`--admission-control=` 参数中包含 `ResourceQuota` 时，资源配额会被启用。
当namespace中存在一个 `ResourceQuota` 对象时，该namespace即开始实施资源配额管理。
一个namespace中最多只应存在一个 `ResourceQuota` 对象
## 计算资源配额
用户可以对给定namespace下的 [计算资源](/docs/user-guide/compute-resources) 总量进行限制。
配额机制所支持的资源类型：
| 资源名称 | 描述 |
| --------------------- | ----------------------------------------------------------- |
| `cpu` | 所有非终止状态的Pod中，其CPU需求总量不能超过该值。 |
| `limits.cpu` | 所有非终止状态的Pod中，其CPU限额总量不能超过该值。 |
| `limits.memory` | 所有非终止状态的Pod中，其内存限额总量不能超过该值。 |
| `memory` | 所有非终止状态的Pod中，其内存需求总量不能超过该值。 |
| `requests.cpu` | 所有非终止状态的Pod中，其CPU需求总量不能超过该值。 |
| `requests.memory` | 所有非终止状态的Pod中，其内存需求总量不能超过该值。 |
## 存储资源配额
用户可以对给定namespace下的 [存储资源](/docs/user-guide/persistent-volumes) 总量进行限制。
此外，还可以根据相关的存储类（Storage Class）来限制存储资源的消耗。
| 资源名称 | 描述 |
| --------------------- | ----------------------------------------------------------- |
| `requests.storage` | 所有的PVC中，存储资源的需求不能超过该值。 |
| `persistentvolumeclaims` | namespace中所允许的 [PVC](/docs/user-guide/persistent-volumes/#persistentvolumeclaims) 总量。 |
| `<storage-class-name>.storageclass.storage.k8s.io/requests.storage` | 所有该storage-class-name相关的PVC中， 存储资源的需求不能超过该值。 |
| `<storage-class-name>.storageclass.storage.k8s.io/persistentvolumeclaims` | namespace中所允许的该storage-class-name相关的[PVC](/docs/user-guide/persistent-volumes/#persistentvolumeclaims)的总量。 |
例如，如果一个操作人员针对 "黄金" 存储类型与 "铜" 存储类型设置配额，操作员可以
定义配额如下：
* `gold.storageclass.storage.k8s.io/requests.storage: 500Gi`
* `bronze.storageclass.storage.k8s.io/requests.storage: 100Gi`
## 对象数量配额
给定类型的对象数量可以被限制。 支持以下类型：
| 资源名称 | 描述 |
| ------------------------------- | ------------------------------------------------- |
| `configmaps` | namespace下允许存在的configmap的数量。 |
| `persistentvolumeclaims` | namespace下允许存在的[PVC](/docs/user-guide/persistent-volumes/#persistentvolumeclaims)的数量。 |
| `pods` | namespace下允许存在的非终止状态的pod数量。 如果pod 的 `status.phase 为 Failed 或 Succeeded` ， 那么其处于终止状态。 |
| `replicationcontrollers` | namespace下允许存在的replication controllers的数量。 |
| `resourcequotas` | namespace下允许存在的 [resource quotas](/docs/admin/admission-controllers/#resourcequota) 的数量。 |
| `services` | namespace下允许存在的service的数量。 |
| `services.loadbalancers` | namespace下允许存在的load balancer类型的service的数量。 |
| `services.nodeports` | namespace下允许存在的node port类型的service的数量。 |
| `secrets` | namespace下允许存在的secret的数量。 |
例如 `pods` 配额统计并保证单个namespace下创建 `pods` 的最大数量。
用户可能希望在namespace中为pod设置配额，来避免有用户创建很多小的pod，从而耗尽集群提供的pod IP地址。
## 配额作用域
每个配额都有一组相关的作用域（scope），配额只会对作用域内的资源生效。
当一个作用域被添加到配额中后，它会对作用域相关的资源数量作限制。
如配额中指定了允许（作用域）集合之外的资源，会导致验证错误。
| 范围 | 描述 |
| ----- | ----------- |
| `Terminating` | 匹配 `spec.activeDeadlineSeconds >= 0` 的pod。 |
| `NotTerminating` | 匹配 `spec.activeDeadlineSeconds is nil` 的pod。 |
| `BestEffort` | 匹配"尽力而为（best effort)"服务类型的pod。 |
| `NotBestEffort` | 匹配非"尽力而为（best effort)"服务类型的pod。 |
`BestEffort` 作用域限制配额跟踪以下资源： `pods`
`Terminating`、 `NotTerminating` 和 `NotBestEffort` 限制配额跟踪以下资源：
* `cpu`
* `limits.cpu`
* `limits.memory`
* `memory`
* `pods`
* `requests.cpu`
* `requests.memory`
## 请求／约束
分配计算资源时，每个容器可以为CPU或内存指定请求和约束。
也可以设置两者中的任何一个。
如果配额中指定了 `requests.cpu` 或 `requests.memory` 的值，那么它要求每个进来的容器针对这些资源有明确的请求。 如果配额中指定了 `limits.cpu` 或 `limits.memory`的值，那么它要求每个进来的容器针对这些资源指定明确的约束。
## 查看和设置配额
Kubectl 支持创建、更新和查看配额：
```shell
$ kubectl create namespace myspace
$ cat <<EOF > compute-resources.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
name: compute-resources
spec:
hard:
pods: "4"
requests.cpu: "1"
requests.memory: 1Gi
limits.cpu: "2"
limits.memory: 2Gi
EOF
$ kubectl create -f ./compute-resources.yaml --namespace=myspace
$ cat <<EOF > object-counts.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
name: object-counts
spec:
hard:
configmaps: "10"
persistentvolumeclaims: "4"
replicationcontrollers: "20"
secrets: "10"
services: "10"
services.loadbalancers: "2"
EOF
$ kubectl create -f ./object-counts.yaml --namespace=myspace
$ kubectl get quota --namespace=myspace
NAME AGE
compute-resources 30s
object-counts 32s
$ kubectl describe quota compute-resources --namespace=myspace
Name: compute-resources
Namespace: myspace
Resource Used Hard
-------- ---- ----
limits.cpu 0 2
limits.memory 0 2Gi
pods 0 4
requests.cpu 0 1
requests.memory 0 1Gi
$ kubectl describe quota object-counts --namespace=myspace
Name: object-counts
Namespace: myspace
Resource Used Hard
-------- ---- ----
configmaps 0 10
persistentvolumeclaims 0 4
replicationcontrollers 0 20
secrets 1 10
services 0 10
services.loadbalancers 0 2
```
## 配额和集群容量
配额对象是独立于集群容量的。它们通过绝对的单位来表示。 所以，为集群添加节点， *不会*
自动赋予每个namespace消耗更多资源的能力。
有时可能需要更复杂的策略，比如：
- 在几个团队中按比例划分总的集群资源。
- 允许每个租户根据需要增加资源使用量，但要有足够的限制以防止意外资源耗尽。
- 在namespace中添加节点、提高配额的额外需求。
这些策略可以基于 ResourceQuota，通过编写一个检测配额使用，并根据其他信号调整各namespace下的配额硬性限制的 "控制器" 来实现。
注意：资源配额对集群资源总体进行划分，但它对节点没有限制：来自多个namespace的Pod可能在同一节点上运行。
## 示例
查看 [如何使用资源配额的详细示例](/docs/tasks/administer-cluster/quota-api-object/)。
## 更多信息
查看 [资源配额设计文档](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md) 了解更多信息。