K8s 完整知识体系（含架构图）

K8s 是什么？（它解决了什么问题？）

传统云服务器部署业务，存在 4 个核心痛点：

1. 部署繁琐：多台服务器手动部署 Docker 镜像，重复操作、效率极低；
2. 扩缩容困难：业务流量暴涨 / 暴跌时，无法自动增加 / 减少容器实例；
3. 自愈能力差：容器宕机、服务器故障，需要人工重启，业务中断；
4. 运维复杂：版本更新、灰度发布、滚动更新、负载均衡、网络通信全靠手动维护。

K8s 本质就是容器编排平台，它的作用就是解决上面列出来的问题。

K8s 整体架构与组件（它的架构）

附加组件
工作节点 Worker
控制平面 Master
外部流量入口
Ingress 控制器
客户端/用户
kube-apiserver
etcd
kube-scheduler
kube-controller-manager
kubelet
kube-proxy
容器运行时
业务Pod
CoreDNS
Metrics Server
CNI网络插件

1. 控制平面 Master（集群大脑）

• kube-apiserver：集群唯一入口，接收 kubectl / 用户指令，鉴权、校验、转发。
• etcd：分布式键值数据库，存储集群所有状态数据。
• kube-scheduler：调度器，把 Pod 分配到最合适的节点。
• kube-controller-manager：内置所有控制器，负责副本、自愈、扩缩容。
• cloud-controller-manager（可选）：对接云厂商资源。

2. 工作节点 Worker（实际运行业务）

• kubelet：管理本节点 Pod 的创建、监控、销毁。
• kube‑proxy：维护网络规则、服务发现、负载均衡。
• 容器运行时：containerd，负责运行容器。
• Pod：K8s 最小调度单元。

3. 入口 & 插件组件

• Ingress：集群流量入口，实现域名路由、负载均衡、HTTPS；
• CoreDNS：集群内部 DNS，Pod 之间用域名互相访问；
• CNI 网络插件：Calico/Flannel，打通所有节点、Pod 的网络通信。

k8s的控制器,资源,日志查看（重点看什么）

K8s 控制器体系

既然是编排，那么我们总要知道有哪些可以使用的控制器，学习编排主要就是学习这些控制器的使用。以及他们都用在什么时候。

kube‑controller‑manager ：控制器，实现自愈、扩缩容、副本维持，比如 Pod 挂了自动重建、副本数不足自动补齐。

一、内置控制器（K8s 自带，最常用）

在K8S中对容器的控制主要是通过控制器实现的，常见的控制器有

1. Deployment：无状态应用，滚动更新、回滚、扩缩容
2. ReplicaSet：维持 Pod 副本数
3. StatefulSet：有状态应用（数据库、中间件）
4. DaemonSet：每个节点必须运行一个（驱动、插件、监控）
5. Job / CronJob：一次性任务 / 定时任务

---

二、系统底层控制器

Node、Namespace、Endpoint、ServiceAccount、ResourceQuota 控制器

---

三、扩展控制器

1. HPA（HorizontalPodAutoscaler 水平 Pod 自动扩缩容）

   根据 CPU / 内存 / 自定义指标，自动增减 Pod 数量，流量高峰扩容、低谷缩容

2. Ingress Controller：流量入口控制器，实现域名路由、负载均衡、HTTPS

3. PV/PVC Controller：存储控制器，管理持久卷挂载、存储生命周期

---

四、高级：自定义控制器 Operator（CRD）

• Device Plugin：节点级插件，负责硬件上报、分配、隔离。
• Operator：厂商自研大脑，负责驱动更新、固件升级、故障自愈、调度增强。

K8s 资源类型与查看命令

既然是调度，那么我们总要知道资源都有哪些，以及怎么看调度之后出现的问题吧

4.1 四大类资源

1. 计算资源：cpu、memory
2. 硬件扩展资源：GPU、NPU、IPU、FPGA 等
3. 存储挂载资源：PVC、ConfigMap、Secret、emptyDir、hostPath
4. 网络与权限资源：端口、网络策略、安全权限、节点亲和

4.2 资源查看常用命令

kubectl api‑resources # 查有哪些资源
kubectl get xxx # 查资源列表
kubectl describe xxx # 查详细信息、排错
kubectl get all # 快速看环境里所有东西
kubectl get crd # 查看所有自定义资源（硬件厂商Operator的资源）
kubectl get nodes # 查看节点
kubectl api-resources --namespaced=true # 查看资源的简写（常用！）

基于
依赖
管控
🔴 1. 基础设施层
Node节点

kubelet / kube‑proxy / 容器运行时
CNI 网络插件

Calico / Flannel
CSI 存储插件
🟡 2. 编排调度层（控制平面）
kube‑apiserver
etcd 存储
kube‑scheduler 调度器
kube‑controller‑manager

内置各类原生控制器
🟢 3. 应用抽象层
Deployment / StatefulSet / DaemonSet / Job
Service / Ingress
ConfigMap / Secret
🔹 4. 生态扩展层
CRD 自定义资源
Operator 控制器
Admission Webhook
聚合API

K8s 日志查看（运维 / 硬件排障）

Pod 日志查看

kubectl logs <pod-name> -n <ns>
kubectl logs -f <pod-name> -n <ns>
kubectl logs -f daemonset/xxx -n kube-system

进入容器内部排查

kubectl exec -it <pod-name> -- /bin/bash
tail -f /xxx/log/app.log

集群与节点日志

kubectl logs -n kube-system kube-apiserver-xxx
journalctl -u kubelet -f
journalctl -u kubelet --since=1h

K8S高频面试题（3 道）

1. Deployment 和 DaemonSet 有什么区别？控制器运行在哪里？

1. Deployment、StatefulSet、DaemonSet、Job 等原生控制器，全部运行在 kube‑controller‑manager 进程内；硬件厂商自研 Operator 控制器独立部署，不在其中。

2. Deployment：跑业务应用，按副本数跑，节点随便选（Nginx、后端服务、AI 推理服务）

   DaemonSet：每个节点必须跑 1 个 Pod，节点级常驻（驱动、Device‑Plugin、监控、日志、网络插件）

2. Device Plugin 和 Operator 的区别？厂商为什么要开发 Operator？

1. Device Plugin ：K8s 标准节点级插件（DaemonSet 部署），只做硬件上报、分配、隔离，不能管理驱动更新、固件升级、故障自愈。
2. Operator ：厂商自研集群级控制器，基于 CRD 开发，管理驱动生命周期、灰度升级、硬件故障自愈、高级调度、监控告警，还自动部署、管理 Device Plugin。
3. 原因：K8s 原生不识别 NPU/GPU/IPU；驱动、固件、硬件拓扑是厂商私有逻辑，必须通过 Operator 实现全生命周期自动化管理。

3. K8s 如何查看日志？硬件场景要排查哪些日志？

1. 基础查看：
   • 实时日志：kubectl logs -f pod名 -n ns
   • 崩溃重启日志：kubectl logs -p pod名
   • 进入容器排查：kubectl exec -it pod名 -- sh
2. 硬件场景重点排查：
   • Device Plugin 插件日志；
   • kubelet 节点日志（journalctl -u kubelet -f）；
   • Operator 控制器日志，排查硬件调度、驱动升级问题