kubernetesK8s学习笔记第十二期核心知识点自测与详解本自测解析针对 Kubernetes 系列第十二期集群健康与安全——探针 认证授权的核心内容。共 10 题每题包含题目回顾、考查知识点、详细解答与分析帮助读者巩固 Kubernetes 应用健康检查与访问安全控制的核心技能。文章索引KubernetesK8s学习笔记第十二期集群健康与安全——探针 认证授权更多自我检测系列欢迎浏览每日知识点小问答我的主页AOwhisky这里有更多运维系统性知识整理和其他有趣内容欢迎与我一起探讨学习~题目一三种探针livenessProbe / readinessProbe / startupProbe的区别题目Kubernetes 中的livenessProbe、readinessProbe和startupProbe三种探针分别有什么作用各自失败后的行为是什么它们之间的执行顺序是怎样的考查知识点三种探针类型 —— 第十二期 §1.2探针执行顺序详细解答三种探针的作用与失败行为探针类型作用失败后的行为livenessProbe存活探针检测容器是否正在运行重启容器Pod 重新创建readinessProbe就绪探针检测容器是否准备好接收流量从 Service Endpoints 中移除 Pod IP不接收流量startupProbe启动探针检测容器是否已完成初始化失败则重启成功后才启动其他探针执行顺序Pod 启动 ↓ startupProbe如果配置—— 成功 → 启动 livenessProbe 和 readinessProbe ↓ readinessProbe持续检测—— 失败 → 从 Service 摘除流量 ↓ livenessProbe持续检测—— 失败 → 重启 Pod为什么需要 startupProbe一些应用如 Java 应用启动时间较长可能需要 30 秒以上如果直接用 livenessProbe 检测启动期间可能因为超时被反复重启startupProbe 给应用一个“宽限期”在启动完成之前livenessProbe 和 readinessProbe 不会执行题目二四种探测方法的对比与适用场景题目Kubernetes 探针支持哪四种探测方法请分别说明其原理和适用场景。对于只检测端口是否打开的服务如 MySQL应该使用哪种方法考查知识点探测方法 —— 第十二期 §1.3各方法适用场景详细解答四种探测方法方法原理成功条件适用场景httpGet对容器 IP 的指定端口和路径执行 HTTP GET 请求响应状态码 200-399Web 应用、API 服务exec在容器内执行指定命令命令退出码为 0检测文件存在、执行自定义脚本tcpSocket对容器 IP 的指定端口执行 TCP 连接检查端口可连接数据库、Redis、TCP 服务grpc执行 gRPC 健康检查RPC 调用响应状态为 SERVINGgRPC 服务YAML 示例# httpGet 方式livenessProbe:httpGet:path:/healthport:8080initialDelaySeconds:5# exec 方式livenessProbe:exec:command:-cat-/tmp/healthy# tcpSocket 方式适用于 MySQLlivenessProbe:tcpSocket:port:3306MySQL 服务应使用 tcpSocketMySQL 使用 TCP 协议不提供 HTTP 健康检查端点tcpSocket 探测可以检测 MySQL 端口是否可连接如果端口无法连接说明 MySQL 服务可能已停止或异常题目三livenessProbe 实验——检测主页文件触发重启题目在 httpd 容器中配置 livenessProbe 检测/index.html文件是否存在。如果该文件被删除Pod 会发生什么请写出关键的 YAML 配置和验证命令。考查知识点livenessProbe 实验 —— 第十二期 §1.6httpGet 探测详细解答YAML 配置apiVersion:apps/v1kind:Deploymentmetadata:name:webspec:replicas:1selector:matchLabels:app:webtemplate:metadata:labels:app:webspec:containers:-image:httpdname:httpdlivenessProbe:httpGet:path:/index.htmlport:80initialDelaySeconds:5periodSeconds:5failureThreshold:3timeoutSeconds:10验证命令# 查看 Pod 初始状态kubectl get pod NAME READY STATUS RESTARTS AGE web-85c6ff748f-qwszz1/1 Running01m# 删除主页文件模拟应用故障kubectlexecweb-85c6ff748f-qwszz --rm-fhtdocs/index.html# 观察 Pod——RESTARTS 变为 1Pod 被重启kubectl get pod NAME READY STATUS RESTARTS AGE web-85c6ff748f-qwszz1/1 Running13m# 访问恢复正常主页文件在重启后恢复kubectlexecweb-85c6ff748f-qwszz --lshtdocs/ index.html关键理解livenessProbe 失败 →Pod 重启尝试自我修复重启后容器恢复到初始状态主页文件重新生成题目四readinessProbe 实验——从 Service Endpoints 移除题目readinessProbe 与 livenessProbe 的关键区别是什么当 readinessProbe 失败时Pod 会被重启吗请说明 Service 的 Endpoints 会如何变化。考查知识点readinessProbe 实验 —— 第十二期 §1.7与 livenessProbe 的区别详细解答关键区别探针失败行为是否重启livenessProbe重启 Pod✅ 是readinessProbe从 Service 移除❌ 否Pod 继续运行YAML 配置readinessProbe:httpGet:path:/index.htmlport:80initialDelaySeconds:5periodSeconds:5验证命令# 创建 Deployment 和 Servicekubectl apply-fdeploy-readiness.yaml kubectl expose deployment web--port80--target-port80# 查看 Endpoints3 个 Pod IPkubectl get endpoints web NAME ENDPOINTS AGE web10.224.73.15:80,10.224.73.34:80,10.224.73.35:80 1m# 删除一个 Pod 的主页文件readinessProbe 会失败kubectlexecweb-9479dc55c-6bpg7 --rm-fhtdocs/index.html# 再次查看 Endpoints——该 Pod 被移出kubectl get endpoints web NAME ENDPOINTS AGE web10.224.73.15:80,10.224.73.34:80 2m# 查看 Pod 状态——READY 变为 0/1但 RESTARTS 没有增加kubectl get pod NAME READY STATUS RESTARTS AGE web-9479dc55c-6bpg70/1 Running08m关键理解readinessProbe 失败 → Pod 从 Service Endpoints移除→ 不再接收流量Pod不会被重启因为应用本身仍在运行只是未就绪两者配合使用readinessProbe 摘除流量livenessProbe 尝试恢复题目五startupProbe 的用途与配置题目什么情况下需要配置 startupProbe请写出一个针对慢启动 Java 应用的 startupProbe 配置并说明其工作原理。考查知识点startupProbe —— 第十二期 §1.8慢启动应用场景详细解答需要 startupProbe 的场景应用启动时间较长如 Java Spring Boot 应用、大型微服务启动期间需要加载大量数据或建立连接如果直接用 livenessProbe启动期间可能因超时被反复重启YAML 配置apiVersion:v1kind:Podmetadata:name:slow-start-appspec:containers:-name:appimage:myapp:lateststartupProbe:httpGet:path:/healthport:8080failureThreshold:30# 最多允许失败 30 次periodSeconds:10# 每 10 秒探测一次# 总宽限期 30 × 10 300 秒5 分钟livenessProbe:httpGet:path:/healthport:8080initialDelaySeconds:0# startupProbe 成功后立即开始periodSeconds:10工作原理Pod 启动后只有 startupProbe 在执行startupProbe 每 10 秒探测一次/health路径如果 30 次探测都失败Pod 被重启一旦 startupProbe 成功livenessProbe 和 readinessProbe 才开始工作总宽限期 failureThreshold × periodSeconds 300 秒5 分钟最佳实践启动慢的应用务必配置 startupProbe避免启动期间被 livenessProbe 误杀。题目六Kubernetes 中的两类用户题目Kubernetes 中的普通用户User和服务账户ServiceAccount有什么区别为什么 Kubernetes 本身不存储普通用户信息考查知识点两类用户 —— 第十二期 §2.1、§4.2User vs ServiceAccount详细解答核心区别对比项普通用户User服务账户ServiceAccount使用主体人管理员、开发者Pod 中的进程作用范围集群范围命名空间范围管理方式外部认证系统证书、OIDCKubernetes API典型场景kubectl操作集群Pod 通过 API 管理集群API 对象❌ 不存在对应的 API 对象✅ 存在ServiceAccount对象为什么 Kubernetes 不存储普通用户信息Kubernetes 遵循UNIX 设计哲学Do One Thing and Do It WellKubernetes只专注于应用编排不负责用户管理用户管理通过接口集成外部系统LDAP、AD、Keycloak 等优点用户账户信息与集群松耦合便于集成企业已有身份认证系统身份认证通过X509 证书等认证插件完成证书中的CN字段即为用户名题目七创建用户X509 证书方式的完整流程题目请写出使用 X509 证书方式创建 Kubernetes 用户的完整流程从客户端生成私钥到验证权限。kubectl config set-credentials命令的作用是什么考查知识点认证管理 —— 第十二期 §2.2用户创建流程详细解答完整流程步骤 1客户端生成私钥和证书签名请求CSRrootclient:~# openssl genrsa -out whisky.key 2048rootclient:~# openssl req -new -key whisky.key -out whisky.csr -subj /CNwhisky/Okubernetes# CN: 用户名whiskyO: 用户组kubernetes# 将 CSR 发送给集群管理员rootclient:~# scp whisky.csr rootmaster30:步骤 2管理员签发证书rootmaster30:~# openssl x509 -req -in whisky.csr \-CA/etc/kubernetes/pki/ca.crt\-CAkey/etc/kubernetes/pki/ca.key\-CAcreateserial-outwhisky.crt-days1095步骤 3创建 kubeconfig# 设置集群信息kubectl config set-cluster kubernetes\--kubeconfigconfig\--certificate-authorityca.crt\--serverhttps://10.1.8.30:6443\--embed-certs# 设置用户凭据此命令的作用kubectl config set-credentials whisky\--kubeconfigconfig\--client-keywhisky.key\--client-certificatewhisky.crt\--embed-certs# 设置上下文kubectl config set-context whisky\--kubeconfigconfig\--namespacedefault\--clusterkubernetes\--userwhiskykubectl config set-credentials的作用在 kubeconfig 文件中添加或更新用户凭据将客户端私钥--client-key和证书--client-certificate关联到用户--embed-certs将证书内容嵌入配置文件而不是只保存文件路径步骤 4授权并验证rootmaster30:~# kubectl create clusterrolebinding whisky-admin \--clusterrolecluster-admin--userwhisky rootclient:~# kubectl get nodes --kubeconfigconfig题目八RBAC 四要素Role / ClusterRole / RoleBinding / ClusterRoleBinding题目Kubernetes RBAC 的四个核心 API 对象是什么请分别说明其作用范围。Role和ClusterRole的主要区别是什么什么情况下应该使用ClusterRoleBinding而不是RoleBinding考查知识点RBAC 核心概念 —— 第十二期 §3.2四要素对比详细解答RBAC 四要素对象作用范围Role定义一组权限规则Namespace 级别ClusterRole定义一组权限规则集群级别RoleBinding将 Role 绑定给用户/组/SANamespace 级别ClusterRoleBinding将 ClusterRole 绑定给用户/组/SA集群级别Role vs ClusterRole 的区别对比项RoleClusterRole作用范围单个 Namespace所有 Namespace 集群级资源管理资源类型Namespace 级资源Namespace 级 集群级Node、PV 等使用 ClusterRoleBinding 的场景需要授予用户集群级权限如查看 Node、PV需要授予用户跨所有 Namespace的权限使用预置的cluster-admin、admin、view等 ClusterRole服务账户需要管理整个集群示例# ClusterRoleBinding——授予集群级权限kubectl create clusterrolebinding whisky-admin\--clusterrolecluster-admin--userwhisky# RoleBinding——授予 Namespace 级权限kubectl create rolebinding default-pod-whisky\-ndefault--rolepod-role--userwhisky题目九apiGroups 对 RBAC 权限的影响题目在 RBAC 的rules中apiGroups字段的作用是什么为什么以下 Role 配置无法操作 Deploymentrules:-apiGroups:[]resources:[deployments]verbs:[get,list,watch]请写出正确的配置。考查知识点apiGroups —— 第十二期 §3.4常见 apiGroups 对照详细解答apiGroups的作用指定资源所属的 API 组不同资源类型属于不同的 API 组需要正确填写才能生效apiGroups默认为空字符串错误原因Deployment 的 apiVersion 是apps/v1apiGroups 是apps配置中apiGroups: []只匹配 Pod、Service 等 v1 资源无法匹配 Deployment所以权限不生效常见 apiGroups 对照表资源类型apiVersionapiGroupsPod、Service、PVCv1Deployment、DaemonSetapps/v1appsJobbatch/v1batchNetworkPolicynetworking.k8s.io/v1networking.k8s.ioRole、RoleBindingrbac.authorization.k8s.io/v1rbac.authorization.k8s.io正确配置rules:-apiGroups:[apps]# 修改为 appsresources:[deployments]verbs:[get,list,watch]查询资源的 apiGroupskubectl explain deployment|grepVERSION VERSION: apps/v1# apiGroups 即为 apps题目十ServiceAccount Token 管理题目在 Kubernetes 1.24 版本中ServiceAccount Token 的默认管理机制是什么kubectl create token和手动创建 Secret 两种方式有什么区别为什么推荐使用临时 Token考查知识点ServiceAccount Token 机制 —— 第十二期 §4.5临时 Token vs 长期 Token详细解答默认管理机制投射卷方式Kubernetes 1.24 使用投射卷Projected Volume为 Pod 提供 TokenToken 通过 TokenRequest API 获取具有绑定的生命周期默认有效期 1 小时到期后自动轮转当 Pod 被删除时Token 自动失效两种 Token 创建方式对比方式命令有效期使用场景临时 Token推荐kubectl create token sa1有限默认 1 小时日常使用、短期访问长期 Token手动创建 Secret创建带特殊注解的 Secret无限手动吊销外部系统集成、CI/CD创建临时 Tokenkubectl create token sa1 eyJhbGciOiJSUzI1NiIsImt...创建长期 Token手动创建 SecretapiVersion:v1kind:Secretmetadata:name:sa1-secretannotations:kubernetes.io/service-account.name:sa1type:kubernetes.io/service-account-tokenkubectl apply-fsa1-token.yaml推荐使用临时 Token 的原因长期 Token 存在安全风险泄漏后永久有效临时 Token 有有效期限制降低泄漏影响范围临时 Token 绑定到特定 PodPod 删除后自动失效符合安全最佳实践最小权限 短期凭证附知识点对应总表题号主要考查知识点对应笔记章节1第十二期 §1.2 三种探针类型2第十二期 §1.3 四种探测方法3第十二期 §1.6 livenessProbe 实验4第十二期 §1.7 readinessProbe 实验5第十二期 §1.8 startupProbe 用途与配置6第十二期 §2.1 两类用户§4.2 User vs ServiceAccount7第十二期 §2.2 创建用户完整流程8第十二期 §3.2 RBAC 四要素9第十二期 §3.4 apiGroups 详解10第十二期 §4.5 ServiceAccount Token 管理学习建议对于答错的题目请回看第十二期对应章节并动手在集群环境中验证。健康检查和认证授权是 Kubernetes 生产环境运维的核心技能建议通过实际操作加深理解。— Compiled and Authored by Whisky — July 5 th, 2026