kubelet 只负责 "我要启动一个容器"，至于底层用什么运行时、怎么启动，kubelet 完全不关心，只要你符合 CRI 标准，就能对接，这也是 K8s 能支持这么多容器运行时的原因。这也是容器为什么这么轻量的原因：容器不是虚拟化，它就是一个被内核隔离、限制的普通进程，所有能力都是内核早就有的，Docker/CRI-O 只是把这些能力打包成了好用的工具而已。runc 启动完容器内的进程之后，容

容器镜像是一个分层存储的归档文件（通常为 Tar 格式），包含运行容器所需的所有静态文件和元数据。其核心设计遵循开放容器倡议（OCI）标准，主要包含以下两部分容器镜像不是 Docker 发明的，而是有全球统一的行业标准（OCI 标准），Docker 只是这个标准的一个实现。核心对应：Docker 镜像完全遵循 OCI 标准OCI 标准定义了容器镜像的本质：分层存储的归档文件，由layer.tar（

光有隔离（Namespace）还不够，容器还要有独立的文件视图和网络设备，这才是完整的 “手工容器”。你会发现，虽然用了--pid隔离，但如果不挂载新的 proc，执行ps -ef还是能看到宿主机进程。原理/proc目录是内核给进程看的资源列表。操作：效果：重新执行ps -ef你只能看到自己的 bash 进程了！PID 命名空间彻底生效。“进程本质上是 /proc 挂载点中的文件描述符”。容器需要

CD 工具（比如 Argo CD、Jenkins）从 Harbor 拉取更新 K8s 的 Deployment YAML，把镜像版本改成K8s 收到更新请求后，执行滚动更新拉取新镜像创建新 Pod，启动容器销毁旧 Pod确保最终运行的 Pod 数量符合期望这里 K8s 只做「运行容器」的事，完全不关心镜像怎么来的。K8s 是「容器的运行平台」，不是「代码的构建平台」。它只负责运行已经打包好的容器，

完整标签键（冒号前）值（冒号后）用途versionv1.1.0标记应用版本releasestable标记版本状态（正式版 / 测试版）env: devenvdev标记运行环境（开发 / 生产）app: nginxappnginx标记应用名称标签是key: value的键值对，冒号前是「分类的维度（键）」，冒号后是「分类的具体值（值）」；键分「可选前缀 + 必须名称」，值规则宽松，核心作用是给资源打

Pod 一直卡 Init？别慌，查看 Init 容器的日志，看看初始化任务哪里出错了，改了就好。进入容器改了内容，重启就没了？因为你改的是容器的临时可写层，镜像本身没变，容器重建就会丢，要永久改的话，要么改镜像，要么用持久化存储。Pod 删了又回来？大概率是静态 Pod，别用 kubectl 删了，去节点上把配置文件删掉才行。别啥容器都往一个 Pod 里塞！只有紧密耦合的才放一起，独立的程序分开做

有 NodePort、LoadBalancer 了，为什么还要搞个 Ingress？直到开始部署多个服务，才明白：用 NodePort 的话，每个服务要开一个不同的端口，我有 10 个服务，就要记 10 个端口，太麻烦了用 LoadBalancer 的话，每个服务要一个独立的公网 IP，10 个服务就要 10 个 IP，成本太高了而 Ingress，就是解决这个问题的：它可以让你用一个公网 IP，

学完这六个控制器，我最大的感受就是，K8s 的设计真的特别清晰，不同的场景用不同的控制器，把不同的能力拆分开：无状态应用用 Deployment有状态应用用 StatefulSet节点级组件用 DaemonSet一次性任务用 Job定时任务用 CronJob搞懂这些，K8s 的应用部署就基本通了，希望我的踩坑总结能帮到同样在学习的朋友～

很多人搞不懂的配置，其实也非常好理解：它和你用 curl 的时候加的参数，是完全一模一样的东西。那 kubelet 发出去的 HTTP 请求，就会自动带上这个请求头，就和你在终端里执行下面这条 curl 命令的效果，100% 完全一样curl -H "Custom-Header: Awesome" http://容器IP:80/health你可能会问，好好的为什么要加这个东西？因为有些服务的健康检

默认的容器里，存储是跟容器绑定的：容器跑着的时候，你能往里面写文件，但是一旦容器崩了、删了，这些文件就全没了 —— 你要是用容器跑个数据库，重启之后数据全没了还有个常见的需求：同一个 Pod 里的两个容器，要共享文件。比如一个容器跑应用，生成日志，另一个容器跑日志收集工具，要把日志传到远程存储，这俩容器得能读到同一份日志文件才行。。容器删了，只要卷还在，数据就还在；同时，卷能被多个容器挂载，实现文