据我所知,Ingress 只是针对 Nginx(或其他)的 LoadBalancer 服务的抽象层
是否有只有 Ingress 才能提供的功能?使用 LoadBalancer + Nginx 有什么缺点吗?
答案1
据我所知,Ingress 只是针对 Nginx(或其他)的 LoadBalancer 服务的抽象层
这只是部分正确;hostNetworking: true
如果你愿意,你可以直接从节点上使用和公开 Ingress 控制器,跳过 SDN 和对负载均衡器的需求(尽管有了坏处将节点的端口直接暴露给互联网)——这与只使用额外端口Service
的想法大致相同type: NodePort
许多人确实在 LoadBalancer 后面使用 Ingress 控制器来将节点与互联网隔离,但这并不是要求
还应该意识到ALB 入口控制器另一种情况是:要求 LBhost:
在到达集群之前执行 URI 路由,并且集群中没有运行 nginx 组件
是否存在只有 Ingress 才能提供的功能?
仅有的?不太可能。方便的以及云便携性?极其
我不确定这是否是您要问的,但大多数人使用单个 LB 和集群内 Ingress 控制器的原因是,只需支付一个具有几乎无限 Ingress 资源的 LB 即可节省大量成本。如果没有 Ingress,则需要使用Service
,type: LoadBalaner
然后等待 kubernetes 为每个服务配置新的 LB,这会花费时间和金钱
使用 LoadBalancer + Nginx 有什么缺点吗?
主要围绕错误和成本管理:
- 从 LB 到集群内的 httpd 会有一个额外的网络跳跃
大多数 LB 都有自己的自己的健康检查方案,并且 LB 的健康检查可能会因入口控制器的健康检查失败而失败,从而导致人为中断
路由问题、权限、云配额等问题也是如此
- 可能存在两种不同的安全机制:LB 和入口控制器,如果它们不一致,则可能导致中断
- 如果开启了访问日志记录,则会记录两次,一次在 LB,一次在入口
- 需要注意的是,集群内路由正在进行,否则就很难理解为什么所有东西都只使用一个 LB