我的K8s之路(2)-ingress实现k8s服务访问

我的K8s之路(2)-ingress实现k8s服务访问

起上回写了一篇入门级的小文，做为这一系列的开始，毕竟什么都是从部署做起的。从k8s本身来说，无论是pod、控制器、svc，还是配置运行条件等等，都是基本内容，只要是接触过，多少都有了解，这也是我每回讲课带班必讲的。但是有一个配置，严格上来说不能算是k8s本身提供的功能，应该说是k8s与其它软件配合实现的，这一部分在CKA考试是没有的，但在实际生产环境是经常会用到的，一般的k8s培训也都会讲到，这回就跟大伙简单说说：ingress。

ingress英译过来的意思是进入或入境权，这与它要实现的功能很是帖切。为什么会有它的存在呢？这与k8s本身提供的服务暴露功能有关，k8s存在的意义在于容器编排，容器的意义是运行应用，所以k8s实际的功能是根据不同的业务需求编排运行应用。而应用运行的意义是要能被访问，这就牵扯到了如何将服务暴露出去接受访问。

承k8s本身能够创建services资源暴露服务，目前来说提供三种服务暴露方式：1. clusterIP，这种方式只提供k8s集群内部访问，如果应用之间要通讯，或做测试是很方便的，但无法提供外部访问。

2. nodePort，这种方式是能够提供集群外部访问的，但是有个先天不足，这种暴露服务需要集群内每个节点都提供相同的服务端口，无论访问哪个节点的IP:PORT，都可以通过service指向后端运行的控制器或POD。其端口是随机的，范围在30000到32767之间。既然是随机的，就有不确定性，很多路由、防火墙等这些网络设备配置上有一定困难，而且也并不是标准访问端口。个人认为最大的不足还不是端口号，是一个服务导致每个节点都要暴露端口，实用性不是很高。

3. 负载均衡，这种方式k8s只提供内部支持，真正的实现要靠外部云供应商提供的负载均衡器技术，功能落地是没有问题，但会有产生费用，客户还是希望少花多办事的。

基于以上几点，这才有了第三方解决方案，即ingress。ingress的功能实现在于能够将外部的访问，准备路由到对应的service服务，由两部分组成：

1、 Kubernetes Ingress2、 Kubernetes Ingress Controller

转上述说的是概念定义，现在业界实现ingress功能的有那么几种，比较多的是用nginx来实现，还有Traefik、HAproxy，包括GKE等等，这次的测试就以nginx来做。

还是用上次部署的源生k8s，先将ingress controller的部署文件搞到，在github的仓库里有

git clone label nodes k8s-node01 ingress-ready=true执行部署：

结根据以上配置，nginx的ingress-controller的配置访问，是由nginx访问代理来实现的，当ingress创建后，ingress-controller通过监控与ingress API交互，根据ingress定义的访问规则，自动配置nginx访问代理，不只是一个域名两个路径，多个域名多路径也可以实现。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。