【云原生】K8S--负载均衡详细介绍；什么是K8S的负载均衡？

于 2024-04-26 21:22:44 发布
阅读量36 收藏
点赞数
分类专栏： 软考-系统架构师 docker k8s 文章标签： kubernetes 云原生 负载均衡
原文链接：https://blog.csdn.net/weixin_39589455/article/details/125614300?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522171413753716800225522600%2522%252C%2522scm%2522%253A%252220140713.130102334.pc%255Fall.%2522%257D&request_id=171413753716800225522600&b
版权
目录

一、K8S云原生服务集群问题

（一）负载均衡原理

在之前的文章说过，每一个Pod都是独立的IP、HostName、存储，同时Pod是随时可以被动态创建和回收的，那么就有个问题，我们如何知道Pod的IP并进行访问的呢？ 其实K8S是使用Service VIP技术的虚拟ip + kube-proxy来解决这个问题，其中service VIP用来转发请求，kube-proxy用来监控pod状态，并且会及时修改pod的ip。

service是K8S的资源对象，service资源对象运行在每一个node节点上，每一个node节点都有一个service进程，service有自己的IP地址（虚拟IP），而service VIP相当于一个网关，所有的请求都要经过service VIP，通过service VIP进行转发，从而实现负载均衡。

service VIP一旦被创建，是不会被修改的，除非删除service后重新创建service；同时由于service信息存储在高可用的etcd中，且service实例运行在多个node节点上，因此Service VIP不存在单点故障的问题；由于service VIP中使用的是虚拟IP，因此Service VIP只能在局域网内部进行访问，不能通过外网进行访问，如果想要进行外网访问，则需要借助物理网卡进行端口映射转发。

在K8S中IP资源的分类如下：

  • Node IP：Node物理节点IP

  • Pod IP：物理机内部运行的一个虚拟容器pod的ip

  • cluster IP：集群IP，也是个虚拟IP，是K8S抽象出来的一个service的IP。此IP只能局域网内部访问，不能通过外网访问，如果要使用外网访问，就必须开辟nodeport类型的IP地址。如下图所示，外网访问物理IP，然后将访问请求映射到service VIP上，service VIP从etcd上获取endpoints中pod的IP，然后使用负载均衡策略选择一个pod进行调用

在这里插入图片描述

（二）Pod服务发现

Pod服务发现借助kube-proxy实现，该组件实现了三件事情：监控pod；pod如果发生了变化，及时修改映射关系；修改映射关系的同时，修改路由规则，以便在负载均衡时可以选择到新的pod。

在这里插入图片描述

二、负载均衡方案（四层负载）

K8S的负载均衡方案有三种：kube-proxy（userspace）、iptables（防火墙）、ipvs。

1、kube-proxy

使用kube-proxy的负载方案是使用kube-proxy来监控pod的状态，如果pod发生了变化，则需要kube-proxy去修改service和pod的映射关系（endpoints），同时修改路由规则，并且由kube-proxy转发请求，这种方式kube-proxy的压力比较大，性能可能会出现问题。
在这里插入图片描述

2、IPtables

IPtables是K8S默认采用的负载策略，这种方式中，kube-proxy同样用来监控pod和修改映射关系以及修改路由规则，但是转发请求是采用轮询iptables路由规则的方式进行调用处理的。

在这里插入图片描述
这种模式kube-proxy主要做好watching Cluster API即可，路由和请求的转发都交给了iptables，但是kube-proxy在请求无响应时会换一个pod进行重试，而iptables则是一条条的路由规则，不会进行重试。

在iptables中，默认的轮询策略是随机的轮询策略，但是也可以将其设置为轮询。

（1）设置为随机策略
# 随机：(Random balancing)
iptables -A PREROUTING -t nat -p tcp -d 192.168.1.1 --dport 27017 -m statistic --mode random --probability 0.33  -j DNAT --to-destination 10.0.0.2:1234
iptables -A PREROUTING -t nat -p tcp -d 192.168.1.1 --dport 27017 -m statistic --mode random --probability 0.5 -j DNAT --to-destination 10.0.0.3:1234
iptables -A PREROUTING -t nat -p tcp -d 192.168.1.1 --dport 27017  -j DNAT --to-destination 10.0.0.4:1234

在iptables命令中，命令的执行和顺序有关，在上述命令中，用–probability 设置了命中几率，第一条设置了纪律是0.33，也就是整个请求的0.33，第二条命中率为0.5，实际是剩余请求的0.5，也就是总请求的0.335，第三条是剩余的流量全部打到该ip上，也就是0.335，基本上就是随机分配了。

（2）设置为轮询策略
#every：每n个包匹配一次规则
#packet：从第p个包开始
iptables -A PREROUTING -t nat -p tcp -d 192.168.1.1 --dport 27017 -m statistic --mode nth --every 3 --packet 0 -j DNAT --to-destination 10.0.0.2:1234
iptables -A PREROUTING -t nat -p tcp -d 192.168.1.1 --dport 27017 -m statistic --mode nth --every 2 --packet 0  -j DNAT --to-destination 10.0.0.3:1234
iptables -A PREROUTING -t nat -p tcp -d 192.168.1.1 --dport 27017 -j DNAT --to-destination 10.0.0.4:1234

3、IPVS

ipvs (IP Virtual Server) 实现传输层负载均衡，通常称为第四层LAN交换，是Linux内核的一部分。

ipvs与iptables的区别：

  • ipvs为大型集群提供了更好的可扩展性和性能

  • ipvs支持比iptables更复杂的负载均衡算法

  • ipvs支持服务器的健康检查和连接重试等。

对于上述差异做个说明：

在linux中iptables设计是用于防火墙的，对于比较少的规则，没有太多的性能影响，如果对于一个庞大的K8S集群，会有上千Service服务，Service服务会对应多个pod，每条都是一个iptables规则，那么对于集群来说，每个node上都有大量的规则，简直是噩梦。而IPVS则是使用hash tables来存储网络转发规则的，比iptables更有优势，而且ipvs主要工作在kerbespace，减少了上下文的切换。

IPVS有轮询（rr）、最小连接数（lc）、目的地址hash（dh）、源地址hash（sh）、最短期望延迟（sed）、无须队列等待（nq）等负载均衡算法，在node上通过 “–ipvs-scheduler”参数，指定kube-proxy的启动算法。

kube-proxy和IPVS合作的流程：

（1）kube-proxy仍然是watching Cluster API，获取新建、删除Service或Endpoint pod指令，如果有新的Service建立，kube-proxy回调网络接口，构建IPVS规则。

（2）kube-proxy会定期同步Service和Pod的转发规则，确保失效的转发可以被及时修复

（3）有请求转发到后端的集群时，IPVS的负载均衡直接将其转发到对应的Pod上

三、Ingres-nginx（七层负载均衡）

（一）为什么要使用Ingres

1、先介绍以下部署K8S服务时使用到的配置文件：

创建配置文件（ingres.yaml），用来部署一个nginx的deployment和service

# 创建一个service资源对象
# kubectl expose deployment xxName –port=80 –target-port=80    k8s指令模式创建一个service
# k8s部署yaml方式
apiVersion: v1
kind: Service
metadata:
  name: nginx
  namespace: default
spec:
  selector:
    app: nginx
  ports:
  - port: 80
    targetPort: 80
---

# 部署deployment对象，k8s创建3个资源对象：Deployment,ReplicaSet,POD
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.16
        ports:
        - containerPort: 80

对上面的配置文件做个描述：
在这里插入图片描述

首先看Deployment：

apiVersion标记版本，Kind标记类型，说明要创建一个Deployment，该deployment的名字叫nginx，空间为默认空间。

spec下是rs和pod的配置，首先replicas是副本的数量，然后就是选择器的名称为nginx。

template下是副本的配置，首先副本的标签是nginx，容器的名字是nginx，镜像为nginx1.16，这里可以配置为镜像仓库地址和对应的镜像，最后ports是容器开放的端口。

这里说明几个比较重要的配置，就是选择器的名称和容器的标签一定要一致（绿色连接线），否则容器不会被副本控制器RS所控制。

然后说一下Service：

apiVersion和Kind都和Deployment一样，Kind的值表明了这是一个Service配置。

然后就是这个service的名字，service标签选择器的名字，以及目标容器的端口。

这里说几个比较重要的配置，和Deployment一样，选择器的名字要和容器的名字一致（绿色连接线），目标容器端口要和容器的端口保持一致（紫色连接线）

执行配置文件，生成deployment和service：

kubectl apply -f ingres.yaml
  • 1

执行后查看deployment、service、rs、pod的情况（注意：这一步一般时间比较久，需要等一会）
在这里插入图片描述
从上面图片的输出中可以看到，nginx的type为ClusterIp，这种类型的service只能在集群内部访问，而不能在外部直接访问，那么就需要修改类型为NodePort，修改命令：

kubectl edit svc nginx
  • 1

在这里插入图片描述
　更改完毕之后，重新查看service，发现type已经变为NodePort，且port也变更了，前面的80是容器内的端口，后面的31758是对外开放的端口，也就是宿主机的端口。
在这里插入图片描述
此时，使用宿主机的ip + 31758访问，即可访问nginx

在这里插入图片描述
但是有个问题，就是如果每个服务都要对外开启一个端口，那么就需要开启很多的端口，这样即麻烦又有点浪费，因此就需要Ingres来解决这个问题，Ingres只需要一个NodePort就可以解决上述的问题。因为ingress相当于一个7层的负载均衡器，是k8s对反向代理的一个抽象。大概的工作原理也确实类似于Nginx，可以理解成在 Ingress 里建立一个个映射规则 , ingress Controller 通过监听 Ingress这个api对象里的配置规则并转化成 Nginx 的配置（kubernetes声明式API和控制循环） , 然后对外部提供服务。

（二）Ingres-Nginx介绍

Ingres是K8S对于nginx进行云原生模式的封装，使得nginx更适合云原生的结构，使用Ingres可以对Service进行负载均衡，因此Ingres工作在七层，属于七层负载均衡。

Ingres通过http协议的方式实现Service的负载均衡：
在这里插入图片描述
对于K8S来说，Ingres就是一个资源控制器，用来控制资源的访问策略，

（三）部署Ingres及使用同一个域名访问不同服务

Ingres的配置文件如下所示：

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: nginx
  namespace: default
  labels:
    app: nginx
spec:
  rules:
  - host: ingress.lcl.com
    http:
      paths:
      - backend:
          serviceName: nginx
          servicePort: 80
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15

在上面文件中，配置了Ingres的规则，那么对于使用同一个域名访问不同服务的配置，则是在paths下面增加多个path路径，让path指向不同的服务，并且在metadata中新增请求重写配置annotations，去除path的路径，保证访问到指定服务上的路径不带有该path，具体配置如下所示：

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: nginx
  namespace: default
  labels:
    app: nginx
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: / # 请求重写
spec: 
  rules:
  - host: ingress.lcl.com
    http:
      paths:
        - path: /nginx   # 把path追加到域名后面 ingress.lcl.com/nginx   把/nignx当成服务请求的一部分
          backend:
            serviceName: nginx
            servicePort: 80
        - path: /tomcat
          backend:
            serviceName: tomcat
            servicePort: 8080

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22

（四）不同域名访问不同服务

不同域名访问不同服务主要是在rules下面配置不同的规则即可。

# 使用多个域名，访问不同的服务
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: nginx
  namespace: default
  labels:
    app: nginx
spec:
  rules:
  - host: ingress.lcl.com
    http:
      paths:
      - path: /
        backend:
         serviceName: nginx
         servicePort: 80
  - host: ingress.lcl.com
    http:
      paths:
      - path: /
        backend:
         serviceName: tomcat
         servicePort: 8080

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24

（五）Ingres和https

如果想将http请求升级为https，我们就需要制作证书

# 生成私钥
openssl genrsa -out lcl.key 2048
# 自签发证书
openssl req -new -x509 -key lcl.key -out lcl.crt -subj /C=CN/ST=Shanghai/L=Shanghai/O=DevOps/CN=ingres.lcl.com
# 创建K8S使用的证书
kubectl create secret tls lcl-secret --cert=lcl.crt --key=lcl.key
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6

创建ingres，使用证书的Ingres

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ingress-tomcat-tls
  namespace: default
  annotations:
    kubernetes.io/ingress.class: "nginx"
  labels:
    app: tomcat
spec:
  tls:
  - hosts:
    - ingress.lcl.com
    secretName: lcl
  rules:
  - host: ingres.lcl.com
    http:
      paths:
        - backend:
            serviceName: nginx
            servicePort: 8080

查看secret资源

修改原来的ingres配置文件

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: nginx
  namespace: default
  labels:
    app: nginx
spec:
  tls:
  - hosts:
    - ingres.lcl.com
    secretName: lcl-secret
  rules:
  - host: ingress.lcl.com
    http:
      paths:
      - backend:
          serviceName: nginx
          servicePort: 80
zhousenshan
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
云原生k8s-kubernetes
07-06
ansible
云原生工程师-6.k8s四层负载均衡-Service
qq_16688317的博客
03-16 1719
在 kubernetes 中，Pod 是有生命周期的，如果 Pod 重启它的 IP 很有可能会发生变化。
[云原生专题-33]：K8S - 核心概念 - 服务Service管理、服务发现、负载均衡
文火冰糖（王文兵）的博客
02-08 2万+
作者主页(文火冰糖的硅基工坊)：文火冰糖（王文兵）的博客_文火冰糖的硅基工坊_CSDN博客 本文网址： 目录 前言： 第1章 服务Service管理概述 1.1 为什么需要服务? 1.2 什么是服务 1.3Service与Deployment的关系 1.4 总体的网络架构 第2章Service的类型与架构 2.1 ClusterIP Sevice 2.2 NodePort Sevice： 2.3 LoadBalancer Sevice： 第3章 Service相关的主要..
k8s系列07-负载均衡器之OpenELB
tinychen
05-24 1367
本文主要在k8s原生集群上部署v0.4.4版本的OpenELB作为k8s的LoadBalancer，主要涉及OpenELB的Layer2模式和BGP模式两种部署方案。由于BGP的相关原理和配置比较复杂，这里仅涉及简单的BGP配置。 文中使用的k8s集群是在CentOS7系统上基于docker和calico组件部署v1.23.6版本，此前写的一些关于k8s基础知识和集群搭建的一些方案，有需要的同学可以看一下。 1、工作原理 1.1 简介 OpenELB 是一个开源的云原生负载均衡器实现，可以在基于裸金属服务器
k8s系列08-负载均衡器之PureLB
tinychen
05-24 1019
本文主要在k8s原生集群上部署v0.6.1版本的PureLB作为k8s的LoadBalancer，主要涉及PureLB的Layer2模式和ECMP模式两种部署方案。由于PureLB的ECMP支持多种路由协议，这里选用的是在k8s中常见的BGP进行配置。由于BGP的相关原理和配置比较复杂，这里仅涉及简单的BGP配置。 文中使用的k8s集群是在CentOS7系统上基于docker和cilium组件部署v1.23.6版本，此前写的一些关于k8s基础知识和集群搭建的一些方案，有需要的同学可以看一下。 1、工作原理
k8s系列06-负载均衡器之MatelLB
tinychen
05-24 873
本文主要在k8s原生集群上部署v0.12.1版本的MetalLB作为k8s的LoadBalancer，主要涉及MetalLB的Layer2模式和BGP模式两种部署方案。由于BGP的相关原理和配置比较复杂，这里仅涉及简单的BGP配置。 文中使用的k8s集群是在CentOS7系统上基于docker和flannel组件部署v1.23.6版本，此前写的一些关于k8s基础知识和集群搭建的一些方案，有需要的同学可以看一下。 1、工作原理 1.1 简介 在开始之前，我们需要了解一下MetalLB的工作原理。 Metal
k8s二进制及负载均衡集群部署详解
qq_51545656的博客
02-01 1406
然后，使用 cfssl 工具根据 ca.pem、ca-key.pem、ca-config.json 和 kube-proxy-csr.json 文件生成 kube-proxy 的证书和私钥，命名为 kube-proxy.pem 和 kube-proxy-key.pem。然后，使用 cfssl 工具根据 ca.pem、ca-key.pem、ca-config.json 和 admin-csr.json 文件生成 admin 的证书和私钥，命名为 admin.pem 和 admin-key.pem。
[云原生专题-40]：K8S - 核心概念 - 网络模型、网络通信、集群内负载均衡机制（重要重要重要）
文火冰糖（王文兵）的博客
02-12 2万+
作者主页(文火冰糖的硅基工坊)：文火冰糖（王文兵）的博客_文火冰糖的硅基工坊_CSDN博客 本文网址：https://blog.csdn.net/HiWangWenBing/article/details/122806829 目录 第1章 K8S集群的网络模型概述 1.1 什么是K8S集群的网络模型 1.2 K8S为什么需要网络模型 1.3 K8S集群网络设计的基本原则 1.4K8S集群的网络类型 1.5四层模型 第2章Docker容器和Docker容器之间的网络与通信 第3章P...
【云原生 • Kubernetes】k8s功能特性、k8s集群架构介绍
热门推荐
商务合作 | 共同学习 | 携手共进
08-05 6万+
Kubernetes 功能和特性介绍、k8s 集群架构理论体系介绍，k8s 核心概念。
【云原生 | Envoy 系列】--Envoy负载均衡策略
Q先生
10-09 1016
【云原生 | Kubernetes 系列】--Envoy负载均衡策略
云原生-基于k8s部署-分布式底层存储-Rook-Ceph
06-13
分布式存储系统是一个有效的解决有状态工作负载高可用问题的方案。Ceph 就是一个分布式存储系统，近年来其影响主键扩大。Rook 是一个编排器，能够支持包括 Ceph 在内的多种存储方案。Rook 简化了 Ceph 在 Kubernetes...
云原生 k8s HPA components.yaml
最新发布
03-06
云原生 k8s HPA components.yaml，搭建metrics server环境，适用于外网下载不到文件的小伙伴，镜像仓库地址已改为阿里云国内镜像，必要的配置也已配置完成，助你快速完成metrics server环境搭建。云原生 k8s HPA ...
如何基于标准k8s打造边缘计算云原生基础设施？
01-27
云原生的理念如今正如火如荼。它不仅仅是一种技术，更是随着云生态的发展而被逐渐提炼出的一系列技术、最佳实践与方法论的集合；它带来了资源利用率提升、分布式系统的弹性扩展与可靠性等能力，能够让IT系统最大程度...
云原生Docker和K8S 03-K8S架构和流程
08-10
云原生Docker和K8S 03-K8S架构和流程
云原生k8s部署流水线
09-22
云原生k8s部署流水线
云原生培训-PaaS云平台项目k8s&ocp原厂性能测试方案
03-16
云原生培训-PaaS云平台项目k8s&ocp原厂性能测试方案
云原生-浏览器操作-centos7系统-镜像构建-k8s集群部署
07-03
本文用于通过Dockerfile构建一个内置vnc及novnc转发的部署后可以直接由浏览器操作centos7系统（理论上可以换成ubuntu操作系统）的镜像，并提供了云原生k8s集群环境下的部署使用文档。 本文适用于构建镜像提供给linux...
云原生+k8s+面试题集锦+128题
10-25
需要面试k8s相关岗位的小朋友来取，增加面试过关率
云原生和云平台、k8s、微服务的关联
03-28
云原生是一种软件开发和部署的方法论，旨在利用云计算的优势，实现更快、更灵活、更可靠的部署和运行。云原生的核心是容器化和微服务化，通过将应用程序打包成容器，使其更易于部署、扩展和管理。同时，云原生也强调自动化、可观察性、故障恢复等方面的技术和实践。 云平台是云计算的基础设施，提供了计算、存储、网络等基础服务。云平台可以提供虚拟机、容器、对象存储等不同的计算和存储资源，以满足不同的应用需求。云平台也提供了自动化的管理服务，如负载均衡、弹性伸缩、安全等，帮助用户快速构建和管理应用程序。 Kubernetes（简称K8s）是一种容器编排平台，提供了容器编排、自动化部署、扩展、负载均衡等功能。K8s可以自动管理应用程序的容器，使其更易于部署、扩展和管理。K8s也提供了自动化的管理服务，如服务发现、故障恢复、滚动升级等，帮助用户快速构建和管理应用程序。 微服务是一种架构风格，将应用程序划分成小型服务，每个服务独立部署和扩展。微服务架构强调松耦合、高内聚、自治性等特点，使得应用程序更易于扩展和维护。微服务也可以利用容器技术进行部署和管理，实现更高效的运维。 综上所述，云原生、云平台、K8s和微服务都是云计算中的重要概念和技术，它们之间存在密切的关联。云平台提供了基础设施和自动化管理服务，支持云原生应用程序的部署和运行；K8s提供了容器编排和自动化管理服务，支持微服务架构的部署和运行；云原生、云平台、K8s和微服务共同构成了现代化的云计算架构，使得企业可以更加敏捷、高效地开发和运营应用程序。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值