类型的入口或服务:LoadBalancer [英] Ingress or Service with type: LoadBalancer

问题描述

Kubernetes既有入口(位于服务前)，服务类型: LoadBalancer .它们似乎做着相同的事情:允许公共流量进入与服务选择器匹配的Pod中.每种都有哪些优点和缺点?在什么情况下我会选择一个?

Kubernetes has both Ingress (in front of a Service) and Service with type: LoadBalancer. These seem to do identical things: allow public traffic into the pods matching the service's selector. What are the benefits and drawbacks of each? In what scenarios would I choose one over the other?

推荐答案

假设您的基础架构位于AWS，GCP或Azure

Assume that AWS, GCP or Azure is where your infrastructure located

> 入口:

• 仅当您具有入口控制器(例如nginx-ingress-controller，traefik，...)时才能工作.

• Only work if you have ingress controller such as nginx-ingress-controller, traefik,...

许多服务可以共享同一个入口

Many services could share the same ingress

基于名称的虚拟主机

基于路径的路由

仅需要一个AWS ELB(或Google Cloud的GCP负载平衡器)

Only one AWS ELB (or GCP load balancer for Google Cloud) is needed

对于大多数用例，建议采用这种方法

Recommend to follow this approach for most of use cases

serviceType LoadBalancer:

• 每个服务都会创建单独的AWS ELB(成本低廉，如果以后有越来越多的服务，成本将会非常高)

• each service would create separated AWS ELB (cost inefficiency, would be super expensive if you have more and more services later)

如果您想确保最大的安全性/工作量(每个服务1 ELB)，可能会有所帮助

Could be helpful in case you want to ensure maximum security / workload ( 1 ELB per service)

这篇关于类型的入口或服务:LoadBalancer的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！