详细分析:监控Kubernetes APIServer，讲解最透的文章

　　详细分析:监控Kubernetes APIServer，讲解最透的文章

　　写在前面

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

　　黑盒测试

　　APIServer在Kubernetes架构中非常核心，是所有API的入口。APIServer 还公开指标数据。让我们试着得到它：

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

　　解释上面的命令和结果。首先我通过ss命令查看了apiserver模块*敏*感*词*了哪些端口，发现进程*敏*感*词*的是6443端口，然后用curl命令请求6443的metrics接口，结果发现这是一个HTTPS服务器，不能用HTTP协议请求。ok，那我用HTTPS协议请求，自签名证书，加上-k参数，返回Forbidden，说我无权访问/metrics接口。OK，看来需要Token认证，我们创建一个相关的ServiceAccount吧。

　　准备认证资料

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

　　---<br />apiVersion: rbac.authorization.k8s.io/v1<br />kind: ClusterRole<br />metadata:<br /> name: categraf<br />rules:<br /> - apiGroups: [""]<br /> resources:<br /> - nodes<br /> - nodes/metrics<br /> - nodes/stats<br /> - nodes/proxy<br /> - services<br /> - endpoints<br /> - pods<br /> verbs: ["get", "list", "watch"]<br /> - apiGroups:<br /> - extensions<br /> - networking.k8s.io<br /> resources:<br /> - ingresses<br /> verbs: ["get", "list", "watch"]<br /> - nonResourceURLs: ["/metrics", "/metrics/cadvisor"]<br /> verbs: ["get"]<br />---<br />apiVersion: v1<br />kind: ServiceAccount<br />metadata:<br /> name: categraf<br /> namespace: flashcat<br />---<br />apiVersion: rbac.authorization.k8s.io/v1<br />kind: ClusterRoleBinding<br />metadata:<br /> name: categraf<br />roleRef:<br /> apiGroup: rbac.authorization.k8s.io<br /> kind: ClusterRole<br /> name: categraf<br />subjects:<br />- kind: ServiceAccount<br /> name: categraf<br /> namespace: flashcat<br />

　　在上一节《Kubernetes监控手册05-监控Kubelet》中，我们为daemonset创建了鉴权信息，主要用于调用kubelet的接口。但是这次我们要调用apiserver接口，所以加了一些权限点。当然，上面例子yaml给的权限点有点多，没关系，反正都是只读的，以后需要其他权限的时候，保存新建ServiceAccount。与上一讲相比，这次ServiceAccount的名称改为categraf，与上一讲使用的ServiceAccount不同。

　　通过以下命令创建相关内容，然后查看是否创建成功：

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

" />

　　在上面的例子中，因为我之前创建过，所以显示为未更改。获取sa的时候可以看到AGE已经超过七个小时了。通过-o yaml可以看到sa对应的secret的名称。在最后一行，您可以看到秘密名称是 categraf-token-6whbs。然后我们使用这个秘密中的令牌来调用 APIServer 并尝试：

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

　　OK，这个新的Token可以拿到数据了，权限认证通过。

　　采集原理

　　既然Token已经存在，那么采集器在抓取APIServer的数据时，理论上只需要在Header中传入Token就可以拿到数据了。如果APIServer是以二进制方式部署的，我们可以直接通过Categraf的Prometheus插件来抓取。如果APIServer部署在Kubernetes容器中，我们最好使用服务发现机制来做。

　　支持 Kubernetes 服务发现的代理有很多，但最正宗的还是 Prometheus 本身。Prometheus新版本（v2.32.0）支持代理模式模式，即使用Prometheus进程作为采集

器代理。采集数据后，通过remote write的方式发送到中心（这里使用早就准备好的Nightingale作为数据接收服务器）。那么这里我使用Prometheus的代理模式来采集

APIServer。

　　部署代理模式prometheus

　　首先准备Prometheus agent需要的配置文件，我们做一个ConfigMap：

　　apiVersion: v1<br />kind: ConfigMap<br />metadata:<br /> name: prometheus-agent-conf<br /> labels:<br /> name: prometheus-agent-conf<br /> namespace: flashcat<br />data:<br /> prometheus.yml: |-<br /> global:<br /> scrape_interval: 15s<br /> evaluation_interval: 15s<br /> scrape_configs:<br /> - job_name: 'apiserver'<br /> kubernetes_sd_configs:<br /> - role: endpoints<br /> scheme: https<br /> tls_config:<br /> ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt<br /> bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token<br /> relabel_configs:<br /> - source_labels: [__meta_kubernetes_namespace, __meta_kubernetes_service_name, __meta_kubernetes_endpoint_port_name]<br /> action: keep<br /> regex: default;kubernetes;https<br /> remote_write:<br /> - url: 'http://10.206.0.16:19000/prometheus/v1/write' <br />

　　可以将以上内容保存为prometheus-agent-configmap.yaml，然后使用kubectl -f prometheus-agent-configmap.yaml创建。

　　配置完成后，我们就可以在下面部署Prometheus了。要使用 Prometheus 进程作为代理，我们需要启用此功能。可以通过命令行参数 --enable-feature=agent 轻松启用。我们使用agent模式方式将Prometheus部署为一个单副本的Deployment。

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

" />

　　请特别注意行 serviceAccountName: categraf。别忘了将上面的yaml内容保存为prometheus-agent-deployment.yaml，然后应用：

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

　　您可以通过 kubectl 日志

　　-n flashcat 查看刚刚创建的prometheus-agent-xx的Pod的log，如果没有报错，理论上没有大问题。

　　查看监控数据

　　查看实时查询中的apiserver_request_total指标。如果能找到，说明数据上报正常。孔飞老师之前整理过Nightingale的Kubernetes/Apiserver监控dashboard，大家可以导入测试。地址在这里。效果如下：

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

　　关于作者的相关文章

　　本文作者秦晓晖是Flashcat的合伙人。本文内容是Flashcat技术团队共同沉淀的结晶。作者进行了编辑整理。我们会持续输出监控和维保相关的技术文章。技术人员的结果。

　　如果你对Nightingale、Categraf、Prometheus等技术感兴趣，欢迎加入我们的微信群，联系我（皮字节）加入部落，与社区同仁共同探讨监控技术。

　　解读:搜索引擎判断文章是否为原创的方法是什么？

　　简述：在这个内容为王的时代，最感人的莫过于原创文章对一个网站的重要性。如果一个网站在某个时间段，如果网页内容质量不够好，那么直接的结果就是网站降级，网站流量下降。虽然我们知道原创文章的重要性，但是大家也都知道一篇文章和两篇原创文章

　　在这个内容为王的时代，最让人感动的莫过于原创文章对于一个网站的重要性。如果一个网站在某个时间段，如果网页内容质量不够好，那么直接的结果就是网站降级，网站流量下降。

　　虽然我们知道原创文章的重要性，但大家也都知道，一两篇原创文章问题不大。网站文章的原创性是很难长期保持的，除非那些大站长的下属有一批专职的撰稿人或编辑。那么没有这样优厚条件的站长怎么办呢？只能是伪原创和抄袭。

　　但是伪原创和抄袭的方法真的有用吗？今天济南东商资讯就来和大家分享一下搜索引擎判断重复内容的知识： 问题一：搜索引擎是如何判断重复内容的？1、一般的基本判断原则是逐页比对数字指纹。这种方法虽然可以找到一些重复的内容，但是缺点是需要消耗大量的资源，而且运行速度慢，效率低。

" />

　　2. 基于全局特征的I-Match 该算法的原理是对所有出现在文本中的词进行排序，然后再进行评分。目的是删除文中不相关的关键词，保留重要的关键词。该方法去重效果高，效果明显。

　　比如我们在伪原创的时候可能会交换文章的文字和段落。这种方法根本骗不了I-Match算法，依然会判断重复。

　　3.如果基于停用词的Spotsig文档中使用了大量的停用词，如语气词、副词、介词、连词等，这些都会干扰有效信息，搜索引擎在去重时会处理这些停用词。先做删除，再做文档匹配。因此，我们在做优化时不妨降低停用词出现频率，增加页面关键词密度，更有利于搜索引擎抓取。

　　4、基于多重Hash的Simhash算法涉及到几何原理，解释起来比较困难。简单地说，相似的文本具有相似的哈希值。如果两个文本的 simhash 越接近，即汉明距离越小，则文本越相似。因此，海量文本查重任务转化为如何快速判断海量simhash中是否存在海明距离小的指纹。

　　我们只需要知道，通过这种算法，搜索引擎可以在极短的时间内对大型网页进行近似的重复检查。目前，该算法在识别效果和查重效率上互为补充。

　　问题二、重复内容在搜索引擎眼中有哪些表现形式？1.形式和内容相似。这种情况在电子商务网站上比较常见，盗图现象比比皆是。

" />

　　2.只是格式相似。3.只是内容相似。

　　4.格式和内容部分相似。这种情况通常比较常见，尤其是企业类网站。

　　问题 3. 为什么搜索引擎会积极处理重复内容？1. 节省抓取、索引和分析内容的空间和时间。一句话，搜索引擎的资源是有限的，但用户的需求是无限的。. 大量的重复内容消耗了搜索引擎的宝贵资源，所以从成本的角度来说，必须对重复内容进行处理。

　　2. 有助于避免重复采集

重复内容。从识别采集的内容中归纳出最符合用户查询意图的信息，既可以提高效率，又可以避免重复采集重复的内容。3、重复的频率可以作为判断优秀内容的标准。搜索引擎既然可以识别出重复的内容，当然可以更有效地识别出哪些内容是原创的、高质量的。重复频率越低，文章原创内容的质量就越高。高的。

　　4、提升用户体验 其实这也是搜索引擎最看重的一点。只有妥善处理重复内容，将更有用的信息呈现给用户，用户才能购买。