K8s介绍以及组件的作用

一、K8S介绍

Kubernetes 通常简称为 k8s（字母 K 和 s 之间有 8 个字母），是一款开源的容器编排与管理平台，由 Google 基于其内部的 Borg 系统研发并捐赠给云原生计算基金会（CNCF），目前是云原生技术生态的核心。

Kubernetes 用于管理云平台中多个主机上的容器化的应用，Kubernetes的目标是让部署容器化的应用简单并且高效,Kubernetes提供了应用部署，规划，更新，维护的强大和灵活的机制。

官网：https://kubernetes.io/

github：https://github.com/kubernetes/kubernetes

传统部署-虚拟化部署-容器部署方式区别：

二、k8s 的核心价值

如果把容器（比如 Docker 容器）比作一个个独立运行的 “应用盒子”，那么 k8s 就是管理这些盒子的 “智能操作系统”，解决了容器集群的三大核心痛点：

1. 自动化部署：替代人工手动启动容器，按规则批量部署应用实例。
2. 高可用保障：容器故障时自动重启，节点故障时自动迁移容器，确保应用不中断。
3. 弹性伸缩：根据 CPU 利用率、请求量等指标，自动增加或减少容器实例数量。
4. 服务发现与负载均衡：自动为容器分配可访问的网络地址，实现请求的均匀分发。

三、k8s 的核心架构

k8s 采用 主从（Master-Node）分布式架构，集群由两类节点组成，各节点分工明确。

Master：总指挥、老板、大脑

Node：干活的员工、服务器、干活机器

Pod：最小运行单位（一个 Pod 里装 1 个 / 多个容器）

容器：你的项目、服务（nginx、java、后端程序等）

Master 只管发指令、调度、管理，不跑业务程序

Node 专门负责真正跑项目、跑容器、干活

1.Master 节点（控制平面）

组件	作用
kube-apiserver	集群的统一入口，所有操作（如创建 Pod、部署应用）都通过它执行，同时提供认证、授权功能
etcd	集群的 “数据库”，存储所有集群状态和配置信息（如 Pod 定义、服务规则），是核心数据存储
kube-scheduler	调度器，负责为新建的 Pod 选择最合适的 Node 节点运行（基于资源利用率、亲和性等规则）。专门分配工作、派活的，决定这个项目跑在哪一台员工机器上。
kube-controller-manager	控制器管理器，包含多种控制器（如 Pod 控制器、节点控制器），负责监控集群状态，当实际状态与期望状态不一致时，自动触发修复（比如 Pod 挂了就重启）

2.Node 节点（工作节点）

组件	作用
kubelet	Master 在 Node 上的 “代理人”，接收 Master 的指令，管理本机的 Pod 生命周期（创建、启动、停止 Pod），并向 Master 汇报节点状态。大白话就是每个员工身上的小组长，老板 (Master) 发命令，它来落地执行干活。
kube-proxy	网络代理，负责为 Pod 提供网络访问能力，实现服务发现和负载均衡（比如将请求转发到不同的 Pod 实例）。负责集群网络、端口转发、访问通信。大白话就是网管 + 接线员，管所有网络连通、请求转发、互相访问。
容器运行时（Container Runtime）	负责拉取镜像、启动容器、停止容器、运行容器 K8s 只是管理它，真正装程序、跑程序全靠它。大白话：干活底层工具，所有项目容器，都是靠它跑起来的。

3.master和node的区别

Master 节点

• 身份：集群大脑、控制中心、总指挥
• 工作：管调度、管分配、管规则、管数据、管监控
• 不跑：不跑业务项目、不跑业务 Pod
• 一个集群可以有 1 个主 Master / 多个高可用 Master

Node 节点

• 身份：干活机器、业务服务器
• 工作：专门跑 Pod、跑容器、跑你的业务服务
• 所有真实项目全部跑在 Node 上
• 集群可以随便加很多个 Node，横向扩容

一句话原理：Master 发号施令，Node 落地干活，etcd 存数据，apiserver 做中转

四、k8s 的核心资源对象

k8s 通过声明式 API 管理资源，用户只需定义 “应用要达到什么状态”，k8s 会自动完成后续操作。核心资源对象包括：

1. Pod

• 定义：k8s 中最小的部署单元，一个 Pod 可以包含一个或多个紧密关联的容器（比如应用容器 + 日志收集容器）。
• 特点：Pod 内的容器共享网络和存储资源，同一 Pod 内的容器可以通过 localhost 通信；Pod 是临时性的，一旦被删除或故障，会被重新创建（IP 也会变化）。

2. Deployment

• 定义：最常用的无状态应用控制器，用于管理 Pod 的创建和扩缩容。

• 核心功能

  • 滚动更新：更新应用时不中断服务，逐个替换旧 Pod。

  • 版本回滚：如果更新失败，可一键回滚到之前的稳定版本。

  • 扩缩容：手动或自动调整 Pod 的副本数量。

3. Service

• 定义：为一组 Pod 提供稳定的访问入口的资源，解决了 Pod IP 动态变化的问题。
• 核心类型：
  • ClusterIP：仅集群内部可访问，用于集群内服务之间的通信。
  • NodePort：将服务暴露到集群所有 Node 节点的固定端口，外部可通过 NodeIP:NodePort 访问。
  • LoadBalancer：借助云服务商的负载均衡器，将服务暴露到公网（云环境常用）。

4. Namespace

• 定义：集群的虚拟隔离空间，可以将资源划分到不同的 Namespace 中，实现多团队、多环境的资源隔离（比如开发环境、测试环境、生产环境）。
• 特点：不同 Namespace 内的资源名称可以重复，同一 Namespace 内的资源名称必须唯一。

5. ConfigMap & Secret

• ConfigMap：存储非敏感的配置信息（如配置文件、环境变量），可以挂载到 Pod 中，实现配置与代码的分离。
• Secret：存储敏感信息（如密码、Token、证书），数据会被加密存储，同样可以挂载到 Pod 中使用。

五、k8s 的典型应用场景

1. 微服务架构部署：将一个大型应用拆分为多个微服务，每个微服务用一个 Deployment 管理，通过 Service 实现服务间通信。
2. 持续集成 / 持续部署（CI/CD）：结合 Jenkins、GitLab CI 等工具，实现代码提交后自动构建镜像、更新 k8s 应用。
3. 大规模容器集群管理：轻松管理成百上千个容器，替代人工运维，降低管理成本。
4. 混合云 / 多云部署：k8s 可以在公有云（阿里云、AWS）、私有云、物理机上运行，实现应用的跨环境迁移。

六、k8s 的优势与局限性

优势

• 开源免费：基于 Apache 2.0 协议，无商业许可费用。
• 高度可扩展：支持自定义资源（CRD）、插件扩展（如网络插件、存储插件），满足复杂业务需求。
• 云中立：不绑定特定云厂商，实现 “一次部署，到处运行”。
• 强大的社区支持：CNCF 维护，全球开发者贡献，生态工具丰富（如监控工具 Prometheus、日志工具 ELK）。

局限性

• 学习曲线陡峭：概念多、组件多，新手入门难度较大。
• 部署和运维复杂：需要配置网络、存储、安全等多个模块，对运维人员要求高。
• 资源开销较大：Master 节点和 Node 节点的核心组件会占用一定的 CPU 和内存资源，不适合超小型集群。

七、k8s 与 Docker 的关系

很多人会混淆 k8s 和 Docker，两者的关系可以总结为：

• Docker：是容器运行时，负责构建和运行容器，是 k8s 的 “底层工具”。
• k8s：是容器编排平台，负责管理大量 Docker 容器，提供自动化运维能力。
• 注意：k8s 并不依赖 Docker，也可以使用 containerd、CRI-O 等其他容器运行时。

八、K8s 完整整套工作流程（从头到尾一步一步）

我用「你部署一个 Nginx 服务」举例，完整全流程：

1. 你在机器上执行：kubectl create 部署 nginx
2. 这个命令先发送给 apiserver（Master 大门）
3. apiserver 校验权限、语法没问题，把配置存入 etcd 数据库
4. kube-scheduler（调度器） 监听到要创建新 Pod
5. scheduler 挨个检查所有 Node 节点 CPU、内存负载
6. 挑选一个合适空闲的 Node，决定就部署在这台机器
7. apiserver 把调度结果下发给 对应 Node 的 kubelet
8. kubelet 收到命令，调用 containerd/docker
9. docker 去镜像仓库拉取 nginx 镜像
10. 拉取完成，创建、启动 nginx 容器
11. kube-proxy 配置好网络规则，做好流量转发
12. kubelet 实时把「pod 启动成功、运行正常」上报给 Master
13. controller-manager 一直循环监控，只要 pod 不挂就正常运行
14. 若 pod 意外挂掉，控制器自动重启、自动补建
15. 外部用户就可以通过地址，正常访问到你的 Nginx 服务

​ K8S流程图

【用户/你】
     ↓  kubectl 命令（创建/删除/查看pod）
——————————————————————————————————
        Master 控制平面（大脑指挥中心）
——————————————————————————————————
1.kube-apiserver  【统一入口 大门】
     ↓（存数据）
2.etcd  【集群数据库 存所有配置+状态】
     ↓
3.kube-scheduler 【调度器：选空闲Node节点】
     ↓
4.kube-controller-manager 【控制器：监控状态、挂了自动重启补pod】
     ↓ 下发执行指令
——————————————————————————————————
         Node 工作节点（真正干活）
——————————————————————————————————
1.kubelet 【接收命令、负责本机干活】
     ↓
2.容器运行时 containerd/docker 【拉镜像、启动容器、运行程序】
     ↓
3.kube-proxy 【配置网络、转发流量、外部访问】
     ↓
【最终：Pod容器正常运行，对外提供服务】

master 只做：管理、调度、存数据、发指令，不跑任何业务容器

apiserver：所有命令、所有组件通信，全部必须走它，是集群唯一入口

etcd：存集群所有数据，节点、pod、配置、状态全存在这里，相当于账本

scheduler：新建 pod 时，帮你挑一台CPU 内存空闲的 node 机器，分配位置

controller-manager：实时一直巡检，期望 3 个 pod，崩 1 个就自动给你补 1 个，维持状态不变

node 只做：老老实实接收命令，跑容器、跑项目、干实际业务活

kubelet：每个 node 上的执行者，接收 master 命令，在本机创建、启动、停止 pod

containerd：底层负责拉镜像、跑容器，k8s 只是指挥它干活

kube-proxy：管 pod 之间互通、外网访问服务、负载均衡、端口转发