一 服务集群内部或者客户端与pod的通信桥梁
kubernets集群的内部pod访问为啥不能使用传统的IP:PORT的形式？
-
- pod是短暂的，它们会随时启动或者关闭，原因可能是pod所在的节点下线了，或者管控者RC，RS，DS，JOB，CronJob等的移除
- pod的IP在调度前才会分配IP，因此客户端无法提前预知到pod的IP地址
- pod的水平伸缩性，预示这，客户端无需关注pod的ip，相反所有的pod都应该通过一个唯一并且固定的IP进行访问才能符合pod的这一特性
二 认识services
结合以上所述场景，kubernets提供了一种servier的资源，services拥有一个固定的IP以及端口，客户端通过这个端口来访问services管理下面的pod
即使管理的pod由于节点下线，或者管控器的缩放导致pod的数量增加或者减少(减少后的数量始终应该大于等于1)，客户端仍然可以通过services的IP以及端口
来访问剩下的pod所提供的服务，而无需管理pod的实际IP，同时也实现了负载均衡的作用
三 定义service
3.1 在定义service之前我们可以先创建包含三个pod的RC，RC通过标签来组织管理pod，同样的svc也是通过标签来为pod提供统一IP和端口暴露
3.1.1 RC以及SVC的定义文件展示
RC的文件展示
apiVersion: v1 kind: ReplicationController metadata: name: kubia spec: replicas: 3 selector: app: kubia template: metadata: labels: app: kubia spec: containers: - name: kubia image: luksa/kubia ports: - containerPort: 8080
SVC的文件定义展示
apiVersion: v1 kind: Service metadata: name: kubia spec:
sessionAffnity: ClientIp ports: - port: 80 targetPort: 8080 selector: app: kubia
sessionAffnity这个参数添加的话可以让每次同一个client访问的pod都是同一个，称之为svc的会话亲和性
3.2 创建RC以及SVC的结果显示
[root@node01 Chapter05]# k get po NAME READY STATUS RESTARTS AGE kubia-c8fnf 1/1 Running 0 10m kubia-k4fkm 1/1 Running 0 10m kubia-kr6bc 1/1 Running 0 10m [root@node01 Chapter05]# k describe svc kubia Name: kubia Namespace: default Labels: <none> Annotations: <none> Selector: app=kubia Type: ClusterIP IP Families: <none> IP: 10.109.29.64 IPs: <none> Port: <unset> 80/TCP TargetPort: 8080/TCP Endpoints: 10.244.1.47:8080,10.244.2.42:8080,10.244.2.43:8080
3.3 验证能否通过服务的唯一IP:PORT来访问刚才创建的pod
[root@node01 Chapter05]# k get po NAME READY STATUS RESTARTS AGE kubia-c8fnf 1/1 Running 0 138m kubia-k4fkm 1/1 Running 0 138m kubia-kr6bc 1/1 Running 0 138m [root@node01 Chapter05]# k get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 3d2h kubia ClusterIP 10.109.29.64 <none> 80/TCP 133m
[root@node01 Chapter05]# k exec kubia-c8fnf -- curl -s http://10.109.29.64 You've hit kubia-k4fkm
[root@node01 Chapter05]# k exec kubia-c8fnf -- curl -s http://10.109.29.64 You've hit kubia-c8fnf
[root@node01 Chapter05]# k exec kubia-c8fnf -- curl -s http://10.109.29.64 You've hit kubia-kr6bc
[root@node01 Chapter05]# k exec kubia-c8fnf -- curl -s http://10.109.29.64 You've hit kubia-k4fkm
通过在节点上面以其中之一的pod里面访问服务暴露出来的ip:port能够访问到服务关联的pod里面的应用，并且每次都是随机的去访问pod的应用
3.4 上面的例子可以很好的说明了对于pod内部的应用是单端口的情况下的访问情况，但是如果pod内部的应用属于两个或两个以上的端口呢？kubernets提供了什么解决方案
下面看这个双端口的pod是如何被服务映射出来的
apiVersion: v1 kind: Service metadata: name: kubia spec: ports: - port: 80 targetPort: 8080 - port: 443 targetPort: 8443 selector: app: kubia
没错，正如你所见，只需要单纯的在spce.ports里面添加pod需要映射出来的端口，是不是很简单？
3.5 另外kubernets还支持使用别名的形式来命名pod里面需要映射的端口号，这么做的好处显而易见，就是在pod修改端口号的时候，由于svc里面只是引用端口的别名，所有svc不需要
更改也能正确的映射出pod修改后的端口号
现在分别对pod和svc的配置文件列出来作出说明
pod
kind: Pod spec: containers: - name: kubia ports: - name: http containerPort: 8080 - name: https containerPort: 8443
svc
kind: Service spec: ports: - name: http port: 80 targetPort: http - name: https port: 443 targetPort: https