国内公有云容器服务运维指令手册

覆盖平台：阿里云 ACK / ACR、腾讯云 TKE / TCR、华为云 CCE / SWR、火山引擎 VKE（含镜像仓库与加速器） 底座版本：Kubernetes 1.30 ~ 1.36（各云支持窗口不同，见第 2 章） 约定：# 本地终端，$ 云 CLI，<xxx> 为占位符；kubectl 一律写全。 边界说明：托管集群的控制面不归你管，本手册讲的是"在托管边界之外，你还能且必须做什么"。 更新时间：2026-11（版本事实核对至 2026-11-05）

目录

1. 全景与托管边界
2. 版本生命周期与强制升级
3. 集群形态与选型
4. CLI、凭据与 kubeconfig
5. 集群创建与节点池
6. 弹性伸缩
7. 网络
8. 存储与备份
9. 镜像仓库 ACR / TCR / SWR
10. 国内镜像加速与拉取
11. 可观测、日志与排障边界
12. 升级窗口与灰度
13. 灾备与跨地域
14. 安全、权限与等保合规
15. 成本治理
16. 混合云与多集群
17. 故障速查
18. 附录

1. 全景与托管边界

1.1 四家平台速览（2026 年公开资料）

上述规模与最高版本来自 2026 年中的公开评测，具体数值以各云当前产品文档为准；云厂商几乎每年都会刷新上限。

1.2 责任共担：什么归你、什么归云

最重要的一条：托管集群没有 etcd 快照可打。所以 K8s 分册里那套 etcdctl snapshot save 在这里用不上；灾备必须靠 Velero/清单 GitOps + 数据层备份 + 镜像异地复制（见第 13 章）。

1.3 与传统自建集群的运维差异

2. 版本生命周期与强制升级

2.1 三家官方策略（2026-11 核对）

阿里云 ACK（文档更新 2026-07-03）：

腾讯云 TKE（官方版本日历）：

⚠️ 时间敏感：以 2026-11-05 计，TKE 1.30 距离 EOS 只剩约两周。还在 1.30 的集群应立刻排升级窗口；过期后不能新建、不再有补丁、SLA 不保证，平台保留强制升级权（提前不少于 30 天通知）。

华为云 CCE Autopilot（官方版本策略）：

CCE 版本格式 vX.Y.Z-rN（rN 是 CCE 补丁号）；EOS 后不提供技术支持、漏洞修复，SLA 失效，平台可能在 EOS 前自动升级。

CCE Standard/Turbo 与 Autopilot 的版本日历不同，查文档时别串台。

2.2 版本治理 SOP

# 1) 每季度盘一次所有集群版本与 EOS 日期
kubectl version --short 2>/dev/null || kubectl version
kubectl get nodes -o jsonpath='{.items[*].status.nodeInfo.kubeletVersion}'

# 2) 检查业务用到的废弃 API（升级前必做）
kubectl api-resources | grep -iE 'policy/v1beta1|extensions/v1beta1|apiextensions.k8s.io/v1beta1'
kubectl get pdb -A -o yaml | grep -i 'policy/v1beta1'      # 老 PDB API
kubectl get ingress -A -o yaml | grep -i 'networking.k8s.io/v1beta1'

# 3) 打升级工单/变更单，明确：目标版本、升级顺序、回滚方案、业务验证清单

坑：升级最常见的翻车不是控制面，而是业务用了已移除的 API（extensions/v1beta1 Ingress、policy/v1beta1 PDB/PSP 等）。控制面升上去后，旧清单直接apply 失败或控制器失效。先把清单迁到新 API，再升集群。

2.3 强制升级的现实

三家都保留"过期版本强制升级"的权利，通知期约 30 天。强制升级可能同时动：集群组件 → 控制面 → 节点池/节点。把它当作不可控变更对待：提前自己升，别等平台替你升。

3. 集群形态与选型

选型的关键分界：要不要为节点运维负责。团队没有节点运维能力、流量波动大，优先 Serverless；有稳定负载且要精细控制内核/网络，用托管标准集群。

4. CLI、凭据与 kubeconfig

4.1 三家 CLI

# 阿里云 aliyun CLI
aliyun version
aliyun configure list
aliyun cs GET /clusters --header "Content-Type=application/json"     # 列集群（示意）

# 腾讯云 tccli
tccli --version
tccli configure list
tccli tke DescribeClusters

# 华为云 hcloud CLI
hcloud --version
hcloud CCE ListClusters

# 通用：kubectl
kubectl config get-contexts
kubectl config current-context
kubectl config use-context <context>

4.2 获取 kubeconfig

# 阿里云（示意，参数以当前 CLI 版本为准）
aliyun cs GET /k8s/<cluster_id>/user_config > ~/.kube/ack-prod
# 腾讯云
tccli tke DescribeClusterKubeconfig --ClusterId <cluster_id>
# 华为云
hcloud CCE ShowClusterConfig --cluster_id <cluster_id>

export KUBECONFIG=~/.kube/ack-prod:~/.kube/tke-prod
kubectl config view --minify | head

坑：云控制台下载的 kubeconfig 常带短期凭据/临时 token（几小时~几天过期），还有的通过云 CLI 插件动态取凭据（如 ACK 的凭据插件、TKE 的 kubeconfig 需配合 CAM）。写进 CI/CD 时要用长期最小权限的服务账号 + 定期轮换，别把个人控制台凭据塞进流水线。

4.3 最小权限

• 阿里云 RAM：给 CI 账号 cs:Describe* / cs:Get*，推送镜像给 ACR 的 cr:Push* 等，按资源组/命名空间收敛。
• 腾讯云 CAM / 华为 IAM：同理，避免 AdministratorAccess / *FullAccess。
• Pod 内访问云资源：优先用 RRSA（ACK）/ OIDC 身份联邦 / 工作负载身份，别在 Secret 里长期存 AK/SK。

# 多集群下每次破坏性操作前确认上下文
kubectl config current-context
kubectl cluster-info

5. 集群创建与节点池

5.1 创建前必定的四件事

1. 网段规划：VPC 网段、Pod 网段、Service 网段三者互不重叠，且不与办公网 / VPN / 其他集群 / 线下 IDC 冲突。云上 VPC 一旦创建，网段改不了。
2. 网络模型：VPC-CNI（Pod 直接拿 VPC IP，性能好但吃 ENI 配额）vs 全局路由 / Overlay（省 IP，多一层转发）。
3. 可用区：控制面多 AZ 由云托管，节点池自己要跨 AZ 分布；单 AZ 节点池 = 单点。
4. 容器运行时与 OS 镜像：云提供的镜像预装了云组件，别随意换成自定义镜像，否则节点可能加不进集群。

# 创建后核验
kubectl get nodes -L topology.kubernetes.io/zone -o wide
kubectl get pods -n kube-system -o wide
kubectl get sc
kubectl get cm -n kube-system kubeadm-config -o yaml 2>/dev/null | grep -iE 'podSubnet|serviceSubnet'

5.2 节点池运维

kubectl get nodes -o wide
kubectl describe node <node> | tail -30
kubectl top nodes
kubectl get events -A --sort-by=.lastTimestamp | grep -i node | tail -20

云厂商的节点池有自己的"期望节点数"。手工 kubectl delete node 后，节点池控制器可能自动补一台，表现为"删了又回来"。要缩容就去改节点池，不要在 kubectl 里删。

6. 弹性伸缩

kubectl get hpa -A
kubectl get vpa -A 2>/dev/null
kubectl get scaledobject -A 2>/dev/null
kubectl describe hpa <name> -n <ns>
kubectl get events -A --sort-by=.lastTimestamp | grep -iE 'scaled|autoscal' | tail -20

坑：HPA 依赖 metrics-server / 云指标适配器。指标缺失时 HPA 显示 <unknown> 且不扩容，业务直接被打爆。把"指标链路可用性"纳入告警，而不是只监控 CPU。

7. 网络

7.1 排查顺序（云上和自建完全不同）

# 1) Pod 与 Service
kubectl get pod,svc,endpoints,endpointslices -n <ns>
kubectl get networkpolicy -A
# 2) Ingress / Gateway
kubectl get ingress -A
kubectl describe ingress <name> -n <ns>
# 3) 云负载均衡（控制台 / CLI）
# 4) 安全组与 VPC 路由（控制台，命令行看不到）
# 5) DNS
kubectl -n <ns> exec <pod> -- nslookup kubernetes.default

云上 70% 的"服务不通"出在安全组、VPC 路由表、CLB 后端健康检查和证书，不是 Pod 本身。先在云控制台看 CLB 后端是否全健康，再去 kubectl describe。

7.2 常见网络坑

#  quotas 相关（控制台为准），命令行先看事件
kubectl get events -A --sort-by=.lastTimestamp | grep -iE 'eni|ip|quota|limit' | tail -20

8. 存储与备份

kubectl get sc -o yaml
kubectl get pvc -A | grep -v Bound
kubectl describe pvc <pvc> -n <ns>
kubectl get volumesnapshot -A 2>/dev/null

坑：块存储云盘不能跨可用区挂载。节点池跨 AZ + 单副本 StatefulSet + 云盘 PVC = 节点故障后 Pod 永远 Pending。要么固定节点池单 AZ，要么用文件存储/多副本。

8.1 备份体系（托管集群没有 etcd 快照）

# Velero 备份集群资源 + PVC 快照
velero install --provider alibabacloud --plugins <云插件镜像> \
  --bucket <bucket> --secret-file ./credentials-cloud
velero backup create full-$(date +%F) --include-namespaces <ns> --snapshot-volumes
velero backup get
velero backup describe <name> --details
velero restore create --from-backup <name>

四层备份缺一不可：

1. 声明式清单：GitOps（Argo CD / Flux）里的所有 yaml / Helm values。
2. 集群资源：Velero 定时备份。
3. 持久化数据：云盘快照 + 数据库自己的 PITR（RDS 备份、自建库 binlog/WAL）。
4. 容器镜像：ACR/TCR/SWR 跨地域复制（见 9.4）。

9. 镜像仓库 ACR / TCR / SWR

9.1 域名与登录

# 通用 docker login（凭据用 RAM/CAM/IAM 子账号或临时 token）
docker login registry.cn-hangzhou.aliyuncs.com -u <user> -p '<token>'
docker login ccr.ccs.tencentyun.com -u <user> -p '<token>'
docker login swr.cn-north-4.myhuaweicloud.com -u <user> -p '<token>'

docker tag app:1.0 registry.cn-hangzhou.aliyuncs.com/prod/app:1.0
docker push registry.cn-hangzhou.aliyuncs.com/prod/app:1.0

# k8s 拉取凭据
kubectl create secret docker-registry regcred -n <ns> \
  --docker-server=<registry> --docker-username=<user> --docker-password='<token>'

生产环境优先用镜像免密拉取组件（ACK 的 aliyun-acr-credential-helper、TKE 的 TCR 免密插件、CCE 的 SWR 免密），别把长期 token 以 Secret 形式散落在各命名空间。

9.2 仓库治理

# 查看集群里实际用的镜像来源（排查是否还在拉公网）
kubectl get pods -A -o jsonpath='{range .items[*]}{.spec.containers[*].image}{"\n"}{end}' \
  | sed 's/:.*//' | sort | uniq -c | sort -rn | head -20

9.3 镜像加速器（与仓库是两回事）

9.4 跨地域/跨云复制

# 三家企业版都支持"实例间镜像复制"规则（控制台配置）
# 手动兜底：skopeo 跨仓库拷贝
skopeo copy --all \
  docker://registry.cn-hangzhou.aliyuncs.com/prod/app:1.0 \
  docker://ccr.ccs.tencentyun.com/prod/app:1.0 \
  --dest-creds <user>:<token>

灾备要覆盖镜像：集群清单恢复了、数据恢复了，但镜像仓库在单地域且没复制，照样起不来。

10. 国内镜像加速与拉取

10.1 2026 年现状（重要）

• 多数高校 / 公益 Docker Hub 公共加速已停止服务或限制匿名访问，继续把清华、中科大、上交等老地址写进 registry-mirrors 往往是拖慢而不是加速。
• 最稳的是云厂商为账号单独分配的专属加速器（ACR / TCR / SWR），有配额、有维护、不会因为滥用被关。
• 网上流传的 https://abc123.mirror.aliyuncs.com 是别人账号的地址，别抄；要么解析不到，要么被对方限流甚至账号注销后失效。
• 公共源（DaoCloud 等）可作应急备用，但不该作为生产唯一依赖。

10.2 验证一个加速地址是否还活着

# 200 或 401 都算服务正常（401 是要求鉴权）
curl -I --connect-timeout 5 https://<加速地址>/v2/

# 实测拉取
time docker pull --platform linux/amd64 hello-world
docker pull <加速地址>/library/nginx:alpine 2>/dev/null || true

10.3 daemon.json 正确写法

{
  "registry-mirrors": ["https://<你的专属ID>.mirror.aliyuncs.com"],
  "log-driver": "json-file",
  "log-opts": { "max-size": "100m", "max-file": "3" }
}

systemctl daemon-reload && systemctl restart docker
docker info | grep -A5 'Registry Mirrors'

坑：registry-mirrors 是串行回退列表。配 5 个地址、前 3 个超时，每次 pull 都要多等几十秒。只配 1 个主力 + 最多 1 个备用，且每月复测一次。

10.4 容器运行时不是 Docker 时

K8s 节点用 containerd，加速器要配在 /etc/containerd/certs.d/docker.io/hosts.toml（containerd 1.7+/2.x）：

# /etc/containerd/certs.d/docker.io/hosts.toml
server = "https://docker.io"
[host."https://<加速地址>"]
  capabilities = ["pull", "resolve"]
  override_path = true

systemctl restart containerd
crictl pull nginx:alpine

云托管节点由平台预置，一般不给你改 containerd 配置。优先把业务镜像同步到同地域的 ACR/TCR/SWR 内网地址，这比在节点上配加速器更稳、更快、也不受公网波动影响。

10.5 内网部署的推荐路径

外网构建机 → push 到 ACR/TCR/SWR 企业版
            → 跨地域复制到内网可达区域
            → 集群通过 VPC 内网地址拉取
            → 完全不依赖 Docker Hub

11. 可观测、日志与排障边界

11.1 日志与监控服务

# 集群侧能自己拿到的
kubectl get events -A --sort-by=.lastTimestamp | tail -50
kubectl top nodes
kubectl top pods -A --sort-by=memory | head -20
kubectl logs -f <pod> -n <ns> --tail=200
kubectl describe pod <pod> -n <ns>

11.2 托管集群看不到的东西

因此排障要有分层意识：Pod 问题自己查；节点问题查云控制台 + 登录节点；控制面/API 不可用直接看云状态页并提工单，别在节点上白折腾两小时。

11.3 常见"看起来像 K8s 问题，其实是云资源问题"

12. 升级窗口与灰度

12.1 升级顺序

1. 清单 API 兼容性治理（废弃 API 迁移）
2. 测试集群升到目标版本，跑核心回归
3. 控制面升级（控制台/CLI 触发，云托管，通常分钟级）
4. 节点池滚动升级（分批，可设并发数与间隔）
5. 插件/组件升级（CNI、CSI、Ingress Controller）
6. 业务验证 + 观察期

12.2 升级前检查

kubectl get pdb -A
kubectl get nodes -o wide
kubectl get pods -A --field-selector=status.phase!=Running | grep -v Completed
kubectl get hpa -A
kubectl api-resources | grep -i beta
# 记录当前版本与节点池配置
kubectl get nodes -o jsonpath='{.items[*].status.nodeInfo.kubeletVersion}' > /root/pre-upgrade.txt

坑：PDB 会卡住节点池 drain。升级前把 maxUnavailable: 0 / minAvailable: 100% 的 PDB 找出来评估，否则节点池滚动升级会一直停在"等待驱逐"。

12.3 回滚现实

托管集群控制面不能降级。升级出问题的兜底是：新建旧版本集群 → 从 GitOps + Velero + 数据备份恢复 → 切流量。所以"回滚方案"在托管集群里其实是重建方案，必须提前演练。

13. 灾备与跨地域

# 定期演练（至少每半年一次）
velero backup create dr-drill-$(date +%F)
velero restore create --from-backup dr-drill-<date> --namespace-mappings <原ns>:<演练ns>
kubectl get pods -n <演练ns>

灾备演练的验收标准不是"备份任务成功"，而是在另一地域用备份把业务真正拉起来并跑通读写。只备份不演练等于没备份。

14. 安全、权限与等保合规

14.1 基线

• 集群 API Server 不开放公网，或严格限定 IP 白名单
• RAM/CAM/IAM 子账号最小权限，禁用主账号 AK
• 开启审计日志并投递到独立日志账号，留存 ≥ 180 天（等保 2.0 三级常见要求）
• Pod 内用工作负载身份（RRSA / OIDC）访问云资源，不落 AK/SK
• Secret 用 KMS 加密（云托管 K8s 提供静态加密选项）
• 镜像仓库开启扫描、签名、不可变 tag
• NetworkPolicy 做东西向隔离；默认拒绝 + 白名单
• 节点安全组最小化，节点不暴露 SSH 到公网
• 开启 PSA / Pod Security Admission，禁用特权容器
• 定期打节点 OS 与运行时补丁（云镜像更新）
• 等保场景：留存操作审计、堡垒机运维通道、日志防篡改

kubectl get psp 2>/dev/null            # PSP 已在 1.25 移除，看到说明版本太老
kubectl get ns -o jsonpath='{.items[*].metadata.labels.pod-security\.kubernetes\.io/enforce}'
kubectl get networkpolicy -A
kubectl get sa -A | head -20

14.2 权限排查

kubectl auth can-i --list --as=system:serviceaccount:<ns>:<sa>
kubectl get clusterrolebindings -o json | jq '.items[] | select(.subjects[]?.name=="<sa>")'

15. 成本治理

kubectl get pvc -A | grep Released
kubectl get svc -A -o wide | grep LoadBalancer
kubectl top nodes
kubectl get hpa -A

成本治理的第一刀通常是日志与镜像存储，而不是节点。先把这两个的留存策略定下来，再谈缩容。

16. 混合云与多集群

kubectl config get-contexts
kubectl --context <ctx-a> get nodes
kubectl --context <ctx-b> get nodes
# Karmada 场景
kubectl --context karmada-apiserver get clusters
kubectl --context karmada-apiserver get propagationpolicy -A

注册集群只是"统一视图"，不会把自建集群变成托管集群：控制面仍归你管，etcd 仍要你备份，升级仍要你自己做。别因为控制台能看到了就以为责任转移了。

17. 故障速查

17.1 三分钟定位脚本

kubectl config current-context
kubectl version --short 2>/dev/null || kubectl version
kubectl get nodes -o wide
kubectl get pods -A --field-selector=status.phase!=Running | grep -v Completed
kubectl get pvc -A | grep -v Bound
kubectl get svc -A -o wide | grep LoadBalancer
kubectl get hpa -A
kubectl get events -A --sort-by=.lastTimestamp | tail -30
kubectl top nodes 2>/dev/null

18. 附录

18.1 CLI 与域名速查

18.2 版本生命周期速查（2026-11）

版本日历变动频繁，每次升级前重新查对应云官方文档，不要以本表为唯一依据。

18.3 高危操作红线

18.4 与其他手册的配合

维护建议：云产品的版本日历、配额上限、CLI 参数与镜像仓库域名随区域和版本变动，本文的表格是 2026-11-05 核对的基线。落地时把「区域 + 集群版本 + EOS 日期 + 仓库域名 + 配额清单 + 升级窗口」写入集群台账，并设置 EOS 前 90/60/30 天三级提醒。