kubernetes-deployment

Kubernetes 部署

此技能可让 Agent 在 Kubernetes 集群上部署和管理应用程序。Agent 可以生成部署清单、服务、Ingress 规则、Helm chart 和自动扩缩容配置。它负责从初始部署到扩缩容、滚动更新和故障排查的完整生命周期，并遵循资源管理、安全性和可靠性方面的生产最佳实践。

工作流

1. **配置集群访问：**Agent 会验证 kubectl 是否已配置正确的集群上下文和命名空间。它会使用 kubectl cluster-info 检查连接，并确认用户具有在目标命名空间中创建和管理资源所需的 RBAC 权限。如果不存在 kubeconfig，Agent 会指导用户完成身份验证（例如，aws eks update-kubeconfig、gcloud container clusters get-credentials）。

2. **定义部署清单：**Agent 会创建 Kubernetes 部署清单，指定容器镜像、副本数、资源请求和限制、环境变量、存活和就绪探针，以及 Pod 反亲和规则。它会统一应用标签和注解，以支持服务发现、监控和运维。Agent 使用特定的镜像标签（绝不使用 latest），并适当设置 imagePullPolicy。

3. **配置服务和 Ingress：**Agent 会创建 Service 资源，将部署暴露在集群内部（ClusterIP）或外部（LoadBalancer、NodePort）。对于 HTTP 工作负载，Agent 会配置 Ingress 资源，使用 cert-manager 终止 TLS、按路径路由并添加速率限制注解。Agent 会根据部署环境和流量要求选择适当的服务类型。

4. **应用清单并验证发布：**Agent 使用 kubectl apply -f 应用清单，并通过 kubectl rollout status 监控发布。它会验证所有 Pod 是否进入 Running 状态、健康检查是否通过，以及服务端点是否已注册。如果发布停滞，Agent 会使用 kubectl describe pod 检查 Pod 事件，并通过 kubectl logs 查看日志以诊断问题；还可以执行 kubectl rollout undo 回退到先前版本。

5. **配置自动扩缩容：**Agent 会设置 Horizontal Pod Autoscaler（HPA），根据 CPU 利用率、内存使用量或自定义指标调整副本数。它会定义最小和最大副本数、扩容和缩容行为，以及用于防止频繁波动的稳定窗口。对于资源需求变化较大的工作负载，Agent 还可以配置 Vertical Pod Autoscaler（VPA）。

6. **使用 Helm chart 管理：**对于包含多个环境的复杂应用程序，Agent 会将 Kubernetes 清单打包为带有模板化值的 Helm chart。Helm 支持版本化发布、失败时自动回滚的原子升级，以及针对不同环境的值覆盖。Agent 使用 helm upgrade --install 实现幂等部署，并在应用更改前使用 helm diff 预览变更。

支持的技术

• **编排：**Kubernetes（EKS、GKE、AKS、自行管理）、k3s、kind、minikube
• **包管理：**Helm 3、Kustomize
• **自动扩缩容：**HPA、VPA、KEDA、Cluster Autoscaler
• **网络：**Nginx Ingress Controller、Traefik、Istio、Cilium
• **证书管理：**cert-manager、Let's Encrypt
• **CI/CD 集成：**ArgoCD、Flux、GitHub Actions、GitLab CI

用法

向 Agent 提供应用程序的容器镜像、资源需求、所需副本数以及目标 Kubernetes 集群的详细信息。

提示词示例：

Deploy my app to the production EKS cluster:
- Image: myregistry.io/myapp:v2.1.0
- 3 replicas with CPU/memory limits
- Liveness and readiness probes on /health
- Expose via Ingress at api.example.com with TLS
- HPA scaling between 3-10 replicas based on CPU

示例

示例 1：使用 Service 和 Ingress 进行生产部署

deployment.yaml：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
  namespace: production
  labels:
    app: myapp
    version: v2.1.0
spec:
  replicas: 3
  revisionHistoryLimit: 5
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
        version: v2.1.0
    spec:
      serviceAccountName: myapp
      terminationGracePeriodSeconds: 60
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
            - weight: 100
              podAffinityTerm:
                labelSelector:
                  matchExpressions:
                    - key: app
                      operator: In
                      values: [myapp]
                topologyKey: kubernetes.io/hostname
      containers:
        - name: myapp
          image: myregistry.io/myapp:v2.1.0
          ports:
            - containerPort: 3000
              name: http
          env:
            - name: NODE_ENV
              value: "production"
            - name: DATABASE_URL
              valueFrom:
                secretKeyRef:
                  name: myapp-secrets
                  key: database-url
          resources:
            requests:
              cpu: 250m
              memory: 256Mi
            limits:
              cpu: "1"
              memory: 512Mi
          livenessProbe:
            httpGet:
              path: /health
              port: http
            initialDelaySeconds: 30
            periodSeconds: 10
            timeoutSeconds: 5
            failureThreshold: 3
          readinessProbe:
            httpGet:
              path: /health
              port: http
            initialDelaySeconds: 5
            periodSeconds: 5
            timeoutSeconds: 3
            failureThreshold: 3
          lifecycle:
            preStop:
              exec:
                command: ["/bin/sh", "-c", "sleep 15"]

service.yaml：

apiVersion: v1
kind: Service
metadata:
  name: myapp
  namespace: production
spec:
  selector:
    app: myapp
  ports:
    - protocol: TCP
      port: 80
      targetPort: http
  type: ClusterIP

ingress.yaml：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapp
  namespace: production
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
    nginx.ingress.kubernetes.io/rate-limit: "100"
spec:
  ingressClassName: nginx
  tls:
    - hosts:
        - api.example.com
      secretName: myapp-tls
  rules:
    - host: api.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: myapp
                port:
                  number: 80

示例 2：使用 Helm 部署 Horizontal Pod Autoscaler

使用自定义值通过 Helm 安装或升级：

helm upgrade --install myapp ./charts/myapp \
  --namespace production \
  --set image.tag=v2.1.0 \
  --set replicaCount=3 \
  --set autoscaling.enabled=true \
  --values values-production.yaml \
  --wait --timeout 5m \
  --atomic

hpa.yaml — Horizontal Pod Autoscaler：

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: myapp
  namespace: production
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: myapp
  minReplicas: 3
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70
    - type: Resource
      resource:
        name: memory
        target:
          type: Utilization
          averageUtilization: 80
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 60
      policies:
        - type: Percent
          value: 50
          periodSeconds: 60
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
        - type: Percent
          value: 25
          periodSeconds: 120

部署步骤：

1. kubectl create namespace production（如果该命名空间不存在）
2. kubectl apply -f deployment.yaml -f service.yaml -f ingress.yaml
3. kubectl apply -f hpa.yaml
4. kubectl rollout status deployment/myapp -n production
5. kubectl get hpa myapp -n production，以验证自动扩缩器目标

最佳实践

• 始终设置资源请求和限制： 每个容器都应定义 CPU 和内存请求（用于调度）以及限制（用于防止邻近负载争用资源）。如果没有请求，调度器就无法做出合理的放置决策；如果没有限制，单个 Pod 就可能耗尽节点上的所有资源。
• 配置存活探针和就绪探针： 存活探针允许 Kubernetes 重启卡住或陷入死锁的容器。就绪探针可防止流量被路由到尚未准备好处理请求的 Pod。设置合适的 initialDelaySeconds，以避免在启动期间终止 Pod。
• 使用命名空间实现隔离： 将不同环境（dev、staging、production）和团队划分到不同的命名空间中。为每个命名空间应用 ResourceQuotas 和 LimitRanges，防止任何单个团队或环境消耗过多的集群资源。
• 遵循最小权限原则实施 RBAC： 为每个应用创建权限最少的服务账号。避免使用 default 服务账号，或向工作负载授予 cluster-admin 权限。尽可能使用作用域限定在命名空间内的 Roles 和 RoleBindings，而不是 ClusterRoles。
• 使用 Helm 实现可重复部署： Helm chart 将清单与模板化值打包，从而支持在不同环境中进行一致的部署。使用 --atomic 在失败时自动回滚，并使用 --wait 等待资源达到健康状态。
• 设置 Pod 中断预算： 定义 PodDisruptionBudgets（PDB），确保在节点排空和集群升级等自愿中断期间，至少有一定数量的副本保持可用。例如，minAvailable: 2 可确保始终至少有 2 个 Pod 正在运行。

边缘情况

• CrashLoopBackOff： Pod 反复崩溃，Kubernetes 会在每次重启尝试之间应用指数退避延迟。使用 kubectl logs <pod> --previous 查看崩溃输出，并使用 kubectl describe pod <pod> 查看事件。常见原因包括环境变量配置错误、缺少密钥或数据库连接失败。
• ImagePullBackOff： 容器运行时无法拉取指定的镜像。这可能是因为镜像标签不存在、镜像仓库需要身份验证，或存在网络问题。使用 docker pull 验证镜像是否存在，检查 Pod 规格中的 imagePullSecrets，并确保节点可以访问镜像仓库。
• 节点压力下驱逐 Pod： 节点内存或磁盘不足时，kubelet 会优先驱逐资源使用量超出请求值的 Pod（先驱逐 BestEffort Pod，再驱逐 Burstable Pod）。设置适当的资源请求，确保关键 Pod 被归类为 Guaranteed QoS 类别，从而最后被驱逐。
• 发布停滞和期限： 如果新 Pod 未通过就绪检查，部署发布可能会停滞。默认的 progressDeadlineSeconds 为 600 秒，超时后 Kubernetes 会将发布标记为失败。使用 kubectl rollout undo deployment/myapp 立即回滚，而不是等待期限到期。
• 新命名空间中的 DNS 解析失败： 如果 CoreDNS 尚未更新其内部记录，新建命名空间中的 Pod 可能会暂时遇到 DNS 解析失败。应用容器应在初始服务发现调用时实现带退避的重试逻辑。
• Helm 发布冲突： 如果先前的 helm upgrade 被中断（例如，由于超时），发布可能处于 pending-upgrade 或 failed 状态。使用 helm history myapp 检查状态，并使用 helm rollback myapp <revision> 恢复，然后再尝试升级。