乐趣区

关于程序员:Kubernetes环境鉴权与自动发现

概览文章中提到了 k8s 的鉴权模式,简略回顾下:

  • RBAC:Role-based access control 是基于角色的访问控制
  • ABAC:Atrribute-based access control 是基于属性的访问控制
  • Node Authorization:节点鉴权,专门用于 kubelet 收回的 api 申请进行鉴权
  • Webhook Authorization:webhook 是一种 http 回调,kube-apiserver 配置 webhook 时,会设置回调 webhook 的规定,这些规定中蕴含了调用的 api
    group、version、operation、scope 等信息。

有仔细的小伙伴指出,RBAC 的角色能够作为 ABAC 的属性来配置。感激小伙伴斧正,ABAC 能够更细粒度的管制权限,相应配置起来也更简单。

kubernetes 鉴权

选定 RBAC 模式后,对于角色,有 Role 和 ClusterRole,对应对象的绑定别离为: RoleBinding 和 ClusterRoleBinding。
Role 创立后归属于特定的 namespace,个别与特定 namespace 的权限绑定,而 ClusterRole 不属于任何 namespace,通常与一组权限绑定。

ClusterRole 通常用于

  • 定义指定 namespace 资源的拜访权限,并在某个 namespace 范畴内授予拜访权限;
  • 定义指定 namespace 资源的拜访权限,并在跨 namespace 范畴内授予拜访权限;
  • 定义集群范畴内的资源拜访权限。

官网文档举荐,如果在单个 namespace 内定义角色则应用 Role,如果是定义集群范畴的角色,则应用 ClusterRole。
要监控 kubernetes 组件和集群范畴内业务以及为了通用性,所以咱们抉择 ClusterRole 和 ClusterRoleBinding。

权限盘点

咱们来盘点须要监控的对象。

  • 组件监控,拜访组件 metrics 接口,须要非资源对象的 get/list 权限。拜访/api/v1/xxx /apis/<group>/<version>/xxx 都属于非资源对象申请。
  • node、pod 对象的资源监控,须要拜访 kubelet metrics 接口,权限同上。
  • serverless 场景下,如果不能间接拜访 kubelet,还须要 node/proxy 的 get 权限。
  • node、pod 对象的数量监控,须要资源对象的 get/list 权限。
  • 主动发现, 须要 service、endpoint 的 get/list+watch 权限。
  • 如果要从 metrics server 拿数据,还须要 metrics.k8s.io 的拜访权限。

不管须要多少权限,一个准则就是按需申请,最小化申请。指标采集都是读权限,根本都是 get、list。主动发现要达到发现及时,须要 watch endpoints 变动。

如何确定资源对象的 api groups 和 version 呢?能够应用 kubectl api-resources -o wide 来查看。新版本的 APIVERSION 蕴含了 api groups 和 version 信息。

权限配置

根本的权限配置如下

  - apiGroups: [""]
    resources:
      - pods
      - nodes
      - nodes/stats
      - nodes/metrics
      - nodes/proxy
      - services
      - endpoints
    verbs: ["get", "list", "watch"]
  - nonResourceURLs: ["/metrics"]
    verbs: ["get"]

将权限填充到 ClusterRole 中

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  annotations: {}
  labels:
    app: n9e
    component: categraf
  name: categraf-role
rules:
  - apiGroups: [""]
    resources:
      - nodes
      - nodes/stats
      - nodes/metrics
      - nodes/proxy
      - services
      - endpoints
      - pods
    verbs: ["get", "list", "watch"]
  - nonResourceURLs: ["/metrics"]
    verbs: ["get"]

有了 ClusterRole, 创立 ClusterRoleBinding 之前,还须要一个 ServiceAccount,用于存储 api 的拜访凭据,这个凭据能够以 token 模式挂载到 Pod 内。
也能够间接解析用于 Pod 内部应用。

apiVersion: v1
kind: ServiceAccount
metadata:
  annotations: {}
  labels:
    app: n9e
    component: categraf
  name: categraf-serviceaccount
  namespace: ${NAMESPACE}

留神,ServiceAccount 须要指定 namespace,须要跟 categraf 行将部署的 namespace 保持一致。
利用 ClusterRoleBinding 将 ClusterRole 和 ServiceAccount 关联起来

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  annotations: {}
  labels:
    app: n9e
    component: categraf
  name: categraf-rolebinding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: categraf-role
subjects:
- kind: ServiceAccount
  name: categraf-serviceaccount
  namespace: ${NAMESPACE}

当初 ClusterRoleBinding 曾经将权限和票据关联起来了。
备注:创立实现后,ServiceAccount 会主动创立一个 secret, 这个 secret 会主动挂载到后续创立的 categraf pod 内。

能够通过 kubectl get secrets -n monitoring categraf-serviceaccount-token-frqc5 -o jsonpath={.data.token} | base64 -d
取得 token 内容,这样通过curl -s -k -H "Authorization: Bearer $TOKEN" 即可拜访 apiserver,用来调试。

kubernetes 组件的服务发现

1. 监控对象部署在 pod 内

当创立 service(带选择符)时,k8s 会主动为 pod 创立 endpoint,这样 service 和 pod 就关联起来了。利用这个个性,咱们能够及时发现 pod 的变动。
如果组件是部署在 pod 内,咱们就能够间接利用这个个性进行采集。比方 kubeadm 部署的集群,apiserver 自身就曾经创立了对应的 service。

...
  - job_name: "apiserver"
    metrics_path: "/metrics"
    kubernetes_sd_configs:
      - role: endpoints # 看这里
    scheme: https
    tls_config:
      insecure_skip_verify: true
    authorization:
      credentials_file: /var/run/secrets/kubernetes.io/serviceaccount/token
    relabel_configs:
      - source_labels:
          [
            __meta_kubernetes_namespace,
            __meta_kubernetes_service_name,
            __meta_kubernetes_endpoint_port_name,
          ]
        action: keep
        regex: default;kubernetes;https
...

2. 监控对象部署在物理机(文件服务发现)

如果组件是以二进制形式部署在物理机,又没有其余服务发现的伎俩。那能够利用 prometheus 相似的文件服务发现,当组件有变更时,间接在目录中增加删除蕴含指标信息的文件就好了。
这里多提一点,之前有小伙伴提出,categraf 提供一个注册接口,服务向 categraf 注册,而后 categraf 去拉注册指标指标。categraf 自身的定位是一个采集器,没有服务发现的性能。
提一个最简略的问题,如果 categraf 挂了重启,然而采集指标没有发现,这里就会有很多数据不能被采集了。再有就是集中式拉取形式,提供 push 接口,会把业务和采集器耦合更深了。
这种形式 并不可取。

....
  - job_name: 'coredns'
    file_sd_configs:
    - files:
      - /home/work/prometheus/file_sd_config/*.json
...

在 file_sd_config 目录下放一个 json 文件,如下:

[
  {
    "labels": {"job": "coredns"},
    "targets": ["172.16.6.160:9153"]
  }
]

等减少新的 coredns 后,只须要再减少一份 json 配置(这里只是为了举例说明,间接批改 coredns.json 成果一样)。不须要再做任何其余操作

[
  {
    "labels": {"job": "coredns"},
    "targets": ["172.16.0.85:9153"]
  }
]

3. 其余服务发现形式

采集器 categraf 集成了 prometheus 的 agent mode 模式, 如果你应用了其余服务发现形式,例如 consul,则能够和 categraf 无缝对接了。
除此之外,还反对 docker_swarm_sd_configs,docker_sd_config, dns_sd_configs, http_sd_configs 等 prometheus 所反对的服务发现形式。

本次次要介绍 kubernete 权限和服务主动发现。感激大家继续关注,欢送各位批评指正, 欢送各位点赞 转发和珍藏。

对于作者

本文作者是孔飞,来自快猫星云(https://flashcat.cloud)是 Kubernetes 和 Prometheus 专家,快猫团队致力于让监控更简略,为企业提供稳定性保障的产品,也提供夜莺监控的技术支持服务,性价比极高,有趣味的小伙伴欢送分割咱们

对于夜莺监控

夜莺监控是一款开源云原生监控剖析零碎,权且能够看做是 Prometheus 的企业级版本。Kubernetes 监控系列文章都是基于夜莺监控来梳理,欢送关注

  • 夜莺站点:https://n9e.github.io/
  • 仓库地址:https://github.com/ccfos/nightingale

更多文章

更多云原生监控相干文章、教程,欢送关注咱们:

本文由 mdnice 多平台公布

退出移动版