容器服务 ACK 结合 MSE Ingress，让集群入口流量管理更丰富、更容易

作者：扬少

随着云原生技术不断普及，越来越多的业务应用开始向云原生架构转变，借助容器管理平台 Kubernetes 的不可变基础设施、弹性扩缩容和高扩展性，助力业务迅速完成数字化转型。其中，集群入口流量管理方式在云原生技术演进过程中逐步通用化、标准化，用户通过 Kubernetes 定义的 Ingress 资源来管理外部访问集群内部服务的方式。入口网关的标准化制定将入口流量管理与网关的实现解耦，不仅促进了各种 Ingress Controller 的发展，而且消除了开发者存在的与厂商绑定的顾虑，日后也可以根据自身业务实际场景切换到不同 Ingress Controller。

阿里云容器服务 Kubernetes 版（简称容器服务 ACK）提供高性能的容器化应用管理服务，让用户轻松高效地在云端运行 Kubernetes 容器化应用。MSE Ingress 是在 MSE 云原生网关之上提供更为强大的 Ingress 流量管理方式，兼容 Nginx Ingress 50 多个Nginx Ingress 的注解，覆盖 90%以上的 Nginx Ingress 业务使用场景，支持多服务版本同时灰度发布、灵活的服务治理能力以及全方位的安全防护保障，能够满足大规模云原生分布式应用的流量治理诉求。本文主要介绍如何利用容器服务 ACK 和 MSE Ingress，让集群入口流量管理更丰富、更容易。

如何更好的灰度发布

业务的发展需要应用系统不断的迭代，我们无法避免应用频繁变更发版，但是我们可以提升应用升级过程中的稳定性和高可用。比较通用的做法是采用灰度发布，俗称金丝雀发布。金丝雀发布的思想则是将少量的请求引流到新版本上，因此部署新版本服务只需极小数的机器。验证新版本符合预期后，逐步调整流量，使得流量慢慢从老版本迁移至新版本，期间可以根据当前流量在新老版本上的分布，对新版本服务进行扩容，同时对老版本服务进行缩容，使得底层资源得到最大化利用。

用户借助 MSE Ingress 可以实现服务多个灰度版本共存，方便服务多个特性功能同时开发并且独立灰度验证。MSE Ingress 支持多种灰度流量识别方式，基于 HTTP Header、基于 Cookie 和基于权重的方式，用户可以按需针对路由级别实施灰度匹配策略。

此外，MSE Ingress 针对服务的灰度版本默认提供了Fallback能力，当服务灰度版本不存在或者不可用时，流量会自动容灾到服务正式版本，在一定程度上保障了业务应用的高可用。用户仍然可以通过 MSE Ingress 提供的 default-backend 的注解来明确控制容灾服务的方向。

在这里插入图片描述

如何构建端到端的全链路灰度

对于分布式架构的微服务应用而言，服务之间的依赖关系错综复杂，一个业务功能需要多个微服务共同提供能力，一次业务请求需要经过多个微服务才能完成处理，牵一发而动全身。

在这种场景下，业务新功能发布可能同时涉及到多个服务发布，对新功能验证时就涉及到了对多个服务同时灰度的问题，通过构建从网关到整个后端服务的环境隔离来对多个不同版本的服务进行灰度验证，这就是微服务架构中特有的全链路灰度场景。

目前，全链路灰度的解决方案包括基于物理环境隔离和基于逻辑环境隔离。基于物理环境隔离的做法是通过增加机器的方式来搭建真正意义上的流量隔离，该方式存在一定的人力成本和机器成本，所以业界比较常用的做法是更灵活的基于逻辑环境管理。该方式虽然看起来是服务正式版本和灰度版本都部署在一个环境中，但是通过灰度路由匹配策略，可以精确控制灰度流量优先流经服务对应的灰度版本，只有当目标服务不存在灰度版本时，才会容灾到服务正式版本。从总体视角上看，针对新功能的灰度验证流量只会流经涉及到待发版服务的灰度版本，对于本次新功能未涉及到改动的服务，灰度流量正常通过，这种精准化的流量控制方式大大方便了开发者在微服务架构中多版本并行开发和验证的痛点，同时也降低了搭建测试环境的机器成本。

容器服务 ACK 用户，可以搭配使用MSE微服务治理和 MSE Ingress，在不改任何一行代码的情况下，轻松快速上手全链路灰度能力，通过这种精细化的流量控制能力在用户在微服务架构治理过程中得心应手。

在这里插入图片描述

具体实践例子，可以参阅该文档：配置基于 MSE Ingress 的全链路灰度

https://help.aliyun.com/document_detail/460375.html

如何打造全方位的安全防护

安全问题始终是业务应用的头号公敌，伴随着业务发展的整个生命周期。此外，外部互联网的环境越来越复杂，内部业务架构日益庞大，部署结构涉及公有云、私有云以及混合云多种形态，安全问题愈演愈烈。

作为入口网关的 MSE Ingress，从一开始就在安全领域进行了积极探索和增强，打造了全方面的安全防护。主要体现在以下几个方面：

加密通信以及 TLS 硬件加速：业务通信数据通常来说都是私有的、敏感的，TLS作为最基本、最广泛的防窃听、防篡改的协议经常和 HTTP 协议结合使用，就是大家熟知的 HTTPS 协议。MSE Ingress 构建了从客户端到网关、网关到后端服务整个体系的 HTTPS 协议支持，并且结合阿里云第七代 ECS 率先完成了 TLS 硬件加速，在不增加用户资源成本的同时大幅度提升 HTTPS 的性能。针对特殊业务场景下对 TLS 协议版本以及 TLS 加密条件的合规性要求，MSE Ingress 额外支持了域名级别的 TLS 版本控制以及加密套件选择。
细粒度的 WAF 防护：在功能上，MSE Ingress 不仅支持全局 WAF 防护，而且提供了细粒度的路由级别的 WAF 防护；在架构上，MSE Ingress 采用内置 WAF Agent 的方式，相比传统 WAF 用户请求链路更短、RT 更低。
细粒度的 IP 访问控制：MSE Ingress 支持实例级别、域名级别以及路由级别的 IP 黑白名单，优先级逐步增加。用户可以在实例级别配置应用范围更广的 IP 访问控制，然后在路由级别配置与业务相关的IP访问控制，满足用户多样化的访问控制策略。
多样化的认证鉴权体系：在微服务的架构中，会有多个服务接收来自外部用户（客户端）的请求，通常不会直接将服务暴露给外部用户，而是在中间加一层网关作为外部用户访问内部服务的控制点。对于外部用户访问的请求，我们通常希望在网关中进行身份验证，知道用户是谁，并能定义访问控制策略。目前，MSE Ingress 支持 Basic Auth、JWT Auth、OIDC、阿里云 IDaaS 服务以及自定义外部认证鉴权，助力业务以无侵入的方式轻松实现高阶访问控制。

在这里插入图片描述

如何建设全方位的可观测体系

可观测性并不是一个新词，该词来源于控制理论，是指系统可以由其外部输出推断其内部状态的程度，随着 IT 行业几十年的发展，IT 系统的监控，告警，问题排查等领域的逐渐成熟，IT 行业也将其抽象形成了一整套可观测性工程体系。而之所以该词在这几年愈发火热，很大程度是因为云原生，微服务模式，devops 等技术的不断流行，对可观测性提出了更大的挑战。

网关作为业务流量的入口，其可观测性建设与整体业务的稳定性息息相关，同时由于网关的用户使用场景与功能较多，且网络环境也较为复杂，这对网关可观测性建设也带来了很多的难点，主要如下：