SRE文档1.Service基本概念
1.1 什么是Service
在Kubernetes中，pod是应用程序的载体，当我们需要访问这个应用时，可以通过Pod的IP进行访问，但是这里有两个问题：
- Pod的IP地址不固定-旦Pod异常退出、节点故障，则会造成Pod发生重建，一旦发生重建客户端则会访问失败；
- Pod如果扩展多份，会造成客户端无法有效使用新增Pod，如果Pod进行缩容又会造成客户端访问错误；
为了解决这个问题，k8s提供了service资源，Service为动态的一组Pod提供一个固定的访问入口；service资源基于标签选择器把筛选出的一组Pod对象定义成一个逻辑组合，而后Service对外提供自己的IP和端口。
当客户端请求Service的IP和端口时，Service将请求调度给标签所匹配的所有Pod，Service向客户端隐藏了真实处理请求的Pod资源，使得客户端的请求看上去是由Service直接处理并进行响应。
Service对象的IP地址（可称为ClusterIP或ServiceIP）是虚拟IP地址，由Kubernetes系统在Service对象创建时在专有网络（ServiceNetwork）地址中自动分配或由用户手动指定。其次Service是基于端口过滤，并根据事先定义好的规则将请求转发至其后端Pod对应的端口上，因此这种代理机制也称为"端口代理"或"四层代理"，工作在TCP/IP协议栈的传输层；
Service的作⽤：
暴露流量：让用户可以通过ServiceIP+ServicePort访问对应后端的Pod应用；
负载均衡：提供基于4层的TCP/IP负载均衡，并不提供HTTP/HTTPS等负载均衡
服务发现：当发现新增Pod则自动加入至Service的后端，如发现Pod异常则自动剔除Service后端；
1.2 Service⼯作逻辑
Service持续监视APIServer，监视Service标签选择器所匹配的后端Pod，并实时跟踪这些Pod对象的变动情况，例如IP地址发生变化、或Pod对象新增与减少。
不过Service并不直接与Pod建立关联关系，它们之间还有一个中间层Endpoints，Endpoints对象是一个由IP地址和端口组成的列表，这些IP地址和端口则来自于Service标签选择器所匹配到的Pod，默认情况下，创建Service资源时，其关联的Endpoints对象会被自动创建。
1.3 Service具体实现
在Kubernetes中，Service只是抽象的一个概念，真正起作用实现负载均衡规则的其实是Kube-Proxy这个进程。它在每个节点上都需要运行一个Kube-Proxy，用来完成负载均衡规则的创建。
1、创建Service资源后，会分配一个随机的ServiceIP，返回给用户，然后写入etcd;
2、ndpoints controller负责生成和维护所有endpoints，它会监听Service和pod的状态，当pod 处于running 且准备就绪时，endpoints controller会将 pod ip 更新到对应Service的 endpoints 对象中，然后写⼊Etcd；
3、be-proxy通过API-Server监听Service、Endpoints的资源变动，一旦Service或Endpoints资源发生变化，Kube-Proxy会将最新的信息转换为对应的IptabLes、IPVS访问规则，而后在本地主机上执行。
4、客户端想要访问Service的时候，其实访问的就是本地节点上的iptabLes、IPVS规则，由它们路由到对应节点;
实现图上的功能，主要需要以下⼏个组件协同⼯作：
1、Service：用户通过kubectl命令向apiServer发送创建Service的请求，APIServer收到后存入Etcd;
2、Endpoints：获取Service所匹配的Pod地址，而后将信息写入与Service同名的endpoints资源中;
3、Kube-Proxy：获取Service和Endpoints资源的变动，而后生成IptabLeS、IPVS规则，在本机执行;
4、ptabLes：当用户请求serviceIP时，使用iptabLes的DNAT技术将ServiceIP的请求调度至endpoint保存ip列表；
2.Kube-Proxy代理模型
2.1 userSpace
userspace模式下，kube-proxy为ServiceIP创建⼀个监听端⼝，当⽤户向ServiceIP发送请求，
1、首先请求会被IptabLes规则拦截，然后重定向到Kube-Proxy对应的端口；
2、然后Kube-Proxy根据调度算法选择挑选一个Pod，将请求调度到该Pod上;
总结：Pod请求ServiceIP时，会被Iptables将请求拦截给⽤户空间的Kube-Proxy，然后再经过内核空间路由到对应的Pod；
问题：该模式流量经过内核空间后，，会送往用户空间Kube-Proxy进程而后又送回内核空间，发往调度分配的目标后端Pod；
2.2 iptables
iptables模式下，kube-proxy为Service后端的所有Pod创建对应的iptabLes规则，当用户向ServiceIP发送请求;
1、首先Iptables会拦截用户请求
2、然后直接将请求调度到后端的Pod;
总结：Pod请求ServiceIP时，IptabLes将请求拦截并且直接完成调度，然后路由到对应的Pod，所以效率比userspace高;
问题：⼀个Service会创建出⼤量的规则，且不⽀持更⾼级的调度算法，当Pod不可⽤也⽆法重试；
2.3 IPVS
ipvs模式和iptables类似，kube-proxy为Service后端所有的Pod创建对应的IPVS规则，一个Service只会生成一条规则，所以规模较大的场景下，应该使用IPVS模式。其次IPVS更多更高级的调度算法。
3.Service资源类型
无论使用那一种代理模型，Service资源都可以其工作逻辑分为ClusterIP，NodePort，LoadBalance、ExternaLName这四种类型
3.1 ClusterIP
ClusterIP：通过集群的内部 IP 暴露服务，选择ServiceIP只能够在集群内部访问。 这也是默认的 ServiceType。
3.2 NodePort
NodePort：NodePort类型是对ClusterIP类型Service资源的扩展。它通过每个节点上的IP和端⼝接⼊集群外部流量，并分发给后端的Pod处理和响应。因此通过<节点IP>:<节点端⼝>，可以从集群外部访问服务。
3.3 LoadBalance
LoadBalancer：这类Service依赖云厂商，需要通过云厂商调用API接口创建软件负载均衡将服务暴露到集群外部。当创建LoadBalance类型的Service对象时，它会在集群上自动创建一个NodePort类型的Service。集群外部的请求流量会先路由至该负载均衡，并由该负载均衡调度至各个节点的NodePort。
3.4 ExternalName
ExternalName：此类型不是用来定义如何访问集群内服务的，而是把集群外部的某些服务以DNS CANME方式映射到集群内，从而让集群内的Pod资源能够访问外部服务的一种实现方式。
4.Service应⽤实践
5.Service与Endpoint
5.1 Endpoint与容器探针
Service对象借助Endpoint资源来跟踪其关联的后端端点，Endpoint对象会根据Service标签选择器筛选出的后端端点的IP地址分别保存在subsets.address字段和subsets.notReadyAddress字段中，它通过APIServer持续、动态跟踪每个端点的状态变化，并及时反应到端点IP所属的字段中。
- subsets.address：保存就绪的容器IP，也就意味着service可以直接将请求调度至该地址段。
- subsets.notReadyAddress：保存未就绪容器IP，也就意味着Service不会将请求调度至该地址段。
案例
1.创建⼀个资源清单，会⾃动创建出同名的Endpoints对象
vi demoapp-readiness.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: demoapp2
spec:
replicas: 2
selector:
matchLabels:
app: web-readiness
template:
metadata:
labels:
app: web-readiness
spec:
containers:
- name: demoapp2
image: registry.cn-zhangjiakou.aliyuncs.com/hsuing/demoapp:v1
ports:
- containerPort: 80
readinessProbe: # 就绪探针
httpGet:
path: '/readyz'
port: 80
initialDelaySeconds: 15 # 初次检测延时时⻓
periodSeconds: 10 # 检测周期
---
apiVersion: v1
kind: Service
metadata:
name: demoapp-readiness-service
spec:
selector:
app: web-readiness
ports:
- protocol: TCP
port: 8888
targetPort: 80apiVersion: apps/v1
kind: Deployment
metadata:
name: demoapp2
spec:
replicas: 2
selector:
matchLabels:
app: web-readiness
template:
metadata:
labels:
app: web-readiness
spec:
containers:
- name: demoapp2
image: registry.cn-zhangjiakou.aliyuncs.com/hsuing/demoapp:v1
ports:
- containerPort: 80
readinessProbe: # 就绪探针
httpGet:
path: '/readyz'
port: 80
initialDelaySeconds: 15 # 初次检测延时时⻓
periodSeconds: 10 # 检测周期
---
apiVersion: v1
kind: Service
metadata:
name: demoapp-readiness-service
spec:
selector:
app: web-readiness
ports:
- protocol: TCP
port: 8888
targetPort: 802.容器初次启动延迟15s，也就意味着⾄少15s以后才能转为就绪状态，对外提供服务
[root@kube-master endpoint]# kubectl get ep demoapp-readiness-service -w
NAME ENDPOINTS AGE
demoapp-readiness-service 172.23.127.120:80,172.30.0.179:80 2m55s[root@kube-master endpoint]# kubectl get ep demoapp-readiness-service -w
NAME ENDPOINTS AGE
demoapp-readiness-service 172.23.127.120:80,172.30.0.179:80 2m55s3.因任何原因导致后端的端点就绪状态监测失败，都会触发Endpoint对象将该端点的IP地址从subset.address字段移至subsets.notReadyAddress字段.
- 模拟⼀个Pod故障
[root@kube-master endpoint]# curl -s -X POST -d 'readyz=Err' 172.23.127.120/readyz
# ⼤约等待30s之后在检查endpoints资源
[root@kube-master endpoint]# kubectl get ep demoapp-readiness-service -w
NAME ENDPOINTS AGE
demoapp-readiness-service 172.23.127.120:80,172.30.0.179:80 4m19s
demoapp-readiness-service 172.30.0.179:80 6m20s
[root@kube-master endpoint]# kubectl describe endpoints demoapp-readiness-service
Name: demoapp-readiness-service
Namespace: default
Labels: <none>
Annotations: endpoints.kubernetes.io/last-change-trigger-time: 2024-05-16T10:12:08Z
Subsets:
Addresses: 172.30.0.179
NotReadyAddresses: 172.23.127.120 # 故障Pod的IP会转⼊NotReadyAddress
Ports:
Name Port Protocol
---- ---- --------
<unset> 80 TCP
Events: <none>[root@kube-master endpoint]# curl -s -X POST -d 'readyz=Err' 172.23.127.120/readyz
# ⼤约等待30s之后在检查endpoints资源
[root@kube-master endpoint]# kubectl get ep demoapp-readiness-service -w
NAME ENDPOINTS AGE
demoapp-readiness-service 172.23.127.120:80,172.30.0.179:80 4m19s
demoapp-readiness-service 172.30.0.179:80 6m20s
[root@kube-master endpoint]# kubectl describe endpoints demoapp-readiness-service
Name: demoapp-readiness-service
Namespace: default
Labels: <none>
Annotations: endpoints.kubernetes.io/last-change-trigger-time: 2024-05-16T10:12:08Z
Subsets:
Addresses: 172.30.0.179
NotReadyAddresses: 172.23.127.120 # 故障Pod的IP会转⼊NotReadyAddress
Ports:
Name Port Protocol
---- ---- --------
<unset> 80 TCP
Events: <none>4.将故障端点重新转为就绪状态后，Endpoints对象会将其移回subsets.address字段，这种处理机制确保了Service对象不会将客户端请求流量调度给那些处于运行状态但服务未就绪的端点。
# 恢复故障
curl -s -X POST -d 'readyz=OK' 172.23.127.120/readyz# 恢复故障
curl -s -X POST -d 'readyz=OK' 172.23.127.120/readyz5.2 ⾃定义endpoint实践
service通过selector和pod建立关联，k8s会根据service关联到的podIP信息组合成一个endpoint。若service定义中没有seLector字段，service被创建时，endpoint controller不会自动创建endpoint.
我们可以通过配置清单创建Service，而无需使用标签选择器，而后自行创建一个同名的endpoint对象，指定对应的IP。这种一般用于将外部MySQL\Redis等应用引l入Kubernetes集群内部，让内部通过Service的方式访问外部资源。
案例
1.准备外部MySQL服务
#安装
yum install mariadb mariadb-server -y
#关闭firewalld
systemctl stop firewalld.service
systemctl disable firewalld.service
#创建远程用户
MariaDB [(none)]> grant all privileges on *.* to 'han' identified by 'han123456' ;
Query OK, 0 rows affected (0.000 sec)
MariaDB [(none)]> flush privileges;
Query OK, 0 rows affected (0.000 sec)
MariaDB [(none)]> exit#安装
yum install mariadb mariadb-server -y
#关闭firewalld
systemctl stop firewalld.service
systemctl disable firewalld.service
#创建远程用户
MariaDB [(none)]> grant all privileges on *.* to 'han' identified by 'han123456' ;
Query OK, 0 rows affected (0.000 sec)
MariaDB [(none)]> flush privileges;
Query OK, 0 rows affected (0.000 sec)
MariaDB [(none)]> exit2.创建Endpoints资源清单
[root@kube-master endpoint]# cat mysql-external-endpoint.yaml
apiVersion: v1
kind: Endpoints
metadata:
name: mysql-external
subsets:
- addresses:
- ip: 10.103.236.199 # 外部宿主机ip，如果有多个ip，继续写 - ip
ports:
- protocol: TCP
port: 3306 # 外部MySQL运⾏的端⼝[root@kube-master endpoint]# cat mysql-external-endpoint.yaml
apiVersion: v1
kind: Endpoints
metadata:
name: mysql-external
subsets:
- addresses:
- ip: 10.103.236.199 # 外部宿主机ip，如果有多个ip，继续写 - ip
ports:
- protocol: TCP
port: 3306 # 外部MySQL运⾏的端⼝- 检查endpoints
[root@kube-master endpoint]# kubectl get endpoints mysql-external
NAME ENDPOINTS AGE
mysql-external 10.103.236.199:3306 63m[root@kube-master endpoint]# kubectl get endpoints mysql-external
NAME ENDPOINTS AGE
mysql-external 10.103.236.199:3306 63m3.创建与endpoint同名的Service资源清单
[root@kube-master endpoint]# cat mysql-external-service.yaml
apiVersion: v1
kind: Service
metadata:
name: mysql-external
spec:
type: ClusterIP
ports:
- port: 13306 # 访问Service的端⼝
targetPort: 3306 # 后端应⽤的端⼝[root@kube-master endpoint]# cat mysql-external-service.yaml
apiVersion: v1
kind: Service
metadata:
name: mysql-external
spec:
type: ClusterIP
ports:
- port: 13306 # 访问Service的端⼝
targetPort: 3306 # 后端应⽤的端⼝- 检查Service
[root@kube-master endpoint]# kubectl describe endpoints mysql-external
Name: mysql-external
Namespace: default
Labels: <none>
Annotations: <none>
Subsets:
Addresses: 10.103.236.199
NotReadyAddresses: <none>
Ports:
Name Port Protocol
---- ---- --------
<unset> 3306 TCP
Events: <none>[root@kube-master endpoint]# kubectl describe endpoints mysql-external
Name: mysql-external
Namespace: default
Labels: <none>
Annotations: <none>
Subsets:
Addresses: 10.103.236.199
NotReadyAddresses: <none>
Ports:
Name Port Protocol
---- ---- --------
<unset> 3306 TCP
Events: <none>4.使⽤Pod访问Service，验证能否正常访问MySQL服务
#通过ServiceIP，或ServiceName（mysql-external）都可以访问到外部数据库
[root@tools /]# mysql -uhan -h 192.168.20.102 -P13306 -phan123456
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 15
Server version: 10.3.39-MariaDB MariaDB Server
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [(none)]> create database hello_service ;
Query OK, 1 row affected (0.01 sec)
MariaDB [(none)]> exit
Bye
[root@tools /]# exit
exit#通过ServiceIP，或ServiceName（mysql-external）都可以访问到外部数据库
[root@tools /]# mysql -uhan -h 192.168.20.102 -P13306 -phan123456
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 15
Server version: 10.3.39-MariaDB MariaDB Server
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [(none)]> create database hello_service ;
Query OK, 1 row affected (0.01 sec)
MariaDB [(none)]> exit
Bye
[root@tools /]# exit
exit6.Service相关字段
6.1 sessionAffinity
如果要将来自于特定客户端的连接调度至同一Pod，可以使用sessionAffinity基于客户端的IP 地址进行会话保持.
还可以通过sessionAffinityConfig.clientIP.timeoutSeconds来设置最大会话停留时间。（默认10800秒，即3小时)
案例
6.2 externalTrafficPolicy
外部流量策略：当外部用户通过NodePort请求Service，是将外部流量路由到本地节点上的Pod，还是路由到集群范围的Pod:
- Cluster（默认）：将用户请求路由到集群范围的所有Pod节点，具有良好的整体负载均衡。
- Local：仅会将流量调度至请求的目标节点本地运行的Pod对象之上，以减少网络跳跃，降低网络延迟，但当请求指向的节点本地不存在目标Service相关的Pod对象时直接丢弃该报文。
案例
6.3 internalTrafficPolicy
本地流量策略：当本地Pod对Service发起访问时，是将流量路由到本地节点上的Pod，还是路由到集群范围的Pod:
- Cluster（默认）：将Pod的请求路由到集群范围的所有Pod节点，具有良好的整体负载均衡
- ocal：将请求路由到与发起方处于相同节点的端点，这种机制有助于节省开销，提升效率。但当请求指向的节点本地不存在目标Service相关的Pod对象时直接丢弃该报文
❌ 注意
注意：在一个Service上，当externalTrafficPolicy已设置为Loca时，internaTrafficPoicy则无法使用。
换句话说，在一个集群的不同Service上可以同时使用这两个特性，但在一个Service 上不行
案例
6.4 publishNotReadyAddresses
publishNotReadyAddresses:表示Pod就绪探针探测失败，也不会将失败的PodIP加入notReadyAddress列表中
案例
7.Service深⼊理解
7.1 Iptables模型分析
ClusterIP 模式分析
NodePort 分析
7.2 IPVS模型分析
8.服务发现
当Pod需要访问Service时，通过Service提供的clusterIP就可以实现了，但是有几个问题；
1、Service的IP不稳定，删除重建会发生变化;
2、ServiceIP难以记忆，如果能通过一个固定的名称访问就好了；
为了解决这样的问题，Kubernetes引l入了环境变量和DNS两种方案来解决这样的问题;
1、环境变量方式：通过特定的名称将环境变量注入到Pod内部；
2、DNS方式：通过APIServer来监视Service变动，而后动态创建对应Service名称与ServiceIP的域名解析记录；
8.1 环境变量
每个Pod启动的时候，会通过环境变量的方式将Service的IP以及Port信息注入进去，这样Pod 中的应用可以通过读取环境变量来获取对应Service服务的地址信息，这种方法使用起来相对简单，但是也存在一定的问题。就是Pod所依赖的Service必须优Pod启动，否则无法注入到环境变量中。
1、创建Service资源
[root@kube-master endpoint]# cat env-service.yaml
apiVersion: v1
kind: Service
metadata:
name: my-env
spec:
ports:
- port: 80
targetPort: 80[root@kube-master endpoint]# cat env-service.yaml
apiVersion: v1
kind: Service
metadata:
name: my-env
spec:
ports:
- port: 80
targetPort: 802、创建容器，然后验证对应的环境变量
[root@kube-master endpoint]# kubectl exec -it pod-env -- /bin/bash
#进入容器执行env
[root@pod-env /]# env
DEMO_SERVICE_PORT_8080_TCP=tcp://192.168.15.149:8080
NGINX_PORT_8080_TCP_PORT=8080
HOSTNAME=pod-env
DEMO_SERVICE_SERVICE_HOST=192.168.15.149
KUBERNETES_PORT_443_TCP_PORT=443
KUBERNETES_PORT=tcp://192.168.0.1:443
TERM=xterm
NGINX_PORT_8080_TCP_ADDR=192.168.253.94
DEMO_SERVICE_PORT_8080_TCP_PORT=8080
NGINX_PORT_8080_TCP_PROTO=tcp
KUBERNETES_SERVICE_PORT=443
KUBERNETES_SERVICE_HOST=192.168.0.1
MY_ENV_SERVICE_HOST=192.168.8.93
DEMO_SERVICE_PORT_8080_TCP_PROTO=tcp
NGINX_SERVICE_HOST=192.168.253.94
MY_ENV_PORT_80_TCP_ADDR=192.168.8.93
NGINX_PORT_8080_TCP=tcp://192.168.253.94:8080
DEMO_SERVICE_PORT=tcp://192.168.15.149:8080
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
PWD=/
NGINX_SERVICE_PORT=8080
MY_ENV_PORT_80_TCP_PROTO=tcp
DEMO_SERVICE_SERVICE_PORT_HTTP=8080
SHLVL=1
HOME=/root
KUBERNETES_PORT_443_TCP_PROTO=tcp
MY_ENV_PORT=tcp://192.168.8.93:80
KUBERNETES_SERVICE_PORT_HTTPS=443
MY_ENV_SERVICE_PORT=80
DEMO_SERVICE_SERVICE_PORT=8080
KUBERNETES_PORT_443_TCP_ADDR=192.168.0.1
MY_ENV_PORT_80_TCP_PORT=80
KUBERNETES_PORT_443_TCP=tcp://192.168.0.1:443
NGINX_PORT=tcp://192.168.253.94:8080
DEMO_SERVICE_PORT_8080_TCP_ADDR=192.168.15.149
MY_ENV_PORT_80_TCP=tcp://192.168.8.93:80
_=/usr/bin/env[root@kube-master endpoint]# kubectl exec -it pod-env -- /bin/bash
#进入容器执行env
[root@pod-env /]# env
DEMO_SERVICE_PORT_8080_TCP=tcp://192.168.15.149:8080
NGINX_PORT_8080_TCP_PORT=8080
HOSTNAME=pod-env
DEMO_SERVICE_SERVICE_HOST=192.168.15.149
KUBERNETES_PORT_443_TCP_PORT=443
KUBERNETES_PORT=tcp://192.168.0.1:443
TERM=xterm
NGINX_PORT_8080_TCP_ADDR=192.168.253.94
DEMO_SERVICE_PORT_8080_TCP_PORT=8080
NGINX_PORT_8080_TCP_PROTO=tcp
KUBERNETES_SERVICE_PORT=443
KUBERNETES_SERVICE_HOST=192.168.0.1
MY_ENV_SERVICE_HOST=192.168.8.93
DEMO_SERVICE_PORT_8080_TCP_PROTO=tcp
NGINX_SERVICE_HOST=192.168.253.94
MY_ENV_PORT_80_TCP_ADDR=192.168.8.93
NGINX_PORT_8080_TCP=tcp://192.168.253.94:8080
DEMO_SERVICE_PORT=tcp://192.168.15.149:8080
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
PWD=/
NGINX_SERVICE_PORT=8080
MY_ENV_PORT_80_TCP_PROTO=tcp
DEMO_SERVICE_SERVICE_PORT_HTTP=8080
SHLVL=1
HOME=/root
KUBERNETES_PORT_443_TCP_PROTO=tcp
MY_ENV_PORT=tcp://192.168.8.93:80
KUBERNETES_SERVICE_PORT_HTTPS=443
MY_ENV_SERVICE_PORT=80
DEMO_SERVICE_SERVICE_PORT=8080
KUBERNETES_PORT_443_TCP_ADDR=192.168.0.1
MY_ENV_PORT_80_TCP_PORT=80
KUBERNETES_PORT_443_TCP=tcp://192.168.0.1:443
NGINX_PORT=tcp://192.168.253.94:8080
DEMO_SERVICE_PORT_8080_TCP_ADDR=192.168.15.149
MY_ENV_PORT_80_TCP=tcp://192.168.8.93:80
_=/usr/bin/env❌ 注意
在使用k8s 配置文件传入变量的时候，需要注意在变量上，整数或者字符串需要使用 单引号或双引号，否则或报错
8.2 CoreDNS
在安装Kubernetes集群时，CoreDNS作为附加组件，用来为Pod提供DNS域名解析。CoreDNS监视 Kubernetes API 中的新Service，并为每个Service名称创建一组DNS记录。这样我们就可以通过固定的Service名称来转换出不固定的ServiceIP
1、了解CoreDNS的配置
[root@kube-master endpoint]# kubectl get configmap coredns -n kube-system -oyaml
apiVersion: v1
data:
Corefile: |
.:53 {
errors # 错误记录
health { # 健康检查
lameduck 5s
}
ready
kubernetes cluster.local in-addr.arpa ip6.arpa { # ⽤于解析Kubernetes集群内域名
pods insecure
fallthrough in-addr.arpa ip6.arpa
ttl 30
}
prometheus :9153 # 监控的端⼝
forward . /etc/resolv.conf { # 如果请求⾮Kubernetes域名，则由节点的resolv.conf中dns解析
max_concurrent 1000
}
cache 30 # 缓存所有内容
loop
reload # ⽀持热更新
loadbalance # 负载均衡，默认轮询
}
kind: ConfigMap
metadata:
creationTimestamp: "2024-04-10T08:32:04Z"
name: coredns
namespace: kube-system
resourceVersion: "239"
uid: 95de04df-4c46-436d-84e1-956c792c0ca9[root@kube-master endpoint]# kubectl get configmap coredns -n kube-system -oyaml
apiVersion: v1
data:
Corefile: |
.:53 {
errors # 错误记录
health { # 健康检查
lameduck 5s
}
ready
kubernetes cluster.local in-addr.arpa ip6.arpa { # ⽤于解析Kubernetes集群内域名
pods insecure
fallthrough in-addr.arpa ip6.arpa
ttl 30
}
prometheus :9153 # 监控的端⼝
forward . /etc/resolv.conf { # 如果请求⾮Kubernetes域名，则由节点的resolv.conf中dns解析
max_concurrent 1000
}
cache 30 # 缓存所有内容
loop
reload # ⽀持热更新
loadbalance # 负载均衡，默认轮询
}
kind: ConfigMap
metadata:
creationTimestamp: "2024-04-10T08:32:04Z"
name: coredns
namespace: kube-system
resourceVersion: "239"
uid: 95de04df-4c46-436d-84e1-956c792c0ca92、CoreDNS只所以是固定的IP以及固定的搜索域。是因为kubeLet将--cluster-dns=<dns-service-ip> 、 --cluster-domain=<default-local-domain>对应的配置传递给了每个容器。
[root@kube-master kubelet]# cat /var/lib/kubelet/config.yaml
....
clusterDNS:
- 192.168.0.10 # DNS的固定ServiceIP
clusterDomain: cluster.local # 域名[root@kube-master kubelet]# cat /var/lib/kubelet/config.yaml
....
clusterDNS:
- 192.168.0.10 # DNS的固定ServiceIP
clusterDomain: cluster.local # 域名3、进⼊任意Pod中，验证/etc/resolv.conf以及域名解析
[root@kube-master kubelet]# kubectl exec -it pod-env -- /bin/bash
[root@pod-env /]#
[root@pod-env /]#
[root@pod-env /]# cat /etc/resolv.conf
nameserver 192.168.0.10
search default.svc.cluster.local svc.cluster.local cluster.local
options ndots:5
# 通过域名解析对应的ServiceIP
[root@pod-env /]# dig @192.168.0.10 demo-service.default.svc.cluster.local +short
192.168.15.149[root@kube-master kubelet]# kubectl exec -it pod-env -- /bin/bash
[root@pod-env /]#
[root@pod-env /]#
[root@pod-env /]# cat /etc/resolv.conf
nameserver 192.168.0.10
search default.svc.cluster.local svc.cluster.local cluster.local
options ndots:5
# 通过域名解析对应的ServiceIP
[root@pod-env /]# dig @192.168.0.10 demo-service.default.svc.cluster.local +short
192.168.15.1498.3 CoreDNS策略
DNS策略可以单独对Pod进行设定，在创建Pod时可以为其指定DNS的策略，最终配置会落在Pod的/etc/resolv.conf文件中，可以通过pod.spec.dnsPolicy字段设置DNS的策略。
1、ClusterFirst（默认DNS策略）
表示Pod内的DNS使用集群中配置的DNS服务，简单来说就是使用Kubernetes中的coredns服务进行域名解析。如果解析不成功，会使用当前Pod所在的宿主机DNS进行解析。
apiVersion: V1
kind: Pod
metadata:
name: dns-test
spec:
dnsPolicy: ClusterFirst
containers:
- name: tools
image: registry.cn-zhangjiakou.aliyuncs.com/hsuing/demoapp:v1
ports:
- containerPort: 80apiVersion: V1
kind: Pod
metadata:
name: dns-test
spec:
dnsPolicy: ClusterFirst
containers:
- name: tools
image: registry.cn-zhangjiakou.aliyuncs.com/hsuing/demoapp:v1
ports:
- containerPort: 802、ClusterFirstWithHostNet
在某些场景下，我们的 Pod 是角HostNetwork 模式启动的，一旦使用HostNetwork模式，那该Pod则会使用当前宿主机的/etc/resoLv.conf来进行 DNS 查询，但如果任然想继续使用Kubernetes 的DNS服务，那就将dnsPolicy设置为ClusterFirstWithHostNet.
apiVersion: v1
kind: Pod
metadata:
name: myapp-pod
spec:
hostNetwork: true # 开启host网络模式
dnsPolicy: ClusterFirstWithHostNet # 如果没配置使⽤当前Pod所在宿主机的DNS
containers:
- name: tools
image: registry.cn-zhangjiakou.aliyuncs.com/hsuing/demoapp:v1
ports:
- containerPort: 8080apiVersion: v1
kind: Pod
metadata:
name: myapp-pod
spec:
hostNetwork: true # 开启host网络模式
dnsPolicy: ClusterFirstWithHostNet # 如果没配置使⽤当前Pod所在宿主机的DNS
containers:
- name: tools
image: registry.cn-zhangjiakou.aliyuncs.com/hsuing/demoapp:v1
ports:
- containerPort: 80803、Default
默认使用宿主机的/etc/resolv.conf但可以使用kubelet 的--resolv-conf=/etc/resolv.conf 来指定DNS解析文件地址。
4、None
空的DNS设置，这种方式一般用于自定义DNS配置的场景，往往需要和dnsConfig一起使用才可以达到自定义DNS的目的。
apiVersion: v1
kind: Pod
metadata:
name: myapp-dns
spec:
containers:
- name: myapp-dns
image: registry.cn-zhangjiakou.aliyuncs.com/hsuing/demoapp:v1
ports:
- containerPort: 8080
dnsPolicy: "None"
dnsConfig:
nameservers:
- 192.168.0.10
- 114.114.114.114
searches:
- cluster.local
- svc.cluster.local
- default.svc.cluster.local
- freehan.ink
options:
- name: ndots
value: "5"apiVersion: v1
kind: Pod
metadata:
name: myapp-dns
spec:
containers:
- name: myapp-dns
image: registry.cn-zhangjiakou.aliyuncs.com/hsuing/demoapp:v1
ports:
- containerPort: 8080
dnsPolicy: "None"
dnsConfig:
nameservers:
- 192.168.0.10
- 114.114.114.114
searches:
- cluster.local
- svc.cluster.local
- default.svc.cluster.local
- freehan.ink
options:
- name: ndots
value: "5"# 检查/etc/resolv.conf配置
kubectl exec -it myapp-dns -- cat /etc/resolv.conf# 检查/etc/resolv.conf配置
kubectl exec -it myapp-dns -- cat /etc/resolv.conf9.HeadLess Service
9.1 什么是HeadLess
HeadlessService也叫无头服务，就是创建的Service没有CLusterIP，而是为Service所匹配的每个Pod都创建一条DNS的解析记录，这样每个Pod都有一个唯一的DNS名称标识身份，访问的格式如下
$(service_name).$(namespace).svc.cluster.local$(service_name).$(namespace).svc.cluster.local
9.2 HeadLess的作⽤
像 elasticsearch，mongodb，kafka 等分布式服务，在做集群初始化时，配置文件中要写上集群中所有节点的IP（或是域名）但Pod是没有固定IP的，所以配置文件里写DNS名称是最合适的。
那为什么不用Service，因为Service 作为 Pod 前置的负载均衡,一般是为一组相同的后端 Pod 提供访问入口，而且Service的selector也没有办法区分同一组Pod的不同身份。
但是我们可以使用Statefulset控制器，它在创建每个Pod的时候，能为每个Pod 做一个编号，就是为了能区分这一组Pod的不同角色，各个节点的角色不会变得混乱，然后再创建 headless service 资源，集群内的节点通过Pod名称+序号.Service名称，来进行彼此间通信的，只要序号不变，访问就不会出错。