K8s9(2-1) k8s中的通信机制, kube-proxy的ipvs模式 ,无头服务,LoadBalancer,ExternalName,外部公有 ip(externalIPs)

1.K8s中的service和通信:

Service可以看作是一组提供相同服务的Pod对外的访问接口。借助Service,应用可以方便地实现服务发现和负载均衡。 service默认只支持4层负载均衡能力,没有7层功能。(可以通过Ingress实现)

service的类型:
• ClusterIP:默认值,k8s系统给service自动分配的虚拟IP,只能在集群内部访问。
• NodePort:将Service通过指定的Node上的端口暴露给外部,访问任意一个 NodeIP:nodePort都将路由到ClusterIP。
• LoadBalancer:在 NodePort 的基础上,借助 cloud provider 创建一个外部的负 载均衡器,并将请求转发到 :NodePort,此模式只能在云服务器上使用。
• ExternalName:将服务通过 DNS CNAME 记录方式转发到指定的域名(通过 spec.externlName 设定)。

Service 是由 kube-proxy 组件,加上 iptables 来共同实现的.
• kube-proxy 通过 iptables 处理 Service 的过程,需要在宿主机上设置相当多的 iptables 规则,如果宿主机有大量的Pod,不断刷新iptables规则,会消耗大量的 CPU资源。
• IPVS模式的service,可以使K8s集群支持更多量级的Pod。

k8s间的通信方式:

k8s通过CNI接口接入其他插件来实现网络通讯。目前比较流行的插件有flannel, calico等。

CNI插件存放位置: cat /etc/cni/net.d/10-flannel.conflist

插件使用的解决方案如下:

虚拟网桥,虚拟网卡,多个容器共用一一个虛拟网卡进行通信。
多路复用: MacVLAN,多个容器共用- -个物理网卡进行通信。
硬件交换: SR-LOV, 一个物理网卡可以虚拟出多个接口,这个性能最好。

容器间通信:同一个pod内的多个容器间的通信,通过Io即可实现;

pod之间的通信:

同一节点的pod之间通过cni网桥转发数据包。
不同节点的pod之间的通信需要网络插件支持。

pod和service通信:通过 iptables 或 ipvs 实现通信,ipvs取代不了iptables,因为ipvs只能做负载均衡,而做不了nat转换。

pod和外网通信:iptables的MASQUERADE

Service与集群外部客户端的通信: Ingress、 NodePort、 Loadbalancer

2.kube-proxy的ipvs模式:

默认情况下:kube-proxy使用的是iptables模式,如果宿主机有大量的pod会浪费cpu来频繁更新iptables策略;

因此,使用ipvs模式下的service可以使k8s支持更多量级的pod;

开启kube-proxy的ipvs模式:
yum install -y ipvsadm 所有节点安装
kubectl edit cm kube-proxy -n kube-system 修改IPVS模式 mode: “ipvs”
kubectl get pod -n kube-system |grep kube-proxy | awk '{system(“kubectl delete pod “$1” -n kube-system”)}'更新kube-proxy pod

安装ipvsadm,更改mode; 由于更改了模式,因此更新kube-proxy pod 最简单的就是删除让其重建;
等删除完成之后可以使用ipvsadm -ln 查看其中策略,可以看见service中的10.96.0.1和10.98.153.70在策略中使用rr调度;
在这里插入图片描述

同时:IPVS模式下,kube-proxy会在service创建后,在宿主机上添加一个虚拟网卡: kube-ipvs0,并分配service IP。
在这里插入图片描述

使用ipvs模式下创建的pod都会在 kube-ipvs0,中分配到对应的service IP;

# demo.yml 
---
apiVersion: v1
kind: Service
metadata:
  name: myservice
spec:
  selector:
    app: myapp
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo2
spec:
  replicas: 4
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: myapp:v2


3.无头服务(Headless Services):

Headless Service “无头服务” 。 Headless Service不需要分配一个VIP,而是直接以DNS记录的方式解析出被代理 Pod的IP地址。
域名格式:$ (servicename).$(namespace).svc.cluster.local

yum install -y bind-utils.x86_64安装解析工具( dig )

[root@server11~]$ vim service.yml 
[root@server11~]$ cat service.yml 
kind: Service
apiVersion: v1
metadata:
  name: myservice
spec:
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  selector:
    app: myapp
  clusterIP: None
[root@server11~]$ kubectl apply -f service.yml 
service/myservice created
[root@server11~]$ kubectl get svc
NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   10.96.0.1    <none>        443/TCP   7d11h
myservice    ClusterIP   None         <none
<think>好的,我需要回答用户关于kube-proxyLoadBalancer模式下Service的iptables工作机制的问题。首先,我得回忆一下kube-proxy的基本知识。用户提供的引用提到,kube-proxy有两种主要模式:userspace和iptables,现在还有ipvs模式。但用户的问题集中在LoadBalancer模式下的iptables机制,所以需要重点考虑iptables模式下的实现。 首先,LoadBalancer类型的Service其实是NodePort的一个扩展,通常会由云提供商提供负载均衡器,将外部流量导向各个节点的NodePort。然后kube-proxy负责将NodePort的流量通过iptables规则转发到后端Pod。我需要解释这个过程中kube-proxy如何生成iptables规则。 根据引用[2],kube-proxy作为控制器,负责更新iptables规则,而实际的流量处理由netfilter(即iptables)完成。在LoadBalancer模式下,当Service创建时,kube-proxy会监听API Server的变化,并生成相应的规则。这些规则包括目标地址转换(DNAT),将到达Service的ClusterIP或NodePort的流量转发到后端Pod的IP和端口。 接下来要详细说明iptables的处理链。例如,引用[4]提到PREROUTING链跳转到KUBE-SERVICES链,这里所有的服务流量都会先经过这个链。当数据包到达时,iptables会根据匹配的Service IP和端口,选择对应的后端Pod,并进行DNAT转换。同时,可能还需要处理负载均衡的策略,比如随机选择Pod或者轮询。 需要注意的是,LoadBalancer模式通常依赖于云平台的负载均衡器,但kube-proxyiptables规则仍然在节点内部处理流量路由。因此,外部流量通过负载均衡器到达节点的NodePort,然后由iptables规则进一步转发到Pod。 还需要确认用户提到的引用内容是否涉及具体的iptables链和规则。比如引用[4]中的KUBE-SERVICES链,以及可能的其他链如KUBE-NODEPORTS,这些链会在处理不同流量时被调用。例如,当流量来自外部负载均衡器时,进入NodePort的端口,会被KUBE-NODEPORTS链处理,进而跳转到对应Service的规则,再DNAT到具体的Pod。 另外,需要说明每个Service对应的iptables规则如何生成。例如,当有多个后端Pod时,kube-proxy会为每个Pod创建相应的规则,并使用概率(--probability)参数来实现流量的随机分发,从而实现负载均衡。这部分需要结合具体的iptables规则示例来解释。 最后,总结整个过程,强调kube-proxy的作用是动态维护这些iptables规则,确保流量正确转发,而实际的数据包处理由Linux内核的netfilter完成。这符合引用[2]和[3]提到的内容,即kube-proxy作为控制器配置规则,而不是直接处理流量。 现在需要将这些思路组织成结构化的回答,确保使用正确的中文术语和LaTeX格式,同时生成相关问题。</think>### kube-proxyLoadBalancer模式下的Service实现原理及iptables工作机制 #### 1. LoadBalancer模式Service的架构 LoadBalancer类型的Service是NodePort的扩展,通过云服务商的负载均衡器将外部流量分发到集群节点的NodePort端口[^1]。kube-proxy在此模式下的核心作用是通过iptables规则,将到达NodePort或ClusterIP的流量转发到后端Pod。 #### 2. iptables规则生成逻辑 kube-proxy通过监听Kubernetes API Server的Service和Endpoint变化,动态生成iptables规则: 1. **目标地址转换(DNAT)**:将目标地址从Service的IP:Port或NodePort转换为后端Pod的IP:Port。 2. **负载均衡规则**:使用`statistic`模块(如`random`或`nth`)实现流量随机分发到多个Pod[^2]。 #### 3. iptables关键处理链 以下是流量从负载均衡器到Pod的路径示例: ```plaintext 外部流量 → 云负载均衡器 → 节点NodePort → iptables PREROUTING链 → KUBE-SERVICES链 → KUBE-NODEPORTS链 → DNAT到Pod ``` 具体链的作用: - **PREROUTING链**:所有流量首先进入此链,跳转到`KUBE-SERVICES`链[^4]。 - **KUBE-SERVICES链**:匹配Service的ClusterIP和端口。 - **KUBE-NODEPORTS链**:处理NodePort类型的流量,进一步匹配端口并跳转到Service规则[^4]。 #### 4. 规则示例及负载均衡实现 假设Service有两个后端Pod(IP1:Port、IP2:Port),kube-proxy生成的规则可能如下: ```bash -A KUBE-SVC-XXXXX -m statistic --mode random --probability 0.5 -j KUBE-SEP-YYYYY -A KUBE-SVC-XXXXX -j KUBE-SEP-ZZZZZ ``` - **`--probability 0.5`**:第一条规则有50%概率命中,剩余流量走第二条规则,实现均匀分发。 #### 5. 与内核协作机制 kube-proxy仅负责规则配置,实际转发由Linux内核的netfilter模块完成[^2]。这种设计避免了用户态代理的性能瓶颈(对比早期的userspace模式[^3])。 $$ \begin{aligned} &\text{性能对比(包转发速率)} \\ &\text{userspace模式} & &< 10^4 \text{ pps} \\ &\text{iptables模式} & &\approx 10^5 \text{ pps} \\ &\text{ipvs模式} & &> 10^6 \text{ pps} \end{aligned} $$
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值