This message was deleted.
# kubernetes
s
This message was deleted.
t
Hi, If you don't mind me asking, I'm curious about your reasons for this migration, like limitations in the ALB, cost, ..? Some thoughts: 1. I don't have hands-on experience with KIC but it makes sense as you can (continue to) configure the load balancing based on K8s resources. If you're planning to configure Kong differently, you might not need KIC at all. 2. Depends on your availability requirements and how the (I'm assuming, external) traffic will get to Kong exactly. An ALB is high-available across AZs and therefore good to get traffic into your EKS cluster even if one AZ becomes unavailable. You would be rebuilding that with Kong. An NLB might still be needed to "expose" the entrypoint service in your cluster if your cluster (nodes) are in a private subnet. 3. While an NLB can terminate SSL traffic, it doesn't understand any HTTP. If you're planning to make all HTTP-based decisions in Kong (virtual host names, path-based routing) this could be fine and you don't need another ALB. Whether you better terminate SSL in Kong depends on your requirements. You may have/define requirements on how to maintain/rotate certificates. Are they issued by AWS or an external provider..?
a
@Thomas Kraus Thank you for the response We are migrating to API Gateway for majorly two reasons 1. Having centralised rate limiting and decoupling it from individual services 2. Having authentication logic at gateway layer which is distributed to multiple services right now and there are some upgrades we need to do every now and then at each of these services For SSL certificates, I believe they are issues by third party but I need to confirm again
v
Re#2 you probably need some LB. Assuming that Kong is distributed across your nodes you would likely want a load balancer in front of those same node pool(s). On my team we use an NLB and ingress nginx behind it Re#3 - we handle certs within the cluster using letsencrypt via cert manager. If you have a high volume requirement beyond what letsencrypt can support, Google has a public CA as does zeroSSL. Hope this helps!