我的K8s之路-ingress实现k8s服务访问
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了我的K8s之路-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 Ingress
2、 Kubernetes Ingress Controller
Kubernetes Ingress是k8s的源生资源,也提供API访问。主要定义了外部通过IP或域名、或加路径访问集群内部的service。但是光有它还不够,具体实现要靠Ingress Controller来做。
Ingress Controller即ingess控制器,是在定义ingress资源之前,手动部署在k8s集群的,与其它应用一样也是一个POD,它的作用是随时与k8s的ingress API进行通讯,检查是否要为外部访问路由到service创建规则。
网上找了张图,简单了点,不过基本上是这样的(懒得自己画了:)
这两个说白了等于是一个定义了访问规则,一个来实现路由访问。
转
上述说的是概念定义,现在业界实现ingress功能的有那么几种,比较多的是用nginx来实现,还有Traefik、HAproxy,包括GKE等等,这次的测试就以nginx来做。
还是用上次部署的源生k8s,先将ingress controller的部署文件搞到,在github的仓库里有
我git的是kubernetes提供的ingress-nginx,全下载大约有个100兆多点。其实还有nginx提供的,不过那个没咋用过。
在老版本中,是分成多个yaml文件,由mandatory.yaml统一执行,新版本(2.1.0)合成一个yaml,除了对应k8s部署外,还有对公有云的。
另外,老版本中要自行添加节点选择器,新版本中已经配了选择条件
ingress-ready=true
所以在执行之前,要先给一个节点配上label
kubectl label nodes k8s-node01 ingress-ready=true
执行部署:
会自动创建namespace,名为ingress-nginx。在这个ns内创建角色、控制器、服务等等等等。。。。。。
创建好之后查看执行结果
现在开始测试,首先创建服务,再将其暴露出来,这个用命令或者yaml都可以,本次测试主要针对ingress,所以其它的就简单实现了
kubectl run --image=nginx test01
kubectl run --image=nginx test02
先用命令创建两个服务,查看创建结果
再将两个服务暴露出来
kubectl expose pod test01 --port=80 --target-port=80
kubectl expose pod test02 --port=80 --target-port=80
用curl命令验证上图中两个clusterIP能否访问,访问正常的情况下,我将test01与test02内nginx的index.html更换内容以便于区分,以test01为例:
root@k8s-master:~# kubectl exec -it test01 bash
root@test01:~# cd /usr/share/nginx/
echo "test01-curl" > index.html
测试访问
好,接下来部署ingress,制定访问规则,编写yaml之前先查看ingess的API 版本
kubectl explain ingress
编写ingress的YAML
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: ingress-example
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
spec:
rules:
- host: test.redflag.com
http:
paths:
- path: /red
backend:
serviceName: test01
servicePort: 80- path: /flag
backend:
serviceName: test02
servicePort: 80
(也许是编辑器原因,记得将o都换成-)
其中,ingress的API是用的刚查到的版本,访问域名为test.redflag.com,刚创建的两个服务与端口分别对应/red与/flag两路径访问,查看部署结果。
查看详细信息
kubectl describe ingress ingress-example
其中访问路径对应的IP地址,是cailico网络插件的地址,这是上回部署环境时装的网络插件。再查看service服务的后端IP,看是否一致。
kubectl get endpoints
好,现在开始验证部署结果,看是否能访问,简单实现我不配外部DNS解析了,就用本地解析,修改master节点的/etc/hosts文件,在节点1或节点2后边配本地解析都可以。
在master节点测试访问
到这里还没完,再看看ingress-controller的实现方式,进入ingress-controller的pod
kubectl -n ingress-nginx exec -it ingress-nginx-controller-cc8dd9868-lr5xf bash
查看nginx.conf文件
cat /etc/nginx/nginx.conf
找到下图这段
这段就是访问test.redflag.com的配置部分的开始。
下边分别是/red与/flag的访问配置
结
根据以上配置,nginx的ingress-controller的配置访问,是由nginx访问代理来实现的,当ingress创建后,ingress-controller通过监控与ingress API交互,根据ingress定义的访问规则,自动配置nginx访问代理,不只是一个域名两个路径,多个域名多路径也可以实现。
以上是关于我的K8s之路-ingress实现k8s服务访问的主要内容,如果未能解决你的问题,请参考以下文章
使用vagrant搭建k8s节点五---使用Ingress实现域访问
使用vagrant搭建k8s节点五---使用Ingress实现域访问