Overcloud

注意

本文档旨在指导配置一个最小化的全合一 Overcloud 主机。如果您正在寻找一个用于测试或开发的集成环境，请参阅 自动化设置。

准备工作

使用在 先决条件 中描述的 bootstrap 用户来访问机器。

如 概述 中所述，我们将使用桥接 (br0) 和虚拟接口 (dummy0) 进行控制平面网络。使用以下命令创建它们，并将静态 IP 地址 192.168.33.3 分配给桥接。

sudo ip l add br0 type bridge
sudo ip l set br0 up
sudo ip a add 192.168.33.3/24 dev br0
sudo ip l add dummy0 type dummy
sudo ip l set dummy0 up
sudo ip l set dummy0 master br0

此配置不是持久性的，如果虚拟机重启则必须重新创建。

安装

按照 安装 中的说明设置 Ansible 控制主机环境。通常这将在单独的机器上完成，但在这里我们尽可能保持简单。

配置

克隆 kayobe-config git 仓库，使用与您部署的发行版相对应的分支。在本例中，我们将使用 stable/2025.2 分支。

cd <base path>/src
git clone https://opendev.org/openstack/kayobe-config.git -b stable/2025.2
cd kayobe-config

该仓库是空的，需要填充。该仓库包含一个示例清单，应该将其删除。

git rm etc/kayobe/inventory/hosts.example

创建一个 Ansible 清单文件，并将机器添加到其中。在本例中，我们的机器名为 controller0。由于这是一个全合一环境，我们将控制器添加到 compute 组，但通常会使用专用的计算节点。

etc/kayobe/inventory/hosts

# This host acts as the configuration management Ansible control host. This must be
# localhost.
localhost ansible_connection=local

[controllers]
controller0

[compute:children]
controllers

inventory 目录还包含网络接口配置的组变量。在本例中，我们将假设该机器只有一个名为 dummy0 的网络接口。我们将创建一个名为 br0 的桥接，并将 dummy0 插入其中。将 controllers 组的网络接口配置替换为以下内容：

etc/kayobe/inventory/group_vars/controllers/network-interfaces

# Controller interface on all-in-one network.
aio_interface: br0

# Interface dummy0 is plugged into the all-in-one network bridge.
aio_bridge_ports:
  - dummy0

在此场景中，使用单个名为 aio 的网络。因此，我们必须将默认控制器的网络名称设置为 aio。

etc/kayobe/networks.yml

---
# Kayobe network configuration.

###############################################################################
# Network role to network mappings.

# Map all networks to the all-in-one network.

# Name of the network used for admin access to the overcloud
#admin_oc_net_name:
admin_oc_net_name: aio

# Name of the network used by the seed to manage the bare metal overcloud
# hosts via their out-of-band management controllers.
#oob_oc_net_name:

# Name of the network used by the seed to provision the bare metal overcloud
# hosts.
#provision_oc_net_name:

# Name of the network used by the overcloud hosts to manage the bare metal
# compute hosts via their out-of-band management controllers.
#oob_wl_net_name:

# Name of the network used by the overcloud hosts to provision the bare metal
# workload hosts.
#provision_wl_net_name:

# Name of the network used to expose the internal OpenStack API endpoints.
#internal_net_name:
internal_net_name: aio

# List of names of networks used to provide external network access via
# Neutron.
# Deprecated name: external_net_name
# If external_net_name is defined, external_net_names will default to a list
# containing one item, external_net_name.
#external_net_names:
external_net_names:
  - aio

# Name of the network used to expose the public OpenStack API endpoints.
#public_net_name:
public_net_name: aio

# Name of the network used by Neutron to carry tenant overlay network traffic.
#tunnel_net_name:
tunnel_net_name: aio

# Name of the network used to carry storage data traffic.
#storage_net_name:
storage_net_name: aio

# Name of the network used to carry storage management traffic.
#storage_mgmt_net_name:
storage_mgmt_net_name: aio

# Name of the network used to carry swift storage data traffic.
#swift_storage_net_name:

# Name of the network used to carry swift storage replication traffic.
#swift_storage_replication_net_name:

# Name of the network used to perform hardware introspection on the bare metal
# workload hosts.
#inspection_net_name:

# Name of the network used to perform cleaning on the bare metal workload
# hosts
#cleaning_net_name:

###############################################################################
# Network definitions.

<omitted for clarity>

接下来，必须定义 aio 网络。这是使用在 网络配置 中描述的各种属性完成的。应根据环境调整这些值。aio_vip_address 变量应该是 OpenStack API 虚拟 IP 地址的同一子网中的一个空闲 IP 地址。

etc/kayobe/networks.yml

<omitted for clarity>

###############################################################################
# Network definitions.

# All-in-one network.
aio_cidr: 192.168.33.0/24
aio_vip_address: 192.168.33.2

###############################################################################
# Network virtual patch link configuration.

<omitted for clarity>

Kayobe 将自动分配 IP 地址。在这种情况下，我们希望确保主机使用它当前拥有的相同 IP 地址，以避免失去连接。我们可以通过填充网络分配文件来实现这一点。使用您环境中的正确主机名和 IP 地址。

etc/kayobe/network-allocation.yml

---
aio_ips:
  controller0: 192.168.33.3

Kayobe 中的默认操作系统发行版是 CentOS。如果使用 Ubuntu 主机，请将 os_distribution 变量设置为 etc/kayobe/globals.yml 中的 ubuntu 或 rocky（如果使用 Rocky Linux）。

etc/kayobe/globals.yml

os_distribution: "ubuntu"

Kayobe 使用 bootstrap 用户创建一个 stack 用户帐户。默认情况下，此用户在 CentOS 上为 cloud-user，在 Rocky 上为 rocky，在 Ubuntu 上为 ubuntu，这与官方云镜像中的默认用户一致。如果您正在使用不同的 bootstrap 用户，请将 controller_bootstrap_user 变量设置为 etc/kayobe/controllers.yml。例如，要将其设置为 cloud-user（如 MAAS 中所示）：

etc/kayobe/controllers.yml

controller_bootstrap_user: "cloud-user"

默认情况下，在禁用 SELinux 的系统上，Kayobe 会将 SELinux 置于 permissive 模式并重启系统以应用更改。在测试或开发环境中，这可能会有些破坏性，尤其是在使用临时网络配置时。为了避免在启用 SELinux 后重启系统，请将 selinux_do_reboot 设置为 etc/kayobe/globals.yml 中的 false。

etc/kayobe/globals.yml

selinux_do_reboot: false

在开发环境中，我们可能希望调整一些 Kolla Ansible 变量。如果 KVM 不可用，使用 QEMU 作为虚拟化类型将是必要的。减少 OpenStack 服务工作进程的数量有助于避免使用过多的内存。

etc/kayobe/kolla/globals.yml

# Most development environments will use nested virtualisation, and we can't
# guarantee that nested KVM support is available. Use QEMU as a lowest common
# denominator.
nova_compute_virt_type: qemu

# Reduce the control plane's memory footprint by limiting the number of worker
# processes to one per-service.
openstack_service_workers: "1"

我们可以看到对配置所做的更改。

cd <base path>/src/kayobe-config
git status

On branch master
Your branch is up to date with 'origin/master'.

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
    deleted:    etc/kayobe/inventory/hosts.example

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
    modified:   etc/kayobe/globals.yml
    modified:   etc/kayobe/inventory/group_vars/controllers/network-interfaces
    modified:   etc/kayobe/kolla/globals.yml
    modified:   etc/kayobe/networks.yml

Untracked files:
  (use "git add <file>..." to include in what will be committed)
    etc/kayobe/inventory/hosts
    etc/kayobe/network-allocation.yml

git diff 命令也很有用。完成所有配置更改后，应将其提交到 kayobe-config git 仓库。

cd <base path>/src/kayobe-config
git add etc/kayobe/inventory/hosts etc/kayobe/network-allocation.yml
git add --update
git commit -m "All in one scenario config"

在实际环境中，这些更改将被推送到中央仓库。

部署

我们现在准备执行部署了。

激活 Kayobe 虚拟环境

cd <base path>/venvs/kayobe
source bin/activate

激活 Kayobe 配置环境

cd <base path>/src/kayobe-config
source kayobe-env

Bootstrap 控制主机

kayobe control host bootstrap

配置 Overcloud 主机

kayobe overcloud host configure

此命令运行后，kayobe-config 仓库中的一些文件将发生更改。Kayobe 执行 IP 地址的静态分配，并在 etc/kayobe/network-allocation.yml 中跟踪它们。通常可能会对此文件进行更改，但在此例中，我们之前手动添加了 controller0 的 IP 地址。Kayobe 使用 Kolla Ansible 提供的工具生成密码，并将其存储在 etc/kayobe/kolla/passwords.yml 中。跟踪此文件的更改非常重要。

cd <base path>/src/kayobe-config
git add etc/kayobe/kolla/passwords.yml
git commit -m "Add autogenerated passwords for Kolla Ansible"

拉取 Overcloud 容器镜像

kayobe overcloud container image pull

部署 Overcloud 服务

kayobe overcloud service deploy

测试

Kolla Ansible 提供的 init-runonce 脚本（不用于生产环境）可用于设置一些用于测试的资源。这包括

• 一些 flavor

• 一个 cirros 镜像

• 一个外部网络

• 一个租户网络和路由器

• ICMP、SSH 和 TCP 端口 8000 和 8080 的安全组规则

• 一个 SSH 密钥

• 增加配额

对于外部网络，使用与之前相同的子网，并使用包含空闲 IP 地址的分配池范围

pip install python-openstackclient
export EXT_NET_CIDR=192.168.33.0/24
export EXT_NET_GATEWAY=192.168.33.3
export EXT_NET_RANGE="start=192.168.33.4,end=192.168.33.254"
source "${KOLLA_CONFIG_PATH:-/etc/kolla}/admin-openrc.sh"
${KOLLA_SOURCE_PATH}/tools/init-runonce

创建一个服务器实例，分配一个浮动 IP 地址，并检查是否可以访问它。

openstack server create --image cirros --flavor m1.tiny --key-name mykey --network demo-net demo1
openstack floating ip create public1

浮动 IP 地址在创建后显示，在本例中为 192.168.33.4

openstack server add floating ip demo1 192.168.33.4
ssh cirros@192.168.33.4