开发者学堂课程【云原生实践公开课：第3步 Kubernetes 集群的监控和日志】学习笔记，与课程紧密联系，让用户快速学习知识
课程地址：https://developer.aliyun.com/learning/course/698/detail/12268
第3步 Kubernetes 集群的监控和日志
内容介绍：
一、 监控体系介绍
二、 日志体系介绍
三、 回归可观测性的本质
四、 阿里云可观测性体系
五、 容器可观测性的困境
一、监控体系介绍
容器可观测性的困境
容器可观测性主要由监控与日志两大部分组成，监控系统可以帮助开发者查看系统的运行状态，而日志系统可以协助问题的排查和诊断，但是和传统的可观测性体系相比，容器的可观测性带来了新的挑战。
- 可监控的内容变多了应该怎么选型?
传统架构:资源监控、应用监控
容器架构:资源监控、管控系统监控、微服务拓扑监控、中间件系统监控、应用监控
Kubernetes 通过标准化的方式定义了交付，同样也规约了可观测性的接入方式，从而更多的组件可以接入到监控体系。
- 采集的方式动态化了应该怎么使用?
传统架构:配置静态采集对象、正向拓扑关系配置
容器架构:服务发现动态采集、反向拓扑关系聚合
在 Kubernetes 中，监控采集的对象会随着应用的发布、升级而动态生成与销毁。因此采集对象的元数据和监控数据应该是解耦的、动态的，并通过一定的规则进行聚合。
- 观测性能力整合了应该怎么运维?
传统架构:
-报警->运维->报警消除
容器架构:
–报警->自愈->报警消除->复盘
–报警->自愈失败-→运维->报警消除
在Kubernetes 中，所有的监控对象默认都是可宕机、可漂移、可恢复的。因此，故障产生和自愈是同步进行的，报警与报警消除是用来回溯自愈能力是否生效的方式，我们应该将系统设计符合自愈的要求，降低人工的运维。
二、监控体系介绍
1. Kubernetes的监控体系–常用的监控方式
- 资源监控
CPU、内存、网络等资源类的指标，常以数值、百分比为单位进行统计，是最常见的资源监控方式。
- 性能监控
应用的内部监控，通常是通过Hook的机制在虚拟机层、字节码执行层隐式回调，或者在应用层显示注入，获取更深层次的监控指标，常用来应用诊断与调优。
- 安全监控
这个在容器里边，也是比较常见的，特别是对于一些对外提供多租服务的一些客户，比如说一个集群里对外服务了很多客户，然后客户之间有数据的隔离性的要求，有网络隔离性的要求等等，那这时，会针对不同的安全进行的一系列监控策略，例如越权管理、安全漏洞扫描等等。
- 事件监控
Kubernetes 中一种另类的监控方式，紧密贴合 Kubernetes 的设计理念，补充常规监控方案的缺欠与弊端。
事件监控K8S里面的这个有一个非常重要的机制，就是这个状态机的机制，状态之间的这个转换，就是把装载机画出来的状态之间的这个转化，就是那条转化的那条曲线。
2. Kubernetes的监控体系–监控接口标准化
- 选择 Kubernetes 监控的方案时需要考虑因素不止有提供的监控指标丰富度，还
有与 Kubernetes 的整合能力的完备性，包括上层 kubectl 的查询、HPA 的弹性能力等等。
- 那K8s和监控方案之间的整合是通过三种接口来对外实现，分别是 Resource
Metrics、Custom Metrics、External Metrics。
- Resource Metrics、Custom Metrics、External Metrics 三种接口的对比:
监控接口标准：Resource Metrics
APIService 地址：metrics.k8s.io
接口使用场景描述：主要用于Kubernetes内置的消费链路，通常由 Metrcis-Server提供。
监控接口标准：Custom Metrics
APIService地址：custom.metrics.k8s.io
接口使用场景描述：主要的实现为 Prometheus，提供资源监控和自定义监控
监控接口标准：External Metrics
APIService地址：external.metrics.k8s.io
接口使用场景描述：主要的实现为云厂商的 Provider 提供云资源的监控指标
3. Kubernetes的监控体系-metrics-server
metrics-server
- metrics-server 是一个监控的聚合和监控的接口的提供方。在 KS 里面，整个监
控采集并不是 metrics-server 去采集，而是 cgroup [Linux Kernel]来采集的。
- 容器的场景的一个底层的原理就是基于 Linux name space，然后通过 cgroup
做隔离，也就是说，监控指标在cgroup那层就已经决定好了，只是这个监控的数据，在 Cgroup 层是一个不太可读的一个状态。
( 1)优点
- Kubernetes 社区孵化的监控采集组件-简单便捷，提供 Kubernetes 集成完备性
(2)缺点
-无法支持自定义监控
4. Kubernetes的监控体系-prometheus
Prometheus
(1) 优点
- CNCF社区孵化的监控采集组件
- 社区活跃且丰富度较高
- 功能强大且灵活
(2）缺点
- 学习成本高
- 架构复杂性较大
- 组件成熟度良莠不齐
- 资源消耗较多
5. Kubernetes 中日志的分类
- 主机内核的日志
主机内核日志可以协助开发者诊断例如:网络栈异常，驱动异常，文件系统异常，影响节点（内核）稳定的异常。
- Runtime 的日志
最常见的运行时是 Docker，可以通过 Docker 的日志排查例如删除 Pod Hang 等问题。
- 核心组件的日志
APIServer 日志可以用来审计，Scheduler 日志可以诊断调度，etcd 日志可以查看存储状态，Ingress 日志可以分析接入层流量。
- 部署应用的日志
可以通过应用日志分析查看业务层的状态，诊断异常
6. Kubernetes 中日志的采集方式
只要有三种采集方式：挂载宿主机采集、标准输入输出采集、sidecar采集。
(1） 挂载宿主机采集
直接把这个日志路径挂出来，挂到这个宿主机特定的一个路径，然后再把对应的这个配置下沉，给采集的组件，由采集的组件去生成采集任务，把这个数据收回到监控的整个离线的数据通路里面，实现数据采集。
(2） 标准输入输出采集
容器里边最常见的、最推荐大家使用的采集方式。在程序里面自己去设置日志，导流到标准输入输出里边，那此时你就可以通过 controllog 或者是这个 doctor locks直接去获取对应的日志。和挂载宿主机采集没有太大的差别。
(3)sidecar 采集
这个采集方式是需要注入一个 container 到我们的 pod 里，然后让两个 container互用相同的这个 name space，两者可以共享 PID/共享文件。然后，在 sidecar 里面去安装对应的 language 然后把它去写到远程。
这种方式，一般情况下是组件要有一些特别的一个诉求，比如，组件里面有一些安全的一个策略，就必须要独立采集，不能够混在一起采集等等，会使用 sidecar 采集。
这三种方式，其实就是K8S里面标准的日志采集的一个主要的策略。
7. Kubernetes 开源日志方案–Flunetd
- Flunetd 中的 Flunetdb 就是采集的一个 agent，然后由 agent 去把对应的数据
推到 Flunetd，再由 Flunetd 去连线 elasticsearch 等再进行整合。
- 不太建议在云上的这个场景，或者是在自建的这个场景直接去使用 Flunetd，建
议大家是使用类似一些云厂商提供的日志策略。比如说在云上的时候，可以通过不同的云厂商提供的日志策略，那种动态的配置策略去实现共同采集。在云下可以把集群移动到云上，然后再下载云上提供的日志组件。
三、回归可观性的本质
1. 回归可观测性的本质–提高系统稳定性
容器可观测性的本质是为了更全面、更快速、更准确地发现系统的问题，核心目标是为了提高系统的稳定性，提升系统稳定性不能只依赖可观测性的滞后的运维操作，而是要把怎么减少出现问题并降低影响范围，怎么准确快速定位问题，标准化的问题怎么系统解决这三个策略整合起来。
(1） 如何减少出现问题，有以下建议：
- 集群组件尽可能精简，减少全局组件
- 应用配置合理的 Request/Limit 超卖比
- 在线业务配置 Readiness/Liveness
(2） 如何更快速、更准确定位问题
- 建立有梯度的监控体系
- 事件监控是容器场景下的利器
(3） 标准化的问题怎么系统解决
- 资源/容量的问题配置HPA或者资源弹性
- 常见的问题固化为自愈脚本、文档、手册
2. 可观测性不是一次性投入，而是持续迭代的循环
阿里云可观测性体系–监控
- 该图为阿里云监控体系的全貌，SLS 是一个日志服务，可以采集系统组件的日
志、网关的日志、应用日志等等。在 SLS 之上，还有各种不同的这个可视化的Dashboard，在 Dashboard 里面去查看特异性的可视化分析。
- 第二个就是APM工具，在阿里云上的arms的这个组件, 实际上是通过 kubelet
AHAS Agent 的方式进行注入的，开发者无需关心怎么去集成它，只需要通过Application Performance 就可以动态的使用这个 APM 的这个能力。
- 第三个是 AHAS，是一个应用 Topology Architecture Monitoring 控制的一个
组件，在容器上很多的服务是微服务的架构，微服务架构里面有一个很重要的一个问题，就是服务之间的流量治理的问题，那对于这个问题来讲，AHAS 是非常合适的，可以可视化微服务框架的东西和南北的流量走向，并且设置对应的一些报警策略来去实现深入的监控，就是云监控。
- eventer 是独立的一个事件监控体系，可以配合 npd，去采集积累上的一些异
常，由 npd 产生对应的事件，再由 eventer 去连线到客户的软件。
四、阿里云可观测性体系–日志
日志体系是基于 Log-Pilot 的一个开源组件来去实现的，Log-Pilot 可以去采集 pod 的日志，到 engine 的日志和一kubelet等等一系列日志，还有 Linux kernel 的日志，并且把这些日志统一聚合到 SLS，由 SLS 去负责上层的这个可视化，以及数据离线和归档，和对应的这个日志分析的这个处理的逻辑。
实操：
- 首先，先部署一个应用 workshop： kubectl apply -f deploy . yaml，这个应
用两个副本的 replicas，然后申请1cpu的资源。
- 应用布置下去之后，看应用目前的一个状态，现在使用多少资源，输入pod，发
现集群里由于没有安装任何监控组件，有一个错误，就目前的 pod 命令是无法使用的。
- 部署一个 metrics-server，观察如何与 Mac、搜狗之间进行联动。在阿里云
上，这些步骤不需要去做，因为阿里云上默认情况下已经安装好了 metrics-server。
- metrics-server 由三部分组成 metrics-server 的组件、rbac、svc。
- 首先 workshop kubectl apply -f rbac.yaml，创建完成后，在 workshop
kubectl apply -f svc.yaml，之后是 workshop kubectl apply -f metrics-server.yaml，然后 workshop kubectl get pod -n kube-system，查看 metrics-server的状态，已经安装完成。
- 但是还不能使用，因为 metrics-server 和 K8s 之间还没有整合，workshop
kubectl apply -f apiservice.yaml，注册一个 apiservice，之后就可以正常使用metrics-server了。
- 下载 HPA workshop kubectl apply-f hpa.yaml，使用 HPA workshop kubectl
describe hpa nginx-deployment-basic-hpa，刚开始的时候，这个地方是一个unknown 的一个状态，正常情况下，应用没有任何问题或异常的时候，这个地方应该是有值的，HPA 是15秒钟做一次判断，所以，当15秒判断之后，获取第一次这个监控指标，当这个监控指标获取到了之后，才会开始判断当前 HPA 的一个弹性。
- status 其实就是状态集中的一个一个的步骤。如果当前这个状态， desired 这
个状态由2改为1的话，在 Events 会生成对状态机的这个转化事件。
