dcoker nginx container
dcoker container
kubelet
docker container
nginx-ingress-controller
serviceA
pod
修改
docker
kubernetes
Ingress Controller自身也是运行于集群中的pod资源对象，它与被代理的运行为pod资源的应用运行于同一网络中。使用Ingress资源进行流量分发时，Ingress控制器可基于某Ingress资源定义的规则将客户端的请求流量直接转发至与service对应的后端pod资源之上，这种转发机制会绕过service资源，从而省去了由kube-proxy实现的端口代理开销。Ingress规则需要由一个service资源对象辅助识别相关的所有pod对象，但Ingress-nginx控制器可经由api.ilinux.io规则的定义直接将请求流量调度至后端pod上，而无须经由service对象api的再次转发。Ingress Controller 通过与 Kubernetes API 交互，动态的去感知集群中 Ingress 规则变化，并按照规则模板生成一段 Nginx 配置，再写到 Nginx Pod 里，最后 reload 一下
prod.dbqp.com.cn/b
kube-porxy
pod-nginx-ingress
47.94.86.14
nginx-ingress-service
Controller Manager
serviceB
API Server
Ingress是k8s的标准资源类型之一，它其实就是一组基于DNS名称或URL路径把请求转发至指定的service资源的规则，用于将集群外部的请求流量转发至集群内部完成服务发布。然而，Ingress资源自身并不能进行流量穿透，它仅是规则的集合，这些规则要想真正发挥作用还需要其他功能的辅助，如监听某套接字，然后根据这些规则的匹配机制路由请求流量。这种能够为Ingress资源监听套接字并转发流量的组件称为Ingress控制器。简单的理解就是你原来需要改 Nginx 配置，然后配置各种域名对应哪个 Service，现在把这个动作抽象出来，变成一个 Ingress 对象，你可以用 yaml 创建，每次不要去改 Nginx 了，直接改 yaml 然后创建/更新就行了；
test.dbqp.com.cn/b
1发生变化调用
2通知
47.95.224.190/test.dbqp.com.cn
test.dbqp.com.cn/a
otherIP/prod.dbqp.com.cn
jenkins
etcd
ingress
prod.dbqp.com.cn/a
scheduler
