单位
1. DevOps 和云 AI 简介：角色、边界、身份验证、安全性和秘密 2. 使用人工智能设计 CI/CD 管道：GitHub Actions 和 GitLab CI 3. 将基础设施管理为代码：使用 Terraform 和 IaC 的人工智能 4. 容器化：Dockerfile 和人工智能图像优化 5. Kubernetes：Manifest、Helm 和 AI 驱动的编排 6. 监控和可观察性：指标、日志、跟踪和警报规则 7. 事件管理和事后分析：利用人工智能进行根本原因分析 8. 云成本优化 (FinOps)：利用人工智能寻找浪费 9. 脚本和自动化生成：Bash、Python 和 PowerShell 10. 安全和秘密管理：DevSecOps 和人工智能 11. 产品验证、发布策略和端到端人工智能工作流程
单位 5 / 11

Kubernetes：Manifest、Helm 和 AI 驱动的编排

收益：

  • 能够理解 Kubernetes 的基本对象（Pod、Deployment、Service、ConfigMap、Secret、Namespace）和声明性哲学，并为人工智能生成可靠的清单
  • 能够使清单做好生产准备，并通过资源限制、运行状况检查（探针）、固定图像标签和窄 RBAC 来确保安全
  • 能够在执行之前验证正确的上下文，并通过试运行/差异应用试运行规则

运行一个容器很容易。但是建立一个系统，将数百个容器分布在数十台服务器上，当其中一台服务器崩溃时自动重新启动，在负载增加时复制它，并以零停机时间更新它？这就是编排，行业标准工具是 Kubernetes（简称 K8s）——跨集群自动部署、扩展和管理容器的平台。 Kubernetes 强大但复杂：一切都是由长的、对缩进敏感的 YAML 文件（称为清单）定义的。这就是人工智能带来新鲜空气的地方；通过正确的上下文，它可以快速生成这些清单并解码其神秘错误。

但在 Kubernetes 中，错误的清单意味着无法支持整个服务、无法正确扩展或留下漏洞。您有责任理解和验证 AI 生成的每个清单 - 特别是在 kubectl 应用之前。

Kubernetes 核心对象

要审计 Kubernetes，您应该了解主要概念：

  • Pod：最小的工作单元；它包含一个或多个容器。一般情况下，Pod不直接使用，而是使用管理它的父对象。
  • 部署：定义应用程序将运行多少个副本、将使用哪个映像以及如何更新。如果 Pod 崩溃，它会自动重新创建它。
  • Service：为Pod提供固定的网络地址和负载均衡；即使 Pod 来来去去，访问地址也不会改变。
  • ConfigMap 和 Secret：将配置值和秘密信息与 Pod 分开。 ConfigMap 用于显式设置，Secret 用于敏感值。
  • 命名空间：逻辑上划分和隔离资源（例如 dev、prod）的区域。
  • Ingress：将来自外界的 HTTP 流量引导至集群中的服务的规则集。

Helm 是 Kubernetes 的“包管理器”：它允许您模板化重复出现的清单（图表），并使用单个命令在不同的环境中使用不同的值安装它们。 AI 会生成原始清单和 Helm 图表。

为什么有这么多物体？因为 Kubernetes 的核心理念是声明性的：您定义“您希望系统最终的外观”（例如“始终运行该应用程序的 3 个副本”），而 Kubernetes 不断使当前状态更接近所需状态。如果一个 Pod 死亡，它会创建一个新的 Pod；如果一个节点出现故障，它会将工作负载转移到另一个节点。这就是为什么清单不是“执行”命令，而是“让它像这样”的食谱。在阅读人工智能产生的清单时，掌握这种区别至关重要：每个域都描述了系统所需状态的一部分。错误的领域意味着 Kubernetes 正在朝着错误的目标努力——而这个目标是默默地、持续地执行的。

提示：在 Kubernetes 中，最重要的安全测试工具是 kubectl apply --dry-run=server -f file.yaml：它显示服务器是否会接受以及在不实际应用清单的情况下做什么。在将清单应用到产品之前，请务必运行 dry-run 和 kubectl diff。

一步一步：使用 AI 创建清单

  1. 描述应用和需求。镜像名称、端口、副本数量、资源限制（CPU/内存）。
  2. 请求部署+服务。通常两者都需要一起使用。
  3. 单独的配置和秘密。设置为ConfigMap，敏感值为Secret。
  4. 添加健康检查。 livenessProbe（是否处于活动状态）和 readinessProbe（是否已准备好流量）至关重要。
  5. 设置资源限制。如果没有请求/限制，Pod 可以消耗整个节点。
  6. 使用“--dry-run”和“diff”进行验证，然后应用。首先在测试命名空间中。

安全性：Kubernetes 特定的风险

  1. Secret 并不是真正的秘密——它只是 Base64。 Kubernetes Secret 对象以 base64 编码值；这不是加密，很容易解密。为了真正的隐私，需要 etcd 加密和外部保管库（Vault、云秘密管理器）。切勿将秘密清单直接提交到 Git（有解决方案，例如密封秘密/外部秘密）。
  2. 设置资源限制。没有限制的 Pod 可能会因内存泄漏而导致整个节点崩溃。
  3. 最小权限 (RBAC)。通过基于角色的访问控制，每个服务/用户仅拥有其所需的权限。 AI有时会提供大型集群管理；缩小范围。
  4. 不要使用“最新”图像标签。您不知道正在运行哪个版本，也无法将其回滚。
注意：kubectl delete 或不正确的应用可能会破坏实时部署。在运行命令之前，请务必验证您所在的命名空间（kubectl config current-context）；意外工作是生产环境中常见的灾难。

原始清单与 Helm 表

标准

原始 YAML 清单

舵图

安装

kubectl 应用-f

舵安装

多媒体（开发/产品）

复制粘贴，容易出错

单个图表，不同的值.yaml

版本/回滚

用手

很容易使用 helm 回滚

学习曲线

低

中等

当

环境狭小、单一

多媒体、重复性服务

三个迷你箱子

案例 1 — 崩溃服务的秘密。 Pod 不断重新启动 (CrashLoopBackOff)。团队将日志和清单提供给人工智能； AI 显示 Pod 从未被视为“就绪”，因为 readinessProbe 正在查看错误的端口。他们修复了端口，10分钟后服务就稳定了。手动建立这种关系可能需要几个小时。

案例2——不设定限制就破裂了。部署没有限制；内存泄漏导致 Pod 膨胀并使整个节点崩溃，同时也导致邻近的服务瘫痪。事件发生后，他们让 AI 说“为所有部署添加合理的 CPU/内存请求和限制”并使其成为标准。一根线路缺失就会造成数小时的停机时间。

案例 3 — 捕获大型 RBAC。在调查过程中，发现 AI 生成的 ServiceAccount 清单与集群管理员角色相关，这意味着该服务可以管理整个集群。该团队将权限缩小为仅读取其命名空间中的 Pod。最小特权原则消除了安全漏洞。

四个可复制模板

1）部署+服务生产：

为 Kubernetes 编写部署和服务清单。应用程序：[AD]，映像：[映像：固定版本]，端口：[X]，副本：[N]。规则：- 添加 CPU/内存请求和限制。- 定义 livenessProbe 和 readinessProbe。- 从 ConfigMap 读取配置，从 Secret 对象读取机密； 不要在清单中嵌入值，使用占位符。 - 不要使用图像标签“：最新”。给出描述。

2）明显错误解决：

当前 Pod 处于 [CrashLoopBackOff / Pending / ImagePullBackOff] 状态。根据以下清单和“kubectl描述”输出，按概率顺序列出可能的根本原因，并对每个问题发出验证命令。清单：[YAML] 描述：[输出]

3）安全/完整性检查：

检查这个 Kubernetes 清单：是否缺少资源限制、是否缺少问题、是否有 :latest 标签、是否存在过于广泛的 RBAC/权限、秘密是否嵌入在清单中？按重要性顺序写下调查结果并进行更正。清单：[YAML]

4) 转换为 Helm 图表：

将以下原始清单转换为可重用的 Helm 图表：哪些值应输出到 value.yaml（图像、副本、源、环境）？显示图表结构和示例值.yaml.Manifests：[YAML]

弱提示/强提示

弱：“为我的应用程序编写 Kubernetes YAML。”

结果：带有 :latest 标签的无探测、无限制部署，嵌入秘密平原；产品中不安全且脆弱。

Strong：“编写 Kubernetes 部署 + 服务。镜像 myapp:1.4.2，3 个副本，8080 个端口。CPU 100m-500m，内存 128Mi-512Mi 添加请求/限制。将 liveness 探针设置为 /healthz，将 readiness 探针设置为 /ready。从 Secret 对象中读取 Secret，不要将其嵌入到清单中。给出描述。”

区别：第二个提示版本给出了规模、资源限制、健康检查和秘密规则；产量接近生产且安全。

常见错误

  • 不设置资源限制。单个 Pod 可以消耗整个节点。
  • 不添加健康检查（探针）。 Kubernetes 无法检测到崩溃/未就绪的 Pod。
  • `:latest` 标签。不清楚正在运行哪个版本，无法回滚。
  • 将秘密直接提交给 Git。 Base64不是加密；每个人都解决它。
  • 在错误的上下文/命名空间中运行命令。产品中最常见的崩溃方式。
  • 跳过 `--dry-run`/`diff`。不知道实施之前会发生什么。

综上所述

Kubernetes 是一个强大但复杂的编排器，可以跨集群自动部署、扩展和优化容器；一切都由 Helm 模板化的清单 YAML 定义。 AI 快速生成部署/服务清单和 Helm 图表，解决神秘的错误 - 但您必须明确要求资源限制、运行状况检查、不可变的图像标签、狭窄的 RBAC 和秘密安全规则。 --dry-run、diff 和正确的上下文检查是防止产品崩溃的习惯。

应用任务

让 AI 使用“部署 + 服务生成”模板为示例应用程序生成清单。然后： (1) 使用“安全/健全性检查”模板检查资源限制、探测、:最新和机密； (2) 如果可能的话，在测试集群/minikube 上运行 kubectl apply --dry-run=server 并读取输出； (3) 记下您发现缺少的两个最关键的安全/稳健性项目。

清单

  • [ ] 我在请求中添加了镜像版本、副本数量、端口和资源限制。
  • [ ] 我在清单中添加了活性和就绪探针。
  • [ ] 修复图像标签；我没有使用：最新。
  • [ ] Secret 未嵌入清单中；我使用了秘密对象/外部保险库。
  • [ ] 我将 RBAC/权限范围缩小到最小权限。
  • [ ] 在申请之前，我验证了我处于正确的上下文中并且 --dry-run/diff 输出。
上一页 下一页