【云原生丨Kubernetes系列②】Kubernetes核心概念与组件通信

0️⃣前言

Kubernetes 是一个自动化的容器编排平台,它负责应用的部署、应用的弹性以及应用的管理,这些都是基于容器的。

在这里插入图片描述



1️⃣基本概念

Kubernetes 中的绝⼤部分概念都抽象成 K8s 管理的⼀种资源对象。

下⾯我们⼀起总结⼀下我们上篇文章中遇到的⼀些资源对象:

  • Master:Master 节点是 Kubernetes 集群的控制节点,负责整个集群的管理和控制。Master 节点 上包含以下组件:
    • kube-apiserver:集群控制的⼊⼝,提供 HTTP REST 服务
    • kube-controller-manager:Kubernetes 集群中所有资源对象的⾃动化控制中⼼
    • kube-scheduler:负责 Pod 的调度

  • Node:Node 节点是 Kubernetes 集群中的⼯作节点,Node 上的⼯作负载由 Master 节点分配, ⼯作负载主要是运⾏容器应⽤。Node 节点上包含以下组件:
    • kubelet:负责 Pod 的创建、启动、监控、重启、销毁等⼯作,同时与 Master 节点协作,实 现集群管理的基本功能。
    • kube-proxy:实现 Kubernetes Service 的通信和负载均衡
    • 运⾏容器化(Pod)应⽤

  • Pod: Pod 是 Kubernetes 最基本的部署调度单元。每个 Pod 可以由⼀个或多个业务容器和⼀个根 容器(Pause 容器)组成。⼀个 Pod 表示某个应⽤的⼀个实例
  • ReplicaSet:是 Pod 副本的抽象,⽤于解决 Pod 的扩容和伸缩
  • Deployment:Deployment 表示部署,在内部使⽤ReplicaSet 来实现。可以通过 Deployment 来 ⽣成相应的 ReplicaSet 完成 Pod 副本的创建
  • Service:Service 是 Kubernetes 最重要的资源对象。Kubernetes 中的 Service 对象可以对应微 服务架构中的微服务。Service 定义了服务的访问⼊⼝,服务的调⽤者通过这个地址访问 Service 后端的 Pod 副本实例。Service 通过 Label Selector 同后端的 Pod 副本建⽴关系,Deployment 保 证后端Pod 副本的数量,也就是保证服务的伸缩性。
    在这里插入图片描述

Kubernetes 主要由以下⼏个核⼼组件组成:

  • etcd 保存了整个集群的状态,就是⼀个数据库;
  • apiserver 提供了资源操作的唯⼀⼊⼝,并提供认证、授权、访问控制、API 注册和发现等机制;
  • controller manager 负责维护集群的状态,⽐如故障检测、⾃动扩展、滚动更新等;
  • scheduler 负责资源的调度,按照预定的调度策略将 Pod 调度到相应的机器上;
  • kubelet 负责维护容器的⽣命周期,同时也负责 Volume(CSI)和⽹络(CNI)的管理;
  • Container runtime 负责镜像管理以及 Pod 和容器的真正运⾏(CRI);
  • kube-proxy 负责为 Service 提供 cluster 内部的服务发现和负载均衡;

当然了除了上⾯的这些核⼼组件,还有⼀些推荐的插件:

  • kube-dns 负责为整个集群提供 DNS 服务
  • Ingress Controller 为服务提供外⽹⼊⼝
  • Heapster 提供资源监控
  • Dashboard 提供 GUI

2️⃣核心功能

Kubernetes 有如下几个核心的功能:

  • 服务的发现与负载的均衡;
  • 容器的自动装箱,我们也会把它叫做 scheduling,就是“调度”,把一个容器放到一个集群的某一个机器上,Kubernetes 会帮助我们去做存储的编排,让存储的声明周期与容器的生命周期能有一个连接;
  • Kubernetes 会帮助我们去做自动化的容器的恢复。在一个集群中,经常会出现宿主机的问题或者说是 OS 的问题,导致容器本身的不可用,Kubernetes 会自动地对这些不可用的容器进行恢复;
  • Kubernetes 会帮助我们去做应用的自动发布与应用的回滚,以及与应用相关的配置密文的管理;
  • 对于 job 类型任务,Kubernetes 可以去做批量的执行;
  • 为了让这个集群、这个应用更富有弹性,Kubernetes 也支持水平的伸缩。

下面,我来借用三个例子跟大家更加切实地介绍一下 Kubernetes 的能力。

1.调度

Kubernetes 可以把用户提交的容器放到 Kubernetes 管理的集群的某一台节点上去。Kubernetes 的调度器是执行这项能力的组件,它会观察正在被调度的这个容器的大小、规格。

比如说它所需要的 CPU以及它所需要的 memory,然后在集群中找一台相对比较空闲的机器来进行一次 placement,也就是一次放置的操作。在这个例子中,它可能会把红颜色的这个容器放置到第二个空闲的机器上,来完成一次调度的工作。

在这里插入图片描述


2.自动恢复

Kubernetes 有一个节点健康检查的功能,它会监测这个集群中所有的宿主机,当宿主机本身出现故障,或者软件出现故障的时候,这个节点健康检查会自动对它进行发现。

下面 Kubernetes 会把运行在这些失败节点上的容器进行自动迁移,迁移到一个正在健康运行的宿主机上,来完成集群内容器的一个自动恢复。

在这里插入图片描述


3.水平伸缩

Kubernetes 有业务负载检查的能力,它会监测业务上所承担的负载,如果这个业务本身的 CPU 利用率过高,或者响应时间过长,它可以对这个业务进行一次扩容。

比如在下面的例子中,黄色的过度忙碌,Kubernetes 就可以把黄颜色负载从一份变为三份。接下来,它就可以通过负载均衡把原来打到第一个黄颜色上的负载平均分到三个黄颜色的负载上去,以此来提高响应的时间。

在这里插入图片描述


3️⃣组件通信

Kubernetes 多组件之间的通信原理:

  • apiserver 负责 etcd 存储的所有操作,且只有 apiserver 才直接操作 etcd 集群
  • apiserver 对内(集群中的其他组件)和对外(⽤户)提供统⼀的 REST API,其他组件均通过 apiserver 进⾏通信
    • controller manager、scheduler、kube-proxy 和 kubelet 等均通过 apiserver watch API 监测 资源变化情况,并对资源作相应的操作
    • 所有需要更新资源状态的操作均通过 apiserver 的 REST API 进⾏
  • apiserver 也会直接调⽤ kubelet API(如 logs, exec, attach 等),默认不校验 kubelet 证书,但 可以通过 --kubelet-certificate-authority 开启(⽽ GKE 通过 SSH 隧道保护它们之间的通信)

⽐如最典型的创建 Pod 的流程:

在这里插入图片描述

  • ⽤户通过 REST API 创建⼀个 Pod
  • apiserver 将其写⼊ etcd
  • scheduluer 检测到未绑定 Node 的 Pod,开始调度并更新 Pod 的 Node 绑定
  • kubelet 检测到有新的 Pod 调度过来,通过 container runtime 运⾏该 Pod
  • kubelet 通过 container runtime 取到 Pod 状态,并更新到 apiserver 中

同一 POD 内部通信原理

不论是 Flannel Vxlan、还是 Calico IPIP ,同一 POD 内部不同 Container 之间的通信,采用的 Container 模式,都是共享同一个 Network Namespace ,于宿主机隔离,新创建的容器不会新建自己的网卡,配置自己的 IP ,而是和一个指定的容器共享 IP、端口范围等,两个容器的进程是可以通过 Lo 网卡(127.0.0.1)通信,但是除网络方面,其他的文件系统,进程等都是隔离的。
在这里插入图片描述

# container-1
sh-4.2$ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1440
        inet 10.234.119.43  netmask 255.255.255.255  broadcast 10.234.119.43
        ether 0e:57:05:1c:e3:12  txqueuelen 0  (Ethernet)
        RX packets 4662749  bytes 4220056657 (3.9 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 4587887  bytes 4242002557 (3.9 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 20357  bytes 110675601 (105.5 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 20357  bytes 110675601 (105.5 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
# container-2
/ # ifconfig
eth0      Link encap:Ethernet  HWaddr 0E:57:05:1C:E3:12
          inet addr:10.234.119.43  Bcast:10.234.119.43  Mask:255.255.255.255
          UP BROADCAST RUNNING MULTICAST  MTU:1440  Metric:1
          RX packets:4663185 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4588351 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:4220103158 (3.9 GiB)  TX bytes:4242042363 (3.9 GiB)
lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:20357 errors:0 dropped:0 overruns:0 frame:0
          TX packets:20357 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:110675601 (105.5 MiB)  TX bytes:110675601 (105.5 MiB)


在这里插入图片描述

猜你喜欢

转载自blog.csdn.net/m0_63947499/article/details/126355601