开启 Kong 网关在 Kubernetes 集群的实践。
背景
其实在开始将 Kong 之前，我们不能不先回答两个问题是：1. 为什么要有 API Gateway ？2. 为什么选 Kong 作为网关 ？
第一个问题直接略过。简单回答下第二个问题。
面对这问题的时候，其实是一个技术选型的问题，因此我们作为普通开发人员，一般从以下几个方面去平衡，去选择：
- 技术栈：除了网关本身的实现，也要考虑与自身业务的技术对接。
- 费用：开源或收费。
- 成熟：是否经受生产环境验证，是否被光大用户验证。
- 部署/运维成本：与云原生（Kubernetes）的兼容性。
- 功能/插件/中间件：网关功能是否丰富，是否有丰富的插件库，是否方便添加自定义插件/中间件。
- 接受水平：开发人员的接受能力，能力越强，那么对 API Gateway 要求就可以放低，反之亦然。
其中 JAVA 系不需要考虑上面，考虑就是 Spring 全家桶。然后，我后来也问过阿里云的技术支持，他们告诉我，他们的企业用户主要以Kong和tyk为主。
然后我说下选择的原因。我所处的环境是 nginx + php 的技术栈，对 nginx 和 lua 有倾向性，然后周围的同事觉得平时接触过，就觉得能驾驭 Kong，因此相中了 Kong。
布局
API Gateway 的加入或者调整往往伴随着业务技术架构的变化，而我也面临 SLB(负载均衡) + AliyunECS(nginx+php) 转型到 SLB + Kubernetes 的变迁。
另外我们还要考虑如何从 ECS 架构平滑地迁移到 Kubernetes 架构，以及业务 APP 和网关 Kong API Gateway 如何落地的问题。
本文转载自: 掘金