Kubernetes Service 的type
默认是 ClusterIP
Type 的取值以及行为如下:
ClusterIP:通过集群的内部 IP 暴露服务,选择该值,服务只能够在集群内部可以访问。
NodePort:通过每个 Node 上的 IP 和静态端口(NodePort 默认30000-32767)暴露服务。NodePort 服务会路由到 ClusterIP 服务,这个 ClusterIP 服务会自动创建。通过请求 <NodeIP>:<NodePort>,可以从集群的外部访问一个 NodePort 服务。
LoadBalancer:使用云提供商的负载局衡器,可以向外部暴露服务。外部的负载均衡器可以路由到 NodePort 服务和 ClusterIP 服务。
ExternalName:通过返回 CNAME 和它的值,可以将服务映射到 externalName 字段的内容(例如, foo.bar.example.com)。 没有任何类型代理被创建。
kube-proxy mode
userspace mode : 当service创建时开一个随机的nodeport,然后将路由写到iptable。当请求访问service的ip+端口时,被iptable拦截并重定向到nodeport上,kube-proxy监听这个端口,把请求转发到pod上,路由模式是round robin。kube-proxy在这里承担了一个反向代理的职责,当kube-proxy与iptables进行交互并进行lb时,必须经常在用户空间和内核空间之间切换上下文。
iptable mode:kube-proxy在service创建时就把路由规则写到了iptable,请求访问service的ip+端口时,直接被重定向到pod上,路由模式是随机。kube-proxy完全将流量分发和负载均衡的任务委派给了netfilter / iptables, 所有这些任务都发生在内核空间中,这使该过程比userspace mode下的处理要快得多。
ipvs mode:iptables主要被设计用作防火墙,在node上service和pod的规模很大时性能表现不佳。而 IPVS(IP虚拟服务器)建立在netfilter之上,作为Linux内核的一部分,实现了传输层负载平衡。 它是Linux虚拟服务器(LVS)的组件,设计初衷就是为了做负载均衡,有更好的扩展性和更快的性能。
kube-proxy可以通过参数 --ipvs-scheduler 来设置路由模式
lc: least connection
dh: destination hashing
sh: source hashing
sed: shortest expected delay
nq: never queue
端口
pod的containerPort是pod对外暴露的端口,如果containerPort跟container中应用的端口不一致,那应用也就无法被访问
service的port是servcie对外暴露的端口,集群内部可以通过这个端口互相访问(集群内部的概念待明确),targetPort是service映射到pod的端口,也就是跟pod的containerPort相对应,type为NodePort时,会生成Node对外暴露的端口,映射到service的port上