使用kube-proxy让外部网络访问K8S service的ClusterIP

本文基于kubernetes 1.5.2版本编写

配置方式

kubernetes版本大于或者等于1.2时,外部网络(即非K8S集群内的网络)访问cluster IP的办法是: 
修改master的/etc/kubernetes/proxy,把KUBE_PROXY_ARGS=”“改为KUBE_PROXY_ARGS=”–proxy-mode=userspace” 
重启kube-proxy服务 
在核心路由设备或者源主机上添加一条路由,访问cluster IP段的路由指向到master上。

kubernetes版本小于1.2时,直接添加路由

这里写图片描述

kube-proxy转发的两种模式

一个简单的网络代理和负载均衡器,负责service的实现,每个Service都会在所有的Kube-proxy节点上体现。具体来说,就是实现了内部从pod到service和外部的从node port向service的访问。

kube-proxy在转发时主要有两种模式Userspace和Iptables。

kuer-proxy目前有userspace和iptables两种实现方式。 
userspace(如下图)是在用户空间,通过kuber-proxy实现LB的代理服务。在K8S1.2版本之前,是kube-proxy默认方式,所有的转发都是通过kube-proxy实现的。这个是kube-proxy的最初的版本,较为稳定,但是效率也自然不太高。 

另外一种方式是iptables方式(如下图)。是纯采用iptables来实现LB。在K8S1.2版本之后,kube-proxy默认方式。所有转发都是通过Iptables内核模块实现,而kube-proxy只负责生成相应的Iptables规则。 

使用Userspace模式(k8s版本为1.2之前默认模式),外部网络可以直接访问cluster IP。 
使用Iptables模式(k8s版本为1.2之后默认模式),外部网络不能直接访问cluster IP。

转发K8S后端服务的四种方式

ClusterIP

此类型会提供一个集群内部的虚拟IP(与Pod不在同一网段),以供集群内部的pod之间通信使用。ClusterIP也是Kubernetes service的默认类型。 
ClusterIP 
为了实现图上的功能主要需要以下几个组件的协同工作: 
apiserver:在创建service时,apiserver接收到请求以后将数据存储到etcd中。 
kube-proxy:k8s的每个节点中都有该进程,负责实现service功能,这个进程负责感知service,pod的变化,并将变化的信息写入本地的iptables中。 
iptables:使用NAT等技术将virtualIP的流量转至endpoint中。

NodePort

NodePort模式除了使用cluster ip外,也将service的port映射到每个node的一个指定内部port上,映射的每个node的内部port都一样。 
为每个节点暴露一个端口,通过nodeip + nodeport可以访问这个服务,同时服务依然会有cluster类型的ip+port。内部通过clusterip方式访问,外部通过nodeport方式访问。 
这里写图片描述

loadbalance

LoadBalancer在NodePort基础上,K8S可以请求底层云平台创建一个负载均衡器,将每个Node作为后端,进行服务分发。该模式需要底层云平台(例如GCE)支持。

Ingress

Ingress,是一种HTTP方式的路由转发机制,由Ingress Controller和HTTP代理服务器组合而成。Ingress Controller实时监控Kubernetes API,实时更新HTTP代理服务器的转发规则。HTTP代理服务器有GCE Load-Balancer、HaProxy、Nginx等开源方案。 
详细说明请见http://blog.csdn.net/liyingke112/article/details/77066814 
这里写图片描述

service的三种端口

port

service暴露在cluster ip上的端口,:port 是提供给集群内部客户访问service的入口。

nodePort

nodePort是k8s提供给集群外部客户访问service入口的一种方式,:nodePort 是提供给集群外部客户访问service的入口。

targetPort

targetPort是pod上的端口,从port和nodePort上到来的数据最终经过kube-proxy流入到后端pod的targetPort上进入容器。

port、nodePort总结

总的来说,port和nodePort都是service的端口,前者暴露给集群内客户访问服务,后者暴露给集群外客户访问服务。从这两个端口到来的数据都需要经过反向代理kube-proxy流入后端pod的targetPod,从而到达pod上的容器内。

猜你喜欢

转载自my.oschina.net/xiaominmin/blog/1631563