关于程序员: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/v1kind: ClusterRolemetadata:  annotations: {}  labels:    app: n9e    component: categraf  name: categraf-rolerules:  - 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: v1kind: ServiceAccountmetadata:  annotations: {}  labels:    app: n9e    component: categraf  name: categraf-serviceaccount  namespace: ${NAMESPACE}

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

apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRoleBindingmetadata:  annotations: {}  labels:    app: n9e    component: categraf  name: categraf-rolebindingroleRef:  apiGroup: rbac.authorization.k8s.io  kind: ClusterRole  name: categraf-rolesubjects:- 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