如何在Kubernetes中暴露服务访问

╰+攻爆jí腚メ 2022-06-16 09:48 227阅读 0赞

## Kubernetes概述 ##

最近的一年，kubernetes的发展如此闪耀，正被越来越多的公司采纳用于生产环境的实践。同时，我们可以在最著名的开发者问答社区StackOverflow上看到k8s的问题数量的增长曲线（2015.5-2016.5），开发者是用脚投票的，从这一点看也无疑证明了k8s的火爆程度。

![20170103153200_514.jpg][]

k8s来源于Google生产环境的实践，社区活跃度很高，在github上的Star数17k+，30k+commits，同时由Google主导CNCF基金会也在强力运作k8s的社区发展，也就在几个月前OpenStack社区宣布全面拥抱k8s，这也宣布了全球第大的开源IAAS云社区已经选择k8s作为容器的唯一解决方案。

![20170103153200_292.jpg][]

谈到k8s，无论怎样的议题怎样的开始，我们都先介绍一个k8s整体架构（如下图所示）：

![20170103153200_434.jpg][]

etcd 作为配置中心和存储服务，保存了所有组件的定义以及状态，k8s的多个组件之间的互相交互也主要通过etcd；

kube-apiserver 提供和外部交互的接口，提供安全机制，大多数接口都是直接读写etcd中的数据；

kube-scheduler 调度器，主要干一件事情，监听etcd中的pod目录变更，然后通过调度算法分配node，最后调用apiserver的bind接口将分配的node和pod进行关联；

kube-controller-manager 承担了master的主要功能，比如和CloudProvider(IaaS)交互，管理node，pod，replication，service，namespace等。

基本机制是监听etcd /registry/events下对应的事件，进行处理；kubelet 主要包含容器管理，镜像管理，Volume管理等；kube-proxy 主要用于实现k8s的service机制。提供一部分SDN功能以及集群内部的智能LoadBalancer。

本文分享的内容主要是在minion节点上的pod和service上，pod是k8s应用的具体实例抽象，而service便是这些抽象的集合。

![20170103153200_882.jpg][]

## ClusterIP & NodePort & Loadbalancer ##

回到本文的主题，在k8s中暴露Service访问（无论内部还是外部），都要经过kube-proxy，比如下图中我们定义一个Service，便可以通过访问Service的80端口转发到Pod的9376端口上。

![20170103153201_683.jpg][]

kube-proxy在转发时主要有两种模式Userspace和Iptables。如下图，左侧是Userspace模式，也是kube-proxy默认的方式，所有的转发都是通过kube-proxy软件实现的；右侧是Iptables模式，所有转发都是通过Iptables内核模块实现，而kube-proxy只负责生成相应的Iptables规则。从效率上看，Iptables会更高一些，但是需要Iptables version >=1.4.11，Iptables模式在k8s1.2版本放出，是否开启使用还需要具体斟酌。

![20170103153201_707.jpg][]

从Service本身看，有三种方式来暴露访问：

*  ClusterIP：使用集群内的私有ip —— 这是默认值
 *  NodePort：除了使用cluster ip外，也将service的port映射到每个node的一个指定内部port上，映射的每个node的内部port都一样。
 *  LoadBalancer：使用一个ClusterIP & NodePort，但是会向cloud provider申请映射到service本身的负载均衡。

LoadBalancer Provider主要有aws、azure、openstack、gce等云平台提供。相关实现可以在k8s的源码中看到，如下图所示：

![20170103153201_524.jpg][]

## Ingress ##

Ingress也是k8s中单独定义的对象（如下图所示），它的作用就是实现对外暴露访问的负载均衡，那么它和Service本身LoadBalancer有哪些区别呢？Ingress支持L4、L7负载均衡，LoadBalancer设计上只支持L4；Ingress基于Pod部署，并将Pod网络设置成external network；Ingress controller支持Nginx、Haproxy、GCE-L7，能够满足企业内部使用。

![20170103153201_294.jpg][]

在实际使用时，Ingress的架构如下图所示：

![20170103153201_89.jpg][]

但是在实际使用中，pod可能会产生漂移，由于Ingress Controller也是基于Pod部署，这样Ingress对外的IP会发生变化。在企业内部都会在防火墙上给Service的访问IP设定规则，而IP变动对这一机制是致命的，因为企业不可能经常手动修改防火墙规则。

那么我们就需要一个VIP功能，同时也要能保证Ingress的HA。我们可以考虑在Ingress Controller基础上增加一个keepalived，可以利用keepalived＋haproxy的机制来完成VIP的功能。要实现这一机制，可以参考并改动k8s社区中的contrib-keepalived-vip机制。

![20170103153201_682.jpg][]

除了以上介绍的暴露服务机制，还有Hpcloud-service-loadbalancer ，它实现了支持keepalived+nginx、F5、OpenStack Lbaas这些方式，并且支持L4 & L7负载均衡，但是与k8s社区本身的发展机制并不兼容，所以一直没有被合并到社区中。另外还有 Contrib-service-loadbalancer ，这个是社区内部正在发展的，它的想法更远大，考虑会支持Cross-namespace、 Cross-cluster这种级别的负载均衡，同时也是设计了插件机制，目前支持Haproxy，同样也支持L4 & L7负载均衡。

## Rancher K8s中暴露服务访问 ##

Rancher自己实现了一个rancher-ingress-controller，它本质上是包装了k8s-ingress-controller，在真正创建负载均衡器上它会调用Rancher Cattle API来创建Rancher自身的LB。

![20170103153201_647.jpg][]

相关代码也是开源的， [ https://github.com/rancher/lb-controller][https_github.com_rancher_lb-controller] ，lb-controller在启动时候会指定provider为rancher，对应的实现也可在package provider/rancher中看到。

![20170103153201_632.jpg][]

创建Ingress后，也可在Rancher UI上展现出来。

![20170103153201_323.jpg][]

[20170103153200_514.jpg]: /images/20220616/3c3de947ec194fb4873bb426fdb84b28.png
[20170103153200_292.jpg]: /images/20220616/195763a906664d6a83cd6b913e2f17bc.png
[20170103153200_434.jpg]: /images/20220616/902e51ca36154f129ae2e9c76a71d1b2.png
[20170103153200_882.jpg]: /images/20220616/37637fa5c47a4c3ea50f64a0cad0e65c.png
[20170103153201_683.jpg]: /images/20220616/facec3a9844b4e9ea8c09f07f67d824f.png
[20170103153201_707.jpg]: /images/20220616/fcd128ca937f4cb8ab0b5c4fed267cbe.png
[20170103153201_524.jpg]: /images/20220616/b0d81be31e7946278fcec3add664c776.png
[20170103153201_294.jpg]: /images/20220616/a3f5bc9319144c1eb9bf373d6d8e12e6.png
[20170103153201_89.jpg]: /images/20220616/31460f31129648e69fc70d697109c62a.png
[20170103153201_682.jpg]: /images/20220616/c82926b20c364f9a8be1b7d1af7719e6.png
[20170103153201_647.jpg]: /images/20220616/07b5f9522996454ab8267f741f9d33e0.png
[https_github.com_rancher_lb-controller]: https://github.com/rancher/lb-controller
[20170103153201_632.jpg]: /images/20220616/c4f51250f53a4fd1b4ab4d2999cb5734.png
[20170103153201_323.jpg]: /images/20220616/151845f9ee5a4c6188e5762644d5c527.png