顾静, 阿里云 邓隽, 阿里云 Kubernetes 异常配置检测框架 我们来自阿里云容器服务 • 顾静，研发工程师 • 邓隽，技术专家 我们参与打造 • 容器服务（ACK/ASK） • 容器镜像服务（ACR） • 服务网格（ASM） • … 1 Kubernetes 典型异常 2 检测框架演进 3 生产实践 4 总结 Kubernetes 使用日常 • 应用部署 • API Server Pod Master API Server Pod Master API Server Pod Kubernetes 典型异常 网络异常 • 安全组、路由表配置错误 • 节点防火墙软件等修改 iptables、内核参数 • 网络链路长，手动排查成本高 异常影响 • 应用间无法正常通信 • 集群内 Controller 无法正常工作 YUM 安装自动运维工具 在集群中运行 CIS Benchmark 检测项依赖于 CIS Benchmark 内容 能发现集群核心组件配置错误 无法发现如 Flannel 组件异常 增加检查项流程较复杂 kuberhealthy 在集群中运行 CronJob 实现检查 可以自定义检查项 无法检测集群核心组件配置 集群异常时无法进行检测 kube-hunter 适用于集群安全检测 仅能检测集群安全性 kubectl-trace

2019.8.11 Service Mesh Meetup #6 广州站基于 Secret Discovery Service Sidecar 的证书管理方案 使用可信身份服务构建敏感数据下发通道 Service Mesh Sidecar 的 TLS 生产级落地实践 分享内容基于 Secret Discovery Service Sidecar 的证书管理方案 Kubernetes SDS方案，实现了 SDS Server 和 SDS 配置管理。Istio 方案中选择 UDS 通信方案，Istio的 方案证书管理流程由 Citadel , Citadel Agent , Pilot 协同完成  Pilot 负责 UDS 路径配置下发，用户通过 Policy CRD 和 DestinationRule 来决策需要给哪些 Sidecar 下发  Sidecar 收到SDS Config Agent请求证书  Citadel Agent 会将Sidecar 的请求包装成CSR 请求Citadel ，Citadel 会先检查缓存中是否已有证书，如果不 存在的话，会基于Citadel 启动时配置的二级ROOTCA签发证书基于 Secret Discovery Service Sidecar证书管理方案 Istio With Envoy SDS Benefits:  The private

Zookeeper • 胖客户端 • 基本服务治理功能 App OSP Server Service Registry Service Config Center 服务发现 服务注册 服务元数据下发 OSP client 服务路由 网络传输 服务元数据上报缺点 • 语言单一 • 升级困难 • 复杂代码嵌入对客户端进程影响大服务化体系2.0 - Service Mesh雏形 • 物理机、sidecar Server Service Registry Service Config Center Remote Proxy Cluster API Gateway 备用链路 服务发现 服务注册 配置下发 服务路由 网络传输 OSP client多语言客户端接入 • HTTP & TCP • Local & Remote • 根据接入对象的不同，制定 不同的接入策略，达到 • 接入简单 切换地址到remote proxy，轻 易实现优雅退出和滚动升级 • 增强隔离性 • Local Proxy被pod共享 • 自保护，对来源方限流和流量 转移 • 资源适配 • 根据宿主机的硬件配置定制不 同资源配置的Daemonset Local Proxy Pod 写入地址 监听变化 宿主机 Proxy address File Pod Remote Proxy Cluster

现 Demo 的演示3/23 为什么需要 Service Mesh 改造 /01 对比传统微服务架构和 Service Mesh 化之后有哪些优缺点4/23 微服务 模块 • 安全 • 配置中心 • 调用链监控 • 网关 • 监控告警 • 注册和发现 • 容错和限流 特点 • 独立部署 • 强化模块边界 • 技术多样性5/23 Service Mesh 优点 • 负责网格中的流量管理以及控制面和数据面之间的配置下发，在 Istio1.5 之后合并了 Galley、Citadel、Sidecar-Inject 和 Pilot 成为 Istiod。 功能 • 根据不同的平台（Kubernetes、Console） 获取一些资源（Kubernetes 中使用 Informer 机制获取 Node、Endpoint、 Service、Pod 变化） • 根据用户的配置（CR、MCP 根据用户的配置（CR、MCP 推送，文件） 触发推送流程 推送流程 • 记录变化的资源类型 • 根据变化的资源类型整理本地数据 • 根据变化的资源类型判断需要下发的 xDS资源 • 构建 xDS 资源，下发到连接的 Sidecar10/23 xDS Sidecar 通过动态获取服务信息，对服务的发现 API 被称为 xDS。 • 协议部分（ADS、控制发送的顺序以及返回的确认数据） • 数据部分（CDS

可观察性：遥测数据、调用跟踪、服务拓扑 通信安全： 服务身份认证、访问鉴权、通信加密 Proxy Application Layer Service 1 Istio 流量管理 – 概览 • 控制面下发流量规则： Pilot • 数据面标准协议：xDS • 集群内Pod流量出入： Sidecar Proxy • 集群外部流量入口：Ingress Gateway • 集群外部流量出口：Egress Gateway（可选 内部客户端 Service2 Service1 网格内部 定义网格入口 • 服务端口 • Host • TLS 配置 • 路由配置 • 根据 Host 路由 • 根据 Header • 根据 URI 路由 目的地流量策略配置 • LB 策略 • 连接池配置 • 断路器配置 • TLS 配置 Gateway External Service 统一网格出口 • 出口地址（Gateway Workload） 对外请求 对外请求（Passthrough/ServiceEntry） 缺省路由 （服务名） 5 Istio 流量管理 – 数据面 – Envoy配置模型和xDS协议 ADS Server LDS RDS CDS EDS Envoy 配置模型的主要概念： • Downstream：连接到 Envoy 的下游 Host，发送请求并接收响应。 • Upstream： 上游 Host 接收来自 Envoy

理想的服务网格应该是什么样？ 易于扩展 理想的服务网格 业务无感知 落地成本低 动态且增量配置 安全管控 可观测 流量精细化管理 跨集群部署 性能损耗低 资源消耗低 按需下发配置 理想的服务网格 整体使用体验上 • 学习和上手成本低 • 社区开放、活跃度高 且快速响应 理想的服务网格 控制面 • 易于上手 • 权限安全管控 • 配置方式被大众接受 理想的服务网格 数据面 • 支持多种协议，甚至是自定义协议 降低 Sidecar 资源占用  按需下发配置  配置本身的精简 资源占用降低了 60% 较低的学习/维护成本  APISIX 丰富的文档，快速上手  抽象出来的网关对象通俗易懂  源码基于 lua 易学易懂  二次开发相比 C++ 要简单许多 强大的扩展/定制化能力  配合CRD进行扩展，更灵活 更原生 不侵入Istio原有配置 降低用户迁移成本/减少冲突可 能 通过 通过 controller 与 amesh 进行 配置推送 强大的扩展/定制化能力  APISIX 官方提供 80+ 插件  支持自定义插件，并且快速集成  支持多语言开发  golang  python  java  wasm  ...... 满足多协议的需求 APISIX Service Mesh  上手成本低  开发及扩展相当容易  性能优（尤其是多路由场景）

nfs prometheus filebeat elastsearch flanneld calico openstack kvm docker 镜 像 管 理 弹性伸缩 智能调度 配置管理 健康检查 服务发现 动态dns 负载均衡 容器监控 日志采集 应用监控 节点监控 动态存储 本地存储 网络存储 静态存储 代码检查 代码编译 镜像编译 服务发布 镜像同步 镜像上传 镜像下载 k8s-api配置对象 作用 k8s-namespace 通过配置文件关键字dev/test/prod等声明应用所属的环境，隔离不同环境业务，通过特定标识来识别业务线。 k8s-service k8s-dns注册服务名，通过配置文件关键字关联业务线应用名称，保持应用和k8s之间的关联。 k8s-app-name 容器host应用名称，deployment 名，通过配置文件关键字关联业务线应用名称，保持应用和k8s之间的关联。 由flanneld下发的子 网到达pod容器; 工作原理： Flannel负责在容器集群中的多个节点之间提供第3层IPv4网 络。 工作模式： 1.vxlan 通过封装协议解包收发包mtu1450，vxlan可以在分 布多个网段的主机间构建2层虚拟网络 。 2.host-gw 通过宿主机路由同步收发包，必需工作在二层。 1.系统启动，flanneld下发docker子网配置，docker启动获

运维人员设置请求路由规则，将不同来源的请求路由到不同的服务实例 组进行处理。 #IstioCon Aeraki Demo: 用户请求和批处理任务隔离(Dubbo) 1. 在 dubbo: application 配置中为 Provider 增加 service_group 自定义属性 2. 通过 Provider 的 deployment 设置 SERVICE_GROUP 环境变量 3. 在 consumer provider 的地域属性为provider实例配置 不同的LB优先级，优先级的判断顺序如下： 1. 最高：相同 region，相同zone 2. 其次：相同 region，不同zone 3. 再次：不同 region #IstioCon Aeraki Demo: 地域感知负载均衡(Dubbo) 1. 在 dubbo: application 配置中为 Provider 增加 aeraki_meata_locality Plugin 实现控制面的流量管理规则下发 ： 1. Aeraki 从 Istio 中获取 ServicEntry，通过端口命名判断 协议类型（如 tcp-metaprotocol-thrift） 2. 为 MetaProtocol 服务生成数据面所需的 Filter 配置 ，Filter 配置中将 RDS 指向 Aeraki 3. Istio 下发 LDS(Patch)/CDS/EDS

日志AIOps探索 3 背景与挑战 产品数量 人员规模 主机规模 100+ 1000 + 10000 + 如何降低日志接入门槛 如何保证日志实时上报 如何保障日志采集不影响业务 如何做配置标准化 如何帮助业务快速排障 如何提供方便便捷的性能分析 调优能力 … 4 多Beats/Logstash接入 管控 提供多产品接入管理，多beats标准 化、界面化、自动化的日志接入方案 日志热数据保存七天 历史数据冷备一个月 其他诉求 日志上报不能影响核心业务 数据上报延时可感知 准备ES 安装Filebeat 编写Filebeat配置文件 测试并下发配置 全网重启filebeat 检测数据是否上报 传统Beats接入流程 配置更改 现网配置是否全部一致？ 日志上报是否有延时？ Filebeat是否资源消耗过多？ Filebeat异常退出如 何处理？ 如何做上报性能调优？ 如何做上报性能调优？ 6 系统架构 云Kafka Api-server2 Consul 云ES Agent-1 Agent-N Agent-1 Agent-N 数据流 配置监听 Agent注册 配置下发 Web-UI Api-server1 HostGroup HostGroup MasterCluster Opsd Monitord Syncd … … 腾讯云产品

图
1-1
API7
架构图
上图为
API7
产品中控制平⾯（简称
CP）与数据平⾯（简称
DP）的架构⽰意图，并包含了3个部分：
API
⽹关
1. ⽤于承载并处理业务流量，管理员在配置路由规则后，⽹关将根据预设规则将请求转发⾄上游服务。 此外，借助
API7
内置的
50
多种插件，可实现⾝份验证、安全防护、流量控制、分析监控、请求/响应 转换等常⻅业务需求；若内置插件⽆法满 数据平⾯⽤于接收并处理调⽤⽅请求，使⽤
Lua
与
Nginx
动态控制请求流量。当请求进⼊时，将根据 预设路由规则进⾏匹配，匹配到的请求将被⽹关转发⾄对应上游服务。在此过程中，⽹关有能⼒根据 预设规则中不同插件的配置，使⽤⼀系列插件对请求从进⼊到离开的各个阶段进⾏操作。例如：请求 可能会经过⾝份认证（避免重放攻击、参数篡改等）、请求审计（请求来源信息、上游处理时⻓ 等）、路由处理（根据预设规则获取最终上游服 控制平⾯包含了
ManagerAPI
与默认配置中⼼
ETCD。管理员在访问并操作控制台时，控制台将调⽤
ManagerAPI
下发配置到
ETCD，借助
ETCD
Watch
机制，配置将在⽹关中实时⽣效。例如：管理员可 增加⼀条路由，并配置限速插件，当触发到限速阈值后，⽹关将会暂时阻⽌后续匹配到该路由的请求 进⼊。借助
ETCD
的
Watch
机制，当管理员在控制⾯板更新配置后，API7
将在毫秒级别内通知到各个