kubernetes负载均衡-service

一、service的概念

1、什么是service

  • 在Kubernetes中,pod是应用程序的载体,当我们需要访问这个应用时,可以通过Pod的IP进行访问,但是这里有两个问题:
  • 1、Pod的IP地址不固定,一旦Pod异常退出、节点故障,则会造成Pod发生重建,一旦发生重建客户端则会访问失败;
  • 2、Pod如果扩展多份,会造成客户端无法有效使用新增Pod,如果Pod进行缩容又会造成客户端访问错误;

为了解决以上问题,kubernetes引入了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协议栈的传输层;

2、service的作用

  • 暴露流量:让用户可以通过ServiceIP+ServicePort访问对应后端的Pod应用;
  • 负载均衡:提供基于4层的TCP/IP负载均衡,并不提供HTTP/HTTPS等负载均衡;
  • 服务发现:当发现新增Pod则自动加入至Service的后端,如发现Pod异常则自动剔除Service后端;

3、service的工作逻辑

Service持续监视APIServer,监视Service标签选择器所匹配的后端Pod,并实时跟踪这些Pod对象的变动情况,例如IP地址发生变化、或Pod对象新增与减少

不过Service并不直接与Pod建立关联关系,它们之间还有一个中间层Endpoints,Endpoints对象是一个由IP地址和端口组成的列表,这些IP地址和端口则来自于Service标签选择器所匹配到的Pod,默认情况下,创建Service资源时,其关联的Endpoints对象会被自动创建。

4、service的具体实现

在Kubernetes中,Service只是抽象的一个概念,真正起作用实现负载均衡规则的其实是Kube-Proxy这个进程。它在每个节点上都需要运行一个Kube-Proxy,用来完成负载均衡规则的创建。

  • 1、创建Service资源后,会分配一个随机的ServiceIP,返回给用户,然后写入etcd;
  • 2、endpoints controller负责生成和维护所有endpoints,它会监听Service和pod的状态,当 pod处于running 且准备就绪时,endpoints controller会将 podip 更新到对应Service的 endpoints 对象中,然后写入Etcd;
  • 3、kube-proxy通过API-Server监听Service、Endpoints的资源变动,-旦Service或Endpoints资源发生变化,Kube-Proxy会将最新的信息转换为对应的Iptables、IPVS访问规则,而后在本地主机上执行。
  • 4、当客户端想要访问Service的时候,其实访问的就是本地节点上的iptables、IPVS规则,由它们路由到对应节点;

5、service的实现主要协调主件

  • Service:用户通过kubectl命令向apiServer发送创建Service的请求,APIServer收到后存入Etcd;
  • Endpoints:获取Service所匹配的Pod地址,而后将信息写入与Service同名的endpoints资源中;
  • Kube-Proxy:获取Service和Endpoints资源的变动,而后生成Iptables、IPVS规则,在本机执行;
  • Iptables:当用户请求serviceIP时,使用iptables的DNAT技术将ServiceIP的请求调度至endpoint保存ip列表;

6、Kube-Proxy代理模式

6.1、 userSpace(目前这种规则已经被废弃)

userspace模式下,kube-proxy为ServiceIP创建一个监听端口,当用户向ServiceIP发送请求,

  • 1、首先请求会被Iptables规则拦截,然后重定向到Kube-Proxy对应的端口;
  • 2、然后Kube-Proxy根据调度算法选择挑选一个Pod,将请求调度到该Pod上;
    总结:Pod请求ServiceIP时,会被Iptables将请求拦截给用户空间的Kube-Proxy,然后再经过内核空间路由到对应的Pod;

6.2 、Iptables模式

iptables模式下,kube-proxy为Service后端的所有Pod创建对应的iptables规则,当用户向ServiceIP发送请求;

  • 1、首先Iptables会拦截用户请求:
  • 2、然后直接将请求调度到后端的Pod;

总结:Pod请求ServiceIP时,Iptables将请求拦截并且直接完成调度,然后路由到对应的Pod,所以效率比userspace高;

问题:-个Service会创建出大量的规则,且不支持更高级的调度算法当Pod不可用也无法重试;

6.3、 IPVS

ipvs模式和iptables类似,kube-proxy为Service后端所有的Pod创建对应的IPVS规则,一个Service只会生成一条规则,所以规模较大的场景下,应该使用IPVS模式。其次IPVS更多更高级的调度算法。

二、service的资源类型

无论使用那一种代理模型Service资源都可以其工作逻辑分为ClusterIP, NodePort,toadBalance、ExternalName这四种类型。

1、clusterIP

ClusterIP:通过集群的内部 IP 暴露服务,选择ServiceIP只能够在集群内部访问。 这也是默认的ServiceType

2、Nodeport

NodePort:NodePort类型是对ClusterIP类型Service资源的扩展。它通过每个节点上的IP和端口接入集群外部流量,并分发给后端的Pod处理和响应。因此通过<节点IP>:<节点端口>,可以从集群外部访问服务。

3、LoadBalance

LoadBalancer:这类Service依赖云厂商,需要通过云厂商调用API接口创建软件负载均衡将服务暴露到集群外部。当创建LoadBalance类型的Service对象时,它会在集群上自动创建一个NodePort类型的Service。集群外部的请求流量会先路由至该负载均衡,并由该负载均衡调度至各个节点的NodePort。

4、ExternalName

ExternalName:此类型不是用来定义如何访问集群内服务的,而是把集群外部的某些服务以DNSCANME方式映射到集群内,从而让集群内的Pod资源能够访问外部服务的一种实现方式。

总结:

service资源类型:
ClusterIP: ServiceIP,为集群内部提供一个虚拟IP,实现负载均衡功能;
NodePort: 将集群外部的请求引入到集群内部; 为所有的节点开启对应的端口; 当用户请求节点IP+port会将请求调度给对应的Pod;
LoadBalance: 需要依赖云厂商;自动创建外部的负载均衡,负载均衡将流量调度给NodePort开放的端口;自动创建NodePort;就会创建ClusterIP;
externalName: 将外部的服务引入到集群内部;Pod请求一个域名就可以访问到外部的服务;

三、Service的实践-clusterIP

1、 clusterIP

1、创建deployment

在这里插入代码片
apiVersion: apps/v1
kind: Deployment 
metadata: name: daemon-app
spec:replicas: 3selector:matchLabels:app: webtemplate:metadata:labels:app: webspec:containers:- name: webservice#image: 192.168.1.20/k8s-test/daemon-app:v1.0image: registry.cn-hangzhou.aliyuncs.com/mokeyking/k8s-oldxu:daemon-app-v1imagePullPolicy: IfNotPresentports:- containerPort: 80 

2、创建svc

apiVersion: v1
kind: Service
metadata:name: daemon-svcspec:type: ClusterIPselector:app: webports:- name: httpport: 8888targetPort: 80  

3、验证查看

查看endpoints与pod的绑定

kubectl  get endpoints  daemon-svc
kubectl  get pod -o wide 
kubectl describe svc daemon-svc

在这里插入图片描述
在这里插入图片描述

4、在集群内进行访问测试验证

访问service默认,默认的是采用iptables的转发策略,如果pod的新增会自动加入service中,删除会自动在service进行清除

while sleep 0.5 ;do curl 10.106.49.247:8888;done 

在这里插入图片描述

5、测试自动加入service和退出service

只需要修改replicaset副本数量
在这里插入图片描述

增加
在这里插入图片描述
减少
在这里插入图片描述

6、编写固定的clusterIP地址,方便记忆

运行以下命令查看 Kubernetes 集群中 Service IP 地址范围的配置:
在这里插入图片描述

apiVersion: v1
kind: Service
metadata:name: daemon-svc-02spec:clusterIP: 10.96.1.1type: ClusterIPselector:app: webports:- name: httpport: 8888targetPort: 80 

验证
在这里插入图片描述

while sleep 0.5 ;do curl 10.96.1.1:8888;done 

在这里插入图片描述

四、Service的实践-NodePort

1、 NodePort

apiVersion: v1
kind: Service
metadata:name: daemon-svc-03spec:type: NodePortselector:app: webports:- name: httpport: 8888targetPort: 80  

在这里插入图片描述
通过浏览器访问:nodeIP + 30695
在这里插入图片描述
在这里插入图片描述

2、NodePort的端口范围

在 Kubernetes 集群中,Service 的端口范围是由 kube-apiserver 的 --service-node-port-range 标志来定义的。这个标志用于指定允许使用的 NodePort 端口范围。

要查看 Kubernetes 集群中 Service 端口范围的配置,可以按照以下步骤进行操作:

1、登录到 Kubernetes 集群的主节点或任意一个运行 kube-apiserver 的节点。

2、查看 kube-apiserver 的配置文件,通常为 /etc/kubernetes/manifests/kube-apiserver.yaml(根据你的安装方式和配置可能会有所不同)。

3、在该配置文件中找到 kube-apiserver 容器的启动参数部分,查找 --service-node-port-range 参数。

4、–service-node-port-range 参数的值将指定 Service 允许使用的 NodePort 端口范围。默认情况下,NodePort 的范围是从30000到32767。

如果你无法直接查看 kube-apiserver 的配置文件,你也可以通过以下命令查看当前 kube-apiserver 的运行参数:

ps aux | grep kube-apiserver

在这里插入图片描述

cat /etc/kubernetes/manifests/kube-apiserver.yaml

在这里插入图片描述
两者输出的信息是一样的

3、修改NodePort的端口范围

(因实验失败后续补充)

4、指定nodePort的端口

apiVersion: v1
kind: Service
metadata:name: daemon-svc-03spec:type: NodePortselector:app: webports:- name: httpport: 8888    ## 这个service+ IP 进行访问targetPort: 80   ## pod服务端口nodePort: 32000  ## Nodeport + IP进行访问

五、Service的实践-externalname

1、externalname

apiVersion: v1
kind: Service
metadata:name: daemon-external
spec:type: ExternalNameexternalName: www.king.com

2、验证测试

启动一个tools的pod进行测试
(存在疑问后续补充)

六、service和Endpoints关系

1、Endpoints与容器探针

Service对象借助Endpoint资源来跟踪其关联的后端端点,Endpoint对象会根据Service标签选择器筛选出的后端端点的IP地址分别保存在subsets.address字段和subsets.notReadyAddress字段中,它通过APIServer持续、动态跟踪每个端点的状态变化,并即使反应到端点IP所属的字段中。

  • subsets.address:保存就绪的容器IP,也就意味着service可以直接将请求调度至该地址段。
  • subsets.notReadyAddress:保存未就绪容器IP,也就意味着Service不会将请求调度至该地址段。
apiVersion: v1
kind: Service
metadata:name: demoapp-readiness-service
spec:publishNotReadyAddresses: trueselector:role: web-readinessports:- protocol: TCPport: 8888targetPort: 80---
apiVersion: apps/v1
kind: Deployment
metadata:name: demoapp2
spec:replicas: 2selector:matchLabels:role: web-readinesstemplate:metadata:labels:role: web-readinessspec:containers:- name: demoapp2image: registry.cn-hangzhou.aliyuncs.com/mokeyking/k8s-oldxu:daemon-app-v1readinessProbe:                 # 就绪探针httpGet:path: '/readyz'port: 80initialDelaySeconds: 15         # 初次检测延时时长periodSeconds: 10               # 检测周期

通过修改deployment的replicaset的副本数量

kubectl  scale  deployment  demoapp2  --replicas=3

在这里插入图片描述

while sleep 10s ;do curl 10.101.87.51 ;done

在这里插入图片描述

七、自定义endpoint实践

service通过selector和pod建立关联,k8s会根据service关联到的pOdIP信息组合成-个endpoint。若service定义中没有selector字段,service被创建时,endpoint controller不会自动创建endpoint。

我们可以通过配置清单创建Service,而无需使用标签选择器,而后自行创建一个同名的endpoint对象,指定对应的IP。这种一般用于将外部MySQL\Redis等应用引入Kubernetes集群内部,让内部通过Service的方式访问外部资源。

在这里插入图片描述

实验一: 将外部mysql数据库引入service集群中

1、准备外部数据库

# 安装mariadb
yum install mariadb mariadb-server -y
systemctl enable mariadb --now
#登陆maridb数据库
mysql# 授权
grant all privileges on *.* to 'king' identified by 'king395';
flush privileges;

2、创建Endpoints资源清单

# 自定义 service和endpoints
apiVersion: v1
kind: Service 
metadata:name: mysql-external
spec:type: ClusterIPports: - port: 3366targetPort: 3306---
apiVersion: v1
kind: Endpoints 
metadata:name: mysql-external
subsets:- addresses:- ip: 192.168.1.100 ports:- protocol: TCPport: 3306               # 定义后端的端口是多少

在这里插入图片描述

4、测试验证

# 使用tools,该镜像带有mysql命令
[root@master service]# kubectl  exec  -it tools  -- /bash/bin 
# 登陆数据库
[root@tools /]# mysql -h mysql-external -P3366 -uking -pking395 
# 创建库,创建表
create database king;
use king;
CREATE TABLE users (id INT AUTO_INCREMENT PRIMARY KEY,name VARCHAR(50)
);

在这里插入图片描述
在这里插入图片描述

5、登陆数据库再次验证

在这里插入图片描述
本次实验试验成功

八、service相关字段

1、sessionAffinity

如果要将来自于特定客户端的连接调度至同一Pod,可以使用sessionAffinity 基于客户端的 IP 地址进行会话保持。

还可以通过sessionAffinityConfig.clientIP.timeoutSeconds来设置最大会话停留时间。(默认10800秒,即3小时)

apiVersion: v1
kind: Service
metadata:name: session-svc
spec:type: ClusterIPselector:app: webports:- name: httpport: 80                  # Service的端口,后期所有的用户通过该端口进行访问targetPort: 80              # Pod的端口sessionAffinity: ClientIPsessionAffinityConfig:clientIP:timeoutSeconds: 60   #会话保持60秒
 curl 10.101.87.51 

在这里插入图片描述
会话记录会保持60秒

2、externalTrafficPolicy

外部流量策略:当外部用户通过NodePort请求Service,是将外部流量路由到本地节点上的Pod,还是路由到集群范围的Pod:

  • Cluster(默认):将用户请求路由到集群范围的所有Pod节点,具有良好的整体负载均衡。
  • Local:仅会将流量调度至请求的目标节点本地运行的Pod对象之上,以减少网络跳跃,降低网络延迟,但当请求指向的节点本地不存在目标Service相关的Pod对象时直接丢弃该报文。

2.1 Cluster模式

apiVersion: v1
kind: Service
metadata:name: demoapp-svc-external-traffic
spec:externalTrafficPolicy: Cluster     # 有两种模式Cluster和Localtype: NodePortselector:app: webports:- name: httpport: 8888                  # Service的端口,后期所有的用户通过该端口进行访问targetPort: 80              # Pod的端口nodePort: 32001             # 

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
会分别到不同的node节点中去

2.1 Local模式

apiVersion: v1
kind: Service
metadata:name: demoapp-svc-external-traffic
spec:externalTrafficPolicy: Local # 有两种模式Cluster和Localtype: NodePortselector:app: webports:- name: httpport: 8888                  # Service的端口,后期所有的用户通过该端口进行访问targetPort: 80              # Pod的端口nodePort: 32001             # 

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
不管怎么刷新,只会在指定的node进行返回

3、internalTrafficPolicy

本地流量策略:当本地Pod对Service发起访问时,是将流量路由到本地节点上的Pod,还是路由到集群范围的Pod:

  • Cluster(默认):将Pod的请求路由到集群范围的所有Pod节点具有良好的整体负载均衡。
  • Local:将请求路由到与发起方处于相同节点的端点,这种机制有助于节省开销,提升效率。但当请求指向的节点本地不存在目标Service相关的Pod对象时直接丢弃该报文。

注意:在一个Service上,当externalTrafficPolicy已设置为 Local时,internalTrafficPolicy则无法使用。 换句话说在一个集群的不同 Service 上可以同时使用这两个特性,但在一个Service 上不行

3.1 Cluster模式

apiVersion: v1
kind: Service
metadata:name: demoapp-svc-internal-traffic
spec:internalTrafficPolicy: Cluster # 有两种模式Cluster和Local,当externalTrafficPolicy已设置为 Local时,internalTrafficPolicy则无法使用selector:app: webports:- name: httpport: 80                  # Service的端口,后期所有的用户通过该端口进行访问targetPort: 80              # Pod的端口

在这里插入图片描述

## 使用tools镜像进行测试
kubectl  exec -it tools  -- /bin/bash 

在这里插入图片描述

3.2 Local模式

apiVersion: v1
kind: Service
metadata:name: demoapp-svc-internal-traffic
spec:internalTrafficPolicy: Local # 有两种模式Cluster和Local,当externalTrafficPolicy已设置为 Local时,internalTrafficPolicy则无法使用selector:app: webports:- name: httpport: 80                  # Service的端口,后期所有的用户通过该端口进行访问targetPort: 80              # Pod的端口

在这里插入图片描述

4、publishNotReadyAddresses

publishNotReadyAddresses:表示Pod就绪探针探测失败,也不会将失败的PodIP加入notReadyAddress列表中

4.1、检查当前Service对应的后端列表;

apiVersion: v1
kind: Service
metadata:name: demoapp-readiness-service
spec:publishNotReadyAddresses: trueselector:role: web-readinessports:- protocol: TCPport: 8888targetPort: 80---
apiVersion: apps/v1
kind: Deployment
metadata:name: demoapp2
spec:replicas: 4selector:matchLabels:role: web-readinesstemplate:metadata:labels:role: web-readinessspec:containers:- name: demoapp2image: oldxu3957/demoapp:v1.0readinessProbe:                 # 就绪探针httpGet:path: '/readyz'port: 80initialDelaySeconds: 15         # 初次检测延时时长periodSeconds: 10               # 检测周期
# 查看svc详情
kubectl  describe  svc demoapp-readiness-service 
# 按照标签进行查看pod
kubectl get pod --show-labels
kubectl get pods -l  role=web-readiness -o wide 

在这里插入图片描述

4.2、将其中的某个Pod设定为不就绪,看看是否会将该PodIP加入到NotReadAddress字段中

apiVersion: v1
kind: Service
metadata:name: demoapp-readiness-service
spec:publishNotReadyAddresses: true  ## 添加该字段selector:role: web-readinessports:- protocol: TCPport: 8888targetPort: 80---
apiVersion: apps/v1
kind: Deployment
metadata:name: demoapp2
spec:replicas: 2selector:matchLabels:role: web-readinesstemplate:metadata:labels:role: web-readinessspec:containers:- name: demoapp2image: oldxu3957/demoapp:v1.0readinessProbe:                 # 就绪探针httpGet:path: '/readyz'port: 80initialDelaySeconds: 15         # 初次检测延时时长periodSeconds: 10               # 检测周期
  • 将pod设置成未就绪
curl -s -X POST -d  'readyz=err' 10.244.2.62/readyz
# 如果想将pod设置成就绪状态,只需要将pod进行删除重建就可以了

在这里插入图片描述

  • 无论如何请求,只会请求只就绪的pod中
    在这里插入图片描述

  • 添加参数后的svc

spec:
'''publishNotReadyAddresses: true
''''

在这里插入图片描述
可以调用到未就绪的pod中
在这里插入图片描述

这种应用场景比较少

九、service的进阶-iptables和IPVS

1、service访问场景:

访问Service会出现如下4中情况:

  • 1、Pod-A>Service >调度>Pod-B/Pod-C
  • 2、Pod-A->Service >调度->Pod-A
  • 3、Docker>Service>调度→>Pod-B/Pod-C
  • 4、NodePort>Service>调度→>Pod-B/Pod-C

2、iptables规则

场景一,clusterIP规则

Pod-A>Service >调度>Pod-B/Pod-C

1、编写资源

apiVersion: apps/v1
kind: Deployment
metadata:name: demoappspec:replicas: 3selector:matchLabels:app: webtemplate:metadata:labels:app: webspec:containers:- name: webserversimage: oldxu3957/demoapp:v1.0imagePullPolicy: IfNotPresentports:- containerPort: 80---
apiVersion: v1
kind: Service
metadata:name: demoapp-svc
spec:type: ClusterIPselector:app: webports:- port: 80targetPort: 80

在这里插入图片描述

2、登陆pod,访问svc

在这里插入图片描述

3、iptables规则查看

iptables的流程:
入站本机:PREROUTING -->INPUT
从本机流入: OUTPUT --》 POSTROUTING
经过节点: PREROUTING --》FORWRD --》POSTROUTING

整体流程:
OUTPUT–>KUBE-SERVICES–>KUBE-SVC-–>KUBE-SEP------>POSTROUTING-----> KUBEPOSTROUTING ---->interface

第一步:所有从OUTPUT出去的数据包,都必须经过KUBE-SERVICES自定义链;[root@node02 ~]# iptables -S OUTPUT
-P OUTPUT ACCEPT
-A OUTPUT -m conntrack --ctstate NEW -m comment --comment "kubernetes service portals" -j KUBE-SERVICES
-A OUTPUT -j KUBE-FIREWALL
-A OUTPUT -o virbr0 -p udp -m udp --dport 68 -j ACCEPT第二步:分析KUBE-SERVICES
当发现请求的ServiceIP是 10.110.217.207的80端口时,则跳转KUBE-SVC-HASH这个自定义链上;	
[root@node2 ~]# iptables -t nat -S KUBE-SERVICES | grep demoapp-svc
-A KUBE-SERVICES -d 10.110.217.207/32 -p tcp -m comment --comment "default/demoapp-svc cluster IP" -m tcp --dport 80 -j KUBE-SVC-EHL433DY3T7P3MZN第三步:
第一条:创建自定义链;
第二条:如果来源不是POd的地址段,则将这个请求直接跳转到KUBE-MARK-MASQ这个自定义链上去; 然后给这个请求打上对应的标记 0x4000/0x4000
第三条到第五条:将请求通过调度算法调度到对应的自定义链上;  --> 第一次请求第一条有1/3  第二次请求50% 第三次 100%[root@node2 ~]# iptables -t nat -S KUBE-SVC-EHL433DY3T7P3MZN
-N KUBE-SVC-EHL433DY3T7P3MZN
-A KUBE-SVC-EHL433DY3T7P3MZN ! -s 10.244.0.0/16 -d 10.110.217.207/32 -p tcp -m comment --comment "default/demoapp-svc cluster IP" -m tcp --dport 80 -j KUBE-MARK-MASQ
### 通过轮休的方式进行调度到指定的地址上
-A KUBE-SVC-EHL433DY3T7P3MZN -m comment --comment "default/demoapp-svc" -m statistic --mode random --probability 0.33333333349 -j KUBE-SEP-OKCWPUIB7WHDSNLK
-A KUBE-SVC-EHL433DY3T7P3MZN -m comment --comment "default/demoapp-svc" -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-47KFJORAGBSAGTDM
-A KUBE-SVC-EHL433DY3T7P3MZN -m comment --comment "default/demoapp-svc" -j KUBE-SEP-GDD5ADYI2DAT4RQT[root@node2 ~]# iptables -t nat -S KUBE-MARK-MASQ
-N KUBE-MARK-MASQ
-A KUBE-MARK-MASQ -j MARK --set-xmark 0x4000/0x4000   #请求打上对应的标记 0x4000/0x4000第四步:第一条:创建自定义链;第二条:如果10.244.1.46 访问得是自己的Service,然后又被Service调度给自己本身,这个时候就将这个请求打上对应的标签  0x4000/0x4000第三条:进行dnat操作,就是将请求Service的IP,替换为Service后端的Pod的IP地址;
[root@node2 ~]# iptables -t nat -S KUBE-SEP-OKCWPUIB7WHDSNLK
-N KUBE-SEP-OKCWPUIB7WHDSNLK
-A KUBE-SEP-OKCWPUIB7WHDSNLK -s 10.244.1.46/32 -m comment --comment "default/demoapp-svc" -j KUBE-MARK-MASQ
-A KUBE-SEP-OKCWPUIB7WHDSNLK -p tcp -m comment --comment "default/demoapp-svc" -m tcp -j DNAT --to-destination 10.244.1.46:80
[root@node2 ~]# iptables -t nat -S KUBE-SEP-47KFJORAGBSAGTDM
-N KUBE-SEP-47KFJORAGBSAGTDM
-A KUBE-SEP-47KFJORAGBSAGTDM -s 10.244.2.64/32 -m comment --comment "default/demoapp-svc" -j KUBE-MARK-MASQ
-A KUBE-SEP-47KFJORAGBSAGTDM -p tcp -m comment --comment "default/demoapp-svc" -m tcp -j DNAT --to-destination 10.244.2.64:80
[root@node2 ~]# iptables -t nat -S KUBE-SEP-GDD5ADYI2DAT4RQT
-N KUBE-SEP-GDD5ADYI2DAT4RQT
-A KUBE-SEP-GDD5ADYI2DAT4RQT -s 10.244.3.77/32 -m comment --comment "default/demoapp-svc" -j KUBE-MARK-MASQ
-A KUBE-SEP-GDD5ADYI2DAT4RQT -p tcp -m comment --comment "default/demoapp-svc" -m tcp -j DNAT --to-destination 10.244.3.77:80第五步:
第一条:创建自定义链;
第二条:无条件调度到KUBE-POSTROUTING这个自定义链上;
第三条: docker相关的;忽略;
第四条:由于源地址是 192.168.122.0/16 目标 192.168.122.0/16,所以RETURN了;又回到了POSTROUTING链;看默认的规则是什么;ACEEPT; 数据包就会被送出;[root@node2 ~]# iptables -t nat -S  POSTROUTING
-P POSTROUTING ACCEPT
-A POSTROUTING -m comment --comment "kubernetes postrouting rules" -j KUBE-POSTROUTING
-A POSTROUTING -s 172.17.0.0/16 ! -o docker0 -j MASQUERADE
-A POSTROUTING -s 192.168.122.0/24 -d 224.0.0.0/24 -j RETURN
-A POSTROUTING -s 192.168.122.0/24 -d 255.255.255.255/32 -j RETURN
-A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p tcp -j MASQUERADE --to-ports 1024-65535
-A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p udp -j MASQUERADE --to-ports 1024-65535
-A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -j MASQUERADE
-A POSTROUTING -s 10.244.0.0/16 -d 10.244.0.0/16 -m comment --comment "flanneld masq" -j RETURN
-A POSTROUTING -s 10.244.0.0/16 ! -d 224.0.0.0/4 -m comment --comment "flanneld masq" -j MASQUERADE
-A POSTROUTING ! -s 10.244.0.0/16 -d 10.244.2.0/24 -m comment --comment "flanneld masq" -j RETURN
-A POSTROUTING ! -s 10.244.0.0/16 -d 10.244.0.0/16 -m comment --comment "flanneld masq" -j MASQUERADE第六步:
第一条:创建自定义链;
第二条:如果这个请求没有对应的标记,那么RETURN返回到POSTROUTING链;[root@node2 ~]# iptables -t nat -S  KUBE-POSTROUTING
-N KUBE-POSTROUTING
-A KUBE-POSTROUTING -m mark ! --mark 0x4000/0x4000 -j RETURN
-A KUBE-POSTROUTING -j MARK --set-xmark 0x4000/0x0
-A KUBE-POSTROUTING -m comment --comment "kubernetes service traffic requiring SNAT" -j MASQUERADE

在这里插入图片描述
在这里插入图片描述

4、iptables 的clusterIP模式图解

在这里插入图片描述

5、iptables的NodePort模式

apiVersion: apps/v1
kind: Deployment
metadata:name: demoappspec:replicas: 3selector:matchLabels:app: webtemplate:metadata:labels:app: webspec:containers:- name: webserversimage: oldxu3957/demoapp:v1.0imagePullPolicy: IfNotPresentports:- containerPort: 80---
apiVersion: v1
kind: Service
metadata:name: demoapp-svc
spec:type: NodePortselector:app: webports:- port: 80targetPort: 80nodePort: 32000

在这里插入图片描述

NodePort类型的service进行分析;Iptables规则:

PREROUTING -->FORWARD>POSTROUTING>interface

第一步:所有经过PREROUTING链的请求,都会被拦截到KUBE-SERVICES自定义链上;
[root@node2 ~]# iptables -t nat -S PREROUTING
-P PREROUTING ACCEPT
-A PREROUTING -m comment --comment "kubernetes service portals" -j KUBE-SERVICES
-A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER第二步:所有的规则都不会被匹配,但是会匹配最后一条规则,最后一条规则是跳转到KUBE-NODEPORTS这个自定义链中;[root@node2 ~]# iptables -t nat -S KUBE-SERVICES
-N KUBE-SERVICES
-A KUBE-SERVICES -d 10.110.217.207/32 -p tcp -m comment --comment "default/demoapp-svc cluster IP" -m tcp --dport 80 -j KUBE-SVC-EHL433DY3T7P3MZN
-A KUBE-SERVICES -d 10.96.0.1/32 -p tcp -m comment --comment "default/kubernetes:https cluster IP" -m tcp --dport 443 -j KUBE-SVC-NPX46M4PTMTKRN6Y
-A KUBE-SERVICES -d 10.96.0.10/32 -p udp -m comment --comment "kube-system/kube-dns:dns cluster IP" -m udp --dport 53 -j KUBE-SVC-TCOU7JCQXEZGVUNU
-A KUBE-SERVICES -d 10.96.0.10/32 -p tcp -m comment --comment "kube-system/kube-dns:dns-tcp cluster IP" -m tcp --dport 53 -j KUBE-SVC-ERIFXISQEP7F7OF4
-A KUBE-SERVICES -d 10.96.0.10/32 -p tcp -m comment --comment "kube-system/kube-dns:metrics cluster IP" -m tcp --dport 9153 -j KUBE-SVC-JD5MR3NA4I4DYORP
-A KUBE-SERVICES -d 10.100.82.155/32 -p tcp -m comment --comment "kube-system/metrics-server:https cluster IP" -m tcp --dport 443 -j KUBE-SVC-Z4ANX4WAEWEBLCTM
-A KUBE-SERVICES -m comment --comment "kubernetes service nodeports; NOTE: this must be the last rule in this chain" -m addrtype --dst-type LOCAL -j KUBE-NODEPORTS第三步:如果请求的是节点的32000端口;那么则跳转到 KUBE-SVC-<HASH>
[root@node2 ~]# iptables -t nat -S KUBE-NODEPORTS
-N KUBE-NODEPORTS
-A KUBE-NODEPORTS -p tcp -m comment --comment "default/demoapp-svc" -m tcp --dport 32000 -j KUBE-SVC-EHL433DY3T7P3MZN第四步:如果来源不是Pod的地址端,但是请求的是Service的IP,ClusterIP,目标端口是80,那么则跳转KUBE-MARK-MASQ 这个自定义链进行打标记;如果请求的是节点的32000端口,那么则跳转到KUBE-MARK-MASQ这个自定义链,进行打标记 (0x4000/0x4000)[root@node2 ~]# iptables -t nat -S KUBE-SVC-EHL433DY3T7P3MZN
-N KUBE-SVC-EHL433DY3T7P3MZN
-A KUBE-SVC-EHL433DY3T7P3MZN ! -s 10.244.0.0/16 -d 10.110.217.207/32 -p tcp -m comment --comment "default/demoapp-svc cluster IP" -m tcp --dport 80 -j KUBE-MARK-MASQ
-A KUBE-SVC-EHL433DY3T7P3MZN -p tcp -m comment --comment "default/demoapp-svc" -m tcp --dport 32000 -j KUBE-MARK-MASQ
-A KUBE-SVC-EHL433DY3T7P3MZN -m comment --comment "default/demoapp-svc" -m statistic --mode random --probability 0.33333333349 -j KUBE-SEP-SI5EEDPDQ7NVQF2Y
-A KUBE-SVC-EHL433DY3T7P3MZN -m comment --comment "default/demoapp-svc" -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-O7GW75MMOH2ZK4J5
-A KUBE-SVC-EHL433DY3T7P3MZN -m comment --comment "default/demoapp-svc" -j KUBE-SEP-ZOJBNUN3LSLJECDO[root@node2 ~]# iptables -t nat -S KUBE-MARK-MASQ
-N KUBE-MARK-MASQ
-A KUBE-MARK-MASQ -j MARK --set-xmark 0x4000/0x4000第五步:直接进行DNAT操作;[root@node2 ~]# iptables -t nat -S KUBE-SEP-O7GW75MMOH2ZK4J5
-N KUBE-SEP-O7GW75MMOH2ZK4J5
-A KUBE-SEP-O7GW75MMOH2ZK4J5 -s 10.244.2.65/32 -m comment --comment "default/demoapp-svc" -j KUBE-MARK-MASQ
-A KUBE-SEP-O7GW75MMOH2ZK4J5 -p tcp -m comment --comment "default/demoapp-svc" -m tcp -j DNAT --to-destination 10.244.2.65:80第六步:所有流经FORWARD这个链中的报文,都必须先到KUBE-FORWARD自定义链中;
[root@node2 ~]# iptables  -S FORWARD
-P FORWARD ACCEPT
-A FORWARD -m comment --comment "kubernetes forwarding rules" -j KUBE-FORWARD第七步:所有流经POSTROUTING这个链中的报文,都必须先到KUBE-POSTROUTING自定义链中;
[root@node2 ~]# iptables -t nat -S POSTROUTING
-P POSTROUTING ACCEPT
-A POSTROUTING -m comment --comment "kubernetes postrouting rules" -j KUBE-POSTROUTING
-A POSTROUTING -s 172.17.0.0/16 ! -o docker0 -j MASQUERADE
-A POSTROUTING -s 192.168.122.0/24 -d 224.0.0.0/24 -j RETURN
-A POSTROUTING -s 192.168.122.0/24 -d 255.255.255.255/32 -j RETURN
-A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p tcp -j MASQUERADE --to-ports 1024-65535
-A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p udp -j MASQUERADE --to-ports 1024-65535
-A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -j MASQUERADE
-A POSTROUTING -s 10.244.0.0/16 -d 10.244.0.0/16 -m comment --comment "flanneld masq" -j RETURN
-A POSTROUTING -s 10.244.0.0/16 ! -d 224.0.0.0/4 -m comment --comment "flanneld masq" -j MASQUERADE
-A POSTROUTING ! -s 10.244.0.0/16 -d 10.244.2.0/24 -m comment --comment "flanneld masq" -j RETURN
-A POSTROUTING ! -s 10.244.0.0/16 -d 10.244.0.0/16 -m comment --comment "flanneld masq" -j MASQUERADE第八步:[root@node2 ~]# iptables -t nat -S KUBE-POSTROUTING
-N KUBE-POSTROUTING
-A KUBE-POSTROUTING -m mark ! --mark 0x4000/0x4000 -j RETURN
-A KUBE-POSTROUTING -j MARK --set-xmark 0x4000/0x0
-A KUBE-POSTROUTING -m comment --comment "kubernetes service traffic requiring SNAT" -j MASQUERADE

十、IPVS模型分析

1、会在每个节点上创建一个名为kube-ipvs0的虚拟接口,并将集群所有Service对象的ClusterIP都配置在该接口:2、Kube-Proxy将每个Service生成一个虚拟服务器VirtualServer的定义;

注意:ipvs仅需要借助极少量的iptables规则完成源地址转换、源端口转换等;

1、设置集群为IPVS模式

在这里插入图片描述

1.1 修改ipvs模式

kubectl  edit  configmaps  kube-proxy -n kube-system ipvs:excludeCIDRs: nullminSyncPeriod: 0sscheduler: ""strictARP: falsesyncPeriod: 0stcpFinTimeout: 0stcpTimeout: 0sudpTimeout: 0skind: KubeProxyConfigurationmetricsBindAddress: ""mode: "ipvs" #指定ipvs规则

1.2、删除kube-proxy的pod,重启kube-proxy

kubectl  delete  pod $(kubectl get pod -n kube-system | grep proxy | awk '{print $1}') -n kube-system kubectl  delete  pod $(kubectl  get pod -l k8s-app=kube-proxy   -n kube-system  | awk 'NR>1 {print $1}') -n kube-system # 只删除第2和第三个pod
kubectl  delete  pod $(kubectl get pod -l k8s-app=kube-proxy -n kube-system | awk 'NR==3 || NR==4 {print $1}') -n kube-system 

在这里插入图片描述

1.3 IPVS 规则查看

## 全部规则查看
ipvsadm -L -n
## IPVS的映射网卡查看
ip a  s  ## 查看网卡
kubect get svc ## 查看svc 
如图所示,正式映射关系

在这里插入图片描述
在这里插入图片描述

十一、服务发现

当Pod需要访问Service时,通过Service提供的ClusterIP就可以实现了,但是有几个问题;

1、Service的IP不稳定,删除重建会发生变化;
2、ServiceIP难以记忆,如果能通过一个固定的名称访问就好了;

为了解决这样的问题,Kubernetes引入了环境变量和DNS两种方案来解决这样的问题;
1、环境变量方式:通过特定的名称将环境变量注入到Pod内部;
2、DNS方式:通过APIServer来监视Service变动,而后动态创建对应Service名称与ServiceIP的域名解析记录;

1、环境变量

每个 Pod 启动的时候,会通过环境变量的方式将Service的IP以及Port信息注入进去,这样 Pod 中的应用可以通过读取环境变量来获取对应Service服务的地址信息,这种方法使用起来相对简单,但是也存在一定的问题。就是Pod所依赖的Service必须优Pod启动,否则无法注入到环境变量中。

kubectl  run tools --image=registry.cn-hangzhou.aliyuncs.com/mokeyking/k8s-oldxu:tools-latest

在这里插入图片描述

kubectl  exec  -it tools  -- /bin/bash
env | grep -i demoapp_svc 
ping ${DEMOAPP_SVC_SERVICE_HOST}

在这里插入图片描述

在这里插入图片描述

在创建一个svc。pod就无法获取到svc的环境变量

apiVersion: v1
kind: Service
metadata:name: env-svc
spec:selector:app: webports:- port: 80targetPort: 80

在这里插入图片描述
在这里插入图片描述
pod无法获取新创建的svc的环境变量信息
但是再新创建一个pod就会能或者svc的变量信息
在这里插入图片描述
重新创建一个pod,能够或者两个svc的环境变量,这就是环境变量的作用

2、CoreDNS

在安装Kubernetes集群时,CoreDNS作为附加组件,用来为Pod提供DNS域名解析。CoreDNS监视 Kubernetes API 中的新Service,并为每个Service名称创建一组 DNS 记录。这样我们就可以通过固定的Service名称来转换出不固定的ServiceIP

了解CoreDNS的配置

[root@master service]# kubectl  get  configmap -n kube-system   ## 查看所有的配置信息
NAME                                 DATA   AGE
coredns                              1      97d
extension-apiserver-authentication   6      97d
kube-flannel-cfg                     2      97d
kube-proxy                           2      97d
kube-root-ca.crt                     1      97d
kubeadm-config                       1      97d
kubelet-config-1.23                  1      97d
[root@master service]# kubectl  get configmaps coredns -n kube-system -o yaml 
apiVersion: v1
data:Corefile: |.:53 {errors                                      ## 错误记录health {		                           ## 监控检查lameduck 5s}readykubernetes cluster.local in-addr.arpa ip6.arpa {   ## 用于解析kubernetes集群内域名pods insecurefallthrough in-addr.arpa ip6.arpattl 30}prometheus :9153    ## 监控端口forward . /etc/resolv.conf {  # 如果请求非Kubernetes域名,则由节点的resolv.conf中dns解析max_concurrent 1000}cache 30   # 缓存所有内容loopreload   # 支持热更新loadbalance  # 负载均衡,默认轮询}
kind: ConfigMap
metadata:creationTimestamp: "2023-12-15T16:08:05Z"name: corednsnamespace: kube-systemresourceVersion: "233"uid: 6fe29dab-17db-45f6-a7eb-70a08724337b

默认的域名解析配置
在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

解析svc域名
在这里插入图片描述
总结:可以解析到对应的svcIP

在这里插入图片描述
总结:删除svc时,svc的ip就会发生变化,但是重新对svc的域名进行解析,仍然能够解析到svc的ip。只要service的名称不发生变化,就可以正常解析,所有可以将这个注入到pod的中,就可以解析svc的配置。这个DNS是通过cordDNS进行转发解析的。

在这里插入图片描述

十二、CordDNS策略

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: pod-example-1
spec:dnsPolicy: ClusterFirstcontainers:- name: toolsimage: registry.cn-hangzhou.aliyuncs.com/mokeyking/k8s-oldxu:tools-latestports:- containerPort: 8899

查看pod的DNS的策略
在这里插入图片描述
在这里插入图片描述
总结: 使用默认DNS解析

2、ClusterFirstWithHostNet

在某些场景下,我们的 Pod 是用 HostNetwork 模式启动的,一旦使用 HostNetwork 模式,那该Pod则会使用当前宿主机的/etc/resolv.conf来进行 DNS 查询,但如果任然想继续使用Kubernetes的DNS服务,那就将 dnsPolicy设置为ClusterFirstWithHostNet

  • 为了方便验证,将三个node的主机域名解析都缓存不一样的的
vim /etc/resolv.conf 
### node1
nameserver 233.5.5.5
### node2
nameserver 233.6.6.6
### node3
nameserver 114.114.114.114

在这里插入图片描述

apiVersion: v1
kind: Pod 
metadata: name: pod-example-2
spec:hostNetwork: true   ## 与主机共享网络dnsPolicy: ClusterFirst containers:- name: toolsimage: registry.cn-hangzhou.aliyuncs.com/mokeyking/k8s-oldxu:tools-latestimagePullPolicy: IfNotPresentports:- containerPort: 8899

在这里插入图片描述
在这里插入图片描述

  • 通过指定node标签,让pod创建到指定的node上
kubectl  get node --show-labels
apiVersion: v1
kind: Pod 
metadata: name: pod-example-2
spec:hostNetwork: truednsPolicy: ClusterFirstcontainers:- name: toolsimage: registry.cn-hangzhou.aliyuncs.com/mokeyking/k8s-oldxu:tools-latestimagePullPolicy: IfNotPresentports:- containerPort: 8899nodeSelector:kubernetes.io/hostname: node2

在这里插入图片描述

通过指定不的node便签进行创建pod,可以看到共享不同pod主机域名解析

在这里插入图片描述pod无法通过svc进行解析,可以dnsPolicy规则改为ClusterFirstWithHostNet

apiVersion: v1
kind: Pod 
metadata: name: pod-example-2
spec:hostNetwork: true  ## 共享主机网络dnsPolicy: ClusterFirstWithHostNet  ## 如果配置了首要配置kubernetes的域名解析containers:- name: toolsimage: registry.cn-hangzhou.aliyuncs.com/mokeyking/k8s-oldxu:tools-latestimagePullPolicy: IfNotPresentports:- containerPort: 8899nodeSelector:kubernetes.io/hostname: node3

在这里插入图片描述

在这里插入图片描述

  • 这个ClusterFirstWithHostNet策略也适用deployment

在这里插入图片描述

  • 编写deployment的资源清单
apiVersion: apps/v1
kind: Deployment
metadata:name: demoappspec:replicas: 3selector:matchLabels:app: webtemplate:metadata:labels:app: webspec:hostNetwork: truednsPolicy: ClusterFirstcontainers:- name: webserversimage: oldxu3957/demoapp:v1.0imagePullPolicy: IfNotPresentports:- containerPort: 80---
apiVersion: v1
kind: Service
metadata:name: demoapp-svc
spec:type: NodePortselector:app: webports:- port: 80targetPort: 80nodePort: 32000

在这里插入图片描述
域名解析能解析到node3的主机 /etc/resolv.conf

3、default

默认使用宿主机的 /etc/resolv.conf但可以使用 kubelet 的 --resolv-conf=/etc/resolv.conf 来指定 DNS 解析文件地址。

  • 使用默认主机的 /etc/resolv.conf
apiVersion: v1
kind: Pod 
metadata: name: pod-example-3
spec:dnsPolicy: Defaultcontainers:- name: toolsimage: registry.cn-hangzhou.aliyuncs.com/mokeyking/k8s-oldxu:tools-latestports:- containerPort: 8899nodeSelector:kubernetes.io/hostname: node3

使用了node3的 /etc/resolv.conf 的默认主机名认证

在这里插入图片描述

  • 使用node节点的指定路径的域名解析的文件,使用主机挂载方式
apiVersion: v1
kind: Pod
metadata:name: pod-example-6
spec:containers:- name: toolsimage: registry.cn-hangzhou.aliyuncs.com/mokeyking/k8s-oldxu:tools-latestimagePullPolicy: IfNotPresentvolumeMounts:- name: resolv-confmountPath: /etc/resolv.confreadOnly: truednsPolicy: DefaultdnsConfig:options:- name: ndotsvalue: "2"volumes:- name: resolv-confhostPath:path: /root/resolv.confnodeSelector:kubernetes.io/hostname: node3

在这里插入图片描述
在这里插入图片描述

  • 将域名添加到,并执行域名解析的ip,我特定的域名地址
apiVersion: v1
kind: Pod
metadata:name: pod-example-4
spec:containers:- name: toolsimage: registry.cn-hangzhou.aliyuncs.com/mokeyking/k8s-oldxu:tools-latestdnsPolicy: DefaultdnsConfig:nameservers:- 10.0.0.1- 10.0.0.2searches:- /etc/resolv.conf- otherdomain.svc.cluster.localnodeSelector:kubernetes.io/hostname: node2

在这里插入图片描述

4、Node

空的DNS设置,这种方式一般用于自定义 DNS 配置的场景,往往需要和dnsConfig一起使用才可以达到自定义DNS的目的。

apiVersion: v1
kind: Pod
metadata:name: pod-example-7
spec:containers:- name: toolsimage: registry.cn-hangzhou.aliyuncs.com/mokeyking/k8s-oldxu:tools-latestimagePullPolicy: IfNotPresentdnsPolicy: NonednsConfig:nameservers:- 233.5.5.5- 233.6.6.6searches:- mydomain.com- otherdomain.svc.cluster.local- king.netnodeSelector:kubernetes.io/hostname: node1

在这里插入图片描述

十三、HeadLess Service

1、什么是HeadLess

HeadlessService也叫无头服务,就是创建的Service没有ClusterIP,而是为Service所匹配的每个Pod都创建一条DNS的解析记录,这样每个Pod都有一个唯一的DNS名称标识身份,访问的格式如下

在这里插入图片描述

2、HeadLess的作用

像 elasticsearch,mongodb,kafka 等分布式服务,在做集群初始化时,配置文件中要写上集群中所有节点的IP(或是域名)但Pod是没有固定IP的,所以配置文件里写DNS名称是最合适的。

那为什么不用Service,因为 Service 作为 Pod 前置的负载均衡一般是为一组相同的后端 Pod 提供访问入口,而且 Service的selector也没有办法区分同一组Pod的不同身份。

但是我们可以使用 Statefulset控制器,它在创建每个Pod的时候,能为每个 Pod 做一个编号,就是为了能区分这一组Pod的不同角色,各个节点的角色不会变得混乱,然后再创建 headless service 资源,集群内的节点通过Pod名称+序号.Service名称,来进行彼此间通信的只要序号不变,访问就不会出错。

当statefulSet.spec.serviceName 配置与headless service相同时,可以通过 {hostName}.fheadless service}.{namespace}.svc.cluster.local 解析出节点IP。hostName 由{statefulSet name}-{编号}组成。

{statefulSet name}-{编号}.{headless service}{namespace}.svc.cluster.local
# 放在当前es中,对应的DNS子域名分别是
es-0.elastic.default.svc.cluster.local
es-1.elastic.default.svc.cluster.local
es-2.elastic.default.svc.cluster.local

3、HeadLess示例

apiVersion: v1
kind: Service
metadata:name: myapp
spec:clusterIP: "None"selector:app: nginxports:- port: 80targetPort: 80

在这里插入图片描述

  • 编写pod资源
apiVersion: apps/v1
kind: StatefulSet
metadata:name: web
spec:serviceName: "myapp"replicas: 2selector:matchLabels:app: nginxtemplate:metadata:labels:app: nginxspec:containers:- name: xximage: nginx:1.16imagePullPolicy: IfNotPresentports:- containerPort: 80

在这里插入图片描述

  • 使用tools 进行验证测试
kubectl  exec -it tools -- /bin/bash

在这里插入图片描述

  • ping myapp.default.svc.cluster.local 可以轮询到不同的pod上。

在这里插入图片描述

  • ping web-1.myapp.default.svc.cluster.local 使用这个可以解析到指定的pod上

4、HeadLess测试

在这里插入图片描述
在这里插入图片描述
总结: 通过删除pod。依旧可以通过域名的方式进行解析

十四、guestBook案例实践

guestBook官网示例
guestBook的GitHub地址

1、场景描述

  • 1、启动 Redis、领导 者(Leader)
  • 2、启动两个 Redis 跟随者(Follower)
  • 3、启动并公开 GuestBook 服务,数据写入Redis Leader节点数据读取统一写入Redis Slave节点
  • 3.1 如果 GET HOSTS_FROM 设置为 env,则需要手动传递Redis Master、以及Slave的 Service名称;
    REDIS LEADER SERVICE HOST # 传递Leader节点的Service名称或IP
    REDIS FOLLOWER_SERVICE_HOST # 传递 Follower节点Service的名称或IP
  • 3.2 如果 GET HOSTS_FROM 设置为 dns,则站点会自动初始化两个变量,这就要求创建service时的名称得固定;
    $host =‘redis-leader’;
    $host =‘redis-follower’;

在这里插入图片描述

2、部署Redis-Leader

apiVersion: apps/v1
kind: Deployment
metadata:name: redis-leader            # Deployment Pod的名称
spec:replicas: 1selector:matchLabels:app: redis-mastertemplate:metadata:labels:app: redis-masterspec:containers:- name: redis-containerimage: redisports:- containerPort: 6379---
apiVersion: v1
kind: Service
metadata:name: redis-leader
spec:type: ClusterIPselector:app: redis-masterports:- port: 6379targetPort: 6379

在这里插入图片描述

3、部署redis-follower

apiVersion: apps/v1
kind: Deployment
metadata:name: redis-follower
spec:replicas: 2selector:matchLabels:app: redis-slavetemplate:metadata:labels:app: redis-slavespec:containers:- name: redis-slaveimage: redis command: ["redis-server"]args:- --port 6379- --slaveof redis-leader 6379---
apiVersion: v1
kind: Service
metadata:name: redis-follower
spec:type: ClusterIPselector:app: redis-slaveports:- port: 6379targetPort: 6379

在这里插入图片描述
在这里插入图片描述

4、部署guestbooks的deploy和service

apiVersion: apps/v1
kind: Deployment
metadata:name: guestbooks
spec:replicas: 3selector:matchLabels:app: bookstemplate:metadata:labels:app: booksspec:containers:- name: books-containerimage: oldxu3957/guestbook:v5env:- name: GET_HOSTS_FROMvalue: "env"- name: REDIS_LEADER_SERVICE_HOSTvalue: "redis-leader"- name: REDIS_FOLLOWER_SERVICE_HOSTvalue: "redis-follower"ports:- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:name: guestbook-svc
spec:type: NodePortselector:app: booksports:- name: httpport: 80targetPort: 80nodePort: 32002

在这里插入图片描述
将redis的server的环境变量注册到Guesbook的环境变量中

在这里插入图片描述
登陆redis从库查看数据
在这里插入图片描述

在这里插入图片描述

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/766900.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

【STM32】读写BKP备份寄存器RTC实时时钟

目录 BKP BKP简介 BKP基本结构 BKP测试代码 RTC RTC简介 RTC框图 RTC基本结构 硬件电路 RTC操作注意事项 接线图 初始化 使用BKP解决只初始化一次时间 初始化参考代码 RTC设置时间 RTC读取时间 完整代码 MyRTC.c MyRTC.h main.c BKP BKP简介 BKP&#xff0…

pytorch中tensor类型转换的几个函数

目录 IntTensor转FloatTensor FloatTensor转IntTensor Tensor类型变为python的常规类型 IntTensor转FloatTensor .float函数&#xff1a; FloatTensor转IntTensor .int函数 Tensor类型变为python的常规类型 item函数

阿里云部署MySQL、Redis、RocketMQ、Nacos集群

文章目录 &#x1f50a;博主介绍&#x1f964;本文内容MySQL集群配置云服务器选购CPU选择内存选择云盘选择ESSD AutoPL云盘块存储性能&#xff08;ESSD&#xff09; 镜像选择带宽选择密码配置注意事项 安装docker和docker-compose部署MySQL三主六从半同步集群一主二从同步集群规…

pytorch如何向tensor结尾添加元素或维度--torch.cat()、torch.unsqueeze()的用法

目录 示例1 矢量后增加元素 示例2 tensor维度增加1 示例3 另一种替代unsqueeze的方法 示例1 矢量后增加元素 使用torch.cat()函数 ptorch.Tensor([1,5,0]) ptorch.cat((p, torch.Tensor([4])), 0) 结果&#xff1a; 这里&#xff0c;cat的第一个输入变量用()包绕&#xf…

Request请求参数----中文乱码问题

一: GET POST获取请求参数: 在处理为什么会出现中文乱码的情况之前, 首先我们要直到GET 以及 POST两种获取请求参数的不同 1>POST POST获取请求参数是通过输入流getReader来进行获取的, 通过字符输入流来获取响应的请求参数, 并且在解码的时候, 默认的情况是 ISO_885…

由浅到深认识Java语言(21):Math类

该文章Github地址&#xff1a;https://github.com/AntonyCheng/java-notes 在此介绍一下作者开源的SpringBoot项目初始化模板&#xff08;Github仓库地址&#xff1a;https://github.com/AntonyCheng/spring-boot-init-template & CSDN文章地址&#xff1a;https://blog.c…

GaussDB WDR分析之集群报告篇

AWR报告目前已经成为Oracle DBA分析问题&#xff0c;定位故障最为重要的报告&#xff0c;阅读与分析AWR报告的技能也是Oracle DBA必备的技能。国产数据库为了提高运维便捷性&#xff0c;都在做类似Oracle AWR报告的模仿&#xff0c;只不过由于指标体系不够完善&#xff0c;因此…

postman 用上一个请求的响应体中的字段设置下一个请求的请求参数

文章目录 IntroPostman usagePre-request ScriptTests javascripts API Intro 这一切都是为了增加自动化动作所占的比例&#xff08;减少人手工操作复制粘贴可能会造成的错误&#xff09;。 Postman usage 最常用的&#xff1a;选HTTP方法类型、写URL&#xff0c;在Headers中…

如何解决Layui后台接口返回数据,但是table.render不渲染表格数据的问题

我这边进行了pareData数据格式转换&#xff0c;response重新定义了layui的参数格式规范 接口正常返回了数据 但是就是不渲染&#xff0c;我这个郁闷啊&#xff01;&#xff01; 忽然&#xff0c;我把后台重新定义的layui规定的格式参数&#xff0c;有个参数名叫data&#xff0…

sql注入五-WEB攻防-注入工具SQLMAPTamper编写指纹修改高权限操作目录架构

演示案例&#xff1a; 数据猜解-库表列数据&字典权限操作-文件&命令&交互式提交方法-POST&HEAD&JSON绕过模块-Tamper脚本-使用&开发分析拓展-代理&调试&指纹&风险&等级 #参考&#xff1a; https://www.cnblogs.com/bmjoker/p/9326258.…

自动化的免下车服务——银行、餐厅、快餐店、杂货店

如果您在20世纪70年代和2020年分别驾车经过免下车服务餐厅&#xff08;汽车穿梭餐厅&#xff09;&#xff0c;您会发现&#xff0c;唯一的不同是排队的车型。50多年来&#xff0c;免下车技术一直为我们提供着良好的服务&#xff0c;但现在也该对它进行现代化改造了。 乘着AI和自…

先进电机技术 —— 长线缆驱动电机面临哪些问题?

一、长线驱动问题简述 电机变频驱动器&#xff08;VFD&#xff09;输出侧采用长线缆驱动电机运行时&#xff0c;将会面对多种问题&#xff0c;主要包括但不限于&#xff1a; 此图片来源于网络 1. **电压降**&#xff1a; - 长线缆的电阻会导致电压降增大&#xff0c;当电…

53 initrd/initramfs 相关

前言 呵呵 这里主要是 探究一下 根文件系统 相关的东西 以及 附加了一些 系统启动的相关信息 计算机启动 硬件重置寄存器 设置初始化数据 计算机访问 0xffff0, 执行 bios 的代码, bios 选择启动设备, 然后执行 启动设备 boolloader 的代码 bootloader 将 boot.img 加载…

你可敢信这是 AI 写的歌?suno 真的惊到我了!

你可敢信这是 AI 写的歌&#xff1f;suno 真的惊到我了&#xff01; AI 音乐平台 suno 横空出世&#xff0c;效果惊人&#xff0c;我赶紧试了一下&#xff0c;amazing&#xff01;&#xff01;&#xff01; suno创作 - 背叛 这是我随意创作的&#xff0c;这几天对诅咒前男友那首…

MySQL常用函数整理,建议收藏!

常见函数 字符串函数数字函数日期函数聚合函数流程控制函数 一、字符串函数 concat(s1,s2...,sn) --将s1,s2...,sn连接成字符串&#xff0c;如果该函数中的任何参数为 null&#xff0c;返回结果为 null concat_ws(sep,s1,s2...,sn) --将s1,s2...,sn连接成字符串,并用sep字符…

xilinx的高速接口构成原理和连接结构

本文来源&#xff1a; V3学院 尤老师的培训班笔记【高速收发器】xilinx高速收发器学习记录Xilinx-7Series-FPGA高速收发器使用学习—概述与参考时钟GT Transceiver的总体架构梳理 文章目录 一、概述&#xff1a;二、高速收发器结构&#xff1a;2.1 QUAD2.1.1 时钟2.1.2 CHANNEL…

【阅读论文】When Large Language Models Meet Vector Databases: A Survey

摘要 本调查探讨了大型语言模型&#xff08;LLM&#xff09;和向量数据库&#xff08;VecDB&#xff09;之间的协同潜力&#xff0c;这是一个新兴但迅速发展的研究领域。随着LLM的广泛应用&#xff0c;出现了许多挑战&#xff0c;包括产生虚构内容、知识过时、商业应用成本高昂…

【Godot4.2】基础知识 - Godot中的2D向量

概述 在Godot中&#xff0c;乃至一切游戏编程中&#xff0c;你应该都躲不开向量。这是每一个初学者都应该知道和掌握的内容&#xff0c;否则你将很难理解和实现某些其实原理非常简单的东西。 估计很多刚入坑Godot的小伙伴和我一样&#xff0c;不一定是计算机专业或编程相关专…

利用sealos安装k8s集群

1. 环境准备 准备三台干净&#xff08;未安装过k8s环境&#xff09;的虚拟机 # 所有的主机都要配置主机名和域名映射 # 设置主机名 hostnamectl set-hostname k8s-master01 # vim /etc/hosts 192.168.59.201 k8s-master01 192.168.59.202 k8s-worker01 192.168.59.203 k8…

基于ssm停车场管理系统(程序+文档+数据库)

** &#x1f345;点赞收藏关注 → 私信领取本源代码、数据库&#x1f345; 本人在Java毕业设计领域有多年的经验&#xff0c;陆续会更新更多优质的Java实战项目&#xff0c;希望你能有所收获&#xff0c;少走一些弯路。&#x1f345;关注我不迷路&#x1f345;** 一、项目概述…