整体架构
其中Ingress又主要划分为三个组件：
- Ingress Service：NodePort类型或LoadBalancer类型的service，为Ingress Controller Pod接入外部流量
- Ingress Controller：Pod类型的工作Pod，根据Ingress Rule将外部流量转发到对应的Service上
- Ingress Rule：Ingress类型的资源，主要定义了转发规则
其中Ingress Controller有多种具体实现，常用的包括：ingress-nginx，Ingress Kong，Traefik等，如果需要在集群中支持多种Ingress Controller，则需要部署对应的Ingress Service以及Ingress Controller Deployment，然后使用Ingress Class资源在集群中定义对应的Ingress类，最后在Ingress资源中配置spec.ingressClassName即可使用指定的Ingress Controller了
p.s. Ingress资源中会有一个Address的字段，它代表了如何从外部访问到Ingress Service，如果Ingress Service本身是通过NodePort类型暴露的，那么Address就是任意一个节点的IP，如果是通过LoadBalancer类型暴露，那么Address就是云服务商提供的LoadBalancer的IP了，这些在部署了Ingress Controller以及Ingress Service的时候就决定了
ingress-nginx工作原理
- ingress controller通过和kubernetes api交互，动态的去感知集群中ingress规则变化。
- 读取Ingress Rule，按照自定义的规则（规则就是写明了那个域名对应哪个service）生成一段nginx配置。
- 将对应的nginx配置写到nginx-ingress-controller的pod里，这个Ingress controller的pod里运行着一个Nginx服务，控制器会把生成的nginx配置写入/etc/nginx.conf文件中。
- 最后reload一下nginx使配置生效，以此达到分配和动态更新问题。
ingress解决痛点
- 动态配置服务：如果按照传统方式，当新增加一个服务时，我们可能需要在流量入口加一个反向代理指向我们新的服务，而使用ingress，只需要配置好ingress，当服务启动时，会自动注册到ingress当中，不需要额外的操作
- 减少不必要的端口暴露：k8s的很多服务会以nodeport方式映射出去，这样对于宿主机来说是非常的不安全的，而ingress可以避免这个问题，只需要将ingress自身服务映射出去，就可代理后端所有的服务，则后端服务不需要映射出去
