Kubernetes 集群运维实践 关注“阿里巴巴云原生”公众号 回复 1124 获取 PPT自我介绍 •嵌入式、微服务框架 •2017 年加入阿里巴巴，负责阿 里集团数十万集群节点规模化运 维管理系统的研发工作 •2019 年参与集团全面上云项目 并经历了整体架构的云原生升级 演进，稳定支撑双11峰值流量分享内容 • 阿里全站上云 • 神龙 (what & why) • 规模化集群运维实践 • Overlay网络 集团机房 云上机房 基础设施 IDC 系统 基础运维 天基系统 CMDB 安全审计 单机监控 ASI 平台 kubelet/Pouch CI/CD k8s extended Service Mesh 安全容器 运维管控 在离线混部 额度管控 监控体系 多租隔离 上层业务 集 团 业 务运维挑战 • 规模大 • 集群规模大 (数十个集群)，节点数量多 (数十万节点) (数十万节点) • 业务线多、应用数量多、应用类型复杂 (有状态、无状态、多语言) • 基础环境复杂 • 大规模 在线、离线 混部 (运维打通) • 装机模板、OS版本、内核版本多；内核补丁、参数不同；其他如网卡中断打散 • 稳定性要求高 • 性能、宕机、夯机、抖动系统架构 • 基础监控 • 秒级、分钟级监控 • 内核性能指标采集 • 监控大盘 • 在线率 • 宕机率 • 抖动率 • 基线系统

三、发布运维体系 目 录 contents 目录3/20 一、业务背景 业务背景4/20 业务背景 业务架构 演进 • 容量  应用|数据库|机房 • 容灾  机房|地域5/20 业务背景 业务架构 单元化 • 高可用 • 一致性 • 可扩展 • 高性能6/20 业务背景 业务诉求 • 运维成本  突发流量应用 | 机房 生命周期 • 运维效率  PaaS 能力 • 面向多租户多环境； • 基础资源管控； • 应用发布运维体系； • 业务实时监控，日志收集； • 机房级和地域级容灾能力; 业务背景业务背景 CAFÉ API Server Aggregation Layer 异地多活架构 同城双活架构 K8S API Server 基础发布运维 跨集群应用 资源管理 IaaS层（Aliyun/OpenStack/VMWare/Bare 流 程 两地三中心架构 跨机房和地域统一应用运维 容器运行时 （Docker/Pouch/安全容器） CNI Plugins (VLAN/VXLAN/VPC Router/ENI) CSI Plugins (NAS/OSS/Cloud Disk/Ceph) 网络接入 (SLB/ALB) 容 器 层 跨集群管理 单元化能力 容器镜像管理 批次发布 原生资源管理 Pod伸缩管理

为前提条件检查结果提供集群级别的全局2级缓存 • 灵活的适配器模型，使其以下操作变得简 单： • 运维添加、使用和删除适配器 • 开发人员创建新的适配器（超过20个适配器）Part 1：ServiceMesh灵魂拷问一：要架构还是要性能？ Mixer v1 架构的缺点 • 管理开销 • 管理Mixer是许多客户不想负担的 • 进程外适配器强制运维管理适配器，增加此负担 • 性能 • 即使使用缓存，在数据路径中同步调用Mixer也会增加端到端延迟 • 复杂性 • Mixer使用一组称为模板的核心抽象，来描述传递给适配器的数据。 这些包括“metrics”，“logentry”，“tracepan”等。这些抽 象与后端想要消费的数据不匹配，导致运维需要编写一些手动配置， 以便在规范的 Istio 样式和后端特定的样式之间进行映射。原本期望 这种映射可以在适配器中实现很大程度上的自动化，但是最终还是 太复杂并需要手动配置。如果要性能，该怎么做？ complexity. Mixer-In-Proxy/Mixer合并进Proxy。 Mixer 将用C ++重写并直接嵌入到Envoy。 将不再有任何独立的 Mixer 服务。 这将提高性能 并降低运维复杂性。Part 2：ServiceMesh灵魂拷问二：性能有了，架构怎么办？ 性能有了，架构怎么办？ Mixer合并到Sidecar之后Part 2：ServiceMesh灵魂拷问二：性能有了，架构怎么办？

支持蚂蚁LDC架构，三地五中心容灾架构 • 全面上线SSL加速卡，提供软硬件一体加速方案 2015 • All in 无线，通信通道全面升级（MMTP，MTLS协议） 2016 • 安全防护能力提升，WAF，流量镜像 2018至 今 • 通信协议，架构，安全再次升级（物联终端接入，QUIC协议，国密，可信计算， 海外加速，云原生）金融级三地五中心容灾架构（LDC） 单机房 LDC 同城双活 LDC 应用既有业务逻辑， 也有各种功能 业务进程专注于业务逻辑Service Mesh 为什么蚂蚁需要Service Mesh • 拥抱微服务，云原生 • 异构语言体系融合 • 统一服务治理 • 运维体系有利支撑 • 全局流量管理，打通南北，东西 • 金融级网络安全为金融业务而生的SOFAMesh Pod Spring Cloud 应用 SOFAMosn SOFA Mesh 控制面 Galley SOFAMosn Sigma TLS，国密 服务鉴权 流量控制 镜像中心 流量镜像 流量镜像 TLS，国密 服务鉴权 流量控制 TLS，国密 服务鉴权 流量控制蚂蚁金服率先大规模落地SOFAMesh UDPA 安全 统一数据 平面API 存量连接无损迁移 提升5倍发布效率 TLS双向加密 支持国密算法 WAF 流量镜像 多协议 SOFARPC Dubbo HTTP1.1/2 平滑升级

基于容器服务的微服务架构实践163yun.com 一、微服务与Docker、Kubernetes163yun.com 应用架构 数据架构 IT架构 微服务的交付形式Kubernetes 轻量级的IT运维模式Swarm 资源利用率高的任务执行模式Mesos 快速迭代 高并发 OPEX CAPEX 大数据分析，运营 容器技术的三种视角微服务形态 Hailo Amazon Netflix 来源: DevOps工具链网易云容器服务架构www.163yun.com 容器管理平台本身也是微服务 所有的多租户容器请求入口流量 对接多个业务：OpenStack， Kubernetes，所有PaaS，持 续集成，镜像仓库，计费，用 户，认证，…… 高可用，横向扩展 熔断，限流，降级 负载均衡，路由 监控，统计 可靠消息163yun.com

review ，批准合并之后，feature/new_branch 会合并到 develop； • 8. Merge 触发 Jenkins/Drone 自动构建； • 9. 构建成功就执行你定义的工作流：打包镜像，触发 deploy 以及其他后续的 Automation Testing 等流程； • 10 . Drone 通知工作流程情况给开发/或者交付 QA 测试；如何提升工程效率？我是作者名称2017 Mesh）这个术语通常用于描述构成这些应用程序 的微服务网络以及应用之间的交互。随着规模和复杂性的增长，服 务网格越来越难以理解和管理。 • 它的需求包括服务发现、负载均衡、故障恢复、指标收集和监控以 及通常更加复杂的运维需求，例如 A/B 测试、金丝雀发布、限流、 访问控制和端到端认证等。什么是 Istio • Istio 提供一种简单的方式来为已部署的服务建立网络，该网络具有 负载均衡、服务间认证、监控等功能，而不需要对服务的代码做任

微服务结合容器云平台的思考和实践 2018.06.25 徐运元关于我 2008年毕业于浙江大学，曾在思科和浙大网新有超过 9年的工作经验和5年的云计算领域工作经验，带领团 队完成公司第一代基于Kubernetes的云平台开发和第 二代基于Kubernetes的DevOps云平台开发 来自于浙江大学SEL实验室目录 CONTENTS Kubernetes平台下的微服务演进 Pilot核心功能解读 面，是个单独 的二进制。 pilot-agent跟envoy打包在同一个docker镜 像里，镜像由Dockerfile.proxy定义， Makefile（include了tools/istio- docker.mk）把这个dockerfile build成了 ${HUB}/proxy:${TAG}镜像，也就是 Kubernetes里跟应用放在同一个pod下的 sidecar。非Kubernetes情况下需要把 sidecar。非Kubernetes情况下需要把 pilot-agent、envoy跟应用部署在一起，这 就有点“污染”应用的意思了。Pilot-Agent的功能介绍 在proxy镜像中，pilot-agent负责的工作包括： • 生成envoy的配置。 • 启动envoy。 • 监控并管理envoy的运行状况，比如envoy出错时pilot-agent负责重启envoy，或者envoy配置变更后 reload envoy。

用户与Istio的区别 我是作者名称没有对称的server端agent • 性能考虑 • Proxy已经增加了一跳，server再增加一跳会加剧 性能压力 • 部署考虑 • 服务端agent成为必选项会增加运维压力 • OSP server默认没有agent，web server只带一个 服务注册agent • 服务端的一些治理、trace、鉴权功能通过代码插 件的方式实现 • 治理效果考虑 • • Istio的设计很美好，但现实总是很残酷 • IPTable性能不总是足够好 • 任何组件都有不可用的时候。客户端无论如何都要有自切换的能力和可 用的备份 • 尽量减少外部组件依赖。业务/运维总会有各种特殊的需求，依赖外部组 件会给自定义需求带来障碍。 • 保持客户端选择proxy的自由度和灵活性，在我们的实践中好处大 于坏处胖客户端 vs. service mesh vs. cluster 响应（目前还没有生成HTTP sdk） 应用侵入性 侵入性大。复杂客户端会给 应用造成负担，包括资源占 用、依赖冲突等等 侵入性小。SDK只有简单的寻址和序列化/ 反序列化的功能 无侵入性。应用自行调用 运维难度 难度大。客户端的问题会对 应用直接产生影响，耦合太 重 难度小。Sidecar故障可以将流量临时切到 remote proxy解决 难度小。集群通过LVS接入，单 台机故障可以下线 升级难度

Ø拥抱微服务，云原生 • SOFA 5规划落地 • 兼容K8S的智能调度体系 Ø运维体系的有力支撑 • LDC • 弹性伸缩 • 蓝绿/容灾/.. Ø金融级网络安全 • 金融级鉴权体系 • 云原生zero trust网络安全趋势 Ø异构语言体系融合 • SOFA/NodeJS/C++/Python/.. • 业务低成本融入服务，运维体系为什么要自研Golang版本ServiceMesh 2 Ø跨团队协作需要考虑技术栈落地成本 a等多种技术栈 Ø基于蚂蚁SOFA体系的Mesh化思考 ü 无法保证上下游应用同时升级到Mesh模式 ü 基于RPC内容的流量调度 ü 升级窗口有限，方案必须简单高效 Ø运维体系，容器化建设等方面适配 ü 蚂蚁运维架构建立在流量调度的基础上 ü 容器管理平台更替快速进行中 ØGolang 性能，成本评估符合蚂蚁实际需求2 构架SOFAMesh 1SOFAMosn 2SOFAMosn内数据流

服务化 开发运维一体化 弹性 极致性能 高可用 全站上云 安全加固 人工智能 大数据 离线计算 全链路压测 边缘计算 敏捷调度 故障演练人为失误 http://integracon.com/11-leading-causes-downtime/ 45%最佳实践之容器化DevOps 杭州 容器集群 集群 伦敦 Serverless集群 自动安全扫描 镜像签名 全球自动分发 全球自动分发 智能构建 上海 边缘集群 ECS ECI 应用定义 ACR 镜像服务 镜像快照两个数字背后的故事 19分23秒 36%观测与预测全链路监控+高性能如何应对 … 流量增长 3倍嗯，还有用户体验 https://marketersmedia.com/global-user-experience-market- trends-2019-share-website-des