rootsongjc
/
kubernetes-handbook
mirror of https://github.com/rootsongjc/kubernetes-handbook.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

refine

pull/411/head
Jimmy song 2020-07-12 12:44:39 +08:00
parent 0c46171d3b
commit 5cde869b16
12 changed files with 190 additions and 214 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
README.md
View File

@ -2,6 +2,10 @@
> 云原生是一种行为方式和设计理念，如今它正在遭受过度地市场化包装。究其本质，凡是能够提高云上资源利用率和应用交付效率的行为或方式都是云原生的。云计算的发展史就是一部云原生化的历史。—— [Jimmy Song](https://jimmysong.io) > 云原生是一种行为方式和设计理念，如今它正在遭受过度地市场化包装。究其本质，凡是能够提高云上资源利用率和应用交付效率的行为或方式都是云原生的。云计算的发展史就是一部云原生化的历史。—— [Jimmy Song](https://jimmysong.io)
![加入云原生社区](https://res.cloudinary.com/jimmysong/image/upload/v1594445787/images/github-banner.jpg)
👉 [https://cloudnative.to](https://cloudnative.to)
[Kubernetes](http://kubernetes.io) 是 Google 于 [2014 年 6 月](https://jimmysong.io/cloud-native/memo/open-source/)基于其内部使用的 [Borg](https://research.google.com/pubs/pub43438.html) 系统开源出来的容器编排调度引擎，Google 将其作为初始和核心项目贡献给 [CNCF](https://cncf.io)（云原生计算基金会），近年来逐渐发展出了云原生生态。 [Kubernetes](http://kubernetes.io) 是 Google 于 [2014 年 6 月](https://jimmysong.io/cloud-native/memo/open-source/)基于其内部使用的 [Borg](https://research.google.com/pubs/pub43438.html) 系统开源出来的容器编排调度引擎，Google 将其作为初始和核心项目贡献给 [CNCF](https://cncf.io)（云原生计算基金会），近年来逐渐发展出了云原生生态。
Kubernetes 的目标不仅仅是一个编排系统，而是提供一个规范用以描述集群的架构，定义服务的最终状态，使系统自动地达到和维持该状态。Kubernetes 作为云原生应用的基石，相当于一个云操作系统，其重要性不言而喻。 Kubernetes 的目标不仅仅是一个编排系统，而是提供一个规范用以描述集群的架构，定义服务的最终状态，使系统自动地达到和维持该状态。Kubernetes 作为云原生应用的基石，相当于一个云操作系统，其重要性不言而喻。
@ -80,7 +84,9 @@ Kubernetes Handbook 开源于 2017 年 3 月并在其后不断完善，是第一
## 云原生社区 ## 云原生社区
云原生社区是一个有技术、有温度、有情怀的开源社区，由 [Jimmy 和他的伙伴们](https://cloudnative.to/team) 成立于 2020 年 5 月 12 日，秉持 “共识、共治、共建、共享” 的原则。立足中国，面向世界，企业中立，旨在借助开源打破企业的边界，关注技术人的成长，面向全球华人，促进中国云原生开源的发展。云原生官方网站 <https://cloudnative.to>，关注社区微信公众号，获取加入方式。 云原生社区是一个有技术、有温度、有情怀的开源社区，由 [Jimmy 和他的伙伴们](https://cloudnative.to/team) 成立于 2020 年 5 月 12 日，由 2016 年即成立的「K8s&云原生讨论群」改组而成，覆盖了上千名云原生早期采纳者。社区秉持 “共识、共治、共建、共享” 的原则，立足中国，面向世界，企业中立，旨在为广大云原生爱好者构建一个自由交流和分享的平台，让云原生技术为大众所用。
官方网站 <https://cloudnative.to>，关注云原生社区官方微信公众号，获取加入方式。
<p align="center"> <p align="center">
<img src="images/cloud-native-wechat.jpg" alt="云原生社区微信公众号" title="云原生社区微信公众号"/> <img src="images/cloud-native-wechat.jpg" alt="云原生社区微信公众号" title="云原生社区微信公众号"/>

2
concepts/daemonset.md
View File

@ -1,5 +1,7 @@
# DaemonSet # DaemonSet
本文将为您介绍 DaemonSet 的基本概念。
## 什么是 DaemonSet？ ## 什么是 DaemonSet？
_DaemonSet_ 确保全部（或者一些）Node 上运行一个 Pod 的副本。当有 Node 加入集群时，也会为他们新增一个 Pod 。当有 Node 从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod。 _DaemonSet_ 确保全部（或者一些）Node 上运行一个 Pod 的副本。当有 Node 加入集群时，也会为他们新增一个 Pod 。当有 Node 从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod。

7
concepts/garbage-collection.md
View File

@ -128,9 +128,4 @@ kubectl delete replicaset my-repset --cascade=false
## 已知的问题 ## 已知的问题
- 1.7 版本，垃圾收集不支持 [自定义资源](https://kubernetes.io/docs/concepts/api-extension/custom-resources/)，比如那些通过 CustomResourceDefinition 新增，或者通过 API server 聚集而成的资源对象。 - 1.7 版本，垃圾收集不支持 [自定义资源](https://kubernetes.io/docs/concepts/api-extension/custom-resources/)，比如那些通过 CustomResourceDefinition 新增，或者通过 API server 聚集而成的资源对象。
- [其它已知的问题](https://github.com/kubernetes/kubernetes/issues/26120)。
[其它已知的问题](https://github.com/kubernetes/kubernetes/issues/26120)
原文地址：https://k8smeetup.github.io/docs/concepts/workloads/controllers/garbage-collection/
译者：[shirdrn](https://github.com/shirdrn)

8
concepts/init-containers.md
View File

@ -242,11 +242,3 @@ Pod 重启，会导致 Init 容器重新执行，主要有如下几个原因：
## 支持与兼容性 ## 支持与兼容性
API Server 版本为 1.6 或更高版本的集群，通过使用 `spec.initContainers` 字段来支持 Init 容器。之前的版本可以使用 alpha 和 beta 注解支持 Init 容器。`spec.initContainers` 字段也被加入到 alpha 和 beta 注解中，所以 Kubernetes 1.3.0 版本或更高版本可以执行 Init 容器，并且 1.6 版本的 API Server 能够安全地回退到 1.5.x 版本，而不会使已创建的 Pod 失去 Init 容器的功能。 API Server 版本为 1.6 或更高版本的集群，通过使用 `spec.initContainers` 字段来支持 Init 容器。之前的版本可以使用 alpha 和 beta 注解支持 Init 容器。`spec.initContainers` 字段也被加入到 alpha 和 beta 注解中，所以 Kubernetes 1.3.0 版本或更高版本可以执行 Init 容器，并且 1.6 版本的 API Server 能够安全地回退到 1.5.x 版本，而不会使已创建的 Pod 失去 Init 容器的功能。
---
> 原文地址：https://k8smeetup.github.io/docs/concepts/workloads/pods/init-containers/
>
> 译者：[shirdrn](https://github.com/shirdrn)
>
> 校对：[Jimmy Song](https://github.com/rootsongjc)

23
concepts/namespace.md
View File

@ -1,24 +1,21 @@
# Namespace # Namespace
在一个Kubernetes集群中可以使用namespace创建多个“虚拟集群”，这些namespace之间可以完全隔离，也可以通过某种方式，让一个namespace中的service可以访问到其他的namespace中的服务，我们[在CentOS中部署kubernetes1.6集群](../practice/install-kubernetes-on-centos.md)的时候就用到了好几个跨越namespace的服务，比如Traefik ingress和`kube-system`namespace下的service就可以为整个集群提供服务，这些都需要通过RBAC定义集群级别的角色来实现。 在一个 Kubernetes 集群中可以使用 namespace 创建多个 “虚拟集群”，这些 namespace 之间可以完全隔离，也可以通过某种方式，让一个 namespace 中的 service 可以访问到其他的 namespace 中的服务，我们 [在 CentOS 中部署 kubernetes1.6 集群](../practice/install-kubernetes-on-centos.md) 的时候就用到了好几个跨越 namespace 的服务，比如 Traefik ingress 和 `kube-system`namespace 下的 service 就可以为整个集群提供服务，这些都需要通过 RBAC 定义集群级别的角色来实现。
## 哪些情况下适合使用多个namespace ## 哪些情况下适合使用多个 namespace
因为namespace可以提供独立的命名空间，因此可以实现部分的环境隔离。当你的项目和人员众多的时候可以考虑根据项目属性，例如生产、测试、开发划分不同的namespace。 因为 namespace 可以提供独立的命名空间，因此可以实现部分的环境隔离。当你的项目和人员众多的时候可以考虑根据项目属性，例如生产、测试、开发划分不同的 namespace。
## Namespace使用 ## Namespace 使用
**获取集群中有哪些namespace** **获取集群中有哪些 namespace **
``` ```kubectl get ns```
kubectl get ns
```
集群中默认会有`default`和`kube-system`这两个namespace。 集群中默认会有 `default` 和 `kube-system` 这两个 namespace。
在执行`kubectl`命令时可以使用`-n`指定操作的namespace。 在执行 `kubectl` 命令时可以使用 `-n` 指定操作的 namespace。
用户的普通应用默认是在`default`下，与集群管理相关的为整个集群提供服务的应用一般部署在`kube-system`的namespace下，例如我们在安装kubernetes集群时部署的`kubedns`、`heapseter`、`EFK`等都是在这个namespace下面。 用户的普通应用默认是在 `default` 下，与集群管理相关的为整个集群提供服务的应用一般部署在 `kube-system` 的 namespace 下，例如我们在安装 kubernetes 集群时部署的 `kubedns`、`heapseter`、`EFK` 等都是在这个 namespace 下面。
另外，并不是所有的资源对象都会对应namespace，`node`和`persistentVolume`就不属于任何namespace。
另外，并不是所有的资源对象都会对应 namespace，`node` 和 `persistentVolume` 就不属于任何 namespace。

32
concepts/node.md
View File

@ -1,38 +1,38 @@
# Node # Node
Node是kubernetes集群的工作节点，可以是物理机也可以是虚拟机。 Node 是 Kubernetes 集群的工作节点，可以是物理机也可以是虚拟机。
## Node的状态 ## Node 的状态
Node包括如下状态信息： Node 包括如下状态信息：
- Address - Address
- HostName：可以被kubelet中的`--hostname-override`参数替代。 - HostName：可以被 kubelet 中的 `--hostname-override` 参数替代。
- ExternalIP：可以被集群外部路由到的IP地址。 - ExternalIP：可以被集群外部路由到的 IP 地址。
- InternalIP：集群内部使用的IP，集群外部无法访问。 - InternalIP：集群内部使用的 IP，集群外部无法访问。
- Condition - Condition
- OutOfDisk：磁盘空间不足时为`True` - OutOfDisk：磁盘空间不足时为 `True`
- Ready：Node controller 40秒内没有收到node的状态报告为`Unknown`，健康为`True`，否则为`False`。 - Ready：Node controller 40 秒内没有收到 node 的状态报告为 `Unknown`，健康为 `True`，否则为 `False`。
- MemoryPressure：当node有内存压力时为`True`，否则为`False`。 - MemoryPressure：当 node 有内存压力时为 `True`，否则为 `False`。
- DiskPressure：当node有磁盘压力时为`True`，否则为`False`。 - DiskPressure：当 node 有磁盘压力时为 `True`，否则为 `False`。
- Capacity - Capacity
- CPU - CPU
- 内存 - 内存
- 可运行的最大Pod个数 - 可运行的最大 Pod 个数
- Info：节点的一些版本信息，如OS、kubernetes、docker等 - Info：节点的一些版本信息，如 OS、kubernetes、docker 等
## Node管理 ## Node 管理
禁止pod调度到该节点上 禁止 Pod 调度到该节点上。
```bash ```bash
kubectl cordon <node> kubectl cordon <node>
``` ```
驱逐该节点上的所有pod 驱逐该节点上的所有 Pod。
```bash ```bash
kubectl drain <node> kubectl drain <node>
``` ```
该命令会删除该节点上的所有Pod（DaemonSet除外），在其他node上重新启动它们，通常该节点需要维护时使用该命令。直接使用该命令会自动调用`kubectl cordon <node>`命令。当该节点维护完成，启动了kubelet后，再使用`kubectl uncordon <node>`即可将该节点添加到kubernetes集群中。 该命令会删除该节点上的所有 Pod（DaemonSet 除外），在其他 node 上重新启动它们，通常该节点需要维护时使用该命令。直接使用该命令会自动调用`kubectl cordon <node>`命令。当该节点维护完成，启动了 kubelet 后，再使用`kubectl uncordon <node>` 即可将该节点添加到 kubernetes 集群中。

2
concepts/pod-lifecycle.md
View File

@ -198,5 +198,3 @@ spec:
## 参考 ## 参考
- [Pod lifecycle - kubernetes.io](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/) - [Pod lifecycle - kubernetes.io](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/)

54
concepts/pod-overview.md
View File

@ -1,65 +1,67 @@
# Pod概览 # Pod 概览
## 理解Pod 本文将为您讲解 Pod 的基础概念。
Pod是kubernetes中你可以创建和部署的最小也是最简的单位。Pod代表着集群中运行的进程。 ## 理解 Pod
Pod中封装着应用的容器（有的情况下是好几个容器），存储、独立的网络IP，管理容器如何运行的策略选项。Pod代表着部署的一个单位：kubernetes中应用的一个实例，可能由一个或者多个容器组合在一起共享资源。 Pod 是 kubernetes 中你可以创建和部署的最小也是最简的单位。Pod 代表着集群中运行的进程。
> [Docker](https://www.docker.com)是kubernetes中最常用的容器运行时，但是Pod也支持其他容器运行时。 Pod 中封装着应用的容器（有的情况下是好几个容器），存储、独立的网络 IP，管理容器如何运行的策略选项。Pod 代表着部署的一个单位：kubernetes 中应用的一个实例，可能由一个或者多个容器组合在一起共享资源。
> [Docker](https://www.docker.com) 是 kubernetes 中最常用的容器运行时，但是 Pod 也支持其他容器运行时。
在Kubernetes集群中Pod有如下两种使用方式： 在 Kubernetes 集群中 Pod 有如下两种使用方式：
- **一个Pod中运行一个容器**。“每个Pod中一个容器”的模式是最常见的用法；在这种使用方式中，你可以把Pod想象成是单个容器的封装，kuberentes管理的是Pod而不是直接管理容器。 - **一个 Pod 中运行一个容器**。“每个 Pod 中一个容器” 的模式是最常见的用法；在这种使用方式中，你可以把 Pod 想象成是单个容器的封装，kuberentes 管理的是 Pod 而不是直接管理容器。
- **在一个Pod中同时运行多个容器**。一个Pod中也可以同时封装几个需要紧密耦合互相协作的容器，它们之间共享资源。这些在同一个Pod中的容器可以互相协作成为一个service单位——一个容器共享文件，另一个“sidecar”容器来更新这些文件。Pod将这些容器的存储资源作为一个实体来管理。 - **在一个 Pod 中同时运行多个容器**。一个 Pod 中也可以同时封装几个需要紧密耦合互相协作的容器，它们之间共享资源。这些在同一个 Pod 中的容器可以互相协作成为一个 service 单位 —— 一个容器共享文件，另一个 “sidecar” 容器来更新这些文件。Pod 将这些容器的存储资源作为一个实体来管理。
[Kubernetes Blog](http://blog.kubernetes.io) 有关于Pod用例的详细信息，查看： [Kubernetes Blog](https://kubernetes.io/blog) 有关于 Pod 用例的详细信息，查看：
- [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns/) - [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns/)
- [Container Design Patterns](https://kubernetes.io/blog/2016/06/container-design-patterns/) - [Container Design Patterns](https://kubernetes.io/blog/2016/06/container-design-patterns/)
每个Pod都是应用的一个实例。如果你想平行扩展应用的话（运行多个实例），你应该运行多个Pod，每个Pod都是一个应用实例。在Kubernetes中，这通常被称为replication。 每个 Pod 都是应用的一个实例。如果你想平行扩展应用的话（运行多个实例），你应该运行多个 Pod，每个 Pod 都是一个应用实例。在 Kubernetes 中，这通常被称为 replication。
### Pod中如何管理多个容器 ### Pod 中如何管理多个容器
Pod中可以同时运行多个进程（作为容器运行）协同工作。同一个Pod中的容器会自动的分配到同一个 node 上。同一个Pod中的容器共享资源、网络环境和依赖，它们总是被同时调度。 Pod 中可以同时运行多个进程（作为容器运行）协同工作。同一个 Pod 中的容器会自动的分配到同一个 node 上。同一个 Pod 中的容器共享资源、网络环境和依赖，它们总是被同时调度。
注意在一个Pod中同时运行多个容器是一种比较高级的用法。只有当你的容器需要紧密配合协作的时候才考虑用这种模式。例如，你有一个容器作为web服务器运行，需要用到共享的volume，有另一个“sidecar”容器来从远端获取资源更新这些文件，如下图所示： 注意在一个 Pod 中同时运行多个容器是一种比较高级的用法。只有当你的容器需要紧密配合协作的时候才考虑用这种模式。例如，你有一个容器作为 web 服务器运行，需要用到共享的 volume，有另一个 “sidecar” 容器来从远端获取资源更新这些文件，如下图所示：
![pod diagram](../images/pod-overview.png) ![pod diagram](../images/pod-overview.png)
Pod中可以共享两种资源：网络和存储。 Pod 中可以共享两种资源：网络和存储。
#### 网络 #### 网络
每个Pod都会被分配一个唯一的IP地址。Pod中的所有容器共享网络空间，包括IP地址和端口。Pod内部的容器可以使用`localhost`互相通信。Pod中的容器与外界通信时，必须分配共享网络资源（例如使用宿主机的端口映射）。 每个 Pod 都会被分配一个唯一的 IP 地址。Pod 中的所有容器共享网络空间，包括 IP 地址和端口。Pod 内部的容器可以使用 `localhost` 互相通信。Pod 中的容器与外界通信时，必须分配共享网络资源（例如使用宿主机的端口映射）。
#### 存储 #### 存储
可以为一个Pod指定多个共享的Volume。Pod中的所有容器都可以访问共享的volume。Volume也可以用来持久化Pod中的存储资源，以防容器重启后文件丢失。 可以为一个 Pod 指定多个共享的 Volume。Pod 中的所有容器都可以访问共享的 volume。Volume 也可以用来持久化 Pod 中的存储资源，以防容器重启后文件丢失。
## 使用Pod ## 使用 Pod
你很少会直接在kubernetes中创建单个Pod。因为Pod的生命周期是短暂的，用后即焚的实体。当Pod被创建后（不论是由你直接创建还是被其他Controller），都会被Kubernetes调度到集群的Node上。直到Pod的进程终止、被删掉、因为缺少资源而被驱逐、或者Node故障之前这个Pod都会一直保持在那个Node上。 你很少会直接在 kubernetes 中创建单个 Pod。因为 Pod 的生命周期是短暂的，用后即焚的实体。当 Pod 被创建后（不论是由你直接创建还是被其他 Controller），都会被 Kubernetes 调度到集群的 Node 上。直到 Pod 的进程终止、被删掉、因为缺少资源而被驱逐、或者 Node 故障之前这个 Pod 都会一直保持在那个 Node 上。
> 注意：重启Pod中的容器跟重启Pod不是一回事。Pod只提供容器的运行环境并保持容器的运行状态，重启容器不会造成Pod重启。 > 注意：重启 Pod 中的容器跟重启 Pod 不是一回事。Pod 只提供容器的运行环境并保持容器的运行状态，重启容器不会造成 Pod 重启。
Pod不会自愈。如果Pod运行的Node故障，或者是调度器本身故障，这个Pod就会被删除。同样的，如果Pod所在Node缺少资源或者Pod处于维护状态，Pod也会被驱逐。Kubernetes使用更高级的称为Controller的抽象层，来管理Pod实例。虽然可以直接使用Pod，但是在Kubernetes中通常是使用Controller来管理Pod的。 Pod 不会自愈。如果 Pod 运行的 Node 故障，或者是调度器本身故障，这个 Pod 就会被删除。同样的，如果 Pod 所在 Node 缺少资源或者 Pod 处于维护状态，Pod 也会被驱逐。Kubernetes 使用更高级的称为 Controller 的抽象层，来管理 Pod 实例。虽然可以直接使用 Pod，但是在 Kubernetes 中通常是使用 Controller 来管理 Pod 的。
### Pod和Controller ### Pod 和 Controller
Controller可以创建和管理多个Pod，提供副本管理、滚动升级和集群级别的自愈能力。例如，如果一个Node故障，Controller就能自动将该节点上的Pod调度到其他健康的Node上。 Controller 可以创建和管理多个 Pod，提供副本管理、滚动升级和集群级别的自愈能力。例如，如果一个 Node 故障，Controller 就能自动将该节点上的 Pod 调度到其他健康的 Node 上。
包含一个或者多个Pod的Controller示例： 包含一个或者多个 Pod 的 Controller 示例：
- [Deployment](deployment.md) - [Deployment](deployment.md)
- [StatefulSet](./statefulset.md) - [StatefulSet](./statefulset.md)
- [DaemonSet](daemonset.md) - [DaemonSet](daemonset.md)
通常，Controller会用你提供的Pod Template来创建相应的Pod。 通常，Controller 会用你提供的 Pod Template 来创建相应的 Pod。
## Pod Templates ## Pod Templates
Pod模版是包含了其他object的Pod定义，例如[Replication Controllers](replicaset.md)，[Jobs](./job.md)和 Pod 模版是包含了其他 object 的 Pod 定义，例如 [Replication Controllers](replicaset.md)，[Jobs](./job.md) 和
[DaemonSets](./daemonset.md)。Controller根据Pod模板来创建实际的Pod。 [DaemonSets](./daemonset.md)。Controller 根据 Pod 模板来创建实际的 Pod。

4
concepts/pod-security-policy.md
View File

@ -184,7 +184,3 @@ podsecuritypolicy "permissive" deleted
在 Kubernetes 1.5 或更新版本，可以使用 PodSecurityPolicy 来控制，对基于用户角色和组的已授权容器的访问。访问不同的 PodSecurityPolicy 对象，可以基于认证来控制。基于 Deployment、ReplicaSet 等创建的 Pod，限制访问 PodSecurityPolicy 对象，[Controller Manager](https://kubernetes.io/docs/admin/kube-controller-manager/) 必须基于安全 API 端口运行，并且不能够具有超级用户权限。 在 Kubernetes 1.5 或更新版本，可以使用 PodSecurityPolicy 来控制，对基于用户角色和组的已授权容器的访问。访问不同的 PodSecurityPolicy 对象，可以基于认证来控制。基于 Deployment、ReplicaSet 等创建的 Pod，限制访问 PodSecurityPolicy 对象，[Controller Manager](https://kubernetes.io/docs/admin/kube-controller-manager/) 必须基于安全 API 端口运行，并且不能够具有超级用户权限。
PodSecurityPolicy 认证使用所有可用的策略，包括创建 Pod 的用户，Pod 上指定的服务账户（service acount）。当 Pod 基于 Deployment、ReplicaSet 创建时，它是创建 Pod 的 Controller Manager，所以如果基于非安全 API 端口运行，允许所有的 PodSecurityPolicy 对象，并且不能够有效地实现细分权限。用户访问给定的 PSP 策略有效，仅当是直接部署 Pod 的情况。当直接部署 Pod 时，应用 PodSecurityPolicy 控制基于角色和组的已授权容器的访问 。 PodSecurityPolicy 认证使用所有可用的策略，包括创建 Pod 的用户，Pod 上指定的服务账户（service acount）。当 Pod 基于 Deployment、ReplicaSet 创建时，它是创建 Pod 的 Controller Manager，所以如果基于非安全 API 端口运行，允许所有的 PodSecurityPolicy 对象，并且不能够有效地实现细分权限。用户访问给定的 PSP 策略有效，仅当是直接部署 Pod 的情况。当直接部署 Pod 时，应用 PodSecurityPolicy 控制基于角色和组的已授权容器的访问 。
原文地址：https://k8smeetup.github.io/docs/concepts/policy/pod-security-policy/
译者：[shirdrn](https://github.com/shirdrn)

251
concepts/rbac.md
View File

@ -1,22 +1,20 @@
# RBAC——基于角色的访问控制 # RBAC—— 基于角色的访问控制
以下内容是 [xingzhou](https://github.com/xingzhou) 对 kubernetes 官方文档的翻译，原文地址 https://k8smeetup.github.io/docs/admin/authorization/rbac/ 基于角色的访问控制（Role-Based Access Control, 即”RBAC”）使用”rbac.authorization.k8s.io” API Group 实现授权决策，允许管理员通过 Kubernetes API 动态配置策略。
基于角色的访问控制（Role-Based Access Control, 即”RBAC”）使用”rbac.authorization.k8s.io” API Group实现授权决策，允许管理员通过Kubernetes API动态配置策略。 截至 Kubernetes 1.6，RBAC 模式处于 beta 版本。
截至Kubernetes 1.6，RBAC模式处于beta版本。 要启用 RBAC，请使用 `--authorization-mode=RBAC` 启动 API Server。
要启用RBAC，请使用`--authorization-mode=RBAC`启动API Server。 ## API 概述
## API概述 本节将介绍 RBAC API 所定义的四种顶级类型。用户可以像使用其他 Kubernetes API 资源一样 （例如通过 `kubectl`、API 调用等）与这些资源进行交互。例如，命令 `kubectl create -f (resource).yml` 可以被用于以下所有的例子，当然，读者在尝试前可能需要先阅读以下相关章节的内容。
本节将介绍RBAC API所定义的四种顶级类型。用户可以像使用其他Kubernetes API资源一样 （例如通过`kubectl`、API调用等）与这些资源进行交互。例如，命令`kubectl create -f (resource).yml` 可以被用于以下所有的例子，当然，读者在尝试前可能需要先阅读以下相关章节的内容。 ### Role 与 ClusterRole
### Role与ClusterRole 在 RBAC API 中，一个角色包含了一套表示一组权限的规则。 权限以纯粹的累加形式累积（没有” 否定” 的规则）。 角色可以由命名空间（namespace）内的 `Role` 对象定义，而整个 Kubernetes 集群范围内有效的角色则通过 `ClusterRole` 对象实现。
在RBAC API中，一个角色包含了一套表示一组权限的规则。 权限以纯粹的累加形式累积（没有”否定”的规则）。 角色可以由命名空间（namespace）内的`Role`对象定义，而整个Kubernetes集群范围内有效的角色则通过`ClusterRole`对象实现。 一个 `Role` 对象只能用于授予对某一单一命名空间中资源的访问权限。 以下示例描述了”default” 命名空间中的一个 `Role` 对象的定义，用于授予对 pod 的读访问权限：
一个`Role`对象只能用于授予对某一单一命名空间中资源的访问权限。 以下示例描述了”default”命名空间中的一个`Role`对象的定义，用于授予对pod的读访问权限：
```yaml ```yaml
kind: Role kind: Role
@ -25,24 +23,24 @@ metadata:
namespace: default namespace: default
name: pod-reader name: pod-reader
rules: rules:
- apiGroups: [""] # 空字符串""表明使用core API group - apiGroups: [""] # 空字符串"" 表明使用 core API group
resources: ["pods"] resources: ["pods"]
verbs: ["get", "watch", "list"] verbs: ["get", "watch", "list"]
``` ```
`ClusterRole`对象可以授予与`Role`对象相同的权限，但由于它们属于集群范围对象， 也可以使用它们授予对以下几种资源的访问权限： `ClusterRole` 对象可以授予与 `Role` 对象相同的权限，但由于它们属于集群范围对象， 也可以使用它们授予对以下几种资源的访问权限：
- 集群范围资源（例如节点，即node） - 集群范围资源（例如节点，即 node）
- 非资源类型endpoint（例如”/healthz”） - 非资源类型 endpoint（例如”/healthz”）
- 跨所有命名空间的命名空间范围资源（例如pod，需要运行命令`kubectl get pods --all-namespaces`来查询集群中所有的pod） - 跨所有命名空间的命名空间范围资源（例如 pod，需要运行命令 `kubectl get pods --all-namespaces` 来查询集群中所有的 pod）
下面示例中的`ClusterRole`定义可用于授予用户对某一特定命名空间，或者所有命名空间中的secret（取决于其[绑定](https://k8smeetup.github.io/docs/admin/authorization/rbac/#rolebinding-and-clusterrolebinding)方式）的读访问权限： 下面示例中的 `ClusterRole` 定义可用于授予用户对某一特定命名空间，或者所有命名空间中的 secret（取决于其 [绑定](https://k8smeetup.github.io/docs/admin/authorization/rbac/#rolebinding-and-clusterrolebinding) 方式）的读访问权限：
```yaml ```yaml
kind: ClusterRole kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1beta1 apiVersion: rbac.authorization.k8s.io/v1beta1
metadata: metadata:
# 鉴于ClusterRole是集群范围对象，所以这里不需要定义"namespace"字段 # 鉴于 ClusterRole 是集群范围对象，所以这里不需要定义 "namespace" 字段
name: secret-reader name: secret-reader
rules: rules:
- apiGroups: [""] - apiGroups: [""]
@ -50,14 +48,15 @@ rules:
verbs: ["get", "watch", "list"] verbs: ["get", "watch", "list"]
``` ```
### RoleBinding与ClusterRoleBinding ### RoleBinding 与 ClusterRoleBinding
角色绑定将一个角色中定义的各种权限授予一个或者一组用户。 角色绑定包含了一组相关主体（即subject, 包括用户——User、用户组——Group、或者服务账户——Service Account）以及对被授予角色的引用。 在命名空间中可以通过`RoleBinding`对象授予权限，而集群范围的权限授予则通过`ClusterRoleBinding`对象完成。 角色绑定将一个角色中定义的各种权限授予一个或者一组用户。 角色绑定包含了一组相关主体（即 subject, 包括用户 ——User、用户组 ——Group、或者服务账户 ——Service Account）以及对被授予角色的引用。 在命名空间中可以通过 `RoleBinding` 对象授予权限，而集群范围的权限授予则通过 `ClusterRoleBinding` 对象完成。
`RoleBinding`可以引用在同一命名空间内定义的`Role`对象。 下面示例中定义的`RoleBinding`对象在”default”命名空间中将”pod-reader”角色授予用户”jane”。 这一授权将允许用户”jane”从”default”命名空间中读取pod。 `RoleBinding` 可以引用在同一命名空间内定义的 `Role` 对象。 下面示例中定义的 `RoleBinding` 对象在”default” 命名空间中将”pod-reader” 角色授予用户”jane”。 这一授权将允许用户”jane” 从”default” 命名空间中读取 pod。
以下角色绑定定义将允许用户 "jane" 从 "default" 命名空间中读取 pod。
```yaml ```yaml
# 以下角色绑定定义将允许用户"jane"从"default"命名空间中读取pod。
kind: RoleBinding kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1 apiVersion: rbac.authorization.k8s.io/v1beta1
metadata: metadata:
@ -73,17 +72,17 @@ roleRef:
apiGroup: rbac.authorization.k8s.io apiGroup: rbac.authorization.k8s.io
``` ```
`RoleBinding`对象也可以引用一个`ClusterRole`对象用于在`RoleBinding`所在的命名空间内授予用户对所引用的`ClusterRole`中 定义的命名空间资源的访问权限。这一点允许管理员在整个集群范围内首先定义一组通用的角色，然后再在不同的命名空间中复用这些角色。 `RoleBinding` 对象也可以引用一个 `ClusterRole` 对象用于在 `RoleBinding` 所在的命名空间内授予用户对所引用的 `ClusterRole` 中 定义的命名空间资源的访问权限。这一点允许管理员在整个集群范围内首先定义一组通用的角色，然后再在不同的命名空间中复用这些角色。
例如，尽管下面示例中的`RoleBinding`引用的是一个`ClusterRole`对象，但是用户”dave”（即角色绑定主体）还是只能读取”development” 命名空间中的secret（即`RoleBinding`所在的命名空间）。 例如，尽管下面示例中的 `RoleBinding` 引用的是一个 `ClusterRole` 对象，但是用户”dave”（即角色绑定主体）还是只能读取”development” 命名空间中的 secret（即 `RoleBinding` 所在的命名空间）。
```yaml ```yaml
# 以下角色绑定允许用户"dave"读取"development"命名空间中的secret。 # 以下角色绑定允许用户 "dave" 读取 "development" 命名空间中的 secret。
kind: RoleBinding kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1 apiVersion: rbac.authorization.k8s.io/v1beta1
metadata: metadata:
name: read-secrets name: read-secrets
namespace: development # 这里表明仅授权读取"development"命名空间中的资源。 namespace: development # 这里表明仅授权读取 "development" 命名空间中的资源。
subjects: subjects:
- kind: User - kind: User
name: dave name: dave
@ -94,10 +93,11 @@ roleRef:
apiGroup: rbac.authorization.k8s.io apiGroup: rbac.authorization.k8s.io
``` ```
最后，可以使用`ClusterRoleBinding`在集群级别和所有命名空间中授予权限。下面示例中所定义的`ClusterRoleBinding` 允许在用户组”manager”中的任何用户都可以读取集群中任何命名空间中的secret。 最后，可以使用`ClusterRoleBinding`在集群级别和所有命名空间中授予权限。下面示例中所定义的`ClusterRoleBinding`允许在用户组”manager” 中的任何用户都可以读取集群中任何命名空间中的 secret。
以下 `ClusterRoleBinding` 对象允许在用户组 "manager" 中的任何用户都可以读取集群中任何命名空间中的 secret。
```yaml ```yaml
# 以下`ClusterRoleBinding`对象允许在用户组"manager"中的任何用户都可以读取集群中任何命名空间中的secret。
kind: ClusterRoleBinding kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1 apiVersion: rbac.authorization.k8s.io/v1beta1
metadata: metadata:
@ -114,14 +114,11 @@ roleRef:
### 对资源的引用 ### 对资源的引用
大多数资源由代表其名字的字符串表示，例如”pods”，就像它们出现在相关API endpoint的URL中一样。然而，有一些Kubernetes API还 包含了”子资源”，比如pod的logs。在Kubernetes中，pod logs endpoint的URL格式为： 大多数资源由代表其名字的字符串表示，例如”pods”，就像它们出现在相关 API endpoint 的 URL 中一样。然而，有一些 Kubernetes API 还 包含了” 子资源”，比如 pod 的 logs。在 Kubernetes 中，pod logs endpoint 的 URL 格式为：
``` ```GET /api/v1/namespaces/{namespace}/pods/{name}/log```
GET /api/v1/namespaces/{namespace}/pods/{name}/log
``` 在这种情况下，”pods” 是命名空间资源，而”log” 是 pods 的子资源。为了在 RBAC 角色中表示出这一点，我们需要使用斜线来划分资源 与子资源。如果需要角色绑定主体读取 pods 以及 pod log，您需要定义以下角色：
在这种情况下，”pods”是命名空间资源，而”log”是pods的子资源。为了在RBAC角色中表示出这一点，我们需要使用斜线来划分资源 与子资源。如果需要角色绑定主体读取pods以及pod log，您需要定义以下角色：
```yaml ```yaml
kind: Role kind: Role
@ -135,7 +132,7 @@ rules:
verbs: ["get", "list"] verbs: ["get", "list"]
``` ```
通过`resourceNames`列表，角色可以针对不同种类的请求根据资源名引用资源实例。当指定了`resourceNames`列表时，不同动作 种类的请求的权限，如使用”get”、”delete”、”update”以及”patch”等动词的请求，将被限定到资源列表中所包含的资源实例上。 例如，如果需要限定一个角色绑定主体只能”get”或者”update”一个configmap时，您可以定义以下角色： 通过`resourceNames`列表，角色可以针对不同种类的请求根据资源名引用资源实例。当指定了`resourceNames`列表时，不同动作 种类的请求的权限，如使用”get”、”delete”、”update” 以及”patch” 等动词的请求，将被限定到资源列表中所包含的资源实例上。 例如，如果需要限定一个角色绑定主体只能”get” 或者”update” 一个 configmap 时，您可以定义以下角色：
```yaml ```yaml
kind: Role kind: Role
@ -150,13 +147,13 @@ rules:
verbs: ["update", "get"] verbs: ["update", "get"]
``` ```
值得注意的是，如果设置了`resourceNames`，则请求所使用的动词不能是list、watch、create或者deletecollection。 由于资源名不会出现在create、list、watch和deletecollection等API请求的URL中，所以这些请求动词不会被设置了`resourceNames` 的规则所允许，因为规则中的`resourceNames`部分不会匹配这些请求。 值得注意的是，如果设置了`resourceNames`，则请求所使用的动词不能是 list、watch、create 或者 deletecollection。 由于资源名不会出现在 create、list、watch 和 deletecollection 等 API 请求的 URL 中，所以这些请求动词不会被设置了`resourceNames`的规则所允许，因为规则中的`resourceNames` 部分不会匹配这些请求。
#### 一些角色定义的例子 #### 一些角色定义的例子
在以下示例中，我们仅截取展示了`rules`部分的定义。 在以下示例中，我们仅截取展示了 `rules` 部分的定义。
允许读取core API Group中定义的资源”pods”： 允许读取 core API Group 中定义的资源”pods”：
```yaml ```yaml
rules: rules:
@ -165,7 +162,7 @@ rules:
verbs: ["get", "list", "watch"] verbs: ["get", "list", "watch"]
``` ```
允许读写在”extensions”和”apps” API Group中定义的”deployments”： 允许读写在”extensions” 和”apps” API Group 中定义的”deployments”：
```yaml ```yaml
rules: rules:
@ -174,7 +171,7 @@ rules:
verbs: ["get", "list", "watch", "create", "update", "patch", "delete"] verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
``` ```
允许读取”pods”以及读写”jobs”： 允许读取”pods” 以及读写”jobs”：
```yaml ```yaml
rules: rules:
@ -186,7 +183,7 @@ rules:
verbs: ["get", "list", "watch", "create", "update", "patch", "delete"] verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
``` ```
允许读取一个名为”my-config”的`ConfigMap`实例（需要将其通过`RoleBinding`绑定从而限制针对某一个命名空间中定义的一个`ConfigMap`实例的访问）： 允许读取一个名为”my-config” 的`ConfigMap`实例（需要将其通过`RoleBinding`绑定从而限制针对某一个命名空间中定义的一个`ConfigMap`实例的访问）：
```yaml ```yaml
rules: rules:
@ -196,7 +193,7 @@ rules:
verbs: ["get"] verbs: ["get"]
``` ```
允许读取core API Group中的”nodes”资源（由于`Node`是集群级别资源，所以此`ClusterRole`定义需要与一个`ClusterRoleBinding`绑定才能有效）： 允许读取 core API Group 中的”nodes” 资源（由于`Node`是集群级别资源，所以此`ClusterRole`定义需要与一个`ClusterRoleBinding`绑定才能有效）：
```yaml ```yaml
rules: rules:
@ -205,29 +202,27 @@ rules:
verbs: ["get", "list", "watch"] verbs: ["get", "list", "watch"]
``` ```
允许对非资源endpoint “/healthz”及其所有子路径的”GET”和”POST”请求（此`ClusterRole`定义需要与一个`ClusterRoleBinding`绑定才能有效）： 允许对非资源 endpoint “/healthz” 及其所有子路径的”GET” 和”POST” 请求（此`ClusterRole`定义需要与一个`ClusterRoleBinding`绑定才能有效）：
```yaml ```yaml
rules: rules:
- nonResourceURLs: ["/healthz", "/healthz/*"] # 在非资源URL中，'*'代表后缀通配符 - nonResourceURLs: ["/healthz", "/healthz/*"] # 在非资源 URL 中，'*' 代表后缀通配符
verbs: ["get", "post"] verbs: ["get", "post"]
``` ```
### 对角色绑定主体（Subject）的引用 对角色绑定主体（Subject）的引用`RoleBinding`或者`ClusterRoleBinding` 将角色绑定到 *角色绑定主体*（Subject）。 角色绑定主体可以是用户组（Group）、用户（User）或者服务账户（Service Accounts）。
`RoleBinding`或者`ClusterRoleBinding`将角色绑定到*角色绑定主体*（Subject）。 角色绑定主体可以是用户组（Group）、用户（User）或者服务账户（Service Accounts）。 用户由字符串表示。可以是纯粹的用户名，例如”alice”、电子邮件风格的名字，如 “bob@example.com” 或者是用字符串表示的数字 id。由 Kubernetes 管理员配置 [认证模块](https://k8smeetup.github.io/docs/admin/authentication/) 以产生所需格式的用户名。对于用户名，RBAC 授权系统不要求任何特定的格式。然而，前缀 `system:` 是 为 Kubernetes 系统使用而保留的，所以管理员应该确保用户名不会意外地包含这个前缀。
用户由字符串表示。可以是纯粹的用户名，例如”alice”、电子邮件风格的名字，如 “bob@example.com” 或者是用字符串表示的数字id。由Kubernetes管理员配置[认证模块](https://k8smeetup.github.io/docs/admin/authentication/) 以产生所需格式的用户名。对于用户名，RBAC授权系统不要求任何特定的格式。然而，前缀`system:`是 为Kubernetes系统使用而保留的，所以管理员应该确保用户名不会意外地包含这个前缀。 Kubernetes 中的用户组信息由授权模块提供。用户组与用户一样由字符串表示。Kubernetes 对用户组 字符串没有格式要求，但前缀 `system:` 同样是被系统保留的。
Kubernetes中的用户组信息由授权模块提供。用户组与用户一样由字符串表示。Kubernetes对用户组 字符串没有格式要求，但前缀`system:`同样是被系统保留的。 [服务账户](https://k8smeetup.github.io/docs/tasks/configure-pod-container/configure-service-account/) 拥有包含 `system:serviceaccount:` 前缀的用户名，并属于拥有 `system:serviceaccounts:` 前缀的用户组。
[服务账户](https://k8smeetup.github.io/docs/tasks/configure-pod-container/configure-service-account/)拥有包含 `system:serviceaccount:`前缀的用户名，并属于拥有`system:serviceaccounts:`前缀的用户组。
#### 角色绑定的一些例子 #### 角色绑定的一些例子
以下示例中，仅截取展示了`RoleBinding`的`subjects`字段。 以下示例中，仅截取展示了 `RoleBinding` 的 `subjects` 字段。
一个名为”alice@example.com”的用户： 一个名为”alice@example.com” 的用户：
```yaml ```yaml
subjects: subjects:
@ -236,7 +231,7 @@ subjects:
apiGroup: rbac.authorization.k8s.io apiGroup: rbac.authorization.k8s.io
``` ```
一个名为”frontend-admins”的用户组： 一个名为”frontend-admins” 的用户组：
```yaml ```yaml
subjects: subjects:
@ -245,7 +240,7 @@ subjects:
apiGroup: rbac.authorization.k8s.io apiGroup: rbac.authorization.k8s.io
``` ```
kube-system命名空间中的默认服务账户： kube-system 命名空间中的默认服务账户：
```yaml ```yaml
subjects: subjects:
@ -254,18 +249,16 @@ subjects:
namespace: kube-system namespace: kube-system
``` ```
名为”qa”命名空间中的所有服务账户： 名为”qa” 命名空间中的所有服务账户：
```yaml ```yaml
subjects: subjects:
- kind: Group - kind: Group
name: system:serviceaccounts:qa name: system:serviceaccounts:qa
apiGroup: rbac.authorization.k8s.io apiGroup: rbac.authorization.k8s.io
``` ​```在集群中的所有服务账户：
在集群中的所有服务账户： ​```yaml
```yaml
subjects: subjects:
- kind: Group - kind: Group
name: system:serviceaccounts name: system:serviceaccounts
@ -279,11 +272,9 @@ subjects:
- kind: Group - kind: Group
name: system:authenticated name: system:authenticated
apiGroup: rbac.authorization.k8s.io apiGroup: rbac.authorization.k8s.io
``` ​```所有未认证的用户（version 1.5+）：
所有未认证的用户（version 1.5+）： ​```yaml
```yaml
subjects: subjects:
- kind: Group - kind: Group
name: system:unauthenticated name: system:unauthenticated
@ -304,62 +295,62 @@ subjects:
## 默认角色与默认角色绑定 ## 默认角色与默认角色绑定
API Server会创建一组默认的`ClusterRole`和`ClusterRoleBinding`对象。 这些默认对象中有许多包含`system:`前缀，表明这些资源由Kubernetes基础组件”拥有”。 对这些资源的修改可能导致非功能性集群（non-functional cluster）。一个例子是`system:node` ClusterRole对象。 这个角色定义了kubelets的权限。如果这个角色被修改，可能会导致kubelets无法正常工作。 API Server 会创建一组默认的 `ClusterRole` 和 `ClusterRoleBinding` 对象。 这些默认对象中有许多包含 `system:` 前缀，表明这些资源由 Kubernetes 基础组件” 拥有”。 对这些资源的修改可能导致非功能性集群（non-functional cluster）。一个例子是 `system:node` ClusterRole 对象。 这个角色定义了 kubelets 的权限。如果这个角色被修改，可能会导致 kubelets 无法正常工作。
所有默认的ClusterRole和ClusterRoleBinding对象都会被标记为`kubernetes.io/bootstrapping=rbac-defaults`。 所有默认的 ClusterRole 和 ClusterRoleBinding 对象都会被标记为 `kubernetes.io/bootstrapping=rbac-defaults`。
### 自动更新 ### 自动更新
每次启动时，API Server都会更新默认ClusterRole所缺乏的各种权限，并更新默认ClusterRoleBinding所缺乏的各个角色绑定主体。 这种自动更新机制允许集群修复一些意外的修改。由于权限和角色绑定主体在新的Kubernetes释出版本中可能变化，这也能够保证角色和角色 绑定始终保持是最新的。 每次启动时，API Server 都会更新默认 ClusterRole 所缺乏的各种权限，并更新默认 ClusterRoleBinding 所缺乏的各个角色绑定主体。 这种自动更新机制允许集群修复一些意外的修改。由于权限和角色绑定主体在新的 Kubernetes 释出版本中可能变化，这也能够保证角色和角色 绑定始终保持是最新的。
如果需要禁用自动更新，请将默认ClusterRole以及ClusterRoleBinding的`rbac.authorization.kubernetes.io/autoupdate` 设置成为`false`。 请注意，缺乏默认权限和角色绑定主体可能会导致非功能性集群问题。 如果需要禁用自动更新，请将默认 ClusterRole 以及 ClusterRoleBinding 的 `rbac.authorization.kubernetes.io/autoupdate` 设置成为 `false`。 请注意，缺乏默认权限和角色绑定主体可能会导致非功能性集群问题。
自Kubernetes 1.6+起，当集群RBAC授权器（RBAC Authorizer）处于开启状态时，可以启用自动更新功能. 自 Kubernetes 1.6 + 起，当集群 RBAC 授权器（RBAC Authorizer）处于开启状态时，可以启用自动更新功能.
### 发现类角色 ### 发现类角色
| 默认ClusterRole | 默认ClusterRoleBinding | 描述 | | 默认 ClusterRole | 默认 ClusterRoleBinding | 描述 |
| --------------------- | ---------------------------------------- | ---------------------------------------- | | --------------------- | ---------------------------------------- | ---------------------------------------- |
| **system:basic-user** | **system:authenticated** and **system:unauthenticated**groups | 允许用户只读访问有关自己的基本信息。 | | **system:basic-user** | **system:authenticated** and **system:unauthenticated**groups | 允许用户只读访问有关自己的基本信息。 |
| **system:discovery** | **system:authenticated** and **system:unauthenticated**groups | 允许只读访问API discovery endpoints, 用于在API级别进行发现和协商。 | | **system:discovery** | **system:authenticated** and **system:unauthenticated**groups | 允许只读访问 API discovery endpoints, 用于在 API 级别进行发现和协商。 |
### 面向用户的角色 ### 面向用户的角色
一些默认角色并不包含`system:`前缀，它们是面向用户的角色。 这些角色包含超级用户角色（`cluster-admin`），即旨在利用ClusterRoleBinding（`cluster-status`）在集群范围内授权的角色， 以及那些使用RoleBinding（`admin`、`edit`和`view`）在特定命名空间中授权的角色。 一些默认角色并不包含 `system:` 前缀，它们是面向用户的角色。 这些角色包含超级用户角色（`cluster-admin`），即旨在利用 ClusterRoleBinding（`cluster-status`）在集群范围内授权的角色， 以及那些使用 RoleBinding（`admin`、`edit` 和 `view`）在特定命名空间中授权的角色。
| 默认ClusterRole | 默认ClusterRoleBinding | 描述 | | 默认 ClusterRole | 默认 ClusterRoleBinding | 描述 |
| ----------------- | ------------------------ | ---------------------------------------- | | ----------------- | ------------------------ | ---------------------------------------- |
| **cluster-admin** | **system:masters** group | 超级用户权限，允许对任何资源执行任何操作。 在**ClusterRoleBinding**中使用时，可以完全控制集群和所有命名空间中的所有资源。 在**RoleBinding**中使用时，可以完全控制RoleBinding所在命名空间中的所有资源，包括命名空间自己。 | | **cluster-admin** | **system:masters** group | 超级用户权限，允许对任何资源执行任何操作。 在 **ClusterRoleBinding** 中使用时，可以完全控制集群和所有命名空间中的所有资源。 在 **RoleBinding** 中使用时，可以完全控制 RoleBinding 所在命名空间中的所有资源，包括命名空间自己。 |
| **admin** | None | 管理员权限，利用**RoleBinding**在某一命名空间内部授予。 在**RoleBinding**中使用时，允许针对命名空间内大部分资源的读写访问， 包括在命名空间内创建角色与角色绑定的能力。 但不允许对资源配额（resource quota）或者命名空间本身的写访问。 | | **admin** | None | 管理员权限，利用 **RoleBinding** 在某一命名空间内部授予。 在 **RoleBinding** 中使用时，允许针对命名空间内大部分资源的读写访问， 包括在命名空间内创建角色与角色绑定的能力。 但不允许对资源配额（resource quota）或者命名空间本身的写访问。 |
| **edit** | None | 允许对某一个命名空间内大部分对象的读写访问，但不允许查看或者修改角色或者角色绑定。 | | **edit** | None | 允许对某一个命名空间内大部分对象的读写访问，但不允许查看或者修改角色或者角色绑定。 |
| **view** | None | 允许对某一个命名空间内大部分对象的只读访问。 不允许查看角色或者角色绑定。 由于可扩散性等原因，不允许查看secret资源。 | | **view** | None | 允许对某一个命名空间内大部分对象的只读访问。 不允许查看角色或者角色绑定。 由于可扩散性等原因，不允许查看 secret 资源。 |
### Core Component Roles ### Core Component Roles
### 核心组件角色 ### 核心组件角色
| 默认ClusterRole | 默认ClusterRoleBinding | 描述 | | 默认 ClusterRole | 默认 ClusterRoleBinding | 描述 |
| ---------------------------------- | ---------------------------------------- | ---------------------------------------- | | ---------------------------------- | ---------------------------------------- | ---------------------------------------- |
| **system:kube-scheduler** | **system:kube-scheduler** user | 允许访问kube-scheduler组件所需要的资源。 | | **system:kube-scheduler** | **system:kube-scheduler** user | 允许访问 kube-scheduler 组件所需要的资源。 |
| **system:kube-controller-manager** | **system:kube-controller-manager** user | 允许访问kube-controller-manager组件所需要的资源。 单个控制循环所需要的权限请参阅[控制器（controller）角色](https://k8smeetup.github.io/docs/admin/authorization/rbac/#controller-roles). | | **system:kube-controller-manager** | **system:kube-controller-manager** user | 允许访问 kube-controller-manager 组件所需要的资源。 单个控制循环所需要的权限请参阅 [控制器（controller）角色](https://k8smeetup.github.io/docs/admin/authorization/rbac/#controller-roles). |
| **system:node** | **system:nodes** group (deprecated in 1.7) | 允许对kubelet组件所需要的资源的访问，**包括读取所有secret和对所有pod的写访问**。 自Kubernetes 1.7开始, 相比较于这个角色，更推荐使用[Node authorizer](https://kubernetes.io/docs/admin/authorization/node/) 以及[NodeRestriction admission plugin](https://kubernetes.io/docs/admin/admission-controllers#NodeRestriction)， 并允许根据调度运行在节点上的pod授予kubelets API访问的权限。 自Kubernetes 1.7开始，当启用`Node`授权模式时，对`system:nodes`用户组的绑定将不会被自动创建。 | | **system:node** | **system:nodes** group (deprecated in 1.7) | 允许对 kubelet 组件所需要的资源的访问，**包括读取所有 secret 和对所有 pod 的写访问**。 自 Kubernetes 1.7 开始，相比较于这个角色，更推荐使用 [Node authorizer](https://kubernetes.io/docs/admin/authorization/node/) 以及 [NodeRestriction admission plugin](https://kubernetes.io/docs/admin/admission-controllers#NodeRestriction)， 并允许根据调度运行在节点上的 pod 授予 kubelets API 访问的权限。 自 Kubernetes 1.7 开始，当启用 `Node` 授权模式时，对 `system:nodes` 用户组的绑定将不会被自动创建。 |
| **system:node-proxier** | **system:kube-proxy** user | 允许对kube-proxy组件所需要资源的访问。 | | **system:node-proxier** | **system:kube-proxy** user | 允许对 kube-proxy 组件所需要资源的访问。 |
### 其它组件角色 ### 其它组件角色
| 默认ClusterRole | 默认ClusterRoleBinding | 描述 | | 默认 ClusterRole | 默认 ClusterRoleBinding | 描述 |
| ---------------------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------ | | ---------------------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------ |
| **system:auth-delegator** | None | 允许委托认证和授权检查。 通常由附加API Server用于统一认证和授权。 | | **system:auth-delegator** | None | 允许委托认证和授权检查。 通常由附加 API Server 用于统一认证和授权。 |
| **system:heapster** | None | [Heapster](https://github.com/kubernetes/heapster)组件的角色。 | | **system:heapster** | None | [Heapster](https://github.com/kubernetes/heapster) 组件的角色。 |
| **system:kube-aggregator** | None | [kube-aggregator](https://github.com/kubernetes/kube-aggregator)组件的角色。 | | **system:kube-aggregator** | None | [kube-aggregator](https://github.com/kubernetes/kube-aggregator) 组件的角色。 |
| **system:kube-dns** | **kube-dns** service account in the **kube-system**namespace | [kube-dns](https://k8smeetup.github.io/docs/admin/dns/)组件的角色。 | | **system:kube-dns** | **kube-dns** service account in the **kube-system**namespace | [kube-dns](https://k8smeetup.github.io/docs/admin/dns/) 组件的角色。 |
| **system:node-bootstrapper** | None | 允许对执行[Kubelet TLS引导（Kubelet TLS bootstrapping）](https://k8smeetup.github.io/docs/admin/kubelet-tls-bootstrapping/)所需要资源的访问. | | **system:node-bootstrapper** | None | 允许对执行 [Kubelet TLS 引导（Kubelet TLS bootstrapping）](https://k8smeetup.github.io/docs/admin/kubelet-tls-bootstrapping/) 所需要资源的访问. |
| **system:node-problem-detector** | None | [node-problem-detector](https://github.com/kubernetes/node-problem-detector)组件的角色。 | | **system:node-problem-detector** | None | [node-problem-detector](https://github.com/kubernetes/node-problem-detector) 组件的角色。 |
| **system:persistent-volume-provisioner** | None | 允许对大部分动态存储卷创建组件（dynamic volume provisioner）所需要资源的访问。 | | **system:persistent-volume-provisioner** | None | 允许对大部分动态存储卷创建组件（dynamic volume provisioner）所需要资源的访问。 |
### 控制器（Controller）角色 ### 控制器（Controller）角色
[Kubernetes controller manager](https://k8smeetup.github.io/docs/admin/kube-controller-manager/)负责运行核心控制循环。 当使用`--use-service-account-credentials`选项运行controller manager时，每个控制循环都将使用单独的服务账户启动。 而每个控制循环都存在对应的角色，前缀名为`system:controller:`。 如果不使用`--use-service-account-credentials`选项时，controller manager将会使用自己的凭证运行所有控制循环，而这些凭证必须被授予相关的角色。 这些角色包括： [Kubernetes controller manager](https://k8smeetup.github.io/docs/admin/kube-controller-manager/) 负责运行核心控制循环。 当使用 `--use-service-account-credentials` 选项运行 controller manager 时，每个控制循环都将使用单独的服务账户启动。 而每个控制循环都存在对应的角色，前缀名为 `system:controller:`。 如果不使用 `--use-service-account-credentials` 选项时，controller manager 将会使用自己的凭证运行所有控制循环，而这些凭证必须被授予相关的角色。 这些角色包括：
- system:controller:attachdetach-controller - system:controller:attachdetach-controller
- system:controller:certificate-controller - system:controller:certificate-controller
@ -386,21 +377,21 @@ API Server会创建一组默认的`ClusterRole`和`ClusterRoleBinding`对象。
## 初始化与预防权限升级 ## 初始化与预防权限升级
RBAC API会阻止用户通过编辑角色或者角色绑定来升级权限。 由于这一点是在API级别实现的，所以在RBAC授权器（RBAC authorizer）未启用的状态下依然可以正常工作。 RBAC API 会阻止用户通过编辑角色或者角色绑定来升级权限。 由于这一点是在 API 级别实现的，所以在 RBAC 授权器（RBAC authorizer）未启用的状态下依然可以正常工作。
用户只有在拥有了角色所包含的所有权限的条件下才能创建／更新一个角色，这些操作还必须在角色所处的相同范围内进行（对于`ClusterRole`来说是集群范围，对于`Role`来说是在与角色相同的命名空间或者集群范围）。 例如，如果用户”user-1”没有权限读取集群范围内的secret列表，那么他也不能创建包含这种权限的`ClusterRole`。为了能够让用户创建／更新角色，需要： 用户只有在拥有了角色所包含的所有权限的条件下才能创建／更新一个角色，这些操作还必须在角色所处的相同范围内进行（对于 `ClusterRole` 来说是集群范围，对于 `Role` 来说是在与角色相同的命名空间或者集群范围）。 例如，如果用户”user-1” 没有权限读取集群范围内的 secret 列表，那么他也不能创建包含这种权限的 `ClusterRole`。为了能够让用户创建／更新角色，需要：
1. 授予用户一个角色以允许他们根据需要创建／更新`Role`或者`ClusterRole`对象。 1. 授予用户一个角色以允许他们根据需要创建／更新 `Role` 或者 `ClusterRole` 对象。
2. 授予用户一个角色包含他们在`Role`或者`ClusterRole`中所能够设置的所有权限。如果用户尝试创建或者修改`Role`或者`ClusterRole`以设置那些他们未被授权的权限时，这些API请求将被禁止。 2. 授予用户一个角色包含他们在 `Role` 或者 `ClusterRole` 中所能够设置的所有权限。如果用户尝试创建或者修改 `Role` 或者 `ClusterRole` 以设置那些他们未被授权的权限时，这些 API 请求将被禁止。
用户只有在拥有所引用的角色中包含的所有权限时才可以创建／更新角色绑定（这些操作也必须在角色绑定所处的相同范围内进行）*或者*用户被明确授权可以在所引用的角色上执行绑定操作。 例如，如果用户”user-1”没有权限读取集群范围内的secret列表，那么他将不能创建`ClusterRole`来引用那些授予了此项权限的角色。为了能够让用户创建／更新角色绑定，需要： 用户只有在拥有所引用的角色中包含的所有权限时才可以创建／更新角色绑定（这些操作也必须在角色绑定所处的相同范围内进行）* 或者 * 用户被明确授权可以在所引用的角色上执行绑定操作。 例如，如果用户”user-1” 没有权限读取集群范围内的 secret 列表，那么他将不能创建 `ClusterRole` 来引用那些授予了此项权限的角色。为了能够让用户创建／更新角色绑定，需要：
1. 授予用户一个角色以允许他们根据需要创建／更新`RoleBinding`或者`ClusterRoleBinding`对象。 1. 授予用户一个角色以允许他们根据需要创建／更新 `RoleBinding` 或者 `ClusterRoleBinding` 对象。
2. 授予用户绑定某一特定角色所需要的权限： 2. 授予用户绑定某一特定角色所需要的权限：
- 隐式地，通过授予用户所有所引用的角色中所包含的权限 - 隐式地，通过授予用户所有所引用的角色中所包含的权限
- 显式地，通过授予用户在特定Role（或者ClusterRole）对象上执行`bind`操作的权限 - 显式地，通过授予用户在特定 Role（或者 ClusterRole）对象上执行 `bind` 操作的权限
例如，下面例子中的ClusterRole和RoleBinding将允许用户”user-1”授予其它用户”user-1-namespace”命名空间内的`admin`、`edit`和`view`等角色和角色绑定。 例如，下面例子中的 ClusterRole 和 RoleBinding 将允许用户”user-1” 授予其它用户”user-1-namespace” 命名空间内的 `admin`、`edit` 和 `view` 等角色和角色绑定。
```yaml ```yaml
apiVersion: rbac.authorization.k8s.io/v1beta1 apiVersion: rbac.authorization.k8s.io/v1beta1
@ -433,56 +424,56 @@ subjects:
当初始化第一个角色和角色绑定时，初始用户需要能够授予他们尚未拥有的权限。 初始化初始角色和角色绑定时需要： 当初始化第一个角色和角色绑定时，初始用户需要能够授予他们尚未拥有的权限。 初始化初始角色和角色绑定时需要：
- 使用包含`system：masters`用户组的凭证，该用户组通过默认绑定绑定到`cluster-admin`超级用户角色。 - 使用包含 `system：masters` 用户组的凭证，该用户组通过默认绑定绑定到 `cluster-admin` 超级用户角色。
- 如果您的API Server在运行时启用了非安全端口（`--insecure-port`），您也可以通过这个没有施行认证或者授权的端口发送角色或者角色绑定请求。 - 如果您的 API Server 在运行时启用了非安全端口（`--insecure-port`），您也可以通过这个没有施行认证或者授权的端口发送角色或者角色绑定请求。
## 一些命令行工具 ## 一些命令行工具
有两个`kubectl`命令可以用于在命名空间内或者整个集群内授予角色。 有两个 `kubectl` 命令可以用于在命名空间内或者整个集群内授予角色。
### `kubectl create rolebinding` ### `kubectl create rolebinding`
在某一特定命名空间内授予`Role`或者`ClusterRole`。示例如下： 在某一特定命名空间内授予 `Role` 或者 `ClusterRole`。示例如下：
- 在名为”acme”的命名空间中将`admin` `ClusterRole`授予用户”bob”： - 在名为”acme” 的命名空间中将 `admin` `ClusterRole` 授予用户”bob”：
`kubectl create rolebinding bob-admin-binding --clusterrole=admin --user=bob --namespace=acme` `kubectl create rolebinding bob-admin-binding --clusterrole=admin --user=bob --namespace=acme`
- 在名为”acme”的命名空间中将`view` `ClusterRole`授予服务账户”myapp”： - 在名为”acme” 的命名空间中将 `view` `ClusterRole` 授予服务账户”myapp”：
`kubectl create rolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp --namespace=acme` `kubectl create rolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp --namespace=acme`
### `kubectl create clusterrolebinding` ### `kubectl create clusterrolebinding`
在整个集群中授予`ClusterRole`，包括所有命名空间。示例如下： 在整个集群中授予 `ClusterRole`，包括所有命名空间。示例如下：
- 在整个集群范围内将`cluster-admin` `ClusterRole`授予用户”root”： - 在整个集群范围内将 `cluster-admin` `ClusterRole` 授予用户”root”：
`kubectl create clusterrolebinding root-cluster-admin-binding --clusterrole=cluster-admin --user=root` `kubectl create clusterrolebinding root-cluster-admin-binding --clusterrole=cluster-admin --user=root`
- 在整个集群范围内将`system:node` `ClusterRole`授予用户”kubelet”： - 在整个集群范围内将 `system:node` `ClusterRole` 授予用户”kubelet”：
`kubectl create clusterrolebinding kubelet-node-binding --clusterrole=system:node --user=kubelet` `kubectl create clusterrolebinding kubelet-node-binding --clusterrole=system:node --user=kubelet`
- 在整个集群范围内将`view` `ClusterRole`授予命名空间”acme”内的服务账户”myapp”： - 在整个集群范围内将 `view` `ClusterRole` 授予命名空间”acme” 内的服务账户”myapp”：
`kubectl create clusterrolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp` `kubectl create clusterrolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp`
请参阅CLI帮助文档以获得上述命令的详细用法 请参阅 CLI 帮助文档以获得上述命令的详细用法
## 服务账户（Service Account）权限 ## 服务账户（Service Account）权限
默认的RBAC策略将授予控制平面组件（control-plane component）、节点（node）和控制器（controller）一组范围受限的权限， 但对于”kube-system”命名空间以外的服务账户，则*不授予任何权限*（超出授予所有认证用户的发现权限）。 默认的 RBAC 策略将授予控制平面组件（control-plane component）、节点（node）和控制器（controller）一组范围受限的权限， 但对于”kube-system” 命名空间以外的服务账户，则 * 不授予任何权限 *（超出授予所有认证用户的发现权限）。
这一点允许您根据需要向特定服务账号授予特定权限。 细粒度的角色绑定将提供更好的安全性，但需要更多精力管理。 更粗粒度的授权可能授予服务账号不需要的API访问权限（甚至导致潜在授权扩散），但更易于管理。 这一点允许您根据需要向特定服务账号授予特定权限。 细粒度的角色绑定将提供更好的安全性，但需要更多精力管理。 更粗粒度的授权可能授予服务账号不需要的 API 访问权限（甚至导致潜在授权扩散），但更易于管理。
从最安全到最不安全可以排序以下方法： 从最安全到最不安全可以排序以下方法：
1. 对某一特定应用程序的服务账户授予角色（最佳实践） 1. 对某一特定应用程序的服务账户授予角色（最佳实践）
要求应用程序在其pod规范（pod spec）中指定`serviceAccountName`字段，并且要创建相应服务账户（例如通过API、应用程序清单或者命令`kubectl create serviceaccount`等）。 要求应用程序在其 pod 规范（pod spec）中指定 `serviceAccountName` 字段，并且要创建相应服务账户（例如通过 API、应用程序清单或者命令 `kubectl create serviceaccount` 等）。
例如，在”my-namespace”命名空间中授予服务账户”my-sa”只读权限： 例如，在”my-namespace” 命名空间中授予服务账户”my-sa” 只读权限：
```bash ```bash
kubectl create rolebinding my-sa-view \ kubectl create rolebinding my-sa-view \
@ -491,13 +482,13 @@ subjects:
--namespace=my-namespace --namespace=my-namespace
``` ```
2. 在某一命名空间中授予”default”服务账号一个角色 2. 在某一命名空间中授予”default” 服务账号一个角色
如果一个应用程序没有在其pod规范中指定`serviceAccountName`，它将默认使用”default”服务账号。 如果一个应用程序没有在其 pod 规范中指定 `serviceAccountName`，它将默认使用”default” 服务账号。
注意：授予”default”服务账号的权限将可用于命名空间内任何没有指定`serviceAccountName`的pod。 注意：授予”default” 服务账号的权限将可用于命名空间内任何没有指定 `serviceAccountName` 的 pod。
下面的例子将在”my-namespace”命名空间内授予”default”服务账号只读权限： 下面的例子将在”my-namespace” 命名空间内授予”default” 服务账号只读权限：
```bash ```bash
kubectl create rolebinding default-view \ kubectl create rolebinding default-view \
@ -506,7 +497,7 @@ subjects:
--namespace=my-namespace --namespace=my-namespace
``` ```
目前，许多[加载项（addon）](https://kubernetes.io/docs/concepts/cluster-administration/addons/)作为”kube-system”命名空间中的”default”服务帐户运行。 要允许这些加载项使用超级用户访问权限，请将cluster-admin权限授予”kube-system”命名空间中的”default”服务帐户。 注意：启用上述操作意味着”kube-system”命名空间将包含允许超级用户访问API的秘钥。 目前，许多 [加载项（addon）](https://kubernetes.io/docs/concepts/cluster-administration/addons/) 作为”kube-system” 命名空间中的”default” 服务帐户运行。 要允许这些加载项使用超级用户访问权限，请将 cluster-admin 权限授予”kube-system” 命名空间中的”default” 服务帐户。 注意：启用上述操作意味着”kube-system” 命名空间将包含允许超级用户访问 API 的秘钥。
```bash ```bash
kubectl create clusterrolebinding add-on-cluster-admin \ kubectl create clusterrolebinding add-on-cluster-admin \
@ -518,7 +509,7 @@ subjects:
如果您希望命名空间内的所有应用程序都拥有同一个角色，无论它们使用什么服务账户，您可以为该命名空间的服务账户用户组授予角色。 如果您希望命名空间内的所有应用程序都拥有同一个角色，无论它们使用什么服务账户，您可以为该命名空间的服务账户用户组授予角色。
下面的例子将授予”my-namespace”命名空间中的所有服务账户只读权限： 下面的例子将授予”my-namespace” 命名空间中的所有服务账户只读权限：
```bash ```bash
kubectl create rolebinding serviceaccounts-view \ kubectl create rolebinding serviceaccounts-view \
@ -543,7 +534,7 @@ subjects:
如果您根本不关心权限分块，您可以对所有服务账户授予超级用户访问权限。 如果您根本不关心权限分块，您可以对所有服务账户授予超级用户访问权限。
警告：这种做法将允许任何具有读取权限的用户访问secret或者通过创建一个容器的方式来访问超级用户的凭据。 警告：这种做法将允许任何具有读取权限的用户访问 secret 或者通过创建一个容器的方式来访问超级用户的凭据。
```bash ```bash
kubectl create clusterrolebinding serviceaccounts-cluster-admin \ kubectl create clusterrolebinding serviceaccounts-cluster-admin \
@ -551,31 +542,29 @@ subjects:
--group=system:serviceaccounts --group=system:serviceaccounts
``` ```
## 从版本1.5升级 ## 从版本 1.5 升级
在Kubernetes 1.6之前，许多部署使用非常宽泛的ABAC策略，包括授予对所有服务帐户的完整API访问权限。 在 Kubernetes 1.6 之前，许多部署使用非常宽泛的 ABAC 策略，包括授予对所有服务帐户的完整 API 访问权限。
默认的RBAC策略将授予控制平面组件（control-plane components）、节点（nodes）和控制器（controller）一组范围受限的权限， 但对于”kube-system”命名空间以外的服务账户，则*不授予任何权限*（超出授予所有认证用户的发现权限）。 默认的 RBAC 策略将授予控制平面组件（control-plane components）、节点（nodes）和控制器（controller）一组范围受限的权限， 但对于”kube-system” 命名空间以外的服务账户，则 *不授予任何权限*（超出授予所有认证用户的发现权限）。
虽然安全性更高，但这可能会影响到期望自动接收API权限的现有工作负载。 以下是管理此转换的两种方法： 虽然安全性更高，但这可能会影响到期望自动接收 API 权限的现有工作负载。 以下是管理此转换的两种方法：
### 并行授权器（authorizer） ### 并行授权器（authorizer）
同时运行RBAC和ABAC授权器，并包括旧版ABAC策略： 同时运行 RBAC 和 ABAC 授权器，并包括旧版 ABAC 策略：
``` ```--authorization-mode=RBAC,ABAC --authorization-policy-file=mypolicy.jsonl```
--authorization-mode=RBAC,ABAC --authorization-policy-file=mypolicy.jsonl
```
RBAC授权器将尝试首先授权请求。如果RBAC授权器拒绝API请求，则ABAC授权器将被运行。这意味着RBAC策略*或者*ABAC策略所允许的任何请求都是可通过的。 RBAC 授权器将尝试首先授权请求。如果 RBAC 授权器拒绝 API 请求，则 ABAC 授权器将被运行。这意味着 RBAC 策略 *或者* ABAC 策略所允许的任何请求都是可通过的。
当以日志级别为2或更高（`--v = 2`）运行时，您可以在API Server日志中看到RBAC拒绝请求信息（以`RBAC DENY:`为前缀）。 您可以使用该信息来确定哪些角色需要授予哪些用户，用户组或服务帐户。 一旦[授予服务帐户角色](https://k8smeetup.github.io/docs/admin/authorization/rbac/#service-account-permissions)，并且服务器日志中没有RBAC拒绝消息的工作负载正在运行，您可以删除ABAC授权器。 当以日志级别为 2 或更高（`--v = 2`）运行时，您可以在 API Server 日志中看到 RBAC 拒绝请求信息（以 `RBAC DENY:` 为前缀）。 您可以使用该信息来确定哪些角色需要授予哪些用户，用户组或服务帐户。 一旦 [授予服务帐户角色](https://k8smeetup.github.io/docs/admin/authorization/rbac/#service-account-permissions)，并且服务器日志中没有 RBAC 拒绝消息的工作负载正在运行，您可以删除 ABAC 授权器。
### 宽泛的RBAC权限 ### 宽泛的 RBAC 权限
您可以使用RBAC角色绑定来复制一个宽泛的策略。 您可以使用 RBAC 角色绑定来复制一个宽泛的策略。
**警告：以下政策略允许所有服务帐户作为集群管理员。 运行在容器中的任何应用程序都会自动接收服务帐户凭据，并且可以对API执行任何操作，包括查看secret和修改权限。 因此，并不推荐使用这种策略。** **警告：以下政策略允许所有服务帐户作为集群管理员。 运行在容器中的任何应用程序都会自动接收服务帐户凭据，并且可以对 API 执行任何操作，包括查看 secret 和修改权限。 因此，并不推荐使用这种策略。**
```bash ```bash
kubectl create clusterrolebinding permissive-binding \ kubectl create clusterrolebinding permissive-binding \

11
concepts/replicaset.md
View File

@ -1,12 +1,12 @@
# ReplicationController和ReplicaSet # ReplicationController 和 ReplicaSet
ReplicationController用来确保容器应用的副本数始终保持在用户定义的副本数，即如果有容器异常退出，会自动创建新的Pod来替代；而如果异常多出来的容器也会自动回收。 ReplicationController 用来确保容器应用的副本数始终保持在用户定义的副本数，即如果有容器异常退出，会自动创建新的 Pod 来替代；而如果异常多出来的容器也会自动回收。
在新版本的Kubernetes中建议使用ReplicaSet来取代ReplicationController。ReplicaSet跟ReplicationController没有本质的不同，只是名字不一样，并且ReplicaSet支持集合式的selector。 在新版本的 Kubernetes 中建议使用 ReplicaSet 来取代 ReplicationController。ReplicaSet 跟 ReplicationController 没有本质的不同，只是名字不一样，并且 ReplicaSet 支持集合式的 selector。
虽然ReplicaSet可以独立使用，但一般还是建议使用 Deployment 来自动管理ReplicaSet，这样就无需担心跟其他机制的不兼容问题（比如ReplicaSet不支持rolling-update但Deployment支持）。 虽然 ReplicaSet 可以独立使用，但一般还是建议使用 Deployment 来自动管理 ReplicaSet，这样就无需担心跟其他机制的不兼容问题（比如 ReplicaSet 不支持 rolling-update 但 Deployment 支持）。
ReplicaSet示例： ReplicaSet 示例：
```yaml ```yaml
apiVersion: extensions/v1beta1 apiVersion: extensions/v1beta1
@ -55,4 +55,3 @@ spec:
ports: ports:
- containerPort: 80 - containerPort: 80
``` ```

2
concepts/taint-and-toleration.md
View File

@ -1,4 +1,4 @@
# Taint和Toleration（污点和容忍） # Taint 和 Toleration（污点和容忍）
Taint（污点）和 Toleration（容忍）可以作用于 node 和 pod 上，其目的是优化 pod 在集群间的调度，这跟节点亲和性类似，只不过它们作用的方式相反，具有 taint 的 node 和 pod 是互斥关系，而具有节点亲和性关系的 node 和 pod 是相吸的。另外还有可以给 node 节点设置 label，通过给 pod 设置 `nodeSelector` 将 pod 调度到具有匹配标签的节点上。 Taint（污点）和 Toleration（容忍）可以作用于 node 和 pod 上，其目的是优化 pod 在集群间的调度，这跟节点亲和性类似，只不过它们作用的方式相反，具有 taint 的 node 和 pod 是互斥关系，而具有节点亲和性关系的 node 和 pod 是相吸的。另外还有可以给 node 节点设置 label，通过给 pod 设置 `nodeSelector` 将 pod 调度到具有匹配标签的节点上。