开发者学堂课程【玩转容器服务进阶课程：如何在 ACK 中使用 MSE Ingress】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1079/detail/15852
如何在 ACK 中使用 MSE Ingress
三、 MSE Ingress 实践
现在更多的介绍的是 MSE Ingress 的一个优势，剩下的知道优势之后可能体感不够，那接下来就通过Nacos Ingress 的一个实践进行讲解，也就是讲解 MSE Ingress更有体感的一些案例，包括最佳实践的一个案例和用户的案例，而且最后会通过一个 demo 给予一个更好的体感。
1. MAE Ingress 最佳实践（统一东西南北流量）
首先介绍一个最佳实践的一个案例，推荐的模式也就是标题最佳实践就是统一东西南北流量。那北向网关就是用户的两个 VPC ，比如说可能是两个业务域，也可能是两个不同的 region ，那北向网关进来通过云原生网关，东西向对跨域也需要云原生网关，那就采用一个内核，然后统一的去做，这样的话对于整个运维人员，包括操作的开发人员都是非常简单的。
那就讲解一下云原生网关在统一东西南北流量的时候有什么好处。第一个就是在北向统一接入一个网关，把所有的北向的入口网关全部统一，那就对北向有两个非常大的优势，
第一个是从云原生网关和 Ingress 的入口角度上来说是安全的防线，现在已经把安全的产品和能力全部集成，支持多重的一个防御能力；
第二个就是支持了微服务网关的一个整合能力，因此可以在入口建立一个高可用的一个防线，并且和微服务的全链路灰度的一些高可用的能力打通，提升整个系统的高可用能力，这是对上建立了整个安全的和高可用的一个防线，对下又支持单体应用， Nacos 的微服务的应用、服务网格的应用和 solace 多种服务发现模式，也就是说流量进来统一防线之后，后面不论是什么负担都可以把他路由下去，这就是第二个推荐优势即统一接入；
第三个就是跨域互通也就是东西向网关，东西向网关在 Ingress 是一个入口和一个出口的意思，为什么现在有这种跨域互通，经常有一些公司也会直接把两个 VPC 拉通业务，直接互调，这样整个带来的问题就是网络断网之后的风险是不可控的，且 RT也是不可控的，因此跨域之间是建议通过网关互动，这是在阿里积累下来的一个经验。
那么东西向网关跨域互通有哪些场景，比如两个不同的安全域，比如阿里的蚂蚁的金融域和电商域是不同的域，所以他们安全就是不一样的；包括阿里上云的过程中，比如钉钉上云中的云上、云下以及云边，他们网络默认都是不通的，在上云的过程中，一部分上云一部分不上云，那云上云下的互动，包括不同的协议，这边可能是一种协议，这边可能是另一种协议，这边可能是 HTTP 到 HTTP ，这边可能是 HTTP 到 Dubbo ，他可以通过网关做一些转化，因此在东西向也通过 MSE Ingress ，那原生网关实际上是东西的一个流量互通，因为整个内核是采用 Envoy 去做的，所以在社区里是标准的可以控制东西南北的流量，一站式的一个解决方案，无论是出口北向的公网到内网的多个安全域，多个业务域之间的全部统一的网关解决方案，这就是推荐的最佳姿势。
2. MSE Ingress 平滑迁移最佳实践方案
那怎么从之前传统的网关模式迁到云原生网关的模式，这里给了两个方案。
（1）方案一
第一个就是如果用户有 DNS 的，比如有域名的，那就从域名上去迁。首先就是从能力上，因为MSE Ingress 云原生网关已经兼容了 Nginx 的一些注解的情况，因此从服务发现上，只要把网关一创建默认就会冒迟到对应的 K8S 的资源，这样就是从路由上，因为都是同样的路由且都是通过 Ingress 去定义的，因此服务发现和路由规则自动就已经和左边的传统的网关一样了，建完云原生网关和做好路由之后，下一步只需要从域名上按照不同的权重，把这个SLB即传统的流量网关的 Ingress 的 SLB 切到云原生网关的 SLB 上，那这样就是比较平稳的一种模式，按照域名去迁。
（2）方案二
当然还有很多公司不用 DNS ，因为 DNS 的解析以及缓存问题，很多公司不好解决，他们做了一个模式就是直接把 SLB 写死，中小公司有一些是这么干的，他直接把这个 SLB 直接暴露出去，这种模式对下边其实是一样的，可以监听兼容所有的 K8S 的路由的资源，那这样只需要用户在自己的SLB 上把云原生网关的 IP 挂到SLB下面去，这样就可以按照SLB 的权重一步一步的把流量迁到云原生网关，如果有问题马上回滚，这样的话可以最大限度的控制整个爆炸半径，当出问题的时候，也可以用最快的速度进行回滚，这就是一个优势。
2. MSE Ingress 平滑迁移最佳实践方案
那怎么从之前传统的网关模式迁到云原生网关的模式，这里给了两个方案。
（1）方案一
第一个就是如果用户有 DNS 的，比如有域名的，那就从域名上去迁。首先就是从能力上，因为MSE Ingress 云原生网关已经兼容了 Nginx 的一些注解的情况，因此从服务发现上，只要把网关一创建默认就会冒迟到对应的 K8S 的资源，这样就是从路由上，因为都是同样的路由且都是通过 Ingress 去定义的，因此服务发现和路由规则自动就已经和左边的传统的网关一样了，建完云原生网关和做好路由之后，下一步只需要从域名上按照不同的权重，把这个SLB即传统的流量网关的 Ingress 的 SLB 切到云原生网关的 SLB 上，那这样就是比较平稳的一种模式，按照域名去迁。
（2）方案二
当然还有很多公司不用 DNS ，因为 DNS 的解析以及缓存问题，很多公司不好解决，他们做了一个模式就是直接把 SLB 写死，中小公司有一些是这么干的，他直接把这个 SLB 直接暴露出去，这种模式对下边其实是一样的，可以监听兼容所有的 K8S 的路由的资源，那这样只需要用户在自己的SLB 上把云原生网关的 IP 挂到SLB下面去，这样就可以按照SLB 的权重一步一步的把流量迁到云原生网关，如果有问题马上回滚，这样的话可以最大限度的控制整个爆炸半径，当出问题的时候，也可以用最快的速度进行回滚，这就是一个优势。
3. MSE Ingress 上海费睿最佳实践
解决了最后的一个平滑迁移的问题，那有没有一些标杆客户，当然是有的——上海费睿。上面是费瑞最早在金融领域的一个架构，他采用的是自建的 Nginx Ingress ，他的数据面和控制面全是在一个 Pod 里。这样，他在当时就有几个问题。
第一个就是他当时没有专门的网关运维人员但是他网关还是非常专业的，他设计安全、微服务以及开发是一个非常焦急的地方，他们这块的整个运维经验是不足的，他们开发不住。
第二个事情就是他们在整个采用了 Nginx Ingress 的实践过程中，遇到了一些安全和稳定性的问题，也可以去翻一下社区的资料，因为控制面和数据面在一起会带来稳定性的问题和安全问题，包括压力大的时候，这个控制面 Nginx Ingress Controller 会影响 Nginx 的一些稳定性。
然后第三个其实是他往后端去转的时候，不支持 TLS 的一些版本设置，这对应的最前线的一些黑白名单的一个机制，这是费芮为什么要从自建的Ingress 迁到云原生网关，他是需要云原生网关这些能力的。
下边就是他迁移到云原生网关的一个架构，前移到云原生网关，右边的最下边可以看到是没有任何变化的，而变化的其实是左边，左边 Nginx Ingress 迁移到了云原生网关，迁移到原生网关之后就可以看到他的整个数据面和控制面是完全独立的，这样，整个安全和稳定性就会得到更好的一个保障，也满足了他的这个黑白名单和TLS 版本设置的一些需求；然后切流上，他们是采用入口 DNS 去切流的，从他的 DNS 把流量就切到了云原生网关，后边所有的路由都是不变的。相信上海费芮上了原生网关之后，也会持续的释放红利。
4. MSE Ingress DEMO 准备
最后介绍一个用云原生网关 MSE Ingress 的一个案例即一个 demo 。首先就是做这个 demo 大概需要三个准备，第一个准备就是让 ACK 有访问创建云原生网关的一个权限；第二步就是在 ACK 的应用目录创建MSE Ingress Controller；第三个是通过自定义资源创建，通过 Controller 识别这个资源，创建一个网关，这就是这个三个步骤。
5. MSE Ingress DEMO 灰度发布
需要这三个步骤先把网关创建出来，然后下面就是显示了网关创建出来之后，后面会有一个应用。这个应用会有三个版本，就是 V1版本、 V2版本、 V3版本。那在测试的过程中，很多的用户都会发一个版本上去并通过不同的 UID 或者不同的参数录入到测试的机器，这样可以控制爆炸半径，这个是目前实现的比较多的一个场景。因此这一步就需要去部署整个测试的样例，就是对应配置Ingress 的资源。这就是要演示的样例，而且这个样例在云起已经有一个案例了，可以去下载点击，目前已经在制作中。
6. DEMO 演示
然后先进行第一步准备工作，先做授权的一些相关的事情。首先到 ACK 的一个集群里，首先比如举个例子，就是要 demo 的 ACK 的实例。
然后点击进去，进去之后到集群的资源管理里先做授权，可以看到这个权限就相当于是让整个 ACK 有创建网关的权限，因为买任何产品或者是开通任何产品都是需要一个权限的，这就是有一个创建权限。
第二步就是有了权限之后，就进入了整个 ACK 的应用市场，在微服务栏目下面有一个 ACK MSE Ingress Controller ，可以看到只要满足1.14版本都可以用这个能力，可以认为就是说目前所有的AK用户都可以使用。第二个就是授权，这个授权的话首先版本要求已经满足了，其次就是授权，刚才已经提前做了授权，目前授权上支持两种模式，一个是ramorte 的模式，一个是 ACK 、KSK 的模式，那演示默认的是 ACK 两种模式都支持，那就用 ramorte 的模式去做。
然后非常简单只需要一键点击部署并选择要 demo 的 K8S 集群，因为网关是需要关联一下对应的 K8S 集群的。
关联完了之后，可以看到这里配置的参数就非常简单，可能都不需要做太多的一些细致的部署，这里边就是 Controller需要的一些资源，这里给了一个最小的资源，授权的模式里边选的是 ramorte
但如果要用 AKSK 模式也可以改一下，按照左边的文档可以去操作。然后最下边，如果要采用 AK 、SK ，那就要填一下，这里边是一个安全的一个 SLV 的保障策略，那么确认没问题就可以点击确认了，因为已经创建好了就不创建了，如果重复创建其实也不会有问题的，他会提示这个已经 ready 了。创完网关的 Controller 之后，那下一步其实就是到整个集群里边去创建整个网关即真正创建网关。上面这个操作只是创建了网关的Controller ，那需要在这里边创建一个 MSE 的一个自定义资源，然后去创建。
通过自定义的资源，只要通过配置的模式，一下子就可以把网关创建出来，这里边已经创建了是这个效果，现在就简单的演示一下，就把刚才 Controller 里边有一个小的 config 的一个代码样目片段，只要按照这个一创建，最后就可以看到这里边的整个资源全部有了。那什么时候，比如是创建网关，那网关到底创建有没有成功。就点击浏览对象，可以看到这个准备状态是 listener 状态的时候，说明云原生网关已经就绪了，因为时间关系，就不一步步给点开了。
在这个基础之上创建成功了也可以在 MSE 的控制台上看到，就是这里边会创建一个云原生网关出来，比如说他的一个 IP 出网是109，等会测试的时候需要用到这个入口的一个 IP 。
那到这一步之后，网关就创建出来了，完成了准备就绪的第一步工作。第二步的工作就是网关创建完了之后，就要创建这个对应的路由。路由的概念是说，比如举个例子，从整个演示的一个环节，有一个应用和三个版本，当然两个版本也可以，这里支持更多的版本，三个版本、四个版本都是一样的，因此就是需要部署一个应用，第一个要把这个应用部署好，第二个要把这个 Ingress 路由创建好，这是需要两步。
然后再去发不同的请求看不同的效果。第一步就是从整个应用准备上。那可以看到一个镜像，那这个镜像创了三个实例，分别是 V1版本、 V2版本和 V3版本。而且这个版本已经部署好了，那下面需要做的应用通过Yaml 要么穿完了之后就到路由里做一个简单的配置，这里可以看到提前创造了三个路由，这些路由都是标准的 Yaml ，这里都是标准的 K8S 的 Nginx Ingress 的一个路由。这个路由是兼容了 Nginx Ingress 的一个路由，他的意思就是当 Herder User ID 等于200的时候，就相当于把向后路由的时候加一个 tag 等于 V3，当满足 User ID等于200的时候，给他路由到 tag 等于V3上，可以看到这是一个标准的 K8S 的一个 Ingress Nginx 的一个扩展。
下边也是标准的 Ingress 的使用模式，没有任何特殊的地方，然后这个东西就是可以看到 V2就是相当于当 UID 等于100的时候，那给他往后路由的时候加上一个 tag 等于 V2，这样的话后端的应用就可以根据不同的 Header 开启或者展示不同的功能。接下来通过对命令行的模式敲一下，来展示一下路由的效果。现在再讲一下路由，就是这个路由里边就相当于如果 User ID 是100，那返回后端是tag V2 。
那到这一步之后，网关就创建出来了，完成了准备就绪的第一步工作。第二步的工作就是网关创建完了之后，就要创建这个对应的路由。路由的概念是说，比如举个例子，从整个演示的一个环节，有一个应用和三个版本，当然两个版本也可以，这里支持更多的版本，三个版本、四个版本都是一样的，因此就是需要部署一个应用，第一个要把这个应用部署好，第二个要把这个 Ingress 路由创建好，这是需要两步。
然后再去发不同的请求看不同的效果。第一步就是从整个应用准备上。那可以看到一个镜像，那这个镜像创了三个实例，分别是 V1版本、 V2版本和 V3版本。而且这个版本已经部署好了，那下面需要做的应用通过Yaml 要么穿完了之后就到路由里做一个简单的配置，这里可以看到提前创造了三个路由，这些路由都是标准的 Yaml ，这里都是标准的 K8S 的 Nginx Ingress 的一个路由。这个路由是兼容了 Nginx Ingress 的一个路由，他的意思就是当 Herder User ID 等于200的时候，就相当于把向后路由的时候加一个 tag 等于 V3，当满足 User ID等于200的时候，给他路由到 tag 等于V3上，可以看到这是一个标准的 K8S 的一个 Ingress Nginx 的一个扩展。
然后这里边有几个路由，这是默认的路由，默认路由就是路由到 V1版本上去的；V3、 V2队已经建好了一个路由，就是标准 Ingress 的 Nginx 的一个扩展。
这个路由讲清楚兼容之后，那最后就可以看敲一下和命令行。这个就相当于请求一个这个域名，就是刚才109即网关的域名，这个 IP 访问一个 Header 的时候，访问这个 URL 的 Header 的时候，可以路由到后面不同的应用
Water.lyl@B-2ӨLTMD6M-2337~%curl-v-H
“host:test.com”116.62.109:8Ө/header
现在来看一下效果，当请求这个的时候即默认的情况下
他走的是 V1版本，也就是路由到了后边的整个 V1，然后对应的 tag 是没有的。
第二个就是给他加一个 user ID 等于100，刚才可以看到就是当User ID 等于100的时候，往后路由的时候会给他打一个 tag 等于 V2的一个信息下去，然后会路由到后端的一个 V2的版本上面的机器上去，来看一下效果
第一个，当 User ID 等于100的时候，可以看到路由到后端的一个V2的一个版本上面去了
并且在他向后路由的时候加上了一个 tag 等于V2，
当后端拿到这个 tag 等于 V2的时候，他就可以做自己业务逻辑上的一些开关，也就是回复的一些机制。与此同时是一样的，那加一个X-User ID 等于200，那就路由到 V3版本上去，并且在 V3版本上可以看到当 User ID 等于200的时候，就路由到 V3版本上
那我给他路由到了V3版本上去，
并且在往后路由的时候打上了一个 V3的 tag。
这就是通过一个非常小的 demo 来介绍云原生网关在整个的路由上的一个能力。当然因为时间有限只能简单的去介绍一下也就是说通过不同的 User ID Header 路由到不同的版本，一般用两个，但是支持更多的一个能力，这样通过灰度能力开发就可以最小的爆炸半径、控制半径的做线上的一个发布，包括全链路的一个发布和MSE 的全服治理做到一起之后就可以支持全链路的一个灰度能力。
