完全限定域名（Kubernetes）

一、简介#服务：一种为一组功能相同的 Pod 提供单一不变的接入点的资源。服务 IP 和端口不会改变对服务的连接会被路由到提供该服务的任意一个 Pod 上（负载均衡）服务通过标签选择器判断哪些 Pod 属于服务WHY ServicePod 需要对集群内部其他 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
(1) 服务会话亲和性#让同一个 client IP 的请求转发到同一个 Podspec:
sessionAffinity: ClientIP # 默认 None（仅支持这两种）
服务会话亲和性不能基于 CookieK8s 服务不是在 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_HOST和BACKEND_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 资源，此时需要手动创建 EndpointapiVersion: 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
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 记录。因此连接到服务的客户端将直接连接到外部服务，完全绕过服务代理。因此该类型服务不会获得集群 IPCNAME 记录指向完全限定的域名而不是数字 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访问2. 使用 LoadBalancer 类型的服务#负载均衡器拥有独一无二的可公开访问的 IP 地址，并将连接重定向到服务（节点无需关闭防火墙）若 K8s 在不支持 LoadBalancer 服务的环境中运行，则不会调用负载均衡器，此时服务仍表现为 NodePort 服务spec:
type: LoadBalancer
可通过<external-ip>:80访问3. 了解外部连接的特性#网络跳数当访问到某个节点的端口，服务随机转发 Pod，此时 Pod 可能不在此节点上，这就需要额外的网络跳转。可将服务配置为仅将外部连接重定向到接收该连接的节点上的 Pod 来阻止跳转：spec:
externalTrafficPolicy: Local
缺点：若无本地 Pod 存在，连接将挂起会导致 Pod 的负载分布不均衡客户端 IP 不会被记录当通过节点端口接收到连接时，会对数据包进行 SNAT（源网络地址转换），因此数据包的源 IP 将发生更改Local 外部流量策略会保留客户端 IP，因为接收连接的节点和 Pod 所在节点没有额外跳跃（不执行 SNAT）四、通过 Ingress 暴露服务#每个 LoadBalancer 服务都需要自己的负载均衡器以及独有的公有 IP，而 Ingress 只需一个公网 IP 便可为多个服务提供访问客户端发送 HTTP 请求时，Ingress 会根据请求的主机名和路径决定请求转发到的服务Ingress 在网络栈（HTTP）的应用层，可以提供一些服务不能实现的功能。如基于 cookie 的会话亲和性只有 Ingress 控制器在集群中运行，Ingress 资源才能正常工作。不同的 K8s 环境使用不同的控制器实现，但有些不提供默认控制器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 工作原理#客户端首先对 kubia.example.com 执行 DNS 查找，DNS 服务器（或本地操作系统）返回 Ingress 控制器的 IP客户端向 Ingress 控制器发送 HTTP 请求，并在 Host 图中指定 kubia.example.com控制器从该头部确定客户端尝试访问哪个服务，通过与服务关联的 EndPoint 查看 Pod IP，并将请求转发给其中一个 Pod3. 暴露多个服务#将不同的服务映射到不同主机的不同路径需要将两个域名都指向 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 名称直接连接到 Podheadless 服务通过 DNS 轮询机制提供 Pod 的负载均衡，而非服务代理可通过 DNS 查找机制查找未准备好的 Pod：使用 publishNotReadyAddresses 字段