在当今的云计算领域，当我们讨论构建现代化的基础设施时，OpenStack 和 OpenShift 无疑是两个频繁出现的名字。许多开发者，尤其是那些刚开始接触云原生技术的朋友，经常会混淆这两者。虽然它们经常在同一个数据中心里协同工作，但它们解决的问题截然不同。在这篇文章中，我们将深入探讨这两大技术栈的核心差异，并通过实际的代码和架构示例，帮助你理解在什么场景下应该选择哪一个，以及它们如何互补以构建强大的混合云环境。
目录
初步印象：定位的本质区别
首先，我们需要明确一个核心概念，这将贯穿我们今天的讨论：OpenStack 专注于“基础设施”，而 OpenShift 专注于“应用平台”。
我们可以把 OpenStack 想象成一个操作系统，它管理的是物理服务器、存储设备和网络交换机，把它们组合成一个巨大的资源池。而 OpenShift 则是运行在这个操作系统之上的“中间件”或“平台”，它帮助开发者更轻松地编写、部署和运行容器化应用。简单来说，OpenStack 更像是一个云厂商（类似于 AWS 或阿里云的基础部分），而 OpenShift 则是一个开发者友好的 Kubernetes 发行版。
什么是 OpenStack？构建 IaaS 的基石
OpenStack 是一个开源的云计算管理平台项目，它允许企业通过标准化的虚拟化技术，将传统的数据中心转变为类似公有云的环境。它由 Rackspace Technology 和 NASA 于 2010 年联合发起，目前由 OpenStack 基金会管理。
核心组件架构
OpenStack 并不是一个单一的软件，它实际上是一组相互协作的服务（微服务）。为了更好地理解它，让我们看看它的核心组件：
- Nova（计算服务）：负责管理虚拟机的生命周期。当你想要创建一个新的虚拟机时，Nova 就在幕后调度资源。
- Neutron（网络服务）：管理软件定义网络（SDN）。它允许你创建路由器、交换机，并为虚拟机分配 IP 地址。
- Cinder（块存储服务）：提供持久化块存储，类似于虚拟机的硬盘。
- Swift（对象存储服务）：用于存储非结构化数据，类似于 Amazon S3。
- Keystone（身份服务）：为所有 OpenStack 服务提供身份验证和授权。
实战示例：使用 OpenStack CLI 创建虚拟机
为了让你对 OpenStack 的工作方式有更直观的感受，让我们通过命令行工具 openstack 来执行一个简单的任务：创建一台名为 "test-server" 的虚拟机。
# 1. 首先登录并设置环境变量
export OS_AUTH_URL=http://your-openstack-domain:5000/v3
export OS_PROJECT_ID=
export OS_USERNAME=admin
export OS_PASSWORD=
export OS_USER_DOMAIN_NAME=Default
export OS_PROJECT_DOMAIN_NAME=Default
export OS_IDENTITY_API_VERSION=3
# 2. 列出可用的镜像，我们需要一个基础镜像来启动 VM
openstack image list
# 假设我们选择了一个名为 "ubuntu-20.04" 的镜像
# 3. 列出可用的硬件规格配置
openstack flavor list
# 假设我们选择了一个名为 "m1.small" 的配置
# 4. 列出内部网络
openstack network list
# 假设我们选择了一个名为 "public" 的网络
# 5. 创建虚拟机
# 我们使用 ubuntu-20.04 镜像，m1.small 规格，并绑定到 public 网络
openstack server create \
--flavor m1.small \
--image ubuntu-20.04 \
--nic net-id= \
--security-group default \
test-server
# 6. 检查服务器状态直到变为 ‘ACTIVE‘
openstack server show test-server
代码解读：这段代码展示了 OpenStack 作为 IaaS 的典型工作流。你需要手动处理底层资源，比如选择镜像、指定硬件规格（Flavor）和配置网络。这给了你极大的控制权，但也要求你对基础设施有深入的了解。你负责管理从操作系统层面往上的一切。
OpenStack 的优势与挑战
- 优势：
* 无限存储与多维扩展：通过 Swift 和 Ceph，OpenStack 可以轻松扩展到 PB 级别的数据存储。
* 无单点故障：大多数组件都是高可用的，没有中央数据库瓶颈。
* 标准化：它是构建私有云的标准选择，兼容 AWS EC2/S3 API。
- 挑战：
* 复杂性：部署和维护一个完整的 OpenStack 集群需要极高的技术门槛。
* 缺乏商业支持：虽然社区活跃，但对于寻求企业级 SLA 的公司来说，直接使用开源版可能需要寻求第三方咨询公司的付费支持。
什么是 OpenShift？PaaS 与容器编排的进化
OpenShift 是 Red Hat 推出的开源容器应用平台，基于 Kubernetes（K8s）构建，但增加了许多企业级功能。它于 2011 年首次发布，最初基于 GearD，后来完全转向 Kubernetes。OpenShift 的核心理念是“以应用为中心”，它让开发者不需要关心底层的 Linux 服务器或网络配置，只需关注代码和容器。
为什么是 OpenShift 而不是原生的 Kubernetes？
你可能会有疑问：“既然 OpenShift 基于 Kubernetes，为什么不直接用 K8s？” 这是一个很好的问题。原生的 Kubernetes 虽然强大，但非常复杂，需要配置很多细节（如 Ingress、Dashboard、CI/CD 流水线等）。OpenShift 提供了一个开箱即用的全栈解决方案，包括开发者友好的 Web 控制台、内置的镜像仓库（S2I 源到镜像）以及强化了的安全策略。
核心概念：Source-to-Image (S2I)
OpenShift 的一个杀手级特性是 S2I。它允许你提供源代码，而 OpenShift 自动将其编译并构建成可运行的 Docker 镜像。
实战示例：OpenShift 中的应用部署 (YAML)
在 OpenShift 中，我们通常不再管理虚拟机，而是管理“资源对象”。下面是一个典型的 OpenShift DeploymentConfig 示例，用于部署一个简单的 Node.js 应用。
# 这是一个名为 ‘nodejs-ex‘ 的部署配置示例
apiVersion: v1
kind: DeploymentConfig
metadata:
name: nodejs-ex
labels:
app: nodejs-ex
spec:
replicas: 3 # 指定我们希望运行 3 个副本以保证高可用性
selector:
app: nodejs-ex
deploymentconfig: nodejs-ex
strategy:
type: Rolling
rollingParams:
updatePeriodSeconds: 1
intervalSeconds: 1
timeoutSeconds: 600
maxUnavailable: 25%
maxSurge: 25%
triggers:
- type: ConfigChange # 当配置文件改变时自动触发部署
- type: ImageChange # 当镜像变化时自动触发部署
imageChangeParams:
automatic: true
containerNames:
- nodejs-ex
from:
kind: ImageStreamTag
name: nodejs-ex:latest
template:
metadata:
labels:
app: nodejs-ex
deploymentconfig: nodejs-ex
spec:
containers:
- name: nodejs-ex
image: ""
ports:
- containerPort: 8080
protocol: TCP
resources:
limits: # 资源限制，防止应用耗尽节点资源
memory: "512Mi"
cpu: "500m"
readinessProbe: # 就绪探针，确保容器准备好后才接收流量
tcpSocket:
port: 8080
initialDelaySeconds: 5
timeoutSeconds: 1
livenessProbe: # 存活探针，如果应用死锁则重启容器
httpGet:
path: /
port: 8080
initialDelaySeconds: 20
timeoutSeconds: 1
代码解读：这个 YAML 文件定义了应用的“期望状态”。我们声明需要 3 个副本，OpenShift（背后的 Kubernetes 集群）就会负责调度这 3 个容器运行在不同的节点上。注意 triggers 部分，OpenShift 支持自动化流水线，一旦构建了新的镜像，它就会自动更新部署。对于开发者来说，你不需要关心这 3 个副本具体运行在哪台服务器上，这是 PaaS 的核心价值。
OpenShift 的架构与特性
OpenShift 采用主从架构：
- Master 节点：托管 API 服务、Web 控制台和调度器，负责做出决策。
- Infrastructure 节点：运行监控、日志和路由器等基础设施组件。
- Worker 节点：实际运行你的用户容器。
主要特性：
- 灵活性：你可以轻松地在本地、AWS、Azure 或 OpenStack 之上部署 OpenShift 集群。
- 自动化：内置 CI/CD（Jenkins 管道）和自动化扩展（HPA）。
- 安全性：严格控制容器权限（通过 SCC），运行时强制实施 SELinux 策略。
潜在的挑战
尽管 OpenShift 功能强大，但在实际使用中你可能会遇到一些挑战：
- 监控复杂性：虽然内置 Prometheus，但监控微服务之间的网络流量（Service Mesh）需要额外配置。
- 日志管理：集群层面的日志非常庞大，EFK 栈的配置和维护相对复杂，初学者可能会觉得难以调试。
深度对比：OpenStack vs OpenShift
为了让你更清晰地做出技术选型，我们从以下几个维度对两者进行详细对比。
OpenStack
:—
基础设施即服务。它管理的是硬件虚拟化。
关注底层。关注虚拟机、存储卷、网络子网、安全组。
Python 编写。基于 Libvirt 管理虚拟化技术。
就像是操作一台“公有的服务器”。你有 Root 权限，可以安装任何 OS，但也得负责打补丁和运维。
可选。虽然可以使用 Magnum/Zun 项目支持容器，但这并非其核心用途，配置繁琐。
通常管理单一的数据中心集群。跨区域管理需要额外的 Magnum 或 Tricircle 项目。
提供 Cinder (块存储) 和 Swift (对象存储)。
需要运行无法容器化的传统应用（如旧版单体 Java 应用），或需要完全控制硬件和网络时。
协同作战：在 OpenStack 之上部署 OpenShift
你可能会问：“既然它们不同，能不能一起用？” 答案是肯定的，而且这是非常经典的架构模式。
在这个架构中，OpenStack 负责“生孩子”，提供虚拟机资源；而 OpenShift 负责“养孩子”，在这些虚拟机之上编排容器应用。
让我们来看看如何结合使用它们：
- 基础设施层：我们使用 OpenStack 部署一个强大的物理集群，利用 Neutron 提供软件定义网络（SDN），利用 Cinder 提供持久化存储。
- 平台层：我们在 OpenStack 的虚拟机中安装 OpenShift 集群。
- 自动化实例：这里我们展示如何使用 Terraform 代码，让 OpenStack 自动为 OpenShift 提供一个持久化存储卷。OpenShift 将会挂载这个卷来保存应用数据。
# Terraform 配置示例：在 OpenStack 上创建一个 OpenShift 使用的存储卷
resource "openstack_blockstorage_volume_v3" "openshift_pv" {
name = "openshift-pv-persistent"
description = "为 OpenShift Pod 提供的后端存储"
size = 20 # 创建 20GB 的卷
volume_type = "ssd" # 选择 SSD 类型以提高 IOPS
}
# 输出卷 ID，方便后续挂载
output "volume_id" {
value = "${openstack_blockstorage_volume_v3.openshift_pv.id}"
}
通过这种组合，你获得了两全其美的效果：OpenStack 的资源管理能力和 OpenShift 的应用部署敏捷性。
常见误区与最佳实践
在多年的架构设计经验中，我们总结了一些开发者在选择这两个平台时容易陷入的误区：
- 误区：有了 OpenShift 就不需要 OpenStack 了。
* 纠正：这取决于你的物理环境。如果你在使用公有云（如 AWS），你只需要 OpenShift（因为 AWS 已经提供了 IaaS）。但如果你是在私有数据中心裸机部署，OpenShift 需要一个运行的地方，这就是 OpenStack 或 VMware 发挥作用的地方。
- 误区：OpenStack 只能运行虚拟机。
* 纠正：虽然这是它的主要功能，但 OpenStack 也有容器编排项目。不过通常情况下，直接使用 OpenShift 会比配置 OpenStack 的容器工具要成熟和方便得多。
总结：如何选择？
让我们回到最初的那个问题：你应该选择哪一个？
- 选择 OpenStack，如果你的目标是构建一个类似 AWS 的云环境，你需要管理大量的虚拟机，出售基础资源，或者运行由于各种原因无法容器化的遗留应用。
- 选择 OpenShift，如果你的目标是开发现代化的云原生应用。如果你的开发团队专注于代码、微服务和持续交付，OpenShift 将极大地提升他们的效率。
展望未来，这两者的界限可能会越来越模糊（OpenStack 也在支持虚拟机上的容器化，即 OpenStack on Kubernetes），但在可预见的未来，它们作为“基础设施管理者”和“应用平台提供者”的定位依然稳固。希望这篇文章能帮助你理清思路，在实际的架构设计中做出最适合的选择。