最新要闻

广告

手机

iphone11大小尺寸是多少?苹果iPhone11和iPhone13的区别是什么?

iphone11大小尺寸是多少?苹果iPhone11和iPhone13的区别是什么?

警方通报辅警执法直播中被撞飞:犯罪嫌疑人已投案

警方通报辅警执法直播中被撞飞:犯罪嫌疑人已投案

家电

焦点资讯:Kubernetes监控手册06-监控APIServer

来源:博客园

写在前面

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

黑盒测试

APIServer 在 Kubernetes 架构中非常核心,是所有 API 的入口,APIServer 也暴露了 metrics 数据,我们尝试获取一下:


(相关资料图)

[root@tt-fc-dev01.nj etcd]# ss -tlpn|grep apiserverLISTEN 0      128                *:6443             *:*    users:(("kube-apiserver",pid=164445,fd=7))[root@tt-fc-dev01.nj etcd]# curl -s http://localhost:6443/metricsClient sent an HTTP request to an HTTPS server.[root@tt-fc-dev01.nj etcd]# curl -s -k https://localhost:6443/metrics{  "kind": "Status",  "apiVersion": "v1",  "metadata": {},  "status": "Failure",  "message": "forbidden: User \"system:anonymous\" cannot get path \"/metrics\"",  "reason": "Forbidden",  "details": {},  "code": 403}

解释一下上面的命令和结果。首先我通过 ss 命令查看 apiserver 模块监听在哪些端口,发现这个进程在 6443 端口有监听。然后,使用 curl 命令请求 6443 的 metrics 接口,结果又说这是一个 HTTPS Server,不能用 HTTP 协议请求。好,那我用 HTTPS 协议请求,自签证书,加了 -k 参数,返回 Forbidden,说没权限访问/metrics接口。OK,那看来是需要 Token 鉴权,我们创建一下相关的 ServiceAccount。

准备认证信息

下面的内容可以保存为 auth-server.yaml。

---apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata:  name: categrafrules:  - apiGroups: [""]    resources:      - nodes      - nodes/metrics      - nodes/stats      - nodes/proxy      - services      - endpoints      - pods    verbs: ["get", "list", "watch"]  - apiGroups:      - extensions      - networking.k8s.io    resources:      - ingresses    verbs: ["get", "list", "watch"]  - nonResourceURLs: ["/metrics", "/metrics/cadvisor"]    verbs: ["get"]---apiVersion: v1kind: ServiceAccountmetadata:  name: categraf  namespace: flashcat---apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRoleBindingmetadata:  name: categrafroleRef:  apiGroup: rbac.authorization.k8s.io  kind: ClusterRole  name: categrafsubjects:- kind: ServiceAccount  name: categraf  namespace: flashcat

在上一节《Kubernetes监控手册05-监控Kubelet》中,我们为 daemonset 创建过认证信息,那个认证信息主要是用于调用 kubelet 的接口。而这次我们要调用的是 apiserver 的接口,所以增加了一些权限点,当然,上例 yaml 中给出的权限点有点多,没关系,反正都是只读的,后面再需要其他权限的时候,省的再创建新的 ServiceAccount 了。与上一讲相比,这次 ServiceAccount 名字改成了 categraf,与上一讲用到的 ServiceAccount 区分开。

通过下面的命令创建相关内容,然后查看一下是否创建成功:

[root@tt-fc-dev01.nj yamls]# kubectl apply -f auth-server.yaml -n flashcatclusterrole.rbac.authorization.k8s.io/categraf unchangedserviceaccount/categraf unchangedclusterrolebinding.rbac.authorization.k8s.io/categraf unchanged[root@tt-fc-dev01.nj yamls]# kubectl get sa categraf -n flashcatNAME       SECRETS   AGEcategraf   1         7h13m[root@tt-fc-dev01.nj yamls]# kubectl get sa categraf -n flashcat -o yamlapiVersion: v1kind: ServiceAccountmetadata:  annotations:    kubectl.kubernetes.io/last-applied-configuration: |      {"apiVersion":"v1","kind":"ServiceAccount","metadata":{"annotations":{},"name":"categraf","namespace":"flashcat"}}  creationTimestamp: "2022-11-28T05:00:17Z"  name: categraf  namespace: flashcat  resourceVersion: "127151612"  uid: 8b473b31-ce09-4abe-ae55-ea799160a9d5secrets:- name: categraf-token-6whbs[root@tt-fc-dev01.nj yamls]# kubectl get secret categraf-token-6whbs -n flashcatNAME                   TYPE                                  DATA   AGEcategraf-token-6whbs   kubernetes.io/service-account-token   3      7h15m

上例中,因为我之前创建过了,所以显示的是 unchanged,获取 sa 的时候,可以看到 AGE 已经七个多小时了。通过-o yaml可以看到 sa 对应的 secret 的名字,最下面那一行,可以看到 secret 名字是 categraf-token-6whbs。然后我们用这个 secret 中的 token 来调用一下 APIServer 试试:

[root@tt-fc-dev01.nj yamls]# token=`kubectl get secret categraf-token-6whbs -n flashcat -o jsonpath={.data.token} | base64 -d`[root@tt-fc-dev01.nj yamls]# curl -s -k -H "Authorization: Bearer $token" https://localhost:6443/metrics > metrics[root@tt-fc-dev01.nj yamls]# head -n 6 metrics# HELP aggregator_openapi_v2_regeneration_count [ALPHA] Counter of OpenAPI v2 spec regeneration count broken down by causing APIService name and reason.# TYPE aggregator_openapi_v2_regeneration_count counteraggregator_openapi_v2_regeneration_count{apiservice="*",reason="startup"} 0aggregator_openapi_v2_regeneration_count{apiservice="k8s_internal_local_delegation_chain_0000000002",reason="update"} 0aggregator_openapi_v2_regeneration_count{apiservice="v1beta1.metrics.k8s.io",reason="add"} 0aggregator_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:

apiVersion: v1kind: ConfigMapmetadata:  name: prometheus-agent-conf  labels:    name: prometheus-agent-conf  namespace: flashcatdata:  prometheus.yml: |-    global:      scrape_interval: 15s      evaluation_interval: 15s    scrape_configs:      - job_name: "apiserver"        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    remote_write:    - 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,单副本。

apiVersion: apps/v1kind: Deploymentmetadata:  name: prometheus-agent  namespace: flashcat  labels:    app: prometheus-agentspec:  replicas: 1  selector:    matchLabels:      app: prometheus-agent  template:    metadata:      labels:        app: prometheus-agent    spec:      serviceAccountName: categraf      containers:        - name: prometheus          image: prom/prometheus          args:            - "--config.file=/etc/prometheus/prometheus.yml"            - "--web.enable-lifecycle"            - "--enable-feature=agent"          ports:            - containerPort: 9090          resources:            requests:              cpu: 500m              memory: 500M            limits:              cpu: 1              memory: 1Gi          volumeMounts:            - name: prometheus-config-volume              mountPath: /etc/prometheus/            - name: prometheus-storage-volume              mountPath: /prometheus/      volumes:        - name: prometheus-config-volume          configMap:            defaultMode: 420            name: prometheus-agent-conf        - name: prometheus-storage-volume          emptyDir: {}

要特别注意serviceAccountName: categraf这一行内容别忘记了,以上 yaml 内容保存为 prometheus-agent-deployment.yaml,然后 apply 一下:

[work@tt-fc-dev01.nj yamls]$ kubectl apply -f prometheus-agent-deployment.yamldeployment.apps/prometheus-agent created

可以通过kubectl logs -n flashcat查看刚才创建的 prometheus-agent-xx 那个 Pod 的日志,如果没有报错,理论上就问题不大了。

查看监控数据

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

另外,Apiserver 的关键指标的含义,孔飞老师也做了整理,我也给摘过来了:

# HELP apiserver_request_duration_seconds [STABLE] Response latency distribution in seconds for each verb, dry run value, group, version, resource, subresource, scope and component.# TYPE apiserver_request_duration_seconds histogramapiserver响应的时间分布,按照url 和 verb 分类一般按照instance和verb+时间 汇聚# 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.# TYPE apiserver_request_total counterapiserver的请求总数,按照verb、 version、 group、resource、scope、component、 http返回码分类统计# HELP apiserver_current_inflight_requests [STABLE] Maximal number of currently used inflight request limit of this apiserver per request kind in last second.# TYPE apiserver_current_inflight_requests gauge最大并发请求数, 按mutating(非get list watch的请求)和readOnly(get list watch)分别限制超过max-requests-inflight(默认值400)和max-mutating-requests-inflight(默认200)的请求会被限流apiserver变更时要注意观察,也是反馈集群容量的一个重要指标# HELP apiserver_response_sizes [STABLE] Response size distribution in bytes for each group, version, verb, resource, subresource, scope and component.# TYPE apiserver_response_sizes histogramapiserver 响应大小,单位byte, 按照verb、 version、 group、resource、scope、component分类统计# HELP watch_cache_capacity [ALPHA] Total capacity of watch cache broken by resource type.# TYPE watch_cache_capacity gauge按照资源类型统计的watch缓存大小# HELP process_cpu_seconds_total Total user and system CPU time spent in seconds.# TYPE process_cpu_seconds_total counter每秒钟用户态和系统态cpu消耗时间, 计算apiserver进程的cpu的使用率# HELP process_resident_memory_bytes Resident memory size in bytes.# TYPE process_resident_memory_bytes gaugeapiserver的内存使用量(单位:Byte)# HELP workqueue_adds_total [ALPHA] Total number of adds handled by workqueue# TYPE workqueue_adds_total counterapiserver中包含的controller的工作队列,已处理的任务总数# HELP workqueue_depth [ALPHA] Current depth of workqueue# TYPE workqueue_depth gaugeapiserver中包含的controller的工作队列深度,表示当前队列中要处理的任务的数量,数值越小越好 例如APIServiceRegistrationController admission_quota_controller

相关文章

  • Kubernetes监控手册01-体系介绍
  • Kubernetes监控手册02-宿主监控概述
  • Kubernetes监控手册03-宿主监控实操
  • Kubernetes监控手册04-监控Kube-Proxy
  • Kubernetes监控手册05-监控Kubelet

关于作者

本文作者秦晓辉,Flashcat合伙人,文章内容是Flashcat技术团队共同沉淀的结晶,作者做了编辑整理,我们会持续输出监控、稳定性保障相关的技术文章,文章可转载,转载请注明出处,尊重技术人员的成果。

如果对 Nightingale、Categraf、Prometheus 等技术感兴趣,欢迎加入我们的微信群组,联系我(picobyte)拉入部落,和社区同仁一起探讨监控技术。

关键词: 工作队列 黑盒测试 相关文章