开发者学堂课程【探索应用架构，发现预期外的网络流量：探索应用架构，发现预期外的网络流量】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/939/detail/14727
探索应用架构，发现预期外的网络流量
内容介绍：
一、课程整体介绍
二、探索应用架构，发现预期外的流量
三、总结 Kubernetes 监控产品价值
四、Kubernetes 监控 vs 应用性能监控 vs prometheus 监控
一、课程整体介绍
1.为什么需要 Kubernetes 监控？
2.什么是 Kubernetes 监控？
3.Kubernetes 监控系列课程介绍
1.为什么需要 Kubernetes 监控？
应用性能监控主要关注业务应用逻辑，应用框架和部分语言运行时监控对象有线程池满、数据库连接无法获取、慢 SQL 、COM 、调用线、异常栈等。随着 Kubernetes 容器化技术带来的于原生技术，上层技术的开发和运维变得更加简单，但复杂度恒定。上层的复杂度降低必然伴随着底层的复杂度提升，如图所示，复杂度转移到容器虚拟化层以及系统调用和内核层对各种虚拟化程度的支持。每一层都可能出现问题，若出现问题均会影响上层应用，比如：容器虚拟化层的 k8s 组件异常，若调度器异常 pod 将无法调度影响应用；比如：文件系统相关的调用异常，上层应用无法读取文件造成应用问题；比如：内核异常，应用进程无法调度完成工作。应用想要健康的进行，需要软件栈，端到端的健康，现有软件监控，也有应用监控，但没有一个监控可以端到端的串联起来隔层软件的行为，导致极少的问题频频发。比如在应用层一个网络请求超时在客户端和服务端看起来似乎均无问题，但实际上是网络层包发送 rtt 过高，重传率过高亦或是 dns 解析过慢，或者是 cni 插件过慢。如何在 Kubernetes 容器化环境下做到端到端的可观测性，是 Kubernetes 监控出现的意义。
2.什么是 Kubernetes 监控？
立足于容器界面和底层操作系统，向上关联应用性能监控，打造端到端可观测性。
Kubernetes 监控立足于应用监控下的 Kubernetes 容器界面和底层操作系统。具体来说，在容器虚拟化层，通过以下五个数据源获取观测数据，即：通过 k8s 管控组件 exporter 来获取 k8s 管控组件的运行数据；通过 cAdvisor 获取容器的资源运行数据；通过 kube-state-metrics 获取资源的状态数据；还包括事件，资源的状态和条件。在系统调用层，通过 meditation 技术获取观测数据，在内核层，通过内核可观测模块获取观测数据， Kubernetes 监控通过进程，容器， Kubernetes 资源和业务应用的关联关系，向上关联打通应用性能监控，打造端到端的客观性。所以 Kubernetes 监控是 Kubernetes 软件栈端到端可观测性的一体化决策方案。在 Kubernetes 监控中，可以同时看到关联层的所有观测数据。
3、Kubernetes监控系统课程介绍
Kubernetes 监控系统公开课旨在于一系列最佳实践，让用户可以使用 Kubernetes 监控解决 Kubernetes 环境下棘手的可观测问题。分为两种类型
①发现问题包含：探索应用构架，发现预期外的流量；发现服务，工作负载的性能异常；发现流量不均匀的服务和工作负载；发现资源配额和限制不合理的 pods；发现资源使用不均匀的 nodes ；发现服务和工作负载的连通性问题；发现 pods 调度问题：无法调度和调度慢；发现 pods notready 问题（即应用架构问题，性能问题，资源问题，调度问题，网络问题）
②定位问题包含：定位服务，工作负载响应失败的根因；定位服务，工作负载响应慢的根因；定位服务，工作负载流量不均的根因；定位服务，工作负载无法连通的根因；定位 pods 无法调度与调度慢的根因；定位 pods notready 的根因（即对以上五类问题进行根因定位并且提供修复建议）
二、探索应用架构，发现预期外的流量
1.背景介绍：说明应用架构探索的挑战
2.典型场景：说明在哪些场景下需要应用架构的探索
3.最佳实践：介绍一种应用架构探索的模式，高效的发现定位问题
1.背景介绍
应用探索的挑战1：混沌的服务架构
在 Kubernetes 应用架构中微服务架构是最普遍的服务架构。在该架构下，随着业务的发展一定会有越来越多的微服务，它们之间的关系会越来越复杂，在复杂度不断增长的情况下，一些常见的架构问题，比如：应用当前架构怎样？应用下游是否正常？应用上游客户端流量是否正常？应用 dns 解析是否正常？两个应用之间的连通性是否正常？
应用探索的挑战2：多语言
在微服务架构里，各个微服务通常可以使用不同编程语言。只需暴露出标准的服务即可。不同语言如何进行监控埋点？是否有相同的埋点模式？是否对应语言具有好用高效的埋点工具？代码侵入对性能影响，是否埋点代码会影响业务运行呢？
应用探索的挑战3：多通信协议
在微服务架构里，各个微服务之间，可以使用不同的通信协议，比如： HTTP、gRPC、Dubbo、Kfakfa 等，往往需要识别这些协议才能快速发现对应依赖服务的问题，但是识别协议意味着理解各个协议，在合适地方需要进行埋点，不同通讯协议如何统一埋点？代码侵入是否会影响业务性能？
2.典型场景
通过使用场景判断出应用架构探索是否值得为解决的问题，需要应用架构。
典型场景一：架构感知
根据真实的网络调用，将微服务作为节点，微服务的调用作为边绘制出图谱，通过对比静态服务的期望架构，发现问题，比如：是否少了某个微服务？微服务之间的关系是否正常？通常在新应用上线，新地区开服，整体链路梳理等需要关注结构大图的场景使用。
典型场景二：异常发现
通过自定义架构拓扑图中节点异常规则，显示对应的异常颜色，能够快速的发现异常节点和边，通常在整体电路梳理和健康巡检等关注的边和状态场景下进行使用。
典型场景三：关联分析
通过异常发现定位到某个节点或者边异常时，需要关联关系的切换，快速查看节点或者边的上下游以及对应服务的自身实力。通过回答自己的是否有问题，依赖是否存在问题，一步一步缩小问题范围。
3.最佳实践
以上三个典型场景，可由最佳实践串联使用。首先通过构架感知，观测应用实际运行架构是否和预期一致，如果存在结构性问题，需要进一步排查结构异常的服务，若不存在结构性问题，进行下一步。通过异常发现是否有颜色异常的节点和边，无异常进行下一步。到特定的节点和边进行关联分析，先分析自身实例是否异常，然后分析上下游依赖是否异常。（如图所示）
4、Kubernetes 集群拓扑--架构感知
Kubernetes 监控通过真实的网络监控绘制出应用架构拓扑图，当前提供 service 和 workload 两种视图。前者是 service 之间的服务调用，
后者是 deployment 、demonstrate、standset 服务调用，进入拓扑图默认对节点进行分组，收敛起来。集群内按命名空间进行分组，集群外按服务类型分组。展开节点可以看到对应的节点关系，点击节点可以看到选定时间范围内的性能指标，数据和时序值，这些值按网络协议进行划分。点击边可以看到选定时间范围内的性能指标，聚合值和
时序值按网络协议进行划分。在配合节点过滤，比如查看两个特定命名空间的架构关系以及节点查询。快速查看一个节点可以对架构进行探索。
5、Kubernetes 集群拓扑--异常发现
Kubernetes 监控通过三个维度的异常条件将节点和边绘制成异常的黄或者红的颜色。具体来说，三个边是性能指标异常，比如说：错误率大于百分之十，平均响应时间大于五百毫秒。资源指标异常，比如说： cpu 使用率大于百分之七十，内存使用率大于百分之七十。 k8s 管控状态异常，比如说：pods 无法到达 notready 状态。在分组收协状态下，展开分组可以看到特定的节点和边的异常。通过 galaxy 可以发现特定的微服务及微服务关系的异常。
6、Kubernetes 集群拓扑--关联分析
Kubernetes 监控具备关联分析的能力，支持查看特定节点的上下游，提供 3D 拓扑查看上下游和自身实例状态，可以在一张图进行所有关联数据的探索，极大提升问题定位的效率。
7、演示
首先进入到 arms 产品的集群拓扑页面可以看到在 service 视图，
放大视图，可以看到收缩的节点分组。在开始部署的节点应用，该应用是 testdemo1 不断的调用 testdemo2 ，testdemo1 不断访问外部的
Redis 和 mysal 服务，均被识别。所以在第一步，在架构感知中可以发现，整体架构是正确的。同时也可观察 kube-system 中的各个节点。
当架构感知没问题时，可看到异常发现在节点收敛时，在外部可显示其占异常的比例，点开后可见特定节点。由图可见， testdemo2 和 kube-dns 是黄色，点击查看，发现其错误数极高，直观可见其为黄色，点击 kube-dns 发现其错误数也极高。
与此同时，可见峰是斜倚，也可查看具体的错误，如图可见，源端对kube-dns 服务发起改域名的请求，响应可见返回码，输入发现该域名不存在。找到问题的根因是 arms-prom-admin 这样的 service 对kube-dns 发起的不存在的域名解析。回到 testdemo2 ，该程序在设计之初为每秒调用一次，可见其请求数维持在每分钟六十次，存在大量错误点击查看，返回码为400，异常发现之后开始进行诊断关联的数据。同时可以查看节点的上下游，由图可知，是整个集群调用 kube-dns 的服务，主要是 testdemo1 和 arms-prom-admin ，与此同时，kube-dns 调用外部的 dns 服务也请求 kube-dns 服务，其还支持查看特定节点容器 3d 拓扑图，由图可见底层的 pod、container、note 的状态。
返回到拓扑图可以直接输入查看节点。通过节点过滤查看特定两个命名空间的应用拓扑。
三、总结 Kubernetes 监控产品价值
阿里云 Kubernetes 监控是一套针对 Kubernetes 集群开发的一站式可测性产品。基于 Kubernetes 集群下的指标、应用链路、日志和事件，阿里云 Kubernetes 监控旨在为 IT 开发运维人员提供整体的可观测性方案。
Kubernetes 监控具备以下特性：
代码无侵入：阿里云 Kubernetes 监控通过旁路技术，不需要对代码进行埋点即可获取到丰富的网络数据。
语言无关：阿里云 Kubernetes 监控在内核层进行网络协议解析，支持任意语言，任意框架。
高性能：阿里云 Kubernetes 监控基于 eBPF 技术，能以极低的消耗获取丰富的网络性能数据。
资源关联：阿里云 Kubernetes 监控通过网络拓扑，资源拓扑展示相关资源的关联。
数据多样：阿里云 Kubernetes 监控支持可观测的各种类型数据（监控指标、链路、日志和事件），涵盖端到端的软件栈。
整体性：阿里云 Kubernetes 监控通过控制台等场景设计，关联起架构感知拓扑、应用监控、prometheus 监控、云拨测、健康巡检、事件中心、日志服务和云服务。
四、Kubernetes 监控 vs 应用性能监控 vs prometheus 监控
如图所示，主要有三个要点：应用性能主要关注逻辑，框架与编程语言； Kubernetes 监控主要关注系统网络和容器界面，同时向上关联应用性能监控； prometheus 监控主要关注基础设施，Kubernetes 监控和应用监控指标类数据将会存储在 prometheus 监控中。
