这是一个创建于 688 天前的主题，其中的信息可能已经有所发展或是发生改变。
以前一直是简单地直接使用 k8s ，最近需要自己去搭建部署，查看资料k8s 官网花了很大篇幅说 API 准入机制，包括一些有名的 RBAC 机制只鹅里的，有一些疑问。
首先，我理解这里的权限控制就是对 API Server 的访问权限，也就是控制外部用户和 pod 对 API Server 的访问， API Server 的功能就是管理集群的资源和元数据，其实就是对 etcd 数据库的读写，比如 Pod 的部署和注销，修改一些配置文件，在我看来就是一些运维层面的功能。
那么 Pod 对 API Server 的访问有些什么应用场景？为什么要去访问 API Server ？ 小白问题轻喷。
 |
1
david98 2023-01-06 15:29:32 +08:00
不是 pod 对 api server 的访问
你部署 pod 的时候 也是要通过 kubectl 调用 api server 来创建的呀 |
 |
2
mingqing 2023-01-06 16:12:51 +08:00
因为 k8s 是容器管理调度平台，而容器就代表着可能时时刻刻都在发生着状态变化，集群需要感知这组状态，各个资源之间就是通过 API Server 去解耦实现。
普通 Pod 不一定要去访问 API Server ；一般控制器之类需要，或者云原生应用需要。 |
 |
3
novolunt 2023-01-06 16:54:30 +08:00  1
场景一：假设你需要创建一个 sa 账号，分发给外部人员使用，这时候你就需要给它绑定权限，主要是对资源的管理，比如 node ，pod ，secret ，cm 等，根据使用者的需要设置固定的权限。
场景二：当你部署的应用是管理类应用，比如可以管理整个集群的，或者管理某个应用，比如 prometheus operator 就是管理 prometheus ，这时候需要创建不同的 sa 账户，对告警规则，告警等设置不同的权限。 以下是场景二的例子: --- apiVersion: v1 kind: ServiceAccount metadata: name: monitoring-updater namespace: monitoring --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: monitoring-updater rules: - apiGroups: [""] resources: ["secrets"] verbs: - "*" - apiGroups: ["monitoring.coreos.com"] resources: ["prometheusrules"] verbs: - "*" --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: monitoring-updater subjects: - kind: ServiceAccount name: monitoring-updater namespace: monitoring roleRef: kind: ClusterRole name: monitoring-updater apiGroup: rbac.authorization.k8s.io #检查是否有 secret 和 PrometheusRule 权限 kubectl auth can-i create secret --as=system:serviceaccount:monitoring:monitoring-updater -n monitoring kubectl auth can-i create prometheusrule --as=system:serviceaccount:monitoring:monitoring-updater -n monitoring |
 |
4
Frankcox 2023-01-06 16:56:34 +08:00
不太明白你说的”Pod 对 API Server 的访问”具体指的是什么。
Pod 的管理是由 kubelet 从 etcd 中获取到预期的状态之后，由 kubelet 进行调度处理，其中 kubelet 与 etcd 的交互是经由 API Server 进行通信的（ Master 部分），但不是具体 Pod 通过 API Server 直接与 etcd 交互，能对容器进行管理的只是 kubelet 通过 CRI ，Pod Network 相关的则是由 Kubelet 与 CNI 控制。这块你可以好好了解下声明式 API 。 至于 API Server ，你可以简单看成集群管理层面的数据总线，外部通过 API Server 来对集群进行调度访问(kubectl ，client-go 等)，集群 Master 的核心组件(controller-manager 和 Scheduler)之间的通信也是通过 API Server 。 |
|
5
Frankcox 2023-01-06 16:57:56 +08:00
|
|
6
Frankcox 2023-01-06 17:08:25 +08:00
上面说的是所谓“Pod 创建和销毁”的通信机制，至于你说的 Pod 和 API Server 的访问，我看了楼上才想起来，比如你在 Pod 里部署了一个访问本集群的应用，那确实是某种“Pod 对 API Server 的访问”，不过我理解这种情况和外部使用 kubectl 访问差不多。
|
 |
7
ryan4yin 2023-01-08 17:42:34 +08:00
可以看看 kyverno 官方的一些 examples ，应用场景还挺多的，很用来做很多骚操作，简单举两个例子：
- 在部署 pod 时自动修改其中部分参数，比如将 requests/limits 调到低于某个固定值避免滥用资源。当然也可以直接拒绝部署这个配置 - 在名字空间之间同步数据，比如实现跨名字空间的 configmaps/secrets 同步 |
Select Language