k8s service

• Service 本身只是一种配置或定义，存储在控制平面的 etcd 中，而不是在 Node 上运行的程序.

经过前面几节的练习，可能你会有一些疑惑：

为什么 pod 不就绪 (Ready) 的话，kubernetes 不会将流量重定向到该 pod，这是怎么做到的？
前面访问服务的方式是通过 port-forword 将 pod 的端口暴露到本地，不仅需要写对 pod 的名字，一旦 deployment 重新创建新的 pod，pod 名字和 IP 地址也会随之变化，如何保证稳定的访问地址呢？。
如果使用 deployment 部署了多个 Pod 副本，如何做负载均衡呢？

kubernetes 提供了一种名叫 Service 的资源帮助解决这些问题， 它为 pod 提供一个稳定的 Endpoint。Service 位于 pod 的前面， 负责接收请求并将它们传递给它后面的所有pod。 一旦服务中的 Pod 集合发生更改，Endpoints 就会被更新， 请求的重定向自然也会导向最新的 pod。

书写 Service 的yml 文件

apiVersion: v1
kind: Service
metadata:
  name: service-hellok8s-clusterip
spec:
  type: ClusterIP
  selector:
    app: hellok8s
  ports:
  - port: 3000
    targetPort: 3000

• spec.type
• • 通过每个节点上的 IP 和静态端口（NodePort）暴露服务。
• • NodePort 服务会路由到自动创建的 ClusterIP 服务。 通过请求 <节点 IP>:<节点端口>，你可以从集群的外部访问一个 NodePort 服务。

应用 service

kubectl apply -f service.yml

查看 service

kubectl get service

ClusterIP

• 集群内部访问
• 支持负载均衡

NodePort

• 类似暴漏一个固定端口, 基本上用于开发和测试环境
• 在 30000-32767 范围内

LoadBalancer

• 一般是云服务厂商负载均衡

1. K8s创建LoadBalancer Service
    ↓
2. 云厂商Controller检测到请求
    ↓  
3. 自动创建SLB/CLB/ELB实例
    ↓
4. 自动分配公网IP
    ↓
5. 自动配置后端服务器组（K8s节点）
    ↓
6. 自动配置健康检查
    ↓
7. 返回External-IP给K8s

把这个 external-IP 用作域名解析