この記事の位置づけ
Ubuntu 22.04 を OpenShift / OKD / OCP 検証の作業端末として使うための記事です。OpenShift クラスタそのものの一般的な構築手順ではなく、SNO 検証に必要な DNS、NTP、Web、CLI ツール、周辺サービスを Ubuntu 側でどう準備するかを整理します。
この記事で扱う範囲
この記事の主語は OpenShift クラスタではなく、OpenShift を構築・検証するための Ubuntu 側の作業環境です。OpenShift は Red Hat の製品であり、クラスタノードやインストーラー自体には固有の前提があります。一方で、DNS、NTP、HTTP、CLI ツール、作業用端末は Ubuntu でも構成できます。
| 要素 | この記事での扱い |
| Workbox | openshift-install、oc、kubectl、podman などを置く作業端末 |
| DNS | api、api-int、*.apps、ノード名の名前解決を提供する |
| NTP | クラスタと周辺コンポーネントの時刻同期を揃える |
| Web | Ignition や ISO など、インストール時に参照するファイルを配布する |
| LoadBalancer | SNO では不要。複数ノード構成では外部に必要になる |
| Proxy | 閉域・プロキシ環境ではログ確認や通信制御のために重要になる |
| TFTP / PXE | PXE ブートを使う場合の補助要素 |
| NFS | 永続ボリューム検証で必要になる場合がある |
先に決めるべきこと
OpenShift 検証では、インストール手順より前にネットワークと名前解決を決めることが重要です。特に api、api-int、*.apps、クラスターネットワーク、サービスネットワークは、あとから雑に変えると切り分けが難しくなります。
- クラスタ名とベースドメインを決める。
- OCP Node、Workbox、DNS、Web などの IP アドレスを決める。
- クラスターネットワークとサービスネットワークが既存ネットワークと重複しないことを確認する。
- SNO なのか、複数ノード構成なのかを先に決める。
- プロキシ環境、閉域環境、直接インターネット接続のどれで検証するかを決める。
OpenShift 検証端末の全体像
OpenShift 構築環境を Ubuntu で構築します。OCP は Red Hat の製品ですが、構築に必要な周辺環境は Ubuntu でも構築可能です。本稿では Ubuntu KVM 上に SNO (Single Node OpenShift) を構築します。
必要な周辺コンポーネント
OCP Node 以外の必要な周辺コンポーネントは下記の通りです。本稿の例では簡易的に全て同一ホストでサービスしますが、一般的な本番環境では各コンポーネント毎にホストを分けることになるでしょう。
| 項目 | 内容 |
|---|---|
| Workbox | openshift-install, oc, kubectl, podman 等の必要なコマンドをインストールするホストです。つまり OCP インストールにおける操作端末です。Workbox という名前は適当(作業箱)です。OCP のダッシュボードにアクセスする為に GUI も入れておくと良いでしょう。 |
| DNS | DNS は必須のコンポーネントです。OCP Node の正引き逆引き、api, api-int, *.apps の正引きが必要です。 |
| NTP | NTP は必須のコンポーネントです。既存の NTP を指定すれば問題ありませんが、プロキシと同じく、検証では子 NTP を用意すると切り分け等で役立つかもしれません。 |
| DHCP(本稿では未使用) | OCP は固定 IP アドレスもサポートしているので DHCP は必須ではありませんが、固定 IP アドレスは構築手順や後述の設定ファイル量が多くなる為、どうしても固定 IP アドレスにしたい事情がない限りは DHCP がお勧めです。OCP Node の MAC アドレスをベースにして DHCP から割り振る IP アドレスを固定にします。これは DNS レコードに登録が必要となる為です。永続的なという観点では DHCP のリース時間を無制限にする良いでしょう。 |
| Web(本稿では未使用) | Web は Ignition ファイルの配信、必要に応じて ISO ファイルの配信を行います。本稿では Workbox でサービスします。ISO に Ignition を埋め込む(カスタム ISO)場合は必須ではありません。 |
| LoadBalancer(本稿では未使用、SNO では不要) | OCP(SNO 以外)の稼働には外部の LoadBalancer が必要です。この LoadBalancer は良くある Kubernetes の Service リソースではありません。OCP のクラスタを構成する時点で必要となる為、外部に配置する必要があります。所感としてこれは良くないポイントです。OCP の構築例では、良く HAProxy が使用されていますが、他の製品でも問題ありません。 |
| Proxy(本稿では未使用) | 一般的な社内ネットワークではインターネットアクセスにプロキシを使用しています。この場合、既存のプロキシを指定するだけで問題ありませんが、検証では OCP 構築時にプロキシのログを確認できると便利な場合がある為、必要に応じて子プロキシを用意すると良いでしょう。クラウド環境等で直接インターネットにアクセスできる場合は必須ではありません。 |
| TFTP(本稿では未使用) | PXE を使用する場合は必要です。PXE を使用すると、起動時にコンソールで Ignition を指定するコマンドの入力が不要となり、かなり楽です。 |
| NFS(本稿では未使用) | 永続ボリューム用です。永続的なデータが必要となるコンテナを稼働させる場合、複数ノードクラスターでは必須です。 |
リソース要件
リソース要件を確認します。
OCP Node
OpenShift 4.11 における SNO の最低要件は下記の通りです。公式ドキュメントはこちらです。
| CPU | RAM | ストレージ |
|---|---|---|
| 8 Core | 16 GB | 120 GB |
本稿の検証環境では下記の仮想マシンを使用しました。このリソースでは途中まで進みますが、最終的に必要な Operator が起動せず、検証環境としてはメモリ不足でした。SNO を現実的に検証する場合は、公式要件に近いリソースを確保した方が安全です。
| CPU | RAM | ストレージ |
|---|---|---|
| 2 Core | 8 GB | 80 GB |
その他のコンポーネント
その他のコンポーネントに特別なリソース要件はありません。負荷状況を確認しながら適切なリソースを割り当てて下さい。構成設計によりますが、一例として多数のクラスタを単一の DNS, LoadBalancer に収容する場合はそれらのサイジングや拡張性も重要になります。
設計
必要な設定値を決めます。
ネットワーク
ネットワークで必要な設定値を決めます。
L3 セグメント
まずはネットワーク全体のデザインを決めます。下記は本稿の検証環境で使用する構成です。
| セグメント | ネットワーク | 備考 |
|---|---|---|
| 管理 | 10.0.32.0/24 | 周辺コンポーネントを配置します。 |
| OCP Node | 10.0.33.0/24 | OCP Node を配置します。 |
| クラスターネットワーク | 10.128.0.0/14 | Pod IP の割り当てに使用される IP アドレスのブロック(OCP 内部セグメント)です。 |
| サービスネットワーク | 172.30.0.0/16 | サービス IP アドレスに使用する IP アドレスプール(OCP 内部セグメント)です。 |
クラスターネットワーク、サービスネットワークは OCP 内で使用されるネットワークアドレスとなり、上記の設定値は Red Hat のサンプルに記載されているものです。実際にはネットワーク全体で重複しないネットワークアドレスを割り当てる必要があります。
良く「OCP 内部で使われるアドレスだから何でも良い」と聞くことがありますが、それは間違いです。例えば、OCP の外にある 10.128.0.0/14 から下記の CIDR で構築した OCP の Pod にアクセスすると、Pod は connected になる為、通信が成り立ちません。このような観点は、日本的な縦割り組織でのサーバーエンジニアでは気づけない場合があるので、必要に応じてネットワークエンジニアもアサインしたほうが良いでしょう。これに限らず「このアドレスは何でもいい」という場合がたまにありますが、何でもいいという根拠をしっかり考えるようにしましょう。
補足として、Prefix は制限があるはずなので(多分、範囲外の Prefix はマニフェストを生成する際にエラーがでます)、事前に確認してネットワークをアサインする必要があります。
IP アドレス / ホスト名
IP アドレスとホスト名を決めます。ocp-test は必要コンポーネントをサービスするホストです。OCP ではクラスタ毎に一意のクラスタ名が必要となります。クラスタ名と表現されますが、これはサブドメインです。つまり、クラスタ名を sno、全体のドメインが si1230.com である場合、sno.si1230.com というドメインになります。
| コンポーネント | Hostname | IP Addr | Gateway | DNS |
|---|---|---|---|---|
| 必要な周辺コンポーネント | ocp-workbox.si1230.com | 10.0.32.120/24 | 10.0.32.1 | 127.0.0.1 |
| OCP Node | ocp-node.sno.si1230.com | 10.0.33.120/24 | 10.0.33.1 | 10.0.32.120 |
DNS
DNS の A レコードに必要な設定値です。Proxy 環境であれば recursion は不要です。他の TTL 等の設定値も一般的な値で問題ありません。複数ノードクラスタで LB を使用する場合は、api, api-int, *.apps が LB の IP アドレスになります。
| FQDN | IP Addr | 逆引き | 備考 |
|---|---|---|---|
| ocp-workbox.si1230.com | 10.0.32.120 | 必要 | |
| ocp-node.sno.si1230.com | 10.0.33.120 | 必要 | |
| api.sno.si1230.com | 10.0.33.120 | 不要 | Kubernetes API |
| api-int.sno.si1230.com | 10.0.33.120 | 不要 | Kubernetes API |
| *.apps.sno.si1230.com | 10.0.33.120 | 不要 | Routes |
Workbox 設定
workbox を設定します。
DNS 設定
こちらを参考に DNS サーバーを設定します。設定値の差分のみ記載します。
/etc/bind/named.conf.options
設定例は下記の通りです。
sudo tee /etc/bind/named.conf.options <<"EOF"
options {
directory "/var/cache/bind";
forwarders { 8.8.8.8; 8.8.4.4; };
dnssec-validation auto;
listen-on-v6 { any; };
allow-query { any; };
recursion yes;
};
EOF/etc/bind/named.conf.local
設定例は下記の通りです。
sudo tee /etc/bind/named.conf.local <<"EOF"
include "/etc/bind/zones.rfc1918";
zone "si1230.com" {
type master;
file "/etc/bind/si1230.com.zone";
};
zone "32.0.10.in-addr.arpa" {
type master;
file "/etc/bind/32.0.10.in-addr.arpa";
};
zone "33.0.10.in-addr.arpa" {
type master;
file "/etc/bind/33.0.10.in-addr.arpa";
};
EOF/etc/bind/si1230.com.zone
正引きのゾーンファイルの設定例です。OCP を検証するまで知らなかったのですが、下記のように記載するとサブドメインを含めて単一のファイルに書くことができます。ドメイン毎にファイルを分けても問題ありません。
sudo tee /etc/bind/si1230.com.zone <<"EOF"
$TTL 172800
@ IN SOA ocp-workbox.si1230.com. root.si1230.com. (
2023010101
3600
300
360000
86400
)
IN NS ocp-workbox.si1230.com.
ocp-workbox.si1230.com. IN A 10.0.32.120
node.sno.si1230.com. IN A 10.0.33.120
api.sno.si1230.com. IN A 10.0.33.120
api-int.sno.si1230.com. IN A 10.0.33.120
*.apps.sno.si1230.com. IN A 10.0.33.120
EOF/etc/bind/32.0.10.in-addr.arpa
10.0.32.0/24 の逆引きのゾーンファイルの設定例です。本番環境では、例えば /12, /27 等の Prefix の場合がある為、少し面倒かもしれません。
sudo tee /etc/bind/32.0.10.in-addr.arpa <<"EOF"
$TTL 172800
@ IN SOA ocp-workbox.si1230.com. root.si1230.com. (
2023010101
3600
300
360000
86400
)
IN NS ocp-workbox.si1230.com.
120 IN PTR ocp-workbox.si1230.com.
EOF/etc/bind/33.0.10.in-addr.arpa
10.0.33.0/24 の逆引きのゾーンファイルの設定例です。
sudo tee /etc/bind/33.0.10.in-addr.arpa <<"EOF"
$TTL 172800
@ IN SOA ocp-workbox.si1230.com. root.si1230.com. (
2023010101
3600
300
360000
86400
)
IN NS ocp-workbox.si1230.com.
120 IN PTR ocp-node.sno.si1230.com.
EOFツールのインストール
各ツールは下記からダウンロードします。
https://mirror.openshift.com/pub/openshift-v4/
curl を使用してダウンロードします。これらをインストールしていれば OCP の大抵のインストールパターンに対応できます。最低限であれば、openshift-install-linux, openshift-client-linux だけで十分です。
curl -OL https://mirror.openshift.com/pub/openshift-v4/clients/ocp/latest/openshift-install-linux-4.11.20.tar.gz
curl -OL https://mirror.openshift.com/pub/openshift-v4/clients/ocp/latest/openshift-client-linux-4.11.20.tar.gz
curl -OL https://mirror.openshift.com/pub/openshift-v4/clients/ocp/latest/opm-linux-4.11.20.tar.gz
curl -OL https://mirror.openshift.com/pub/openshift-v4/clients/butane/latest/butane
curl -OL https://mirror.openshift.com/pub/openshift-v4/clients/helm/latest/helm-linux-amd64curl でプロキシを指定する場合の例です。curl はコマンドで直接プロキシを指定できる為、環境変数にプロキシを指定する必要がある wget より好きです。
curl -OL -x http://proxy.si1230.com:3128 https://mirror.openshift.com/pub/openshift-v4/clients/ocp/latest/openshift-install-linux-4.11.20.tar.gztar を展開します。
tar xzf openshift-install-linux-4.11.20.tar.gz
tar xzf openshift-client-linux-4.11.20.tar.gz
tar xzf opm-linux-4.11.20.tar.gz/usr/local/bin に各ツールを配置して実行権限を付与します。
sudo mv {openshift-install,oc,kubectl,opm,butane} /usr/local/bin
sudo mv helm-linux-amd64 /usr/local/bin/helm
sudo chmod 755 /usr/local/bin/*不要なファイルを削除します。
rm *.tar.gz README.mdコマンド補完の設定をします。ここで指定しているコマンドは補完が可能です。実行可能な状態でのみ補完が動作するように指定しています。
sudo tee /etc/profile.d/openshift-install.sh <<"EOF"
if [ -x /usr/local/bin ]; then
source <(openshift-install completion bash)
fi
EOF
sudo tee /etc/profile.d/oc.sh <<"EOF"
if [ -x /usr/local/bin ]; then
source <(oc completion bash)
fi
EOF
sudo tee /etc/profile.d/kubectl.sh <<"EOF"
if [ -x /usr/local/bin ]; then
source <(kubectl completion bash)
fi
EOF
sudo tee /etc/profile.d/opm.sh <<"EOF"
if [ -x /usr/local/bin ]; then
source <(opm completion bash)
fi
EOF
sudo tee /etc/profile.d/helm.sh <<"EOF"
if [ -x /usr/local/bin ]; then
source <(helm completion bash)
fi
EOFPodman のインストール
Podman をインストールします。Podman は後述の coreos-installer コマンドで使用しますが、実は coreos-installer のバイナリも存在します。ただ、Ubuntu の環境では OpenSSL のライブラリのバージョンが異なるようで使用できませんでした。
sudo DEBIAN_FRONTEND=noninteractive apt-get -o Dpkg::Options::=--force-confdef -o Dpkg::Options::=--force-confold install podmanSSH 鍵の作成
パスフレーズ無しの SSH 鍵を作成します。
ssh-keygen -t rsa -b 4096 -N '' -C "myadmin@workbox.si1230.com"作業用ディレクトリ
ディレクトリは自由ですが、実質的にはクラスタ名で分けることになるでしょう。OCP のクラスタ名はサブドメインとなり、本稿の例では sno.si1230.com とします。
mkdir -p ~/work/ocp/sno/{ign,iso}RHCOS のダウンロード
RHCOS をダウンロードします。公式サイトでは変数を設定して云々としていますが、意味不明なので直接ダウンロードしています。
cd ~/work/ocp/sno/iso
curl -OL https://mirror.openshift.com/pub/openshift-v4/dependencies/rhcos/4.11/4.11.9/rhcos-4.11.9-x86_64-live.x86_64.isoIgnition ファイルの作成
Ignition ファイルは OCP インストールに必要な全ての情報が記載されます。実体は cloud-init です。
install-config.yaml の作成
公式ドキュメントを参考に作成します。
tee ~/work/ocp/sno/install-config.yaml <<"EOF"
apiVersion: v1
baseDomain: si1230.com
compute:
- name: worker
replicas: 0
controlPlane:
name: master
replicas: 1
metadata:
name: sno
networking:
clusterNetwork:
- cidr: 10.128.0.0/14
hostPrefix: 23
machineNetwork:
- cidr: 10.0.0.0/24
networkType: OVNKubernetes
serviceNetwork:
- 172.30.0.0/16
platform:
none: {}
bootstrapInPlace:
installationDisk: /dev/vda
pullSecret: 'pullSecret'
sshKey: 'sshKey'
EOF- SNO では controlPlane.replicas を 1、compute.replicas を 0 にします。
- metadata.name はクラスタ名です。ベースドメインのサブドメイン(sno.si1230.com)になります。
- machineNetwork は Node の外部ネットワークです。
- bootstrapInPlace.installationDisk は OCP をインストールするディスクデバイスを指定します。基本的に最初のデバイス名になりますが、事前に RHCOS を起動して確認しても良いでしょう。
- pullSecret は Red Hat OpenShift Cluster Manager にログインして Run it yourself > Platform agnostic (x86_64) > Pull secret を取得して貼り付け、シングルクォートで囲みます。Pull secret の取得にはブラウザが必要です。
- sshKey は前述で作成した ssh public key (.ssh/id_rsa.pub) を記載します。シングルクォートで囲みます。
01-master-network.bu の作成
一般的に OCP は DHCP で IP アドレスを払い出す手法が多いですが、今回は静的に IP アドレスを割り当てます。こちらを参考しました。
tee ~/work/ocp/sno/01-master-network.bu <<"EOF"
variant: openshift
version: 4.11.0
metadata:
name: 01-master-network-enp1s0
labels:
machineconfiguration.openshift.io/role: master
storage:
files:
- path: /etc/NetworkManager/system-connections/enp1s0.nmconnection
mode: 0600
overwrite: true
contents:
inline: |
[connection]
id=enp1s0
type=ethernet
interface-name=enp1s0
[ethernet]
mtu=1500
[ipv4]
address1=10.0.33.120/24,10.0.33.1
dns=10.0.32.120;
method=manual
[ipv6]
method=disabled
- path: /etc/hostname
mode: 0644
overwrite: true
contents:
inline: |
ocp-node
EOFManifest ファイルの作成
openshift-install を実行して Manifest ファイルを作成します。openshift-install コマンドは、~/work のようには指定できません。WARNING が出力されていますが、これは複数ノードクラスタの場合には control-plane に Pod を schedulable しないように設定が必要と言っています。SNO では無視できます。
cp /home/myadmin/work/ocp/sno/install-config.yaml /home/myadmin/work/ocp/sno/ign
openshift-install create manifests --dir=/home/myadmin/work/ocp/sno/ign
INFO Consuming Install Config from target directory
WARNING Making control-plane schedulable by setting MastersSchedulable to true for Scheduler cluster settings
INFO Manifests created in: /home/myadmin/work/ocp/sno/ign/manifests and /home/myadmin/work/ocp/sno/ign/openshiftこの時点でのディレクトリツリーは下記の通りです。
tree /home/myadmin/work/ocp/sno
/home/myadmin/work/ocp/sno
├── 01-master-network.bu
├── ign
│ ├── manifests
│ │ ├── cluster-config.yaml
│ │ ├── cluster-dns-02-config.yml
│ │ ├── cluster-infrastructure-02-config.yml
│ │ ├── cluster-ingress-02-config.yml
│ │ ├── cluster-network-01-crd.yml
│ │ ├── cluster-network-02-config.yml
│ │ ├── cluster-proxy-01-config.yaml
│ │ ├── cluster-scheduler-02-config.yml
│ │ ├── cvo-overrides.yaml
│ │ ├── kube-cloud-config.yaml
│ │ ├── kube-system-configmap-root-ca.yaml
│ │ ├── machine-config-server-tls-secret.yaml
│ │ └── openshift-config-secret-pull-secret.yaml
│ └── openshift
│ ├── 99_kubeadmin-password-secret.yaml
│ ├── 99_openshift-cluster-api_master-user-data-secret.yaml
│ ├── 99_openshift-cluster-api_worker-user-data-secret.yaml
│ ├── 99_openshift-machineconfig_99-master-ssh.yaml
│ ├── 99_openshift-machineconfig_99-worker-ssh.yaml
│ └── openshift-install-manifests.yaml
├── install-config.yaml
└── iso
└── rhcos-4.11.9-x86_64-live.x86_64.iso01-master-network.bu の組み込み
butane を使用して Manifest 内に 01-master-network.bu を組み込みます。
butane /home/myadmin/work/ocp/sno/01-master-network.bu -o /home/myadmin/work/ocp/sno/ign/openshift/01-master-network.yamlこの時点でのディレクトリツリーは下記の通りです。
tree /home/myadmin/work/ocp/sno
/home/myadmin/work/ocp/sno
├── 01-master-network.bu
├── ign
│ ├── manifests
│ │ ├── cluster-config.yaml
│ │ ├── cluster-dns-02-config.yml
│ │ ├── cluster-infrastructure-02-config.yml
│ │ ├── cluster-ingress-02-config.yml
│ │ ├── cluster-network-01-crd.yml
│ │ ├── cluster-network-02-config.yml
│ │ ├── cluster-proxy-01-config.yaml
│ │ ├── cluster-scheduler-02-config.yml
│ │ ├── cvo-overrides.yaml
│ │ ├── kube-cloud-config.yaml
│ │ ├── kube-system-configmap-root-ca.yaml
│ │ ├── machine-config-server-tls-secret.yaml
│ │ └── openshift-config-secret-pull-secret.yaml
│ └── openshift
│ ├── 01-master-network.yaml
│ ├── 99_kubeadmin-password-secret.yaml
│ ├── 99_openshift-cluster-api_master-user-data-secret.yaml
│ ├── 99_openshift-cluster-api_worker-user-data-secret.yaml
│ ├── 99_openshift-machineconfig_99-master-ssh.yaml
│ ├── 99_openshift-machineconfig_99-worker-ssh.yaml
│ └── openshift-install-manifests.yaml
├── install-config.yaml
└── iso
└── rhcos-4.11.9-x86_64-live.x86_64.isoIgnition ファイルの作成
Ignition ファイルを作成します。具体的には前述の Manifest ファイルが変換されます。変換後は .ign ファイルとなり .yaml のように可読性はありません。
openshift-install create single-node-ignition-config --dir=/home/myadmin/work/ocp/sno/ign
INFO Consuming Worker Machines from target directory
INFO Consuming OpenShift Install (Manifests) from target directory
INFO Consuming Openshift Manifests from target directory
INFO Consuming Master Machines from target directory
INFO Consuming Common Manifests from target directory
INFO Single-Node-Ignition-Config created in: /home/myadmin/work/ocp/sno/ign and /home/myadmin/work/ocp/sno/ign/authIgnition ファイル作成後のディレクトリツリーは下記の通りです。
tree ~/work/ocp/sno
/home/myadmin/work/ocp/sno
├── 01-master-network.bu
├── ign
│ ├── auth
│ │ ├── kubeadmin-password
│ │ └── kubeconfig
│ ├── bootstrap-in-place-for-live-iso.ign
│ ├── metadata.json
│ └── worker.ign
├── install-config.yaml
└── iso
└── rhcos-4.11.9-x86_64-live.x86_64.isoカスタム ISO の作成
coreos-installer を使用してカスタム ISO を作成します。まず、後述の coreos-installer が同一ディレクトリ上でしか機能しない為、作成した .ign を iso ディレクトリにコピーします。
cp ~/work/ocp/sno/ign/bootstrap-in-place-for-live-iso.ign ~/work/ocp/sno/iso次に RHCOS の ISO を別名でコピーします。これは .ign を埋め込む iSO となります。
cp ~/work/ocp/sno/iso/rhcos-4.11.9-x86_64-live.x86_64.iso ~/work/ocp/sno/iso/rhcos-4.11.9-x86_64-live.x86_64-ocp-node.sno.si1230.com.isocoreos-installer はバイナリが存在しますが、Ubuntu の環境では OpenSSL のバージョンの問題で機能しない為、Podman コマンドの alias として設定します。
alias coreos-installer='podman run --privileged --pull always --rm -v /dev:/dev -v /run/udev:/run/udev -v $PWD:/data -w /data quay.io/coreos/coreos-installer:release'.ign を埋め込みます。coreos-installer は同一ディレクトリでしか機能しない為、対象のディレクトリに移動して実行します。
cd ~/work/ocp/sno/iso && coreos-installer iso ignition embed -fi bootstrap-in-place-for-live-iso.ign rhcos-4.11.9-x86_64-live.x86_64-ocp-node.sno.si1230.com.iso
Trying to pull quay.io/coreos/coreos-installer:release...
Getting image source signatures
Copying blob d882444b85a3 [--------------------------------------] 0.0b / 0.0b
Copying blob 4b0f320c94da [--------------------------------------] 0.0b / 0.0b
Copying blob a5bf0747400a [--------------------------------------] 0.0b / 0.0b
Copying config 246a91e0c2 done
Writing manifest to image destination
Storing signatures少々コマンドが長くなりますが、ISO 起動時点で、静的に IP アドレスを設定するカーネル引数を埋め込みます。
cd ~/work/ocp/sno/iso && coreos-installer iso kargs modify -a "console=ttyS0 rd.neednet=1 ip=10.0.33.120::10.0.33.1:255.255.255.0:ocp-node:enp1s0:none nameserver=10.0.32.120" rhcos-4.11.9-x86_64-live.x86_64-ocp-node.sno.si1230.com.iso
Trying to pull quay.io/coreos/coreos-installer:release...
Getting image source signatures
Copying blob d882444b85a3 [--------------------------------------] 0.0b / 0.0b
Copying blob 4b0f320c94da [--------------------------------------] 0.0b / 0.0b
Copying blob a5bf0747400a [--------------------------------------] 0.0b / 0.0b
Copying config 246a91e0c2 done
Writing manifest to image destination
Storing signaturesKVM ホストに ISO をコピーします。
scp ~/work/ocp/sno/iso/rhcos-4.11.9-x86_64-live.x86_64-ocp-node.sno.si1230.com.iso hv0009.si1230.com:~/KVM で ISO を起動
ISO を /var/lib/libvirt/images に移動します。
sudo mv rhcos-4.11.9-x86_64-live.x86_64-ocp-node.sno.si1230.com.iso /var/lib/libvirt/imagesvirt-install スクリプトを作成します。
tee ~/work/kvm/virt-install/si1230.com/ocp-install.sh <<"EOF"
#!/bin/bash
disksize="80"
hostname="ocp-node"
domain="sno.si1230.com"
name=${hostname}.${domain}
os="fedora-coreos-stable"
vcpus="2"
memory="8192"
net1="br2001"
imgdir="/var/lib/libvirt/images"
isodir="/var/lib/libvirt/images"
iso="rhcos-4.11.9-x86_64-live.x86_64-ocp-node.sno.si1230.com.iso"
virt-install \
--connect qemu:///system \
--name ${name} \
--os-variant ${os} \
--vcpus ${vcpus} \
--memory ${memory} \
--disk path=${imgdir}/${name}.qcow2,size=${disksize} \
--network bridge=${net1} \
--graphics spice,listen=0.0.0.0,keymap=ja \
--noautoconsole \
--cdrom ${isodir}/${iso} \
--boot uefi
EOFvirt-install スクリプトに実行権限を付与し、実行します。
chmod 755 ~/work/kvm/virt-install/si1230.com/ocp-install.sh
~/work/kvm/virt-install/si1230.com/ocp-install.shコンソールから起動状態を確認します。コンソールログインはできないので、起動確認後はコンソールは不要です。トラブルシューティングがない限り、KVM での操作も終了です。
virsh console ocp-node.sno.si1230.comインストール状態の確認
SSH で Node にログインし、bootkube の状態を確認します。まずはこれが終わらないと始まりません。正常に完了すると自動で再起動します。
ssh core@ocp-node.sno.si1230.com
journalctl -b -f -u release-image.service -u bootkube.service多分、スクリプトに noautoconsole を指定した為、初回の再起動は起動してきません。とりあえず KVM 上で手動で起動します。
virsh start ocp-node.sno.si1230.comocp-workbox に戻り、openshift-install でインストール状態を確認します。
openshift-install wait-for install-complete --dir=work/ocp/sno/ignインストールが完了後、oc コマンドでクラスタの状態を確認します。
export KUBECONFIG=ocp/auth/kubeconfig
oc get nodes
oc get clusterversionその他
OpenShift (RHCOS) のインストールは、その仕組み上、ある程度の時間を待つ必要があり、失敗の判定も分かりづらい為、なんか変だなと思ったら ISO の再作成をしたほうが良いです。下記のように作業ディレクトリを再作成してやり直しましょう。
rm -r ~/work/ocp/sno/{ign,iso}
mkdir -p ~/work/ocp/sno/{ign,iso}次に読む記事
参考書籍
書籍
Kubernetes完全ガイド 第2版
Kubernetes の仕組み、リソース、ネットワーク、運用観点を体系的に確認したい場合の参考書籍です。価格や在庫はリンク先で確認してください。
Amazon で見るこのリンクは Amazon アソシエイトリンクです。

