一、Service

1、Service的作用

Service将运行在一组 Pods 上的应用程序公开为网络服务的抽象方法

2、Service应用场景

由于 Pod 是非永久性资源，如果是使用 Deployment 来管理应用程序，那么 Pod 会被动态的创建和销毁。这导致了一个问题：如果一组Pod（后端服务）为集群内的其他 Pod （前端服务）提供功能，那么如果前端使用通过ip方式来寻找 后端Pod。由于后端Pod的ip动态变化，这就造成了服务不通或者需要频繁修改前端Pod中后端Pod 的ip地址。Service可以解决这个问题

没有引入Service.png 引入Service.png

二、无Selector的Service

1、创建一个无 Selector Service

apiVersion: v1
kind: Service
metadata:
  name: noselector-service
  namespace: raven
spec:
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80

无 Selector Service.png

2、提供3个Nginx Pod

3个Nginx Pod.png

3、还原 前端Pod 访问 后端Pod 的场景

测试pod.png

• 通过测试pod访问192.169.154.225

  
  curl 192.169.154.225.png

• 通过测试pod访问192.169.154.229

  
  curl 192.169.154.229.png

• 通过测试pod访问192.169.154.213

  
  curl 192.169.154.213.png

• 删除deployment-nginx-raven-7849c96969-fwvj7（192.169.154.229），发现虚拟ip和Pod名称都已改变，所以通过虚拟ip方式是不科学的

kubectl delete pod deployment-nginx-raven-7849c96969-fwvj7 -n raven

image.png

4、Service 和 Pod

到目前为止，Service 和 Pod 还没有任何关系，Service 并没有管理起来 Pod。为了让Service和Pod产生管理需要引入Endpoint这种资源

Endpoints

apiVersion: v1
kind: Endpoints
metadata:
  name: noselector-service
  namespace: raven
subsets:
- addresses:
  - ip: 192.169.154.225
  - ip: 192.169.154.239
  - ip: 192.169.154.213
  ports:
  - port: 80

• 在Endpoints中配置addresses（需要被管理的Pod的虚拟ip）

5、Service 、Endpoints 和 Pod之间关系 Service 、Endpoints 和 Pod.png

小结

• Service的metadata.name与Endpoints的metadata.name必须相同
• 这样依然无法保存存起的 Pod 会自动加入到 Endpoints，所以无法满足负载均衡
• Service和Endpoints中ports中不能有name字段 image.png