民生银行：基于 F5 技术实现 Kubernetes 生产环境最佳实践

转载自博客：https://cloud.tencent.com/developer/news/401666

Kubernetes服务发布方式及局限性

Service是Kubernetes最核心的资源对象之一，通过它可以为一组具备相同功能的容器应用提供一个统一的访问入口地址，并将请求负载分发到后端的各个容器应用上。这一点与传统IT基础架构中F5等负载均衡设备将访问请求负载分发到后端功能相同的应用上类似，Kubernetes集群中每个节点上运行的kube-proxy其实就是一个智能的软件负载均衡器，它负责把对Service的请求转发到后端的某个pod实例上，并在内部实现服务的负载均衡与会话保持机制。Service被分配了一个全局唯一的虚拟IP地址，称为ClusterIP。但ClusterIP只能实现集群内部的访问（即东西向服务），对于需要通过外部IP对外提供访问（即南北向服务）的场景，Kubernetes提供了三种主要方案，分别是NodePort 、LoadBalancer 、Ingress。

2.1 NodePort

NodePort 的实现方式是在每个节点上为需要外部访问的Service开启一个对应的TCP监听端口，外部系统用:可以从集群外部访问一个NodePort服务，NodePort 服务会路由到 ClusterIP ，通过kube-proxy转发至后端的容器，完成对服务的访问。NodePort的方式是解决服务暴露问题最直接的做法，其配置和维护都很简单，但它依赖于kube-proxy，目前仅支持轮询算法以及源地址会话保持。在负载均衡的其他特性方面还有一定缺陷。另外，NodePort占用node节点一个独立的端口，限制了集群中暴露服务的数量。且在实际使用过程中定义一个NodePort，需要在Kubernetes集群中的所有节点上开通此端口的入访能力，因此一般会结合集群外的负载均衡设备，与kube-proxy形成两级负载均衡的架构，对性能会产生一定影响，同时增加成本。

2.2 LoadBalancer

LoadBalancer 是Kubernetes深度结合云平台的一个组件，使用它构建服务时，实际上是向底层IaaS申请创建一个负载均衡来实现。IaaS网络和容器网络在不同云平台的融合方案不同，因此LoadBalancer 和云平台的网络方案深度耦合，只能在特定的云平台上使用，局限性较大。

2.3 Ingress

Ingress可以很好的解决LoadBalancer和NodePort的限制。它由3个组件组成：Ingress策略集、Ingress Controller和反向代理负载均衡器（如Nginx）。Ingress策略集定义了集群外的流量到达集群内的Service的规则。Ingress Controller与Kubernetes的API交互，实时感知后端Service、pod的变化，再结合Ingress策略集生成配置，然后更新反向代理负载均衡器的配置，实现动态服务发现与更新。反向代理负载均衡器对集群外流量进行负载分发。现有的Kubernetes版本已将Nginx与Ingress Controller合并为一个组件Nginx-Ingress-Controller，无需单独部署Nginx。但Kubernetes原生Ingress是一个七层负载均衡技术，仅适用于http服务。另外，其并未解决Kubernetes环境下，不同租户的服务隔离问题。