Kubernetes监控手册06-监控APIServer

小小小幸运  金牌会员 | 2023-2-2 17:20:57 | 显示全部楼层 | 阅读模式
打印 上一主题 下一主题
楼主

主题 840|帖子 840|积分 2520

写在前面

如果是用的公有云托管的 Kubernetes 集群，控制面的组件都交由云厂商托管的，那作为客户的我们就省事了，基本不用操心 APIServer 的运维。个人也推荐使用云厂商这个服务，毕竟 Kubernetes 还是有点复杂的，升级也不好搞，我们自己来维护整个集群，性价比有点低。当然，如果因为各种原因最后我们还是要维护控制面这些组件，那就要好好看看本系列接下来的几篇博客了。
黑盒测试

APIServer 在 Kubernetes 架构中非常核心，是所有 API 的入口，APIServer 也暴露了 metrics 数据，我们尝试获取一下：
  1. [root@tt-fc-dev01.nj etcd]# ss -tlpn|grep apiserver
  2. LISTEN 0      128                *:6443             *:*    users:(("kube-apiserver",pid=164445,fd=7))
  4. [root@tt-fc-dev01.nj etcd]# curl -s http://localhost:6443/metrics
  5. Client sent an HTTP request to an HTTPS server.
  7. [root@tt-fc-dev01.nj etcd]# curl -s -k https://localhost:6443/metrics
  8. {
  9.   "kind": "Status",
  10.   "apiVersion": "v1",
  11.   "metadata": {},
  12.   "status": "Failure",
  13.   "message": "forbidden: User "system:anonymous" cannot get path "/metrics"",
  14.   "reason": "Forbidden",
  15.   "details": {},
  16.   "code": 403
  17. }
复制代码
解释一下上面的命令和结果。首先我通过 ss 命令查看 apiserver 模块监听在哪些端口，发现这个进程在 6443 端口有监听。然后，使用 curl 命令请求 6443 的 metrics 接口，结果又说这是一个 HTTPS Server，不能用 HTTP 协议请求。好，那我用 HTTPS 协议请求，自签证书，加了 -k 参数，返回 Forbidden，说没权限访问 /metrics 接口。OK，那看来是需要 Token 鉴权，我们创建一下相关的 ServiceAccount。
准备认证信息

下面的内容可以保存为 auth-server.yaml。
  1. ---
  2. apiVersion: rbac.authorization.k8s.io/v1
  3. kind: ClusterRole
  4. metadata:
  5.   name: categraf
  6. rules:
  7.   - apiGroups: [""]
  8.     resources:
  9.       - nodes
  10.       - nodes/metrics
  11.       - nodes/stats
  12.       - nodes/proxy
  13.       - services
  14.       - endpoints
  15.       - pods
  16.     verbs: ["get", "list", "watch"]
  17.   - apiGroups:
  18.       - extensions
  19.       - networking.k8s.io
  20.     resources:
  21.       - ingresses
  22.     verbs: ["get", "list", "watch"]
  23.   - nonResourceURLs: ["/metrics", "/metrics/cadvisor"]
  24.     verbs: ["get"]
  25. ---
  26. apiVersion: v1
  27. kind: ServiceAccount
  28. metadata:
  29.   name: categraf
  30.   namespace: flashcat
  31. ---
  32. apiVersion: rbac.authorization.k8s.io/v1
  33. kind: ClusterRoleBinding
  34. metadata:
  35.   name: categraf
  36. roleRef:
  37.   apiGroup: rbac.authorization.k8s.io
  38.   kind: ClusterRole
  39.   name: categraf
  40. subjects:
  41. - kind: ServiceAccount
  42.   name: categraf
  43.   namespace: flashcat
复制代码
在上一节《Kubernetes监控手册05-监控Kubelet》中，我们为 daemonset 创建过认证信息，那个认证信息主要是用于调用 kubelet 的接口。而这次我们要调用的是 apiserver 的接口，所以增加了一些权限点，当然，上例 yaml 中给出的权限点有点多，没关系，反正都是只读的，后面再需要其他权限的时候，省的再创建新的 ServiceAccount 了。与上一讲相比，这次 ServiceAccount 名字改成了 categraf，与上一讲用到的 ServiceAccount 区分开。
通过下面的命令创建相关内容，然后查看一下是否创建成功：
  1. [root@tt-fc-dev01.nj yamls]# kubectl apply -f auth-server.yaml -n flashcat
  2. clusterrole.rbac.authorization.k8s.io/categraf unchanged
  3. serviceaccount/categraf unchanged
  4. clusterrolebinding.rbac.authorization.k8s.io/categraf unchanged
  6. [root@tt-fc-dev01.nj yamls]# kubectl get sa categraf -n flashcat
  7. NAME       SECRETS   AGE
  8. categraf   1         7h13m
  10. [root@tt-fc-dev01.nj yamls]# kubectl get sa categraf -n flashcat -o yaml
  11. apiVersion: v1
  12. kind: ServiceAccount
  13. metadata:
  14.   annotations:
  15.     kubectl.kubernetes.io/last-applied-configuration: |
  16.       {"apiVersion":"v1","kind":"ServiceAccount","metadata":{"annotations":{},"name":"categraf","namespace":"flashcat"}}
  17.   creationTimestamp: "2022-11-28T05:00:17Z"
  18.   name: categraf
  19.   namespace: flashcat
  20.   resourceVersion: "127151612"
  21.   uid: 8b473b31-ce09-4abe-ae55-ea799160a9d5
  22. secrets:
  23. - name: categraf-token-6whbs
  25. [root@tt-fc-dev01.nj yamls]# kubectl get secret categraf-token-6whbs -n flashcat
  26. NAME                   TYPE                                  DATA   AGE
  27. categraf-token-6whbs   kubernetes.io/service-account-token   3      7h15m
复制代码
上例中，因为我之前创建过了，所以显示的是 unchanged，获取 sa 的时候，可以看到 AGE 已经七个多小时了。通过 -o yaml 可以看到 sa 对应的 secret 的名字，最下面那一行，可以看到 secret 名字是 categraf-token-6whbs。然后我们用这个 secret 中的 token 来调用一下 APIServer 试试：
  1. [root@tt-fc-dev01.nj yamls]# token=`kubectl get secret categraf-token-6whbs -n flashcat -o jsonpath={.data.token} | base64 -d`
  2. [root@tt-fc-dev01.nj yamls]# curl -s -k -H "Authorization: Bearer $token" https://localhost:6443/metrics > metrics
  3. [root@tt-fc-dev01.nj yamls]# head -n 6 metrics
  4. # HELP aggregator_openapi_v2_regeneration_count [ALPHA] Counter of OpenAPI v2 spec regeneration count broken down by causing APIService name and reason.
  5. # TYPE aggregator_openapi_v2_regeneration_count counter
  6. aggregator_openapi_v2_regeneration_count{apiservice="*",reason="startup"} 0
  7. aggregator_openapi_v2_regeneration_count{apiservice="k8s_internal_local_delegation_chain_0000000002",reason="update"} 0
  8. aggregator_openapi_v2_regeneration_count{apiservice="v1beta1.metrics.k8s.io",reason="add"} 0
  9. aggregator_openapi_v2_regeneration_count{apiservice="v1beta1.metrics.k8s.io",reason="update"} 0
复制代码
OK，这个新的 Token 是可以获取到数据的了，权限认证通过。
采集原理

既然 Token 已经有了，采集器抓取 APIServer 的数据的时候，只要在 Header 里传入这个 Token 理论上就可以拿到数据了。如果 APIServer 是二进制方式部署，咱们就直接通过 Categraf 的 Prometheus 插件来抓取就可以了。如果 APIServer 是部署在 Kubernetes 的容器里，咱们最好是使用服务发现机制来做。
支持 Kubernetes 服务发现的 agent 有不少，但是要说最原汁原味的还是 Prometheus 自身，Prometheus 新版本(v2.32.0)支持了 agent mode 模式，即把 Prometheus 进程当做采集器 agent，采集了数据之后通过 remote write 方式传给中心(这里使用早就准备好的 Nightingale 作为数据接收服务端)。那这里我就使用 Prometheus 的 agent mode 方式来采集 APIServer。
部署 agent mode prometheus

首先准备一下 Prometheus agent 需要的配置文件，我们做成一个 ConfigMap：
  1. apiVersion: v1
  2. kind: ConfigMap
  3. metadata:
  4.   name: prometheus-agent-conf
  5.   labels:
  6.     name: prometheus-agent-conf
  7.   namespace: flashcat
  8. data:
  9.   prometheus.yml: |-
  10.     global:
  11.       scrape_interval: 15s
  12.       evaluation_interval: 15s
  13.     scrape_configs:
  14.       - job_name: 'apiserver'
  15.         kubernetes_sd_configs:
  16.         - role: endpoints
  17.         scheme: https
  18.         tls_config:
  19.           insecure_skip_verify: true
  20.         authorization:
  21.           credentials_file: /var/run/secrets/kubernetes.io/serviceaccount/token
  22.         relabel_configs:
  23.         - source_labels: [__meta_kubernetes_namespace, __meta_kubernetes_service_name, __meta_kubernetes_endpoint_port_name]
  24.           action: keep
  25.           regex: default;kubernetes;https
  26.     remote_write:
  27.     - url: 'http://10.206.0.16:19000/prometheus/v1/write'   
复制代码
可以把上面的内容保存为 prometheus-agent-configmap.yaml，然后 kubectl -f prometheus-agent-configmap.yaml 创建一下即可。
有了配置了，下面我们就可以部署 Prometheus 了，要把 Prometheus 进程当做 agent 来用，需要启用这个 feature，通过命令行参数 --enable-feature=agent 即可轻松启用了，我们把 agent mode 模式的 Prometheus 部署成一个 Deployment，单副本。
  1. apiVersion: apps/v1
  2. kind: Deployment
  3. metadata:
  4.   name: prometheus-agent
  5.   namespace: flashcat
  6.   labels:
  7.     app: prometheus-agent
  8. spec:
  9.   replicas: 1
  10.   selector:
  11.     matchLabels:
  12.       app: prometheus-agent
  13.   template:
  14.     metadata:
  15.       labels:
  16.         app: prometheus-agent
  17.     spec:
  18.       serviceAccountName: categraf
  19.       containers:
  20.         - name: prometheus
  21.           image: prom/prometheus
  22.           args:
  23.             - "--config.file=/etc/prometheus/prometheus.yml"
  24.             - "--web.enable-lifecycle"
  25.             - "--enable-feature=agent"
  26.           ports:
  27.             - containerPort: 9090
  28.           resources:
  29.             requests:
  30.               cpu: 500m
  31.               memory: 500M
  32.             limits:
  33.               cpu: 1
  34.               memory: 1Gi
  35.           volumeMounts:
  36.             - name: prometheus-config-volume
  37.               mountPath: /etc/prometheus/
  38.             - name: prometheus-storage-volume
  39.               mountPath: /prometheus/
  40.       volumes:
  41.         - name: prometheus-config-volume
  42.           configMap:
  43.             defaultMode: 420
  44.             name: prometheus-agent-conf
  45.         - name: prometheus-storage-volume
  46.           emptyDir: {}
复制代码
要特别注意 serviceAccountName: categraf 这一行内容别忘记了，以上 yaml 内容保存为 prometheus-agent-deployment.yaml，然后 apply 一下：
  1. [work@tt-fc-dev01.nj yamls]$ kubectl apply -f prometheus-agent-deployment.yaml
  2. deployment.apps/prometheus-agent created
复制代码
可以通过 kubectl logs  -n flashcat 查看刚才创建的 prometheus-agent-xx 那个 Pod 的日志，如果没有报错，理论上就问题不大了。
查看监控数据

在即时查询里查一下 apiserver_request_total 这个指标，如果可以查到，就说明数据上报是正常的。孔飞老师之前整理过夜莺的 Kubernetes / Apiserver 监控大盘，可以导入测试，地址在这里。效果如下：

另外，Apiserver 的关键指标的含义，孔飞老师也做了整理，我也给摘过来了：
  1. # HELP apiserver_request_duration_seconds [STABLE] Response latency distribution in seconds for each verb, dry run value, group, version, resource, subresource, scope and component.
  2. # TYPE apiserver_request_duration_seconds histogram
  3. apiserver响应的时间分布，按照url 和 verb 分类
  4. 一般按照instance和verb+时间 汇聚
  6. # HELP apiserver_request_total [STABLE] Counter of apiserver requests broken out for each verb, dry run value, group, version, resource, scope, component, and HTTP response code.
  7. # TYPE apiserver_request_total counter
  8. apiserver的请求总数，按照verb、 version、 group、resource、scope、component、 http返回码分类统计
  10. # HELP apiserver_current_inflight_requests [STABLE] Maximal number of currently used inflight request limit of this apiserver per request kind in last second.
  11. # TYPE apiserver_current_inflight_requests gauge
  12. 最大并发请求数, 按mutating(非get list watch的请求)和readOnly(get list watch)分别限制
  13. 超过max-requests-inflight(默认值400)和max-mutating-requests-inflight(默认200)的请求会被限流
  14. apiserver变更时要注意观察，也是反馈集群容量的一个重要指标
  16. # HELP apiserver_response_sizes [STABLE] Response size distribution in bytes for each group, version, verb, resource, subresource, scope and component.
  17. # TYPE apiserver_response_sizes histogram
  18. apiserver 响应大小，单位byte, 按照verb、 version、 group、resource、scope、component分类统计
  20. # HELP watch_cache_capacity [ALPHA] Total capacity of watch cache broken by resource type.
  21. # TYPE watch_cache_capacity gauge
  22. 按照资源类型统计的watch缓存大小
  24. # HELP process_cpu_seconds_total Total user and system CPU time spent in seconds.
  25. # TYPE process_cpu_seconds_total counter
  26. 每秒钟用户态和系统态cpu消耗时间, 计算apiserver进程的cpu的使用率
  28. # HELP process_resident_memory_bytes Resident memory size in bytes.
  29. # TYPE process_resident_memory_bytes gauge
  30. apiserver的内存使用量(单位:Byte)
  32. # HELP workqueue_adds_total [ALPHA] Total number of adds handled by workqueue
  33. # TYPE workqueue_adds_total counter
  34. apiserver中包含的controller的工作队列，已处理的任务总数
  36. # HELP workqueue_depth [ALPHA] Current depth of workqueue
  37. # TYPE workqueue_depth gauge
  38. apiserver中包含的controller的工作队列深度，表示当前队列中要处理的任务的数量，数值越小越好
  39. 例如APIServiceRegistrationController admission_quota_controller
复制代码
相关文章

关于作者

本文作者秦晓辉，Flashcat合伙人，文章内容是Flashcat技术团队共同沉淀的结晶，作者做了编辑整理，我们会持续输出监控、稳定性保障相关的技术文章，文章可转载，转载请注明出处，尊重技术人员的成果。
如果对 Nightingale、Categraf、Prometheus 等技术感兴趣，欢迎加入我们的微信群组，联系我(picobyte)拉入部落，和社区同仁一起探讨监控技术。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！

本帖子中包含更多资源

您需要 登录 才可以下载或查看，没有账号？立即注册

x
回复

使用道具 举报

0 个回复

正序浏览
返回列表

快速回复

高级模式
B Color Image Link Quote Code Smilies
您需要登录后才可以回帖 登录 or 立即注册

本版积分规则

小小小幸运

金牌会员
这个人很懒什么都没写!

楼主热帖

标签云

挺好的 服务器
微信订阅号
微信服务号
微信客服
小程序
H5
关于我们 商务合作 网站地图
©Copyright 2022-2024 杭州祥升科技有限公司 版权所有 浙ICP备20004199号
快速回复 返回顶部 返回列表