1、基础知识
1.1、需求
在传统的系统部署中,服务运行在一个固定的已知的 IP 和端口上,如果一个服务需要调用另外一个服 务,可以通过地址直接调用,但是,在虚拟化或容器话的环境中,以我们的k8s集群为例,如果存在个位数个 service我们可以很快的找到对应的clusterip地址,进而找到指定的资源,虽然ip地址不容易记住,因为 service在创建的时候会为每个clusterip分配一个名称,我们同样可以根据这个名称找到对应的服务。但 是,如果我们的集群中有1000个Service,我们如何找到指定的service呢?
尤其是在k8s集群中,服务实例的启动和销毁是很频繁的,服务地址在动态的变化,所以传统的方式配置 DNS解析记录就不太好实现了。所以针对于这种场景,我们如果需要将请求发送到动态变化的服务实例上,可 以通过一下两个步骤来实现: 服务注册 — 创建服务实例后,主动将当前服务实例的信息,存储到一个集中式的服务管理中心。 服务发现 — 当A服务需要找未知的B服务时,先去服务管理中心查找B服务地址,然后根据该地址找到B服务
1.2、服务注册和发现的解决方案
专用于kubernetes集群中的服务注册和发现的解决方案就是KubeDNS。kubeDNS自从k8s诞生以来,其方案 的具体实现样式前后经历了三代,分别是 SkyDNS、KubeDNS、CoreDNS(目前默认的)。 对于k8s的容器环境来说,之前用的是Docker,那么对于docker本身来说,我们可以基于 手工环境变量 + --link参数方式实现有限的发现功能,所以环境变量也是一种服务发现方案。 所以,对于k8s环境来说,它主要有两种服务发现机制: DNS解析 环境变量
2、方案解析
2.1、环境变量类型
2.1.1、Kubernetes Service环境变量
Kubernetes为每个Service资源生成包括以下形式的环境变量在内一系列环境变量,在同一名称空间中创建的Pod对象都会自动拥有这些变量: {SVCNAME}_SERVICE_HOST、{SVCNAME}_SERVICE_PORT 举例:default名称空间,创建名为demoapp的Service,意味着default名称空间下的每个Pod内部会被自动注入 DEMOAPP_SERVICE_HOST:ClusterIP, DEMOAPP_SERVICE_PORT=80 注意:如果先创建pod然后关联到service是不生效的。
2.1.2、Docker Link形式的环境变量
Docker使用--link选项实现容器连接时所设置的环境变量形式,具体使用方式请参考Docker的相关文档。在创建Pod对象时,kubernetes也会把与此形式兼容的一系列环境变量注入到Pod对象中。 由于k8s准备下一个版本禁用dockershim,所以后续的k8s环境中,可能不再支持这种样式了。
2.2、环境变量-实践
2.2.1、创建service环境
cat >service-test.yml<<'EOF' kind: Service apiVersion: v1 metadata: name: service-test spec: selector: app: my-nginx ports: - name: http protocol: TCP port: 80 targetPort: 80 EOF
2.2.2、创建pod对象,通过标签将其添加到service环境
master1 ]# kubectl apply -f service-test.yml service/service-test created master1 ]# kubectl get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 6d17h service-test ClusterIP 10.102.251.155 <none> 80/TCP 2s master1 ~]# kubectl create deployment my-nginx --image=192.168.10.33:80/k8s/pod_test:v0.1 --replicas=3 注意: 必须先创建service,后创建deployment,否则的话,无法演示后面的效果
2.2.3、分析环境变量
master1 ~]# kubectl get pod NAME READY STATUS RESTARTS AGE my-nginx-7c7dc654f6-7kqwf 1/1 Running 0 30s my-nginx-7c7dc654f6-dnmnf 1/1 Running 0 30s my-nginx-7c7dc654f6-qv6mr 1/1 Running 0 30s master1 ~]# kubectl exec my-nginx-7c7dc654f6-qv6mr -- printenv PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin HOSTNAME=my-nginx-7c7dc654f6-qv6mr DEPLOYENV=Production RELEASE=Stable PS1=[\u@\h \w]\$ SERVICE_TEST_PORT=tcp://10.102.251.155:80 SERVICE_TEST_PORT_80_TCP_PORT=80 SERVICE_TEST_PORT_80_TCP_ADDR=10.102.251.155 KUBERNETES_PORT=tcp://10.96.0.1:443 KUBERNETES_PORT_443_TCP_PROTO=tcp KUBERNETES_PORT_443_TCP_PORT=443 KUBERNETES_PORT_443_TCP=tcp://10.96.0.1:443 KUBERNETES_PORT_443_TCP_ADDR=10.96.0.1 SERVICE_TEST_SERVICE_HOST=10.102.251.155 SERVICE_TEST_SERVICE_PORT=80 SERVICE_TEST_PORT_80_TCP=tcp://10.102.251.155:80 SERVICE_TEST_PORT_80_TCP_PROTO=tcp KUBERNETES_SERVICE_HOST=10.96.0.1 KUBERNETES_SERVICE_PORT=443 KUBERNETES_SERVICE_PORT_HTTPS=443 SERVICE_TEST_SERVICE_PORT_HTTP=80 HOME=/root # 在容器内部,可以直接使用变量名来进行服务的访问,访问环境变量. [root@my-nginx-7c7dc654f6-qv6mr /]# curl ${SERVICE_TEST_SERVICE_HOST}:${SERVICE_TEST_SERVICE_PORT} kubernetes pod-test v0.1!! ClientIP: 10.244.3.216, ServerName: my-nginx-7c7dc654f6-7kqwf, ServerIP: 10.244.4.94!
2.2、DNS解析-实践
2.2.1、实现方式
Kubelet会为创建的每一个容器于/etc/resolv.conf配置文件中生成DNS查询客户端依赖到的必要配置, 相关的配置信息源自于kubelet的配置参数,各容器的DNS服务器由clusterDNS参数的值设定,它的取值为 kube-system名称空间中的Service对象kube-dns的ClusterIP,默认为10.96.0.10,而DNS搜索域的 值由clusterDomain参数的值设定,若部署Kubernetes集群时未特别指定,其值将为cluster.local、 svc.cluster.local和NAMESPACENAME.svc.cluster.local,下面的示例取自集群上的一个随机选择的Pod中的容器。 [root@my-nginx-7c7dc654f6-qv6mr /]# cat /etc/resolv.conf search default.svc.cluster.local svc.cluster.local cluster.local nameserver 10.96.0.10 options ndots:5 上述search参数中指定的DNS各搜索域,是以次序指定的几个域名后缀,它们各自的如下所示。 <ns>.svc.<zone>:附带有特定名称空间的域名,例如default.svc.cluster.local; svc. <zone>:附带了Kubernetes标识Service专用子域svc的域名,例如svc.cluster.local; <zone>:集群本地域名,例如cluster.local。 ndots:5,表示:如果手工查询时候给的域名包含的点“.”,不到5个,那么进行DNS查找,将使用非完全限定名称 即 <手工输入域名> 或者 <手工输入域名>.<search 部分给定的域名后缀> 如果你查询的域名包含点数大于等于5,那么DNS查询,默认会使用绝对域名进行查询。 即 <手工输入域名>
2.2.3、基于DNS的服务发现-3个类型的DNS资源记录
基于DNS的服务发现,对于每个Service对象,都会具有以下3个类型的DNS资源记录。 1)、根据ClusterIP的地址类型,为IPv4生成固定格式的 A记录,为IPv6生成AAAA记录; <service>.<ns>.svc.<zone>. <ttl> IN A <cluster-ip> <service>.<ns>.svc.<zone>. <ttl> IN AAAA <cluster-ip> 举例: demoapp, demoapp.default.svc.cluster.local. 注意: cluster.local 是我们在初始化k8s集群中,自己通过dnsDomain属性定制的。 2)、为每个定义了名称的端口生成一个SRV记录,未命名的端口号则不具有该记录; _<port>._<proto>.<service>.<ns>.svc.<zone>. <ttl> IN SRV <weight> <priority> <port-number> <service>.<ns>.svc.<zone>. 3)、对于每个给定的A记录或AAAA记录都要生成PTR记录,它们各自的格式如下所示: <d>.<c>.<b>.<a>.in-addr.arpa. <ttl> IN PTR <service>.<ns>.svc.<zone>. h4.h3.h2.h1.g4.g3.g2.g1.f4.f3.f2.f1.e4.e3.e2.e1.d4.d3.d2.d1.c4.c3.c2.c1.b4.b3.b2 .b1.a4.a3.a2.a1.ip6.arpa <ttl> IN PTR <service>.<ns>.svc.<zone>. 例如,前面在default名称空间中创建Service对象demoapp-svc的地址为10.97.72.1,且为TCP协议的 80端口取名http,对于默认的cluster.local域名来说,此它会拥有如下3个DNS资源记录。 A记录:demoapp-svc.default.svc.cluster.local. 30 IN A 10.97.72.1; SRV记录:_http._tcp.demoapp-svc.default.svc.cluster.local. 30 IN SRV 0 100 80 demoapp-svc.default.svc.cluster.local. PTR记录:1.72.97.10.in-addr.arpa. 30 IN PTR demoappsvc.default.svc.cluster.local.
2.2.4、实践
master1 ~]# kubectl -n kube-system describe svc kube-dns ... Port: dns 53/UDP TargetPort: 53/UDP Endpoints: 10.244.0.12:53,10.244.1.6:53 Port: dns-tcp 53/TCP TargetPort: 53/TCP Endpoints: 10.244.0.12:53,10.244.1.6:53 Port: metrics 9153/TCP TargetPort: 9153/TCP Endpoints: 10.244.0.12:9153,10.244.1.6:9153 ... master1 ~]# kubectl -n kube-system get pod -l k8s-app=kube-dns -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES coredns-75c9cf9bd7-qcwcf 1/1 Running 0 6d17h 10.244.1.6 master2 <none> <none> coredns-75c9cf9bd7-sdsq5 1/1 Running 0 6d17h 10.244.0.12 master1 <none> <none> ------ # pod里面查看相关的配置信息 [root@my-nginx-7c7dc654f6-qv6mr /]# cat /etc/hosts # Kubernetes-managed hosts file. ... 10.244.3.216 my-nginx-7c7dc654f6-qv6mr [root@my-nginx-7c7dc654f6-qv6mr /]# cat /etc/resolv.conf search default.svc.cluster.local svc.cluster.local cluster.local nameserver 10.96.0.10 options ndots:5 [root@my-nginx-7c7dc654f6-qv6mr /]# curl service-test kubernetes pod-test v0.1!! ClientIP: 10.244.3.1, ServerName: my-nginx-7c7dc654f6-qv6mr, ServerIP: 10.244.3.216! [root@my-nginx-7c7dc654f6-qv6mr /]# curl service-test.default.svc.cluster.local kubernetes pod-test v0.1!! ClientIP: 10.244.3.216, ServerName: my-nginx-7c7dc654f6-dnmnf, ServerIP: 10.244.3.215! [root@my-nginx-7c7dc654f6-qv6mr /]# curl service-test.default.svc.cluster.local. kubernetes pod-test v0.1!! ClientIP: 10.244.3.216, ServerName: my-nginx-7c7dc654f6-7kqwf, ServerIP: 10.244.4.94! 注意: 一旦我们将service删除后,就无法正常删除了,
3、DNS记录解析-实践
3.1、正向解析记录
master1 ~]# kubectl exec -it my-nginx-7c7dc654f6-qv6mr -- /bin/sh [root@my-nginx-7c7dc654f6-qv6mr /]# nslookup > service-test.default.svc.cluster.local Server: 10.96.0.10 Address: 10.96.0.10#53 Name: service-test.default.svc.cluster.local Address: 10.102.251.155 > kube-dns.kube-system.svc.cluster.local Server: 10.96.0.10 Address: 10.96.0.10#53 Name: kube-dns.kube-system.svc.cluster.local Address: 10.96.0.10
3.2、反向解析记录
# 反向解析 [root@master1 ~]# kubectl exec -it my-nginx-7c7dc654f6-qv6mr -- /bin/sh [root@my-nginx-7c7dc654f6-qv6mr /]# nslookup > 10.244.3.215 215.3.244.10.in-addr.arpa name = 10-244-3-215.service-test.default.svc.cluster.local. > 10.244.3.216 216.3.244.10.in-addr.arpa name = 10-244-3-216.service-test.default.svc.cluster.local. > 10.244.4.94 94.4.244.10.in-addr.arpa name = 10-244-4-94.service-test.default.svc.cluster.local.
3.3、查询域名的A记录
# 查询域名的A记录,对应SVC IP地址 [root@my-nginx-7c7dc654f6-qv6mr /]# nslookup -query=A service-test.default.svc.cluster.local Server: 10.96.0.10 Address: 10.96.0.10#53 Name: service-test.default.svc.cluster.local Address: 10.102.251.155 master2 ~]# kubectl get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 6d18h service-test ClusterIP 10.102.251.155 <none> 80/TCP 44m
4、CoreDNS配置
4.1、配置解析
4.1.1、查询configmap的coredns
# coredns的配置依然是存放在 configmap master2 ~]# kubectl -n kube-system get cm | grep coredns coredns 1 6d18h
4.1.2、查看coredns配置
# 查询CoreDNS配置 master2 ~]# kubectl -n kube-system describe configmap coredns ... ==== Corefile: ---- .:53 { errors health { # 健康检测 lameduck 5s } ready kubernetes cluster.local in-addr.arpa ip6.arpa { # 解析配置 pods insecure fallthrough in-addr.arpa ip6.arpa ttl 30 } prometheus :9153 forward . /etc/resolv.conf { max_concurrent 1000 # 转发配置,如果集群内部无法解析的话,交由宿主机文件解析 } cache 30 loop reload # 自动加载 loadbalance # dns记录负载 } 对于我们之前所说的企业级的dns解决方案,我们可以通过 forward 来实现,格式如下 forward <域名> <转发后的地址> { # 转发配置,如果集群内部无法解析 的话,交由宿主机文件解析 max_concurrent 最大连接配置 except 排除的域名 } 注意: 如果仅仅对某个域名进行转发的话,只需要将 <域名> 部分设置为指定的域名即可。 生产中不推荐直接将 "." 的转发地址使用公网的dns地址,推荐在当前主机 的/etc/resolv.conf中配置外网,实现间接的效果 # 添加dns解析 hosts { 192.168.8.100 www.example.com fallthrough }
4.2、实践:不使用默认的转发策略,使用自定义的转发策略
4.2.1、编辑coredns配置文件
master1 ~]# kubectl edit configmap coredns -n kube-system ... prometheus :9153 forward . /etc/resolv.conf { max_concurrent 1000 except www.baidu.com. } hosts { 192.168.10.33 harbor.test.com fallthrough } cache 30 ... 注意: 多个dns地址间用空格隔开 排除的域名最好在末尾添加 “.”,对于之前的旧版本来说可能会出现无法保存的现象。
4.2.2、同步dns的配置信息
master1 ~]# kubectl -n kube-system delete pod -l k8s-app=kube-dns
4.2.3、测试自定义DNS解析是否正常
# 删除svc,重新创建 master1 ]# kubectl delete service service-test cat >service-test.yml<<'EOF' kind: Service apiVersion: v1 metadata: name: service-test spec: selector: app: my-nginx ports: - name: http protocol: TCP port: 80 targetPort: 80 EOF kubectl apply -f service-test.yml kubectl create deployment my-nginx --image=192.168.10.33:80/k8s/pod_test:v0.1 --replicas=3 master1 ]# kubectl get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 6d19h service-test ClusterIP 10.104.128.244 <none> 80/TCP 4s [root@master1 service]# kubectl get deployments.apps NAME READY UP-TO-DATE AVAILABLE AGE my-nginx 3/3 3 3 7s master1 ]# kubectl get pod NAME READY STATUS RESTARTS AGE my-nginx-768865db6b-fbpk9 1/1 Running 0 13s my-nginx-768865db6b-lftcm 1/1 Running 0 13s my-nginx-768865db6b-n6mcb 1/1 Running 0 13s # 验证域名配置是否生效 [root@my-nginx-768865db6b-fbpk9 /]# ping www.baidu.com ping: bad address 'www.baidu.com' [root@my-nginx-768865db6b-fbpk9 /]# ping harbor.test.com PING harbor.test.com (192.168.10.33): 56 data bytes 64 bytes from 192.168.10.33: seq=0 ttl=63 time=1.279 ms
5、会话粘滞
5.1、需求
kubernetes的Service功能可以通过多种方式将pod对象提供的服务对外开放,但是当pod多的时候, 用户访问service的时候,service默认是按照轮训的情况进行转发,如果我们的用户请求由一定的会话要 求,即希望同一个客户能访问一个pod的时候,我们可以使用service的affinity机制来实现,它能将同一 个客户端的请求始终转发至同一个后端Pod对象,它是由kube-proxy的ipvs机制来实现的。 默认情况下,service所提供的会话粘性效果默认在10800s(3小时)后会重新调度,而且仅能基于客户端IP进行识别,调度粒度较粗,不推荐使用
5.2、属性解析
5.2.1、属性信息
spec.sessionAffinity,定义粘性会话的类型,可为 None 和 ClientIP spec.sessionAffinityConfig.clientIP,配置会话保持时长,默认10800s 范围 1-86400
5.2.2、配置样式
sessionAffinity: ClientIP sessionAffinityConfig: clientIP: timeoutSeconds: 10800
5.3、默认没有使用会话粘滞
5.3.1、删除原来的配置
# 删除原来的配置 kubectl delete deployments.apps my-nginx kubectl delete service service-test
5.3.2、重新创建service和deployment
# 重新创建service和 deployment cat >service-test.yml<<'EOF' kind: Service apiVersion: v1 metadata: name: service-test spec: selector: app: my-nginx ports: - name: http protocol: TCP port: 80 targetPort: 80 EOF kubectl apply -f service-test.yml kubectl create deployment my-nginx --image=192.168.10.33:80/k8s/pod_test:v0.1 --replicas=3
5.3.3、访问测试
# 可以看到,每次都是不一样的IP地址 master1 ]# for i in {1..3}; do curl 10.104.82.193; done kubernetes pod-test v0.1!! ClientIP: 10.244.0.0, ServerName: my-nginx-5fc6bb8b-7z4fk, ServerIP: 10.244.3.223! kubernetes pod-test v0.1!! ClientIP: 10.244.0.0, ServerName: my-nginx-5fc6bb8b-6mrn2, ServerIP: 10.244.3.222! kubernetes pod-test v0.1!! ClientIP: 10.244.0.0, ServerName: my-nginx-5fc6bb8b-45bdt, ServerIP: 10.244.4.98!
5.4、修改会话配置-实现会话粘滞
5.4.1、定义资源配置清单
cat >nginx-service.yml<<'EOF' apiVersion: v1 kind: Service metadata: name: nginx-service spec: type: LoadBalancer ports: - port: 80 selector: app: my-nginx sessionAffinity: ClientIP EOF
5.4.2、应用资源配置清单
master1 ]# kubectl apply -f nginx-service.yml service/nginx-service created master1 ]# kubectl get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 6d19h nginx-service LoadBalancer 10.101.186.100 <pending> 80:30140/TCP 5s
5.4.3、验证是否生效
master1 ]# kubectl apply -f nginx-service.yml service/nginx-service created master1 ]# kubectl get service NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 6d19h nginx-service ClusterIP 10.101.164.147 <none> 80/TCP 8s master1 ]# for i in {1..3};do curl 10.101.164.147;done kubernetes pod-test v0.1!! ClientIP: 10.244.0.0, ServerName: my-nginx-5fc6bb8b-45bdt, ServerIP: 10.244.4.98! kubernetes pod-test v0.1!! ClientIP: 10.244.0.0, ServerName: my-nginx-5fc6bb8b-45bdt, ServerIP: 10.244.4.98! kubernetes pod-test v0.1!! ClientIP: 10.244.0.0, ServerName: my-nginx-5fc6bb8b-45bdt, ServerIP: 10.244.4.98!
6、无头服务
6.1、需求
到现在为止,我们所遇到的用户访问,用户将请求交给service对象的流程是,kube-proxy其实是将 用户访问的域名解析给了service对象所对应的cluster_ip,然后再由cluster_ip将请求转发给后端的 pod,然后在交给pod内部的容器,这样一个请求经过了两层转发才到容器里面的服务,流程有些繁琐。 目前我们集群的资源调度主要是针对的是无状态的服务,但是对于一些特定场景状态服务,我们虽然可以 基于会话粘滞来实现,但是毕竟需要经过两层跳转,如果转发量太大的话,效果不是太好。 对于某些特殊的负载均衡场景,既然pod有专门的ip地址,那么我可以无需经过cluster_ip,直接定向 到Pod_ip就行了,那么和普通Service相比,这种没有配置ClusterIP项的场景,我们称之为Headless Service。
6.2、简介
无头服务场景下,k8s会将一个集群内部的所有成员提供唯一的DNS域名来作为每个成员的网络标识,集 群内部成员之间使用域名通信,这个时候,就特别依赖service的selector属性配置了。 无头服务管理的域名是如下的格式: $(service_name).$(k8s_namespace).svc.cluster.local。 dns解析记录 A记录 <a>-<b>-<c>-<d>.<service>.<ns>.svc.<zone> A PodIP PodIP的PTR反解析记录 <d>.<c>.<b>.<a>.in-addr.arpa IN PTR <hostname>.<service>.<ns>.svc.<zone>
关键点: svc_name的解析结果从常规Service的ClusterIP,转为各个Pod的IP地址; 反解,则从常规的clusterip解析为service name,转为从podip到hostname, <a>-<b>-<c>-<d>.<service>.<ns>.svc.<zone> <hostname>指的是a-b-c-d格式,而非Pod自己的主机名;
6.3、实践
6.3.1、方法1:命令行的创建
master1 ]# kubectl create service clusterip service-headless-cmd --clusterip="None" service/service-headless created master1 ]# kubectl get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 6d19h service-headless-cmd ClusterIP None <none> <none> 3s
6.3.2、方法2:资源配置清单的创建
cat >service-headless.yml<<'EOF' apiVersion: v1 kind: Service metadata: name: service-headless spec: selector: app: my-nginx clusterIP: "None" EOF kubectl apply -f service-headless.yml master1 ]# kubectl get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 6d19h service-headless ClusterIP None <none> <none> 3s
6.3.3、创建deployment
kubectl create deployment my-nginx --image=192.168.10.33:80/k8s/pod_test:v0.1 --replicas=3
6.3.4、查询定义的service详细信息
master1 ]# kubectl describe service service-headless Name: service-headless Namespace: default Labels: <none> Annotations: <none> Selector: app=my-nginx Type: ClusterIP IP Family Policy: SingleStack IP Families: IPv4 IP: None IPs: None Session Affinity: None Events: <none> master1 ]# kubectl describe ep service-headless Name: service-headless Namespace: default Labels: service.kubernetes.io/headless= Annotations: endpoints.kubernetes.io/last-change-trigger-time: 2023-03-23T07:53:08Z Subsets: Addresses: 10.244.3.224,10.244.3.225,10.244.4.99 NotReadyAddresses: <none> 注意: 有可能因为dns的原因,这里面的无头服务可能无法显示对应的subnets相关的信息,但是不影响无头服 务的正常使用可以正常的进入到pod内部进行测试.
6.3.5、验证是否生效
master1 ]# kubectl exec -it my-nginx-b5fb867f7-dcsr6 -- /bin/sh [root@my-nginx-b5fb867f7-dcsr6 /]# nslookup 10.244.4.99 99.4.244.10.in-addr.arpa name = 10-244-4-99.service-headless.default.svc.cluster.local. master1 ]# kubectl get pods -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES my-nginx-b5fb867f7-dcsr6 1/1 Running 0 107m 10.244.4.99 node2 <none> <none> my-nginx-b5fb867f7-mkp2h 1/1 Running 0 107m 10.244.3.224 node1 <none> <none> my-nginx-b5fb867f7-t9s6t 1/1 Running 0 107m 10.244.3.225 node1 <none> <none> [root@my-nginx-b5fb867f7-dcsr6 /]# nslookup service-headless.default.svc.cluster.local Server: 10.96.0.10 Address: 10.96.0.10#53 Name: service-headless.default.svc.cluster.local Address: 10.244.3.225 Name: service-headless.default.svc.cluster.local Address: 10.244.4.99 Name: service-headless.default.svc.cluster.local Address: 10.244.3.224 结总: 从上面解析结果发现,解析出来的是pod的三个IP地址,说明headless生效,,不是通过ClusterIp中转,直接把请求直接转发到pod地址处理。
6.3.6、注意事项
headless service 在statefulSet资源对象中会重点使用 headless service是一个四层调度,因为iptables/ipvs都是四层的,所以我们如果要建立一个https 服务的话,每一个服务都必须配置一个https的主机,因为四层调度是无法卸载https回话的。
标签:service,会话,28,svc,cluster,nginx,CoreDNS,10.244,my From: https://www.cnblogs.com/ygbh/p/17246974.html