エンタープライズ版のライセンスの無い自宅の環境に、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のベアメタルインストール手順と同様。
環境
構成自体は、赤帽エンジニアブログでUPIインストール芸人マスターの田中さんが検証されている環境とほぼ同じです。
(というか、RHCOS+エンタープライズ版OpenShift4.2を入れるとき含めて大変参考になりました。この場でお礼申し上げます)
図を書きたいけど力尽きた。
- 自宅ネットワークが
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を利用。
赤帽ブログの記事ほぼそのままなので、そちら参照…
PXEブートするためのTFTPについては、これもdnsmasqで構築。たぶんこれは赤帽ブログと違うかも。
といっても、過去のこの記事の構成ほぼそのままです。
準備
作業ディレクトリ
[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の入手
中央の Bare Metal & Virtualized から。
Raw
PXEブートした後のOSインストール用に、raw.xzファイルをネットワーク内のwebサーバに配置する。
分かりづらいけど、sigファイルも無いとインストールに失敗するの入手する。(無いとwebサーバのアクセスログに404が記録され、その後インストールが途中で止まる)
[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.ign、worker.ign、bootstrap.ignをwebサーバへ配置する。
(注意)
./openshift-install create manifests --dir=bare-metalを実行し、bare-metal/manifests/cluster-scheduler-02-config.ymlのmastersSchedulableの値を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) マシンの作成
VMのMACアドレス毎の設定
bootstrap/master/workerそれぞれの起動パラメタファイルが作成できたら、VMのMACアドレスを確認し、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が起動しないことがあるので、念のためリブートしておく方がトラブルが少なそう。
バグっぽいです。ワークアラウンドはbootstrapノードを再起動です。↑と同じ組み合わせで止まった後に、嘘だろーと思ってやったらうまくいきましたw https://t.co/hnu7Kkmt9F
— Shion Tanaka (@tnk4on) 2020年2月8日
あとは、ログイン時のメッセージにも出力されているが、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が続く場合はミスってる可能性高いので作り直した方が良いかも。
また、master0とmaster2だけ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ノードのみのクラスタの方が省リソースだったりするけど…
イメージレジストリ
[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本体は動いていないはず。
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の具体的な設定はなぜか制限ネットワークのベアメタルインストールドキュメントにしか載ってなかったので、そちらも参照。
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
Availableがtrueになっておらず、Progressingがtrueのものは、まだ処理中なのでしばらく待つ。
(だいたいレジストリの設定やってれば完了するはず)
[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とか使って名前解決できるよう設定してアクセスする。
初期状態であれば、ユーザ名はkubeadmin、パスワードはignitionファイルを作成したディレクトリのbare-metal/auth/kubeadmin-passwordファイルに保存されているので、catなどで内容を確認する
参考サイト
RHCOS / OpenShift
全体を通して基本的にはエンタープライズ版OpenShift 4.xのUPIインストールと同様なので、エンタープライズ版OpenShiftのベアメタルインストールドキュメントを見ると参考になる。
あとやっぱり赤帽エンジニアブログ
福岡のk8sイベントでのOKDについてのスライドもご参考
Fedora CoreOS
OKD
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
