「网络拓扑」Kubernetes 网络模型来龙去脉( 四 ) |设计|Mac电脑|Docker|

4. ExternalName摈弃内部机制，依赖外部设施，比如某个用户特别强，他觉得我们提供的都没什么用，就是要自己实现，此时一个 Service 会和一个域名一一对应起来，整个负载均衡的工作都是外部实现的。
下图是一个实例。它灵活地应用了 ClusterIP、NodePort 等多种服务方式，又结合了云厂商的 ELB ，变成了一个很灵活、极度伸缩、生产上真正可用的一套系统。

本文插图
首先我们用 ClusterIP 来做功能 Pod 的服务入口。大家可以看到，如果有三种 Pod 的话，就有三个 Service Cluster IP 作为它们的服务入口。这些方式都是 Client 端的，如何在 Server 端做一些控制呢？
首先会起一些 Ingress 的 Pod（Ingress 是 K8s 后来新增的一种服务，本质上还是一堆同质的 Pod），然后将这些 Pod 组织起来，暴露到一个 NodePort 的 IP ， K8s 的工作到此就结束了。
任何一个用户访问 23456 端口的 Pod 就会访问到 Ingress 的服务，它的后面有一个 Controller ，会把 Service IP 和 Ingress 的后端进行管理，最后会调到 ClusterIP ，再调到我们的功能 Pod 。前面提到我们去对接云厂商的 ELB ，我们可以让 ELB 去监听所有集群节点上的 23456 端口，只要在 23456 端口上有服务的，就认为有一个 Ingress 的实例在跑。
【「网络拓扑」Kubernetes 网络模型来龙去脉】整个的流量经过外部域名的一个解析跟分流到达了云厂商的 ELB ， ELB 经过负载均衡并通过 NodePort 的方式到达 Ingress ， Ingress 再通过 ClusterIP 调用到后台真正的 Pod 。这种系统看起来比较丰富，健壮性也比较好。任何一个环节都不存在单点的问题，任何一个环节也都有管理与反馈。
本文总结
本节课的主要内容就到此为止了，这里为大家简单总结一下：