Kubernetes 实战——发现应用(Service)

  • A+
所属分类:linux技术
摘要

WHY Service测试让同一个 client IP 的请求转发到同一个 Pod服务会话亲和性不能基于 Cookie


一、简介

  • 服务:一种为一组功能相同的 Pod 提供单一不变的接入点的资源。服务 IP 和端口不会改变
  • 对服务的连接会被路由到提供该服务的任意一个 Pod 上(负载均衡
  • 服务通过标签选择器判断哪些 Pod 属于服务

Kubernetes 实战——发现应用(Service)

WHY Service

  • Pod 需要对集群内部其他 Pod 或集群外部客户端 HTTP 请求作出响应
  • Pod 生命周期短,随时启动或关闭。K8s 在 Pod 启动前为其分配 IP 地址,因此客户端不能提前知道 Pod 的 IP 地址
  • 多个 Pod 可能提供相同的服务,因此需要单一的 IP 地址访问

1. 创建服务

kubectl expose ... 
apiVersion: v1 kind: Service metadata:   name: kubia spec:   selector:  # 该服务管理 app=kubia 的 Pod     app: kubia   ports:   - port: 80  # 服务暴露端口     targetPort: 8080  # 服务将连接转发到的容器端口 

测试

# 该服务集群 IP 为 10.111.249.153,只能在集群内部访问 $ kubectl get svc NAME           TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE kubia          ClusterIP   10.111.249.153  <none>        80/TCP    2d16h  # 1. 在 K8s 节点 curl $ curl 10.111.249.153 You've hit kubia-5fje3 # 2. 在运行的 Pod 容器中发送 curl 命令(`--`表示 kubectl 命令的结束,后跟 Pod 内部执行的指令) $ kubectl exec kubia-7nog1 -- curl -s http://10.111.249.153 You've hit kubia-gzwli 

Kubernetes 实战——发现应用(Service)

(1) 服务会话亲和性

让同一个 client IP 的请求转发到同一个 Pod

spec:   sessionAffinity: ClientIP  # 默认 None(仅支持这两种) 

服务会话亲和性不能基于 Cookie

K8s 服务不是在 HTTP 层面上工作。服务处理 TCP 和 UDP 包,并不关心其中的荷载内容。而 cookie 是 HTTP 协议的一部分,服务并不知道它们

会话亲和性和 Web 浏览器

浏览器使用 keep-alive 连接,通过单个连接发送所有请求,而 curl 每次打开一个新连接。服务在连接级别工作,因此当首次与服务连接时会随机,但属于该连接的所有网络数据包全部发送到单个 Pod(即使服务会话亲和性设置为 None),直到连接关闭

(2) 服务暴露多个端口

spec:   ports:   - name: http  # 多个端口的服务必须指定端口名字     port: 80     targetPort: 8080   - name: https     port: 443     targetPort: 8443 

(3) 使用命名的端口(推荐)

kind: Pod spec:   containers:   - name: kubia     ports:     - name: http  # 端口 8080 被命名为 http       containerPort: 8080     - name: https       containerPort: 8443 
kind: Service spec:   ports:   - name: http     port: 80     targetPort: http  # 映射到容器中被称为 http 的端口   - name: https     port: 443     targetPort: https 

2. 服务发现

Pod 获取服务 IP 和端口

(1) 通过环境变量发现服务

Pod 启动时,K8s 会初始化一系列环境变量指向现存的服务。若服务早于 Pod 创建,Pod 进程便可根据环境变量获取服务信息

规则:如名为backend-database的服务会生成BACKEND_DATABASE_SERVICE_HOSTBACKEND_DATABASE_SERVICE_PORT两个环境变量

$ kubectl exec kubia-3inly env KUBIA_SERVICE_HOST=10.111.249.153 KUBIA_SERVICE_PORT=80 ... 

(2) 通过 DNS 发现服务

kube-system 下的 kube-dns Pod 运行 DNS 服务,集群中的其他 Pod 都被配置成使用其作为 dns(K8s 通过修改每个容器的 /etc/resolve.conf 实现)。因此,运行在 Pod 上的进程 DNS 查询都会被 K8s 自身的 DNS 服务器响应,该服务器知道系统中运行的所有服务

Pod 是否使用内部的 DNS 服务器是根据 Pod 中 spec.dnsPolicy 决定

$ kubectl get svc -n kube-system NAME       TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)                  AGE kube-dns   ClusterIP   10.96.0.10   <none>        53/UDP,53/TCP,9153/TCP   3d20h $ kubectl exec kubia-3inly -- cat /etc/resolv.conf nameserver 10.96.0.10 search default.svc.cluster.local svc.cluster.local cluster.local ... 

每个服务从内部 DNS 服务器中获得一个 DNS 条目,客户端 Pod 在知道服务名称的情况下可通过 FQDN(全限定域名)来访问。格式为:<服务名称>.<服务命名空间>.svc.cluster.local。其中svc.cluster.local是在所有集群本地服务名称中使用的可配置集群域后缀

客户端仍需知道服务的端口号。服务可直接使用标准端口号(如 HTTP 的 80 端口或 Postgres 的 5432 端口)或从环境变量中获取端口号

$ kubectl exec -it kubia-3inly bash root@kubia-3inly:/# curl kubia.default.svc.cluster.local You've hit kubia-3inly # 若两个 Pod 在同一个命名空间,可直接使用服务名称 root@kubia-3inly:/# curl kubia You've hit kubia-5asi2 # 服务的集群 IP 为虚拟 IP,且只有与服务端口结合时才有意义 root@kubia-3inly:/# ping kubia 6 packets transmitted, 0 packets received, 100% packet loss 

二、连接集群外部的服务

服务将请求重定向到外部 IP 和端口

1. 服务 Endpoint

  • 服务并不是和 Pod 直接相连,而是通过 Endpoint 资源:暴露一个服务的 IP 地址和端口的列表
  • 服务的 Pod 选择器仅用来构建 IP 和端口列表,存储在 Endpoint 资源中。当客户端连接到服务时,服务代理会选择一个 IP 进行重定向
$ kubectl get endpoints kubia NAME       ENDPOINTS                                          AGE kubia      10.108.1.4:8080,10.108.2.5:8080,10.108.2.6:8080    2h 

2. 手动配置服务的 Endpoint

创建不包含 Pod 选择器的服务将不会创建 Endpoint 资源,此时需要手动创建 Endpoint

apiVersion: v1 kind: Service metadata:   name: external-service spec:  # 没有指定 Pod 选择器   ports:   - port: 80 
apiVersion: v1 kind: Endpoints metadata:   name: external-service  # Endpoint 名称需和服务名称匹配 subsets:   - addresses:  # 服务将连接重定向到 Endpoint 的 IP 地址     - ip: 11.11.11.11     - ip: 22.22.22.22     ports:  # Endpoint 的目标端口     - port: 80 

Kubernetes 实战——发现应用(Service)

3. 为外部服务创建别名

通过 FQDN(完全限定域名)访问外部服务

apiVersion: v1 kind: Service metadata:   name: external-service spec:   type: ExternalName  # 创建一个具有别名的外部服务的服务   externalName: someapi.somecompany.com  # 实际服务的全限定名   ports:   - port: 80 

Pod 通过external-service.default.svc.cluster.local访问外部服务

ExternalName 服务仅在 DNS 级别实施,为服务创建了简单的 CNAME DNS 记录。因此连接到服务的客户端将直接连接到外部服务,完全绕过服务代理。因此该类型服务不会获得集群 IP

CNAME 记录指向完全限定的域名而不是数字 IP 地址

三、将服务暴露给外部客户端

  • 将服务类型设置为 NodePort:每个集群节点打开一个端口,并将在该端口上收到的流量重定向到该服务
  • 将服务类型设置为 LoadBalance:NodePort 类型的一种扩展。服务通过一个专用的负载均衡器来访问,客户端通过负载均衡器的 IP 连接到服务
  • 创建一个 Ingress 资源:通过一个 IP 地址公开多个服务。运行在 HTTP 层(网络协议第七层,而服务运行在第四层)

1. 使用 NodePort 类型的服务

apiVersion: v1 kind: Service metadata:   name: kubia-nodeport spec:   type: NodePort  # 默认 ClusterIP   ports:   - port: 80     targetPort: 8080     nodePort: 30123  # 集群节点端口(不指定则随机)   selector:     app: kubia 

可通过<node-ips>:30123<cluster-ip>:80访问

Kubernetes 实战——发现应用(Service)

2. 使用 LoadBalancer 类型的服务

  • 负载均衡器拥有独一无二的可公开访问的 IP 地址,并将连接重定向到服务(节点无需关闭防火墙)
  • 若 K8s 在不支持 LoadBalancer 服务的环境中运行,则不会调用负载均衡器,此时服务仍表现为 NodePort 服务
spec:   type: LoadBalancer 

可通过<external-ip>:80访问

Kubernetes 实战——发现应用(Service)

3. 了解外部连接的特性

网络跳数

当访问到某个节点的端口,服务随机转发 Pod,此时 Pod 可能不在此节点上,这就需要额外的网络跳转。可将服务配置为仅将外部连接重定向到接收该连接的节点上的 Pod 来阻止跳转:

spec:   externalTrafficPolicy: Local 

缺点:

  • 若无本地 Pod 存在,连接将挂起
  • 会导致 Pod 的负载分布不均衡

Kubernetes 实战——发现应用(Service)

客户端 IP 不会被记录

当通过节点端口接收到连接时,会对数据包进行 SNAT(源网络地址转换),因此数据包的源 IP 将发生更改

Local 外部流量策略会保留客户端 IP,因为接收连接的节点和 Pod 所在节点没有额外跳跃(不执行 SNAT)

四、通过 Ingress 暴露服务

  • 每个 LoadBalancer 服务都需要自己的负载均衡器以及独有的公有 IP,而 Ingress 只需一个公网 IP 便可为多个服务提供访问
  • 客户端发送 HTTP 请求时,Ingress 会根据请求的主机名和路径决定请求转发到的服务
  • Ingress 在网络栈(HTTP)的应用层,可以提供一些服务不能实现的功能。如基于 cookie 的会话亲和性
  • 只有 Ingress 控制器在集群中运行,Ingress 资源才能正常工作。不同的 K8s 环境使用不同的控制器实现,但有些不提供默认控制器

Kubernetes 实战——发现应用(Service)

1. 创建 Ingress 资源

apiVersion: extensions/v1beta1 kind: Ingress metadata:   name: kubia spec:   rules:   # 接收所有请求主机 kubia.example.com 的 HTTP 请求,转发到 kubia-nodeport 的 80 端口   - host: kubia.example.com  # must be a DNS name, not an IP address     http:       paths:       - path: /         backend:           serviceName: kubia-nodeport           servicePort: 80 
$ kubectl get ingress NAME    CLASS    HOSTS               ADDRESS          PORTS   AGE kubia   <none>   kubia.example.com   192.168.99.100   80      14s # 要将域名解析为 Ingress 控制器的 IP $ vi /etc/hosts 192.168.99.100 kubia.example.com $ curl http://kubia.example.com You've hit kubia-5asi2 

2. Ingress 工作原理

Kubernetes 实战——发现应用(Service)

  • 客户端首先对 kubia.example.com 执行 DNS 查找,DNS 服务器(或本地操作系统)返回 Ingress 控制器的 IP
  • 客户端向 Ingress 控制器发送 HTTP 请求,并在 Host 头中指定 kubia.example.com
  • 控制器从该头部确定客户端尝试访问哪个服务,通过与服务关联的 EndPoint 查看 Pod IP,并将请求转发给其中一个 Pod

3. 暴露多个服务

将不同的服务映射到不同主机的不同路径

需要将两个域名都指向 Ingress 控制器的 IP 地址,通过 Host 头判断

spec:   rules:   - host: kubia.example.com     http:       paths:       - path: /kubia         backend:           serviceName: kubia           servicePort: 80       - path: /foo         backend:           serviceName: foo           servicePort: 80   - host: bar.example.com     http:       paths:       - path: /         backend:           serviceName: bar           servicePort: 80 

4. 处理 TLS 传输

  • Ingress 转发 HTTPS 流量
  • 当客户端创建到 Ingress 控制器的 TLS 连接时,客户端和 Ingress 控制器之间的通信是加密的,而控制器和后端 Pod 之间的通信不是
kubectl create secret tls tls-secret --cert=tls.cert --key=tls.key 
kind: Ingress spec:   tls:  # tls 配置   - hosts:  # 接收主机的 tls 连接     - kubia.example.com     serviceName: tls-secret  # 私钥和证书 

五、就绪探针

  • Pod 启动时可能需要加载配置或数据,此时不要将请求转发到这些 Pod,直到准备就绪
  • 就绪探针被定期调用(默认 10s/次),来确定 Pod 是否可以接收客户端请求
  • 启动容器时,可配置一个等待时间,等待后执行第一次就绪检查,之后周期性调用就绪探针
  • 若 Pod 未准备就绪,则从服务中删除该 Pod,就绪后再添加 Pod
  • 只要删除容器,K8s 就会从所有服务中移除该容器,此时无需用就绪探针

类型

  • Exec 探针:由进程的退出状态码确定
  • HTTP GET 探针:向容器发送请求,由响应状态码确定
  • TCP socket 探针:打开一个 TCP 连接到容器的指定端口,由连接是否建立来确定

对比

  • 存活探针通过重启异常容器来保持 Pod 正常工作
  • 就绪探针确保只有准备好的 Pod 才能接收请求

添加就绪探针

apiVersion: v1 kind: ReplicationController metadata:   name: kubia spec:   replicas: 2   template:     metadata:       labels:         app: kubia     spec:       containers:       - name: kubia         image: luksa/kubia         readinessProbe:           exec:             command: ["ls", "/var/ready"]         ports:         - containerPort: 8080 
$ kubectl get pod NAME          READY   STATUS    RESTARTS   AGE kubia-5csgl   0/1     Running   0          2m5s kubia-qj7gz   0/1     Running   0          2m5s $ kubectl exec kubia-5csgl -- touch /var/ready $ kubectl get pod NAME          READY   STATUS    RESTARTS   AGE kubia-5csgl   1/1     Running   0          3m43s kubia-qj7gz   0/1     Running   0          3m43s 

六、headless 服务

创建 headless 服务

apiVersion: v1 kind: Service metadata:   name: kubia-headless spec:   clusterIP: None  # headless   selector:     app: kubia   ports:   - port: 80     targetPort: 8080 

执行 DNS 查找

# 创建可支持 DNS 查找的 Pod $ kubectl run dnsutils --image=tutum/dnsutils --command -- sleep infinity pod/dnsutils created # headless 服务返回的是(就绪的)Pod IP $ kubectl exec dnsutils nslookup kubia-headless ... Name:	kubia-headless.default.svc.cluster.local Address: 10.42.0.20 Name:	kubia-headless.default.svc.cluster.local Address: 10.42.0.19 # 常规服务返回的是 Cluster IP $ kubectl exec dnsutils nslookup kubia ... Name:	kubia.default.svc.cluster.local Address: 10.43.99.228 
  • 客户端也可通过 headless 服务的 DNS 名称直接连接到 Pod
  • headless 服务通过 DNS 轮询机制提供 Pod 的负载均衡,而非服务代理
  • 可通过 DNS 查找机制查找未准备好的 Pod:使用 publishNotReadyAddresses 字段