gao/ljwx-k8s

Fork 0

Files

T

bruno 2a56d7fd6c first commit

2026-02-20 22:50:45 +08:00

25 KiB

Raw Permalink Blame History

Kubernetes 集群优化执行计划

创建时间: 2025-12-30 执行周期: 4 周预计总工时: 约 20 小时目标: 从企业级良好 (⭐⭐⭐⭐) 提升到企业级卓越 (⭐⭐⭐⭐⭐)

📋 总览

优化范围

P0 关键修复: 5 项 (必须立即完成)
P1 高优先级: 4 项 (本周完成)
P2 中优先级: 5 项 (2周内完成)
P3 低优先级: 4 项 (4周内完成)

预期成果

✅ HPA 自动弹性伸缩恢复工作
✅ 关键服务高可用 (2-3副本)
✅ 资源利用率提升 2-3 倍
✅ 存储成本降低 30-50%
✅ 集群完整备份能力
✅ 自动化安全扫描
✅ 零信任网络架构

第 1 天 - P0 关键修复 (2 小时)

任务 1: 修复 HPA Metrics 收集问题 ⚠️ 【最高优先级】

问题: 所有 6 个 HPA 显示 cpu: <unknown>/70%，无法自动扩缩容

执行步骤:

# === 步骤 1: 诊断问题 ===

# 1.1 验证 metrics-server 工作正常
kubectl get deployment metrics-server -n kube-system
kubectl get apiservice v1beta1.metrics.k8s.io
kubectl logs -n kube-system deployment/metrics-server --tail=50

# 1.2 检查各个 HPA 目标
kubectl get hpa --all-namespaces -o wide

# 1.3 检查目标 Deployment 的 resource requests
echo "=== Checking Prometheus ==="
kubectl get deployment prometheus -n monitoring -o jsonpath='{.spec.template.spec.containers[0].resources}' | jq .

echo "=== Checking Grafana ==="
kubectl get deployment grafana -n monitoring -o jsonpath='{.spec.template.spec.containers[0].resources}' | jq .

echo "=== Checking ArgoCD Server ==="
kubectl get deployment argocd-server -n argocd -o jsonpath='{.spec.template.spec.containers[0].resources}' | jq .

echo "=== Checking Ingress NGINX ==="
kubectl get deployment ingress-nginx-controller -n infra -o jsonpath='{.spec.template.spec.containers[0].resources}' | jq .

echo "=== Checking Gitea Runner ==="
kubectl get deployment gitea-runner -n gitea-runner -o jsonpath='{.spec.template.spec.containers[0].resources}' | jq .

echo "=== Checking Stock Backend ==="
kubectl get deployment claude-stock-backend -n ljwx-stock -o jsonpath='{.spec.template.spec.containers[0].resources}' | jq .

# === 步骤 2: 修复问题 ===

# 2.1 为缺少 resource requests 的 Deployment 添加配置
# 创建补丁脚本
cat > /tmp/fix-hpa-resources.sh << 'SCRIPT'
#!/bin/bash

# 修复 Grafana
if ! kubectl get deployment grafana -n monitoring -o jsonpath='{.spec.template.spec.containers[0].resources.requests}' | grep -q "cpu"; then
  echo "Adding resource requests to Grafana..."
  kubectl patch deployment grafana -n monitoring --type='json' -p='[
    {
      "op": "add",
      "path": "/spec/template/spec/containers/0/resources/requests",
      "value": {"cpu": "100m", "memory": "128Mi"}
    }
  ]'
fi

# 修复 ArgoCD Server
if ! kubectl get deployment argocd-server -n argocd -o jsonpath='{.spec.template.spec.containers[0].resources.requests}' | grep -q "cpu"; then
  echo "Adding resource requests to ArgoCD Server..."
  kubectl patch deployment argocd-server -n argocd --type='json' -p='[
    {
      "op": "add",
      "path": "/spec/template/spec/containers/0/resources/requests",
      "value": {"cpu": "100m", "memory": "128Mi"}
    }
  ]'
fi

# 修复 Ingress NGINX
if ! kubectl get deployment ingress-nginx-controller -n infra -o jsonpath='{.spec.template.spec.containers[0].resources.requests}' | grep -q "cpu"; then
  echo "Adding resource requests to Ingress NGINX..."
  kubectl patch deployment ingress-nginx-controller -n infra --type='json' -p='[
    {
      "op": "add",
      "path": "/spec/template/spec/containers/0/resources/requests",
      "value": {"cpu": "100m", "memory": "128Mi"}
    }
  ]'
fi

# 修复 Gitea Runner
if ! kubectl get deployment gitea-runner -n gitea-runner -o jsonpath='{.spec.template.spec.containers[0].resources.requests}' | grep -q "cpu"; then
  echo "Adding resource requests to Gitea Runner..."
  kubectl patch deployment gitea-runner -n gitea-runner --type='json' -p='[
    {
      "op": "add",
      "path": "/spec/template/spec/containers/0/resources/requests",
      "value": {"cpu": "100m", "memory": "128Mi"}
    }
  ]'
fi

# 修复 Stock Backend
if ! kubectl get deployment claude-stock-backend -n ljwx-stock -o jsonpath='{.spec.template.spec.containers[0].resources.requests}' | grep -q "cpu"; then
  echo "Adding resource requests to Stock Backend..."
  kubectl patch deployment claude-stock-backend -n ljwx-stock --type='json' -p='[
    {
      "op": "add",
      "path": "/spec/template/spec/containers/0/resources/requests",
      "value": {"cpu": "100m", "memory": "128Mi"}
    }
  ]'
fi

echo "All resource requests added!"
SCRIPT

chmod +x /tmp/fix-hpa-resources.sh
/tmp/fix-hpa-resources.sh

# === 步骤 3: 等待 Pod 重启并验证 ===

echo "Waiting for Pods to restart..."
sleep 60

# 验证 metrics 可以正常收集
kubectl top pods -n monitoring
kubectl top pods -n argocd
kubectl top pods -n infra
kubectl top pods -n gitea-runner
kubectl top pods -n ljwx-stock

# === 步骤 4: 验证 HPA 工作正常 ===

echo "Checking HPA status..."
kubectl get hpa --all-namespaces

# 应该看到具体的 CPU 百分比，而不是 <unknown>
# 例如: cpu: 15%/70%

验证标准:

✅ kubectl get hpa --all-namespaces 显示具体的 CPU 百分比
✅ kubectl top pods 可以正常显示资源使用
✅ HPA events 中没有错误信息

预计时间: 30 分钟

任务 2: 补全缺失的监控配置

执行步骤:

# === 步骤 1: 检查现有配置 ===

# 列出所有 ServiceMonitor
echo "=== ServiceMonitors (应该有 16 个) ==="
kubectl get servicemonitor --all-namespaces
kubectl get servicemonitor --all-namespaces --no-headers | wc -l

# 列出所有 PrometheusRule
echo "=== PrometheusRules (应该有 34 个) ==="
kubectl get prometheusrule --all-namespaces
kubectl get prometheusrule --all-namespaces --no-headers | wc -l

# === 步骤 2: 对比文档找出缺失项 ===

# 文档中声明的 16 个 ServiceMonitor:
# 1. prometheus
# 2. grafana
# 3. alertmanager
# 4. kube-state-metrics
# 5. node-exporter
# 6. mysql-exporter
# 7. postgres-exporter
# 8. redis-exporter
# 9. loki
# 10. tempo
# 11. otel-collector
# 12. ingress-nginx
# 13. argocd-metrics
# 14. argocd-server-metrics
# 15. argocd-repo-server-metrics
# 16. cert-manager

# 检查每个 ServiceMonitor 是否存在
for sm in prometheus grafana alertmanager kube-state-metrics node-exporter \
           mysql-exporter postgres-exporter redis-exporter \
           loki tempo otel-collector ingress-nginx \
           argocd-metrics argocd-server-metrics argocd-repo-server-metrics cert-manager; do
  if kubectl get servicemonitor $sm --all-namespaces 2>/dev/null; then
    echo "✅ $sm exists"
  else
    echo "❌ $sm missing"
  fi
done

# === 步骤 3: 创建缺失的 ServiceMonitor ===

# 假设缺少 cert-manager 的 ServiceMonitor
cat > /tmp/cert-manager-servicemonitor.yaml << 'EOF'
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: cert-manager
  namespace: cert-manager
  labels:
    app: cert-manager
spec:
  selector:
    matchLabels:
      app: cert-manager
  endpoints:
  - port: tcp-prometheus-servicemonitor
    interval: 30s
    path: /metrics
EOF

# 应用配置（如果确实缺失）
# kubectl apply -f /tmp/cert-manager-servicemonitor.yaml

# === 步骤 4: 检查并补全 PrometheusRule ===

# 类似地检查 PrometheusRule
kubectl get prometheusrule --all-namespaces -o custom-columns=NAMESPACE:.metadata.namespace,NAME:.metadata.name

# 对比文档中的 34 条规则，找出缺失项

验证标准:

✅ kubectl get servicemonitor --all-namespaces | wc -l 显示 16
✅ kubectl get prometheusrule --all-namespaces | wc -l 显示 34
✅ Prometheus Targets 页面显示所有目标都是 UP 状态

预计时间: 15 分钟

第 1 天总结:

✅ HPA 恢复正常工作，可以自动扩缩容
✅ 监控覆盖 100% 完整
✅ 耗时: 约 45 分钟

第 2-3 天 - P1 高优先级优化 (4 小时)

任务 3: 部署 VPA (Vertical Pod Autoscaler)

目标: 自动优化 Pod 资源配置，减少 50-70% 资源浪费

执行步骤:

# === 步骤 1: 安装 VPA ===

cd /tmp
git clone https://github.com/kubernetes/autoscaler.git
cd autoscaler/vertical-pod-autoscaler

# 部署 VPA 组件
./hack/vpa-up.sh

# 验证部署
kubectl get deployment -n kube-system | grep vpa
# 应该看到:
# vpa-admission-controller
# vpa-recommender
# vpa-updater

# === 步骤 2: 为 Prometheus 创建 VPA ===

cat > /tmp/vpa-prometheus.yaml << 'EOF'
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: prometheus-vpa
  namespace: monitoring
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: prometheus
  updatePolicy:
    updateMode: "Auto"  # 自动更新资源配置
  resourcePolicy:
    containerPolicies:
    - containerName: prometheus
      minAllowed:
        cpu: 100m
        memory: 256Mi
      maxAllowed:
        cpu: 4
        memory: 8Gi
      controlledResources: ["cpu", "memory"]
EOF

kubectl apply -f /tmp/vpa-prometheus.yaml

# === 步骤 3: 为 Grafana 创建 VPA ===

cat > /tmp/vpa-grafana.yaml << 'EOF'
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: grafana-vpa
  namespace: monitoring
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: grafana
  updatePolicy:
    updateMode: "Auto"
  resourcePolicy:
    containerPolicies:
    - containerName: grafana
      minAllowed:
        cpu: 50m
        memory: 128Mi
      maxAllowed:
        cpu: 2
        memory: 4Gi
EOF

kubectl apply -f /tmp/vpa-grafana.yaml

# === 步骤 4: 为数据库创建 VPA (Initial 模式，避免频繁重启) ===

# MySQL VPA
cat > /tmp/vpa-mysql.yaml << 'EOF'
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: mysql-vpa
  namespace: infra
spec:
  targetRef:
    apiVersion: apps/v1
    kind: StatefulSet
    name: mysql
  updatePolicy:
    updateMode: "Initial"  # 仅在 Pod 创建时设置，避免重启
  resourcePolicy:
    containerPolicies:
    - containerName: mysql
      minAllowed:
        cpu: 100m
        memory: 512Mi
      maxAllowed:
        cpu: 4
        memory: 8Gi
EOF

kubectl apply -f /tmp/vpa-mysql.yaml

# PostgreSQL VPA
cat > /tmp/vpa-postgres.yaml << 'EOF'
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: postgres-vpa
  namespace: data
spec:
  targetRef:
    apiVersion: apps/v1
    kind: StatefulSet
    name: postgresql
  updatePolicy:
    updateMode: "Initial"
  resourcePolicy:
    containerPolicies:
    - containerName: postgresql
      minAllowed:
        cpu: 100m
        memory: 256Mi
      maxAllowed:
        cpu: 4
        memory: 8Gi
EOF

kubectl apply -f /tmp/vpa-postgres.yaml

# Redis VPA
cat > /tmp/vpa-redis.yaml << 'EOF'
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: redis-vpa
  namespace: data
spec:
  targetRef:
    apiVersion: apps/v1
    kind: StatefulSet
    name: redis-master
  updatePolicy:
    updateMode: "Initial"
  resourcePolicy:
    containerPolicies:
    - containerName: redis
      minAllowed:
        cpu: 50m
        memory: 128Mi
      maxAllowed:
        cpu: 2
        memory: 4Gi
EOF

kubectl apply -f /tmp/vpa-redis.yaml

# === 步骤 5: 验证 VPA 工作 ===

# 查看 VPA 推荐
kubectl get vpa --all-namespaces

# 查看详细推荐
kubectl describe vpa prometheus-vpa -n monitoring
kubectl describe vpa grafana-vpa -n monitoring

# 等待 24 小时后查看推荐是否生效

验证标准:

✅ VPA 组件正常运行
✅ VPA 资源对象创建成功
✅ 24 小时后 Pod 资源配置自动优化

预计时间: 1 小时

任务 4: 优化 Prometheus 存储策略

执行步骤:

# === 步骤 1: 检查当前配置 ===

kubectl get deployment prometheus -n monitoring -o yaml | grep -A 5 "args:"

# === 步骤 2: 编辑 Prometheus 配置 ===

kubectl edit deployment prometheus -n monitoring

# 在 args 部分添加/修改:
# - --storage.tsdb.retention.time=7d
# - --storage.tsdb.retention.size=50GB
# - --storage.tsdb.wal-compression

# 完整示例:
# args:
# - --config.file=/etc/prometheus/prometheus.yml
# - --storage.tsdb.path=/prometheus
# - --storage.tsdb.retention.time=7d
# - --storage.tsdb.retention.size=50GB
# - --storage.tsdb.wal-compression
# - --web.enable-lifecycle

# === 步骤 3: 等待 Pod 重启 ===

kubectl rollout status deployment prometheus -n monitoring

# === 步骤 4: 验证配置 ===

# 访问 Prometheus UI
kubectl port-forward -n monitoring svc/prometheus 9090:9090 &
open http://localhost:9090/config

# 检查 Runtime & Build Information
# 确认保留期为 7d

# === 步骤 5: 监控存储使用 ===

# 检查 PVC 使用情况
kubectl get pvc -n monitoring
kubectl exec -n monitoring deployment/prometheus -- df -h /prometheus

验证标准:

✅ Prometheus 保留期设置为 7 天
✅ WAL 压缩已启用
✅ 存储占用减少

预计时间: 30 分钟

任务 5: 关键服务多副本部署

执行步骤:

# === 步骤 1: 扩展 Grafana 到 2 副本 ===

kubectl scale deployment grafana -n monitoring --replicas=2

# 验证
kubectl get pods -n monitoring -l app=grafana
kubectl get hpa grafana-hpa -n monitoring

# === 步骤 2: 扩展 ArgoCD Server 到 2 副本 ===

kubectl scale deployment argocd-server -n argocd --replicas=2

# 验证
kubectl get pods -n argocd -l app.kubernetes.io/name=argocd-server
kubectl get hpa argocd-server-hpa -n argocd

# === 步骤 3: 扩展 Ingress NGINX 到 2 副本 ===

kubectl scale deployment ingress-nginx-controller -n infra --replicas=2

# 验证
kubectl get pods -n infra -l app.kubernetes.io/name=ingress-nginx
kubectl get hpa ingress-nginx-hpa -n infra

# === 步骤 4: (可选) Redis 高可用部署 ===

# 使用 Bitnami Redis Helm Chart 部署 Redis Sentinel
helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update

# 检查当前 Redis 配置
kubectl get all -n data -l app.kubernetes.io/name=redis

# 如果需要重新部署为高可用模式:
# helm upgrade redis bitnami/redis \
#   --set architecture=replication \
#   --set master.persistence.enabled=true \
#   --set replica.replicaCount=2 \
#   --set sentinel.enabled=true \
#   -n data

# === 步骤 5: 验证多副本工作正常 ===

# 检查所有副本是否 Running
kubectl get pods -n monitoring -l app=grafana
kubectl get pods -n argocd -l app.kubernetes.io/name=argocd-server
kubectl get pods -n infra -l app.kubernetes.io/name=ingress-nginx

# 检查 Service 负载均衡
kubectl describe svc grafana -n monitoring
kubectl describe svc argocd-server -n argocd
kubectl describe svc ingress-nginx-controller -n infra

# 测试滚动更新（应该零停机）
kubectl set image deployment/grafana -n monitoring grafana=grafana/grafana:11.4.0 --record
kubectl rollout status deployment/grafana -n monitoring

验证标准:

✅ 关键服务都有 2 个以上副本
✅ 所有 Pod 都是 Running 状态
✅ Service 正确负载均衡到所有副本
✅ 滚动更新零停机

预计时间: 1.5 小时

第 2-3 天总结:

✅ VPA 自动优化资源配置
✅ Prometheus 存储优化，减少 30-50% 占用
✅ 关键服务高可用，支持零停机更新
✅ 耗时: 约 3 小时

第 4-7 天 - P2 中优先级优化 (6 小时)

任务 6: 部署 Velero 集群备份

执行步骤:

# === 步骤 1: 安装 Velero CLI ===

brew install velero

# === 步骤 2: 准备 MinIO 凭证 ===

cat > /tmp/credentials-velero << EOF
[default]
aws_access_key_id = minioadmin
aws_secret_access_key = minioadmin123
EOF

# === 步骤 3: 在 MinIO 创建 bucket ===

# 访问 MinIO Console 创建 bucket: velero-backups
# 或使用 mc 命令:
# mc alias set minio http://minio.data.svc.cluster.local:9000 minioadmin minioadmin123
# mc mb minio/velero-backups

# === 步骤 4: 安装 Velero ===

velero install \
  --provider aws \
  --plugins velero/velero-plugin-for-aws:v1.9.0 \
  --bucket velero-backups \
  --secret-file /tmp/credentials-velero \
  --use-volume-snapshots=false \
  --backup-location-config \
    region=minio,s3ForcePathStyle="true",s3Url=http://minio.data.svc.cluster.local:9000

# === 步骤 5: 验证部署 ===

kubectl get deployment -n velero
kubectl get pods -n velero

# === 步骤 6: 创建测试备份 ===

velero backup create test-backup \
  --include-namespaces monitoring \
  --wait

# 检查备份状态
velero backup describe test-backup
velero backup logs test-backup

# === 步骤 7: 创建定期备份计划 ===

# 每日全量备份 (2:00 AM)
velero schedule create daily-full-backup \
  --schedule="0 2 * * *" \
  --include-namespaces=data,monitoring,logging,tracing,argocd,infra,cert-manager \
  --ttl 168h

# 每周归档备份 (Sunday 3:00 AM)
velero schedule create weekly-archive-backup \
  --schedule="0 3 * * 0" \
  --include-namespaces=data,monitoring,logging,tracing,argocd,infra,cert-manager \
  --ttl 720h

# === 步骤 8: 测试恢复 ===

# 创建测试命名空间
kubectl create namespace test-restore

# 恢复备份到测试命名空间
velero restore create test-restore \
  --from-backup test-backup \
  --namespace-mappings monitoring:test-restore

# 验证恢复
kubectl get all -n test-restore

# 清理测试
kubectl delete namespace test-restore

验证标准:

✅ Velero 组件运行正常
✅ 测试备份成功
✅ 定期备份计划已创建
✅ 恢复测试成功

预计时间: 2 小时

任务 7: 部署 Trivy Operator 安全扫描

执行步骤:

# === 步骤 1: 添加 Helm repo ===

helm repo add aqua https://aquasecurity.github.io/helm-charts/
helm repo update

# === 步骤 2: 安装 Trivy Operator ===

helm install trivy-operator aqua/trivy-operator \
  --namespace trivy-system \
  --create-namespace \
  --set="trivy.ignoreUnfixed=true" \
  --set="compliance.enable=true" \
  --set="scanJobsConcurrentLimit=3"

# === 步骤 3: 验证部署 ===

kubectl get deployment -n trivy-system
kubectl get pods -n trivy-system

# === 步骤 4: 等待扫描完成 ===

# Trivy Operator 会自动扫描所有命名空间的镜像
# 等待 5-10 分钟后查看结果

sleep 300

# === 步骤 5: 查看漏洞报告 ===

# 查看所有漏洞报告
kubectl get vulnerabilityreports --all-namespaces

# 查看特定 Pod 的漏洞
kubectl get vulnerabilityreports -n monitoring

# 查看详细漏洞信息
kubectl describe vulnerabilityreports -n monitoring | grep -A 10 "CRITICAL\|HIGH"

# === 步骤 6: 查看配置审计报告 ===

kubectl get configauditreports --all-namespaces

# 查看详细配置问题
kubectl describe configauditreports -n monitoring

# === 步骤 7: 查看合规报告 ===

kubectl get clustercompliancereports

# === 步骤 8: 创建仪表板监控 ===

# 在 Grafana 中导入 Trivy Dashboard
# Dashboard ID: 16337

验证标准:

✅ Trivy Operator 正常运行
✅ 漏洞报告已生成
✅ 配置审计报告已生成
✅ 可以查看 CRITICAL/HIGH 漏洞

预计时间: 1 小时

任务 8: 增强 Network Policies

执行步骤:

# === 步骤 1: 创建默认拒绝策略 ===

cat > /tmp/default-deny-all.yaml << 'EOF'
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress
EOF

# 应用到所有关键命名空间
for ns in data monitoring logging tracing argocd infra; do
  kubectl apply -f /tmp/default-deny-all.yaml -n $ns
done

# === 步骤 2: 允许 DNS 查询 ===

cat > /tmp/allow-dns.yaml << 'EOF'
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: kube-system
    ports:
    - protocol: UDP
      port: 53
    - protocol: TCP
      port: 53
EOF

for ns in data monitoring logging tracing argocd infra; do
  kubectl apply -f /tmp/allow-dns.yaml -n $ns
done

# === 步骤 3: 允许 Prometheus 采集指标 ===

cat > /tmp/allow-prometheus-scrape.yaml << 'EOF'
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-prometheus-scrape
  namespace: data
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: monitoring
    - podSelector:
        matchLabels:
          app: prometheus
    ports:
    - protocol: TCP
      port: 9104  # MySQL Exporter
    - protocol: TCP
      port: 9187  # Postgres Exporter
    - protocol: TCP
      port: 9121  # Redis Exporter
EOF

kubectl apply -f /tmp/allow-prometheus-scrape.yaml

# === 步骤 4: 允许 Loki 收集日志 ===

cat > /tmp/allow-loki.yaml << 'EOF'
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-loki
  namespace: logging
spec:
  podSelector:
    matchLabels:
      app: loki
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector: {}
    - podSelector:
        matchLabels:
          app: promtail
    ports:
    - protocol: TCP
      port: 3100
EOF

kubectl apply -f /tmp/allow-loki.yaml

# === 步骤 5: 允许 Ingress 流量 ===

cat > /tmp/allow-ingress.yaml << 'EOF'
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-ingress
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: infra
    - podSelector:
        matchLabels:
          app.kubernetes.io/name: ingress-nginx
EOF

# 应用到需要暴露的命名空间
for ns in monitoring argocd; do
  kubectl apply -f /tmp/allow-ingress.yaml -n $ns
done

# === 步骤 6: 验证 Network Policies ===

kubectl get networkpolicy --all-namespaces

# 测试连接性
kubectl run test-curl --image=curlimages/curl -i --rm --restart=Never -- \
  curl -m 5 http://grafana.monitoring.svc.cluster.local:3000

# 如果被拒绝，说明 Network Policy 工作正常

验证标准:

✅ 每个关键命名空间都有默认拒绝策略
✅ DNS 查询正常工作
✅ Prometheus 可以采集指标
✅ Loki 可以收集日志
✅ Ingress 流量正常

预计时间: 2-3 小时

第 4-7 天总结:

✅ 集群完整备份能力
✅ 自动化安全扫描
✅ 零信任网络架构
✅ 耗时: 约 5-6 小时

第 8-14 天 - P3 低优先级优化 (6.5 小时)

任务 9: 优化资源配额

# 基于实际使用调整配额
# data: 550m → 5 cores
# monitoring: 1150m → 5 cores
# logging: 150m → 2 cores

kubectl edit resourcequota data-quota -n data
kubectl edit resourcequota monitoring-quota -n monitoring
kubectl edit resourcequota logging-quota -n logging

预计时间: 30 分钟

任务 10: 部署 Thanos 长期存储

# 安装 Thanos 实现 Prometheus 长期存储
helm install thanos bitnami/thanos \
  --set query.enabled=true \
  --set compactor.enabled=true \
  --set storegateway.enabled=true \
  -n monitoring

预计时间: 3 小时

任务 11: 配置 AlertManager 通知

# 配置钉钉 Webhook 通知
kubectl edit configmap alertmanager-config -n monitoring
# 部署 dingtalk-webhook-proxy

预计时间: 1 小时

任务 12: 压力测试验证

# 创建负载生成器测试 HPA
kubectl create deployment load-generator \
  --image=busybox \
  -- /bin/sh -c "while true; do wget -q -O- http://grafana.monitoring.svc.cluster.local; done"

# 观察 HPA 自动扩容
watch kubectl get hpa -n monitoring

预计时间: 1 小时

📊 进度跟踪

完成情况

阶段	任务数	进度
第 1 天 (P0)	2	⬜⬜⬜⬜⬜ 0%
第 2-3 天 (P1)	3	⬜⬜⬜⬜⬜ 0%
第 4-7 天 (P2)	3	⬜⬜⬜⬜⬜ 0%
第 8-14 天 (P3)	4	⬜⬜⬜⬜⬜ 0%

里程碑

里程碑 1: P0 完成 - HPA 正常工作
里程碑 2: P1 完成 - VPA + 多副本 + 存储优化
里程碑 3: P2 完成 - Velero + Trivy + Network Policies
里程碑 4: P3 完成 - 所有优化完成

🎯 成功标准

技术指标

✅ HPA: 6/6 正常工作（显示具体百分比）
✅ 监控覆盖: 16 ServiceMonitor, 34 PrometheusRule
✅ VPA: 5+ VPA 自动优化资源
✅ 高可用: 关键服务 2-3 副本
✅ 备份: 每日自动备份
✅ 安全: Trivy 自动扫描
✅ 网络: 零信任架构

性能指标

✅ 资源利用率: CPU 5-10%, Memory 40-50%
✅ 存储优化: 减少 30-50%
✅ 服务可用性: 99.9%+

📝 注意事项

执行前检查

备份当前集群配置
确认有足够的资源空间
准备回滚计划
通知相关团队

风险管理

低风险: P0, P3 优化（只读操作或增强功能）
中风险: P1 优化（多副本部署，可能短暂重启）
中高风险: P2 Network Policies（可能影响连接性）

回滚计划

每个任务执行前:

# 备份当前配置
kubectl get all -n <namespace> -o yaml > backup-<namespace>-$(date +%Y%m%d).yaml

📚 相关文档

优化分析报告: K8S-OPTIMIZATION-ANALYSIS.md
企业级实施报告: ENTERPRISE-K8S-IMPLEMENTATION-REPORT.md
可观测性指南: OBSERVABILITY-GUIDE.md
部署指南: README.md

计划创建: 2025-12-30 执行开始: 待定 预计完成: 4 周后 负责人: DevOps Team

25 KiB Raw Permalink Blame History

Kubernetes 集群优化执行计划

📋 总览

优化范围

预期成果

第 1 天 - P0 关键修复 (2 小时)

任务 1: 修复 HPA Metrics 收集问题 ⚠️ 【最高优先级】

任务 2: 补全缺失的监控配置

第 2-3 天 - P1 高优先级优化 (4 小时)

任务 3: 部署 VPA (Vertical Pod Autoscaler)

任务 4: 优化 Prometheus 存储策略

任务 5: 关键服务多副本部署

第 4-7 天 - P2 中优先级优化 (6 小时)

任务 6: 部署 Velero 集群备份

任务 7: 部署 Trivy Operator 安全扫描

任务 8: 增强 Network Policies

第 8-14 天 - P3 低优先级优化 (6.5 小时)

任务 9: 优化资源配额

任务 10: 部署 Thanos 长期存储

任务 11: 配置 AlertManager 通知

任务 12: 压力测试验证

📊 进度跟踪

完成情况

里程碑

🎯 成功标准

技术指标

性能指标

📝 注意事项

执行前检查

风险管理

回滚计划

📚 相关文档

25 KiB

Raw Permalink Blame History