k8s 的 API 准入机制的具体应用场景

[balabalaXMX]

以前一直是简单地直接使用 k8s ，最近需要自己去搭建部署，查看资料k8s 官网花了很大篇幅说 API 准入机制，包括一些有名的 RBAC 机制只鹅里的，有一些疑问。

首先，我理解这里的权限控制就是对 API Server 的访问权限，也就是控制外部用户和 pod 对 API Server 的访问， API Server 的功能就是管理集群的资源和元数据，其实就是对 etcd 数据库的读写，比如 Pod 的部署和注销，修改一些配置文件，在我看来就是一些运维层面的功能。

那么 Pod 对 API Server 的访问有些什么应用场景？为什么要去访问 API Server ？ 小白问题轻喷。

[david98]

不是 pod 对 api server 的访问
你部署 pod 的时候 也是要通过 kubectl 调用 api server 来创建的呀

[mingqing]

因为 k8s 是容器管理调度平台，而容器就代表着可能时时刻刻都在发生着状态变化，集群需要感知这组状态，各个资源之间就是通过 API Server 去解耦实现。

普通 Pod 不一定要去访问 API Server ；一般控制器之类需要，或者云原生应用需要。

[novolunt]

场景一：假设你需要创建一个 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

[Frankcox]

不太明白你说的”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 。

[Frankcox]

https://godleon.github.io/blog/Kubernetes/k8s-CoreConcept-Cluster-Architecture/
https://cizixs.com/2016/10/25/kubernetes-intro-kubelet/

[Frankcox]

上面说的是所谓“Pod 创建和销毁”的通信机制，至于你说的 Pod 和 API Server 的访问，我看了楼上才想起来，比如你在 Pod 里部署了一个访问本集群的应用，那确实是某种“Pod 对 API Server 的访问”，不过我理解这种情况和外部使用 kubectl 访问差不多。

[ryan4yin]

可以看看 kyverno 官方的一些 examples ，应用场景还挺多的，很用来做很多骚操作，简单举两个例子：

- 在部署 pod 时自动修改其中部分参数，比如将 requests/limits 调到低于某个固定值避免滥用资源。当然也可以直接拒绝部署这个配置
- 在名字空间之间同步数据，比如实现跨名字空间的 configmaps/secrets 同步