当前位置：首页 > news >正文

K8s(Kubernetes)学习（一）：k8s概念及组件

news 文章来源：https://blog.csdn.net/qq_45808700/article/details/130604300 2025/4/18 22:05:50

Kubernetes中文文档：https://kubernetes.io/zh-cn/docs/home/
Kubernetes源码地址：https://github.com/kubernetes/kubernetes

一:Kubernetes是什么

首先要了解应用程序部署经历了以下几个时代：
在这里插入图片描述

传统部署时代：在物理服务器上运行应用程序。
虚拟化部署时代：虚拟化技术允许你在单个物理服务器的 CPU 上运行多台虚拟机（VM）。虚拟化能使应用程序在不同 VM 之间被彼此隔离，且能提供一定程度的安全性，因为一个应用程序的信息不能被另一应用程序随意访问。
容器部署时代：容器类似于 VM，但是更宽松的隔离特性，使容器之间可以共享操作系统（OS）。每个容器之间互相隔离，具有自己的文件系统、CPU、内存、进程空间等，容器之间进程不会相互影响，能区分计算资源。相对于虚拟机，容器能快速部署，由于容器与底层设施、机器文件系统解耦的，所以它能在不同云、不同版本操作系统间进行迁移。
容器因具有许多优势而变得流行起来，例如：
- 敏捷应用程序的创建和部署：与使用 VM 镜像相比，提高了容器镜像创建的简便性和效率。
- 持续开发、集成和部署：通过快速简单的回滚（由于镜像不可变性），提供可靠且频繁的容器镜像构建和部署。
- 关注开发与运维的分离：在构建、发布时创建应用程序容器镜像，而不是在部署时，从而将应用程序与基础架构分离。
- 可观察性：不仅可以显示 OS 级别的信息和指标，还可以显示应用程序的运行状况和其他指标信号。
- 跨开发、测试和生产的环境一致性：在笔记本计算机上也可以和在云中运行一样的应用程序。
- 跨云和操作系统发行版本的可移植性：可在 Ubuntu、RHEL、CoreOS、本地、 Google Kubernetes Engine 和其他任何地方运行。
- 以应用程序为中心的管理：提高抽象级别，从在虚拟硬件上运行 OS 到使用逻辑资源在 OS 上运行应用程序。
- 松散耦合、分布式、弹性、解放的微服务：应用程序被分解成较小的独立部分，并且可以动态部署和管理 - 而不是在一台大型单机上整体运行。
- 资源隔离：可预测的应用程序性能。
- 资源利用：高效率和高密度。

而Kubernetes就是一个开源容器集群管理系统，可以在物理或虚拟机的Kubernetes集群上运行容器化应用，提供一个以“容器为中心的基础架构”，实现容器集群的自动化部署、自动扩缩容、维护等功能。
在生产环境中，需要管理运行着应用程序的容器，并确保服务不会下线。例如，如果一个容器发生故障，则你需要启动另一个容器。这就可以交给Kubernetes ，它提供了一个可弹性运行分布式系统的框架。Kubernetes 可以通过一个命令为你提供集中式的管理集群机器和应用，加机器、版本升级、版本回滚，不停机的灰度更新，确保高可用、高性能、高扩展。

服务发现和负载均衡
存储编排
自动部署和回滚
自动完成装箱计算
自我修复
配置和存储管理

二:Kubernetes架构

Kubernetes部署完成后一定是一个集群集群。k8s 总体架构采用了经典的 master slave 架构模式，分 master 节点和 worker 节点，节点可以是虚拟机也可以是物理机。
在这里插入图片描述

master 节点——Control Plane控制平面四个逻辑组件组成：API Server、Scheduler、Controller、etcd，它们被称为是程序组件，每个组件之间都必须运行一个守护进程，API Server、Scheduler、Controller是k8s提供的，而etcd不是k8s提供的。

etcd：一种的分布式存储机制，底层采用 Raft 协议，k8s 集群的状态数据包括配置、节点等都存储于 etcd 中，它保存了整个集群的状态。
API server：对外提供操作和获取 k8s 集群资源的的 API，是唯一操作 etcd 的组件，其他的组件包括管理员操作都是通过 API server 进行交互的，可以将它理解成 etcd 的 “代理人”。
Scheduler：在 k8s 集群中做调动决策，负责资源的调度，按照预定的调度策略将 Pod 调度到相应的机器上。
Controller Manager：相当于集群状态的协调者，观察着集群的实际状态，与 etcd 中的预期状态进行对比，如果不一致则对资源进行协调操作让实际状态和预期状态达到最终的一致，维护集群的状态，比如故障检测、自动扩展、滚动更新等。

worker 节点由以下组件组成：

Controller Runtime：下载镜像和运行容器的组件，负责镜像管理以及 Pod 和容器的真正运行（CRI）。
Pod：K8S 调度、管理的最小单位，一个 Pod 可以包含一个或多个容器，每个 Pod 有自己的虚拟IP。一个工作节点可以有多个 pod，主节点会考量负载自动调度 pod 到哪个节点运行。
kubelet：负责管理 worker 节点上的组件，与 master 节点上的 API server 节点进行交互，接受指令执行操作。
kube-proxy：负责对 Pod 进行寻址和负载均衡

三:Kubernetes组件

在这里插入图片描述

1.Master节点——控制平面（Control Plane）组件

在这里插入图片描述

1.1 kubectl

kubectl是Kubernetes命令行工具（command-line tool），用于管理Kubernetes集群和应用程序。kubectl可以通过命令行方式与Kubernetes API服务器进行通信，实现对集群的部署、维护和监控等操作。

kubectl官方介绍：https://kubernetes.io/zh-cn/docs/reference/kubectl/

1.2 kube-apiserver

APIServer提供了K8S各类资源对象的操作，是集群内各个功能模块之间数据交互和通信的中心枢纽，是整个系统的数据总线和数据中心。通常我们通过kubectl与APIServer进行交互。API服务提供Kubernetes API 的服务，试图通过把所有或者大部分的业务逻辑放到不两只的部件中从而使其具有CRUD特性。它主要处理REST操作，在etcd中验证更新这些对象（并最终存储）。

API Server是整个K8S上唯一接收客户端请求的入口，负责检查用户创建提交的命令是否合乎语法规范，如果合乎语法规范接下来他就把它保存到etcd当中。API Server是一个数据库，它负责用户通过任何一个接口完成对容器的增删改查，这个时候容器并没有跑起来，它只是存下来用户提交了一个创建容器得请求，这个容器有没有跑起来由Controller来负责，API Server会通知Controller，Controller会watch到 API server上得变动，比如创建删除操作，一旦有了变动，Controller会立即获得变动相关状态，然后Controller对用户下达指令进行操作。
kube-apiserver官方介绍：https://kubernetes.io/zh-cn/docs/concepts/overview/kubernetes-api/
Kubernetes API 官方介绍：https://kubernetes.io/zh-cn/docs/reference/using-api/

1.3 kube-Scheduler组件

kube-Scheduler即调度器，负责监视新创建的、未指定运行节点（node）的 Pods，并选择节点来让 Pod 在上面运行。

通过API、UI、CLI向master提起要创建一个容器，这个容器到底要运行在node节点中的哪一个呢，需要调度器去评估一下哪一个node是最佳目标节点，如果多个node节点都是最佳的那就从中随机选择一个，例如用户新建一个容器，Scheduler会watch到api server,Scheduler会把它调度到某一个节点上创建出来，创建出来健康与否，Controller去负责监控它。

通过调度算法，为待调度Pod列表的每个Pod，从Node列表中选择一个最合适的Node。然后，目标节点上的kubelet通过API Server监听到Kubernetes Scheduler产生的Pod绑定事件，获取对应的Pod清单，下载Image镜像，并启动容器。

Scheduler官方介绍：https://kubernetes.io/zh-cn/docs/concepts/scheduling-eviction/kube-scheduler/

1.4 etcd

etcd：是一个k/v存储系统，可以定义容器是通过不同的k/v来描述一个容器的多个状态信息，如一个容器里面有容器名，有镜像，监听端口，为了能够确保用户能够合理合法的描述k8s所支持的资源的属性，API server对etcd进行了包装和抽象，使得用户只能按照api server中定的结构来定义数据。
etcd官网：https://etcd.io/docs/

1.5 kube-controller-manager

在应用程序当中有两种api范式，一种叫陈述式，一种叫声明式，k8s的api提供的是一种声明式api，若某一个客户端想运行容器，通过API、UI、CLI来告诉maste运行一个容器，运行一个nginx容器，运行这个容器的镜像占多少内存，镜像从哪里来，是否能跑起来你都不用管，只需要告诉master给我运行一个nginx容器，Controller知道到哪去找镜像，拿过来以后通过Scheduler调度以后，Controller知道nginx容器运行健康与否，有没有正常监听用户所指定的端口，如果没有，Controller会试图把它干掉在重新启动，这叫自动创建，这个所有功能都是Controller来实现的。Controller是整个master当中的大脑，因为用户指令下来以后，真正能负责执行并监控它、能符合用户所指定的期望都由Controller负责。

在k8s之上一个资源有两种状态，一种是用户期望状态。用户请求并保存在etcd当中用户期望，第二种状态是当前实际状态。Controller把指令从etcd中取出来并确保在节点上可以运行起来，这个是真正运行它的容器，这个真正运行它的容器的状态和用户期望保存在etcd的状态有可能是不一致的，比如用户运行的状态etcd监听80端口，而Controller监听的是8080端口，就会不符合用户期望，Controller会对比etcd的状态和Controller上的状态是否一样，如果不一致，Controller就负责确保真正运行的状态和etcd的状态是否一致，不一致就Controller重启或者重建确保他们一致。

kube-controller-manager 集群控制器负责运行控制器进程。从逻辑上讲，每个控制器都是一个单独的进程，但是为了降低复杂性，它们都被编译到同一个可执行文件，并在同一个进程中运行。这些控制器包括：

节点控制器（Node Controller）：负责在节点出现故障时进行通知和响应
任务控制器（Job Controller）：监测代表一次性任务的 Job 对象，然后创建 Pods 来运行这些任务直至完成
端点分片控制器（EndpointSlice controller）：填充端点分片（EndpointSlice）对象（以提供 Service 和 Pod 之间的链接）。
服务账号控制器（ServiceAccount controller）：为新的命名空间创建默认的服务账号（ServiceAccount）。

controller-manager官方介绍：https://kubernetes.io/zh-cn/docs/reference/command-line-tools-reference/kube-controller-manager/
controller官方介绍：https://kubernetes.io/zh-cn/docs/concepts/architecture/controller/

2.Node节点组件

在这里插入图片描述

节点组件会在每个节点上运行，负责维护运行的 Pod 并提供 Kubernetes 运行环境。

2.1 Pod

Kubernetes 不是直接调度容器的，而是将其封装成了一个个 Pod ，Pod 才是 k8s 的基本调度单位。Pod 是可以在 Kubernetes 中创建和管理的、最小的可部署的计算单元。

Pod是一组（一个或多个）容器；这些容器共享存储、网络、以及怎样运行这些容器的声明。 Pod 中的内容总是并置的并且一同调度，在共享的上下文中运行。 Pod 所建模的是特定于应用的 “逻辑主机”，其中包含一个或多个应用容器，这些容器相对紧密地耦合在一起。

Pod官方介绍：https://kubernetes.io/zh-cn/docs/concepts/workloads/pods/

2.2 kubelet

kubelet 会在集群中每个节点（node）上运行，用于管理pod和container，每个kubelet会向apiserver注册本节点的信息，并向master节点上报本节点资源使用的情况它保证容器（containers）都运行在 Pod 中。

kubelet 接收一组通过各类机制提供给它的 PodSpecs，确保这些 PodSpecs 中描述的容器处于运行状态且健康。 kubelet 不会管理不是由 Kubernetes 创建的容器。

kubelet官方介绍：https://kubernetes.io/zh-cn/docs/reference/command-line-tools-reference/kubelet/

2.3 kube-proxy

kube-proxy 是集群中每个节点（node）上所运行的网络代理，实现 Kubernetes 服务（Service）概念的一部分。

kube-proxy 维护节点上的一些网络规则，这些网络规则会允许从集群内部或外部的网络会话与 Pod 进行网络通信。如果操作系统提供了可用的数据包过滤层，则 kube-proxy 会通过它来实现网络规则。否则，kube-proxy 仅做流量转发。

kube-proxy官方介绍：https://kubernetes.io/zh-cn/docs/reference/command-line-tools-reference/kube-proxy/

2.4 容器运行时（Container Runtime）

容器运行环境是负责运行容器的软件。

Kubernetes 支持许多容器运行环境，例如 containerd、 CRI-O 以及 Kubernetes CRI (容器运行环境接口) 的其他任何实现。

容器的创建过程涉及到多个组件协同工作。用户创建一个容器向API server发请求，Scheduler watch到api server创建容器的请求开始调度，从当前集群中的node节点中选一个作为真正运行这个容器的节点，之后Scheduler把调度的结果保存到etcd当中，node组件中的kubelet组件监视 API server上的资源变动，如果说Scheduler调度某个容器给Node节点以后，这个节点可以通过 api server得到消息，kubelet会创建执行容器的任务，kubelet会调用容器、下载镜像、启动容器。

官方介绍文档：https://kubernetes.io/zh-cn/docs/setup/production-environment/container-runtimes/

3.插件（Add-ons）

3.1 DNS

DNS组件为Pod提供了服务发现、域名解析功能，使得Pod可以通过名称而非IP地址来相互通信。

Kubernetes使用名为kube-dns的开源DNS解决方案作为其集群内部DNS服务器。kube-dns具有高可用性和水平扩展能力，以适应大规模部署的需求。它为每个Service分配一个固定的DNS名称，并在需要时将它们映射到相关的Pod的IP地址。这种方式简化了服务发现的过程，使得服务之间的通信更加灵活和可靠。

3.2 Dashboard

Kubernetes Dashboard是一个基于Web的UI工具，提供了一种直观的方法来管理和监控Kubernetes集群。

Dashboard支持查看和编辑应用程序、管理Pod和容器、检查系统日志和监视集群资源等操作。Dashboard具有用户友好的界面和易于导航的菜单，可帮助用户更好地理解和掌握整个Kubernetes集群的运行状况。除此之外，Dashboard还允许管理员配置和管理用户访问权限，并与其他Kubernetes API组件集成以提供更全面的集群管理体验。

3.3 容器资源监控

容器资源监控将关于容器的一些常见的时间序列度量值保存到一个集中的数据库中，并提供浏览这些数据的界面。

3.4 集群层面日志

集群层面日志机制负责将容器的日志数据保存到一个集中的日志存储中，这种集中日志存储提供搜索和浏览接口