Kubernetes ReplicaSet 入门实战：从声明式创建、自愈验证到安全删除（devops-exercises 复现指南）

文档教程DevOps运维【免费下载链接】devops-exercisesLinux, Jenkins, AWS, SRE, Prometheus, Docker, Python, Ansible, Git, Kubernetes, Terraform, OpenStack, SQL, NoSQL, Azure, GCP, DNS, Elastic, Network, Virtualization. DevOps Interview Questions项目地址https://gitcode.com/GitHub_Trending/de/devops-exercises点击查看免费下载ReplicaSet 是 Kubernetes 中保证指定数量的 Pod 副本始终运行的核心控制器也是面试与 CKA 备考中绕不开的基础概念。本文以 devops-exercises 仓库中 ReplicaSet 101 练习及其官方解答 为主线完整复现创建 ReplicaSet → 验证副本 → 删除单个 Pod 观察自愈 → 删除 ReplicaSet的全流程并结合仓库问答区Kubernetes 官方式 QA逐字段拆解 YAML、说明底层事件链与级联删除行为。读完后你将能独立编写一个可运行的 ReplicaSet 清单并用 kubectl 验证其自愈特性为后续理解 Deployment、滚动更新与 CKA 实操打下基础。一、为什么需要 ReplicaSet稳定副本的守护者在 Kubernetes 中Pod 是最小的调度单元但它本身不具备自愈能力——如果某个 Pod 意外崩溃或被误删系统不会自动把它找回来。正如仓库 Kubernetes README 中明确指出的If a Pod dies, Kubernetes will not bring it back. This is why its more useful for example to define ReplicaSets that will make sure that a given number of Pods will always run, even after a certain Pod dies.ReplicaSet 正是为了解决这个问题而生的控制器。仓库问答区对其目的给出了权威定义A ReplicaSets purpose is to maintain a stable set of replica Pods running at any given time. As such, it is often used to guarantee the availability of a specified number of identical Pods.用更直白的话来说ReplicaSet 会持续比对期望副本数与当前实际运行的匹配 Pod 数——多了就删除多余的少了就补建缺失的从而保证集群中始终存在期望数量的、满足选择条件的 Pod。这也是 Kubernetes 自愈Self-Healing能力在副本层面的具体体现。二、完整清单解析创建一个 2 副本的 ReplicaSet练习第 1 步要求创建一个包含 2 个副本的 ReplicaSet应用类型不限。仓库官方解答给出的完整清单如下这是全篇最核心、可直接复制运行的 YAMLapiVersion: apps/v1 kind: ReplicaSet metadata: name: web labels: app: somewebapp type: web spec: replicas: 2 selector: matchLabels: type: web template: metadata: labels: type: web spec: containers: - name: httpd image: registry.redhat.io/rhscl/httpd-24-rhel7逐字段拆解如下字段取值含义与要点apiVersionapps/v1ReplicaSet 属于 apps API 组当前稳定版本为apps/v1。写错版本会导致 API 拒绝。kindReplicaSet对象类型。仓库问答区特意给出了一个陷阱题把kind写成ReplicaCet会报错见 README 修复题。metadata.nameweb对象名称命名空间内唯一。metadata.labelsapp: somewebapp、type: webReplicaSet 自身的标签用于标识和组织该对象本身不参与 Pod 选择。spec.replicas2期望副本数。仓库问答区明确若省略该字段默认值为 1见 README。spec.selector.matchLabelstype: web选择器决定 ReplicaSet认领哪些 Pod。它必须能匹配template中定义的 Pod 标签否则清单无法通过校验。spec.templatePod 模板spec下唯一必填字段见 README它定义了 ReplicaSet 在需要补建 Pod 时照着什么样创建。模板内部的spec.containers与普通 Pod 的写法完全一致。值得强调的两个关键点选择器必须覆盖模板标签。本例中selector.matchLabels.type: web与template.metadata.labels.type: web严格对应。仓库问答区给出了反例当selector匹配tier: cache而模板标签却是tier: cachy时清单是错误的见 README 修复题。选择器只认标签不认来源。ReplicaSet 会接管一切带有匹配标签的 Pod——无论它是由本 ReplicaSet 创建还是由其他对象预先创建见 README。这正是标签-选择器模型的核心威力也是后续第 3 个练习移除标签实验的理论基础。三、创建与验证kubectl 命令速成3.1 应用清单仓库解答使用 heredoc 写入文件后统一应用cat rs.yaml EOL apiVersion: apps/v1 kind: ReplicaSet # ...完整清单见上文 EOL kubectl apply -f rs.yaml采用kubectl apply -f声明式应用是 Kubernetes 的最佳实践——它幂等、可追踪、便于版本化。当然如果你已经把清单存成了rs.yaml直接kubectl apply -f rs.yaml即可。3.2 验证 ReplicaSet 已创建且副本数为 2kubectl get rs # OR a more specific way: kubectl get -f rs.yamlkubectl get rs会输出类似下面的表格NAME DESIRED CURRENT READY AGE web 2 2 2 10s各列含义参考 README 对输出示例的讲解DESIRED清单中声明的期望副本数2CURRENT当前实际运行、匹配选择器的 Pod 数READY其中就绪容器正常启动、探针通过的 Pod 数AGEReplicaSet 存在时长。注意READY为 0 并不代表失败。容器镜像拉取需要时间READY会随 Pod 就绪逐渐增长若长时间为 0可用kubectl describe po POD_NAME或kubectl logs POD_NAME排查README 原文。kubectl get -f rs.yaml是另一种更精确的查看方式——它直接以清单文件为查询对象输出与该文件对应资源的实时状态适合在只有清单、记不清对象名时使用。四、自愈验证删除一个 Pod数量会怎样练习第 3 步删除 ReplicaSet 创建出的其中一个 Podkubectl delete po POD_NAME练习第 4 步的官方答案原文The same number of Pods. Since we defined 2 replicas, the ReplicaSet will make sure to create another Pod that will replace the one youve deleted.Pod 总数保持不变。这正是 ReplicaSet 的核心行为ReplicaSet 控制器持续监听集群中匹配其选择器的 Pod 数量一旦发现少于期望值本例为 2立即用template模板创建新 Pod 补齐差额。仓库问答区同样印证了这一结论见 READMEThe ReplicaSet will create a new Pod in order to reach the desired number of replicas.反之如果匹配的 Pod 数量超过期望值比如你手动又创建了一个带type: web标签的 PodReplicaSet 会删除多余的 Pod 以收敛到期望状态README。由此可以总结出 ReplicaSet 的闭环逻辑期望副本数(DESIRED) ──对比── 当前匹配 Pod 数(CURRENT) 少 → 用 template 新建 Pod 多 → 终止多余的 Pod 相等 → 什么都不做需要补充的一点删除的 Pod 是全新创建的新的名字、新的 IP并非旧 Pod 的复活。因此 ReplicaSet 适合无状态应用有状态应用应改用 StatefulSet仓库 README 有专项章节。五、删除 ReplicaSet连带清理与孤儿模式练习第 5、6 步删除 ReplicaSet 并验证kubectl delete -f rs.yaml kubectl get rs # OR a more specific way: kubectl get -f rs.yaml执行后kubectl get rs不再输出web即删除成功。这里要强调一个容易被忽略的事实README 原文Deleting a ReplicaSet will delete the Pods it created — True (and not only the Pods but anything else it created).也就是说默认情况下删除 ReplicaSet 是级联cascade删除它创建的 Pod 会一并被清理。如果你希望删控制器、留 Pod仓库的 ReplicaSet 102 练习与解答 给出了明确写法kubectl delete -f rs.yaml --cascadeorphan kubectl get rs # 已无 rs输出为空 kubectl get po # 但 Pod 仍在运行这便是孤儿orphan删除模式。更值得注意的是该练习的后续步骤用同一份清单重新kubectl apply -f rs.yaml后ReplicaSet 会直接接管刚才幸存的 Pod而不是重复创建新 Pod——因为选择器匹配上了Pod 数量也已满足期望值可用kubectl describe rs web的 Events 区确认没有新建事件。这再次验证了ReplicaSet 认标签不认来源的设计哲学。六、标签实验移除标签会让 ReplicaSet 补建 Pod 吗为了更直观地理解选择器的工作方式仓库配套的 ReplicaSet 103 练习 设计了一个拆标签实验解答见 replicaset_03_solution.md先按上文清单创建 ReplicaSet选择器为typeweb用kubectl get po running_pods.txt记录当前 Pod 列表移除其中一个 Pod 的匹配标签kubectl label pod POD_NAME type-再次列出 Pod数量变多了3 个。原因官方解答原文一旦移除标签该 Pod 不再匹配选择器从而脱离 ReplicaSet 的管理ReplicaSet 发现自己管辖的 Pod少于期望值 2立即创建了一个新 Pod 来补齐。于是集群中出现 3 个 Pod2 个受控 1 个自由的旧 Pod。仓库问答区也有同样的结论README。这个实验深刻揭示了 ReplicaSet 与 Pod 之间的耦合完全建立在标签之上而非血缘关系。同理如果给一个本来不匹配的 Pod 贴上typeweb标签它会被 ReplicaSet吸收甚至可能因超出期望数而被终止。七、底层原理创建 ReplicaSet 时发生了什么仓库问答区给出了创建 ReplicaSet 的完整事件序列README理解它有助于回答kubectl apply 之后系统做了什么这类面试题客户端kubectl向 API Server 发送创建 ReplicaSet 的请求ReplicaSet 控制器监听到这一新事件控制器依据清单中的replicas数量创建对应数量的 Pod 定义Scheduler 发现未调度的 Pod为每个 Pod 选定合适的节点并回写 API Server工作节点上的 Kubelet 持续监听 API Server发现 Pod 被分配给自己所在节点Kubelet 请求容器运行时如 containerd/Docker创建容器Kubelet 向 API Server 上报 Pod 已创建完成。注意步骤 3 是 ReplicaSet 控制器Controller Manager 中的 replicaset-controller完成的而非用户直接创建 Pod——这也是Pod 通常不直接创建的原因README 相关论述。在日常排障中如果你想确认ReplicaSet 到底是找到了现成 Pod 还是新建了 Pod可运行kubectl describe rs web重点查看输出末尾的Events区README其中会记录created pod xxx或adopted/claimed pod xxx等事件一目了然。八、高频面试要点速查结合本文练习与仓库问答区以下结论可直接用于面试回答均见 Kubernetes README 的 ReplicaSets 章节目的在任意时刻维持稳定数量的副本 Pod保证应用可用性。spec.template必填ReplicaSet 靠模板补建 Pod其余字段如replicas可省略replicas默认值为 1。自愈方向是双向的少于期望数→补建多于期望数→终止多余 Pod。删除单个受控 PodReplicaSet 立即补建Pod 总数不变。删除 ReplicaSet默认级联删除其创建的 Pod用--cascadeorphan可保留 Pod。移除匹配标签Pod 脱离管理ReplicaSet 会补建新 Pod。选择器不要求 Pod 必须由自己创建可接管任何匹配标签的现成 Pod。输出列解读DESIRED期望/CURRENT当前匹配数/READY就绪数READY长期为 0 需结合describe/logs排查。与 Deployment 的关系Deployment 内部管理 ReplicaSet为应用提供滚动更新与回滚能力日常生产多直接使用 Deployment 而非裸 ReplicaSet。与 DaemonSet 的区别ReplicaSet 保证指定数量的副本在集群中运行DaemonSet 保证每个节点都运行一份 Pod见 README。九、扩展练习与后续学习路径本练习的题目原文见 replicaset_01.md官方解答见 solutions/replicaset_01_solution.md。继续挑战删除但保留 Pod / 接管旧 PodReplicaSet 102 练习 及其解答。深入标签-选择器行为ReplicaSet 103 练习 及其解答以及 Labels and Selectors 101 练习。按部就班备考 CKA可参考仓库的 CKA.md 专项页完整的 Kubernetes 问答库位于 topics/kubernetes/README.md。练习建议把本文清单保存为rs.yaml在测试集群如 minikube上依次执行创建 → 验证 → 删 Pod → 观察自愈 → 删除再动手完成孤儿删除与拆标签两个进阶实验。亲手验证一次比背诵十遍原理都有效。赞分享文档教程DevOps运维【免费下载链接】devops-exercisesLinux, Jenkins, AWS, SRE, Prometheus, Docker, Python, Ansible, Git, Kubernetes, Terraform, OpenStack, SQL, NoSQL, Azure, GCP, DNS, Elastic, Network, Virtualization. DevOps Interview Questions项目地址https://gitcode.com/GitHub_Trending/de/devops-exercises点击查看免费下载相关推荐devops-exercises 实战指南Kubernetes ReplicaSet 101 创建、自愈与清理全流程devops exercises 实战指南Kubernetes ReplicaSet 101 创建、自愈与清理全流程 导读 本指南以 devops exerc文档教程DevOps运维devops-exercises 实战Kubernetes ReplicaSet 运维全解——孤儿 Pod 保留、级联删除与无缝接管ReplicaSet 102devops exercises 实战Kubernetes ReplicaSet 运维全解——孤儿 Pod 保留、级联删除与无缝接管ReplicaSet 1文档教程DevOps运维devops-exercises 实战Kubernetes ReplicaSet 标签与选择器机制全解析ReplicaSet 103 实验devops exercises 实战Kubernetes ReplicaSet 标签与选择器机制全解析ReplicaSet 103 实验 本篇技术指南以文档教程DevOps运维创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考