Istio在UAEK中的实践改造之路

为什么需要ServiceMesh

UCloud App Engine on Kubernetes(后简称“UAEK”)是UCloud内部打造的一个基于Kubernetes的，具备高可用、跨机房容灾、自动伸缩、立体监控、日志搜集和简便运维等特性计算资源交付平台，旨在利用容器技术提高内部研发运维效率，让开发能将更多的精力投入在业务研发本身，同时，让运维能更从容应对资源伸缩、灰度发布、版本更迭、监控告警等日常工作。

考虑到Kubernetes本来就是为自动部署、伸缩和容器化而生，再加上UCloud UAEK团队完成IPv6组网调研和设计实现后，一个成熟的容器管理平台很快正式在北京二地域的多个可用区上线了。相比于过去申请管理虚拟机部署应用服务，Kubernetes确实带来了实实在在的便利，例如方便灵活的自动伸缩以及触手可及的微服务架构，只需简单配置即可实现跨可用区容灾等。

然而，微服务化又为系统架构带来许多新的问题，例如服务发现、监控、灰度控制、过载保护、请求调用追踪等。大家已经习惯自行运维一组Zookeeper集群用以实现服务发现和客户端负载均衡，使用UAEK后能否免去运维Zookeeper的工作?为了监控业务运行状态，大家都需要在代码里加上旁路上报逻辑，使用UAEK是否能无侵入零耦合地实现监控上报?

此外，过去很多系统模块间调用缺少熔断保护策略，波峰流量一打就瘫，使用UAEK是否能帮助业务方免去大规模改造呢?过去排查问题，尤其是调用耗时环节排查总是费时费力，使用UAEK能否为定位瓶颈提供方便的工具?

显然，仅凭一个稳定的Kubernetes平台不足以解决这些问题。因此，在UAEK立项之初，团队就把ServiceMesh作为一个必须实现的目标，任何在UAEK上部署的TCP后台服务，都能享受到ServiceMesh带来的这些特性：

• SideCar模式部署，零侵入，微服务治理代码与业务代码完全解耦;
• 与Kubernetes平台融合的服务发现机制和负载均衡调度;
• 提供灵活，实时，无需重启、能根据7层业务信息进行流量灰度管理功能;
• 提供统一抽象数据上报API层，用于实现监控和访问策略控制;
• 使用分布式请求链路追踪系统，快速追溯Bug，定位系统性能瓶颈;
• 过载保护机制，能在请求量超过系统设计容量时自动触发熔断;
• 能在服务上线前提供故障模拟注入演习剧本，提前进行故障处理演练;
• 这样，使用UAEK部署应用服务后，即可从小范围按账号灰度上线开始，通过陆续地监控观察，轻松掌握版本异常回退、扩大灰度范围、全量发布、过载保护、异常请求定位追踪等信息。

为什么是Istio?

关于ServiceMesh的实现，我们重点考察了Istio。通过前期的调研和测试，我们发现Istio的几个特性能很好满足UAEK的需求：

• 完美支持Kubernetes平台;
• 控制面和数据转发面分离;
• Sidecar部署，掌控所有服务间调用流量，无上限的控制力;
• 使用Envoy作为Sidecar实现，Envoy使用C++11开发，基于事件驱动和多线程机制运行，性能好并发能力强，媲美NGINX;
• 对业务的代码和配置文件零侵入;
• 配置简单，操作方便，API完善。

整个服务网格分成控制面板和数据面两大部分。数据面指的就是注入到应用Pod中的Envoy容器，它负责代理调度模块间的所有流量。控制面分为Pilot，Mixer和Citadel三大模块，具体功能如下：

• Pilot负责向Kubernetes API获取并Watch整个集群的服务发现信息，并向Envoy下发集群服务发现信息和用户定制的路由规则策略。
• Mixer分为Policy和Telemetry两个子模块。Policy用于向Envoy提供准入策略控制，黑白名单控制，QPS流速控制服务;Telemetry为Envoy提供了数据上报和日志搜集服务，以用于监控告警和日志查询。
• Citadel为服务和用户提供认证和鉴权、管理凭据和 RBAC。
• 此外Istio为运维人员提供了一个叫istioctl的命令行工具，类似kubernetes的kubectl。运维编写好路由规则yaml文件后，使用istioctl即可向集群提交路由规则。

Istio整体工作的原理和流程细节非常复杂，所涉及到的技术栈有一定的深度和广度。这里只概括一下大体过程：

• 运维人员使用istioctl或者调用API向控制层创建修改路由规则策略。
• Pilot向Kube APIServer获取并watch集群服务发现信息。
• 部署应用程序时，Istio会在pod的部署配置中注入Envoy容器，Envoy会通过iptables nat redirect劫持代理pod中的全部TCP流量。
• Envoy会实时从Pilot更新集群的服务发现信息和路由规则策略，并根据这些信息智能调度集群内的流量。
• Envoy会在每次请求发送前向Mixer Policy发送Check请求检查该请求是否收策略限制或者配额限制，每次请求接收后会向Mixer Telemetry上报本次请求的基本信息，如调用是否成功、返回状态码、耗时数据。
• Citadel实现了双向TLS客户端证书生成与注入，服务端密钥和证书的下发注入，以及K8S RBAC访问控制。

Istio在UAEK环境下的改造之路

经过上述的调研和与一系列测试，UAEK团队充分认可Istio的设计理念和潜在价值，希望通过利用Istio丰富强大的微服务治理功能吸引更多的内部团队将服务迁移到UAEK环境中。

然而，事实上，在UAEK上接入Istio的过程并非一帆风顺。最早开始调研Istio的时候，Istio还在0.6版本，功能并不完善，在UAEK环境中无法开箱即用。

IPv6问题的解决

我们首先碰到的问题是，UAEK是一个纯IPv6网络环境，而Istio对IPv6流量的支持并不完备，部分组件甚至无法在IPv6环境下部署。

在介绍具体改造案例之前，先了解下Istio Sidecar是如何接管业务程序的流量。

如上图所描述，Istio会向应用Pod注入两个容器：proxy-init容器和envoy容器。proxy-init容器通过初始化iptables设置，将所有的TCP层流量通过nat redirect重定向到Envoy监听的15001端口。以入流量为例，Envoy的服务端口接收到被重定向到来的TCP连接后，通过getsocketopt(2)系统调用，使用SO_ORIGINAL_DST参数找到该TCP连接的真实目的地IP地址，并将该请求转发到真实目的IP。

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!