Hi folks
I am new to Kong and have some basic architecture question. The context
We have a lot of REST API’s that are running in different Kubernetes clusters and some are running on EC2 as well as on-premise VM. I want to explore the usage of Kong API Gateway to centralize all API access. I am aware of API gateway node installations on VM, docker etc. I am trying to explore the usage of K8s as a place where my API Gateway will reside to get the High Availability out of K8s (Kubernetes). I am aware of Kong Ingress Controller providing the ingress traffic into K8s and that internally talking to API gateway components (not exposed to users)
Question 1:
Since most of my Rest API services are not going to be inside the K8s cluster where Kong resides, is deploying Kong in K8s a good approach?
Question 2:
Assuming that the answer to question 1 is “yes”, I see that the way Kong can interact with external services (which is going to be the case for me) is via K8s Service feature of ExternalName and the DNS route. Do I understand this correctly?
Question 3:
I actually do not need the Kong ingress controller just the API Gateway piece but most documentation speak of the two and also have examples of reaching services that reside inside the K8s cluster where the Kong components reside. Am I on the wrong track here architecture wise?
If you’re not planning to migrate other services into Kubernetes slowly, there’s probably not too much reason to use it for Kong alone. The Kubernetes integrations are most useful when you are using Kubernetes throughout your stack. ExternalName Services are supported and work fine, but if you’re using them for most everything upstream you’re probably not getting a huge amount of value out of using Kubernetes–it sounds like you’d mostly be using it just to handle scheduling and scaling Kong instances at that point, which you could reasonably handle with dedicated VMs and ASGs for the Kong cluster.
Ultimately it depends on your preferences and whether you have other reasons to use Kubernetes. If you don’t, the non-Kubernetes options for deploying and configuring Kong work fine and offer the same level of functionality. Kong is designed to be architecture-agnostic.
@traines
Thanks for responding. All of our services will be outside the EKS cluster in which the Kong ingress controller/API GW will be deployed in. Basically, I am also trying to make a use case for using ASG/EC2 (with cloudformation) instead of EKS. However our IT wants to go down the path of EKS, their primary reason is to not use an AMI and EC2 as it adds operational complexity to O.S. patching which they do not want.
I will be engaging the Kong sales rep. at some point to ensure that we get an approved recommendation from Kong, we most likely will end up using Kong Enterprise (not the OSS version).
But I wanted to get the open source communities input on whether its even a viable solution to have when most of our services are not in the same cluster as the Kong components.
It sounds like you are suggesting that its not reasonable although doable 
Thanks a lot for your inputs