Enable the Kong Gateway practice in Kubernetes clustering.

background

In fact, before we begin to take Kong, we have to answer two questions first: 1. Why an API Gateway? 2. Why choose Kong as the gateway?

I’ll skip the first question. Answer the second question briefly.

In the face of this problem, in fact, it is a problem of technology selection, so we as ordinary developers, generally from the following aspects to balance, to choose:

  1. Technology stack: In addition to the implementation of the gateway itself, we should also consider the technology docking with our own business.
  2. Cost: Open source or charged.
  3. Mature: whether to undergo production environment verification, whether to be everbright user verification.
  4. Deployment/operation cost: Compatibility with Cloud native (Kubernetes).
  5. Function/plug-in/middleware: whether the gateway has rich functions, whether there is a rich plug-in library, whether it is convenient to add custom plug-in/middleware.
  6. Acceptance level: The acceptance level of the developer, the higher the acceptance level, the lower the API Gateway requirements, and vice versa.

The JAVA system does not need to consider the above, consider the Spring family bucket. Later, I also asked the technical support of Aliyun, and they told me that their enterprise users are mainly Kong and Tyk.

And then I’ll tell you why. I live in the nginx + PHP technology stack and have a bias towards Nginx and Lua. Then, my colleagues around me think they can handle Kong after they have been in contact with it, so they like Kong.

layout

The addition or adjustment of API Gateway is often accompanied by changes in business technology architecture, and I also faced the transition from SLB(load balancing) + AliyunECS(Nginx + PHP) to SLB + Kubernetes.

We also need to consider how to smoothly migrate from the ECS architecture to the Kubernetes architecture, and how to land the business APP and Gateway Kong API Gateway.