手册

部署最小的、可协同工作的负载单元。

→定义一个 `Pod` 资源。Pod 可以包含一个或多个共享网络和存储的容器。

原因: Pod 是 Kubernetes 中调度的原子单元。容器始终部署在 Pod 内部。

参考↗

确保集群状态持续与期望状态匹配。

→依赖 `kube-controller-manager`。它运行控制循环，监视资源（例如 ReplicaSets、Deployments）并协调差异。

原因: 这是核心的声明式、自愈机制。如果一个由 ReplicaSet 管理的 Pod 发生故障，控制器会自动替换它。

自动将新创建的 Pod 分配给最合适的工作节点。

→依赖 `kube-scheduler`。它根据 Pod 需求（例如资源请求）过滤节点，并对其进行评分以选择最合适的节点。

原因: 调度器根据策略、亲和性和可用性做出放置决策，将节点选择从用户中抽象出来。

确保 Pod 中指定的容器在给定的工作节点上运行并健康。

→`kubelet` 代理在每个节点上运行，与 API 服务器通信，并通过容器运行时管理容器生命周期（启动、停止、健康检查）。

原因: Kubelet 是控制平面与工作节点之间的链接；它执行 Pod 规范。

可靠地持久化 Kubernetes 集群的整个状态和配置。

→使用 `etcd`，一个一致且高可用的键值存储。它作为集群的单一事实来源。

原因: 所有集群对象（Pods、Services 等）都存储在 etcd 中。只有 API 服务器直接与它通信。

在每个节点上实施网络规则，以通过 Kubernetes Services 实现通信。

→每个节点上的 `kube-proxy` 组件维护网络规则（例如 iptables、IPVS），将流量从 Service IP 转发到正确的后端 Pod。

原因: Kube-proxy 是 Service 抽象背后的实现细节，处理负载均衡和路由。

为多个团队、项目或环境逻辑分区单个 Kubernetes 集群。

→创建 `Namespace` 资源。命名空间为名称提供范围，并提供附加授权和策略（例如 ResourceQuotas）的方式。

原因: 命名空间实现了多租户和资源组织，而无需多个集群的开销。

为一组短暂的 Pod 提供稳定的网络端点（IP 和 DNS）。

→定义一个 `Service` 资源，使用标签选择器定位一组 Pod。

原因: Pod 是短暂的，其 IP 会变化。Service 提供了一个持久的抽象，可以将流量负载均衡到正确的 Pod。

参考↗

将 Pod 中运行的应用程序暴露给不同的网络范围。

→选择 Service `类型`：`ClusterIP`（仅内部，默认）、`NodePort`（在每个节点 IP:port 上暴露）或 `LoadBalancer`（预置云负载均衡器）。

原因: Service 类型决定了应用程序的可访问性，从纯内部到完全外部。

启用单个 Pod 的直接网络发现，绕过 Service 代理。

→创建一个 `clusterIP: None` 的 `Service`。这将为每个 Pod 创建 DNS A 记录，允许客户端直接连接到 Pod。

原因: 对于需要点对点通信或稳定 Pod 身份的有状态应用程序（通常与 StatefulSets 结合使用）至关重要。

组织和选择 Kubernetes 对象的一个子集。

→将键值 `labels` 附加到对象（例如 `app: my-api`）。在其他对象（例如 Services、Deployments）中使用 `label selectors` 来定位它们。

原因: 标签是 Kubernetes 中的核心分组机制，实现了资源之间的松耦合。

将应用程序配置与容器镜像解耦。

→将非敏感配置数据存储在 `ConfigMap` 中。将其作为卷挂载或将键作为环境变量注入到 Pod 中。

原因: 这使得配置可以独立于应用程序代码进行管理，遵循 12-Factor App 原则。

存储密码、令牌或 API 密钥等敏感数据供应用程序使用。

→使用 `Secret` 对象。将其作为卷挂载或作为环境变量注入。

原因: Secrets 专门用于敏感数据，并且比 ConfigMaps 处理得更安全（例如，默认情况下不会在 `kubectl describe` 中显示，可以在静态时加密）。

为有状态应用程序提供在 Pod 重启后仍然存在的存储。

→Pod 创建 `PersistentVolumeClaim` (PVC) 来请求存储。管理员预置一个 `PersistentVolume` (PV) 来满足该请求。

原因: 这将存储消耗 (PVC) 与存储预置 (PV) 解耦，从而实现了可移植的工作负载定义。

管理容器的 CPU 和内存分配。

→设置 `resources.requests` 用于保证资源（用于调度），设置 `resources.limits` 用于最大允许使用量（在运行时强制执行）。

原因: 请求确保 Pod 有足够的资源运行；限制防止 Pod 消耗过多资源并影响其他工作负载。

对命名空间设置聚合资源约束。

→创建 `ResourceQuota` 对象以限制在命名空间中可以创建的 CPU、内存总量或对象数量（Pods、Services）。

原因: ResourceQuotas 对于多租户环境至关重要，可确保公平的资源共享并防止过度消耗。

使用版本控制的配置文件管理 Kubernetes 资源。

→使用 `kubectl apply -f <filename.yaml>`。此命令根据文件内容创建或更新资源。

原因: `apply` 是声明性的，非常适合 GitOps 和 CI/CD。它跟踪更改并执行三向合并，这比命令式的 `create` 或 `replace` 更安全。

诊断 Pod 未正常运行的原因（例如，停留在 Pending、ContainerCreating 或 CrashLoopBackOff 状态）。

→使用 `kubectl describe pod <pod-name>`。检查底部的 `Events` 部分，获取来自调度器、kubelet 或控制器的详细消息。

原因: `describe` 提供了一个按时间顺序排列的事件日志，是调试资源生命周期问题的主要工具。

为容器提供网络功能，实现集群范围内的 Pod 到 Pod 通信。

→使用容器网络接口 (CNI) 插件（例如 Calico、Flannel、Cilium）。每个节点上的 kubelet 使用 CNI 插件为每个 Pod 配置网络。

原因: CNI 提供了一个标准接口，允许 Kubernetes 与各种网络解决方案集成，而无需修改核心组件。

控制用户和应用程序对 Kubernetes API 资源的访问。

→使用基于角色的访问控制 (RBAC)。定义具有权限的 `Role`（命名空间级别）或 `ClusterRole`（集群级别），并使用 `RoleBinding` 或 `ClusterRoleBinding` 将其绑定到主体（用户、组、ServiceAccount）。

原因: RBAC 是保护 Kubernetes 的标准，为所有 API 交互启用了最小权限原则。

参考↗

管理无状态应用程序，实现轻松更新和回滚。

→使用 `Deployment` 工作负载。它管理 ReplicaSets 以确保所需数量的 Pod 副本正在运行，并提供声明式更新策略。

原因: Deployments 是无状态应用程序的标准，抽象了扩缩容和滚动更新的细节。

参考↗

部署需要稳定网络身份和存储的有状态应用程序（例如数据库）。

→使用 `StatefulSet` 工作负载。它为每个 Pod 提供稳定、唯一的主机名和在重启后仍然保留的持久存储。

原因: 与 Deployments 不同，StatefulSets 管理带有身份的 Pod，确保有序部署和扩缩容，这对于有状态系统至关重要。

在集群中的每个节点上部署代理（例如日志收集器、监控代理）。

→使用 `DaemonSet` 工作负载。它确保 Pod 的一个副本在每个节点（或节点子集）上运行。

原因: DaemonSets 自动化节点级服务的分发，随着新节点加入集群而自动扩缩。

运行一个需要执行完成的有限、一次性任务。

→使用 `Job` 资源。它创建一个或多个 Pod 并确保它们成功终止。

原因: Jobs 用于批处理，与用于持续服务的 Deployments 不同。Pod 在成功完成后不会被替换。

按重复计划运行任务（例如夜间备份、报告）。

→使用 `CronJob` 资源。它根据 cron 调度字符串创建 Jobs。

原因: CronJobs 提供了一种原生的 Kubernetes 方式来管理基于时间的重复任务。

自动重启已无响应的容器（例如死锁）。

→在容器规范中配置 `livenessProbe`。如果探测失败，kubelet 将重启容器。

原因: Liveness probes 为那些可能陷入损坏状态而不崩溃的应用程序提供了强大的自愈机制。

防止流量发送到尚未准备好处理请求的容器。

→在容器规范中配置 `readinessProbe`。只有当探测成功后，Pod 才会被添加到 Service 端点。

原因: Readiness probes 对于零停机滚动更新至关重要，确保新 Pod 在接收生产流量之前完全初始化。

在启动主应用程序容器之前运行设置任务或等待依赖项就绪。

→在 Pod 规范中定义一个或多个 `initContainers`。它们在任何应用程序容器启动之前按顺序运行完成。

原因: Init 容器为设置逻辑提供了清晰的分离，确保满足先决条件，而不会使主应用程序容器变得混乱。

确保 Pod 调度到具有特定特征的节点上（例如，具有 GPU、SSD 的节点）。

→在 Pod 规范中使用 `nodeAffinity` 根据节点标签设置规则。可以是“required”（硬）或“preferred”（软）约束。

原因: 节点亲和性比 `nodeSelector` 更具表达力，是根据节点属性控制 Pod 放置的现代方式。

控制 Pod 之间相互的协同定位，以实现性能或高可用性。

→使用 `podAffinity` 将 Pod 调度在一起（例如在同一个节点上），或使用 `podAntiAffinity` 将它们分散开（例如跨不同的节点或区域）。

原因: 反亲和性对于确保服务的副本不在同一个故障域中至关重要，从而提高了可用性。

防止通用 Pod 调度到专用或特殊用途节点上。

→对节点应用 `Taint`。Pod 必须在其规范中具有匹配的 `Toleration` 才能在该节点上调度。

原因: Taints 和 tolerations 确保节点保留给明确允许在其上运行的工作负载。

通过在区域或节点等故障域中均匀分布 Pod 来确保高可用性。

→在 Pod 规范中定义 `topologySpreadConstraints`，以根据标签和拓扑键（例如 `topology.kubernetes.io/zone`）控制 Pod 的分布方式。

原因: 这比 Pod 反亲和性提供了更细粒度的高可用性控制，防止所有副本集中在单个位置。

根据观测到的负载自动扩缩应用程序副本的数量。

→创建一个 `HorizontalPodAutoscaler` (HPA) 资源，它以 Deployment 为目标，并指定一个指标（例如 CPU 利用率）和目标值。

原因: HPA 实现了弹性扩缩，确保在负载下的性能，同时在空闲期间节省成本，无需人工干预。

参考↗

根据资源需求自动向集群添加或删除工作节点。

→部署 `Cluster Autoscaler`。它监视无法调度的 Pod（由于资源稀缺）并添加节点，或移除利用率不足的节点。

原因: Cluster Autoscaler 管理基础设施级别的弹性，与云提供商协作，根据工作负载需求调整集群大小。

在自愿中断（例如节点升级）期间，确保最少数量的应用程序副本保持可用。

→创建一个 `PodDisruptionBudget` (PDB)，为一组 Pod 指定 `minAvailable` 或 `maxUnavailable`。

原因: PDBs 防止诸如 `kubectl drain` 之类的操作一次性关闭太多副本，从而保护应用程序的可用性。

对无状态应用程序执行零停机更新。

→使用采用默认 `RollingUpdate` 策略的 `Deployment`。配置 `maxSurge` 和 `maxUnavailable` 来控制更新过程。

原因: 滚动更新逐步用新 Pod 替换旧 Pod，确保服务在整个更新过程中保持可用。

使用版本控制和审计追踪以声明方式管理基础设施和应用程序部署。

→实施 GitOps。使用 Git 仓库作为单一事实来源。使用像 Argo CD 或 Flux 这样的工具自动将集群状态与 Git 同步。

原因: GitOps 提供了所有更改清晰、可审计的历史记录，并通过回滚 Git 提交实现轻松回滚。它将基础设施即代码操作化。

以可重用和版本化的方式打包、配置和部署复杂的 Kubernetes 应用程序。

→使用 `Helm`，Kubernetes 的包管理器。将应用程序打包为 `Charts`，包含模板化的 manifests 和可配置的 `values.yaml` 文件。

原因: Helm 简化了具有许多组件的复杂应用程序的管理，处理依赖项、版本控制和生命周期管理。

无需使用模板即可为不同环境自定义 Kubernetes manifests。

→使用 `Kustomize`。定义一个 `kustomization.yaml` 文件，指定基础配置并为每个环境应用补丁或覆盖。

原因: Kustomize 提供了一种声明式、无模板的方式来管理配置变体，这比基于文本的模板更简单且不易出错。

在全面发布之前，使用一小部分生产流量测试新应用程序版本。

→将新版本与旧版本并排部署。使用服务网格或 Ingress 控制器将一小部分流量（例如 5%）路由到新的“金丝雀”版本。

原因: 金丝雀发布通过限制影响范围并允许生产测试，降低了引入不良版本的风险。

部署新应用程序版本，实现零停机和即时回滚能力。

→将新的“绿色”版本与现有“蓝色”版本并排部署。一旦绿色版本通过验证，在 Service/路由器级别将 100% 的流量从蓝色切换到绿色。

原因: 蓝绿部署消除了停机时间。回滚就像将流量切换回蓝色环境一样简单。

将复杂应用程序设计为一系列小型、独立且松耦合的服务。

→将应用程序结构化为微服务，每个微服务围绕一个业务能力组织。每个服务应拥有自己的数据并通过明确定义的 API 进行通信。

原因: 这种架构支持服务的独立开发、部署和扩缩，提高了敏捷性和弹性。

遵循既定的最佳实践构建可移植、可伸缩的云原生应用程序。

→遵循 Twelve-Factor App 方法论。一个关键原则是将所有在不同环境之间变化的配置存储在环境变量中。

原因: 这严格地将配置与代码分离，允许相同的容器镜像在不同环境中推广而无需更改。

参考↗

管理复杂的服务间通信，提供流量管理、安全和可观测性。

→实施服务网格（例如 Istio、Linkerd）。它向每个 Pod 注入一个 Sidecar 代理，以拦截和管理所有网络流量。

原因: 服务网格将网络问题（mTLS、重试、熔断）从应用程序代码中抽象出来，并在平台级别强制执行。

在不修改应用程序容器代码的情况下，扩展或增强其功能。

→在与主应用程序相同的 Pod 中部署一个“Sidecar”容器。它共享相同的网络和存储。

原因: Sidecar 用于横切关注点，如日志记录、监控或代理（如在服务网格中），促进关注点分离。

深入了解分布式系统的行为，以便于故障排除。

→实施可观测性的三大支柱：`Metrics`（聚合数值数据）、`Logs`（离散事件）和 `Traces`（端到端请求流）。

原因: 这些数据类型共同提供了系统健康和性能的全面视图，这对于复杂的微服务架构至关重要。