Kubernetes 云原生可观察性Observability实践指南指标、日志与追踪三大支柱详解【免费下载链接】kubernetes-handbookKubernetes 架构与生态从云原生到 AI 原生基础设施的构建指南项目地址: https://gitcode.com/gh_mirrors/ku/kubernetes-handbook可观察性Observability是通过指标Metrics、日志Logs和追踪Tracing这些外部输出来理解系统内部状态的能力是 Kubernetes 集群与应用运维的基石。本文以 kubernetes-handbook 仓库的 usecases/observability.md 为骨架结合仓库内 监控实践、日志收集实践、EFK 插件安装 与 分布式追踪实践 等章节系统讲解三大支柱的定义、分类与落地工具链帮助你掌握在云原生环境中看懂系统运行状态、快速定位故障的完整方法论与可执行的配置方案。什么是可观察性可观察性使用指标、日志和追踪这些外部输出来理解系统的能力。这些指标、日志和追踪是基于系统内部的事件产生的——当请求到达系统、被各个服务处理、最终返回结果时系统内部发生的每个事件都会转化为可供外部观测的数据。在传统单体架构中应用部署在一台或少数几台服务器上运维人员可以直接登录机器查看进程状态、读取日志文件系统状态相对透明。而在 Kubernetes 中应用被抽象为 Pod、Service、Deployment 等众多对象且生命周期极短、可以随时漂移和重建直接进到机器里看已经不可行。因此构建一套完整的可观察性体系成为生产环境下 Kubernetes 集群运维的当务之急——正如 practice/monitoring.md 开篇所言Kubernetes 使得管理复杂环境变得更简单但对集群组件和运行其上的应用做到很好的洞察却很困难。可观察性的三大支柱各有分工支柱回答的问题特点指标Metrics系统现在好不好数据总体汇总持续衡量开销小日志Logs系统发生了什么冗长、信息完整记录事件从头到尾追踪Tracing一个请求经历了什么实时捕捉事件行为定位故障发生位置指标Metrics服务健康状况的持续衡量标准指标是数据的总体汇总它能让你了解正在发生的事情和需要深入挖掘的地方。服务不断产生并消费指标这些指标是服务健康状况的持续衡量标准。指标包括两种类型应用/业务指标和运维指标。应用指标Application Performance Metrics应用性能指标APM数据与应用性能有关如加载时间和响应时间用于确保应用向客户提供预期性能。像 Apache SkyWalking 这样的开源技术可以集成到 Istio 服务网格中既可以作为 APM也可以作为额外的服务性能管理Service Performance ManagementSPM系统——一举两得既能看到单次请求的性能细节又能获得服务维度的性能管理视图。运维指标与 RED 方法运维指标关注的是服务的运行情况你的环境表现如何。它通常被描述为 RED 指标Request rate请求率每秒处理的请求数量反映服务的负载和吞吐。Error rate错误率请求中出错的比例反映服务的健康程度。Duration持续时间请求处理的耗时分布如 P50/P95/P99反映服务的响应性能。服务网格比如 Istio唯一关心的就是收集这些运维指标帮助你确定服务表现如何并对服务健康状况有一个大致的了解。在微服务规模下请求率、错误率、耗时这三个维度足以勾勒出服务的整体健康画像这也是 Google SRE 运维理念在云原生时代的自然延伸。落地工具Prometheus 与 Kubernetes 集群监控在指标收集领域Prometheus 是目前 Kubernetes 生态的事实标准。仓库 practice/prometheus.md 指出Prometheus 是由 SoundCloud 开源的监控告警解决方案2016 年成为继 Kubernetes 之后第二个加入 CNCF 的项目。相较以往的系统监控云原生时代监控对象和指标呈指数级增加、监控对象生命周期更短暂正需要一款统一监控指标和数据查询语言的工具。主要功能包括多维数据模型时序由 metric 名字和 k/v 的 labels 构成labels 天然契合 Kubernetes 中 Pod 的 label 体系灵活的查询语句 PromQL无依赖存储支持 local 和 remote 不同模型采用 http 协议使用pull 模式拉取数据简单易懂监控目标可采用服务发现或静态配置的方式——与 Kubernetes 集成时可直接通过 API 服务发现 Pod支持多种统计数据模型图形化友好。核心组件包括Prometheus Server抓取和存储时序数据、提供查询与告警规则管理、client libraries对接 Prometheus Server查询和上报数据、push gateway批量、短期监控数据的汇总节点主要用于业务数据汇报、各种 exporters如汇报机器数据的 node_exporter、汇报 MongoDB 信息的 MongoDB exporter、以及用于告警通知管理的 alertmanager。Prometheus 的大致使用逻辑是Prometheus server 定期从静态配置的 target 或服务发现的 target 拉取数据当新拉取的数据大于配置的内存缓冲区时Prometheus 会将数据持久化到磁盘如果使用 remote storage 将持久化到云端Prometheus 可以配置 rule 定时查询数据条件触发时把 alert 推送到配置的 AlertmanagerAlertmanager 收到警告后根据配置进行聚合、去重、降噪最后发送告警可以使用 API、Prometheus Console 或 Grafana 查询和聚合数据。使用注意Prometheus 的数据是基于时序的 float64 值如果你的数据还有其他类型则无法满足Prometheus 也不适合做审计计费——它按一定时间采集关注系统运行的瞬时状态和趋势能容忍少量数据缺失而审计计费需要记录每个请求并长期存储数据。仓库 practice/using-prometheus-to-monitor-kuberentes-cluster.md 给出了在 Kubernetes 集群中部署 Prometheus 的完整步骤所需 YAML 文件位于 manifests/prometheus 目录## 创建 monitoring namespace kubectl create -f prometheus-monitoring-ns.yaml ## 创建 serviceaccount kubectl create -f prometheus-monitoring-serviceaccount.yaml ## 创建 configmaps kubectl create -f prometheus-configmaps.yaml ## 创建 clusterrolebinding注意先创建 RBAC 对象再部署 kubectl create clusterrolebinding kube-state-metrics --clusterrolecluster-admin --serviceaccountmonitoring:kube-state-metrics kubectl create clusterrolebinding prometheus --clusterrolecluster-admin --serviceaccountmonitoring:prometheus ## 部署 Prometheus kubectl create -f prometheus-monitoring.yaml部署要点RBAC 授权对象serviceaccount、clusterrole、clusterrolebinding应写在一个单独文件中并先于其他资源创建因为kubectl不会判断 YAML 文件中的资源依赖关系只会从文件头部开始依次执行。此外旧版本中kube-state-metrics对 Job、PersistentVolumeClaim、StatefulSet、CronJob 等资源的 API 路径兼容存在差异参见 concepts/rbac.md 关于基于角色的访问控制的说明部署时需要确认集群 API 版本与监控组件的兼容性。监控的三个层次仓库 practice/monitor.md 指出Kubernetes 集群和应用的监控需要关注三个方面——Kubernetes 集群本身各组件、集群中 PodCPU、内存、网络、磁盘等、集群内部应用本身。与物理机监控不同Kubernetes 多了虚拟化层还在 Docker 之上抽象了 Service 概念因此监控时需要考虑给 Pod 打上哪些 label这些 label 将成为监控的 metrics、Pod 漂移后如何持续监控、以及监控指标来源通过 heapster 汇聚还是直接从每台主机的 docker 上取。在监控数据落地时docker inspect $container_name中可见的容器 labels如io.kubernetes.pod.name、io.kubernetes.pod.namespace以及 kubelet 中 BuildDockerName 定义的k8s_容器名_Pod全名_PodUID命名规范都是将容器指标关联回 Pod、Namespace 的关键映射依据。日志Logs记录事件从头到尾的冗长信息日志是冗长的包含一个事件从头到尾的信息。一则日志可以收集匿名用户数据例如哪个用户发出了请求这条请求从哪里开始到达哪些服务等等。如果说指标回答系统现在怎么样日志则回答具体发生了什么是排障时最直接的证据来源。云原生环境下的日志收集方案选型日志的收集方式直接决定运维效率。仓库 practice/app-log-collection.md 对比了 Kubernetes 集群中三种主流日志收集方案编号方案优点缺点1每个 app 的镜像中都集成日志收集组件部署方便kubernetes 的 yaml 文件无须特别配置可以为每个 app 自定义日志收集配置强耦合不方便应用和日志收集组件升级和维护且会导致镜像过大2单独创建一个日志收集组件跟 app 的容器一起运行在同一个 pod 中低耦合扩展性强方便维护和升级需要对 kubernetes 的 yaml 文件进行单独配置略显繁琐3将所有的 Pod 的日志都挂载到宿主机上每台主机上单独起一个日志收集 Pod完全解耦性能最高管理起来最方便需要统一日志收集规则目录和输出方式方案二sidecar 模式在扩展性、个性化、部署和后期维护方面都能做到均衡因此被该实践采纳。在日志收集组件选型上Logstash 基于 JDK单纯启动就约消耗 500M 内存而 Filebeat 单独启动约消耗 12M 内存相当轻量级适合在每个 Pod 中都部署日志收集组件的场景。Filebeat sidecar 收集日志的完整配置以下 YAML完整文件见 manifests/test/filebeat-test.yaml展示了 sidecar 模式的典型做法通过emptyDir卷将 app 的日志目录挂载给同 Pod 内的 filebeat 容器并用 ConfigMap 挂载 filebeat 配置apiVersion: extensions/v1beta1 kind: Deployment metadata: name: filebeat-test namespace: default spec: replicas: 3 template: metadata: labels: k8s-app: filebeat-test spec: containers: - image: harbor-001.jimmysong.io/library/filebeat:5.4.0 name: filebeat volumeMounts: - name: app-logs mountPath: /log - name: filebeat-config mountPath: /etc/filebeat/ - image: harbor-001.jimmysong.io/library/analytics-docker-test:Build_8 name : app ports: - containerPort: 80 volumeMounts: - name: app-logs mountPath: /usr/local/TalkingData/logs volumes: - name: app-logs emptyDir: {} - name: filebeat-config configMap: name: filebeat-config --- apiVersion: v1 kind: ConfigMap metadata: name: filebeat-config data: filebeat.yml: | filebeat.prospectors: - input_type: log paths: - /log/* - /log/usermange/common/* output.elasticsearch: hosts: [172.23.5.255:9200] username: elastic password: changeme index: filebeat-docker-test实践要点将 app 的日志目录挂载到 filebeat 的/log目录下filebeat 即可通过paths配置采集一个或多个日志路径/log/*与/log/usermange/common/*同时生效推荐使用 ConfigMap 管理 filebeat 配置比环境变量方式更灵活——通过环境变量如PATHS、ES_SERVER、INDEX、INPUT_TYPE传参时PATHS只能传递单个目录多目录需自行修改镜像的docker-entrypoint.sh脚本将index值设为service name可以方便地按服务收集和查看日志部署命令为kubectl create -f filebeat-test.yaml部署后可通过curl http://172.23.5.255:9200/_cat/indices查看生成的索引如green open filebeat-docker-test ...并在 Kibana 中查看收集到的日志字段——_index对应 YAML 中配置的 index 值beat.hostname/beat.name即 Pod 名称source表示 filebeat 容器中的日志目录。集群级日志方案EFKElasticsearch Fluentd Kibana对于集群级统一日志收集Kubernetes 官方提供 EFK 方案在每台 node 上部署一个以DaemonSet方式运行的 fluentd 来收集该节点上的日志。Fluentd 将 docker 日志目录/var/lib/docker/containers和/var/log挂载到 Pod 中并在 node 节点的/var/log/pods目录下创建目录区分不同容器的日志输出。仓库 practice/efk-addon-installation.md 给出了完整的安装步骤修改后的 YAML 文件位于 manifests/EFK 目录含es-controller.yaml、es-service.yaml、fluentd-es-ds.yaml、kibana-controller.yaml、kibana-service.yaml与efk-rbac.yaml。安装流程概要创建 EFK 的 RBAC配置 serviceaccount 为efk定义文件为 manifests/EFK/efk-rbac.yaml给 Node 打标签fluentd-es-ds.yaml中设置了 nodeSelectorbeta.kubernetes.io/fluentd-ds-readytrue需在期望运行 fluentd 的 Node 上打标签kubectl label nodes 172.20.0.113 beta.kubernetes.io/fluentd-ds-readytrue执行定义文件kubectl create -f .依次创建 serviceaccount、clusterrolebinding、replicationcontrollerelasticsearch、service、daemonsetfluentd、deploymentkibana验证运行状态通过kubectl get pods -n kube-system | grep -E elasticsearch|fluentd|kibana确认各组件 Running。Kibana Pod 首次启动会用较长时间10-20 分钟优化和 Cache 状态页面可kubectl logs观察进度访问 Kibana通过kubectl cluster-info获取代理 URL/api/v1/proxy/namespaces/kube-system/services/kibana-logging或使用kubectl proxy后访问代理地址在 Settings - Indices 页面创建索引默认logstash-*pattern后即可在 Discover 下查看汇聚的日志。常见问题若 Kibana 的 Create 按钮灰色无法点击且 Time-field name 无选项需检查 docker 的--log-driver配置是否设置为json-file格式默认可能是 journald因为 fluentd 读取的是/var/log/containers/下链接到/var/lib/docker/containers/${CONTAINER_ID}/${CONTAINER_ID}-json.log的日志文件只有 json-file 驱动才会产生该格式的日志文件。追踪Tracing从请求起点到终点的实时捕捉追踪让你能够看到一个请求从开始到结束的过程。它是对事件行为的实时捕捉可以帮助确定故障发生的位置或确定引起当前性能问题的原因。在基于微服务的环境中会产生大量的事件——事件被定义为从请求到达网络外围的那一刻起发生的一切即产生可观察数据的动作。为什么需要分布式追踪当单体应用拆成多个微服务后它们可能分布在上千个服务器、不同的数据中心和可用区中如何监控服务之间的依赖关系和调用链以判断应用在哪个服务环节出了问题、哪些地方可以优化这就需要用到分布式追踪。仓库 practice/distributed-tracing.md 总结了分布式追踪系统的核心要求对应用程序的消耗足够低一是指占用的系统资源要足够低二是指造成的延迟要足够低对应用程序透明为了做到 7x24 小时无所不在的部署要让程序员对程序的改动尽可能的小便于大范围低成本接入这正是 Istio 等服务网格通过 sidecar 自动注入实现追踪的原因可扩展为了将所有服务接入分布式追踪系统该系统必须能够承载大规模服务。此外还要求系统对追踪数据的处理尽可能快、可以方便地对追踪结果进行查询和可视化。OpenTracing 标准与核心术语CNCF 提出了分布式追踪的标准 OpenTracing它提供厂商中立的 API并提供 Go、Java、JavaScript、Python、Ruby、PHP、Objective-C、C 和 C# 等语言的库支持的 Tracer 包括 Zipkin、Skywalking、Jaeger 等。仓库 practice/opentracing.md 对基本术语做了精确定义Trace通常指一次完整的调用链。例如 Jaeger UI 中展示的 Istio 官方 Bookinfo 示例对productpage的调用链分析。Span每个 trace 由一系列 Span 组成一个 Span 可以理解为两个微服务之间的调用如同 Chrome 检查器中查看网络访问瀑布一样。根据 OpenTracing 的规格约定每个 Span 都要包含以下状态状态说明示例操作名称必填可以是访问的一个 URLlocalhost:8808/起/止时间戳必填也可用起始时间和持续时间表示1540273832696773Tags必填一组键值对集合Semantic Conventions 有一些常用约定http.protocolLogs可选填一组键值对集合用于记录调用日志—SpanContext在进程间通信时携带的 span 信息指整个 trace—下面是 Jaeger 收集的来自 Bookinfo 示例中productpage的调用链追踪数据可以看到每个 Span 携带的操作名称、父子引用CHILD_OF、时间戳、耗时duration、tags如component: proxy、node_id以及进程信息processID、serviceName、IP{ data: [ { traceID: aaccbe962478cf93, spans: [ { traceID: aaccbe962478cf93, spanID: fa36a9cbd60b4ae5, operationName: details.default.svc.cluster.local:9080/*, references: [ { refType: CHILD_OF, traceID: aaccbe962478cf93, spanID: 2 } ], startTime: 1540273832696773, duration: 8171, tags: [ { key: component, type: string, value: proxy }, { key: node_id, type: string, value: sidecar~172.33.5.11~productpage-v1-8584c875d8-4jgwg.default~default.svc.cluster.local } ], logs: [], processID: p1, warnings: null } ], processes: { p1: { serviceName: productpage, tags: [ { key: ip, type: string, value: 172.33.5.11 } ] } }, warnings: null } ], total: 0, limit: 0, offset: 0, errors: null }在开发应用时需要使用兼容 OpenTracing API 的 Tracing 实现库例如 Jaeger来实现自动的分布式追踪而在 Istio 服务网格环境中sidecar 代理会自动生成这些 Span 数据上述示例中component: proxy、node_id即来自 sidecar 代理应用几乎无需改造即可获得全链路追踪能力这正是分布式追踪对应用程序透明要求的体现。三大支柱的协同构建完整的云原生可观察性体系指标、日志、追踪三者并非相互替代而是互补协作指标回答有没有问题——通过 RED请求率、错误率、持续时间等汇总数据持续监测服务健康用最小开销建立全局视野配合 Prometheus 告警规则第一时间发现异常日志回答问题是什么——当指标异常时通过日志定位具体的事件细节、请求来源与流转路径如 Filebeat sidecar 或集群级 EFK 方案统一收集追踪回答问题在哪一环——当异常跨越多个微服务时通过 Trace 还原请求从开始到结束的完整路径在分布式环境中精确锁定故障服务或性能瓶颈。三者结合覆盖了从全局态势感知到单点精准定位的完整排障链路。在生产实践中指标层可用 Prometheus Grafana部署清单见 manifests/prometheus日志层可用 Filebeat/EFK清单见 manifests/EFK 与 manifests/test/filebeat-test.yaml追踪层可用 Jaeger 等 OpenTracing 兼容实现若已引入 Istio 等服务网格sidecar 会自动输出 RED 运维指标与链路追踪数据让可观察性体系的构建成本进一步降低。这套以外部输出理解内部状态的方法论正是云原生时代 Kubernetes 集群稳定运行的技术底座。【免费下载链接】kubernetes-handbookKubernetes 架构与生态从云原生到 AI 原生基础设施的构建指南项目地址: https://gitcode.com/gh_mirrors/ku/kubernetes-handbook创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Kubernetes 云原生可观察性（Observability）实践指南：指标、日志与追踪三大支柱详解
Kubernetes 云原生可观察性Observability实践指南指标、日志与追踪三大支柱详解【免费下载链接】kubernetes-handbookKubernetes 架构与生态从云原生到 AI 原生基础设施的构建指南项目地址: https://gitcode.com/gh_mirrors/ku/kubernetes-handbook可观察性Observability是通过指标Metrics、日志Logs和追踪Tracing这些外部输出来理解系统内部状态的能力是 Kubernetes 集群与应用运维的基石。本文以 kubernetes-handbook 仓库的 usecases/observability.md 为骨架结合仓库内 监控实践、日志收集实践、EFK 插件安装 与 分布式追踪实践 等章节系统讲解三大支柱的定义、分类与落地工具链帮助你掌握在云原生环境中看懂系统运行状态、快速定位故障的完整方法论与可执行的配置方案。什么是可观察性可观察性使用指标、日志和追踪这些外部输出来理解系统的能力。这些指标、日志和追踪是基于系统内部的事件产生的——当请求到达系统、被各个服务处理、最终返回结果时系统内部发生的每个事件都会转化为可供外部观测的数据。在传统单体架构中应用部署在一台或少数几台服务器上运维人员可以直接登录机器查看进程状态、读取日志文件系统状态相对透明。而在 Kubernetes 中应用被抽象为 Pod、Service、Deployment 等众多对象且生命周期极短、可以随时漂移和重建直接进到机器里看已经不可行。因此构建一套完整的可观察性体系成为生产环境下 Kubernetes 集群运维的当务之急——正如 practice/monitoring.md 开篇所言Kubernetes 使得管理复杂环境变得更简单但对集群组件和运行其上的应用做到很好的洞察却很困难。可观察性的三大支柱各有分工支柱回答的问题特点指标Metrics系统现在好不好数据总体汇总持续衡量开销小日志Logs系统发生了什么冗长、信息完整记录事件从头到尾追踪Tracing一个请求经历了什么实时捕捉事件行为定位故障发生位置指标Metrics服务健康状况的持续衡量标准指标是数据的总体汇总它能让你了解正在发生的事情和需要深入挖掘的地方。服务不断产生并消费指标这些指标是服务健康状况的持续衡量标准。指标包括两种类型应用/业务指标和运维指标。应用指标Application Performance Metrics应用性能指标APM数据与应用性能有关如加载时间和响应时间用于确保应用向客户提供预期性能。像 Apache SkyWalking 这样的开源技术可以集成到 Istio 服务网格中既可以作为 APM也可以作为额外的服务性能管理Service Performance ManagementSPM系统——一举两得既能看到单次请求的性能细节又能获得服务维度的性能管理视图。运维指标与 RED 方法运维指标关注的是服务的运行情况你的环境表现如何。它通常被描述为 RED 指标Request rate请求率每秒处理的请求数量反映服务的负载和吞吐。Error rate错误率请求中出错的比例反映服务的健康程度。Duration持续时间请求处理的耗时分布如 P50/P95/P99反映服务的响应性能。服务网格比如 Istio唯一关心的就是收集这些运维指标帮助你确定服务表现如何并对服务健康状况有一个大致的了解。在微服务规模下请求率、错误率、耗时这三个维度足以勾勒出服务的整体健康画像这也是 Google SRE 运维理念在云原生时代的自然延伸。落地工具Prometheus 与 Kubernetes 集群监控在指标收集领域Prometheus 是目前 Kubernetes 生态的事实标准。仓库 practice/prometheus.md 指出Prometheus 是由 SoundCloud 开源的监控告警解决方案2016 年成为继 Kubernetes 之后第二个加入 CNCF 的项目。相较以往的系统监控云原生时代监控对象和指标呈指数级增加、监控对象生命周期更短暂正需要一款统一监控指标和数据查询语言的工具。主要功能包括多维数据模型时序由 metric 名字和 k/v 的 labels 构成labels 天然契合 Kubernetes 中 Pod 的 label 体系灵活的查询语句 PromQL无依赖存储支持 local 和 remote 不同模型采用 http 协议使用pull 模式拉取数据简单易懂监控目标可采用服务发现或静态配置的方式——与 Kubernetes 集成时可直接通过 API 服务发现 Pod支持多种统计数据模型图形化友好。核心组件包括Prometheus Server抓取和存储时序数据、提供查询与告警规则管理、client libraries对接 Prometheus Server查询和上报数据、push gateway批量、短期监控数据的汇总节点主要用于业务数据汇报、各种 exporters如汇报机器数据的 node_exporter、汇报 MongoDB 信息的 MongoDB exporter、以及用于告警通知管理的 alertmanager。Prometheus 的大致使用逻辑是Prometheus server 定期从静态配置的 target 或服务发现的 target 拉取数据当新拉取的数据大于配置的内存缓冲区时Prometheus 会将数据持久化到磁盘如果使用 remote storage 将持久化到云端Prometheus 可以配置 rule 定时查询数据条件触发时把 alert 推送到配置的 AlertmanagerAlertmanager 收到警告后根据配置进行聚合、去重、降噪最后发送告警可以使用 API、Prometheus Console 或 Grafana 查询和聚合数据。使用注意Prometheus 的数据是基于时序的 float64 值如果你的数据还有其他类型则无法满足Prometheus 也不适合做审计计费——它按一定时间采集关注系统运行的瞬时状态和趋势能容忍少量数据缺失而审计计费需要记录每个请求并长期存储数据。仓库 practice/using-prometheus-to-monitor-kuberentes-cluster.md 给出了在 Kubernetes 集群中部署 Prometheus 的完整步骤所需 YAML 文件位于 manifests/prometheus 目录## 创建 monitoring namespace kubectl create -f prometheus-monitoring-ns.yaml ## 创建 serviceaccount kubectl create -f prometheus-monitoring-serviceaccount.yaml ## 创建 configmaps kubectl create -f prometheus-configmaps.yaml ## 创建 clusterrolebinding注意先创建 RBAC 对象再部署 kubectl create clusterrolebinding kube-state-metrics --clusterrolecluster-admin --serviceaccountmonitoring:kube-state-metrics kubectl create clusterrolebinding prometheus --clusterrolecluster-admin --serviceaccountmonitoring:prometheus ## 部署 Prometheus kubectl create -f prometheus-monitoring.yaml部署要点RBAC 授权对象serviceaccount、clusterrole、clusterrolebinding应写在一个单独文件中并先于其他资源创建因为kubectl不会判断 YAML 文件中的资源依赖关系只会从文件头部开始依次执行。此外旧版本中kube-state-metrics对 Job、PersistentVolumeClaim、StatefulSet、CronJob 等资源的 API 路径兼容存在差异参见 concepts/rbac.md 关于基于角色的访问控制的说明部署时需要确认集群 API 版本与监控组件的兼容性。监控的三个层次仓库 practice/monitor.md 指出Kubernetes 集群和应用的监控需要关注三个方面——Kubernetes 集群本身各组件、集群中 PodCPU、内存、网络、磁盘等、集群内部应用本身。与物理机监控不同Kubernetes 多了虚拟化层还在 Docker 之上抽象了 Service 概念因此监控时需要考虑给 Pod 打上哪些 label这些 label 将成为监控的 metrics、Pod 漂移后如何持续监控、以及监控指标来源通过 heapster 汇聚还是直接从每台主机的 docker 上取。在监控数据落地时docker inspect $container_name中可见的容器 labels如io.kubernetes.pod.name、io.kubernetes.pod.namespace以及 kubelet 中 BuildDockerName 定义的k8s_容器名_Pod全名_PodUID命名规范都是将容器指标关联回 Pod、Namespace 的关键映射依据。日志Logs记录事件从头到尾的冗长信息日志是冗长的包含一个事件从头到尾的信息。一则日志可以收集匿名用户数据例如哪个用户发出了请求这条请求从哪里开始到达哪些服务等等。如果说指标回答系统现在怎么样日志则回答具体发生了什么是排障时最直接的证据来源。云原生环境下的日志收集方案选型日志的收集方式直接决定运维效率。仓库 practice/app-log-collection.md 对比了 Kubernetes 集群中三种主流日志收集方案编号方案优点缺点1每个 app 的镜像中都集成日志收集组件部署方便kubernetes 的 yaml 文件无须特别配置可以为每个 app 自定义日志收集配置强耦合不方便应用和日志收集组件升级和维护且会导致镜像过大2单独创建一个日志收集组件跟 app 的容器一起运行在同一个 pod 中低耦合扩展性强方便维护和升级需要对 kubernetes 的 yaml 文件进行单独配置略显繁琐3将所有的 Pod 的日志都挂载到宿主机上每台主机上单独起一个日志收集 Pod完全解耦性能最高管理起来最方便需要统一日志收集规则目录和输出方式方案二sidecar 模式在扩展性、个性化、部署和后期维护方面都能做到均衡因此被该实践采纳。在日志收集组件选型上Logstash 基于 JDK单纯启动就约消耗 500M 内存而 Filebeat 单独启动约消耗 12M 内存相当轻量级适合在每个 Pod 中都部署日志收集组件的场景。Filebeat sidecar 收集日志的完整配置以下 YAML完整文件见 manifests/test/filebeat-test.yaml展示了 sidecar 模式的典型做法通过emptyDir卷将 app 的日志目录挂载给同 Pod 内的 filebeat 容器并用 ConfigMap 挂载 filebeat 配置apiVersion: extensions/v1beta1 kind: Deployment metadata: name: filebeat-test namespace: default spec: replicas: 3 template: metadata: labels: k8s-app: filebeat-test spec: containers: - image: harbor-001.jimmysong.io/library/filebeat:5.4.0 name: filebeat volumeMounts: - name: app-logs mountPath: /log - name: filebeat-config mountPath: /etc/filebeat/ - image: harbor-001.jimmysong.io/library/analytics-docker-test:Build_8 name : app ports: - containerPort: 80 volumeMounts: - name: app-logs mountPath: /usr/local/TalkingData/logs volumes: - name: app-logs emptyDir: {} - name: filebeat-config configMap: name: filebeat-config --- apiVersion: v1 kind: ConfigMap metadata: name: filebeat-config data: filebeat.yml: | filebeat.prospectors: - input_type: log paths: - /log/* - /log/usermange/common/* output.elasticsearch: hosts: [172.23.5.255:9200] username: elastic password: changeme index: filebeat-docker-test实践要点将 app 的日志目录挂载到 filebeat 的/log目录下filebeat 即可通过paths配置采集一个或多个日志路径/log/*与/log/usermange/common/*同时生效推荐使用 ConfigMap 管理 filebeat 配置比环境变量方式更灵活——通过环境变量如PATHS、ES_SERVER、INDEX、INPUT_TYPE传参时PATHS只能传递单个目录多目录需自行修改镜像的docker-entrypoint.sh脚本将index值设为service name可以方便地按服务收集和查看日志部署命令为kubectl create -f filebeat-test.yaml部署后可通过curl http://172.23.5.255:9200/_cat/indices查看生成的索引如green open filebeat-docker-test ...并在 Kibana 中查看收集到的日志字段——_index对应 YAML 中配置的 index 值beat.hostname/beat.name即 Pod 名称source表示 filebeat 容器中的日志目录。集群级日志方案EFKElasticsearch Fluentd Kibana对于集群级统一日志收集Kubernetes 官方提供 EFK 方案在每台 node 上部署一个以DaemonSet方式运行的 fluentd 来收集该节点上的日志。Fluentd 将 docker 日志目录/var/lib/docker/containers和/var/log挂载到 Pod 中并在 node 节点的/var/log/pods目录下创建目录区分不同容器的日志输出。仓库 practice/efk-addon-installation.md 给出了完整的安装步骤修改后的 YAML 文件位于 manifests/EFK 目录含es-controller.yaml、es-service.yaml、fluentd-es-ds.yaml、kibana-controller.yaml、kibana-service.yaml与efk-rbac.yaml。安装流程概要创建 EFK 的 RBAC配置 serviceaccount 为efk定义文件为 manifests/EFK/efk-rbac.yaml给 Node 打标签fluentd-es-ds.yaml中设置了 nodeSelectorbeta.kubernetes.io/fluentd-ds-readytrue需在期望运行 fluentd 的 Node 上打标签kubectl label nodes 172.20.0.113 beta.kubernetes.io/fluentd-ds-readytrue执行定义文件kubectl create -f .依次创建 serviceaccount、clusterrolebinding、replicationcontrollerelasticsearch、service、daemonsetfluentd、deploymentkibana验证运行状态通过kubectl get pods -n kube-system | grep -E elasticsearch|fluentd|kibana确认各组件 Running。Kibana Pod 首次启动会用较长时间10-20 分钟优化和 Cache 状态页面可kubectl logs观察进度访问 Kibana通过kubectl cluster-info获取代理 URL/api/v1/proxy/namespaces/kube-system/services/kibana-logging或使用kubectl proxy后访问代理地址在 Settings - Indices 页面创建索引默认logstash-*pattern后即可在 Discover 下查看汇聚的日志。常见问题若 Kibana 的 Create 按钮灰色无法点击且 Time-field name 无选项需检查 docker 的--log-driver配置是否设置为json-file格式默认可能是 journald因为 fluentd 读取的是/var/log/containers/下链接到/var/lib/docker/containers/${CONTAINER_ID}/${CONTAINER_ID}-json.log的日志文件只有 json-file 驱动才会产生该格式的日志文件。追踪Tracing从请求起点到终点的实时捕捉追踪让你能够看到一个请求从开始到结束的过程。它是对事件行为的实时捕捉可以帮助确定故障发生的位置或确定引起当前性能问题的原因。在基于微服务的环境中会产生大量的事件——事件被定义为从请求到达网络外围的那一刻起发生的一切即产生可观察数据的动作。为什么需要分布式追踪当单体应用拆成多个微服务后它们可能分布在上千个服务器、不同的数据中心和可用区中如何监控服务之间的依赖关系和调用链以判断应用在哪个服务环节出了问题、哪些地方可以优化这就需要用到分布式追踪。仓库 practice/distributed-tracing.md 总结了分布式追踪系统的核心要求对应用程序的消耗足够低一是指占用的系统资源要足够低二是指造成的延迟要足够低对应用程序透明为了做到 7x24 小时无所不在的部署要让程序员对程序的改动尽可能的小便于大范围低成本接入这正是 Istio 等服务网格通过 sidecar 自动注入实现追踪的原因可扩展为了将所有服务接入分布式追踪系统该系统必须能够承载大规模服务。此外还要求系统对追踪数据的处理尽可能快、可以方便地对追踪结果进行查询和可视化。OpenTracing 标准与核心术语CNCF 提出了分布式追踪的标准 OpenTracing它提供厂商中立的 API并提供 Go、Java、JavaScript、Python、Ruby、PHP、Objective-C、C 和 C# 等语言的库支持的 Tracer 包括 Zipkin、Skywalking、Jaeger 等。仓库 practice/opentracing.md 对基本术语做了精确定义Trace通常指一次完整的调用链。例如 Jaeger UI 中展示的 Istio 官方 Bookinfo 示例对productpage的调用链分析。Span每个 trace 由一系列 Span 组成一个 Span 可以理解为两个微服务之间的调用如同 Chrome 检查器中查看网络访问瀑布一样。根据 OpenTracing 的规格约定每个 Span 都要包含以下状态状态说明示例操作名称必填可以是访问的一个 URLlocalhost:8808/起/止时间戳必填也可用起始时间和持续时间表示1540273832696773Tags必填一组键值对集合Semantic Conventions 有一些常用约定http.protocolLogs可选填一组键值对集合用于记录调用日志—SpanContext在进程间通信时携带的 span 信息指整个 trace—下面是 Jaeger 收集的来自 Bookinfo 示例中productpage的调用链追踪数据可以看到每个 Span 携带的操作名称、父子引用CHILD_OF、时间戳、耗时duration、tags如component: proxy、node_id以及进程信息processID、serviceName、IP{ data: [ { traceID: aaccbe962478cf93, spans: [ { traceID: aaccbe962478cf93, spanID: fa36a9cbd60b4ae5, operationName: details.default.svc.cluster.local:9080/*, references: [ { refType: CHILD_OF, traceID: aaccbe962478cf93, spanID: 2 } ], startTime: 1540273832696773, duration: 8171, tags: [ { key: component, type: string, value: proxy }, { key: node_id, type: string, value: sidecar~172.33.5.11~productpage-v1-8584c875d8-4jgwg.default~default.svc.cluster.local } ], logs: [], processID: p1, warnings: null } ], processes: { p1: { serviceName: productpage, tags: [ { key: ip, type: string, value: 172.33.5.11 } ] } }, warnings: null } ], total: 0, limit: 0, offset: 0, errors: null }在开发应用时需要使用兼容 OpenTracing API 的 Tracing 实现库例如 Jaeger来实现自动的分布式追踪而在 Istio 服务网格环境中sidecar 代理会自动生成这些 Span 数据上述示例中component: proxy、node_id即来自 sidecar 代理应用几乎无需改造即可获得全链路追踪能力这正是分布式追踪对应用程序透明要求的体现。三大支柱的协同构建完整的云原生可观察性体系指标、日志、追踪三者并非相互替代而是互补协作指标回答有没有问题——通过 RED请求率、错误率、持续时间等汇总数据持续监测服务健康用最小开销建立全局视野配合 Prometheus 告警规则第一时间发现异常日志回答问题是什么——当指标异常时通过日志定位具体的事件细节、请求来源与流转路径如 Filebeat sidecar 或集群级 EFK 方案统一收集追踪回答问题在哪一环——当异常跨越多个微服务时通过 Trace 还原请求从开始到结束的完整路径在分布式环境中精确锁定故障服务或性能瓶颈。三者结合覆盖了从全局态势感知到单点精准定位的完整排障链路。在生产实践中指标层可用 Prometheus Grafana部署清单见 manifests/prometheus日志层可用 Filebeat/EFK清单见 manifests/EFK 与 manifests/test/filebeat-test.yaml追踪层可用 Jaeger 等 OpenTracing 兼容实现若已引入 Istio 等服务网格sidecar 会自动输出 RED 运维指标与链路追踪数据让可观察性体系的构建成本进一步降低。这套以外部输出理解内部状态的方法论正是云原生时代 Kubernetes 集群稳定运行的技术底座。【免费下载链接】kubernetes-handbookKubernetes 架构与生态从云原生到 AI 原生基础设施的构建指南项目地址: https://gitcode.com/gh_mirrors/ku/kubernetes-handbook创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考