k8s概要

ztio2025/7/29大约 19 分钟k8s

概述 | Kubernetes

Kubernetes为你提供：

服务发现和负载均衡
存储编排
自动部署和回滚
自动完成装箱计算
自我修复
密钥与配置管理
批处理执行
水平扩缩
IPv4/IPv6 双栈
为可扩展性设计

Kubernetes不是包罗万象的PaaS系统

不限制支持得应用类型
不部署源代码，也不构建你的应用服务
不是日志记录、监视或报警的解决方案
不提供也不要求配置的语言、系统，它提供声明性API
不用提供也不采用任何全面的机器配置、维护、管理或自我修复系统
Kubernetes不仅仅是编排系统，实际上它消除了编排的需要。

Kubernetes 的历史背景

传统部署时代
虚拟化部署时代
容器部署时代

Kubernetes 组件 | Kubernetes

核心组件

控制平面组件
- kube-apiserver
- etcd
- kube-scheduler
- kube-controller-manager
- cloud-controller-manager（optional）
Node组件
- kubelet
- kube-proxy(可选)
- 容器运行时（container runtime）
插件
- DNS：集群范围内
- Web界面（dashboard)
- 容器资源监控
- 集群层面日志

Kubernetes 对象 | Kubernetes

理解 Kubernetes 对象

Kubernetes 对象是持久化的实体。 Kubernetes 使用这些实体去表示整个集群的状态:

哪些容器化应用正在运行（以及在哪些节点上运行）
可以被应用使用的资源
关于应用运行时行为的策略，比如重启策略、升级策略以及容错策略

Kubernetes 对象是一种“意向表达（Record of Intent）”。一旦创建该对象， Kubernetes 系统将不断工作以确保该对象存在。通过创建对象，你本质上是在告知 Kubernetes 系统，你想要的集群工作负载状态看起来应是什么样子的，这就是 Kubernetes 集群所谓的期望状态（Desired State）。

操作 Kubernetes 对象 —— 无论是创建、修改或者删除 —— 需要使用 Kubernetes API。比如，当使用 kubectl 命令行接口（CLI）时，CLI 会调用必要的 Kubernetes API；也可以在程序中使用客户端库，来直接调用 Kubernetes API。

对象规约（Spec）与状态（Status）

关于对象 spec、status 和 metadata 的更多信息，可参阅 Kubernetes API 约定。

描述 Kubernetes 对象

这里有一个清单示例文件，展示了 Kubernetes Deployment 的必需字段和对象 spec：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2 # 告知 Deployment 运行 2 个与该模板匹配的 Pod
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

必需字段

在想要创建的 Kubernetes 对象所对应的清单（YAML 或 JSON 文件）中，需要配置的字段如下：

apiVersion - 创建该对象所使用的 Kubernetes API 的版本
kind - 想要创建的对象的类别
metadata - 帮助唯一标识对象的一些数据，包括一个 name 字符串、UID 和可选的 namespace
spec - 你所期望的该对象的状态

Kubernetes 架构 | Kubernetes

控制平面组件

控制平面组件会为集群做出全局决策，比如资源的调度。以及检测和响应集群事件，例如当不满足 Deployment 的 replicas 字段时，要启动新的 Pod）。

控制器有许多不同类型。以下是一些例子：
- Node 控制器：负责在节点出现故障时进行通知和响应
- Job 控制器：监测代表一次性任务的 Job 对象，然后创建 Pod 来运行这些任务直至完成
- EndpointSlice 控制器：填充 EndpointSlice 对象（以提供 Service 和 Pod 之间的链接）。
- ServiceAccount 控制器：为新的命名空间创建默认的 ServiceAccount。

cloud-controller-manager

下面的控制器都包含对云平台驱动的依赖：

Node 控制器：用于在节点终止响应后检查云平台以确定节点是否已被删除
Route 控制器：用于在底层云基础架构中设置路由
Service 控制器：用于创建、更新和删除云平台上的负载均衡器

节点组件

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

kubelet

kubelet 会在集群中每个节点（node）上运行。它保证容器（containers）都运行在 Pod 中。

kube-proxy（可选）

容器运行时

这个基础组件使 Kubernetes 能够有效运行容器。它负责管理 Kubernetes 环境中容器的执行和生命周期。

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

插件（Addons）

插件使用 Kubernetes 资源（DaemonSet、 Deployment 等）实现集群功能。因为这些插件提供集群级别的功能，插件中命名空间域的资源属于 kube-system 命名空间

DNS

Web 界面（仪表盘）

容器资源监控

集群层面日志

网络插件

架构变种

虽然 Kubernetes 的核心组件保持一致，但它们的部署和管理方式可能有所不同。了解这些变化对于设计和维护满足特定运营需求的 Kubernetes 集群至关重要。

控制平面部署选项

控制平面组件可以通过以下几种方式部署：

传统部署
控制平面组件直接在专用机器或虚拟机上运行，通常作为 systemd 服务进行管理。
静态 Pod
控制平面组件作为静态 Pod 部署，由特定节点上的 kubelet 管理。这是像 kubeadm 这样的工具常用的方法。
自托管
控制平面在 Kubernetes 集群本身内部作为 Pod 运行，由 Deployments、StatefulSets 或其他 Kubernetes 原语管理。
托管 Kubernetes 服务
云平台通常将控制平面抽象出来，将其组件作为其服务的一部分进行管理。

工作负载调度说明

含控制平面组件在内的工作负载的调度可能因集群大小、性能要求和操作策略而有所不同：

- 在较小或开发集群中，控制平面组件和用户工作负载可能在同一节点上运行。
- 较大的生产集群通常将特定节点专用于控制平面组件，将其与用户工作负载隔离。
- 一些组织在控制平面节点上运行关键组件或监控工具。

集群管理工具

像 kubeadm、kops 和 Kubespray 这样的工具提供了不同的集群部署和管理方法

Kubernetes 架构的灵活性使各组织能够根据特定需求调整其集群，平衡操作复杂性、性能和管理开销等因素。

定制和可扩展性

Kubernetes 架构允许大幅度的定制：

你可以部署自定义的调度器与默认的 Kubernetes 调度器协同工作，也可以完全替换掉默认的调度器。
API 服务器可以通过 CustomResourceDefinition 和 API 聚合进行扩展。
云平台可以使用 cloud-controller-manager 与 Kubernetes 深度集成。

节点 | Kubernetes

管理

向 API 服务器添加节点的方式主要有两种：

节点上的 kubelet 向控制面执行自注册；
你（或者别的什么人）手动添加一个 Node 对象。
Node 对象的名称必须是合法的 DNS 子域名。

节点名称唯一性

节点自注册

手动节点管理

节点状态

一个节点的状态包含以下信息:

地址（Addresses）
状况（Condition）
容量与可分配（Capacity）
信息（Info）

节点心跳

节点控制器

逐出速录限制

资源容量跟踪

节点拓扑

节点与控制面之间的通信 | Kubernetes

本文列举控制面节点（确切地说是 API 服务器）和 Kubernetes 集群之间的通信路径。目的是为了让用户能够自定义他们的安装，以实现对网络配置的加固，使得集群能够在不可信的网络上（或者在一个云服务商完全公开的 IP 上）运行。

节点到控制面

控制面到节点

API 服务器到 kubelet

API 服务器到节点、Pod 和服务

SSH 隧道

Konnectivity 服务

控制器 | Kubernetes

在 Kubernetes 中，控制器通过监控集群的公共状态，并致力于将当前状态转变为期望的状态。

控制器模式

通过 API 服务器来控

直接控制

期望状态与当前状态

设计

运行控制器的方式

租约（Lease） | Kubernetes

云控制器管理器 | Kubernetes

Kubernetes 自我修复 | Kubernetes

关于 cgroup v2 | Kubernetes

容器运行时接口（CRI） | Kubernetes

Kubernetes 容器运行时接口（CRI）定义了在节点组件 kubelet 和容器运行时之间通信的主要 gRPC 协议。

垃圾收集 | Kubernetes

垃圾收集允许系统清理如下资源：

终止的 Pod
已完成的 Job
不再存在属主引用的对象
未使用的容器和容器镜像
动态制备的、StorageClass 回收策略为 Delete 的 PV 卷
阻滞或者过期的 CertificateSigningRequest (CSR)
在以下情形中删除了的节点对象：
- 当集群使用云控制器管理器运行于云端时；
- 当集群使用类似于云控制器管理器的插件运行在本地环境中时。
节点租约对象

混合版本代理 | Kubernetes

容器 | Kubernetes

容器镜像

容器镜像是一个随时可以运行的软件包，包含运行应用程序所需的一切：代码和它需要的所有运行时、应用程序和系统库，以及一些基本设置的默认值。
容器旨在设计成无状态且不可变的：你不应更改已经运行的容器的代码。如果有一个容器化的应用程序需要修改，正确的流程是：先构建包含更改的新镜像，再基于新构建的镜像重新运行容器。

容器运行时

通常，你可以允许集群为一个 Pod 选择其默认的容器运行时。如果你需要在集群中使用多个容器运行时，你可以为一个 Pod 指定 RuntimeClass，以确保 Kubernetes 会使用特定的容器运行时来运行这些容器。

镜像 | Kubernetes

容器环境 | Kubernetes

容器运行时类（Runtime Class） | Kubernetes

容器生命周期回调 | Kubernetes

工作负载 | Kubernetes

为了减轻用户的使用负担，通常不需要用户直接管理每个 Pod。而是使用负载资源来替用户管理一组 Pod。这些负载资源通过配置控制器来确保正确类型的、处于运行状态的 Pod 个数是正确的，与用户所指定的状态相一致。

Kubernetes 提供若干种内置的工作负载资源：

Deployment 和 ReplicaSet （替换原来的资源 ReplicationController）。 Deployment 很适合用来管理你的集群上的无状态应用，Deployment 中的所有 Pod 都是相互等价的，并且在需要的时候被替换。
StatefulSet 让你能够运行一个或者多个以某种方式跟踪应用状态的 Pod。例如，如果你的负载会将数据作持久存储，你可以运行一个 StatefulSet，将每个 Pod 与某个 PersistentVolume 对应起来。你在 StatefulSet 中各个 Pod 内运行的代码可以将数据复制到同一 StatefulSet 中的其它 Pod 中以提高整体的服务可靠性。
DaemonSet 定义提供节点本地支撑设施的 Pod。这些 Pod 可能对于你的集群的运维是非常重要的，例如作为网络链接的辅助工具或者作为网络插件的一部分等等。每次你向集群中添加一个新节点时，如果该节点与某 DaemonSet 的规约匹配，则控制平面会为该 DaemonSet 调度一个 Pod 到该新节点上运行。
Job 和 CronJob。定义一些一直运行到结束并停止的任务。你可以使用 Job 来定义只需要执行一次并且执行后即视为完成的任务。你可以使用 CronJob 来根据某个排期表来多次运行同一个 Job。

在庞大的 Kubernetes 生态系统中，你还可以找到一些提供额外操作的第三方工作负载相关的资源。通过使用定制资源定义（CRD），你可以添加第三方工作负载资源，以完成原本不是 Kubernetes 核心功能的工作。例如，如果你希望运行一组 Pod，但要求所有 Pod 都可用时才执行操作（比如针对某种高吞吐量的分布式任务），你可以基于定制资源实现一个能够满足这一需求的扩展，并将其安装到集群中运行。

Pod | Kubernetes

什么是 Pod？

Kubernetes 集群中的 Pod 主要有两种用法：

运行单个容器的 Pod。"每个 Pod 一个容器"模型是最常见的 Kubernetes 用例；在这种情况下，可以将 Pod 看作单个容器的包装器，并且 Kubernetes 直接管理 Pod，而不是容器。
运行多个协同工作的容器的 Pod。 Pod 可以封装由紧密耦合且需要共享资源的多个并置容器组成的应用。这些位于同一位置的容器构成一个内聚单元。

使用 Pod

用于管理 Pod 的工作负载资源

通常你不需要直接创建 Pod，甚至单实例 Pod。相反，你会使用诸如 Deployment 或 Job 这类工作负载资源来创建 Pod。如果 Pod 需要跟踪状态，可以考虑 StatefulSet 资源。
Pod 天生地为其成员容器提供了两种共享资源：网络和存储。

使用 Pod

Pod 操作系统

你应该将 .spec.os.name 字段设置为 windows 或 linux 以表示你希望 Pod 运行在哪个操作系统之上。这两个是 Kubernetes 目前支持的操作系统。将来，这个列表可能会被扩充。

Pod 和控制器

你可以使用工作负载资源来创建和管理多个 Pod。

Deployment
StatefulSet
DaemonSet

Pod 模板

工作负载资源的控制器通常使用 Pod 模板（Pod Template）来替你创建 Pod 并管理它们。

Pod 模板是包含在工作负载对象中的规范，用来创建 Pod。这类负载资源包括 Deployment、 Job 和 DaemonSet 等。

Pod 更新与替换

Pod 子资源

资源共享和通信

Pod 中的存储

Pod 联网

Pod 安全设置

静态 Pod

静态 Pod（Static Pod）直接由特定节点上的 kubelet 守护进程管理，不需要 API 服务器看到它们。尽管大多数 Pod 都是通过控制面（例如，Deployment）来管理的，对于静态 Pod 而言，kubelet 直接监控每个 Pod，并在其失效时重启之。

Pod 管理多个容器

例如，你可能有一个容器，为共享卷中的文件提供 Web 服务器支持，以及一个单独的边车（Sidercar）容器负责从远端更新这些文件，如下图所示：

容器探针

Pod 的生命周期 | Kubernetes

和一个个独立的应用容器一样，Pod 也被认为是相对临时性（而不是长期存在）的实体。
Pod 在其生命周期中只会被调度一次。将 Pod 分配到特定节点的过程称为绑定，而选择使用哪个节点的过程称为调度。

关联的生命期

如果某物声称其生命期与某 Pod 相同，例如存储卷，这就意味着该对象在此 Pod （UID 亦相同）存在期间也一直存在。如果 Pod 因为任何原因被删除，甚至某完全相同的替代 Pod 被创建时，这个相关的对象（例如这里的卷）也会被删除并重建。

一个包含文件拉取程序 Sidecar（边车）和 Web 服务器的多容器 Pod。此 Pod 使用临时 emptyDir 卷作为容器之间的共享存储。

Pod 阶段

下面是 phase 可能的值

Pod 状态说明

取值	描述
Pending（悬决）	Pod 已被 Kubernetes 系统接受，但有一个或者多个容器尚未创建亦未运行。此阶段包括等待 Pod 被调度的时间和通过网络下载镜像的时间。
Running（运行中）	Pod 已经绑定到了某个节点，Pod 中所有的容器都已被创建。至少有一个容器仍在运行，或者正处于启动或重启状态。
Succeeded（成功）	Pod 中的所有容器都已成功结束，并且不会再重启。
Failed（失败）	Pod 中的所有容器都已终止，并且至少有一个容器是因为失败终止。也就是说，容器以非 0 状态退出或者被系统终止，且未被设置为自动重启。
Unknown（未知）	因为某些原因无法取得 Pod 的状态。这种情况通常是因为与 Pod 所在主机通信失败。

容器状态

容器的状态有三种：Waiting（等待）、Running（运行中）和 Terminated（已终止）。
要检查 Pod 中容器的状态，你可以使用 kubectl describe pod <pod 名称>。其输出中包含 Pod 中每个容器的状态。

Pod 如何处理容器问题

最初的崩溃：Kubernetes 尝试根据 Pod 的 restartPolicy 立即重新启动。
反复的崩溃：在最初的崩溃之后，Kubernetes 对于后续重新启动的容器采用指数级回退延迟机制，如 restartPolicy 中所述。这一机制可以防止快速、重复的重新启动尝试导致系统过载。
CrashLoopBackOff 状态：这一状态表明，对于一个给定的、处于崩溃循环、反复失效并重启的容器，回退延迟机制目前正在生效。
回退重置：如果容器成功运行了一定时间（如 10 分钟）， Kubernetes 会重置回退延迟机制，将新的崩溃视为第一次崩溃。

Init 容器 | Kubernetes

理解 Init 容器

Pod 也可以有一个或多个先于应用容器启动的 Init 容器。

Init 容器与普通的容器非常像，除了如下两点：

它们总是运行到完成。
每个都必须在下一个启动之前成功完成。

Init 容器可以包含一些安装过程中应用容器中不存在的实用工具或个性化代码。例如，没有必要仅为了在安装过程中使用类似 sed、awk、python 或 dig 这样的工具而去 FROM 一个镜像来生成一个新的镜像。
由于 Init 容器必须在应用容器启动之前运行完成，因此 Init 容器提供了一种机制来阻塞或延迟应用容器的启动，直到满足了一组先决条件。一旦前置条件满足，Pod 内的所有的应用容器会并行启动。

Deployment （也间接包括 ReplicaSet）是在集群上运行应用的最常见方式。
StatefulSet 允许你管理一个或多个运行相同应用代码、但具有不同身份标识的 Pod。
DaemonSet 定义了在特定节点上提供本地设施的 Pod，例如允许该节点上的容器访问存储系统的驱动。当必须在合适的节点上运行某种驱动或其他节点级别的服务时，你可以使用 DaemonSet。DaemonSet 中的每个 Pod 执行类似于经典 Unix / POSIX 服务器上的系统守护进程的角色。DaemonSet 可能对集群的操作至关重要，例如作为插件让该节点访问集群网络，也可能帮助你管理节点，或者提供增强正在运行的容器平台所需的、不太重要的设施。你可以在集群的每个节点上运行 DaemonSets（及其 Pod），或者仅在某个子集上运行（例如，只在安装了 GPU 的节点上安装 GPU 加速驱动）。
你可以使用 Job 和/或 CronJob 定义一次性任务和定时任务。 Job 表示一次性任务，而每个 CronJob 可以根据排期表重复执行。