Kubernetes 引入的 Service 层给集群带来了两样特性:第一是 ClusterIP,通过集群 DNS 分配的服务别名,服务可以获得一个稳定的服务名字,例如:foo.bar.svc.cluster.local。第二是反向代理,通过 iptables/IPVS/eBPF 等各种网络数据转换技术把流量负载到上游的 Pod 容器组中。到这里,其实 Service 层的基本技术已经给大家介绍了,但是从实践的角度再次分析,发现其中还有很多最新的进展需要给大家讲解以下,并从中我们能总结出技术发展过程中如何优化的策略总结。
Ingress 的误解?
在社区文档中介绍的 Ingress 资源,我们知道它是应对 HTTP(S) Web 流量引入到集群的场景创建的资源对象。一般介绍中我们会说它不支持 L4 层的引流。如果想支持其它网络协议,最好用 Service 的另外两种形式 ServiceType=NodePort
或者 ServiceType=LoadBalancer
模式来支持。
首先,Ingress 资源对象能不能支持 L4 层,并不是完全由这个资源对象能把控,真正承载引流能力的是独立部署的 Ingress-Nginx 实例,也就是 Nginx 才能决定。我们知道 Nginx 本身就是支持 L4 层的。所以,Ingress 通过变相增加参数的方式可以提供支持:
apiVersion: v1
kind: ConfigMap
metadata:
name: tcp-services
namespace: default
data:
27017: "default/tcp-svc:27017"
---
apiVersion: flux.weave.works/v1beta1
kind: HelmRelease
metadata