• Kubernetes(k8s)的流量负载组件Service基础介绍和原理讲解、IPVS的开启


    1. Service介绍

    虽然可以通过Pod的IP来访问应用程序,但是Pod的IP地址不是固定的。而Service会对提供同一个服务的多个Pod进行聚合,并且提供一个统一的访问入口地址

    Service
    每个Node节点上都运行了一个kube-proxy的服务进程。当创建Service的时候会通过API Server向etcd写入创建的Service的信息,而kube-proxy会基于监听的机制发现Service的变化,然后它会将最新的Service信息转换为对应的访问规则

    kube-proxy

    2. Service访问规则转发说明

    [root@k8s-master ~]# ipvsadm -Ln
    IP Virtual Server version 1.2.1 (size=4096)
    Prot LocalAddress:Port Scheduler Flags
      -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
    ......省略部分......    
    TCP  10.96.0.10:53 rr
      -> 10.244.235.203:53            Masq    1      0          0         
      -> 10.244.235.204:53            Masq    1      0          0         
    TCP  10.96.0.10:9153 rr
      -> 10.244.235.203:9153          Masq    1      0          0         
      -> 10.244.235.204:9153          Masq    1      0          0         
    ......省略部分......      
    UDP  10.96.0.10:53 rr
      -> 10.244.235.203:53            Masq    1      0          0         
      -> 10.244.235.204:53            Masq    1      0          0         
    [root@k8s-master ~]# 
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16

    当以TCP方式访问10.96.0.10:53这个service提供的访问入口。会基于rr(轮询)的策略,将请求转发到后面的两个Pod中的一个。真正提供服务的是10.244.235.203:53或10.244.235.204:53

    Service的访问规则会同时在集群内的所有节点上都生成,所以在任何一个节点上访问都可以

    3. ipvs的开启

    1. 验证是否安装ipvs。如下已经安装了IPVS
    [root@k8s-master ~]# ipvsadm -Ln
    IP Virtual Server version 1.2.1 (size=4096)
    Prot LocalAddress:Port Scheduler Flags
      -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
    [root@k8s-master ~]# 
    
    • 1
    • 2
    • 3
    • 4
    • 5
    1. 修改kube-proxy配置,将mode: ""修改成mode: "ipvs"
    [root@k8s-master ~]# kubectl edit cm kube-proxy -n kube-system
    configmap/kube-proxy edited
    [root@k8s-master ~]#
    
    • 1
    • 2
    • 3
    1. 删除所有节点的kube-proxy pod。然后DaemonSet会自动进行重建kube-proxy pod
    [root@k8s-master ~]# kubectl delete pod -l k8s-app=kube-proxy -n kube-system
    pod "kube-proxy-9gc7d" deleted
    pod "kube-proxy-f9w7h" deleted
    pod "kube-proxy-s8rwk" deleted
    [root@k8s-master ~]#
    
    • 1
    • 2
    • 3
    • 4
    • 5
    1. 测试ipvs模块是否开启成功
    [root@k8s-master ~]# ipvsadm -Ln
    IP Virtual Server version 1.2.1 (size=4096)
    Prot LocalAddress:Port Scheduler Flags
      -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
    ......省略部分......    
    TCP  10.96.0.10:53 rr
      -> 10.244.235.203:53            Masq    1      0          0         
      -> 10.244.235.204:53            Masq    1      0          0         
    TCP  10.96.0.10:9153 rr
      -> 10.244.235.203:9153          Masq    1      0          0         
      -> 10.244.235.204:9153          Masq    1      0          0         
    ......省略部分......      
    UDP  10.96.0.10:53 rr
      -> 10.244.235.203:53            Masq    1      0          0         
      -> 10.244.235.204:53            Masq    1      0          0         
    [root@k8s-master ~]# 
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16

    4. kube-proxy支持的三种工作模式

    4.1 userspace模式

    kube-proxy会为每一个Service创建一个监听端口,发向Cluster IP的请求被iptables规则重定向到kube-proxy监听的端口上,kube-proxy根据LB算法(负载均衡算法)选择一个提供服务的Pod并和其建立连接,以便将请求转发到Pod上

    该模式下,kube-proxy充当了一个四层负载均衡器的角色。由于kube-proxy运行在userspace中,在进行转发处理的时候会增加内核和用户空间之间的数据拷贝,虽然比较稳定,但是效率非常低下

    username

    4.2 iptables模式

    kube-proxy为Service后端的每个Pod创建对应的iptables规则,直接将发向Cluster IP的请求重定向到一个Pod的IP上

    该模式下kube-proxy不承担四层负载均衡器的角色,只负责创建iptables规则。该模式的优点在于较userspace模式效率更高,但是不能提供灵活的LB策略,而且当后端Pod不可用的时候无法进行重试

    iptables

    4.3 ipvs模式

    ipvs模式和iptables类似,kube-proxy监控Pod的变化并创建相应的ipvs规则。ipvs相对iptables转发效率更高,除此之外,ipvs支持更多的LB算法

    ipvs

    5. Service的类型和资源清单模板

    Service的资源清单模板

    apiVersion: v1                 
    kind: Service                   
    metadata:                      
      name: service                     # Service名称
      namespace: dev                    # Serivce所属的命名空间
    spec:
      selector:                         # 标签选择器,用于确定当前Service代理哪些Pod
        app: nginx-pod
      type: NodePort                    # Service的类型,指定Service的访问方式
      clusterIP: 10.96.68.68            # cluster虚拟服务的IP地址
      sessionAffinity: ClientIP         # session亲和性,支持ClientIP、None(默认)两个选项
      ports:                            # 端口信息
        - protocol: TCP                 # 协议,支持TCP(默认)和UDP
          port: 8080                    # cluster虚拟服务版本的端口,即Service端口
          targetPort: 8080              # Pod端口
          nodePort: 30080               # 主机端口。用于NodePort和LoadBalancer的Service类型。默认只能在端口范围(30000~32767)中指定。如果不指定,会自动分配一个
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16

    spec.type的说明:

    • ClusterIP:默认值,kubernetes系统自动分配虚拟IP(也可通过clusterIP手动指定),只能在集群内部访问
    • NodePort:将Service通过指定的Node上的端口暴露给外部,可以在集群外部访问服务。
    • LoadBalancer:使用外接负载均衡器完成服务的负载分发,此模式需要外部云环境的支持
    • ExternalName:把集群外部的服务引入集群内部,直接使用
  • 相关阅读:
    研报复现 | Alpha是否存在于日内股价跳跃中?
    基于springboot+vue的大学生交友活动管理网站 elementui
    A Self-Attentive model for Knowledge Tracing论文笔记和代码解析
    阿斯达年代记三强争霸账号怎么注册 游戏账号注册教程分享
    nodejs+vue旅行社网站系统-计算机毕业设计
    公网使用PLSQL远程连接Oracle数据库【内网穿透】
    java8 Optional理解及示例
    Linux开发讲课18--- “>file 2>&1“ 和 “2>&1 >file“ 的区别
    jmeter利用bean shell加密解密方法
    【ONE·Linux || 多线程(一)】
  • 原文地址:https://blog.csdn.net/yy8623977/article/details/124885428