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

巴特西

kubernets之服务资源

二认识services

三定义service

最新文章

热门文章

巴特西

kubernets之服务资源

二 认识services

三 定义service

最新文章

热门文章

二认识services

三定义service