zaki work log

作業ログやら生活ログやらなんやら

OKD4.4 on Fedora CoreOS(FCOS)をベアメタルUPIインストールしてOpenShift4マルチノードクラスタを試してみた

エンタープライズ版のライセンスの無い自宅の環境に、Fedora CoreOSでOKD4を入れたときの手順です。

OKDはOpenShiftのアップストリーム版で、安定版と言って良いバージョンがあるのかなんとも微妙で、タイミングやCoreOSとのバージョンの組み合わせに等よってはインストールできないこともあるので、うまくいかない場合はしばらく様子を見るのもアリです。(3.11のときのHawkularは1か月以上放置してたことも…)

2020.02.15~16時点での、Fedora CoreOS(31.20200127.3.0 stable) + ODK (4.4.0-0.okd-2020-01-28-022517)での構築です。
基本的にはエンタープライズ版OpenShiftのベアメタルインストール手順と同様。

access.redhat.com

環境

構成自体は、赤帽エンジニアブログでUPIインストール芸人マスターの田中さんが検証されている環境とほぼ同じです。
(というか、RHCOS+エンタープライズ版OpenShift4.2を入れるとき含めて大変参考になりました。この場でお礼申し上げます)

rheb.hatenablog.com

図を書きたいけど力尽きた。

  • 自宅ネットワークが192.168.0.0/24で、OpenShiftネットワークが172.16.0.0/23というネットワーク構成
  • 踏み台サーバに相当するホスト(192.168.0.100/172.16.0.50)と、イメージやignファイル用のwebサーバ(192.168.0.19/172.16.1.0)は両方のネットワークに接続
  • OpenShiftノードから見てデフォルトゲートウェイDNSは172.16.1.0で、インターネットに接続可能

クラスタ情報

host cpu memory storage OS memo
okd4-manager 2 2GB 40GB CentOS 7.7 HAProxy
okd4-bootstrap 4 16GB 40GB Fedora CoreOS
okd4-master0 4 16GB 60GB Fedora CoreOS
okd4-master1 4 16GB 60GB Fedora CoreOS
okd4-master2 4 16GB 60GB Fedora CoreOS
okd4-worker0 2 8GB 60GB Fedora CoreOS
okd4-worker1 2 8GB 60GB Fedora CoreOS

OKD4の要求リソースは記載が…まだない?
エンタープライズ版OpenShift 4.3の場合はこちら

bootstrapについてはクラスタの構築時にしか使わないので、メモリ16GBはぶっちゃけ必要ない。ストレージも120GB使うとちょっとつらいので、半分の60GBにしている。

環境は無償ライセンスのESXiを使用。
プロビジョニングするディスクはthinでもthickでも問題ないが、なぜかVMのスナップショットを作成すると、FCOSインストール時にblk_update_request : critical target errorというエラーが出続けてインストールに成功しないので、スナップショットは作らない事。(作成済みの場合は削除する)

外部ミドルウェア(DNS/DHCP/TFTP/LB)

DNS/DHCPについてはdnsmasqで構築。LBはHAproxyを利用。
赤帽ブログの記事ほぼそのままなので、そちら参照…

rheb.hatenablog.com

PXEブートするためのTFTPについては、これもdnsmasqで構築。たぶんこれは赤帽ブログと違うかも。
といっても、過去のこの記事の構成ほぼそのままです。

zaki-hmkc.hatenablog.com

準備

作業ディレクト

[zaki@okd4-manager ~]$ mkdir okd4.4-preview2
[zaki@okd4-manager ~]$ cd okd4.4-preview2/
[zaki@okd4-manager okd4.4-preview2]$ 

OKDの入手

ocの入手

Release 4.4.0-0.okd-2020-01-28-022517 - Preview 2 · openshift/okd

OKDを入手するためのoc adm release extractを実行するため、まずocコマンドが必要なので、クライアントをダウンロードする。 https://mirror.openshift.com/pub/openshift-v4/clients/oc/latest/linux/

このocはダウンロードに使用するためだけに使用する。(OKDに別途ocは含まれている)

[zaki@okd4-manager okd4.4-preview2]$ curl -LO https://mirror.openshift.com/pub/openshift-v4/clients/oc/latest/linux/oc.tar.gz
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 22.4M  100 22.4M    0     0  2647k      0  0:00:08  0:00:08 --:--:-- 3229k
[zaki@okd4-manager okd4.4-preview2]$ tar xf oc.tar.gz 
[zaki@okd4-manager okd4.4-preview2]$ ./oc version
Client Version: v4.4.0
[zaki@okd4-manager okd4.4-preview2]$ 

OKD

2020.02.15時点でGitHubのREADMEには4.4.0-0.okd-2020-01-20-084618を使うように書いてあるけど、現時点でPreview 2バージョンの2020-01-28-022517がpre-release状態で公開されているため、そちらを指定する。

[zaki@okd4-manager okd4.4-preview2]$ time oc adm release extract --tools registry.svc.ci.openshift.org/origin/release:4.4.0-0.okd-2020-01-28-022517

real    0m25.012s
user    0m10.484s
sys     0m1.995s
[zaki@okd4-manager okd4.4-preview2]$ ll
合計 203696
-rwxr-xr-x. 1 zaki zaki 76088936  2月 14 16:29 oc
-rw-rw-r--. 1 zaki zaki 23498692  2月 15 18:27 oc.tar.gz
-rwxr-xr-x. 1 zaki zaki 24909985  1月 22 18:34 openshift-client-linux-4.4.0-0.okd-2020-01-28-022517.tar.gz
-rwxr-xr-x. 1 zaki zaki 84056766  1月 28 05:20 openshift-install-linux-4.4.0-0.okd-2020-01-28-022517.tar.gz
-rw-r--r--. 1 zaki zaki    20400  2月 15 18:30 release.txt
-rw-r--r--. 1 zaki zaki      331  2月 15 18:30 sha256sum.txt

Fedora CoreOSの入手

Download Fedora CoreOS

中央の Bare Metal & Virtualized から。

f:id:zaki-hmkc:20200216165710p:plain

Raw

PXEブートした後のOSインストール用に、raw.xzファイルをネットワーク内のwebサーバに配置する。
分かりづらいけど、sigファイルも無いとインストールに失敗するの入手する。(無いとwebサーバのアクセスログに404が記録され、その後インストールが途中で止まる)

f:id:zaki-hmkc:20200216165746p:plain f:id:zaki-hmkc:20200216165812p:plain

[root@manager cos]# pwd
/var/www/html/cos
[root@manager cos]# 
[root@manager cos]# curl -LO https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/31.20200127.3.0/x86_64/fedora-coreos-31.20200127.3.0-metal.x86_64.raw.xz
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  434M  100  434M    0     0  11.6M      0  0:00:37  0:00:37 --:--:-- 11.7M
[root@manager cos]# curl -LO https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/31.20200127.3.0/x86_64/fedora-coreos-31.20200127.3.0-metal.x86_64.raw.xz.sig
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   543  100   543    0     0    367      0  0:00:01  0:00:01 --:--:--   367
[root@manager cos]# ll
合計 445248
-rw-r--r--. 1 root root 455925828  2月 15 18:42 fedora-coreos-31.20200127.3.0-metal.x86_64.raw.xz
-rw-r--r--. 1 root root       543  2月 15 18:43 fedora-coreos-31.20200127.3.0-metal.x86_64.raw.xz.sig

PXE

PXEブート用にkernelとinitramfsをTFTPのディレクトリに配置する。

[root@manager tftpboot]# pwd
/var/lib/tftpboot
[root@manager tftpboot]# curl -LO https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/31.20200127.3.0/x86_64/fedora-coreos-31.20200127.3.0-live-kernel-x86_64
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  9.8M  100  9.8M    0     0  3625k      0  0:00:02  0:00:02 --:--:-- 3626k
[root@manager tftpboot]# curl -LO https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/31.20200127.3.0/x86_64/fedora-coreos-31.20200127.3.0-live-initramfs.x86_64.img
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  595M  100  595M    0     0  12.8M      0  0:00:46  0:00:46 --:--:-- 12.8M

ignitionファイル

install-config.ymlファイル作成

RHCOSの場合の内容と同等で良い。

クラスタ内で使用されるFQDN等は***.<metadata.name>.<baseDomain>となる。
↓で言えばhogehoge.okd4.naru.jp-z.jpみたいな感じ。

apiVersion: v1
baseDomain: naru.jp-z.jp
compute:
- hyperthreading: Enabled
  name: worker
  replicas: 0
controlPlane:
  hyperthreading: Enabled
  name: master
  replicas: 3
metadata:
  name: okd4
networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  networkType: OpenShiftSDN
  serviceNetwork:
  - 172.30.0.0/16
platform:
  none: {}
pullSecret: '{"auths": ... }'
sshKey: ''

pullSecretについては、ドキュメントに記載されているダミー値である{"auths":{"fake":{"auth": "bar"}}}を書くか(私は未確認)、CodeReady Containersをセットアップするときにも使用するRed Hatアカウントで取得できるシークレットの内容を張り付けておけば良い(はず)。
sshKeyについては、CoreOSへsshアクセスするためのsshキーペアを作成し、その公開鍵(~/.ssh/id_rsa.pubなど)の内容を張り付ける。セットアップ後CoreOSへsshするために使用する。

ファイル配置

[zaki@okd4-manager okd4.4-preview2]$ mkdir bare-metal
[zaki@okd4-manager okd4.4-preview2]$ cp install-config.yaml bare-metal/
[zaki@okd4-manager okd4.4-preview2]$ find bare-metal/
bare-metal/
bare-metal/install-config.yaml
[zaki@okd4-manager okd4.4-preview2]$ 

インストーラ

openshift-installは最初の手順でgetしてるので展開しておく。インストールにしか使わないのでカレントで良い。

[zaki@okd4-manager okd4.4-preview2]$ tar xf openshift-install-linux-4.4.0-0.okd-2020-01-28-022517.tar.gz 
[zaki@okd4-manager okd4.4-preview2]$ ll openshift-install
-rwxr-xr-x. 1 zaki zaki 332156928  1月 28 05:20 openshift-install
[zaki@okd4-manager okd4.4-preview2]$ ./openshift-install version
./openshift-install 4.4.0-0.okd-2020-01-28-022517
built from commit 7ca0817244033e5f543541def5b18ea1bac440f7
release image registry.svc.ci.openshift.org/origin/release@sha256:2350fee6c0d8a980d499b7bbb3ba20137ffa58416bc1381304596772957f7836

ignitionファイル作成

[zaki@okd4-manager okd4.4-preview2]$ ./openshift-install create ignition-configs --dir=bare-metal
INFO Consuming Install Config from target directory 
WARNING Making control-plane schedulable by setting MastersSchedulable to true for Scheduler cluster settings 
[zaki@okd4-manager okd4.4-preview2]$ find bare-metal/
bare-metal/
bare-metal/.openshift_install.log
bare-metal/.openshift_install_state.json
bare-metal/auth
bare-metal/auth/kubeconfig
bare-metal/auth/kubeadmin-password
bare-metal/master.ign
bare-metal/worker.ign
bare-metal/bootstrap.ign
bare-metal/metadata.json

作成されたmaster.ignworker.ignbootstrap.ignをwebサーバへ配置する。

(注意)
./openshift-install create manifests --dir=bare-metalを実行し、bare-metal/manifests/cluster-scheduler-02-config.ymlmastersSchedulableの値をFalseに変更する手順を行うと、bootstrapノードの起動が途中で停止してしまうので省略。

e.g. 1.1.8. Kubernetes マニフェストおよび Ignition 設定ファイルの作成

ignitionファイルの配置

[root@manager cos]# ll /var/www/html/cos
合計 445548
-rw-r--r--. 1 root root    296002  2月 15 19:01 bootstrap.ign
-rw-r--r--. 1 root root 455925828  2月 15 18:42 fedora-coreos-31.20200127.3.0-metal.x86_64.raw.xz
-rw-r--r--. 1 root root       543  2月 15 18:43 fedora-coreos-31.20200127.3.0-metal.x86_64.raw.xz.sig
-rw-r--r--. 1 root root      1851  2月 15 19:01 master.ign
-rw-r--r--. 1 root root      1851  2月 15 19:01 worker.ign

リモートからcurlなどでこのファイルにwwwアクセスできることを確認しておく。

$ curl http://192.168.0.19/cos/worker.ign

TFTP設定

起動パラメタ設定ファイル

bootstrap用, master用, worker用、3種類のPXEブート用起動パラメタの設定ファイルを作成する。
bootstrap用であれば以下の通り。

参考: Installing CoreOS on Bare Metal :: Fedora Docs Site

DEFAULT pxeboot
TIMEOUT 20
PROMPT 0
LABEL pxeboot
    KERNEL fedora-coreos-31.20200127.3.0-live-kernel-x86_64
    APPEND ip=dhcp rd.neednet=1 initrd=fedora-coreos-31.20200127.3.0-live-initramfs.x86_64.img console=tty0 console=ttyS0 coreos.inst.install_dev=sda coreos.inst.stream=stable coreos.inst.ignition_url=http://192.168.0.19/cos/bootstrap.ign coreos.inst.image_url=http://192.168.0.19/cos/fedora-coreos-31.20200127.3.0-metal.x86_64.raw.xz
IPAPPEND 2

master/workerは上のファイルをコピーして、coreos_inst.ignition_urlのURLをmaster.ign/worker.ignになるよう修正する。
異なるバージョンのイメージを使用する場合は、ファイル名など環境に合わせる。
FCOSのstable/testingについては後述。

APPEND行のRHCOSとの違いは以下の2点

  • coreos.inst不要
  • coreos.inst.stream追加

coreos.inst.streamについては、FCOSのイメージがstableであればstable、testingであればtestingを指定すれば良い…と思う(ソース無し)

1.1.9.2. PXE または iPXE ブートによる Red Hat Enterprise Linux CoreOS (RHCOS) マシンの作成

VMMACアドレス毎の設定

bootstrap/master/workerそれぞれの起動パラメタファイルが作成できたら、VMMACアドレスを確認し、bootstrap用VM・master用VM・worker用VMがそれぞれ、bootstrap・master・worker用の起動パラメタ設定ファイルを参照するようにsymlinkを作成する

[root@manager pxelinux.cfg]# ls -Fl /var/lib/tftpboot/pxelinux.cfg/
合計 16
lrwxrwxrwx. 1 root root  11  2月  2 22:56 01-**-**-**-**-**-** -> master.conf
lrwxrwxrwx. 1 root root  11  2月  2 21:23 01-**-**-**-**-**-** -> worker.conf
lrwxrwxrwx. 1 root root  11  2月  2 21:23 01-**-**-**-**-**-** -> worker.conf
lrwxrwxrwx. 1 root root  11  2月  2 21:23 01-**-**-**-**-**-** -> master.conf
lrwxrwxrwx. 1 root root  11  2月  2 21:23 01-**-**-**-**-**-** -> master.conf
lrwxrwxrwx. 1 root root  14  2月  2 21:19 01-**-**-**-**-**-** -> bootstrap.conf
-rw-r--r--. 1 root root 456  2月 15 19:48 bootstrap.conf
drwxr-xr-x. 6 root root 100  2月 16 13:01 conf/
-rw-r--r--. 1 root root 117  1月 30 22:09 default
-rw-r--r--. 1 root root 453  2月 15 19:49 master.conf
-rw-r--r--. 1 root root 453  2月 15 19:49 worker.conf

こんな感じ。

PXEの仕様?で、MACアドレスop:qr:st:uv:wx:yzの場合、対応するファイル名は01-op-qr-st-uv-wx-yzになるらしい。
という記述の文書はたくさんヒットするけど、大元の情報はどれなのかな…

インストール

全ての準備が整ったら、(OSのインストールについては)VMの電源を入れるだけ。。

bootstrap

しばらく待てばOSインストールが完了し、sshできるようになる。

[zaki@okd4-manager okd4.4-preview2]$ ssh core@okd4-bootstrap 
The authenticity of host 'okd4-bootstrap (172.16.0.51)' can't be established.
ECDSA key fingerprint is SHA256:
ECDSA key fingerprint is MD5:
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'okd4-bootstrap,172.16.0.51' (ECDSA) to the list of known hosts.
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
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
Fedora CoreOS 31.20200127.20.1
Tracker: https://github.com/coreos/fedora-coreos-tracker

[core@okd4-bootstrap ~]$

LISTENしているサービスを確認

[core@okd4-bootstrap ~]$ sudo ss -anptl
State   Recv-Q  Send-Q   Local Address:Port    Peer Address:Port
LISTEN  0       4096         127.0.0.1:10248        0.0.0.0:*     users:(("kubelet",pid=4128,fd=25))
LISTEN  0       128            0.0.0.0:111          0.0.0.0:*     users:(("rpcbind",pid=864,fd=4),("systemd",pid=1,fd=42))
LISTEN  0       4096         127.0.0.1:40947        0.0.0.0:*     users:(("crio",pid=4111,fd=11))
LISTEN  0       128            0.0.0.0:34099        0.0.0.0:*     users:(("rpc.statd",pid=873,fd=8))
LISTEN  0       128            0.0.0.0:22           0.0.0.0:*     users:(("sshd",pid=796,fd=4))
LISTEN  0       4096                 *:10250              *:*     users:(("kubelet",pid=4128,fd=29))
LISTEN  0       4096                 *:6443               *:*     users:(("kube-etcd-signe",pid=4021,fd=3))
LISTEN  0       4096                 *:10255              *:*     users:(("kubelet",pid=4128,fd=28))
LISTEN  0       128               [::]:111             [::]:*     users:(("rpcbind",pid=864,fd=6),("systemd",pid=1,fd=44))
LISTEN  0       128               [::]:42357           [::]:*     users:(("rpc.statd",pid=873,fd=10))
LISTEN  0       128               [::]:22              [::]:*     users:(("sshd",pid=796,fd=6))
LISTEN  0       4096                 *:22623              *:*     users:(("machine-config-",pid=5357,fd=5))
LISTEN  0       4096                 *:22624              *:*     users:(("machine-config-",pid=5357,fd=3))
LISTEN  0       4096                 *:6080               *:*     users:(("kube-etcd-signe",pid=4021,fd=5))

ここまで確認できたら、一度bootstrapノードのOSをリブート(sshしてsudo reboot)する。
現在、etcdの証明書関連の処理に不具合があるっぽく、一度リブートしておけば良いらしい。現stableバージョンでもリブートなしだとetcdが起動しないことがあるので、念のためリブートしておく方がトラブルが少なそう。

あとは、ログイン時のメッセージにも出力されているが、journalctl -b -f -u bootkube.serviceを実行すれば、master/workerの起動時した際のログが表示される。

 2月 16 04:53:41 okd4-bootstrap bootkube.sh[773]: {"level":"warn","ts":"2020-02-16T04:53:41.441Z","caller":"clientv3/retry_interceptor.go:61","msg":"retrying of unary invoker failed","target":"endpoint://client-11582fbc-5d9d-4404-aefa-b6ef09630f29/etcd-0.okd4.naru.jp-z.jp:2379","attempt":0,"error":"rpc error: code = DeadlineExceeded desc = latest connection error: connection error: desc = \"transport: Error while dialing dial tcp 172.16.0.10:2379: connect: connection refused\""}
 2月 16 04:53:41 okd4-bootstrap bootkube.sh[773]: {"level":"warn","ts":"2020-02-16T04:53:41.441Z","caller":"clientv3/retry_interceptor.go:61","msg":"retrying of unary invoker failed","target":"endpoint://client-6b5bab61-eb91-4f75-877f-d7f46ba28b57/etcd-1.okd4.naru.jp-z.jp:2379","attempt":0,"error":"rpc error: code = DeadlineExceeded desc = latest connection error: connection error: desc = \"transport: Error while dialing dial tcp 172.16.0.11:2379: connect: connection refused\""}
 2月 16 04:53:41 okd4-bootstrap bootkube.sh[773]: {"level":"warn","ts":"2020-02-16T04:53:41.441Z","caller":"clientv3/retry_interceptor.go:61","msg":"retrying of unary invoker failed","target":"endpoint://client-ace3ec6a-85ad-4884-af7a-864270b99d0a/etcd-2.okd4.naru.jp-z.jp:2379","attempt":0,"error":"rpc error: code = DeadlineExceeded desc = latest connection error: connection error: desc = \"transport: Error while dialing dial tcp 172.16.0.12:2379: connect: connection refused\""}
 2月 16 04:53:41 okd4-bootstrap bootkube.sh[773]: https://etcd-0.okd4.naru.jp-z.jp:2379 is unhealthy: failed to commit proposal: context deadline exceeded
 2月 16 04:53:41 okd4-bootstrap bootkube.sh[773]: https://etcd-1.okd4.naru.jp-z.jp:2379 is unhealthy: failed to commit proposal: context deadline exceeded
 2月 16 04:53:41 okd4-bootstrap bootkube.sh[773]: https://etcd-2.okd4.naru.jp-z.jp:2379 is unhealthy: failed to commit proposal: context deadline exceeded
 2月 16 04:53:41 okd4-bootstrap bootkube.sh[773]: Error: unhealthy cluster

bootstrapしか起動していない状態だとetcdがunheltyとエラーが出力されつづけるので、master/workerも続いてセットアップを行う。

master, worker

bootstrap同様、VMを起動しネットワークインストールを行う。
ノード上のCoreOSインストールが完了しログインプロンプトが表示されても、OKD環境の構築は追加で処理が行われるため、bootstrapノードでjournalctl -b -f -u bootkube.serviceを実行しておき、メッセージが変化するまで待機する。

しばらく待てば、bootkube.serviceのログのetcdのunhealthyログが解消し、pod statusなどのコンテナ関連のログが流れ始め、処理が終わると以下のログで完了する

 2月 16 06:26:21 okd4-bootstrap bootkube.sh[4366]: bootkube.service complete
 2月 16 06:26:21 okd4-bootstrap systemd[1]: bootkube.service: Succeeded.
 2月 16 06:26:21 okd4-bootstrap systemd[1]: bootkube.service: Consumed 36.035s CPU time.

1時間くらい経ってもetcdのunhealthyが続く場合はミスってる可能性高いので作り直した方が良いかも。
また、master0master2だけhealthチェックは通るのにmaster1だけunhealthの場合も、再現性なくて微妙だけどmaster1だけ作り直すとうまくいく可能性は高い。

起動確認

[zaki@okd4-manager okd4.4-preview2]$ ./openshift-install --dir=bare-metal wait-for bootstrap-complete 
INFO Waiting up to 30m0s for the Kubernetes API at https://api.okd4.naru.jp-z.jp:6443... 
INFO API v1.17.1 up
INFO Waiting up to 30m0s for bootstrapping to complete...
INFO It is now safe to remove the bootstrap resources

ocコマンドをパスの通ったところに配置

[zaki@okd4-manager okd4.4-preview2]$ sudo mkdir /usr/local/oc-4.4.0-0.okd-2020-01-28-022517
[sudo] zaki のパスワード:
[zaki@okd4-manager okd4.4-preview2]$ 
[zaki@okd4-manager okd4.4-preview2]$ 
[zaki@okd4-manager okd4.4-preview2]$ sudo tar xf openshift-client-linux-4.4.0-0.okd-2020-01-28-022517.tar.gz -C /usr/local/oc-4.4.0-0.okd-2020-01-28-022517/
[zaki@okd4-manager okd4.4-preview2]$ sudo rm /usr/local/bin/oc /usr/local/bin/kubectl 
[zaki@okd4-manager okd4.4-preview2]$ sudo ln -s /usr/local/oc-4.4.0-0.okd-2020-01-28-022517/oc /usr/local/bin/
[zaki@okd4-manager okd4.4-preview2]$ sudo ln -s /usr/local/oc-4.4.0-0.okd-2020-01-28-022517/kubectl /usr/local/bin/
[zaki@okd4-manager okd4.4-preview2]$ 

認証情報を設定して状態確認

認証情報は、ignitionファイルを作成したディレクトリのauthディレクトリにあるのでexportすればOK

[zaki@okd4-manager okd4.4-preview2]$ export KUBECONFIG=bare-metal/auth/kubeconfig
[zaki@okd4-manager okd4.4-preview2]$ oc version
Client Version: 4.4.0-0.okd-2020-01-28-022517
Server Version: 4.4.0-0.okd-2020-01-28-022517
Kubernetes Version: v1.17.1
[zaki@okd4-manager okd4.4-preview2]$ oc get node
NAME           STATUS   ROLES           AGE   VERSION
okd4-master0   Ready    master,worker   12m   v1.17.1
okd4-master1   Ready    master,worker   12m   v1.17.1
okd4-master2   Ready    master,worker   12m   v1.17.1
okd4-worker0   Ready    worker          13m   v1.17.1
okd4-worker1   Ready    worker          12m   v1.17.1

workerノードの追加

もし、masterノードが上がり切ってからworkerノードをセットアップした場合、クラスタにworkerノードが追加されない場合がある。

[zaki@okd4-manager okd4.4-preview2]$ oc get node
NAME           STATUS   ROLES           AGE   VERSION
okd4-master0   Ready    master,worker   21m   v1.17.1
okd4-master1   Ready    master,worker   21m   v1.17.1
okd4-master2   Ready    master,worker   21m   v1.17.1

その場合、csrがpending状態になっているので、approveしてやればOK

[zaki@okd4-manager okd4.4-preview2]$ oc get csr
NAME        AGE     REQUESTOR                                                                   CONDITION
csr-6n2nf   10m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
csr-6wnmb   9m12s   system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
csr-7gzzz   2m53s   system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
:
:

このようにPendingになっているリソースが出力されるので

[zaki@okd4-manager okd4.4-preview2]$ oc get csr -o name | xargs oc adm certificate approve
:
:
[zaki@okd4-manager okd4.4-preview2]$ oc get node
NAME           STATUS     ROLES           AGE   VERSION
okd4-master0   Ready      master,worker   28m   v1.17.1
okd4-master1   Ready      master,worker   28m   v1.17.1
okd4-master2   Ready      master,worker   28m   v1.17.1
okd4-worker0   NotReady   worker          30s   v1.17.1
okd4-worker1   NotReady   worker          35s   v1.17.1

しばらく待てば↓のようになる(はず)

[zaki@okd4-manager okd4.4-preview2]$ oc get node 
NAME           STATUS   ROLES           AGE     VERSION
okd4-master0   Ready    master,worker   30m     v1.17.1
okd4-master1   Ready    master,worker   30m     v1.17.1
okd4-master2   Ready    master,worker   30m     v1.17.1
okd4-worker0   Ready    worker          2m10s   v1.17.1
okd4-worker1   Ready    worker          2m15s   v1.17.1

インストール後の設定

bootstrapをクラスタから外す

OpenShift的な操作はとくに無いので、HAProxyの設定を外し、ノードをシャットダウンすればOK

masterノードをスケジュールから外す

デフォルトではmasterノードもworkerロールが付与されてるので外す。

[zaki@okd4-manager okd4.4-preview2]$ oc get schedulers.config.openshift.io cluster -o yaml
apiVersion: config.openshift.io/v1
kind: Scheduler
metadata:
  creationTimestamp: "2020-02-16T06:18:03Z"
  generation: 1
  name: cluster
  resourceVersion: "443"
  selfLink: /apis/config.openshift.io/v1/schedulers/cluster
  uid: 7530bdda-3781-4fb9-b2e3-69de08590da7
spec:
  mastersSchedulable: true
  policy:
    name: ""
status: {}

spec.mastersSchedulableの値がtrueになっているのでfalseにする。

[zaki@okd4-manager okd4.4-preview2]$ oc patch schedulers.config.openshift.io cluster --type merge --patch '{"spec":{"mastersSchedulable":false}}'
scheduler.config.openshift.io/cluster patched

はい。

[zaki@okd4-manager okd4.4-preview2]$ oc get node
NAME           STATUS   ROLES    AGE   VERSION
okd4-master0   Ready    master   55m   v1.17.1
okd4-master1   Ready    master   55m   v1.17.1
okd4-master2   Ready    master   56m   v1.17.1
okd4-worker0   Ready    worker   56m   v1.17.1
okd4-worker1   Ready    worker   55m   v1.17.1

検証環境なのでむしろworker無しでmaster3ノードのみのクラスタの方が省リソースだったりするけど…

rheb.hatenablog.com

イメージレジストリ

[zaki@okd4-manager okd4.4-preview2]$ oc get pod -n openshift-image-registry 
NAME                                              READY   STATUS    RESTARTS   AGE
cluster-image-registry-operator-9d46c59d6-rdz6r   2/2     Running   0          9m21s

レジストリにオペレータpodは起動しているが、インストール中にremoveされることになっているので上記のようにオペレータのみでレジストリpod本体は動いていないはず。

参考: 1.1.13. Operator の初期設定

storageの設定

個人でOKD4を構築してる無ライセンス民にはそこらへんのNFSでも使わせておけ

[zaki@okd4-manager okd4.4-preview2]$ sudo mkdir -p /exports/nfs/okd4/registry
[zaki@okd4-manager okd4.4-preview2]$ sudo chmod 775 /exports/nfs/okd4/registry/
[zaki@okd4-manager okd4.4-preview2]$ sudo sh -c 'echo "/exports/nfs/okd4/registry *(rw,sync,no_wdelay,no_root_squash,insecure,fsid=0)" > /etc/exports.d/registry.exports'
[zaki@okd4-manager okd4.4-preview2]$ cat /etc/exports.d/registry.exports 
/exports/nfs/okd4/registry *(rw,sync,no_wdelay,no_root_squash,insecure,fsid=0)
[zaki@okd4-manager okd4.4-preview2]$ sudo exportfs -ar
[zaki@okd4-manager okd4.4-preview2]$ sudo exportfs -v
/exports/nfs/okd4/registry
                <world>(sync,no_wdelay,hide,no_subtree_check,fsid=0,sec=sys,rw,insecure,no_root_squash,no_all_squash)

↑のようにNFSサーバの設定をしたら、

apiVersion: v1
kind: PersistentVolume
metadata:
  name: registry-pv
spec:
  accessModes:
  - ReadWriteOnce
  - ReadWriteMany
  capacity:
    storage: 100Gi
  nfs:
    path: /exports/nfs/okd4/registry/
    server: okd4-manager.okd4.naru.jp-z.jp
  persistentVolumeReclaimPolicy: Retain

適当にpvを作成する。

[zaki@okd4-manager pv]$ oc apply -f registry-pv.yml 
persistentvolume/registry-pv created
[zaki@okd4-manager pv]$ oc get pv
NAME          CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
registry-pv   100Gi      RWO,RWX        Retain           Available                                   5s

そしてレジストリのストレージでpvを使うように設定を更新

[zaki@okd4-manager pv]$ oc edit configs.imageregistry.operator.openshift.io 
spec:
  :
  :
  storage: {}

となっている箇所を

spec:
  :
  :
  storage:
    pvc:
      claim:

に変更。

emptyDirを使うならpvcでなくemptyDir: {}にすればOK

[zaki@okd4-manager okd4.4-preview2]$ oc patch configs.imageregistry.operator.openshift.io cluster --type merge --patch '{"spec":{"storage":{"emptyDir":{}}}}'
config.imageregistry.operator.openshift.io/cluster patched

このpvの具体的な設定はなぜか制限ネットワークのベアメタルインストールドキュメントにしか載ってなかったので、そちらも参照。

access.redhat.com

registry podの有効化

ストレージ設定に加えて、managementState: Removedも変更。

spec:
  :
  :
  managementState: Removed

になっている箇所をManagedに変更。

[zaki@okd4-manager okd4.4-preview2]$ oc patch configs.imageregistry.operator.openshift.io cluster --type merge --patch '{"spec":{"managementState":"Managed"}}'
config.imageregistry.operator.openshift.io/cluster patched

するとpodが起動し始める。

[zaki@okd4-manager pv]$ oc get pod -n openshift-image-registry 
NAME                                              READY   STATUS              RESTARTS   AGE
cluster-image-registry-operator-9d46c59d6-rdz6r   2/2     Running             0          37m
image-registry-96c874cf5-wjrqb                    0/1     ContainerCreating   0          1s
node-ca-8x2gf                                     0/1     ContainerCreating   0          3s
node-ca-cmdk4                                     0/1     ContainerCreating   0          3s
node-ca-ptl22                                     0/1     ContainerCreating   0          3s
node-ca-rk5pv                                     0/1     ContainerCreating   0          3s
node-ca-szjrg                                     0/1     ContainerCreating   0          3s
[zaki@okd4-manager pv]$ oc get pvc -n openshift-image-registry 
NAME                     STATUS   VOLUME        CAPACITY   ACCESS MODES   STORAGECLASS   AGE
image-registry-storage   Bound    registry-pv   100Gi      RWO,RWX                       42s
[zaki@okd4-manager pv]$ oc get pv
NAME          CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                                             STORAGECLASS   REASON   AGE
registry-pv   100Gi      RWO,RWX        Retain           Bound    openshift-image-registry/image-registry-storage                           7m5s

pvもこの時点でboundになる。

operator

[zaki@okd4-manager okd4.4-preview2]$ oc get clusteroperators
NAME                                       VERSION                         AVAILABLE   PROGRESSING   DEGRADED   SINCE
authentication                                                             False       True          False      4m30s
cloud-credential                           4.4.0-0.okd-2020-01-28-022517   True        False         False      17m
cluster-autoscaler                         4.4.0-0.okd-2020-01-28-022517   True        False         False      3m54s
console                                    4.4.0-0.okd-2020-01-28-022517   False       True          False      5m28s
csi-snapshot-controller                    4.4.0-0.okd-2020-01-28-022517   True        False         False      6m39s
dns                                        4.4.0-0.okd-2020-01-28-022517   True        False         False      8m7s
image-registry                             4.4.0-0.okd-2020-01-28-022517   True        False         False      6m2s
ingress                                    4.4.0-0.okd-2020-01-28-022517   True        False         False      4m49s
insights                                   4.4.0-0.okd-2020-01-28-022517   True        False         False      13m
kube-apiserver                             4.4.0-0.okd-2020-01-28-022517   True        True          False      10m
kube-controller-manager                    4.4.0-0.okd-2020-01-28-022517   True        True          False      8m16s
kube-scheduler                             4.4.0-0.okd-2020-01-28-022517   True        False         False      8m39s
kube-storage-version-migrator              4.4.0-0.okd-2020-01-28-022517   True        False         False      12m
machine-api                                4.4.0-0.okd-2020-01-28-022517   True        False         False      8m27s
machine-config                             4.4.0-0.okd-2020-01-28-022517   True        False         False      8m40s
marketplace                                4.4.0-0.okd-2020-01-28-022517   True        False         False      5m16s
monitoring                                                                 False       True          True       51s
network                                    4.4.0-0.okd-2020-01-28-022517   True        False         False      13m
node-tuning                                4.4.0-0.okd-2020-01-28-022517   True        False         False      12m
openshift-apiserver                        4.4.0-0.okd-2020-01-28-022517   True        False         False      7m52s
openshift-controller-manager               4.4.0-0.okd-2020-01-28-022517   True        False         False      9m30s
openshift-samples                          4.4.0-0.okd-2020-01-28-022517   True        False         False      3m29s
operator-lifecycle-manager                 4.4.0-0.okd-2020-01-28-022517   True        False         False      8m22s
operator-lifecycle-manager-catalog         4.4.0-0.okd-2020-01-28-022517   True        False         False      8m21s
operator-lifecycle-manager-packageserver   4.4.0-0.okd-2020-01-28-022517   True        False         False      6m35s
service-ca                                 4.4.0-0.okd-2020-01-28-022517   True        False         False      12m
service-catalog-apiserver                  4.4.0-0.okd-2020-01-28-022517   True        False         False      12m
service-catalog-controller-manager         4.4.0-0.okd-2020-01-28-022517   True        False         False      12m
storage                                    4.4.0-0.okd-2020-01-28-022517   True        False         False      6m2s
support                                    4.4.0-0.okd-2020-01-28-022517   True        False         False      12m

Availabletrueになっておらず、Progressingtrueのものは、まだ処理中なのでしばらく待つ。
(だいたいレジストリの設定やってれば完了するはず)

[zaki@okd4-manager okd4.4-preview2]$ oc get clusteroperators
NAME                                       VERSION                         AVAILABLE   PROGRESSING   DEGRADED   SINCE
authentication                             4.4.0-0.okd-2020-01-28-022517   True        False         False      35m
cloud-credential                           4.4.0-0.okd-2020-01-28-022517   True        False         False      58m
cluster-autoscaler                         4.4.0-0.okd-2020-01-28-022517   True        False         False      44m
console                                    4.4.0-0.okd-2020-01-28-022517   True        False         False      38m
csi-snapshot-controller                    4.4.0-0.okd-2020-01-28-022517   True        False         False      47m
dns                                        4.4.0-0.okd-2020-01-28-022517   True        False         False      48m
image-registry                             4.4.0-0.okd-2020-01-28-022517   True        False         False      7m37s
ingress                                    4.4.0-0.okd-2020-01-28-022517   True        False         False      45m
insights                                   4.4.0-0.okd-2020-01-28-022517   True        False         False      53m
kube-apiserver                             4.4.0-0.okd-2020-01-28-022517   True        False         False      51m
kube-controller-manager                    4.4.0-0.okd-2020-01-28-022517   True        False         False      49m
kube-scheduler                             4.4.0-0.okd-2020-01-28-022517   True        False         False      49m
kube-storage-version-migrator              4.4.0-0.okd-2020-01-28-022517   True        False         False      53m
machine-api                                4.4.0-0.okd-2020-01-28-022517   True        False         False      49m
machine-config                             4.4.0-0.okd-2020-01-28-022517   True        False         False      49m
marketplace                                4.4.0-0.okd-2020-01-28-022517   True        False         False      46m
monitoring                                 4.4.0-0.okd-2020-01-28-022517   True        False         False      38m
network                                    4.4.0-0.okd-2020-01-28-022517   True        False         False      54m
node-tuning                                4.4.0-0.okd-2020-01-28-022517   True        False         False      52m
openshift-apiserver                        4.4.0-0.okd-2020-01-28-022517   True        False         False      48m
openshift-controller-manager               4.4.0-0.okd-2020-01-28-022517   True        False         False      50m
openshift-samples                          4.4.0-0.okd-2020-01-28-022517   True        False         False      44m
operator-lifecycle-manager                 4.4.0-0.okd-2020-01-28-022517   True        False         False      49m
operator-lifecycle-manager-catalog         4.4.0-0.okd-2020-01-28-022517   True        False         False      49m
operator-lifecycle-manager-packageserver   4.4.0-0.okd-2020-01-28-022517   True        False         False      47m
service-ca                                 4.4.0-0.okd-2020-01-28-022517   True        False         False      52m
service-catalog-apiserver                  4.4.0-0.okd-2020-01-28-022517   True        False         False      52m
service-catalog-controller-manager         4.4.0-0.okd-2020-01-28-022517   True        False         False      52m
storage                                    4.4.0-0.okd-2020-01-28-022517   True        False         False      46m
support                                    4.4.0-0.okd-2020-01-28-022517   True        False         False      52m

ログイン

webコンソールログインするには

[zaki@okd4-manager okd4.4-preview2]$ oc get route -A
NAMESPACE                  NAME                HOST/PORT                                                       PATH   SERVICES            PORT    TERMINATION            WILDCARD
openshift-authentication   oauth-openshift     oauth-openshift.apps.okd4.naru.jp-z.jp                                 oauth-openshift     6443    passthrough/Redirect   None
openshift-console          console             console-openshift-console.apps.okd4.naru.jp-z.jp                       console             https   reencrypt/Redirect     None
openshift-console          downloads           downloads-openshift-console.apps.okd4.naru.jp-z.jp                     downloads           http    edge/Redirect          None
openshift-monitoring       alertmanager-main   alertmanager-main-openshift-monitoring.apps.okd4.naru.jp-z.jp          alertmanager-main   web     reencrypt/Redirect     None
openshift-monitoring       grafana             grafana-openshift-monitoring.apps.okd4.naru.jp-z.jp                    grafana             https   reencrypt/Redirect     None
openshift-monitoring       prometheus-k8s      prometheus-k8s-openshift-monitoring.apps.okd4.naru.jp-z.jp             prometheus-k8s      web     reencrypt/Redirect     None
openshift-monitoring       thanos-querier      thanos-querier-openshift-monitoring.apps.okd4.naru.jp-z.jp             thanos-querier      web     reencrypt/Redirect     None

openshift-consoleへブラウザでアクセスする。 ワイルドカードDNSを設定しているネームサーバを利用できないときはhostsとか使って名前解決できるよう設定してアクセスする。

f:id:zaki-hmkc:20200216162129p:plain

初期状態であれば、ユーザ名はkubeadmin、パスワードはignitionファイルを作成したディレクトリのbare-metal/auth/kubeadmin-passwordファイルに保存されているので、catなどで内容を確認する

f:id:zaki-hmkc:20200216162349p:plain


参考サイト

RHCOS / OpenShift

全体を通して基本的にはエンタープライズ版OpenShift 4.xのUPIインストールと同様なので、エンタープライズ版OpenShiftのベアメタルインストールドキュメントを見ると参考になる。

access.redhat.com

あとやっぱり赤帽エンジニアブログ

rheb.hatenablog.com

rheb.hatenablog.com

rheb.hatenablog.com

rheb.hatenablog.com

福岡のk8sイベントでのOKDについてのスライドもご参考

speakerdeck.com

Fedora CoreOS

docs.fedoraproject.org

OKD

github.com

github.com

openshift-instrallerってTerraform使うようになる感じ?


oc get node-o wideしてなかったので記念に

[zaki@okd4-manager ~]$ oc get node -o wide
NAME           STATUS   ROLES    AGE     VERSION   INTERNAL-IP   EXTERNAL-IP   OS-IMAGE                         KERNEL-VERSION           CONTAINER-RUNTIME
okd4-master0   Ready    master   5h10m   v1.17.1   172.16.0.10   <none>        Fedora CoreOS 31.20200127.20.1   5.4.13-201.fc31.x86_64   cri-o://1.17.0-rc1
okd4-master1   Ready    master   5h10m   v1.17.1   172.16.0.11   <none>        Fedora CoreOS 31.20200127.20.1   5.4.13-201.fc31.x86_64   cri-o://1.17.0-rc1
okd4-master2   Ready    master   5h10m   v1.17.1   172.16.0.12   <none>        Fedora CoreOS 31.20200127.20.1   5.4.13-201.fc31.x86_64   cri-o://1.17.0-rc1
okd4-worker0   Ready    worker   5h10m   v1.17.1   172.16.0.20   <none>        Fedora CoreOS 31.20200127.20.1   5.4.13-201.fc31.x86_64   cri-o://1.17.0-rc1
okd4-worker1   Ready    worker   5h10m   v1.17.1   172.16.0.21   <none>        Fedora CoreOS 31.20200127.20.1   5.4.13-201.fc31.x86_64   cri-o://1.17.0-rc1