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 Pod2

Co., Ltd. All rights reserved. Page 2 个人介绍 张伟 华为云容器网格数据面技术专家 拥有10年以上中间件及高性能系统开发经验， 作为架构师及核心开发人员发布过传输网管系 统、Tuxedo交易中间件、ts-server多媒体转码服 务、GTS高性能事务云服务、SC高性能注册中心、 ASM数据面等多个产品。先后就职于亿阳信通、 北电、甲骨文、polycom、阿里巴巴等公司；目 rights reserved. Page 3 目录 1. Envoy启动及配置文件 2. Envoy流量拦截原理、常用部署方式 3. Envoy可扩展过滤器架构、可观测性 4. Envoy线程模型 5. 生产环境问题分析及解决方法 6. 针对Envoy做的一些优化及效果 7. 常用性能分析测试工具及使用方法 8. 华为ASM产品介绍 Copyright © Huawei Technologies 载均衡、熔断等能力前所未有的诉求。 • 第一阶段为dubbo、SpringCloud侵入式开发框架，语言强相关。 • 非侵入服务网格最早为2016年Linkerd。 • 2017年，Goole、IBM、Lyft发布Istio。Istio目前为服务网格的事实标准，并且是2019年Github增长最快的TOP 10开源 项目之一。目前最新为1.10版本。 Copyright © Huawei Technologies

实现的七层通信相关功能抽象 出来，使用一个专用层次来实现，Service Mesh 对应用透明，因此应用 可以无需关注分布式架构带来的通信相关问题，而专注于其业务价值。 流量控制：服务发现、请求路由、负载均衡、灰度发布、错误重试、 断路器、故障注入 可观察性：遥测数据、调用跟踪、服务拓扑 通信安全： 服务身份认证、访问鉴权、通信加密 Proxy Application Layer Service 1 Istio MCP Adapter https://github.com/istio-ecosystem/consul-mcp 欢迎大家试用、共建！ 4 Istio 流量管理 – 控制面 – 流量管理模型 Gateway Virtual Service Destination Rule 外部请求 内部客户端 Service2 Service1 网格内部 定义网格入口 • 服务端口 • Host • TLS 对外请求 对外请求（Passthrough/ServiceEntry） 缺省路由 （服务名） 5 Istio 流量管理 – 数据面 – Envoy配置模型和xDS协议 ADS Server LDS RDS CDS EDS Envoy 配置模型的主要概念： • Downstream：连接到 Envoy 的下游 Host，发送请求并接收响应。 • Upstream： 上游 Host 接收来自 Envoy

Protocol）提供了一套用于订阅、推送的 API。 分为 Source 和 Sink： • Source 是资源提供方（server），资源变化了推送给订阅者（Pilot），Istio 1.5 之前这个 角色就是 Galley 或者自定义 MCP Server； • Sink 资源的订阅者（client），在 Istio1.5 之前这个角色就是 Pilot 和 Mixer，都是订阅 Galley 或者自定义

模拟接口延迟响应 ü 使用hey压力工具 ü 相同压力 ü 先用hey进行预热 ü 从10份数据中取中位数解决方案 ü方案一 • 业务性能和日志之间的选择，出现阻塞，丢弃日志保性能 ü方案二 • 使用主题订阅模式，减少阻塞问题Istio_Ca——安全证书管理（ICA） u证书生成 u证书挂载 u证书过期证书生成 ü生成root-cert.pem ü生成cert-chain.pem ü生成key.pem证书挂载

• 在服务间通信之间进行加密 • 访问控制和频率限制 • …Istio目前的突出问题 • API稳定性问题：流量管理也仅仅是v1alpha3，用alpha特性发布 1.0的情况似乎比较罕见。 • 发布进度和质量：大版本以月计算的发布延迟，据我所知的 Release撤回发生了两次。 • 世纪难题：多出一层Sidecar造成的延迟。 • Pilot的性能，近几个版本一直在出问题。 • Mix

微服务化带来的问题 错综复杂的服务调度掩盖了 问题的源头 服务间交互的复杂性： Ø 难以可视化 Ø 难以全面测试 Ø 多服务联动时问题难以察觉 Ø ... 服务间通信的复杂性： Ø 网络延迟 Ø 消息序列化 Ø 不可靠的网络 Ø 异步机制 Ø ... 开发难 排错难 测试难 运维难 Ø 服务变得非常多 Ø 版本变得非常复杂 Ø 上线十分痛苦 Ø 排查问题更难 Ø 解决手段更复杂

语言和技术栈的自由 • 中间件升级和切换的自由 • 不被供应商绑定的自由11/25 兼容新旧服务体系 Istio 的价值和问题12/25 兼容新旧调用链体系 Istio 的价值和问题13/25 灰度发布 Istio 的价值和问题14/25 性能损耗 Istio 的价值和问题 每 pod 多占用内存 20 MB -8 毫秒 测试 API 平均响应时 间变化量 吞吐量提升 5 %15/25 RevisionUnkown 状态(0.8版本) • Queue-proxy 内存增长(0.8版本) • Activator 重复创建并占用大量资源22/25 Knative 当前瓶颈 FAAS 实践进展 • 还未发布 Production-ready 版本 • Queue-proxy 过重 • 冷启动时间亟待优化 • 支持代码级更新？23/25 展望-推动组织变革 FAAS 实践进展24/25 总结

○ 数据面：MetaProtocol Proxy 实现 RDS、负载均衡、熔 断等公共的基础能力 ○ 控制面：Aeraki + Istio 提供控制面管理，实现按请求 header 路由、灰度发布、地域感知LB、流量镜像等高级 流量管理能力。 ● 基于 MetaProtocol 框架扩展开发，只需要实现 encode、 decode 的少量接口即可在 Istio 中支持一个新的七层协议