【Kubernetes】Kubernetes是什么？ 是如何工作的？它的核心组件有哪些？以及实际工作案例理解

通过Kubernets与Docker Swarm的比较来了解Kubernets

• Kubernetes 和 Docker Swarm 都是 容器编排工具，但它们有本质上的区别：

1. 定义

• Kubernetes（K8s）：一个 完整的容器编排系统，支持自动化部署、扩展、负载均衡、服务发现、滚动更新、存储管理等。
• Docker Swarm：Docker 官方提供的 轻量级集群管理工具，用于 管理多个 Docker 容器，功能相对简单，适合小规模集群。

2. 主要区别

3. 什么时候用 Kubernetes？什么时候用 Swarm？

• 用 Kubernetes

  • 需要 大规模集群
  • 需要 自动扩展、持久化存储、服务发现
  • 需要 高可用性
  • 需要 云原生生态支持（如 Helm、Istio、Prometheus）

• 用 Docker Swarm

  • 只管理 少量容器
  • 需要 快速搭建、轻量级编排
  • 团队成员 不熟悉 Kubernetes

Kubernetes 的工作原理

Kubernetes 通过以下方式工作：

1. 声明式配置：用户通过 YAML 或 JSON 文件定义应用的期望状态（如副本数、资源限制等）。
2. 控制循环：Kubernetes 的核心组件持续监控集群状态，确保实际状态与期望状态一致。
3. 自动化操作：Kubernetes 自动执行调度、扩展、负载均衡、故障恢复等操作。
4. 分布式架构：Kubernetes 集群由多个节点组成，分为控制平面（Control Plane）和工作节点（Worker Nodes）。

Kubernetes 的核心组件

Kubernetes 的架构分为两部分：控制平面和工作节点。以下是各组件的详细介绍：

1. 控制平面（Control Plane）

控制平面负责管理集群的全局状态和决策，包括以下核心组件：

(1) API Server

• 作用：Kubernetes 的入口，提供 RESTful API，用于与集群交互。
• 功能：验证请求、处理操作（如创建、更新、删除资源）。
• 工具：kubectl 通过 API Server 与集群通信。

(2) etcd

• 作用：分布式键值存储，保存集群的所有配置数据和状态。
• 特点：高可用、强一致性。
• 注意：etcd 是 Kubernetes 的唯一有状态组件。

(3) Controller Manager

• 作用：运行各种控制器，确保集群的当前状态与期望状态一致。
• 核心控制器：
  • Node Controller：管理节点状态。
  • Replication Controller：确保 Pod 的副本数符合预期。
  • Endpoint Controller：维护 Service 和 Pod 的映射关系。
  • 其他控制器：如 Deployment、DaemonSet 等。

(4) Scheduler

• 作用：将 Pod 调度到合适的工作节点上。
• 调度策略：基于资源需求、亲和性、污点等条件选择节点。

2. 工作节点（Worker Nodes）

工作节点负责运行容器化应用，包括以下核心组件：

(1) Kubelet

• 作用：节点上的代理，负责与控制平面通信，管理 Pod 和容器。
• 功能：
  • 启动、停止容器。
  • 监控容器状态并报告给 API Server。
  • 执行健康检查。

(2) Kube Proxy

• 作用：实现 Kubernetes Service 的网络代理和负载均衡。
• 功能：
  • 维护节点上的网络规则。
  • 将请求转发到正确的 Pod。

(3) 容器运行时（Container Runtime）

• 作用：负责运行容器（如 Docker、containerd、CRI-O）。
• 功能：下载镜像、创建和管理容器。

3. 附加组件

除了核心组件，Kubernetes 还依赖一些附加组件来实现完整功能：

(1) DNS

• 作用：为 Service 和 Pod 提供 DNS 解析。
• 常用实现：CoreDNS。

(2) Ingress Controller

• 作用：管理外部流量访问集群内部服务。
• 常用实现：Nginx Ingress Controller。

(3) CNI（容器网络接口）

• 作用：提供 Pod 之间的网络通信。
• 常用实现：Calico、Flannel、Weave 等。

(4) 存储插件

• 作用：为 Pod 提供持久化存储。
• 常用实现：CSI（Container Storage Interface）插件。

Kubernetes 的工作流程

1. 用户通过 kubectl 或 API 提交资源定义（如 Deployment、Service）。
2. API Server 接收请求并写入 etcd。
3. Controller Manager 检测到资源变化，确保实际状态与期望状态一致。
4. Scheduler 将未调度的 Pod 分配到合适的工作节点。
5. Kubelet 在节点上启动 Pod 和容器。
6. Kube Proxy 配置网络规则，确保 Service 的流量转发。

Kubernetes 工作流程详解

1. 用户通过 kubectl 或 API 提交资源定义

• 详细说明：
  • 用户通过 kubectl 命令行工具或直接调用 Kubernetes API，提交资源定义文件（通常是 YAML 或 JSON 格式）。
  • 这些资源定义文件描述了应用的期望状态，比如：
    • Deployment：定义应用的副本数、容器镜像、资源限制等。
    • Service：定义如何访问应用（如负载均衡、服务发现）。
• 实际场景：
  • 假设你有一个 Web 应用，需要部署 3 个副本，并通过负载均衡对外提供服务。
  • 你可以编写一个 deployment.yaml 文件，定义副本数、容器镜像等信息，然后通过以下命令提交：

    kubectl apply -f deployment.yaml
    

2. API Server 接收请求并写入 etcd

• 详细说明：
  • API Server 是 Kubernetes 的入口，负责接收用户请求。
  • 它会对请求进行验证（如权限检查、资源格式校验）。
  • 验证通过后，API Server 将资源定义写入 etcd（Kubernetes 的分布式键值存储）。
• 实际场景：
  • 当你提交 deployment.yaml 后，API Server 会将其解析并存储到 etcd 中。
  • 此时，Kubernetes 已经知道了你的应用期望状态（如 3 个副本）。

3. Controller Manager 检测到资源变化，确保实际状态与期望状态一致

• 详细说明：
  • Controller Manager 是 Kubernetes 的“大脑”，包含多个控制器（如 Deployment Controller、ReplicaSet Controller）。
  • 这些控制器会监听 etcd 中的资源变化，并确保集群的实际状态与期望状态一致。
  • 例如，如果期望有 3 个 Pod 副本，但实际只有 2 个，控制器会创建新的 Pod。
• 实际场景：
  • 假设你提交的 deployment.yaml 中定义了 3 个副本，但当前集群中只有 2 个 Pod 在运行。
  • Deployment Controller 会检测到这一差异，并自动创建第 3 个 Pod。

4. Scheduler 将未调度的 Pod 分配到合适的工作节点

• 详细说明：
  • Scheduler 负责将新创建的 Pod 分配到合适的工作节点。
  • 它会根据资源需求、节点负载、亲和性规则等条件，选择一个最优节点。
• 实际场景：
  • 假设你的集群有 3 个工作节点，Scheduler 会根据以下条件选择节点：
    • 节点是否有足够的 CPU 和内存资源。
    • 节点是否满足 Pod 的亲和性规则（如必须运行在某个特定节点）。
  • 最终，Scheduler 将 Pod 调度到合适的节点上。

5. Kubelet 在节点上启动 Pod 和容器

• 详细说明：
  • Kubelet 是工作节点上的代理，负责与管理平面通信并执行具体操作。
  • 它会从 API Server 获取分配给本节点的 Pod 信息，并启动相应的容器。
  • Kubelet 还负责监控容器的运行状态，并向 API Server 报告。
• 实际场景：
  • 假设 Scheduler 将 Pod 调度到节点 A。
  • 节点 A 上的 Kubelet 会执行以下操作：
    1. 下载所需的容器镜像。
    2. 启动容器。
    3. 监控容器的健康状态。

6. Kube Proxy 配置网络规则，确保 Service 的流量转发

• 详细说明：
  • Kube Proxy 是工作节点上的网络代理，负责实现 Service 的网络功能。
  • 它会配置 iptables 或 IPVS 规则，将 Service 的流量转发到后端的 Pod。
  • 它还负责负载均衡，确保流量均匀分布到多个 Pod。
• 实际场景：
  • 假设你定义了一个 Service，用于暴露 Web 应用的 3 个 Pod。
  • Kube Proxy 会为这个 Service 配置网络规则：
    1. 当外部请求到达 Service 的 IP 和端口时，Kube Proxy 会将请求转发到后端的 Pod。
    2. 如果某个 Pod 不可用，Kube Proxy 会自动将流量转发到其他健康的 Pod。

完整工作流程示例

假设你要部署一个 Web 应用，以下是 Kubernetes 的工作流程：

1. 提交资源定义：
   • 你编写了一个 deployment.yaml 文件，定义 3 个副本，并通过 kubectl apply -f deployment.yaml 提交。
2. API Server 处理请求：
   • API Server 接收请求，验证后将其写入 etcd。
3. Controller Manager 检测变化：
   • Deployment Controller 发现期望状态是 3 个 Pod，但实际只有 2 个，于是创建第 3 个 Pod。
4. Scheduler 调度 Pod：
   • Scheduler 将新创建的 Pod 调度到合适的工作节点（如节点 A）。
5. Kubelet 启动容器：
   • 节点 A 上的 Kubelet 下载镜像并启动容器。
6. Kube Proxy 配置网络：
   • Kube Proxy 配置网络规则，确保外部请求可以访问 Web 应用。

Kubernetes 的核心组件包括：

• 控制平面：API Server、etcd、Controller Manager、Scheduler。
• 工作节点：Kubelet、Kube Proxy、容器运行时。
• 附加组件：DNS、Ingress Controller、CNI、存储插件。

https://github.com/0voice