深入理解Service

Service 存在的意义

• 防止Pod失联（服务发现）

• 定义一组Pod的访问策略（负载均衡）

Pod与Service的关系

• 通过label-selector相关联

• 通过Service实现Pod的负载均衡（ TCP/UDP 4层）

Service三种类型

ClusterIP：

分配一个内部集群IP地址，只能在集群内部访问（同Namespace内的Pod），默认ServiceType。 ClusterIP 模式的 Service 为你提供的，就是一个 Pod 的稳定的 IP 地址，即 VIP。

web-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: web
  name: web
spec:
  replicas: 1
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - image: nginx
        name: nginx

service-clusterip.yaml

apiVersion: v1
kind: Service
metadata:
  labels: 
    app: web
  name: web
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: web

如果不指定type 默认创建的是 ClusterIp

clusterip 类型只能在集群内部访问在node节点 curl 10.0.0.169:80

NodePort：

分配一个内部集群IP地址，并在每个节点上启用一个端口来暴露服务，可以在集群外部访问。访问地址：<NodeIp>:<NodePort>

apiVersion: v1
kind: Service
metadata:
  labels:
    app: web
  name: web
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
    nodePort: 30008    #如果nodePort未指定将随机分配一个端口范围30000-32767
  selector:
    app: web
  type: NodePort

nodeport的默认范围30000-32767，如果需要修改这个范围

比如像把端口范围改成1-65535，则在apiserver的启动命令里面添加如下参数：

–service-node-port-range=1-65535

curl k8s-node1:30008

通过nodeport暴露服务可以在集群外部访问,nodeport类型会在每个node上开启对应的端口（30008）服务

需要注意的问题：

指定的port 首先不能被占用。

如果某个node挂了，前端访问时却不能感知，导致访问落空，node挂了没法通知到前端，这时候假如有个lb来记录可用的后端服务，这样才显得灵活，传统使用 nginx haproxy lvs 来充当这样的lb，但是每次需要手动更新后端可用节点ip和端口。

如果采用公有云的loadbalancer ，每次创建新的service会自动调用loadbalancer的api更新后端的<nodeip>:<nodeport>

LoadBalancer：

分配一个内部集群IP地址，并在每个节点上启用一个端口来暴露服务。除此之外，Kubernetes会请求底层云平台上的负载均衡器，将每个Node（[NodeIP]:[NodePort]）作为后端添加进去。

Service代理模式

默认启用的时 iptables 来创建转发规则。

ipvs转发性能明显优于iptables，但是iptables是kubernetes默认的转发工具比较稳定可靠。

修改默认转发工具为ipvs

查看是否加载ipvs模块

集群内所有节点都需要加载

lsmod |grep ip_vs  #如果没有返回 需要加载以下模块
modprobe -- ip_vs
modprobe -- ip_vs_rr
modprobe -- ip_vs_wrr
modprobe -- ip_vs_sh
modprobe -- nf_conntrack_ipv4

kubeadmin方式部署（ipvs）

kube-proxy的配置是保存在一个configmap中

kubectl edit configmap kube-proxy -n kube-system

找到 mode 字段，默认是为空的，为空的时候使用iptables，此时将mode字段对应的值改为ipvs

mode:"ipvs"

重启kube-proxy pod 方能生效

kubectl delete pod kube-proxy-xxx -n kube-system

二进制部署方式 (ipvs)

修改kube-proxy配置文件指定模式为ipvs

重启kube-proxy服务才能生效

systemctl restart kube-proxy

验证

在node节点安装 ipvsadm 工具

yum install ipvsadm -y

通过 10.0.0.203 这个ip的80端口来转发到后端的服务，后端的服务为这个service的endpoint

此时 curl 10.0.0.203:80 相当于请求了这个endpoint 10.244.0.31:80

如果pod 重建了 endpoint 发生变化，ipvs能自动更新后端的 server 嘛？

当我们重建pod后 endpoint 由 10.244.0.31:80 变成 10.244.1.43:80, ipvs自动更新了后端的server

Iptables VS IPVS 对比

Iptables：

• 灵活，功能强大

• 规则遍历匹配和更新，呈线性时延

• 可扩展性

IPVS：

• 工作在内核态，有更好的性能

• 调度算法丰富：rr，wrr，lc，wlc，ip hash...

Service DNS名称

DNS服务监视Kubernetes API，为每一个Service创建DNS记录用于域名解析。

ClusterIP A记录格式：<service-name>.<namespace-name>.svc.cluster.local 示例：my-svc.my-namespace.svc.cluster.local

k8s默认使用coredns 用来集群内部域名解析，将service的名称和 clusterip 做一个A记录

创建一个测试pod

nslookup.yaml

apiVersion: v1
kind: Pod
metadata:
  labels:
    run: busybox 
  name: dns-test
  namespace: default
spec:
  containers:
  - image: busybox:1.28.4
    name: b1
    command:
      - "ping"
      - "baidu.com"