首先 Service是一种k8s集群中访问pod的策略。k8s中的pod具有生命周期,且不可复活。每个pod有着自己的IP地址,pod的销毁与创建都会创新的IP地址。Service就是用来统一管理跟踪这些pod的变化,即使pod发生变化,对于前台的调用是无感知,前台无需进行任何修改。service肩负着服务发现与负载均衡等职能。
首先创建一个pod,标签为web(后续的service是通过匹配这个标签来实现管理pod的)
apiVersion: apps/v1
kind: Deployment
metadata:
name: dep01
spec:
selector:
matchLabels:
app: web
replicas: 2
template:
metadata:
labels:
app: web
spec:
containers:
- name: testnginx9
image: daocloud.io/library/nginx
ports:
- containerPort: 80
创建出来的pod如下
再创建一个svc,这里的svc端口暴露方法有多种。集群内部访问通过8080,外部访问通过30001,流量过来时则是转发到80上
- port
- port是暴露在cluster ip上的端口,port提供了集群内部客户端访问service的一个虚拟ip。可以进入pod后用分配到的这个ip:port
- nodeport
- nodePort 提供了集群外部客户端访问 Service 的一种方式,相当于给每个pod在其对应的主机上开了个访问端口,nodePort 提供了集群外部客户端访问 Service 的端口,通过 nodeIP:nodePort 提供了外部流量访问k8s集群中service的入口。
- targetPort
- targetPort是pod的端口,从port和nodePort来的流量经过kube-proxy流入到后端pod的targetPort上,最后进入容器。
- containerPort
- containerPort是pod内部容器的端口,targetPort映射到containerPort。
apiVersion: v1
kind: Service
metadata:
name: mysvc
spec:
type: NodePort
ports:
- port: 8080
nodePort: 30001
targetPort: 80
selector:
app: web
创建出的svc如下:
首先查看nodepot的情况,把pod中nginx的index.html换了,看看访问30001时到底是哪个pod在提供服务,发现两者交替提供服务(刚开始发现一直是pod2在提供服务,后来想起来是nginx长连接未关闭,关闭后两者正常交替)
再看看port的情况,可以进入其中的一个pod,再去访问port分到的虚拟ip以及8080端口,结果还是两个pod交替提供服务
Ingress
ingress工作原理基本上如图,相当于一个七层全局的反向代理服务
上面的service是通过各种ip加端口的形式访问的服务,但是服务一旦多起来,NodePort 在每个节点上开启的端口会及其庞大,而且难以维护,就有了一种以域名访问的方法,这个ingress就用于实现用域名的方式访问k8s内部应用。那么首先把ingress的包拉下来,官方下载地址国内访问慢,借助小工具下载下来。
下载完成后,还需要进入yml文件中,把image的拉取地址换成国内的,否则拉取缓慢或失败
然后用这个yml创建ingress,报错一大串,
查看错误,是”rbac.authorization.k8s.io/v1beta1″,版本没对上,我的版本是v1,改成了rbac.authorization.k8s.io/v1即可创建成功。
接下来创建两个apache和nginx进行测试
查看pod状态,两个tomcat和nginx都好了
接下来创建ingress来通过域名访问他们,
这个yml就是当访问: test.apache.ingress的时候,将由my-apache的svc处理;当访问:my-nginx时,交给my-nginx的svc来处理,看看创建的这个ingress
去浏览器访问试试,
ingress配置成功。