来源快照｜虚拟化与云原生

本页是原图的只读导入快照，不是已核验文档。原有历史命令、版本标记与疑点保留；已识别口令替换为占位符。图片只保留引用。

虚拟化与云原生 ^xm-8139c241f6594e87ae002186b8

◆ 2026 深度扩展｜虚拟化与云原生
- OCI 镜像、容器运行时与隔离 ^xm-327dbb6eccce4ddea587ac4fc4
  - 🎯 目标 ^xm-e43f99a08a86425f8b706a9abc
    - 从镜像到进程理解容器生命周期与安全边界。
  - 🧠 知识拆解 ^xm-aecc449a73184ea185d76ad061
    - OCI image/runtime spec
    - layers/content store/snapshotter
    - namespace/cgroup/capabilities/seccomp
    - containerd/CRI/runc
    - rootless
    - image provenance
  - ⌨️ 命令 / 配置 / 关键对象 ^xm-c6067296be784153aa3a72bbde
    - docker/podman inspect
    - ctr/crictl
    - nsenter
    - unshare
    - capsh
    - skopeo
  - 🔥 高频故障与风险 ^xm-3aea05068fde40d39f44244b76
    - image pull
    - cgroup limit
    - permission/capability
    - overlay disk
    - runtime/shim 卡死
  - 🔎 排障路径 ^xm-4185c2957069493584bfa0ba77
    - 镜像→runtime→shim→process→cgroup
    - 看 CRI events/logs
    - 核对 namespace/capability
  - 🧪 实战练习 ^xm-7730a286e95b41b3a103aba7dc
    - 手工 namespace/cgroup 容器
    - crictl 排查运行时
  - ✅ 验收标准 ^xm-e74d060f86984c5dba6c9b7228
    - 理解容器不是虚拟机
    - 镜像最小且可追溯
    - 运行时权限最小
  - 🔗 对应优秀开源项目 ^xm-edcdb9314c034851b26cf4b237
    - moby/moby
      
      备注（源图文本，未作运行验证）：
      定位：容器引擎核心实现源码阅读：API→daemon→containerd→runc 实战：跟踪一次容器创建的调用链注意：源码大，围绕一条请求阅读整理日期：2026-07-09
      - 原链接（未复核）：https://github.com/moby/moby
    - containerd/containerd
      
      备注（源图文本，未作运行验证）：
      定位：行业级容器运行时源码阅读：CRI、snapshotter、content store、shim 实战：用 ctr/crictl 对比镜像与容器生命周期注意：生产 Kubernetes 排障优先使用 crictl 整理日期：2026-07-09
      - 原链接（未复核）：https://github.com/containerd/containerd
- Kubernetes 控制面与对象生命周期 ^xm-22263f8c87ef464f8a7ea1af77
  - 🎯 目标 ^xm-eb5722cadb5247b28be0e0de59
    - 跟踪声明如何通过控制循环变成实际状态。
  - 🧠 知识拆解 ^xm-cbcccf48bbbc47b69a4482df17
    - API object/version
    - etcd
    - apiserver admission
    - controller reconciliation
    - scheduler binding
    - kubelet/CRI
  - ⌨️ 命令 / 配置 / 关键对象 ^xm-261048a760284d27a922d74c22
    - kubectl get -o yaml/watch
    - events
    - audit logs
    - component metrics
    - etcdctl
  - 🔥 高频故障与风险 ^xm-07713d88e89c4e56b6e473a6a6
    - API unavailable
    - controller backlog
    - etcd latency/space
    - webhook 阻塞
    - 证书过期
  - 🔎 排障路径 ^xm-273ffe1b33894e599b4f8891dc
    - 请求→apiserver→etcd→controller/scheduler→kubelet
    - 检查 workqueue/latency
    - 审计和事件对齐
  - 🧪 实战练习 ^xm-a036d67d5d3a446d8212db00a1
    - 跟踪 Deployment 创建
    - 模拟 admission webhook 超时
  - ✅ 验收标准 ^xm-b32e50a842084a41a17a833d8a
    - 能画完整控制循环
    - 控制面 SLO 可观测
    - etcd 恢复演练
  - 🔗 对应优秀开源项目 ^xm-ecb6a1a200b14baf9b7d8f4bcc
    - kubernetes/kubernetes
      
      备注（源图文本，未作运行验证）：
      定位：容器编排核心源码阅读：kubectl→apiserver→controller/scheduler→kubelet 实战：跟踪 Deployment 创建与 Pod 调度注意：不要从仓库第一行顺序阅读整理日期：2026-07-09
      - 原链接（未复核）：https://github.com/kubernetes/kubernetes
    - etcd-io/etcd
      
      备注（源图文本，未作运行验证）：
      定位：Kubernetes 关键一致性存储源码阅读：Raft、WAL、snapshot、watch、compaction 实战：备份恢复与配额/碎片整理演练注意：恢复必须保持 revision 与集群身份一致整理日期：2026-07-09
      - 原链接（未复核）：https://github.com/etcd-io/etcd
- Pod、工作负载与生命周期 ^xm-5c025cdadc054e79ac8144e99b
  - 🎯 目标 ^xm-cc80aca240d6473eb563a2a67d
    - 正确选择 Deployment/StatefulSet/DaemonSet/Job 并排查 Pod 状态。
  - 🧠 知识拆解 ^xm-85eff6cd5a014c278e82f26373
    - Pod phase/condition
    - init/sidecar
    - probe/startup
    - termination grace
    - Deployment rollout
    - Stateful identity
    - Job retries
  - ⌨️ 命令 / 配置 / 关键对象 ^xm-13ef78fdcd4140a0a76ce6adae
    - kubectl describe/logs/exec/debug
    - rollout status/history/undo
    - get events
    - ephemeral containers
  - 🔥 高频故障与风险 ^xm-df7ce464a8604657a265e0b180
    - CrashLoopBackOff
    - ImagePullBackOff
    - probe loop
    - Terminating
    - Job 重试风暴
    - 滚动升级卡住
  - 🔎 排障路径 ^xm-1fd222f064f34d469f9b7f4c25
    - 状态/condition→events→logs→previous logs→runtime
    - 核对 probe 与启动时间
    - 检查 PDB/strategy
  - 🧪 实战练习 ^xm-3c0c8d6f3241468ea9096d7ace
    - 逐项制造典型 Pod 故障
    - 零中断滚动升级
  - ✅ 验收标准 ^xm-4d7bfc4d6f7b490b83c8a99949
    - 每类状态有排障清单
    - 优雅终止验证
    - 回滚经过演练
  - 🔗 对应优秀开源项目 ^xm-b280f0dd8b2e4e858244cdc5a7
    - robusta-dev/kubernetes-demos
      
      备注（源图文本，未作运行验证）：
      定位：真实 Kubernetes 故障练习集源码阅读：按故障 YAML、现象和修复学习实战：逐项演练 CrashLoop/OOM/Pending/ImagePull 注意：只在测试集群执行整理日期：2026-07-09
      - 原链接（未复核）：https://github.com/robusta-dev/kubernetes-demos
    - k9scli/k9s
      
      备注（源图文本，未作运行验证）：
      定位：Kubernetes 终端运维界面源码阅读：资源发现、watch、plugins、skins 实战：配置只读排障插件注意：便捷工具不能替代 RBAC 和审计整理日期：2026-07-09
      - 原链接（未复核）：https://github.com/k9scli/k9s
- 调度、资源与自动扩缩 ^xm-59ddf55574dc41ac91dbf44319
  - 🎯 目标 ^xm-e92aa7923bc04142aa825415b6
    - 用 requests/limits、优先级、拓扑和 autoscaling 管理资源。
  - 🧠 知识拆解 ^xm-9c46cc8244d74a3bb951c76c71
    - scheduler filter/score
    - requests/limits/QoS
    - taint/toleration
    - affinity/topology spread
    - priority/preemption
    - HPA/VPA/cluster autoscaler
  - ⌨️ 命令 / 配置 / 关键对象 ^xm-5c7bd035b3fd480a94f587fb45
    - kubectl describe pod/node
    - scheduler events/logs
    - metrics-server
    - top
    - resource quota/limit range
  - 🔥 高频故障与风险 ^xm-545e0a353b5c42adba12a888df
    - Pending/Unschedulable
    - CPU throttling
    - OOMKilled
    - 热点节点
    - HPA 抖动
    - 抢占
  - 🔎 排障路径 ^xm-10870a8a6af143beaf94e9d8ca
    - Pod request→node allocatable→约束→配额
    - 看 throttling/OOM/working set
    - 核对指标延迟
  - 🧪 实战练习 ^xm-0e4bac82f4774d5c8171bc61bd
    - Pending 原因矩阵
    - HPA + PDB + topology spread
  - ✅ 验收标准 ^xm-217f8424e015485fa8cf4cef99
    - requests 基于历史与 SLO
    - 扩缩容有稳定窗口
    - 关键服务有优先级和 PDB
  - 🔗 对应优秀开源项目 ^xm-56af602ad9b4457485e91a0b18
    - robusta-dev/krr
      
      备注（源图文本，未作运行验证）：
      定位：基于 Prometheus 的 K8s 资源建议源码阅读：历史指标→算法→recommendation 实战：对 requests/limits 做建议与回归注意：建议需结合峰值、突发和 SLO 审核整理日期：2026-07-09
      - 原链接（未复核）：https://github.com/robusta-dev/krr
- Kubernetes 网络、Ingress 与 Gateway ^xm-598c5086e237466eae2a8fcbc5
  - 🎯 目标 ^xm-8c92c20c4aff489fa5c31388ef
    - 掌握 Service/EndpointSlice/CNI/Ingress 的路径和故障。
  - 🧠 知识拆解 ^xm-ebdcafcb22554c27b551450a69
    - Pod network
    - Service/EndpointSlice
    - kube-proxy/eBPF
    - Ingress/Gateway API
    - NetworkPolicy
    - CoreDNS
  - ⌨️ 命令 / 配置 / 关键对象 ^xm-bdea412f654c4e57926860661e
    - kubectl get endpointslices
    - curl/dig in pod
    - ip/iptables/ipvs
    - cilium/hubble
    - ingress controller logs
  - 🔥 高频故障与风险 ^xm-a0a6ef0ed240452db2827babbc
    - Service 无 endpoint
    - DNS timeout
    - Ingress 404/502
    - NetworkPolicy
    - cross-node MTU
  - 🔎 排障路径 ^xm-a8e2251829f54b8e9a54c21fa5
    - DNS→Service→Endpoint→Pod
    - 逐跳请求与抓包
    - 核对 selector/port/targetPort
  - 🧪 实战练习 ^xm-c5c2bf1b55ff40dfb5c8a82368
    - Service/Ingress/Gateway 对比
    - 默认拒绝与可视化流量
  - ✅ 验收标准 ^xm-a28a78c58e9e4f2ea2f42f55e3
    - 包路径可解释
    - 策略有自动测试
    - 入口超时与重试受控
  - 🔗 对应优秀开源项目 ^xm-9750438ff8bc4aadbc3c7d2485
    - cilium/cilium
      
      备注（源图文本，未作运行验证）：
      定位：eBPF CNI、网络策略与可观测源码阅读：agent→endpoint→policy→BPF maps→Hubble 实战：实现 L3/L4/L7 策略并观测丢包注意：升级前检查内核与功能兼容矩阵整理日期：2026-07-09
      - 原链接（未复核）：https://github.com/cilium/cilium
    - istio/istio
      
      备注（源图文本，未作运行验证）：
      定位：Service Mesh 流量、安全与遥测源码阅读：control plane→xDS→Envoy data plane 实战：灰度、熔断、mTLS、故障注入注意：先证明业务收益再接受复杂度整理日期：2026-07-09
      - 原链接（未复核）：https://github.com/istio/istio
- Kubernetes 存储 ^xm-cb43f18c587d4c0d9d49abad67
  - 🎯 目标 ^xm-107266fb456249f296259ffce7
    - 管理动态供给、CSI、拓扑、快照和有状态应用。
  - 🧠 知识拆解 ^xm-dd82d523913e42d280467fbd52
    - PV/PVC/SC
    - CSI sidecars
    - binding/access mode
    - volume topology
    - snapshot
    - stateful workload
  - ⌨️ 命令 / 配置 / 关键对象 ^xm-1c7c11ccc2144d9bb1d2fe6044
    - kubectl describe pvc/pv
    - VolumeAttachment
    - CSI controller/node logs
    - backend health
  - 🔥 高频故障与风险 ^xm-ff7f2e0c0b734d309bc951a4cf
    - PVC Pending
    - attach/mount failed
    - zone mismatch
    - volume full
    - snapshot/restore failed
  - 🔎 排障路径 ^xm-4569b6c5e4bc4380bd1c1bd645
    - claim→class→provisioner→backend
    - attach→node plugin→mount
    - 检查容量/权限/拓扑
  - 🧪 实战练习 ^xm-49aa9e346d80442898710c704c
    - StatefulSet + dynamic PVC
    - 快照、扩容、节点故障
  - ✅ 验收标准 ^xm-4ba80b8ed3aa424fbb4094c7bd
    - 恢复可验证
    - 有容量告警
    - 应用一致性方案清楚
  - 🔗 对应优秀开源项目 ^xm-622232c155cf46489ea7ea7045
    - rook/rook
      
      备注（源图文本，未作运行验证）：
      定位：Kubernetes 云原生存储编排源码阅读：operator→CephCluster→CSI→pool/filesystem 实战：部署块/文件/对象存储并演练节点故障注意：测试环境不能代替容量和故障域设计整理日期：2026-07-09
      - 原链接（未复核）：https://github.com/rook/rook
    - velero/velero
      
      备注（源图文本，未作运行验证）：
      定位：Kubernetes 资源与持久卷备份恢复源码阅读：backup→object store→restore→plugins 实战：命名空间级备份、集群迁移与恢复演练注意：备份成功不等于应用一致性恢复成功整理日期：2026-07-09
      - 原链接（未复核）：https://github.com/velero/velero
- RBAC、Pod Security 与 Secret ^xm-53f267bffd4d45ad897b7f3073
  - 🎯 目标 ^xm-08150f1b115a467ba9598f0741
    - 以最小权限保护 Kubernetes API、工作负载和密钥。
  - 🧠 知识拆解 ^xm-075319b2bdc8440fabeca9062d
    - subject/role/binding
    - service account/token
    - Pod Security Standards
    - admission policy
    - secret encryption
    - workload identity
  - ⌨️ 命令 / 配置 / 关键对象 ^xm-d4d168e68bd7454aac834d67d8
    - kubectl auth can-i
    - SelfSubjectRulesReview
    - audit logs
    - kyverno/gatekeeper reports
    - certificates
  - 🔥 高频故障与风险 ^xm-e51dec8fc5624320afc433cb5b
    - cluster-admin 泛滥
    - token 长期有效
    - 特权容器
    - secret 明文/跨租户泄露
    - webhook fail-open
  - 🔎 排障路径 ^xm-a5144d0af5b94a63bf6945ce46
    - 身份→binding→role rules
    - 核对 admission/audit
    - 检查 secret 流转与挂载
  - 🧪 实战练习 ^xm-c0fb23a775334d528fd8c051c2
    - 最小权限 namespace 运维角色
    - PSA + policy + external secret
  - ✅ 验收标准 ^xm-00b73e81fdb64cdf80c1605728
    - 默认拒绝
    - 权限定期回收
    - 策略先 audit 后 enforce
    - 密钥可轮换
  - 🔗 对应优秀开源项目 ^xm-225c47d551004cb18ea28f5889
    - kyverno/kyverno
      
      备注（源图文本，未作运行验证）：
      定位：Kubernetes Policy as Code 源码阅读：policy→admission/background→report 实战：强制镜像来源、资源限制与标签注意：先 audit 后 enforce，避免阻断生产整理日期：2026-07-09
      - 原链接（未复核）：https://github.com/kyverno/kyverno
    - open-policy-agent/gatekeeper
      
      备注（源图文本，未作运行验证）：
      定位：OPA 驱动的 K8s 准入治理源码阅读：ConstraintTemplate→Constraint→admission 实战：编写并测试一条组织策略注意：策略性能与例外治理同样重要整理日期：2026-07-09
      - 原链接（未复核）：https://github.com/open-policy-agent/gatekeeper
    - external-secrets/external-secrets
      
      备注（源图文本，未作运行验证）：
      定位：外部密钥管理与 K8s 同步源码阅读：SecretStore→ExternalSecret→provider 实战：轮换密钥并验证应用无中断注意：同步进 K8s Secret 后仍需 etcd 加密与 RBAC 整理日期：2026-07-09
      - 原链接（未复核）：https://github.com/external-secrets/external-secrets
- Helm、Kustomize 与配置治理 ^xm-9723cc002afb49ab9fe4253c82
  - 🎯 目标 ^xm-07beb0b4698943e69fddafe5d4
    - 让 Kubernetes 配置可复用、可验证、可回滚。
  - 🧠 知识拆解 ^xm-cba18514bca740ccb148a9879b
    - base/overlay
    - chart/values/schema
    - render vs apply
    - release history
    - CRD lifecycle
    - secret separation
  - ⌨️ 命令 / 配置 / 关键对象 ^xm-76447a87a4794f97a266a66916
    - helm lint/template/diff/test/rollback
    - kustomize build
    - kubectl diff
    - schema validation
  - 🔥 高频故障与风险 ^xm-27a891d7d39e4094b41ac34d48
    - values 覆盖意外
    - CRD 升级不兼容
    - render 正确但运行失败
    - secret 进 Git
  - 🔎 排障路径 ^xm-96245f11f53547bfa58b40aff4
    - 先渲染再 diff
    - 核对 values 来源
    - 检查 hooks/order/CRD
    - 回放 release history
  - 🧪 实战练习 ^xm-7adee97ff93e42cc9064596c7b
    - 同一应用 dev/stage/prod
    - Chart schema 与测试
  - ✅ 验收标准 ^xm-5fcc92067eb34d77b56642ccff
    - 配置有 owner/schema
    - 生产 diff 被审查
    - 回滚和数据兼容明确
  - 🔗 对应优秀开源项目 ^xm-fa775898d7ca46b3a697ed506e
    - helm/helm
      
      备注（源图文本，未作运行验证）：
      定位：Kubernetes 包管理源码阅读：chart→values→template→release storage 实战：制作带 schema、tests、rollback 的 Chart 注意：模板逻辑不宜过度复杂整理日期：2026-07-09
      - 原链接（未复核）：https://github.com/helm/helm
    - kubernetes-sigs/kustomize
      - 原链接（未复核）：https://github.com/kubernetes-sigs/kustomize
- 集群升级、备份与生命周期 ^xm-1ba8573f0f3f422f86c8e72bb4
  - 🎯 目标 ^xm-dfaeca7f383649f9bb944efad4
    - 安全完成版本、节点、插件和 API 生命周期管理。
  - 🧠 知识拆解 ^xm-962c20d48187488cad4aff4a8d
    - version skew
    - deprecated APIs
    - control plane/node upgrade
    - drain/PDB
    - CNI/CSI/Ingress compatibility
    - etcd backup
  - ⌨️ 命令 / 配置 / 关键对象 ^xm-8ca99cdb69d2482cab27d6cac0
    - kubectl version/api-resources
    - kubent/pluto
    - kubeadm upgrade
    - cordon/drain/uncordon
    - etcdctl snapshot
  - 🔥 高频故障与风险 ^xm-e8005067dc6c4c3fbf0b668162
    - PDB 阻塞 drain
    - API 移除
    - webhook/CNI 不兼容
    - 节点无法回归
    - 证书过期
  - 🔎 排障路径 ^xm-843f4adc08ae44658114acb7db
    - 预检组件矩阵
    - 测试集群演练
    - 分批升级与 SLO 观察
    - 保留回滚窗口
  - 🧪 实战练习 ^xm-4f5c1204890a4d2d93795ae966
    - kind 多版本升级思维演练
    - 节点替换与 etcd 恢复
  - ✅ 验收标准 ^xm-091aab3421ec4bd98a1a028877
    - 升级 Runbook 完整
    - 兼容性/回滚经过验证
    - 弃用 API 为零
  - 🔗 对应优秀开源项目 ^xm-513181be7aff4407b1f2ab15ce
    - kubernetes-sigs/kind
      
      备注（源图文本，未作运行验证）：
      定位：本地多节点 Kubernetes 实验环境源码阅读：cluster config、node image、provider 实战：创建 3 节点集群并演练升级/网络故障注意：kind 适合学习和 CI，不等同生产集群整理日期：2026-07-09
      - 原链接（未复核）：https://github.com/kubernetes-sigs/kind
    - kubernetes/kubernetes
      
      备注（源图文本，未作运行验证）：
      定位：容器编排核心源码阅读：kubectl→apiserver→controller/scheduler→kubelet 实战：跟踪 Deployment 创建与 Pod 调度注意：不要从仓库第一行顺序阅读整理日期：2026-07-09
      - 原链接（未复核）：https://github.com/kubernetes/kubernetes
★ [新增] Kubernetes 生产主线
- 架构与生命周期 ^xm-d6315614a48f484daeb361ed7f
  - 控制平面与工作节点
  - etcd 一致性与备份
  - 版本偏差策略
  - 升级与回滚
  - 证书轮换
- 工作负载 ^xm-e923c777c4054a87acec51f0f7
  - Pod
  - Deployment/StatefulSet/DaemonSet
  - Job/CronJob
  - 探针与优雅终止
  - PDB
- 调度与资源 ^xm-36250a9e0a92430b9dcc29ae9c
  - requests/limits
  - QoS 与 Eviction
  - 亲和/反亲和
  - 污点与容忍
  - 优先级与抢占
  - HPA/VPA/Cluster Autoscaler
- 网络与流量 ^xm-6f3e228367ea48ca8e5d8061e9
  - CNI
  - Service
  - Ingress/Gateway API
  - NetworkPolicy
  - DNS
  - 服务网格
- 存储 ^xm-0d00d7d181654e32a7aea4abad
  - PV/PVC/StorageClass
  - CSI
  - 快照与备份
  - StatefulSet 数据保护
- 安全治理 ^xm-be9f380e93c240d9920030b295
  - RBAC 最小权限
  - 短期 ServiceAccount Token
  - Pod Security Standards
  - Admission Policy
  - Secret/KMS
  - 镜像与运行时安全
- 集群运维 ^xm-af01e4a49b80429f9c89fe4785
  - 节点维护
  - 故障排查
  - 审计日志
  - 成本与配额
  - 多集群治理
  - 灾备与恢复
★ [新增] 容器与虚拟化
- OCI 镜像与容器运行时
- Namespace/cgroup/seccomp
- Docker/Podman/containerd/CRI-O
- KVM/QEMU/libvirt
- OpenStack 与云平台基础
docker

⚑ [纠错] Kubernetes

备注（源图文本，未作运行验证）：

统一使用官方项目名称 Kubernetes。

集群安装
- kubeadm安装 ^xm-6pfc73fln0bcqgnvcp2nuvfrf6
  - 单节点部署
  - 高可用部署 ^xm-2ofkkqsgc2g3ko8dvt0g9n1kqo
    - 子主题 1
- 二进制安装
- rancher安装
- DCE安装

组件定义

⚑ [纠错] 控制平面组件

备注（源图文本，未作运行验证）：

控制平面通常包括 kube-apiserver、etcd、kube-scheduler、kube-controller-manager；具体部署形态可能为静态 Pod 或外部托管。

kube-apiserver
kube-controller-manager
kube-scheduler

⚑ [纠错] 工作节点组件

备注（源图文本，未作运行验证）：

工作节点运行 kubelet、容器运行时以及网络代理/数据面组件。

kubelet

⚑ [纠错] kube-proxy（节点网络代理）

备注（源图文本，未作运行验证）：

kube-proxy 运行在各节点，负责实现 Kubernetes Service 的部分网络转发能力。部分 CNI/eBPF 方案可替代其数据面职责。原控制平面下的重复节点已合并。

etcd
- 备份
- 集群
- 监控

⚑ [纠错] CNI 网络插件

备注（源图文本，未作运行验证）：

CNI 不是控制平面核心进程；插件通常以节点侧组件提供 Pod 网络、网络策略或数据面能力。

pod
- 创建流程 ^xm-472ntith7o7g5u473kr7etmd69
  - 1.客户端提交Pod的配置信息（可以是yaml⽂件定义的信息）到kube-apiserver
  - 2.Apiserver收到指令后，通知给controller-manager创建⼀个资源对象
  - 3.Controller-manager通过api-server将Pod的配置信息存储到etcd数据中⼼中
  - 4.Kube-scheduler检测到Pod信息会开始调度预选
  - 5.Kubelet根据scheduler发来的资源配置单运⾏Pod
- 健康检查⽅式 ^xm-5dncas7u89v52msd8pnbscn64n
  - LivenessProbe探针
    - 判断容器是否存活running
  - ⚑ [纠错] ReadinessProbe 就绪探针
    
    备注（源图文本，未作运行验证）：
```
原节点名称：ReadineeProbe探针。已统一为标准拼写。
```
    - 于判断容器是否启动完成ready
  - startupProbe探针
  - 启动检查机制，应⽤⼀些启动缓慢的业务
- NodeAffinity亲和性调度
CNI网络策略
- flannel ^xm-1dhhdt8g5t29fa3k6k8fsmj5fb
  - 每个node分配不同的ip地址,地址间形成Overlay Network(VXLAN)
  - 优点:部署简单,vxlan容器间通信
  - 缺点:overlay解封装消耗性能,扩展性差
- Calico ^xm-05b4vft05ujfqevkma0d5u2pks
  - BGP的纯三层IP路由的⽅式,不需要额外NET
  - 优点:ip路由通信,性能高,扩展性强
  - 缺点:配置复杂

⚑ [纠错] Kubernetes 安全机制

备注（源图文本，未作运行验证）：

原节点名称：K8S安全机制。已统一为标准拼写。

认证Auth

kubeconfig ^xm-77t0dt00cda4kr24e6fov9tflr

X.509证书 admin/用户证书

kubeconfig:路径版

⚑ [纠错] # 1. 生成私钥和 CSR (CN=用户名, O=组名) openssl genrsa -out user.key 2048（详见备注）

备注（源图文本，未作运行验证）：

原节点名称：# 1. 生成私钥和 CSR (CN=用户名, O=组名)
openssl genrsa -out user.key 2048
openssl req -new -key user.key -out user.csr \
  -subj "/CN=devuser/O=dev-team"
 
# 2. 用 K8s CA 签发用户证书, CA 用 ca-key.pem 对这些内容做数字签名
  openssl x509 -req -in user.csr \
    -CA /opt/kubernetes/ssl/ca.pem \
    -CAkey /opt/kubernetes/ssl/ca-key.pem \
    -CAcreateserial \
    -out user.crt \
    -days 3650
 
  发生了什么：
  user.key（私钥）──生成──▶ user.csr（证书申请）
                                      │
                                      │ CA 用自己的私钥签名
                                      ▼
                      /opt/kubernetes/ssl/ca.pem（CA 证书）
                      /opt/kubernetes/ssl/ca-key.pem（CA 私钥）
                                      │
                                      ▼
                                user.crt（签发完成的用户证书）
 
  - user.csr 里包含：用户名 CN=devuser、组名 O=dev-team、公钥
  - CA 用自己的私钥对这些信息签名，生成 user.crt
  - 任何持有 ca.pem 的人都能验证这张证书是合法的
  - -CAcreateserial 自动生成序列号文件 ca.srl
  - -days 365 证书有效期 1 年
 
  ---
# 3.验证签名 确认 user.crt 确实是由这个 CA 签的，输出 user.crt: OK 才继续。
  openssl verify -CAfile /opt/kubernetes/ssl/ca.pem user.crt
 
# 4.写入集群信息
  kubectl config set-cluster k8s-direct \
    --server=https://192.168.9.221:6443 \
    --certificate-authority=/opt/kubernetes/ssl/ca.pem \
    --kubeconfig=cert-kubeconfig
 
  写入 kubeconfig 的内容：
  clusters:
  - name: k8s-direct
    cluster:
      server: https://192.168.9.221:6443        # 直连 master 节点
      certificate-authority: /opt/kubernetes/ssl/ca.pem  # 验证服务端证书用
 
  certificate-authority 的作用：kubectl 发 HTTPS 请求时，用这个 CA
  验证服务器（kube-apiserver）的证书是否可信，防止中间人攻击。
 
# 5.写入用户凭证
  kubectl config set-credentials devuser \
    --client-certificate=user.crt \
    --client-key=user.key \
    --kubeconfig=cert-kubeconfig
 
  写入 kubeconfig 的内容：
  users:
  - name: devuser
    user:
      client-certificate: user.crt   # 告诉 apiserver 我是谁
      client-key: user.key           # 证明这张证书是我的（私钥配对）
 
  client-certificate + client-key 的作用：这是 双向 TLS
  认证，不只是服务端验证客户端，客户端也要出示自己的证书给服务端验证。kube-apiserver
  收到请求后：
 
  收到 user.crt
      │
      ▼
  用 /opt/kubernetes/ssl/ca.pem 验证签名
      │
      ▼
  签名合法 → 提取 CN=devuser, O=dev-team → 这就是请求者的身份
      │
      ▼
  去 RBAC 查 devuser 有没有权限做这个操作
 
  ---
# 6. 写入 context 并设为默认
 
  kubectl config set-context default \
    --cluster=k8s-direct \
    --user=devuser \
    --kubeconfig=cert-kubeconfig
 
  kubectl config use-context default --kubeconfig=cert-kubeconfig
 
  context 就是把「用哪个集群」和「用哪个用户」绑定在一起：
 
  context: default
    ├── cluster: k8s-direct  (server + CA)
    └── user: devuser        (cert + key)
 
# 7. RBAC 授权
 
  kubectl create clusterrolebinding devuser-admin \
    --clusterrole=cluster-admin \
    --user=devuser
 
  kube-apiserver 认证通过后（知道你是 devuser）还要检查授权，没有 RBAC 规则就会返回
  403。这一步告诉 K8s：devuser 拥有 cluster-admin 权限。。已修正拼写或统一术语。
 
原节点完整内容：
⚑ [纠错] # 1. 生成私钥和 CSR (CN=用户名, O=组名)
openssl genrsa -out user.key 2048
openssl req -new -key user.key -out user.csr \
  -subj "/CN=devuser/O=dev-team"
 
# 2. 用 Kubernetes CA 签发用户证书, CA 用 ca-key.pem 对这些内容做数字签名
  openssl x509 -req -in user.csr \
    -CA /opt/kubernetes/ssl/ca.pem \
    -CAkey /opt/kubernetes/ssl/ca-key.pem \
    -CAcreateserial \
    -out user.crt \
    -days 3650
 
  发生了什么：
  user.key（私钥）──生成──▶ user.csr（证书申请）
                                      │
                                      │ CA 用自己的私钥签名
                                      ▼
                      /opt/kubernetes/ssl/ca.pem（CA 证书）
                      /opt/kubernetes/ssl/ca-key.pem（CA 私钥）
                                      │
                                      ▼
                                user.crt（签发完成的用户证书）
 
  - user.csr 里包含：用户名 CN=devuser、组名 O=dev-team、公钥
  - CA 用自己的私钥对这些信息签名，生成 user.crt
  - 任何持有 ca.pem 的人都能验证这张证书是合法的
  - -CAcreateserial 自动生成序列号文件 ca.srl
  - -days 365 证书有效期 1 年
 
  ---
# 3.验证签名 确认 user.crt 确实是由这个 CA 签的，输出 user.crt: OK 才继续。
  openssl verify -CAfile /opt/kubernetes/ssl/ca.pem user.crt
 
# 4.写入集群信息
  kubectl config set-cluster Kubernetes-direct \
    --server=https://192.168.9.221:6443 \
    --certificate-authority=/opt/kubernetes/ssl/ca.pem \
    --kubeconfig=cert-kubeconfig
 
  写入 kubeconfig 的内容：
  clusters:
  - name: Kubernetes-direct
    cluster:
      server: https://192.168.9.221:6443        # 直连 master 节点
      certificate-authority: /opt/kubernetes/ssl/ca.pem  # 验证服务端证书用
 
  certificate-authority 的作用：kubectl 发 HTTPS 请求时，用这个 CA
  验证服务器（kube-apiserver）的证书是否可信，防止中间人攻击。
 
# 5.写入用户凭证
  kubectl config set-credentials devuser \
    --client-certificate=user.crt \
    --client-key=user.key \
    --kubeconfig=cert-kubeconfig
 
  写入 kubeconfig 的内容：
  users:
  - name: devuser
    user:
      client-certificate: user.crt   # 告诉 apiserver 我是谁
      client-key: user.key           # 证明这张证书是我的（私钥配对）
 
  client-certificate + client-key 的作用：这是 双向 TLS
  认证，不只是服务端验证客户端，客户端也要出示自己的证书给服务端验证。kube-apiserver
  收到请求后：
 
  收到 user.crt
      │
      ▼
  用 /opt/kubernetes/ssl/ca.pem 验证签名
      │
      ▼
  签名合法 → 提取 CN=devuser, O=dev-team → 这就是请求者的身份
      │
      ▼
  去 RBAC 查 devuser 有没有权限做这个操作
 
  ---
# 6. 写入 context 并设为默认
 
  kubectl config set-context default \
    --cluster=Kubernetes-direct \
    --user=devuser \
    --kubeconfig=cert-kubeconfig
 
  kubectl config use-context default --kubeconfig=cert-kubeconfig
 
  context 就是把「用哪个集群」和「用哪个用户」绑定在一起：
 
  context: default
    ├── cluster: Kubernetes-direct  (server + CA)
    └── user: devuser        (cert + key)
 
# 7. RBAC 授权
 
  kubectl create clusterrolebinding devuser-admin \
    --clusterrole=cluster-admin \
    --user=devuser
 
  kube-apiserver 认证通过后（知道你是 devuser）还要检查授权，没有 RBAC 规则就会返回
  403。这一步告诉 Kubernetes：devuser 拥有 cluster-admin 权限。

⚑ [纠错] 查看集群、用户、认证信息 1. 查看 kubeconfig 所有信息 # 查看当前 kubeconfig 完整内容（证书显示路径（详见备注）

备注（源图文本，未作运行验证）：

原节点名称：查看集群、用户、认证信息
  
  1. 查看 kubeconfig 所有信息
 
  # 查看当前 kubeconfig 完整内容（证书显示路径/截断）
  kubectl config view
 
  # 查看原始完整内容（含 base64 证书数据）
  kubectl config view --raw
 
  # 查看指定 kubeconfig 文件
  kubectl config view --kubeconfig=cert-kubeconfig
 
  ---
  2. 查看集群列表
 
  kubectl config get-clusters
 
  # 输出示例：
  # NAME
  # k8s-direct
  # k8s-rancher
 
  ---
  3. 查看用户（凭证）列表
 
  kubectl config get-users
 
  # 输出示例：
  # NAME
  # devuser
  # k8s
 
  ---
  4. 查看 context（集群+用户绑定关系）
 
  # 查看所有 context（★ 最直观，一行看清绑定关系）
  kubectl config get-contexts
 
  # 输出示例：
  # CURRENT   NAME      CLUSTER      AUTHINFO   NAMESPACE
  # *         default   k8s-direct   devuser
  #           rancher   k8s          k8s
 
  # 查看当前使用的 context
  kubectl config current-context
 
  ---
  5. 查看某个具体 context 的详细信息
 
  kubectl config view -o jsonpath='{.contexts[?(@.name=="default")]}'
 
  ---
  6. 解析证书内容（查看用户名、组、有效期）
 
  # 从文件解析
  openssl x509 -in user.crt -noout -text | grep -E 'Subject:|Issuer:|Not Before|Not After'
 
  # 从 kubeconfig base64 数据直接解析
  kubectl config view --raw \
    -o jsonpath='{.users[?(@.name=="k8s")].user.client-certificate-data}' \
    | base64 -d | openssl x509 -noout -text \
    | grep -E 'Subject:|Issuer:|Not Before|Not After'
 
  # 输出示例：
  # Issuer: CN=k8s-ca
  # Subject: CN=devuser, O=dev-team
  # Not Before: May 20 10:00:00 2025 GMT
  # Not After : May 20 10:00:00 2026 GMT
 
  ---
  7. 验证当前使用的是哪个用户身份
 
  # ★ 最实用：直接问 apiserver 我是谁
  kubectl auth whoami
 
  # 或
  kubectl auth whoami --kubeconfig=cert-kubeconfig
 
  # 输出示例：
  # ATTRIBUTE   VALUE
  # Username    devuser
  # Groups      [dev-team system:authenticated]
 
  ---
  8. 查看这个用户有哪些权限
 
  # 查看能做什么操作
  kubectl auth can-i --list --kubeconfig=cert-kubeconfig
 
  # 查看能不能做某个具体操作
  kubectl auth can-i get pods --kubeconfig=cert-kubeconfig
  kubectl auth can-i delete nodes --kubeconfig=cert-kubeconfig
 
  # 管理员查看某个用户的权限
  kubectl auth can-i get pods --as=devuser
 
  ---
  9. 查看 RBAC 绑定关系
 
  # 查看所有 ClusterRoleBinding（集群级别绑定）
  kubectl get clusterrolebinding -o wide | grep devuser
 
  # 查看所有 RoleBinding（命名空间级别绑定）
  kubectl get rolebinding -A -o wide | grep devuser
 
  # 查看某个绑定的详情
  kubectl describe clusterrolebinding devuser-admin
  # 输出：
  # Role:
  #   Kind:  ClusterRole
  #   Name:  cluster-admin
  # Subjects:
  #   Kind  Name      Namespace
  #   User  devuser
 
  ---
  一条命令总览
 
  # 汇总：context + 集群 + 用户 + 证书有效期
  kubectl config get-contexts && \
  echo "---当前用户---" && \
  kubectl auth whoami && \
  echo "---证书有效期---" && \
  kubectl config view --raw \
    -o jsonpath='{.users[0].user.client-certificate-data}' \
    | base64 -d | openssl x509 -noout -dates 2>/dev/null || \
  echo "（token 认证，无客户端证书）"。已修正拼写或统一术语。
 
原节点完整内容：
⚑ [纠错] 查看集群、用户、认证信息
  
  1. 查看 kubeconfig 所有信息
 
  # 查看当前 kubeconfig 完整内容（证书显示路径/截断）
  kubectl config view
 
  # 查看原始完整内容（含 base64 证书数据）
  kubectl config view --raw
 
  # 查看指定 kubeconfig 文件
  kubectl config view --kubeconfig=cert-kubeconfig
 
  ---
  2. 查看集群列表
 
  kubectl config get-clusters
 
  # 输出示例：
  # NAME
  # Kubernetes-direct
  # Kubernetes-rancher
 
  ---
  3. 查看用户（凭证）列表
 
  kubectl config get-users
 
  # 输出示例：
  # NAME
  # devuser
  # Kubernetes
 
  ---
  4. 查看 context（集群+用户绑定关系）
 
  # 查看所有 context（★ 最直观，一行看清绑定关系）
  kubectl config get-contexts
 
  # 输出示例：
  # CURRENT   NAME      CLUSTER      AUTHINFO   NAMESPACE
  # *         default   Kubernetes-direct   devuser
  #           rancher   Kubernetes          Kubernetes
 
  # 查看当前使用的 context
  kubectl config current-context
 
  ---
  5. 查看某个具体 context 的详细信息
 
  kubectl config view -o jsonpath='{.contexts[?(@.name=="default")]}'
 
  ---
  6. 解析证书内容（查看用户名、组、有效期）
 
  # 从文件解析
  openssl x509 -in user.crt -noout -text | grep -E 'Subject:|Issuer:|Not Before|Not After'
 
  # 从 kubeconfig base64 数据直接解析
  kubectl config view --raw \
    -o jsonpath='{.users[?(@.name=="Kubernetes")].user.client-certificate-data}' \
    | base64 -d | openssl x509 -noout -text \
    | grep -E 'Subject:|Issuer:|Not Before|Not After'
 
  # 输出示例：
  # Issuer: CN=Kubernetes-ca
  # Subject: CN=devuser, O=dev-team
  # Not Before: May 20 10:00:00 2025 GMT
  # Not After : May 20 10:00:00 2026 GMT
 
  ---
  7. 验证当前使用的是哪个用户身份
 
  # ★ 最实用：直接问 apiserver 我是谁
  kubectl auth whoami
 
  # 或
  kubectl auth whoami --kubeconfig=cert-kubeconfig
 
  # 输出示例：
  # ATTRIBUTE   VALUE
  # Username    devuser
  # Groups      [dev-team system:authenticated]
 
  ---
  8. 查看这个用户有哪些权限
 
  # 查看能做什么操作
  kubectl auth can-i --list --kubeconfig=cert-kubeconfig
 
  # 查看能不能做某个具体操作
  kubectl auth can-i get pods --kubeconfig=cert-kubeconfig
  kubectl auth can-i delete nodes --kubeconfig=cert-kubeconfig
 
  # 管理员查看某个用户的权限
  kubectl auth can-i get pods --as=devuser
 
  ---
  9. 查看 RBAC 绑定关系
 
  # 查看所有 ClusterRoleBinding（集群级别绑定）
  kubectl get clusterrolebinding -o wide | grep devuser
 
  # 查看所有 RoleBinding（命名空间级别绑定）
  kubectl get rolebinding -A -o wide | grep devuser
 
  # 查看某个绑定的详情
  kubectl describe clusterrolebinding devuser-admin
  # 输出：
  # Role:
  #   Kind:  ClusterRole
  #   Name:  cluster-admin
  # Subjects:
  #   Kind  Name      Namespace
  #   User  devuser
 
  ---
  一条命令总览
 
  # 汇总：context + 集群 + 用户 + 证书有效期
  kubectl config get-contexts && \
  echo "---当前用户---" && \
  kubectl auth whoami && \
  echo "---证书有效期---" && \
  kubectl config view --raw \
    -o jsonpath='{.users[0].user.client-certificate-data}' \
    | base64 -d | openssl x509 -noout -dates 2>/dev/null || \
  echo "（token 认证，无客户端证书）"

⚠ [版本限定] ServiceAccount 长期 Bearer Token 示例

备注（源图文本，未作运行验证）：

长期 Secret Token 仅用于遗留兼容，并存在泄露与难轮换风险。生产主线应优先使用 TokenRequest/投射卷获取短期、受众受限的 Token；授权按最小权限，避免默认绑定 cluster-admin。

⚑ [纠错] 1.创建 ServiceAccount kubectl create serviceaccount devuser-sa -n（详见备注）

备注（源图文本，未作运行验证）：

原节点名称：1.创建 ServiceAccount
 
kubectl create serviceaccount devuser-sa -n default
 
2.创建 Secret 绑定 SA（K8s 1.24+ 需要手动创建）
 
kubectl apply -f - <<EOF
apiVersion: v1
kind: Secret
metadata:
  name: devuser-sa-token
  namespace: default
  annotations:
    kubernetes.io/service-account.name: devuser-sa
type: kubernetes.io/service-account-token
EOF
 
3.# 等几秒 token 自动填充后提取
TOKEN=$(kubectl get secret devuser-sa-token -n default \
  -o jsonpath='{.data.token}' | base64 -d)
 
echo $TOKEN
 
4. 提取 CA 证书直接用已知的 K8s CA 文件
CA_DATA=$(base64 -w 0 /opt/kubernetes/ssl/ca.pem)
 
5. 生成 kubeconfig
 
cat > token-kubeconfig <<EOF
apiVersion: v1
kind: Config
clusters:
- name: k8s-direct
  cluster:
    server: https://192.168.9.221:6443
    certificate-authority-data: ${CA_DATA}
users:
- name: devuser-sa
  user:
    token: ${TOKEN}
contexts:
- name: default
  context:
    cluster: k8s-direct
    user: devuser-sa
    namespace: default
current-context: default
EOF
 
---
6. RBAC 授权,按需选择授权范围
 
# 方式A：集群管理员（全部权限）
kubectl create clusterrolebinding devuser-sa-admin \
  --clusterrole=cluster-admin \
  --serviceaccount=default:devuser-sa
 
# 方式B：只读权限
kubectl create clusterrolebinding devuser-sa-view \
  --clusterrole=view \
  --serviceaccount=default:devuser-sa
 
# 方式C：只能操作某个命名空间
kubectl create rolebinding devuser-sa-admin-ns \
  --clusterrole=admin \
  --serviceaccount=default:devuser-sa \
  -n your-namespace
 
---
7.  验证身份
kubectl auth whoami --kubeconfig=token-kubeconfig
 
# 验证权限
kubectl get nodes --kubeconfig=token-kubeconfig
kubectl get pods -A --kubeconfig=token-kubeconfig。已修正拼写或统一术语。
 
原节点完整内容：
⚑ [纠错] 1.创建 ServiceAccount
 
kubectl create serviceaccount devuser-sa -n default
 
2.创建 Secret 绑定 SA（Kubernetes 1.24+ 需要手动创建）
 
kubectl apply -f - <<EOF
apiVersion: v1
kind: Secret
metadata:
  name: devuser-sa-token
  namespace: default
  annotations:
    kubernetes.io/service-account.name: devuser-sa
type: kubernetes.io/service-account-token
EOF
 
3.# 等几秒 token 自动填充后提取
TOKEN=$(kubectl get secret devuser-sa-token -n default \
  -o jsonpath='{.data.token}' | base64 -d)
 
echo $TOKEN
 
4. 提取 CA 证书直接用已知的 Kubernetes CA 文件
CA_DATA=$(base64 -w 0 /opt/kubernetes/ssl/ca.pem)
 
5. 生成 kubeconfig
 
cat > token-kubeconfig <<EOF
apiVersion: v1
kind: Config
clusters:
- name: Kubernetes-direct
  cluster:
    server: https://192.168.9.221:6443
    certificate-authority-data: ${CA_DATA}
users:
- name: devuser-sa
  user:
    token: ${TOKEN}
contexts:
- name: default
  context:
    cluster: Kubernetes-direct
    user: devuser-sa
    namespace: default
current-context: default
EOF
 
---
6. RBAC 授权,按需选择授权范围
 
# 方式A：集群管理员（全部权限）
kubectl create clusterrolebinding devuser-sa-admin \
  --clusterrole=cluster-admin \
  --serviceaccount=default:devuser-sa
 
# 方式B：只读权限
kubectl create clusterrolebinding devuser-sa-view \
  --clusterrole=view \
  --serviceaccount=default:devuser-sa
 
# 方式C：只能操作某个命名空间
kubectl create rolebinding devuser-sa-admin-ns \
  --clusterrole=admin \
  --serviceaccount=default:devuser-sa \
  -n your-namespace
 
---
7.  验证身份
kubectl auth whoami --kubeconfig=token-kubeconfig
 
# 验证权限
kubectl get nodes --kubeconfig=token-kubeconfig
kubectl get pods -A --kubeconfig=token-kubeconfig

Exec Plugin（外部认证，适合 Rancher/OIDC/AWS）

⚑ [纠错] 3. Exec Plugin（外部认证，适合 Rancher/OIDC/AWS）适合需要动态获取 token 的场景： # R（详见备注）

备注（源图文本，未作运行验证）：

原节点名称：3. Exec Plugin（外部认证，适合 Rancher/OIDC/AWS）
 
  适合需要动态获取 token 的场景：
 
  # Rancher exec 方式（等效于当前你们的 Rancher token 模式）
  users:
  - name: rancher-user
    user:
      exec:
        apiVersion: client.authentication.k8s.io/v1beta1
        command: kubectl
        args:
        - oidc-login     # 需要安装 kubelogin 插件
        - get-token
        - --oidc-issuer-url=https://192.168.9.221/auth
        - --oidc-client-id=kubectl
 
  # AWS EKS 方式
  users:
  - name: aws-user
    user:
      exec:
        apiVersion: client.authentication.k8s.io/v1beta1
        command: aws
        args: ["eks", "get-token", "--cluster-name", "my-cluster"]。已修正拼写或统一术语。
 
原节点完整内容：
⚑ [纠错] 3. Exec Plugin（外部认证，适合 Rancher/OIDC/AWS）
 
  适合需要动态获取 token 的场景：
 
  # Rancher exec 方式（等效于当前你们的 Rancher token 模式）
  users:
  - name: rancher-user
    user:
      exec:
        apiVersion: client.authentication.Kubernetes.io/v1beta1
        command: kubectl
        args:
        - oidc-login     # 需要安装 kubelogin 插件
        - get-token
        - --oidc-issuer-url=https://192.168.9.221/auth
        - --oidc-client-id=kubectl
 
  # AWS EKS 方式
  users:
  - name: aws-user
    user:
      exec:
        apiVersion: client.authentication.Kubernetes.io/v1beta1
        command: aws
        args: ["eks", "get-token", "--cluster-name", "my-cluster"]

1. 多集群合并到一个 kubeconfig

⚑ [纠错] # 把多个 kubeconfig 合并 export KUBECONFIG=~~/.kube/config:~~/rancher-k（详见备注）

备注（源图文本，未作运行验证）：

原节点名称：# 把多个 kubeconfig 合并
  export KUBECONFIG=~/.kube/config:~/rancher-kubeconfig:~/dev-kubeconfig
 
  # 合并写入单文件
  kubectl config view --merge --flatten > ~/.kube/merged-config
 
  # 查看所有 context
  kubectl config get-contexts
 
  # 切换集群
  kubectl config use-context k8s-prod
  kubectl config use-context k8s-dev。已修正拼写或统一术语。
 
原节点完整内容：
⚑ [纠错] # 把多个 kubeconfig 合并
  export KUBECONFIG=~/.kube/config:~/rancher-kubeconfig:~/dev-kubeconfig
 
  # 合并写入单文件
  kubectl config view --merge --flatten > ~/.kube/merged-config
 
  # 查看所有 context
  kubectl config get-contexts
 
  # 切换集群
  kubectl config use-context Kubernetes-prod
  kubectl config use-context Kubernetes-dev

认证原理 ^xm-4vidhfc1rdk54ct9k12s4qmrm0

完整认证流程 kubectl get nodes —kubeconfig=cert-kubeconfig │ ▼ ① TLS（详见备注）

备注（源图文本，未作运行验证）：

原节点完整内容：
 完整认证流程
 
  kubectl get nodes --kubeconfig=cert-kubeconfig
          │
          ▼
  ① TLS 握手
     客户端用 ca.pem 验证服务端证书 ──▶ 服务端是合法的 192.168.9.221
     服务端收到客户端的 user.crt   ──▶ 用 ca.pem 验签 ──▶ 身份是 devuser
          │
          ▼
  ② 认证通过（Authentication）
     身份确认：CN=devuser, O=dev-team
          │
          ▼
  ③ 授权检查（Authorization）
     RBAC：devuser 有 cluster-admin 权限？ ──▶ 有
          │
          ▼
  ④ 返回结果
     node 列表

授权Authz
- RBAC
⚑ [纠错] 准入控制 Admission

备注（源图文本，未作运行验证）：
```
原节点名称：准入控制Adminssion。已统一为标准拼写。
```
审计Audit

OpenStack

YS.WIKI

探索

S01-07-虚拟化与云原生

来源快照｜虚拟化与云原生

关系图谱

反向链接