概览

本文主要介绍了利用开源 github 社区的 Openshift 4 的 libvirt 实现来安装一个可以使用的 openshift 集群 ， 以及其中启动、控制和工作节点相关步骤的详细介绍。 [[X1]](#_msocom_1)

Openshift 分为 开源版本 和 商业版本 ，出于技术交流的目的，本文所讨论的都是开源版本，主要的代码都在 这里 。

对比 openshift 3 / 4 的安装和后续节点管理的工作，最重要的区别是针对云的概念的引入，从而极大程度的减轻管理员安装配置的负担，之前的 openshift3 所针对的安装环境都是以机器 (machine) 为对象通过 ansible 来安装，这样不仅复杂，而且极易出错；而 openshift4 的 Installer Provisioned Infrastructure (IPI) 所针对的安装环境主要是云，所有所需要的资源例如虚拟机 / 裸金属机，存储，网络，负载均衡都通过访问云 API 从而动态获得，极大的增加了安装的健壮性和弹性。 目前所支持的 cloud 列表可以参考 支持列表 。

Libvirt with KVM installer 作为一个单机开发的工具，可以提供方便的开发环境给开发者，同时，分析 libvirt 的安装过程也有助于读者深入浅出的理解 openshift 4 的安装过程以及 openshift4 内部组件的启动等内容。

基本概念

CoreOS 是一个基于 Linux 内核的轻量级操作系统，面向云和集群为主，其主要的优势是一致 、 安全 、 可靠。关于 CoreOS 具体可以参考 官方文档 , CoreOS 又分为 fedora Co reOS （社区版）和 RHEL CoreOS ( 商业版 ) ， CoreOS 作为云原生操作系统， ignition 是其很有特色以及和普通 Linux 不一样的地方 ， 下面这个 ignition 的实例主要的目的就是将生成的公钥注入部署出的虚拟机里，这样当 coreos 启动之后，可以通过公钥对应的私钥 ssh 登录。 Openshift4 中控制节点 (master) 必须是 CoreOS ，工作节点 (worker) 可以是 CoreOS 。

{

"ignition": {

"config": {},

"timeouts": {},

"version": "2.1.0"

},

"networkd": {},

"passwd": {

"users": [

{

"name": "core",

"sshAuthorizedKeys": [

"ssh-rsa ABCD..."

]

}

]

},

….

}

Operator: 简化应用程序部署和生命周期管理—— 自动化 的执行应用程序维护，扩展，故障转移等工作 , openshift 4 的控制面几乎都建立在 operator 之上，关于 operator 可以参考 概念介绍 ，如果读者对 Operater 的概念不是很理解，也可以参考这里的 实验教程 。

Cluster API: Cluster API 是一个 Kubernetes 之上的可选项目，它使用 Kuber ne tes 的 扩展机制(Custom Resource Definition) 来创建、配置和管理集群 (Cluster) 。关于 Cluster API 的用况，范围等内容可以参考 这篇 和 这篇 文章， Cluster API 作为通用的 Kubernetes 集群管理框架，有许多不同种类的云提供商都以 Cluster API 为基础，您可从 此处 获取云提供商的完整列表。 Openshift installer 基于 Cluster API 的 Kubernetes 版本做了一定修改 来创建工作节点。

Terraform: 一种构建、更改和版本控制基础设施的工具 (Infrastructure as code) ，针对业界 几乎所有的云平台都有自己的实现 ， 例如 aws, openstack; libvirt 等 也有自己的 provider 实现， libvirt 的实现 一般只是拿来作为开发和测试使用的 ， openshift installer 的 libvirt 安装方法 现在使用 terraform 的 libvirt 实现来完成基于 libvirt 集群的控制面创建 (bootstrap 节点， master 节点 ) ，而 worker 节点则是通过 Cluster API libvirt 来安装的。 从开发和测试的角度来说，如果本地有机器，通过 libvirt 创建开发环境是最经济和方便的 。

环境准备

笔者使用的是 RHEL7.6 ，请准备好基本和扩展的 yum 源以备安装时使用 ， 另外，默认的 libvirt 会创建至少三个虚拟机（ bootstrap 启动节点， master 节点，工作节点）， 而每个虚拟机的内存默认为 6G ，所以主机至少配置 24G 内存以上保证工作 。

安装和更新必要的软件

首先[[X2]](#_msocom_2) ，需要安装必要的文件，这些包作为编译的依赖如果不安装，在编译过程中会出现错误：

# yum -y install gcc gcc-c++ automake libtool zlib-devel glib2-devel bzip2-devel libuuid-devel spice-protocol spice-server-devel usbredir-devel libaio-devel golang-bin

如果找不到 golang-bin ， 可以考虑从 golang 官网直接搜索 golang 的可执行文件 ， 并把 golang 可执行文件放在目录 。

qemu 更新

笔者的 RHEL7.6 环境下默认的 qemu 版本是 1.5.3 ， 然而由于 openshift 4 libvirt 使用了 fw_cfg 设备来完成 ingition 的初始化 ， 而该版本的 qemu 是不支持 fw_cfg 的 ，如果不更新 qemu 的话在安装过程中由于不能创建 fw_cfg 设备会遇到错误， 所以需要通过使能 kvm-common 这个源来更新 qemu-kvm , 具体请参考 这里 。

编译openshift-installer

从 github 下载 openshift-install er ，编译 openshift-installer ，由于 libvirt 是开发和测试使用的，所以默认编译 之后所支持的安装列表 是不支持 libvirt 的，需要加入 TAGS=libvirt 这个 tag 从而 在编译过程来加入 libvirt 支持 。

[root@jj-installer installer]# TAGS=libvirt hack/build.sh

• minimum_go_version=1.12

++ go version

++ cut -d ' ' -f 3

• current_go_version=go1.12.9

++ version 1.12.9

++ IFS=.

++ printf '%03d%03d%03d\n' 1 12 9

++ unset IFS

++ version 1.12

++ IFS=.

++ printf '%03d%03d%03d\n' 1 12

++ unset IFS

• '[' 001012009 -lt 001012000 ']'
• LAUNCH_PATH=/root/go/src/github.com/openshift/installer

++ dirname hack/build.sh

• cd hack/..

++ go list -e -f '{{.Dir}}' github.com/openshift/installer

• PACKAGE_PATH=/root/go/src/github.com/openshift/installer
• test -z /root/go/src/github.com/openshift/installer
• LOCAL_PATH=/root/go/src/github.com/openshift/installer
• test /root/go/src/github.com/openshift/installer '!=' /root/go/src/github.com/openshift/installer
• MODE=release

++ git rev-parse --verify 'HEAD^{commit}'

• GIT_COMMIT=d70ea3ee878a6c09ae309d614746107f05f207b5

++ git describe --always --abbrev=40 --dirty

• GIT_TAG=unreleased-master-2274-gd70ea3ee878a6c09ae309d614746107f05f207b5
• LDFLAGS=' -X github.com/openshift/installer/pkg/version.Raw=unreleased-master-2274-gd70ea3ee878a6c09ae309d614746107f05f207b5 -X github.com/openshift/installer/pkg/version.Commit=d70ea3ee878a6c09ae309d614746107f05f207b5'
• TAGS=libvirt
• OUTPUT=bin/openshift-install
• export CGO_ENABLED=0
• CGO_ENABLED=0
• case "${MODE}" in
• LDFLAGS=' -X github.com/openshift/installer/pkg/version.Raw=unreleased-master-2274-gd70ea3ee878a6c09ae309d614746107f05f207b5 -X github.com/openshift/installer/pkg/version.Commit=d70ea3ee878a6c09ae309d614746107f05f207b5 -s -w'
• TAGS='libvirt release'
• test '' '!=' y
• go generate ./data

writing assets_vfsdata.go

• echo 'libvirt release'
• grep -q libvirt
• export CGO_ENABLED=1
• CGO_ENABLED=1
• go build -ldflags ' -X github.com/openshift/installer/pkg/version.Raw=unreleased-master-2274-gd70ea3ee878a6c09ae309d614746107f05f207b5 -X github.com/openshift/installer/pkg/version.Commit=d70ea3ee878a6c09ae309d614746107f05f207b5 -s -w' -tags 'libvirt release' -o bin/openshift-install ./cmd/openshift-install

修改libvirt配置

由于默认 libvirt 的 tcp 端口没有打开，因此需要通过修改 libvirt daemon 的配置来打开 TCP 连接端口 (16509) 。

需要修改如下文件 ：

/etc/libvirt/libvirtd.conf listen_tls = 0

listen_tcp = 1

auth_tcp="none"

tcp_port = "16509"

/etc/sysconfig/libvirtd LIBVIRTD_ARGS="--listen"

重启 libvirtd 服务 ：

systemctl restart libvirtd 确认 libvirtd 在 16509 端口上监听 tcp 请求 ： [root@jj-installer installer]# netstat -tlunp | grep libvirt

tcp 0 0 0.0.0.0:16509 0.0.0.0:* LISTEN 3696/libvirtd

安装集群

到现在为止我们已经完成了所有的安装准备，下面可以开始安装 openshift 集群了 :

使用如下命令 ，我们会被要求提供一定的输入， 具体的参数选择如下 :

[root@jj-installer installer]# bin/openshift-install create cluster

? SSH Public Key /root/.ssh/id_rsa.pub

? Platform libvirt

? Libvirt Connection URI qemu+tcp://192.168.122.1/system

? Base Domain tt.testing

? Cluster Name test1

? Pull Secret [? for help

…

INFO Fetching OS image: rhcos-42.80.20190827.1-qemu.qcow2 *

INFO Creating infrastructure resources...

INFO Waiting up to 30m0s for the Kubernetes API at https://api.test1.aa.testing:6443...

Ssh public key: 如果选择了某个公钥 (public key) 文件 ， 该公钥文件会 通过 Ignition 被注入部署出来的 CoreOS 机器 ， 这样 当遇到需要登录 CoreOS 的时候 （ 例如调试等 ） 可以通过 ssh 的方式来 登录该 Co reOS, 该方法主要是开发测试中使用。

Platform: 选择 libvirt 平台 ， 如果前面编译的时候没有增加 TAGS=libvirt ， 这里就不会出现 libvirt 的选项。

Libvirt connection URI: Libvirt 连接 URI ， 默认是 qemu+tcp ://192.168.122.1/system, 除非运行 installer 的节点和运行 libvirtd （ 也就是集群运行的节点 ） 不同 ， 这个参数我们可以选择默认参数 ； 如果存在不同节点的情况例如 installer 是 x86 平台而 libvirtd 是 IBM system z 平台 ， 可以调整该参数。

Base Domain: 基本域名 。

Cluster Name: 集群名字 ， Base Domain 和 Cluster Name 会在集群的 Ingress /Router 中使用。

Pull Secret: 请使用 ‘ ? ’ 搜索 ， 如果没有的话，需要访问 这里 并获取一个令牌 (Token) 。

集群安装过程分析

首先 openshift installer 会使用 terraform （通过 terraform libvirt provider ） 通过 libvirt 来 创建两 台虚拟机 ， 其中 一个是启动节点（ bootstrap ），另一个是控制节点 (master) ， 而 terraform 在创建虚拟机过程中的 参数是根据上述准备过程用户输入生成的，当然，也可以根据实际需要修改很多默认值（例如默认工作节点数量是 1 ），本文不再赘述。

当虚拟机创建完成之后，可以观察到虚拟机情况如下所示 ，在笔者的环境中使用了 test1 作为 集群的名字， bootstrap 代表启动节点， master 代表控制节点。

[root@jj-installer ~]# virsh list --all

Id Name State

11 test1-gbvhv-bootstrap running

13 test1-gbvhv-master-0 running

虚拟机创建完成之后， 我们可以 通过 virsh console 命令 登入 bootstrap 和 master 节点 ，在 bootstrap 和 master 的启动阶段 会 执行 ignition 从而 完成所有的配置和初始化工作 。 [[X3]](#_msocom_3)

首先 进入 Bootstrap 节点，请注意 这个 IP 192.168.126.10 是 固定的 ，并且由于在 笔者的环境中 选择了 注

入 ssh public key ， 这样 当 ingition 完成之后我们可以通过私钥 ( private key) 无密码访问 bootstrap 节点 。

[root@jj-installer ~]# ssh core@192.168.126.10

Warning: Permanently added '192.168.126.10' (ECDSA) to the list of known hosts.

Red Hat Enterprise Linux CoreOS 42.80.20190827.1

WARNING: Direct SSH access to machines is not recommended.

This is the bootstrap node; it will be destroyed when the master is fully up.

The primary service is "bootkube.service". To watch its status, run e.g.

journalctl -b -f -u bootkube.service

[core@test1-vrqms-bootstrap ~]$

Bootstrap 节点启动 日志 （节选）（通过 journalctl -b -f -u bootkube.service 查看） 。

Sep 03 08:30:36 test1-gbvhv-bootstrap systemd[1]: Started Bootstrap a Kubernetes cluster.

Sep 03 08:31:06 test1-gbvhv-bootstrap bootkube.sh[1624]: Rendering Cluster Version Operator Manifests...

Sep 03 08:31:28 test1-gbvhv-bootstrap bootkube.sh[1624]: Rendering cluster config manifests...

Sep 03 08:31:36 test1-gbvhv-bootstrap bootkube.sh[1624]: Rendering Kubernetes API server core manifests...

Sep 03 08:31:44 test1-gbvhv-bootstrap bootkube.sh[1624]: Rendering Kubernetes Controller Manager core manifests...

Sep 03 08:31:52 test1-gbvhv-bootstrap bootkube.sh[1624]: Rendering Kubernetes Scheduler core manifests...

Sep 03 08:32:01 test1-gbvhv-bootstrap bootkube.sh[1624]: Rendering MCO manifests...

Sep 03 08:32:14 test1-gbvhv-bootstrap bootkube.sh[1624]: Starting etcd certificate signer...

Sep 03 08:32:31 test1-gbvhv-bootstrap bootkube.sh[1624]: Waiting for etcd cluster...

Sep 03 08:37:39 test1-gbvhv-bootstrap bootkube.sh[1624]: https://etcd-0.test1.tt.testing:2379 is healthy: successfully committed propo>

Sep 03 08:37:40 test1-gbvhv-bootstrap bootkube.sh[1624]: etcd cluster up. Killing etcd certificate signer...

Sep 03 08:37:41 test1-gbvhv-bootstrap bootkube.sh[1624]: Starting cluster-bootstrap..

Sep 03 08:37:48 test1-gbvhv-bootstrap bootkube.sh[1624]: Starting temporary bootstrap control plane...

Sep 03 08:43:21 test1-gbvhv-bootstrap bootkube.sh[1624]: Tearing down temporary bootstrap control plane...

Sep 03 08:43:22 test1-gbvhv-bootstrap bootkube.sh[1624]: bootkube.service complete

Bootstrap 主要作用是创建一个临时的 Kubernetes 控制面帮助 openshift 集群的创建，当集群创建成功之后， bootstrap 节点会被删除。

接着可以进入 Master 节点， 请注意这个 IP 192.168.126.11 也是 固定的 。

Master 节点启动记录 （节选）。

GET https://api-int.test1.aa.testing:22623/config/master: attempt #1

GET error: Get https://api-int.test1.aa.testing:22623/config/master: dial tcp: dial tcp: lookup api-int.test1.aa.testing on [::1]:53: read udp [::1]:39836->[::1]:53: read

GET https://api-int.test1.aa.testing:22623/config/master: attempt #122

fetched referenced config at https://api-int.test1.aa.testing:22623/config/master with SHA512: ccc337da770

Started Ignition (disks)

Ignition finished successfully

reading system config file "/usr/lib/ignition/base.ign"

Ignition finished successfully

Starting Kubernetes Kubelet...

Reading config file "/etc/kubernetes/manifests/etcd-member.yaml"

Master 节点启动 etcd 命令。

set -euo pipefail

source /run/etcd/environment

exec etcd grpc-proxy start \

--endpoints https://${ETCD_DNS_NAME}:9978 \

--metrics-addr https://0.0.0.0:9979 \

--listen-addr 127.0.0.1:9977 \

--key /etc/ssl/etcd/system:etcd-peer:${ETCD_DNS_NAME}.key \

--key-file /etc/ssl/etcd/system:etcd-metric:${ETCD_DNS_NAME}.key \

--cert /etc/ssl/etcd/system:etcd-peer:${ETCD_DNS_NAME}.crt \

--cert-file /etc/ssl/etcd/system:etcd-metric:${ETCD_DNS_NAME}.crt \

--cacert /etc/ssl/etcd/ca.crt \

--trusted-ca-file /etc/ssl/etcd/metric-ca.crt \

启动过程略 图如下 ，其中包括了 bootstrap ， master 和 worker( 工作 ) 节点 :

集群安装结果

通过如下命令 显示所有的 operator ，确保所有的 operator 的状态都是 AVAILABLE.

[root@test1-gbvhv-master-0 ~]# oc get co

NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE

…

network 4.2.0-0.okd-2019-09-03-003428 True False False 19h

node-tuning 4.2.0-0.okd-2019-09-03-003428 True False False 19h

openshift-apiserver 4.2.0-0.okd-2019-09-03-003428 True False False 18m

openshift-controller-manager 4.2.0-0.okd-2019-09-03-003428 True False False 18h

openshift-samples 4.2.0-0.okd-2019-09-03-003428 True False False 18h

operator-lifecycle-manager 4.2.0-0.okd-2019-09-03-003428 True False False 19h

operator-lifecycle-manager-catalog 4.2.0-0.okd-2019-09-03-003428 True False False 19h

operator-lifecycle-manager-packageserver 4.2.0-0.okd-2019-09-03-003428 True False False 12m

service-ca 4.2.0-0.okd-2019-09-03-003428 True False False 19h

service-catalog-apiserver 4.2.0-0.okd-2019-09-03-003428 True False False 19h

service-catalog-controller-manager 4.2.0-0.okd-2019-09-03-003428 True False False 19h

storage 4.2.0-0.okd-2019-09-03-003428 True False False 19h

…

当前所有的节点信息如下，可以发现，当集群建立好之后，会默认多出一 个 worker 的节点，这是因为在我们的集群定义里加上了一个 worker 节点，当集群部署之后（确切的说是 machine-api-provider operator 正常运行），该 worker 节点会被创建。

[root@jj-installer ~]# virsh list --all

Id Name State

11 test1-gbvhv-bootstrap running

13 test1-gbvhv-master-0 running

18 test1-gbvhv-worker-0-k2kd2 running

我们可以尝试增加节点数量 ，利用声明式的 API 来定义需要的 worker 数量，我们可以通过 machine-api-provider operator 来自动调整 worker 节点。

[root@test1-gbvhv-master-0 ~]# oc scale --replicas=3 machineset test1-gbvhv-worker-0 -n openshift-machine-api

machineset.machine.openshift.io/test1-gbvhv-worker-0 scaled

通过如下命令 可以看出我们的集群工作节点从一个变成了三个 。

[root@jj-installer ~]# virsh list

Id Name State

11 test1-gbvhv-bootstrap running

13 test1-gbvhv-master-0 running

18 test1-gbvhv-worker-0-k2kd2 running

19 test1-gbvhv-worker-0-6n7dp running

20 test1-gbvhv-worker-0-btspb running

删除集群

创建完成之后，可以通过如下命令来删除所有申请的资源，主要包含创建的 domain 、 network 、 volume 和 pool 等 自动创建的资源 。

bin/openshift-install destroy cluster

INFO Deleted domain domain=test1-vrqms-master-0

INFO Deleted domain domain=test1-vrqms-worker-0-v95wl

INFO Deleted domain domain=test1-vrqms-bootstrap

INFO Deleted network network=test1-vrqms

INFO Deleted volume volume=test1-vrqms-bootstrap

INFO Deleted volume volume=test1-vrqms-bootstrap.ign

INFO Deleted volume volume=test1-vrqms-master-0

INFO Deleted volume volume=test1-vrqms-master.ign

INFO Deleted volume volume=test1-vrqms-worker-0-v95wl

INFO Deleted volume volume=test1-vrqms-base

INFO Deleted volume volume=test1-vrqms-worker-0-v95wl.ignition

INFO Deleted pool pool=test1-vrqms

结束语

本 文 简述了 openshift 4 的 installer 如何利用 libvirt 来创建一个最简的集群来帮助开发和测试工作，主要介绍了 bootstrap 和 master 两个节点的启动过程以及 ignition 的执行过程 以及 worker 节点的创建过程 ，帮助读者了解 openshift 4 内部的一些基本实现机制。