【云原生】学习K8s，读完这篇就够了

「爱情、让人受尽委屈。」 2023-10-02 21:07 113阅读 0赞

#### 目录 ####

*  前言
 *  K8s集群架构及核心概念
 *   *  架构图
     *  K8s组件
     *   *  api service
         *  controller manager
         *  scheduler
         *  etcd
         *  kubelet
         *  kube-proxy
         *  其他重要插件：
     *  K8s资源
     *   *  1.名称空间级资源
         *  2.集群级资源
         *  3.元数据型资源
     *  工作负载
     *   *  Node
     *  节点管理
     *   *  节点控制器（Node Controller）
         *  节点自注册 （Self-Registration）
     *  Pod
     *   *  Pod创建流程
         *  Pod的定义
 *  服务发现、负载均衡、网络
 *   *  服务代理
     *   *  User space 代理模式
         *  Iptables 代理模式--默认模式
         *  IPVS 代理模式
     *  服务发现--DNS
     *   *  Service 类型
         *  Ingress
     *  K8s网络
     *   *  容器网络
         *  Flannel插件

--------------------

## 前言 ##

在容器化时代，虽然Docker已经很强大了，但是在实际使用上还是有诸多不便，比如集群管理、资源调度、文件管理等等。

不过目前也涌现了很多解决方案，比如 Mesos、Swarm、Kubernetes 等等，其中谷歌开源的Kubernetes就是其中的王者！

它是基于容器的集群编排引擎，具备扩展集群、滚动升级回滚、弹性伸缩、自动治愈、服务发现等多种特性能力。

学习K8s，需要了解K8s常见的应用场景和核心概念。内容丰富，建议收藏！！

--------------------

## K8s集群架构及核心概念 ##

### 架构图 ###

![图片][f79b9bd7521a50fc2450a261a3f87015.png]

### K8s组件 ###

#### api service ####

所有服务访问统一入口。对外暴露K8s的api接口，是外界进行资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制。

#### controller manager ####

负责维护集群的状态，比如故障检测、自动扩展、滚动更新等，他们是处理集群中常规任务的后台线程。

#### scheduler ####

负责资源的调度，按照预定的调度策略将Pod调度到响应的机器上；就是监视新创建的Pod，如果没有分配节点，就选择一个节点供他们运行，这就是Pod的调度。

#### etcd ####

一个可信赖的分布式键值存储服务，能够为整个分布式集群存储一些关键数据，协助分布式集群运转。储存K8s集群所有重要信息（持久化）。

v2版本是基于内存的存储，v3开始才是序列化到介质。

新版K8s(v1.11以上)已经改用v3版本的etcd。

#### kubelet ####

直接跟容器引擎交互实现容器的生命周期管理。

#### kube-proxy ####

负责写入规则至iptables、ipvs实现服务映射访问。

其中scheduler和controller-manager两个组件是有leader选举的，这个选举机制是K8s对于这两个组件的高可用保障。Api server是可以水平扩展的。

#### 其他重要插件： ####

*  CoreDNS
    
    可以为集群中的SVC创建一个域名IP的对应解析关系。
 *  Dashboard
    
    给K8s集群提供一个B/S结构访问体系。
 *  Ingress Controller
    
    官方只能实现四层代理，ingress可以实现七层代理。
 *  Federation
    
    提供一个可以跨集群中心多K8s统一管理功能。
 *  Prometheus
    
    提供K8s集群的监控能力。
 *  ELK
    
    提供K8s集群日志统一分析介入平台。

### K8s资源 ###

K8S中的所有内容都抽象为资源，资源实例化后叫做对象。

在K8S中，一般使用yaml格式的文件来创建符合我们预期的Pod，这种yaml文件一般被称为资源清单。

K8s中的资源可分为三种：

#### 1.名称空间级资源 ####

通过：

kubectl api-resources --namespaced=true查看全部。

K8S是有空间概念的，以下资源是归属于某个空间的（没有指定就是默认空间default）。

同时也可以根据功能分为以下集中：

*  工作负载型
    
    Pod、ReplicaSet（Replication
    
    Controller在v1.11版本废弃）、Deployment、StatefulSet、DaemonSet、Job、CronJob
 *  服务发现及负载均衡型
    
    Service、Ingress等
 *  配置与存储型
    
    Volume、CSI（容器存储接口，可以扩展各种各样的第三方存储卷）
 *  特殊类型的存储卷
    
    ConfigMap（当做配置中心来使用的资源类型）、Secret（保存敏感数据）、DownwardAPI（把外部环境中的信息输出给容器）

#### 2.集群级资源 ####

通过：、

kubectl api-resources --namespaced=false 查看全部。

Namespace、Node、Role、ClusterRole、RoleBinding、ClusterRoleBinding

#### 3.元数据型资源 ####

HPA、PodTemplate、LimitRange

**资源清单常用字段：**

yaml文件是K8s资源声明表达的格式。各种资源通用的常用字段如下：

![图片][9579d82134badcb8d03c6a64cd97c42e.png]

![图片][fd3f327a040ff553658ed5717c2e7bd4.png]

### 工作负载 ###

#### Node ####

K8s中节点（node）指的是一个工作机器，曾经叫做minion。

不同的集群中，节点可能是虚拟机，也可能是物理机。每个节点都由master组件管理，并包含了运行Pod（容器组）所需的服务。

这些服务包括：容器引擎、kubelet、kube-proxy。

kubectl get nodes -o wide 查看所有节点的列表。

kubectl describe node 查看节点状态以及节点的其他详细信息。

输出的节点状态包括以下信息：

*  Addersses
    
    包括内外部IP、hostname等信息。
 *  Conditions
    
    描述了节点的硬盘、内存、进程数等压力状态。
 *  Capacity and Allocatable
    
    描述节点上的可用资源如CPU、内存、该节点可调度的最大pod数等情况。
 *  Info
    
    描述了节点的基本信息，如Linux内核版本、Kubernetes版本、Docker版本、操作系统名称等。

### 节点管理 ###

与Pod和Service不一样，节点并不是由Kubernetes创建的，节点由云供应商创建。

向Kubernetes中创建节点时，仅仅是创建了一个描述该节点的API对象。

节点API对象创建成功后，Kubernetes将检查该节点是否有效。

例如，假设创建如下节点信息：

![图片][e39cfd938790f01568465211e2003a34.png]

Kubernetes在APIServer上创建一个节点API对象（节点的描述），并且基于metadata.name字段对节点进行健康检查。

如果节点有效，则可以向该节点调度Pod；否则，该节点API对象将被忽略，直到节点变为有效状态。

#### 节点控制器（Node Controller） ####

这是一个负责管理节点的Kubernetes master组件。在节点的生命周期中，节点控制器起到了许多作用：

**1.** 在注册节点时为节点分配CIDR地址块。

**2.** 通过云供应商（cloud-controller-manager）接口，检查节点列表中每一个节点对象对应的虚拟机是否可用。在云环境中，只要节点状态异常，节点控制器检查其虚拟机在云供应商的状态，如果虚拟机不可用，自动将节点对象从APIServer中删除。

**3.** 监控节点的健康状况。当节点变得不可触达时（例如，由于节点已停机，节点控制器不再收到来自节点的心跳新号），节点控制器将节点API对象的NodeStatusCondition取值从NodeReady更新为Unknown；然后在等待pod-eviction-timeout时间后，将节点上的所有Pod从节点驱逐。

#### 节点自注册 （Self-Registration） ####

如果Kubelet的启动参数–register-node为true（默认为true），kubelet会尝试将自己注册到APIServer。

Kubelet自行注册时，将使用以下选项：

*  –kubeconfig：向apiserver进行认证时所用身份信息的路径
 *  –cloud-provider：向云供应商读取节点自身元数据
 *  –register-node：自动向API Server祖册节点
 *  –register-with-taints：注册节点时，为节点添加污点（逗号分隔，格式为=:）
 *  –node-ip：节点的IP地址
 *  –node-labels：注册节点时，为节点添加标签
 *  –node-status-update-frequency：向master节点发送心跳信息的时间间隔

如果 Node authorization mode (opens new window)和 NodeRestriction admission plugin (opens new window)被启用，kubelet 只拥有创建/修改其自身所对应的节点 API 对象的权限。

### Pod ###

Pod（容器组）是 Kubernetes 中最小的可部署单元。

一个 Pod（容器组）包含了一个应用程序容器（某些情况下是多个容器）、存储资源、一个唯一的网络 IP 地址、以及一些确定容器该如何运行的选项。

Pod 容器组代表了 Kubernetes 中一个独立的应用程序运行实例，该实例可能由单个容器或者几个紧耦合在一起的容器组成。

一个Pod是容器环境下的“逻辑主机”，它可能包含一个或者多个紧密相连的应用，这些应用可能是在同一个物理主机或虚拟机上。

Pod 的context可以理解成多个linux命名空间的联合：

*  PID 命名空间
    
    同一个Pod中应用可以看到其它进程。
 *  网络 命名空间
    
    同一个Pod的中的应用对相同的IP地址和端口有权限。
 *  IPC 命名空间
    
    同一个Pod中的应用可以通过VPC或者POSIX进行通信。
 *  UTS 命名空间
    
    同一个Pod中的应用共享一个主机名称。

注：同一个Pod中的应用可以共享磁盘，磁盘是Pod级的，应用可以通过文件系统调用。

#### Pod创建流程 ####

创建Pod的整个流程，时序图如下：

![图片][63e605544a41b5aae9f91baeff1137c0.png]

注：

1、用户提交创建Pod的请求，可以通过API Server的REST API ，也可用Kubectl命令行工具，支持Json和Yaml两种格式。

2、API Server 处理用户请求，存储Pod数据到Etcd。

3、Schedule通过和 API Server的watch机制，查看到新的pod，尝试为Pod绑定Node。调度器用一组规则过滤掉不符合要求的主机，比如Pod指定了所需要的资源，那么就要过滤掉资源不够的主机，对上一步筛选出的符合要求的主机进行打分，在主机打分阶段，调度器会考虑一些整体优化策略进行调度；选择打分最高的主机，进行binding操作，结果存储到Etcd中。

4、kubelet根据调度结果执行Pod创建操作。绑定成功后，会启动container。scheduler会调用API Server的API在etcd中创建一个bound pod对象，描述在一个工作节点上绑定运行的所有pod信息。运行在每个工作节点上的kubelet也会定期与etcd同步bound pod信息。

#### Pod的定义 ####

可以通过kubectl explain pod 查看pod yaml定义的顶级属性，然后通过类似 kubectl explain pod.\{顶级属性\}查看二级属性的细节定义。

下面给出一个pod资源定义的样例，对pod的描述有一个初步了解。

apiVersion: v1  #与k8s集群版本有关，使用 kubectl api-versions 即可查看当前集群支持的版本
    kind: Pod   #该配置的类型，我们使用的是Pod
    metadata:           #译名为元数据，即 Pod 的一些基本属性和信息
      name: nginx-pod   #Pod 的名称
      labels:       #标签，可以灵活定位一个或多个资源，其中key和value均可自定义，可以定义多组，目前不需要理解
        app: nginx  #为该Deployment设置key为app，value为nginx的标签
    spec:       #期望Pod实现的功能（即在pod中部署）
      containers:   #生成container，与docker中的container是同一种
      - name: nginx #container的名称
        image: nginx:1.7.9  #使用镜像nginx:1.7.9创建container，该container默认80端口可访问

保存为nginx-pod.yaml文件，通过kubectl apply -f nginx-pod.yaml启动pod。通过kubectl get pods -o wide查看pod的启动情况。

--------------------

## 服务发现、负载均衡、网络 ##

Kubernetes 中 Service 是一个 API 对象，通过 kubectl + YAML 定义一个 Service，可以将符合 Service 指定条件的 Pod ，作为可通过网络访问的服务提供给服务调用者。

Service 是 Kubernetes 中的一种服务发现机制：

*  Pod 有自己的 IP 地址
 *  Service 被赋予一个唯一的 dns name
 *  Service 通过 label selector 选定一组 Pod
 *  Service 实现负载均衡，可将请求均衡分发到选定这一组 Pod 中

例如，假设您有一组 Pod：

*  每个 Pod 都监听 9376 TCP 端口
 *  每个 Pod 都有标签 app=MyApp

下面文件可用来创建一个 Service(名字为 my-service)：

apiVersion: v1
    kind: Service
    metadata:
      name: my-service
    spec:
      selector:
        app: MyApp
      ports:
        - protocol: TCP
          port: 80
          targetPort: 9376

Service 从自己的 IP 地址和 port 端口接收请求，并将请求映射到符合条件的 Pod 的 targetPort。

为了方便，默认 targetPort 的取值 与 port 字段相同

*  Kubernetes 将为该 Service 分配一个 IP 地址（ClusterIP 或 集群内 IP），供 Service Proxy 使用
 *  Kubernetes 将不断扫描符合该 selector 的 Pod，并将最新的结果更新到与 Service 同名 my-service 的 Endpoint 对象中

### 服务代理 ###

Kubernetes 集群中的每个节点都运行了一个 kube-proxy。

负责为 Service （ExternalName 类型的除外） 提供虚拟 IP 访问。

Kubernetes 支持三种 proxy mode（代理模式），他们的版本兼容性如下：

![图片][64d499df11b3f7e78dc94713d88ba68c.png]

#### User space 代理模式 ####

*  kube-proxy 监听 kubernetes master以获得添加和移除 Service / Endpoint 的事件
 *  kube-proxy 在其所在的节点（每个节点都有 kube-proxy）上为每一个 Service 打开一个随机端口
 *  kube-proxy 安装 iptables 规则，将发送到该 Service 的 ClusterIP（虚拟 IP）/ Port 的请求重定向到该随机端口
 *  任何发送到该随机端口的请求将被代理转发到该 Service 的后端 Pod 上（kube-proxy 从 Endpoint 信息中获得可用 Pod）
 *  kube-proxy 在决定将请求转发到后端哪一个 Pod 时，默认使用 round-robin（轮询）算法，并会考虑到 Service 中的 SessionAffinity 的设定

如下图所示：

![图片][64837cc4a21458dbce2a38b0fd326936.png]

#### Iptables 代理模式–默认模式 ####

*  kube-proxy 监听 kubernetes master 以获得添加和移除 Service / Endpoint 的事件
 *  kube-proxy 在其所在的节点（每个节点都有 kube-proxy）上为每一个 Service 安装 iptable 规则
 *  iptables 将发送到 Service 的 ClusterIP / Port 的请求重定向到 Service 的后端 Pod 上
 *  对于 Service 中的每一个 Endpoint，kube-proxy 安装一个 iptable 规则。默认情况下，kube-proxy 随机选择一个 Service 的后端 Pod

如下图所示：

![图片][302772a7a5f40691ec92372a5d476933.png]

**iptables proxy mode 的优点：**

*  更低的系统开销
    
    在 linux netfilter 处理请求，无需在 userspace 和 kernel space 之间切换
 *  更稳定

**与 user space mode 的差异：**

*  使用 iptables mode 时
    
    如果第一个 Pod 没有响应，则创建连接失败
 *  使用 user space mode 时
    
    如果第一个 Pod 没有响应，kube-proxy 会自动尝试连接另外一个后端 Pod

您可以配置 Pod 就绪检查（readiness probe）确保后端 Pod 正常工作。

此时，在 iptables 模式下 kube-proxy 将只使用健康的后端 Pod，从而避免了 kube-proxy 将请求转发到已经存在问题的 Pod 上。

#### IPVS 代理模式 ####

*  kube-proxy 监听 kubernetes master 以获得添加和移除 Service / Endpoint 的事件
 *  kube-proxy 根据监听到的事件，调用 netlink 接口，创建 IPVS 规则；并且将 Service/Endpoint 的变化同步到 IPVS 规则中
 *  当访问一个 Service 时，IPVS 将请求重定向到后端 Pod

如下图所示：

![图片][0cedda270bc77c262262fdd32eea0c0a.png]

IPVS proxy mode 基于 netfilter 的 hook 功能，与 iptables 代理模式相似，但是 IPVS 代理模式使用 hash table 作为底层的数据结构，并在 kernel space 运作。

**这就意味着：**

*  IPVS 代理模式可以比 iptables 代理模式有更低的网络延迟，在同步代理规则时，也有更高的效率
 *  与 user space 代理模式 / iptables 代理模式相比，IPVS 模式可以支持更大的网络流量

**IPVS 提供更多的负载均衡选项：**

*  rr: round-robin
 *  lc: least connection (最小打开的连接数)
 *  dh: destination hashing
 *  sh: source hashing
 *  sed: shortest expected delay
 *  nq: never queue

在所有的代理模式中，发送到 Service 的 IP:Port 的请求，将被转发到一个合适的后端 Pod，而无需调用者知道任何关于 Kubernetes/Service/Pods 的细节。

### 服务发现–DNS ###

安装了K8s插件-- DNS 服务，Core DNS (opens new window)。

Kubernetes 集群中就会运行一组 DNS Pod，配置了对应的 Service，并由 kubelete 将 DNS Service 的 IP 地址配置到节点上的容器中以便解析 DNS names。

CoreDNS 监听 Kubernetes API 上创建和删除 Service 的事件，并为每一个 Service 创建一条 DNS 记录。

集群中所有的 Pod 都可以使用 DNS Name 解析到 Service 的 IP 地址。

例如：

名称空间 my-ns 中的 Service my-service，将对应一条 DNS 记录 my-service.my-ns。

名称空间 my-ns 中的Pod可以直接 nslookup my-service （my-service.my-ns 也可以）。

其他名称空间的 Pod 必须使用 my-service.my-ns。my-service 和 my-service.my-ns 都将被解析到 Service 的 Cluster IP。

#### Service 类型 ####

Kubernetes 中可以通过不同方式发布 Service，通过 ServiceType 字段指定，该字段的默认值是 ClusterIP。

可选值有：

*  ClusterIP: 默认值。
    
    通过集群内部的一个Cluster IP 地址暴露 Service，只在集群内部可以访问。
 *  NodePort
    
    通过每一个节点上的的静态端口（NodePort）暴露 Service，同时自动创建 ClusterIP 类型的访问方式。
    
    在集群内部通过(ClusterIP):(Port) 访问，  
    在集群外部通过 (NodeIP):(NodePort) 访问。
 *  LoadBalancer
    
    通过云服务供应商（AWS、Azure、GCE 等）的负载均衡器在集群外部暴露 Service，同时自动创建 NodePort 和 ClusterIP 类型的访问方式。LoadBalancer是将 .spec.type 字段设置为 LoadBalancer，Kubernetes 将为该Service 自动创建一个负载均衡器。
    
    负载均衡器的创建操作异步完成，您可能要稍等片刻才能真正完成创建，负载均衡器的信息将被回写到 Service 的.status.loadBalancer 字段。  
    在集群内部通过 (ClusterIP):(Port) 访问  
    在集群外部通过 (NodeIP):(NodePort) 访问  
    在集群外部通过 (LoadBalancerIP):(Port) 访问。
 *  ExternalName
    
    将 Service 映射到 externalName 指定的地址（例如：foo.bar.example.com），返回值是一个 CNAME 记录。不使用任何代理机制。ExternalName 类型的 Service 映射到一个外部的 DNS name，而不是一个 pod label selector。可通过 spec.externalName 字段指定外部 DNS name。
 *  External IP
    
    如果有外部 IP 路由到 Kubernetes 集群的一个或多个节点，Kubernetes Service 可以通过这些 externalIPs 进行访问。externalIP 需要由集群管理员在 Kubernetes 之外配置。  
    在 Service 的定义中， externalIPs 可以和任何类型的 .spec.type 一通使用。

#### Ingress ####

Ingress 是 Kubernetes 的一种 API 对象，将集群内部的 Service 通过 HTTP/HTTPS 方式暴露到集群外部，并通过规则定义 HTTP/HTTPS 的路由。

Ingress 具备如下特性：集群外部可访问的 URL、负载均衡、SSL Termination、按域名路由（name-based virtual hosting）。

Ingress 的例子如下所示：

apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: my-ingress-for-nginx  # Ingress 的名字，仅用于标识
    spec:
      rules:                      # Ingress 中定义 L7 路由规则
      - host: demo.my-company.com   # 根据 virtual hostname 进行路由（请使用您自己的域名）
        http:
          paths:                  # 按路径进行路由
          - path: /
            backend:
              serviceName: nginx-service  # 指定后端的 Service 为之前创建的 nginx-service
              servicePort: 80

Ingress Controller 通常是部署在集群中的一个 Deployment，并且通过 NodePort Service 暴露自己的端口，使得用户可以在集群外通过其 NodePort 访问到 Ingress Controller。

假设该端口为 32351，并且 demo.my-company.com 这个域名被解析到集群中某一个节点的 IP（或者被配置到浏览器所在机器的 hosts 文件），则当用户在浏览器中输入地址 http://demo.my-company.com:32351 时：

*  请求被转发到集群某节点的 32351 节点端口。
 *  根据 Service 的定义，请求被转发到 Ingress Controller 的 Web 端口。
 *  Ingress Controller 根据请求域名 demo.my-company.com 以及请求路径，匹配到 Ingress 定义中该请求应该被路由到 nginx-service 的 80 端口。
 *  Ingress Controller 执行 L7 路由转发，将请求发送到 nginx-service 的 80 端口。

### K8s网络 ###

#### 容器网络 ####

容器网络是容器选择连接到其他容器、主机和外部网络（如Internet）的机制。

CNI意为容器网络接口，它是一种标准的设计，为了让用户在容器创建或销毁时都能够更容易地配置容器网络。

目前最流行的CNI插件是Flannel。Flannel插件既可以确保满足Kubernetes的网络要求，又能为Kubernetes集群管理员提供他们所需的某些特定的网络功能。

容器的Runtime提供了各种网络模式，每种模式都会产生不同的体验。

例如，Docker默认情况下可以为容器配置以下网络：

*  none
    
    将容器添加到一个容器专门的网络堆栈中，没有对外连接。
 *  host
    
    将容器添加到主机的网络堆栈中，没有隔离。
 *  default bridge
    
    默认网络模式。每个容器可以通过IP地址相互连接。
 *  自定义网桥
    
    用户定义的网桥，具有更多的灵活性、隔离性和其他便利功能。

Docker还可以让用户通过其他驱动程序和插件，来配置更高级的网络（包括多主机覆盖网络）。

#### Flannel插件 ####

Flannel是CoreOs团队针对kubernetes设计的一个网络规划服务。

简单来说，它的功能是让集群中的不同节点主机创建的Docker容器都具有全集群唯一的虚拟IP地址。

而且它还能在这些IP之间建立一个覆盖网络（Overlay Network），通过这个覆盖网络，将数据包原封不动地传递到目标容器内。

Flannel监控ETCD中每个Pod的实际地址，并在内存中建立维护Pod节点路由表。

![图片][56a643951d71457eaa787fca253869ea.png]

Kubernetes的网络模型假设了所有Pod都在一个可以直接连通的扁平的网络空间中，kubernetes假定这个网络已经存在。

Pod之间的通信存在以下三种情况，对应的通信方式如下：

*  同一个Pod内的多个容器之间。这个是通过lo回路在机器内寻址
 *  当两个Pod在同一个节点主机。由网桥直接转发至对应Pod，不用经过Flannel。
 *  当两个Pod在不同的节点主机，不同Node之间的通信智能通过宿主机的物理网卡进行。

Pod至Service的网络，目前基于性能考虑，采用的是LVS方式维护和转发。

**Pod到外网**： Pod向外网发送请求，查找路由表，转发数据包到宿主机的网卡，宿主网卡完成路由选择后，iptable执行Masquerade，把源IP更改为宿主机网卡的IP，然后向外网服务器发送请求。

**外网访问Pod**： 是通过Service找到对应的Pod，通过网络转换为对应的pod网络Ip再定位到具体的Pod。

**版权声明**：该内容由神州数码云基地团队编撰，转载请注明出处！  
微信公众号后台回复“云原生”，可加入技术交流群！

[f79b9bd7521a50fc2450a261a3f87015.png]: https://img-blog.csdnimg.cn/img_convert/f79b9bd7521a50fc2450a261a3f87015.png
[9579d82134badcb8d03c6a64cd97c42e.png]: https://img-blog.csdnimg.cn/img_convert/9579d82134badcb8d03c6a64cd97c42e.png
[fd3f327a040ff553658ed5717c2e7bd4.png]: https://img-blog.csdnimg.cn/img_convert/fd3f327a040ff553658ed5717c2e7bd4.png
[e39cfd938790f01568465211e2003a34.png]: https://img-blog.csdnimg.cn/img_convert/e39cfd938790f01568465211e2003a34.png
[63e605544a41b5aae9f91baeff1137c0.png]: https://img-blog.csdnimg.cn/img_convert/63e605544a41b5aae9f91baeff1137c0.png
[64d499df11b3f7e78dc94713d88ba68c.png]: https://img-blog.csdnimg.cn/img_convert/64d499df11b3f7e78dc94713d88ba68c.png
[64837cc4a21458dbce2a38b0fd326936.png]: https://img-blog.csdnimg.cn/img_convert/64837cc4a21458dbce2a38b0fd326936.png
[302772a7a5f40691ec92372a5d476933.png]: https://img-blog.csdnimg.cn/img_convert/302772a7a5f40691ec92372a5d476933.png
[0cedda270bc77c262262fdd32eea0c0a.png]: https://img-blog.csdnimg.cn/img_convert/0cedda270bc77c262262fdd32eea0c0a.png
[56a643951d71457eaa787fca253869ea.png]: https://img-blog.csdnimg.cn/img_convert/56a643951d71457eaa787fca253869ea.png