kubernets之服务资源

一  服务集群内部或者客户端与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