云计算平台运维与开发认证备考指南：从OpenStack到Kubernetes-育师

简介：这是一份面向云计算平台运维与开发职业技能等级认证备考者的PDF教程，系统讲解工程项目文档编写与管理、项目管理核心概念、瀑布与敏捷开发模型、项目开发全流程等知识点，适合参加中级认证培训或从事云平台运维开发工作的人员作为理论复习与参考手册。资源包仅含1个PDF文件，大小2.61MB，内容精炼，便于移动端或桌面端随时查阅，按章节组织可快速定位工程立项、计划、需求、设计、开发等阶段要点。已有146人学习下载，适合希望系统梳理项目管理与文档规范、理解两种开发模型适用场景的学员。通过通读本教程，读者可以掌握项目文档版本控制与质量管理方法，熟悉从启动到收尾的完整管理过程，理解瀑布模型与敏捷开发在真实项目中的选择依据，为后续实操认证和岗位工作积累必要理论基础。

1. 云计算平台运维与开发职业技能等级认证教程：一本把运维和开发绑在一起的备考手册

拿到《云计算平台运维与开发职业技能等级认证教程》这本PDF的读者，大多数是奔着一个目标：把认证考下来，给简历加一张有分量的证书。但我的建议是，先别急着翻到考点清单，因为这本教程最值钱的地方不是证书本身，而是它把“平台运维”和“应用开发”放在同一个考核体系里，逼着你既会敲命令行，又能写自动化代码。如果你正准备认证、是刚入行的云计算运维工程师、或者想从纯运维转做运维开发，这份教程对应的学习路径都值得完整走一遍。它解决的从来不是“会不会背题”，而是“能不能在一台真实云平台上把环境搭起来、排得动错、扩得起来”。

2. 认证教程的考试地图：等级划分、考核模块与分值权重

先把全貌看清楚，再决定从哪里投入时间。

2.1 三个等级对运维和开发的能力要求差异

这类技能等级认证通常把“运维”和“开发”揉进同一个考核体系，按难度分成初级、中级、高级三档。初级侧重命令和概念，中级要求能独立部署平台并处理故障，高级则默认你具备生产环境经验。三个等级对两端能力的要求差异很大，备考前先找准自己的起点，能省下大量无效刷题时间。

中级是一个明显的分水岭。初级考试背熟命令基本能过，但中级开始要求你在一个不熟悉的集群环境里现场解决问题，题库里大量题目没有标准答案，只有“能不能跑通”和“步骤是否合理”。如果你已经能独立配好一台 Linux 服务器的网络和磁盘，并且能解释清楚虚拟机和容器的区别，完全可以直接从中级目标开始准备，不用在初级内容上耗太久。

2.2 考核模块与分值占比：理论、实操、开发题的分布规律

虽然不同批次和机构的考试细则有差异，但分值分布通常遵循一个规律：云计算基础理论占两成左右，平台运维实操占四到五成，开发与自动化占两到三成，剩下约一成是综合排障。也就是说，整本《云计算平台运维与开发职业技能等级认证教程》里约七成内容最终要落到键盘上，而不是答题卡上。

实操环境的常见规格是三台互联的服务器，分别充当控制节点、计算节点和存储节点；也可能直接给一套轻量 Kubernetes 集群。考试账号通常是一个普通用户加 sudo 权限，网络段和主机名由系统分配，你需要在规定时间里完成组件的部署、启动和功能验证，再回答几道关于配置参数的问题。

这意味着只看不练基本没有通过的可能。备考时最好给自己准备一台 8G 内存以上的虚拟机，把教程里的部署命令完整执行两遍：第一遍照抄，第二遍关掉教程凭记忆写。能不看文档把一套 OpenStack 最小环境搭起来的人，说明底层的运维逻辑是真的理解了，而不是背出来的。

2.3 教程里“开发”部分的隐藏重点：API、编排、自动化

很多人一看到“开发”两个字就紧张，以为要写业务系统，实际完全不是一回事。这个认证里的“开发”，指的是用代码去操控云平台，把重复的运维动作变成可复用的工具。常见考点有三类，它们共同构成了教程后半部分的主线。

第一类是云平台 API 调用。OpenStack、Kubernetes 都提供了完整 API，考试时可能要求你用 Python 脚本调用 API，完成云主机从创建、查询到删除的整个生命周期。这类题看起来像编程，本质考的是对 API 资源模型的理解：查镜像、查规格、建主机、等状态，每一步对应哪个接口，参数从哪来。

第二类是基础设施编排。给一段业务描述，要求用模板定义两台云主机、一个私有网络、一个浮动 IP。常见实现方式是 Heat 模板或 Terraform，答题时不需要把整个语言背下来，但必须能看懂字段含义，并能按题目要求修改变量。这类题最容易丢分的地方是网络关联，很多人能建主机却连不通网络。

第三类是自动化交付，小到写一个一键巡检脚本，大到用 Jenkins 把代码拉到云端、构建镜像、滚动发布。写巡检脚本时，“定时执行、异常输出、结果落盘”三个点缺一不可，这其实就是一个小的 agent 开发任务；给云平台控制台扩展一个资源展示页，又会用到前端开发知识。所以教程里的“开发”不是软件工程意义上的业务开发，而是运维的工程化表达。

备考开发类题目时，不用追求复杂框架，先把“输入参数—调用接口—处理返回—输出结果”这条链路写顺。阅卷通常不要求你写出媲美开源项目的代码，但非常看重异常处理和边界条件，这两项恰恰是普通考生最容易忽略的。

3. 把教程内容落到实操环境：OpenStack、Docker 与 Kubernetes 的最小复现

这一章解决“去哪里练”的问题。认证题目大多围绕 OpenStack 和 Kubernetes 展开，你需要先有一台能反复折腾的环境。

3.1 用 DevStack 在虚拟机里搭单节点 OpenStack：最小命令与参数

很多真题要求操作 OpenStack 平台完成网络、镜像、云主机的管理。生产环境的 OpenStack 是分布式的，学习阶段没必要硬上，用 DevStack 是社区里最常见的做法，它能把一套单节点 OpenStack 装在同一台机器里，足够练习大部分运维操作。

准备一台 8G 内存、60G 磁盘的干净虚拟机，推荐 CentOS 或 Ubuntu LTS 版本。磁盘小于 40G 会在下载镜像阶段直接写满，内存小于 8G 会在 Keystone 启动时 OOM，这两条是装之前必须确认的硬条件。

# 创建专用用户，DevStack 不允许用 root 直接执行 useradd -m stack echo "stack:123456" | chpasswd echo "stack ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers # 切换到 stack 用户并拉取代码 su - stack git clone https://github.com/openstack/devstack.git cd devstack # 写最小 local.conf，避免安装过程中反复交互 cat > local.conf <<'EOF' [[local|localrc]] HOST_IP=192.168.10.100 ADMIN_PASSWORD=Admin@123 DATABASE_PASSWORD=Admin@123 RABBIT_PASSWORD=Admin@123 SERVICE_PASSWORD=Admin@123 EOF # 开始安装，日志在 /opt/stack/logs 目录 ./stack.sh

HOST_IP 必须填虚拟机实际能访问的 IP，不能填 127.0.0.1，否则后面创建云主机时，网络节点会找不到地址。四个密码可以设成一样的，学习环境不需要讲究；但生产环境用这种密码会被审计直接打回，这个习惯要一开始就养好。

./stack.sh根据机器性能一般要跑 30 到 90 分钟。中途失败不要直接重跑，先看 /opt/stack/logs/ 下对应服务的日志。最常见的失败原因是磁盘写满、系统软件源不通、以及 Keystone 的 Fernet key 初始化异常。前两个问题可以在执行前解决，第三个通常删掉 /opt/stack 目录重新来，不要尝试在原目录上修补，容易越修越乱。

3.2 用 kubeadm 初始化 Kubernetes 集群：关键参数与 CNI 选择

Kubernetes 的学习环境有多种选法：Minikube 适合单机体验，Kind 适合跑 CI，但认证实操题几乎都围绕 kubeadm 展开，因为只有它覆盖了多节点加入集群的完整流程，能真正考到 token、CA 证书、CNI 网络这些知识点。

# 所有节点执行：配置软件源并安装组件 cat > /etc/yum.repos.d/kubernetes.repo <<'EOF' [kubernetes] name=Kubernetes baseurl=https://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64/ enabled=1 gpgcheck=0 EOF yum install -y kubelet kubeadm kubectl systemctl enable --now kubelet # 控制平面节点初始化 kubeadm init \ --apiserver-advertise-address=192.168.10.100 \ --pod-network-cidr=10.244.0.0/16

apiserver-advertise-address 是集群其他节点访问 API Server 的地址，必须和控制平面节点的内网 IP 一致。pod-network-cidr 要跟 CNI 插件配套：Flannel 默认用 10.244.0.0/16，Calico 默认用 192.168.0.0/16。这两个参数只要有一个不匹配，节点就会一直 NotReady，而且表面上看不出问题，属于典型的“日志里全是玄学报错”的场景。

kubeadm init 完成后，按提示执行 kubectl 配置命令，然后安装 Flannel：

kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/master/Documentation/kube-flannel.yml

这份 YAML 里已经写好了与 10.244.0.0/16 对应的网络配置，不需要再改。如果你的环境拉取 flannel 镜像失败，先确认节点能访问镜像仓库，再考虑把 image 字段改成你能访问的仓库地址，这是考试环境中常见的镜像拉取问题。

很多考生在这个阶段会把 kubelet 和 kubeadm 的版本装混，导致 kubeadm init 时提示版本不匹配。我一般习惯在执行 init 前先用kubeadm version确认版本，再固定到同一系列的 kubelet，能少踩一个坑。

3.3 把“运维动作”变成“开发产物”：写一个一键巡检脚本

教程里的“开发”不是从零写一套系统，而是把平时手动敲的命令变成脚本。最典型的题目是写一个资源巡检工具，要求检查 CPU 负载、内存使用率、磁盘占用和核心服务状态，输出结构化结果。

#!/usr/bin/env python3 # 一键巡检脚本：CPU、内存、磁盘、服务状态 import json import subprocess import psutil def collect_cpu(): load1, load5, load15 = psutil.getloadavg() return {"load1": load1, "load5": load5, "load15": load15} def collect_memory(): mem = psutil.virtual_memory() return { "total_g": round(mem.total / 1024**3, 2), "used_g": round(mem.used / 1024**3, 2), "percent": mem.percent, } def collect_disk(): disk = psutil.disk_usage("/") return { "total_g": round(disk.total / 1024**3, 2), "used_g": round(disk.used / 1024**3, 2), "percent": disk.percent, } def check_service(name): # 返回 systemctl 的 is-active 结果：active / inactive / failed ret = subprocess.run( ["systemctl", "is-active", name], capture_output=True, text=True, ) return ret.stdout.strip() if __name__ == "__main__": report = { "cpu": collect_cpu(), "memory": collect_memory(), "disk": collect_disk(), "services": { "nova-api": check_service("nova-api"), "kubelet": check_service("kubelet"), }, } print(json.dumps(report, ensure_ascii=False, indent=2))

psutil 是第三方库，没有外网的考试环境不一定装了。这时要学会退路：从 /proc/loadavg 读负载，从 /proc/meminfo 读内存，用df -P读磁盘。两条路都能得分，但能解析 /proc 文件的答案更完整，因为它不依赖任何额外安装。

脚本输出用 JSON 而不是纯文本，是考场上的加分习惯。后续如果要把结果上报给纳管平台，JSON 可以直接被消费，纯文本还要再处理一遍。别忘了考虑定时调度，题目如果问“如何每 5 分钟执行一次”，答案就是在 crontab 加一行：*/5 * * * * /usr/local/bin/inspect.py > /var/log/inspect.out 2>&1。

4. 开发类考题的得分套路：API 编排、自动扩缩容与发布流水线

认证里的“开发题”不是让写业务系统，而是围绕云平台 API、资源编排和发布流水线展开。这一章讲三件最常考的事。

4.1 用云平台 API 完成云主机生命周期管理

命令行操作有极限，批量创建几十台云主机时，用代码调用 API 才是正解。OpenStack Python SDK 是常见选择，它读取一个配置文件来定位平台地址和凭证，这个文件就是 clouds.yaml。

# ~/.config/openstack/clouds.yaml clouds: openstack: auth: auth_url: http://192.168.10.100:5000/v3 username: admin password: Admin@123 project_name: admin user_domain_name: Default region_name: RegionOne

auth_url 从 Keystone 的 endpoint 列表里找，一般带 /v3 后缀。region_name 填错了不会报密码错误，而是报 404，这个现象很有迷惑性。考场上有人在这里反复改密码浪费时间，其实先查 endpoint 列表就能定位。

然后是调用代码：

import openstack # 读取 clouds.yaml 并选择名为 openstack 的云环境 conn = openstack.connect(cloud="openstack") # 先查询镜像和规格的 ID，再创建云主机 images = conn.compute.find_image("ubuntu-22.04") flavors = conn.compute.find_flavor("m1.small") server = conn.compute.create_server( name="web-01", image_id=images.id, flavor_id=flavors.id, key_name="demo-key", networks=[{"uuid": "你的网络ID"}], ) # 等待状态变为 ACTIVE，超时时间设为 120 秒 conn.compute.wait_for_server(server, timeout=120)

create_server 里的 key_name 是指已经注入到云平台里的密钥对，不是本地文件名。你要是传了一个本机不存在的路径，云主机能创建成功，但控制台登录只能靠密码，后续题目里“通过密钥登录”那一步就白丢了。wait_for_server 也经常被省略，结果是在状态还没有 ACTIVE 时就去查 IP，查了个空然后怀疑脚本写错。

这类题得分的关键在顺序：先确认镜像、规格、网络三个 ID 都存在，再执行创建。这三个 ID 只要填错一个，后面所有步骤都会跟着失败，而且报错信息往往指向完全无关的模块，排查起来非常费时。

4.2 基于 HPA 的自动扩缩容：参数设置与验证压测

Kubernetes 开发题里，HPA 出现频率很高。它处在“分布式开发”和“平台运维”的交汇点：既要理解 Pod 调度机制，又要能写清单文件并做压测验证。

# web-hpa.yaml apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: web-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: web minReplicas: 2 maxReplicas: 8 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 60

averageUtilization 是目标平均 CPU 使用率，设为 60 意味着当所有 Pod 的平均使用率超过 60% 时扩容。minReplicas 和 maxReplicas 的差距不能拍脑袋定，得根据业务峰值来。考试场景里常见的是 2 到 8，太小看不出弹性效果，太大则会拖垮单机环境。

HPA 要生效，集群里必须先有 metrics-server。没有它时kubectl get hpa能看到策略，但 TARGETS 列会一直显示 unknown，压测半天也不触发扩缩容。这是整个 HPA 题目里最经典的“不是配置错，而是环境缺组件”的坑。

验证时压测工具的选择有讲究：

# 查看 HPA 当前状态 kubectl get hpa web-hpa # 用 busybox 循环请求服务 kubectl run -it load-test \ --image=busybox \ --restart=Never \ -- /bin/sh -c "while true; do wget -q -O- http://web-service; done"

busybox 镜像在离线环境不一定存在，如果拉不下来就换成集群里已有的带 wget 或 curl 的镜像；再不行就在宿主机上用 ab 直接打 Service 的 NodePort。判分看的是 HPA 是否真的扩容到预期副本数，而不是压测工具本身体面不体面。

扩容触发后，kubectl get pods -o wide能看到新 Pod 被调度到节点上，kubectl describe hpa里能查上一轮扩缩容事件。把这两条命令的输出截进答题记录，是拿满步骤分的常见做法。

4.3 从源码到云上部署：一条可手写的 CI/CD 流水线

认证里出现 CI/CD 时，不会让完整搭建一套 Jenkins 集群，但要求理解构建、推送、部署、回滚这几个环节。用 Jenkinsfile 表达是最常见的答题形式。

pipeline { agent any environment { IMAGE = "registry.local/cloud/web" } stages { stage("构建") { steps { // 构建并打上构建号标签 sh "docker build -t ${IMAGE}:${BUILD_NUMBER} ." } } stage("推送") { steps { sh "docker push ${IMAGE}:${BUILD_NUMBER}" } } stage("部署") { steps { // 滚动更新 Deployment 镜像，保留历史版本用于回滚 sh "kubectl set image deployment/web web=${IMAGE}:${BUILD_NUMBER} --record" } } } }

BUILD_NUMBER 是 Jenkins 内置变量，每次构建自增。用它当镜像标签是为了让每次部署的版本可以追溯；如果固定写 latest，发布后很难定位线上跑的是哪次构建。

kubectl set image --record会把这次变更记录到 Deployment 的 annotation 里，后面一条kubectl rollout undo deployment/web就能回滚到上一个版本。这个操作就是运维口里常说的后悔药。考试时如果环境里没有 Jenkins，用 shell 脚本按“构建、推送、部署、回滚”四段实现同样能得分，重点在于体现“版本可追溯”和“回滚路径存在”两个意识。

很多人在部署阶段会直接kubectl delete pod来重启服务，这是最容易被扣分的写法。正确做法是用 rollout 或 scale 这类受控制器管理的动作，手工删 Pod 只解决了眼前，却绕过了 Deployment 的状态机，日志里会留下诡异的时间线。

5. 备考避坑：认证环境里最容易丢分的 5 个实操场景与排查思路

下面 5 个场景是我见过最多人翻车的地方，每一条都按“现象、原因、解决”的顺序写，方便直接对照。

5.1 创建云主机一直失败，提示 No valid host

现象：用 openstack server create 创建云主机，命令执行后很快进入 ERROR 状态，详情里显示 No valid host was found。这是新手最容易慌的报错，因为页面上除了一行字什么都没有。

原因：调度器找不到可以放置云主机的计算节点。多数时候是 nova-compute 服务处于 down 状态，也可能是可用域、主机聚合或资源余量不满足要求。注意，它不代表配置写错，只代表当前集群没有节点能接收这个请求。

解决：基本三连。先执行openstack compute service list确认 nova-compute 是 enabled 且 state 为 up；再执行openstack host show <计算节点名>查看可用内存和 vCPU；最后看 /var/log/nova/nova-scheduler.log 里最后一条调度失败记录。若节点 up 但资源紧张，释放一台旧云主机或等待资源回收后再试。考试时不要把时间花在反复改 flavor 上，原因多半不在 flavor。

5.2 Kubernetes 节点 NotReady，coredns 一直 Pending

现象：kubeadm init 成功，但kubectl get nodes显示 NotReady，coredns 两个 Pod 停在 Pending，重启也不动。

原因：CNI 网络插件没有安装，或者插件版本与集群不兼容；也可能是 kubelet 的 cgroup 驱动和容器运行时不一致，导致 kubelet 反复重启。

解决：先看kubectl describe node里的 Conditions，通常会写 network plugin not ready。安装 Flannel 或 Calico 之后等待几分钟，再执行kubectl get nodes确认状态。如果还是 NotReady，在节点上执行journalctl -u kubelet --since 10min，重点搜 cgroup、kubelet 相关报错。使用 containerd 时，要确保/etc/containerd/config.toml里的 SystemdCgroup 与 kubelet 的 cgroup driver 一致，这是“日志全正常但节点一直 NotReady”的高发位置，也是典型的玄学现场。

5.3 脚本里写死 IP，换环境后服务全挂

现象：一套部署脚本在练习环境跑通，换到考试环境的另一组网段后，服务起不来，或起来了但互相访问不通。

原因：脚本里把控制节点、计算节点的 IP 硬编码了，比如controller_ip="192.168.10.100"。换环境后 IP 变了，配置文件却还指向旧地址。

解决：写脚本时把 IP 提取成变量，执行前从环境变量或配置文件中读取。

# 错误写法 controller_ip=192.168.10.100 # 正确写法：支持外部传入，缺省时才用本地值 controller_ip=${CONTROLLER_IP:-192.168.10.100}

这里顺手记一下赋默认值的语法，既是考试考点，也是生产中避免误操作的手段。改完脚本后，检查所有涉及 IP 的配置文件是否引用同一个变量，再重新执行部署。这属于能在考前自查避免的丢分点，完全不用拼临场反应。

5.4 浏览器访问不了 OpenStack Dashboard

现象：在外部机器上访问 http://控制节点IP/dashboard，页面一直转圈或直接拒绝连接，控制节点本机访问正常。

原因：80 端口没被防火墙放行，httpd 服务没起来，或 Django 的 ALLOWED_HOSTS 配置里不包含当前访问的域名或 IP。

解决：先在控制节点执行ss -lntp | grep :80确认端口在监听，没监听就systemctl status httpd看服务状态。端口正常时，再看 OpenStack Dashboard 配置文件里的 ALLOWED_HOSTS，改成['*']或显式写上访问 IP，然后重启 httpd 和 memcached。

这个现象经常被误判成 Keystone 挂了，因为浏览器里看到的是一串 502 错误。其实看 /var/log/httpd/error_log 能立刻定位是 allowed host 还是 upstream 的问题，比逐个猜快很多。

5.5 安全组放行了，云主机端口仍然不通

现象：安全组里已经添加入方向规则放行 80 端口，但从外部访问云主机的 80 端口超时，ping 也不同。

原因：安全组规则的协议或方向填错，比如只放行了 IPv6 却用 IPv4 访问。另一种常见原因是云主机所在网络没有关联路由器，浮动 IP 的 NAT 映射无法建立。在 OpenStack 里，路由器的 gateway 接口必须连到外部网络，内部网络也要有 subnet 关联，否则浮动 IP 只是一个空壳。

解决：执行openstack router list查看路由器，确认 external gateway 和内部接口都正常；再执行openstack security group rule list核对方向和协议。考试里最常见的操作顺序是先绑定浮动 IP、再加安全组规则、最后建路由器，顺序反了会找很久问题。遇到这种情况，删掉重建通常比重启服务更高效。

以上五条都过一遍之后，你对这套认证环境的理解就和死记命令不在一个层次了。排查顺序也有共性可循：先看服务状态，再看端口监听，最后看日志文件，永远比对着配置文件猜目录高效得多。

6. 从考证到转岗：值得深入的三条进阶学习方向

6.1 把 OpenStack 和 Kubernetes 练成一套“组合拳”

认证教程把 OpenStack 和 Kubernetes 分开讲，但上岗后你会发现两者常常出现在同一条交付链路上：OpenStack 提供虚拟机、网络和存储，Kubernetes 在虚拟机之上调度容器。学习阶段不需要把两套系统装进同一台机器，先分别在 DevStack 和 kubeadm 上把基础操作练熟，再用编排工具把它们串成完整交付链路。

这个阶段值得刻意练习的是基础设施编排。Terraform 管理 OpenStack 资源，Ansible 负责在资源创建后做配置，两者配合就是完整的“基础设施即代码”。

# main.tf：创建一台 OpenStack 云主机 resource "openstack_compute_instance_v2" "web" { name = "web-01" image_id = "镜像UUID" flavor_id = "规格UUID" key_pair = "demo-key" network { uuid = "网络UUID" } }

执行 terraform apply 之前，先通过环境变量传入 OpenStack 认证信息。示例里四个 UUID 任何一个填错，apply 都会失败，所以“先查询再引用”的习惯要在这个阶段养成。

6.2 面试里高频但教程没展开的三组概念

考证帮助建立操作记忆，但面试官通常会用三组概念来验证你是否真正理解了平台。

这三组内容不一定写在那本认证教程最显眼的位置，但都是实际排障绕不开的关键路径。比如遇到“Pod 一直创建不到指定节点上”的问题，如果不知道 taint 和 toleration 的匹配规则，可能查一小时日志都找不到方向。

6.3 给新人的一条路线建议

如果只给一条建议，那就是：考证前至少完整部署三遍 OpenStack 和 Kubernetes。第一遍照教程，第二遍凭记忆，第三遍故意制造故障再修复。这套流程走完，认证的实际意义才算真正落到你身上。

我自己当年是先抱着 PDF 啃理论，结果第一次上机就卡在 No valid host 上，人直接懵了。后来改成“每学一章就搭对应环境”，一周时间比之前一个月都扎实。技术认证的证书是入场券，但你在反复部署中形成的排错手感，才是面试和试用期里真正替你说话的东西。希望帮到你。

本文还有配套的精品资源，点击获取

云计算平台运维与开发认证备考指南：从OpenStack到Kubernetes