k8s-Service - k8s | 方家小白 = 和你一起遇见更好的自己

# 服务 (Service)

# 解决的问题

Pod 是非永久性资源。如果你使用 Deployment 来运行你的应用程序，则它可以动态创建和销毁 Pod。

每个 Pod 都有自己的 IP 地址，但是在 Deployment 中，在同一时刻运行的 Pod 集合可能与稍后运行该应用程序的 Pod 集合不同。

这导致了一个问题：如果一组 Pod （称为 “后端”）为集群内的其他 Pod （称为 “前端”）提供功能，那么前端如何找出并跟踪要连接的 IP 地址，以便前端可以使用提供工作负载的后端部分？

# 定义

Kubernetes Service 定义了这样一种抽象：一个 Pod 的逻辑分组，一种可以访问它们的策略 —— 通常称为微服务。这一组 Pod 能够被 Service 访问到，通常是通过 Label Selector .

Service 能够提供负载均衡的能力，但是在使用上有以下限制：
只提供 4 层负载均衡能力，而没有 7 层功能，但有时我们可能需要更多的匹配规则来转发请求，这点上 4 层负载均衡是不支持的

假设，你有一组 pod , 那如何使用一个 Service 为这组 pod 提供负载均衡的能力呢？刚才说了，通过 Label Selector 选择出符合条件的 Pod . 当请求访问到 Service , 则会请求转到对应的一个 pod 上。还有一种方式就是 非 Label Selector 方式.

# Selector 关联

举一个例子:

假定有一组 Pod，它们对外暴露了 80 端口，同时还被打上 app.kubernetes.io/name=proxy 标签

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    app.kubernetes.io/name: proxy
spec:
  containers:
  - name: nginx
    image: nginx:stable
    ports:
      - containerPort: 80
        name: http-web-svc

然后创建了一个 Service

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app.kubernetes.io/name: proxy
  ports:
  - name: name-of-service-port
    protocol: TCP
    port: 80
    targetPort: http-web-svc

Kubernetes 为该服务分配一个 IP 地址（有时称为 “集群 IP”），该 IP 地址由服务代理使用。服务选择算符的控制器不断扫描与其选择算符匹配的 Pod (即 app.kubernetes.io/name=proxy 的 Pod ) ，然后将所有更新发布到也称为 “my-service” 的 Endpoint 对象。

即使 Service 中使用同一配置名称混合使用多个 Pod ，各 Pod 通过不同的端口号支持相同的网络协议，此功能也可以使用。这为 Service 的部署和演化提供了很大的灵活性。例如，你可以在新版本中更改 Pod 中后端软件公开的端口号，而不会破坏客户端。

# 非 Selector 关联

举个例子:

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376

创建一个 Service . 由于此服务没有选择算符，因此不会自动创建相应的 Endpoints 对象。你可以通过手动添加 Endpoints 对象，将服务手动映射到运行该服务的网络地址和端口：

apiVersion: v1
kind: Endpoints
metadata:
  # 这里的 name 要与 Service 的名字相同
  name: my-service
subsets:
  - addresses:
      - ip: 192.0.2.42
    ports:
      - port: 9376

# Service 可以管理多少个 Endpoint

截止目前 kubernetes v1.22 . 一个 Service 最多管理 1000 个 Pod . 如果某个 Endpoints 资源中包含的端点个数超过 1000 ，则 Kubernetes v1.22 版本（及更新版本）的集群会将为该 Endpoints 添加注解 endpoints.kubernetes.io/over-capacity: truncated 。这一注解表明所影响到的 Endpoints 对象已经超出容量，此外 Endpoints 控制器还会将 Endpoints 对象数量截断到 1000。

# 如何解决

可以使用 EndpointSlices 来解决.

EndpointSlices 是一种 API 资源，可以为 Endpoints 提供更可扩展的替代方案。尽管从概念上讲与 Endpoints 非常相似，但 EndpointSlices 允许跨多个资源分布网络端点。默认情况下，一旦到达 100 个 Endpoint ，该 EndpointSlice 将被视为 “已满”，届时将创建其他 EndpointSlices 来存储任何其他 Endpoints 。

# `Service` 的类型

Service 在 K8s 中有以下五种类型

ClusterIp ：默认类型，自动分配一个仅 Cluster 内部可以访问的虚拟 IP ，这种类型使得 Service 只能从集群内访问。
NodePort ：在 ClusterIP 基础上为 Service 在每台机器上绑定一个端口，这样就可以通过 : NodePort 来访问该服务
LoadBalancer ：在 NodePort 的基础上，借助 cloud provider 创建一个外部负载均衡器，并将请求转发到: NodePort
ExternalName ：把集群外部的服务引入到集群内部来，在集群内部直接使用。没有任何类型代理被创建，这只有 kubernetes 1.7 或更高版本的 kube-dns 才支持
Ingress : Ingress 是对集群中服务的外部访问进行管理的 API 对象，典型的访问方式是 HTTP 。 Ingress 可以提供负载均衡、 SSL 终结和基于名称的虚拟托管。 Ingress 公开从集群外部到集群内服务的 HTTP 和 HTTPS 路由。流量路由由 Ingress 资源上定义的规则控制。

# 代理

# `VIP` 和 `Service` 代理

在 Kubernetes 集群中，每个 Node 运行一个 kube-proxy 进程。 kube-proxy 负责为 Service 实现了一种 VIP(虚拟IP) 的形式，而不是 ExternalName 的形式。在 Kubernetes v1.0 版本，代理完全在 userspace 。在 Kubernetes v1.1 版本，新增了 iptables 代理，但并不是默认的运行模式。从 Kubernetes v1.2 起，默认就是 iptables 代理。在 Kubernetes v1.8.0-beta.0 中，添加了 ipvs 代理在 Kubernetes 1.14 版本开始默认使用 ipvs 代理。在 Kubernetes v1.0 版本， Service 是 “4层” （ TCP/UDP over IP ）概念。在 Kubernetes v1.1 版本，新增了 Ingress API(beta 版) ，用来表示 “7层”(HTTP) 服务

# 代理模式的分类

# `userspace`

kube-proxy 会监视 Kubernetes kubelet 对 Service 对象和 Endpoints 对象的添加和移除操作。对每个 Service ，它会在本地 Node 上打开一个端口（随机选择）。任何连接到 “代理端口” 的请求，都会被代理到 Service 的某个 pod 上。使用哪个后端 Pod ，是 kube-proxy 基于 SessionAffinity 来确定的。

最后，它配置 iptables 规则，捕获到达该 Service 的 clusterIP （是虚拟 IP）和 Port 的请求，并重定向到代理端口，代理端口再代理请求到后端 Pod 。

默认情况下，用户空间模式下的 kube-proxy 通过轮转算法选择后端。

# iptables

这种模式， kube-proxy 会监视 Kubernetes 控制节点对 Service 对象和 Endpoints 对象的添加和移除。对每个 Service ，它会配置 iptables 规则，从而捕获到达该 Service 的 clusterIP 和端口的请求，进而将请求重定向到 Service 的一组后端中的某个 Pod 上面。对于每个 Endpoints 对象，它也会配置 iptables 规则，这个规则会选择一个后端组合。

默认的策略是， kube-proxy 在 iptables 模式下随机选择一个后端。

使用 iptables 处理流量具有较低的系统开销，因为流量由 Linux netfilter 处理，而无需在用户空间和内核空间之间切换。这种方法也可能更可靠。

如果 kube-proxy 在 iptables 模式下运行，并且所选的第一个 Pod 没有响应，则连接失败。这与用户空间模式不同：在这种情况下， kube-proxy 将检测到与第一个 Pod 的连接已失败，并会自动使用其他后端 Pod 重试。

你可以使用 Pod 就绪探测器验证后端 Pod 可以正常工作，以便 iptables 模式下的 kube-proxy 仅看到测试正常的后端。这样做意味着你避免将流量通过 kube-proxy 发送到已知已失败的 Pod

# ipvs

这种模式， kube-proxy 会监视 Kubernetes Service 对象和 Endpoints ，调用 netlink 接口以相应地创建 ipvs 规则并定期与 Kubernetes Service 对象和 Endpoints 对象同步 ipvs 规则，以确保 ipvs 状态与期望一致。访问服务时，流量将被重定向到其中一个后端 Pod . 与 iptables 类似， ipvs 于 netﬁlter 的 hook 功能，但使用哈希表作为底层数据结构并在内核空间中工作。这意味着 ipvs 可以更快地重定向流量，并且在同步代理规则时具有更好的性能。此外， ipvs 为负载均衡算法提供了更多选项，例如：

rr ：轮询调度
lc ：最小连接数
dh ：目标哈希
sh ：源哈希
sed ：最短期望延迟
nq ：不排队调度

# Service 类型实验

# `ClusterIP`

clusterIP 主要在每个 node 节点使用 iptables 等代理方式，将发向 clusterIP 对应端口的数据，转发到 kube-proxy 中。然后 kube-proxy 自己内部实现有负载均衡的方法，并可以查询到这个 service 下对应 pod 的地址和端口，进而把数据转发给对应的 pod 的地址和端口。这种类型使得 Service 只能从集群内访问。

为了实现图上的功能，主要需要以下几个组件的协同工作：

apiserver 用户通过 kubectl 命令向 apiserver 发送创建 service 的命令， apiserver 接收到请求后将数据存储到 etcd 中
kube-proxy kubernetes 的每个节点中都有一个叫做 kube-porxy 的进程，这个进程负责感知 service ， pod 的变化，并将变化的信息写入本地的 iptables 规则中.
iptables 使用 NAT 等技术将 virtualIP 的流量转至 endpoint 中

# 创建一个 deploy

apiVersion: apps/v1
kind: Deployment
metadata:
  name: cluster-ip-demo
spec:
  replicas: 3
  selector:
    matchLabels:
      app: cluster-ip-demo
      tag: cluster-ip-v1
  template:
    metadata:
      labels:
        app: cluster-ip-demo
        tag: cluster-ip-v1
        env: test
    spec:
      containers:
      - name: cluster-ip-demo-container
        image: fangjiaxiaobai/my-app:v3
        imagePullPolicy: IfNotPresent
        ports:
        - name: http
          containerPort: 80
        env:
        - name: "MY_APP_VERSION"
          value: "3.0"

# 把 `Deploymenet` 绑定到 `Service` 上

apiVersion: v1
kind: Service
metadata:
  name: service-cluster-ip-demo
spec:
  type: ClusterIP
  selector:
    app: cluster-ip-demo
    tag: cluster-ip-v1
  ports:
  - name: http
    port: 80
    targetPort: 80

# `Headless Service`

有时不需要或不想要负载均衡 sc 以及单独的 Service IP 。遇到这种情况，可以通过指定 Cluster IP(spec.clusterIP) 的值为 “None” 来创建 Headless Service 。这类 Service 并不会分配 Cluster IP ， kube-proxy 不会处理它们，而且平台也不会为它们进行负载均衡和路由

apiVersion: v1
kind: Service
metadata:
  name: headless-service
  namespace: default
spec:
  selector:
    app: headless-app
    clusterIp: "None"
  ports:
  - port: 80
    targetPort: 80

使用 dig 命令可以验证一下

1	dig -t A headless-service.default.svc.cluster.local. @10.96.0.10

# `NodePort`

nodePort 的原理在于在 node 上开了一个端口，将向该端口的流量导入到 kube-proxy ，然后由 kube-proxy 进一步到给对应的 pod

# 创建 `Deployment`

apiVersion: apps/v1
kind: Deployment
metadata:
  name: node-port-container-demo
spec:
  replicas: 3
  selector:
    matchLabels:
      app: node-port-service
      tag: node-port-tag-v3
  template:
    metadata:
      labels:
        app: node-port-service
        tag: node-port-tag-v3
        env: test
    spec:
      containers:
      - name: cluster-ip-demo-container
        image: fangjiaxiaobai/my-app:v3
        imagePullPolicy: IfNotPresent
        ports:
        - name: http
          containerPort: 80
        env:
        - name: "MY_APP_VERSION"
          value: "3.0"

# 绑定到 `Service` 上。

apiVersion: v1
kind: Service
metadata:
  name: node-port-service
  namespace: default
spec:
  type: NodePort
  selector:
    app: node-port-service
    tag: node-port-tag-v3
    env: test
  ports:
  - name: http
    port: 80
    targetPort: 80

可以在浏览器上访问 Node 的 IP ( http://192.168.0.10:31024/ ), 多次访问查看 hostname 和 ip 的变化.

# `LoadBalancer`

loadBalancer 和 nodePort 其实是同一种方式。区别在于 loadBalancer 比 nodePort 多了一步，就是可以调用 cloud provider 去创建 LB 来向节点导流.

# `ExternalName`

这种类型的 Service 通过返回 CNAME 和它的值，可以将服务映射到 externalName 字段的内容 ( 例如：
hub.atguigu.com )。 ExternalName Service 是 Service 的特例，它没有 selector ，也没有定义任何的端口和 Endpoint 。相反的，对于运行在集群外部的服务，它通过返回该外部服务的别名这种方式来提供服务

apiVersion: v1
kind: Service
metadata:
  name: external-name-service
  namespace: default
spec:
  type: ExternalName
  externalName: www.fangjiaxiaobai.cn

当查询主机 my-service.defalut.svc.cluster.local ( SVC_NAME.NAMESPACE.svc.cluster.local ) 时，集群的 DNS 服务将返回一个值 my.database.example.com 的 CNAME 记录。访问这个服务的工作方式和其他的相同，唯一不同的是重定向发生在 DNS 层，而且不会进行代理或转发

下一篇，我们介绍另外一种资源控制器 Ingress .

# 最后

希望和你一起遇见更好的自己

# 服务 (Service)

# 解决的问题

# 定义

# Selector 关联

# 非 Selector 关联

# Service 可以管理多少个 Endpoint

# 如何解决

# Service 的类型

# 代理

# VIP 和 Service 代理

# 代理模式的分类

# userspace

# iptables

# ipvs

# Service 类型实验

# ClusterIP

# 创建一个 deploy

# 把 Deploymenet 绑定到 Service 上

# Headless Service

# NodePort

# 创建 Deployment

# 绑定到 Service 上。

# LoadBalancer

# ExternalName