手册

从命令行键值对创建 ConfigMap 或通用 Secret。

→使用 `kubectl create configmap <name> --from-literal=<key>=<value>` 或 `kubectl create secret generic <name> --from-literal=<key>=<value>`。

原因: `--from-literal` 用于直接的键值输入。对于多个键，可以多次使用此标志。这比为简单情况创建 YAML 文件更快。

参考↗

将 ConfigMap 或 Secret 中的所有键值对作为环境变量注入容器。

→在容器规范中，使用 `envFrom` 和 `configMapRef` 或 `secretRef`。示例：`envFrom: [{configMapRef: {name: my-config}}]`。

原因: `envFrom` 是一种批量操作，将源中的所有键映射到环境变量。这避免了手动列出每个键。

参考↗

将 ConfigMap 或 Secret 中的单个特定值作为环境变量注入。

→使用 `env.valueFrom`。示例：`env: [{name: LOG_LEVEL, valueFrom: {configMapKeyRef: {name: my-config, key: log_level}}}]`。

原因: `valueFrom` 提供选择性注入，并允许将源键映射到不同的环境变量名。

将 ConfigMap 或 Secret 作为文件挂载到 Pod 中，允许实时更新。

→定义 `configMap` 或 `secret` 类型的 `volume`。使用 `volumeMounts` 将其挂载到容器中。文件将以键命名。

原因: 当源发生变化时，从 ConfigMap/Secret 挂载的文件会自动更新。环境变量则不会，需要重启 Pod。

参考↗

强制执行安全最佳实践：防止以 root 身份运行，使根文件系统只读，或指定用户 ID。

→在 Pod 或容器级别使用 `securityContext`。设置 `runAsNonRoot: true`、`readOnlyRootFilesystem: true` 和/或 `runAsUser: <UID>`。

原因: SecurityContext 提供对容器权限的细粒度、声明式控制，对于强化应用程序和满足安全策略至关重要。

参考↗

授予 Pod 访问 Kubernetes API 的最小权限。

→1. 创建自定义 `ServiceAccount`。2. 创建一个只包含必要 API 权限（例如，列出 Pod）的 `Role`。3. 创建 `RoleBinding` 将 ServiceAccount 和 Role 关联起来。4. 通过 `spec.serviceAccountName` 将 ServiceAccount 分配给 Pod。

原因: 遵循最小权限原则，如果 Pod 被攻破，可最大程度地减少攻击面。

阻止 ServiceAccount 令牌自动挂载到不需要 API 访问的 Pod 中。

→在 Pod 规范或 ServiceAccount 本身中设置 `automountServiceAccountToken: false`。

原因: 通过不向不需要 API 凭据的容器提供凭据来减少攻击面。

创建用于 Ingress 或其他安全服务的 TLS 终止的 Secret。

→使用 `kubectl create secret tls <secret-name> --cert=<path/to/cert.pem> --key=<path/to/key.pem>`。

原因: 这将创建一个类型为 `kubernetes.io/tls` 的 Secret，其中包含 Ingress 控制器预期的标准 `tls.crt` 和 `tls.key` 数据键。

将 Pod 元数据（如名称、命名空间、标签或节点 IP）暴露给容器。

→使用 Downward API 将元数据作为环境变量或文件投射到 `downwardAPI` 卷中。示例：`valueFrom: {fieldRef: {fieldPath: metadata.name}}`。

原因: 允许容器在不需要查询 Kubernetes API 的情况下自我感知，从而简化配置并降低 RBAC 要求。

参考↗

为命名空间中的所有 Pod 设置默认的 CPU/内存请求和限制。

→在命名空间中创建 `LimitRange` 对象。为资源定义 `default` 和 `defaultRequest` 值。

原因: 确保所有 Pod 都有资源限制，即使开发人员忘记指定，也能提高调度和稳定性。与 ResourceQuota 协同工作。

限制命名空间中可以消耗的资源总量（CPU、内存、对象数量）。

→创建 `ResourceQuota` 对象。在 `spec.hard` 中定义硬限制，例如 `requests.cpu: "4"`，`pods: "10"`。

原因: 防止一个命名空间或团队消耗所有集群资源，确保公平的资源分配。

在主应用程序启动之前运行先决任务（例如，等待数据库、运行迁移、拉取数据）。

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

原因: 将设置逻辑与应用程序容器解耦，并确保在应用程序启动之前满足依赖关系。

参考↗

通过日志、监控或代理等辅助功能扩展主应用程序容器。

→在 Pod 规范中添加第二个容器（即 sidecar）。两个容器共享网络和卷等资源。

原因: 在不修改主应用程序代码的情况下增强功能，促进关注点分离。

在同一 Pod 中的容器之间共享一个目录用于读写。

→在 Pod 规范中定义一个 `emptyDir` 卷，并将其挂载到所有必需的容器中。

原因: `emptyDir` 提供了一个简单的、短暂的存储卷，它与 Pod 的生命周期一致，非常适合 Pod 内部数据共享。

覆盖容器镜像的默认 ENTRYPOINT 和/或 CMD。

→在容器规范中，使用 `command` 覆盖 ENTRYPOINT，使用 `args` 覆盖 CMD。`command: ["/bin/sh"], args: ["-c", "echo hello"]`。

原因: 从 Pod 定义中完全控制容器启动命令，这对于适配通用镜像非常有用。

运行有限任务直至完成，控制并行度和成功完成的数量。

→使用 `Job` 资源。设置 `spec.completions` 用于目标成功计数，设置 `spec.parallelism` 用于并发 Pod 的数量。使用 `spec.backoffLimit` 控制重试。

原因: Job 专为运行到完成的任务而设计，与长时间运行的 Deployment 不同。这些设置是管理批处理工作负载的关键。

使用 cron 语法调度重复任务，并控制如何处理重叠的 Job。

→使用 `CronJob` 资源。以 cron 格式定义 `spec.schedule`（例如，`*/5 * * * *`）。将 `spec.concurrencyPolicy` 设置为 `Allow`、`Forbid` 或 `Replace`。

原因: 自动化计划任务。`concurrencyPolicy` 对于防止重叠运行 (`Forbid`) 或替换过期任务 (`Replace`) 至关重要。

快速生成资源的 YAML 清单，而不在集群中创建它。

→对命令式命令使用 `--dry-run=client -o yaml` 标志。示例：`kubectl run nginx --image=nginx --dry-run=client -o yaml > pod.yaml`。

原因: 通过搭建可自定义并声明式应用的有效清单来节省时间。

命令式地更新、扩缩、检查状态、查看历史和回滚 Deployment。

→使用 `kubectl set image`、`kubectl scale`、`kubectl rollout status`、`kubectl rollout history` 和 `kubectl rollout undo`。

原因: 这些是开发和故障排除期间管理已部署应用程序生命周期的核心命令式命令。

控制 Deployment 更新的速度和安全性以确保可用性。

→在 `spec.strategy.rollingUpdate` 中，配置 `maxSurge`（可以创建多少额外 Pod）和 `maxUnavailable`（可以有多少 Pod 处于不可用状态）。

原因: 平衡 `maxSurge` 和 `maxUnavailable` 是在更新期间管理容量与资源使用情况的关键。为了实现零停机，`maxUnavailable` 必须小于 `replicas`。

通过在创建新 Pod 之前终止所有旧 Pod，确保应用程序的两个版本不会同时运行。

→在 Deployment 中设置 `spec.strategy.type: Recreate`。

原因: 保证旧版本和新版本不共存，这对于无法处理两个不同版本访问相同数据的应用程序是必需的。此策略会导致停机。

对实时 Deployment 进行多次更改，而无需为每个更改触发中间的滚动更新。

→使用 `kubectl rollout pause deployment/<name>`，应用更改，然后使用 `kubectl rollout resume deployment/<name>`。

原因: 将多个更新整合到一个滚动更新事件中，防止不必要的变动和竞态条件。

限制为 Deployment 保留的旧 ReplicaSet 数量，以节省 etcd 存储。

→将 `spec.revisionHistoryLimit` 设置为要保留的修订版数量（例如，3）。默认值为 10。

原因: 设置较低的限制可减少 etcd 的混乱。设置为 `0` 则完全禁用回滚功能。

记录 Deployment 更新的原因，使其显示在修订历史中。

→在 Deployment 清单中添加 `kubernetes.io/change-cause` 注解。示例：`kubectl annotate deployment/nginx kubernetes.io/change-cause="update to 1.20"`。

原因: 在查看滚动更新历史 (`kubectl rollout history`) 时提供有价值的上下文，使其更容易识别要回滚到哪个修订版。

将新应用程序版本与旧版本并行部署，并即时切换流量以实现零停机。

→使用两个具有不同版本标签的 Deployment（例如，`app-blue`、`app-green`）。单个 Service 通过其 `selector` 选择活动版本。要切换，请 `kubectl patch service` 更新选择器到新版本标签。

原因: 通过简单地将 Service 选择器打补丁回原始版本，提供即时、低风险的发布和即时回滚能力。

将一小部分流量路由到新的应用程序版本，以便在生产环境中进行测试。

→使用两个共享相同选择器标签的 Deployment（稳定版、金丝雀版）。一个 Service 目标两者。通过副本比例控制流量百分比（例如，9 个稳定版副本，1 个金丝雀版副本用于 10% 流量）。

原因: 一种无需服务网格即可执行金丝雀发布的简单方法，允许对新功能进行受控、低风险的测试。流量分布是近似的。

仅从集群内部暴露一组 Pod 以进行通信。

→使用 `type: ClusterIP` 的 Service。这是默认类型。

原因: `ClusterIP` 为服务提供一个稳定的内部 IP 地址和 DNS 名称，抽象出单个 Pod IP。

在每个节点的 IP 地址上通过静态端口暴露服务。

→使用 `type: NodePort` 的 Service。K8s 会从一个范围（默认：30000-32767）中分配一个端口。

原因: 适用于开发或没有外部负载均衡器的情况。流向 `<NodeIP>:<NodePort>` 的流量将被转发到 Service。

根据主机名或 URL 路径，将外部 HTTP/S 流量路由到内部服务。

→创建 `Ingress` 资源。定义主机的 `rules` 和 `http.paths` 以映射到后端服务。使用 `spec.tls` 指向 TLS Secret 来配置 TLS。

原因: Ingress 提供 L7 路由，将多个服务整合到一个外部 IP 下，并卸载 TLS 终止。

根据标签、命名空间或 IP 块限制 Pod 的网络流量。

→创建 `NetworkPolicy`，使用 `podSelector` 定位 Pod。定义 `ingress` 和/或 `egress` 规则以允许特定流量。默认情况下，将策略应用于 Pod 会拒绝所有未明确允许的流量。

原因: NetworkPolicy 是 Kubernetes 中网络分段和实现零信任安全模型的基础。

参考↗

默认情况下，阻止命名空间中所有 Pod 的所有入站和出站流量。

→创建 `NetworkPolicy`，其中 `podSelector: {}` 为空，并且入站/出站规则为空。示例：`podSelector: {}, policyTypes: [Ingress, Egress]`。

原因: 建立一个安全基线，其中所有流量都被拒绝，除非通过其他更具体的 NetworkPolicy 明确允许。

提供一个稳定的 DNS 条目，直接解析到所有 Pod IP，而无需用于负载均衡的虚拟 IP。

→创建 `spec.clusterIP: None` 的 Service。

原因: 对于有状态应用程序（如 StatefulSet）或需要直接发现和与特定 Pod 通信的对等系统至关重要。

确保后端 Pod 能够看到来自 NodePort 或 LoadBalancer Service 的流量的原始客户端 IP。

→在 Service 上设置 `spec.externalTrafficPolicy: Local`。

原因: 默认的 (`Cluster`) 策略通过网络地址转换混淆源 IP。`Local` 策略会保留它，但如果 Pod 不在所有节点上，可能导致流量分布不均。

确保来自特定客户端的所有请求都发送到同一个 Pod。

→在 Service 上，设置 `spec.sessionAffinity: ClientIP`。

原因: 提供“粘性会话”，这对于在特定 Pod 内存中存储会话状态的传统应用程序是必需的。

一个命名空间中的 Pod 需要与另一个命名空间中的 Service 进行通信。

→使用扩展的 DNS 名称：`<service-name>.<namespace-name>.svc.cluster.local` 或短形式 `<service-name>.<namespace-name>`。

原因: 简单的服务名称只能在同一个命名空间内解析。跨命名空间通信需要在 DNS 查询中指定目标命名空间。

定义健康检查以管理 Pod 生命周期：失败时重启与从服务中移除。

→`livenessProbe`：如果探测失败，则重启容器。`readinessProbe`：如果探测失败，则将 Pod 从 Service 端点中移除。`startupProbe`：禁用其他探测，直到容器完成其启动。

原因: 正确配置的探测对于应用程序的自我修复和实现零停机部署至关重要。

参考↗

诊断 Pod 为什么卡在非运行状态（例如，Pending、ContainerCreating、CrashLoopBackOff）。

→使用 `kubectl describe pod <pod-name>`。`Events` 部分提供了来自调度器（资源问题）、kubelet（镜像拉取错误）或容器运行时的关键线索。

原因: `describe` 是理解在应用程序启动或记录任何日志之前发生的 Pod 生命周期问题的最重要命令。

检查已崩溃并处于重启循环（CrashLoopBackOff）的容器的日志。

→使用 `kubectl logs <pod-name> --previous`。

原因: `--previous` 标志显示容器上次终止实例的日志，其中包含导致崩溃的错误。

实时查看和跟踪与标签选择器匹配的所有 Pod 的日志。

→使用 `kubectl logs -l <label-selector> -f`。添加 `--prefix` 以查看每行日志来自哪个 Pod。

原因: 聚合分布式应用程序的日志，提供其行为的统一视图。

在运行中的容器内执行命令或获取交互式 shell 以进行调试。

→使用 `kubectl exec -it <pod-name> -- /bin/sh`（或 `/bin/bash`）。`--` 用于将 kubectl 标志与命令分开。

原因: 提供对容器环境的直接访问，用于实时调试、检查文件或检查网络连接。

查看运行中的 Pod 当前的 CPU 和内存消耗。

→使用 `kubectl top pod <pod-name>`。使用 `--containers` 查看 Pod 中每个容器的使用情况。

原因: 需要安装 Metrics Server。这对于识别资源密集型应用程序、内存泄漏或 CPU 瓶颈至关重要。

调试缺少 shell 或调试工具的运行中容器。

→使用 `kubectl debug <pod-name> -it --image=busybox --share-processes --copy-to=debug-pod`。这会创建一个新 Pod，其中包含一个共享相同进程命名空间的调试容器。

原因: `kubectl debug` 是将带有调试工具的临时“临时容器”（ephemeral container）附加到运行中的 Pod 的现代方法，而无需修改原始 Pod 规范。