V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
balabalaXMX
V2EX  ›  Kubernetes

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

  •  
  •   balabalaXMX · 2023-01-06 15:17:25 +08:00 · 819 次点击
    这是一个创建于 447 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

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

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

    david98
        1
    david98  
       2023-01-06 15:29:32 +08:00
    不是 pod 对 api server 的访问
    你部署 pod 的时候 也是要通过 kubectl 调用 api server 来创建的呀
    mingqing
        2
    mingqing  
       2023-01-06 16:12:51 +08:00
    因为 k8s 是容器管理调度平台,而容器就代表着可能时时刻刻都在发生着状态变化,集群需要感知这组状态,各个资源之间就是通过 API Server 去解耦实现。

    普通 Pod 不一定要去访问 API Server ;一般控制器之类需要,或者云原生应用需要。
    novolunt
        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
    Frankcox
        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 。
    Frankcox
        6
    Frankcox  
       2023-01-06 17:08:25 +08:00
    上面说的是所谓“Pod 创建和销毁”的通信机制,至于你说的 Pod 和 API Server 的访问,我看了楼上才想起来,比如你在 Pod 里部署了一个访问本集群的应用,那确实是某种“Pod 对 API Server 的访问”,不过我理解这种情况和外部使用 kubectl 访问差不多。
    ryan4yin
        7
    ryan4yin  
       2023-01-08 17:42:34 +08:00
    可以看看 kyverno 官方的一些 examples ,应用场景还挺多的,很用来做很多骚操作,简单举两个例子:

    - 在部署 pod 时自动修改其中部分参数,比如将 requests/limits 调到低于某个固定值避免滥用资源。当然也可以直接拒绝部署这个配置
    - 在名字空间之间同步数据,比如实现跨名字空间的 configmaps/secrets 同步
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   3702 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 32ms · UTC 05:03 · PVG 13:03 · LAX 22:03 · JFK 01:03
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.