Kubernetes容器应用基于Istio的灰度发布实践 张超盟 @ Huawei Cloud BU 2018.08.25 Service Mesh Meetup #3 深圳站 Agenda • Istio & Kubernetes • Istio & Kubernetes上的灰度发布 An open platform to connect, manage, and secure microservices 服务发现 • 扩缩容 • 运维 • 部署 Kubernetes Istio Istio治理的不只是微服务，只要有访问的服务，都可以被治理。 Istio关键能力 流量管理 负载均衡 动态路由 灰度发布 可观察性 调用链 访问日志 监控 策略执行 限流 ACL 故障注入 服务身份和安全 认证 鉴权 平台支持 Kubernetes CloudFoundry Eureka 集成和定制 Istio构建服务治理能力，将逐渐成为应用微服务转型的标准配置。 Agenda • Istio & Kubernetes • Istio & Kubernetes上的灰度发布 灰度发布：蓝绿 灰度发布：A/B Testing 灰度发布：Canary releases 灰度发布：基于Kubernetes RC Version2 SVC SVC Pod1 Pod2 Pod3 SVC Pod1 Pod2

1 Kubernetes容器应用基于Istio的灰度发布实践 张超盟 @ Huawei Cloud BU 2018.08.25 Service Mesh Meetup #3 深圳站2 Agenda • Istio & Kubernetes • Istio & Kubernetes上的灰度发布3 An open platform to connect, manage, and secure • 扩缩容 • 运维 • 部署 Kubernetes Istio9 Istio治理的不只是微服务，只要有访问的服务，都可以被治理。10 Istio关键能力 流量管理 负载均衡 动态路由 灰度发布 可观察性 调用链 访问日志 监控 策略执行 限流 ACL 故障注入 服务身份和安全 认证 鉴权 平台支持 Kubernetes CloudFoundry Eureka 集成和定制 微服务转型的标准配置。16 Agenda • Istio & Kubernetes • Istio & Kubernetes上的灰度发布17 灰度发布：蓝绿18 灰度发布：A/B Testing19 灰度发布：Canary releases20 灰度发布：基于Kubernetes RC Version2 SVC SVC Pod1 Pod2 Pod3 SVC Pod1

，是⽬前匹配路由速度最快的
API
⽹关。它⽀ 持全路径匹配、前缀匹配，也⽀持使⽤
Nginx
内置变量作为匹配条件，以此实现精细化路由。此 外，API7
⽀持流量镜像与⾼级路由匹配功能，可实现灰度发布等精细化路由管理功能。此外，它 也⽀持服务发现与多种注册中⼼，并有能⼒根据请求中
Header、Query、Cookie
等参数进⾏分 流； • 协议转换：API7
⽀持丰富的协议，如
服务熔断
✔
✔
✔
✔
✅
服务降级
✔
✔
✔
✖
✅
API
熔断
✔
✔
✖
✖
✅
超时
✔
✔
✔
✔
✅
流量管理
灰度发布
✔
✔
✖
✔
❌
蓝绿发布
✔
✔
✖
✔
❌
流量镜像
✔
✖
✖
✔
❌
故障注⼊
✔
✖
✖
✖
❌
启⽤该插件后，在⼀个固定时间窗⼝内，超过预设值的请求 将被拒绝。
limit-req
启⽤该插件后，将使⽤漏桶算法限制请求速率。
traffic-split
该插件允许我们动态控制指向不同上游服务的流量⽐。
灰度
Serv erles s
Serverless
插件在⽹关
access
阶段动态执⾏
Lua
代码，以实现⽆服务环境下执⾏
FaaS
函数。
serverless-post- function

Service Mesh 的 优势 灰度引流 • 服务间调用灰度引流 • 外域调用灰度引流 • 平滑迁移是 Service Mesh 在混合云架构落地的关键17/24 平滑迁移 • 边缘网关支持跨 LDC 访问 • 兜底路由：云内云外互备 • 访问控制（如白名单能力） • 灰度引流使架构透明化 • 服务间调用灰度引流 • 外域调用灰度引流18/24 API 网关 • 整体基于 MCP，一套标准 GRPC 协议）19/24 质量保障体系 • CICD • 单元测试 • 性能基准自动测试 • 监控报警 • 版本升级机制 • Envoy 热更新机制 • 灰度发布机制：业务灰度+流量灰度 • 演练测试 • 业务回归验证20/24 一些坑 • Envoy 目前编译版本存在 Bug • 在 Istio pilot 升级到加入 accesslog 相关配置下发功能版本后，Envoy

mechanism. 简而言之，就是官方对动态化后的性能没有自信，并且对安全性有所顾虑。之前，官 方提供方案的局限性也十分明显。比如对 Native-Flutter 混合 App 支持不友好，并 且无法进行灰度等业务定制操作，所以不能满足通用性和高性能的核心目标。 前端 < 229 b. AOT 搭载 JIT Flutter 在 Release 模式下构建的是 AOT 编译产物，iOS 是 AOT Assembly， 接入了美团内部统一的动态化发布平台 DD，并利用 DD 平台的能力实现了 App 版本、平台类型、UUID、Flutter SDK 版本等细粒度的下发规则管控。业务方 可以根据实际情况选择不同的策略灰度发布方案，如果发生了严重异常，Flap 也支 持撤包操作。 前端 < 245 图 13 Bundle 发布系统的各项边界控制 某一个页面加了标记支持了动态化之后，也会继续进行 AOT 编译过渡 替代方案，Rules 也会定时补充和删减。 提前周知各方资源 包括确认好 Android 的上线节奏，QA 的测试节奏，以及周知 PM 动态化的覆盖 占比。 关键权限收紧管理 相比于整理权限、灰度、降级、容灾等线上的 SOP 和 FAQ，让大家都学着操作， 直 接指定 2~3 位超级管理员看上去更靠谱，线上环境由“老司机”把控更好。 5.3 落地结果 业务应用涵盖 App 一级页在内的

服务契约管理 • 服务测试 • 服务Mock • 开发环境隔离 • 端云互联 运行态Ops 开发态Dev • 无损下线 • 无损上线 • 金丝雀发布 • A/B Test • 全链路灰度 安全态Sec 发布态 • 离群实例摘除 • 限流降级 • 同AZ优先路由 • 就近容灾路由 高可用 • 服务鉴权 • 漏洞防护 服务治理的区分 服务治理中心 提供者 消费者 5 应用重启 4 调用其他提供者 Agent 2 主动通知 Agent 3 客户端主动刷新 Agent Agent 无损下线: 白天大流量下发布依然丝般顺滑 场景一：某应用发布，灰度几台机器，由于代码逻辑写的有问题，造成线程池满，客户端调用失败。 场景二：某应用运行过程中，某几台机器由于磁盘满，或者是宿主机资源争抢导致load很高，客户端出现调用超时。 客户端摘除 • 实时性高 标签路由 可灰度 可监控 可回滚 变更管控 安全变更三板斧 故障应急 发布封网 故障复盘 紧急发布 稳定性分 安全 变更 GitOps 持续集 成 自动化 回归 性能压 测 灰度发 布 监控对 比 发布/ 回滚 1分钟发现 5分钟定位 10分钟恢复 故障应急 1-5-10原则 安全变更 4. 读取灰度规则 配置中心 3. 配置灰度规则 http-header:

 服务管理：实现服务 CRUD，域名 CRUD，服务健康状态检查，服务权重管理等功能。  配置管理：实现配置管 CRUD，版本管理，灰度管理，监听管理，推送轨迹，聚合数据等功能。  元数据管理：提供元数据 CURD 和打标能力，为实现上层流量和服务灰度非常关键。 19 > Nacos 架构 内核层  插件机制：实现三个模块可分可合能力，实现扩展点 SPI 机制，用于扩展自己公司定制。 定性，也提高了维护的成本。 那么如何能够做到服务不重启就可以修改配置？所有就产生了四个基础诉求：  需要支持动态修改配置  需要动态变更有多实时  变更快了之后如何管控控制变更风险，如灰度、回滚等  敏感配置如何做安全配置 Nacos 架构 < 22 概念介绍 配置(Configuration) 在系统开发过程中通常会将⼀些需要变更的参数、变量等从代码中分离出来独立管理，以独立的配 者运维人员完成这 个步骤。配置变更是调整系统运行时的行为的有效手段之⼀。 配置管理 (Configuration Management) 在 Nacos 中，系统中所有配置的存储、编辑、删除、灰度管理、历史版本管理、变更审计等所有 与配置相关的活动统称为配置管理。 配置服务 (Configuration Service) 在服务或者应用运行过程中，提供动态配置或者元数据以及配置管理的服务提供者。

与 Citadel Agent 采用基于UDS 通信的Grpc服务获取密钥等敏感信息Service Mesh Sidecar 的TLS 生产级落地实践 TLS 实践难点 证书管理 开关切换 灰度控制 SDS 证书管理方案 ISTIO Policy | Mesh Policy ScopeConfigService Mesh Sidecar 的TLS 生产级落地实践 开关切换 RPC Mesh Sidecar 的TLS 生产级落地实践Service Mesh Sidecar 的TLS 生产级落地实践 灰度控制 新功能总是离不开灰度过程，社区已有的Policy CRD 实现 Namespace + Service 的灰度能力不能满足 蚂蚁金服生产落地的要求，需要具备单机灰度、回滚能力。 借鉴社区 SourceLabel 和 Sidecar CRD 的设计思路，创造性提出具备“正交”组合能力的ScopeConfig ScopeConfig 通过 Pod IP 这个label 实现单实例开关控制， 在观察正常后，逐步调整ScopeConfig 的Selector 范围，实现功能的灰度上线能力Service Mesh Sidecar 的TLS 生产级落地实践 灰度控制关注 ServiceMesher 微信公众号 获取社区最新信息 关注 金融级分布式架构 微信公众号 获取 SOFAStack 最新信息 ServiceMesher

腾讯大数据云 通用云平台 目录 • 架构简介 • 企业级容器云解决方案 • Next 企业级容器云架构 产品功能 企业级容器云解决方案 企业级 场景 易用 • 全组件自动化部署、统一配置管理、多策略灰度升级 • 提供可视化、自动化的运维能力，降低使用者的人力成本和学习成本 可靠 • 所有组件无单点； • 平台本身支持热升级； • 组件自身HA机制，如docker； • 多地域多可用区的容灾设计 annotation.io.kubernetes.container.restartCoun • Cgroup目录结构发生变化，新增Pod层级 平台容灾 应用容灾 数据容灾 企业内部各个集群灰度运营。 可靠 资源管 理 CPU Memory Disk Space Network TX Network RX Disk IO (include buffer IO) cluster-agent Cloud API 集群弹性伸缩： • 监控节点资源使用率 • 自动迁移低负载Node上的Pod，完成缩容 • 一定数量Pod因资源不足pending时，自动扩容 能力扩展：灰度升级 • 在GPU集群中有一个长时间服务应用prd-cloud-str-003-p40- cluster1。该应用有25个实例，每个实例需要2个GPU卡。用 来提供图片识别的OCR服务。 •

用户没有学习成本 响应速度响应快 能够快速裂变分享 打通社交媒体 触达海量用户 小程序成为互联网巨头争夺的流量入口是因为？ #移动应用如何利用小程序转型升级# 组合 索引 推荐 灰度 拆分 分享 应用场景小程序化 “上下架” 打破传统APP 信息孤岛 重组 自营APP 业务功能独立 拆分成小程序 第三方 终端应用 移动应用演进趋势 — APP 乐高化，化整为零，可合可分 支持对APP内所有小程序进行快速索引，用户无需苦苦寻找功能 入口 • 小程序支持多版本灰度发布，支持A/B测试，充分释放运营创 新活力 • 支持小程序的精准投放，不同用户得到不同的小程序 功能生态更全：兼容微信，快速引入 距离用户更近：分享裂变，快速索引 需求响应更快：松散耦合，敏捷迭代 服务提供更准：灰度发布，千人千面 小程序让APP“组件化”，外部生态引进来，公司业务走出去 兼容微信，助力银行快速构建数字生态 的APP发版周期所困扰，今天创意、明天上线。 1.0版本 2.0版本 版本级别的精准投放 千人千面+灰度发布 • 小程序可根据用户画像进行精准投放，超越传 统的A/B测试。 • 支持城市、性别、年龄... 支持根据用户画像创 建发布；支持机型、网络、版本号... 支持根据 设备特征创建发布； • 各种发布规则灵活组合，不仅能实现传统意义 上的灰度覆盖发布，更能实现灵活、多样的业 务发布目标 1. 设备信息 2