^-^
  1. K8S理论基础
    1. 1. 先从Docker说起
    2. 2. K8S的概念
    3. 3. K8S的架构
      1. 3.1 Master节点
      2. 3.2 Node节点
    4. 4. K8S的核心资源对象
    5. 5. 工智道系统K8S架构

K8S理论基础

1. 先从Docker说起

img

Docker，翻译过来是码头工人，是容器的代表，容器是一种虚拟化的技术。

Docker和虚拟机

Docker和虚拟机，都用到了虚拟化的技术。

虚拟机是通过对物理机进行虚拟化，每一个虚拟机都是一个具有完整的硬件功能的计算机系统。

Docker是通过对操作系统虚拟化，所有的Docker容器共享主机的操作系统内核，但是具有各自独立且隔离的用户空间。

Docker的优势

同样是虚拟化的技术，Docker相对于虚拟机的优势就在于Docker更加的轻量。

虚拟机的创建、启动和销毁都需要加载整个操作系统以及所有的硬件功能，它的整个生命周期的操作，往往都会耗费分钟级别的时间。

但是Docker只需要数秒钟，因为Docker容器其实就是一个进程，创建和销毁Docker容器，需要分配和回收的资源相比虚拟机要小得多，是以MB为单位的。

所以一台物理机，一般支持运行几十个虚拟机，但是同样规格的单机，无论是虚拟机或者物理机，一般可以支持上千个容器运行。

Docker的架构

img

2. K8S的概念

img

Kubernetes，翻译过来是“舵手”（掌舵的人），简称K8S。K8S是用来管理Docker的，是一个容器编排工具。

为什么需要K8S

从Docker成为企业的主流选择之后，相继出现过很多容器编排工具，比如Docker-Compose或者是Docker-Swarm，但是这些工具都有一个通病，就是过于以单台主机上的Docker容器为核心，提供的能力也比较简单，比如定义网络，指定镜像，控制谁先启动谁后启动等等，无法满足复杂的集群场景。

K8S的由来

K8S最开始是Google的一个开源项目，因为Google很早就全面使用容器作为应用的运行环境，绝大部分应用都运行在容器上，需要一个管理大规模容器集群的工具，K8S就是诞生在这种背景下，基于 Google 公司超过 10 多年的运维经验，2015年发布Kubernetes v1.0 ，融入Linux开源生态，随后Microsoft、IBM、RedHat、VMWare等众多国际大厂都积极支持该项目。

K8S的企业支持

K8S发展到现在，已经成为企业中最受欢迎的开源容器编排平台，因此也被广泛地支持和集成到各大云服务提供商的容器服务中，包括 Google Kubernetes Engine（GKE）、Amazon Elastic Kubernetes Service（EKS）、Microsoft Azure Kubernetes Service（AKS）等，国内有腾讯云 TKE 和阿里云 ACK 等。

3. K8S的架构

img

K8S集群是由多台服务器组成的，在K8S集群中，单台服务器都称为节点，K8S的集群节点分为两种角色：Master节点和Node节点。

3.1 Master节点

官方叫做控制平面（Control Plane）。主要负责整个集群的管控，包含监控、编排、调度集群中的各类资源对象，通常 Master 会占用一个单独的集群节点（不会运行应用容器），基于高可用考虑，一般会占用多台。

Master节点由四部分组成

API Server

API Server是Master节点的核心组件之一，为集群中各类资源提供增删改查的 HTTP REST 接口，即操作任何资源都要经过 API Server。

运维人员和开发人员想要管理集群，一般都是通过间接调用API Server的接口实现的。

即通过 kubectl 客户端访问，其本质上是将命令转换为 REST API 调用，是最主要的访问方式。

etcd

K8s 使用 etcd 作为内部数据库，用于保存集群配置以及所有对象的状态信息，是以键值对的方式存储的。只有 API Server 进程能直接读写 etcd。为了保证集群数据安全性，一般会做etcd的高可用，并且为其考虑备份方案。

Scheduler

Scheduler是 Pod 资源的调度器，用于监听刚创建还未分配 Node 的 Pod，为其分配相应 Node。 调度器也是操作 API Server 进程的各项接口来完成调度的。比如 Watch 接口监听新建的 Pod，并搜索所有满足 Pod 需求的 Node 列表， 再执行 Pod 调度逻辑，调度成功后将 Pod 绑定到目标 Node 上。

kube-controller-manager

Controller 管理器实现了全部的后台控制循环，完成对集群的健康并对事件做出响应。Controller 管理器是各种 Controller 的管理者，负责创建 controller，并监控它们的执行。这些 Controller 包括 NodeController、ReplicationController 等，每个 controller 都在后台启动了一个独立的监听循环（可以简单理解为一个线程），负责监控 API Server 的变更。

3.2 Node节点

Node 由三部分组成：kubelet、kube-proxy 和容器运行时（如 docker/containerd）。

kubelet

kubelet是每个 Node 上都运行的主要代理进程，管理Node节点上的资源。kubelet负责监听从API Server发送来的任务，执行任务并报告给主节点。

kubelet 也会及时将 Pod 内容器状态以及自身状态报告给 API Server。

kube-proxy

kube-proxy也是每个Node上都运行代理进程，管理Node节点上的网络规则。kube-proxy会监听 API Server 中各类资源发生的变化，并将这些变化实时反应到节点的网络规则中，确保流量正确路由到服务。 总结来说，kube-proxy 主要负责维护网络规则和四层流量的负载均衡工作。

容器运行时

容器运行时负责在Node节点上创建容器的运行环境，K8S支持多种容器运行时，主流的容器运行时是Docker，containerd等，不过在较新的K8S版本中强制采用了Containerd作为容器运行时，Docker被废弃（1.24版本及以前仍然是可用的）。

4. K8S的核心资源对象

Namespace

Namespace（命名空间）用来隔离集群内不同环境下的资源。

Pod

在 Kubernetes 的世界中，调度的原子单位是 Pod。一个Pod中通常包含一个或多个容器，我们的业务应用都运行在容器中。

Deployment

通常，Pod 不会被直接创建和管理，而是由更高级别的控制器，例如 Deployment 来创建和管理。 这是因为单独运行的 Pod 没有自愈能力，一旦因为各种原因被删除就不会再重新创建。Deployment控制器可以提供更强大的管理功能，比如：应用更新和回滚，Pod自愈能力，副本数量管理等。

Service

Pod被创建之后，只能在K8S的Pod子网内被访问。要实现被外界所访问，就需要依靠Service资源，所以简单来说，Service是作为一个四层网络代理，外界的流量进入Node节点，然后转发给Service，由Service转发给各种业务Pod。

Ingress

在实际环境中，往往需要七层的代理，这是Service无法完成的工作，于是需要Ingress来定义路由规则，使请求根据域名和路径匹配路由到不同的后端服务。

PV

PV（persistent volume）是持久化数据卷，一种K8S的全局资源。

持久卷是对存储资源数据卷(volume)创建和使用的抽象，使得存储作为集群中的资源管理。PV允许底层存储使用NFS、Cephfs或是其他存储系统，可以预先定义存储能力(使用多大的存储空间)，也可以实现后端存储的权限管控(rw,ro)。

PVC

PVC（persistent volume claim）是持久化数据卷声明，PVC也不负责数据的真实存储，它只是显式声明需要使用的存储资源需求，然后K8S会自动去关联符合条件的PV，从而实现对存储资源的使用。

5. 工智道系统K8S架构

image-20240820161315665

2024-08-17