1、什么是K8s

一、什么是 Kubernetes

Kubernetes(简称 K8s) 是 Google 开源的容器编排平台,用于自动化部署、扩展和管理容器化应用。

|------|----------------------------------------------------|
| 诞生背景 | :源于 Google 内部 Borg 系统,2014 年开源,现由 CNCF(云原生计算基金会)维护 |
| 核心定位 | :不是容器运行时(如 Docker),而是容器编排引擎------负责调度和管理容器 |
| 设计目标 | :让部署容器化应用像部署单个容器一样简单,同时提供生产级的高可用、弹性伸缩、自愈能力 |

二、为什么要用 K8s?(解决什么问题)

传统部署痛点:
├─ 手动部署容器 → 效率低、易出错
├─ 机器故障 → 服务宕机,需人工迁移
├─ 流量突增 → 无法自动扩容,服务被打挂
├─ 多环境配置 → 开发/测试/生产环境不一致
└─ 服务发现/负载均衡 → 需自行搭建

K8s 提供的解决方案:
├─ 自动部署与回滚
├─ 服务自愈(节点故障自动重新调度)
├─ 水平自动扩缩容(HPA)
├─ 服务发现与负载均衡(内置)
├─ 配置管理(ConfigMap/Secret)
└─ 存储编排(自动挂载各类存储)

三、核心架构:Control Plane + Worker Node

K8s 集群由两类节点组成:

┌─────────────────────────────────────────────────────────┐
│ Kubernetes Cluster │
├─────────────────────────┬───────────────────────────────┤
│ Control Plane │ Worker Nodes │
│ (控制平面/主节点) │ (工作节点) │
│ │ │
│ ┌─────────────────┐ │ ┌─────────────────────┐ │
│ │ API Server │ │ │ kubelet │ │
│ │ (集群入口网关) │ │ │ (节点代理) │ │
│ └─────────────────┘ │ └─────────────────────┘ │
│ ┌─────────────────┐ │ ┌─────────────────────┐ │
│ │ etcd │ │ │ kube-proxy │ │
│ │ (数据存储) │ │ │ (网络代理/负载均衡) │ │
│ └─────────────────┘ │ └─────────────────────┘ │
│ ┌─────────────────┐ │ ┌─────────────────────┐ │
│ │ Scheduler │ │ │ Container Runtime │ │
│ │ (调度器) │ │ │ (容器运行时:Docker/ │ │
│ └─────────────────┘ │ │ containerd等) │ │
│ ┌─────────────────┐ │ └─────────────────────┘ │
│ │ Controller Mgr │ │ │
│ │ (控制器管理器) │ │ ┌─────────────────────┐ │
│ └─────────────────┘ │ │ Pod (运行单元) │ │
│ │ └─────────────────────┘ │
└─────────────────────────┴───────────────────────────── ┘

四、核心概念(必须掌握)

1. Pod(最小调度单元)

  • Pod 是一组容器的集合,是 K8s 中最小的可部署单元
  • 一个 Pod 内的容器共享网络命名空间(IP 相同)和存储卷
  • 通常一个 Pod 只运行一个主容器(Sidecar 模式除外)

2. Node(节点)

  • 物理机或虚拟机,分为 Master Node(控制平面) 和 Worker Node(工作节点)
  • Worker Node 上运行实际的应用负载

3. Cluster(集群)

  • 一个 K8s 集群 = 1个 Control Plane + N 个 Worker Node

4. Namespace(命名空间)

  • 逻辑隔离单位,用于区分不同环境(如 dev、test、prod)或不同团队

五、核心组件详解

Control Plane 组件

|--------------------|------------------------------------------------------------------|
| 组件 | 作用 |
| API Server | 集群的唯一入口,所有操作(包括 kubectl 命令)都通过它进行,负责认证、鉴权、校验 |
| etcd | 分布式键值数据库,存储集群的所有配置数据和状态信息(是集群的"大脑记忆") |
| Scheduler | 调度器,负责将新创建的 Pod 分配到合适的 Worker Node 上 |
| Controller Manager | 运行各种控制器(如 Deployment Controller、Node Controller),确保集群实际状态与期望状态一致 |

Worker Node 组件

|-------------------|--------------------------------------------------|
| 组件 | 作用 |
| kubelet | 节点代理,接收 API Server 指令,管理本节点上的 Pod 生命周期 |
| kube-proxy | 网络代理,维护节点上的网络规则,实现 Service 的负载均衡 |
| Container Runtime | 容器运行时,负责真正运行容器(如 containerd、CRI-O,Docker 已逐步被替代) |

六、核心资源对象(API 对象)

|-----------------------------|----------------------------------------------------|---------|
| 资源 | 说明 | 类比 |
| Pod | 最小运行单元,包含一个或多个容器 | 一个"进程组" |
| Deployment | 管理 Pod 的副本数和更新策略,支持滚动升级/回滚 | 应用的管理者 |
| ReplicaSet | 确保指定数量的 Pod 副本始终运行(通常由 Deployment 自动管理) | 副本控制器 |
| Service | 为一组 Pod 提供稳定的访问入口(ClusterIP/NodePort/LoadBalancer) | 负载均衡器 |
| Ingress | 集群入口网关,基于域名/路径路由 HTTP/HTTPS 流量 | 智能路由器 |
| ConfigMap | 存储非敏感的配置数据(如配置文件、环境变量) | 配置文件 |
| Secret | 存储敏感数据(如密码、Token、TLS 证书),Base64 编码 | 密钥库 |
| PersistentVolume (PV) | 集群级别的存储资源 | 硬盘 |
| PersistentVolumeClaim (PVC) | 用户对存储的请求/声明 | 存储订单 |
| StatefulSet | 管理有状态应用(如数据库),保证 Pod 名称、网络标识、存储的稳定 | 有状态控制器 |
| DaemonSet | 确保每个(或指定)Node 上运行一个 Pod 副本 | 守护进程 |
| Job / CronJob | 一次性任务 / 定时任务 | 批处理/定时器 |

七、K8s 的工作流程(以部署一个应用为例)

  1. 用户执行: kubectl apply -f deployment.yaml
    ↓
  2. kubectl 将请求发送给 API Server
    ↓
  3. API Server 将配置写入 etcd
    ↓
  4. Controller Manager 中的 Deployment Controller 检测到新资源
    → 创建 ReplicaSet,设定期望副本数
    ↓
  5. Scheduler 监控到未调度的 Pod
    → 根据资源需求、亲和性等策略,选择合适的 Node
    ↓
  6. 目标 Node 上的 kubelet 收到调度指令
    → 调用 Container Runtime 创建并运行 Pod
    ↓
  7. kube-proxy 配置网络规则,使 Service 能将流量转发到该 Pod
    ↓
  8. Controller Manager 持续监控

→ 如果 Pod 挂掉,自动创建新的 Pod(自愈)
→ 如果副本数不足,自动补充

八、K8s 的核心设计哲学

|---------|--------------------------------------------|
| 原则 | 含义 |
| 声明式 API | 你告诉 K8s "我想要什么状态",K8s 自动帮你达到并维持该状态 |
| 控制器模式 | 通过无限循环(Reconcile Loop)对比"期望状态"与"实际状态",持续纠偏 |
| 不可变基础设施 | 不修改运行中的容器,而是替换为新版本(滚动更新) |
| 解耦与抽象 | 应用与基础设施解耦,通过标准接口(CRI/CNI/CSI)对接不同底层实现 |

相关推荐
帷幕落秋3 小时前
Docker的两种安装
运维·docker·容器
fengkai45454 小时前
十二、Redis -2
运维·数据库·redis·容器
DolitD6 小时前
3D应用多实例并发中的GPU隔离技术路径分析
容器·gru·接口隔离原则
姜鱼问生7 小时前
docker exec 排查容器问题:从日志到进程
运维·网络·数据库·docker·容器
小匠石钧知9 小时前
07_在k8s集群中安装ingress-nginx
nginx·容器·kubernetes·ingress
零基础12310 小时前
Docker 部署实战:从入门到精通
docker·容器
承渊政道10 小时前
自建服务越来越多怎么管理?Docker部署Flare,搭一个自己的数字入口
运维·docker·容器·内网穿透·cpolar·nas·flare
芷栀夏11 小时前
极空间部署Photopea:Docker运行、网页修图与多设备使用
运维·docker·容器
openFuyao1 天前
新增Agent沙箱调度能力!openFuyao v26.09社区发行版上线,AI原生基础设施能力进一步升级
云原生·ai-native·ai推理·openfuyao·多样化算力集群软件