トップ > Red Hat OpenShift > OpenShift 4.1をベアメタルへUPIインストールする

OpenShift 4.1をベアメタルへUPIインストールする

Red Hat OpenShift Red Hat OpenShift Container Platform

Red Hatの福岡オフィスでソリューションアーキテクトをしている田中司恩です。OpenShift 4.1をUPIでベアメタル環境にインストールする方法について解説します。基本的にはインストールドキュメントの要約になりますが、初めてOpenShiftに触れる方にも分かりやすいように順を追って説明していきます。*1

なお、AWSへのUPIインストールについては、前の記事で林さんが書かれていますのでそちらを参考にしてください。

rheb.hatenablog.com

2019/10/30追記。 OpenShift 4.2がGAになりましたので、4.1からの変更点について下記の記事にまとめました。

rheb.hatenablog.com

本記事の章立てはこのようになります。

  • UPIインストールの概要
  • UPIインストールの事前準備
  • UPIインストールの実施手順
  • 参考：踏み台サーバーの構築

ゴールは「手作業でベアメタル環境にOpenShift 4.1をインストールし手順について理解する」です。

UPIインストールの概要

まず、OpenShift 4.1のUPIインストールの概要から説明していきます。

ドキュメント

インストール方法について記載されたドキュメントは日本語、英語どちらもあります。本記事では下記の日本語ドキュメントを対象とします。*2

第3章 ベアメタルへのインストール OpenShift Container Platform 4.1 | Red Hat Customer Portal

IPI/UPIについて

OpenShift 4のインストール方法はIPIとUPIの2種類があります。IPIは「Installer Provisioned Infrastructure」の略で、自動でインフラ環境を作成してインストールを行う方法です。

それに対しUPIは「User Provisioned Infrastructure」の略で、ユーザーがインフラ環境を事前に用意してインストールを行う方法です。ユーザーが環境を準備する手間はありますが、自由に用意した環境にインストールを行うことができます。現時点でUPIで対応しているインストール環境は下記の通りです。*3*4

  • AWS
  • VMware vSphere
  • ベアメタル

Infrastructure Provider
Infrastructure Provider

UPIインストール構成

UPIではユーザーが自由に環境を用意できる反面、必要な要件を満たすインフラの知識が無いと、どのようにインフラ環境を構成すればよいか悩むことと思います。 そこで、本記事では下記の検証環境をサンプルとして説明を進めていきます。*5

検証環境ネットワーク構成図
検証環境ネットワーク構成図

UPIインストールの事前準備

次に、構成に必要なものについて説明していきます。UPIインストールにおいて、ここが一番時間のかかるポイントになります。 この事前準備がきっちりと出来ていれば、インストール作業自体はそれほど時間はかかりません。*6

ノードの準備

UPIインストールで必要なノードの情報は下記の通りです。

マシン 台数 OS vCPU RAM ストレージ 備考
Bootstrap Node 1 RHCOS 4 16GB 120GB UPIインストール時のみ必要
Master Node 3 RHCOS 4 16GB 120GB 3台必須
Worker Node 2 RHCOS 2 8GB 120GB 2台以上
  • インストールする検証目的だけであれば、Bootstrap NodeのRAM容量はもう少し下げても大丈夫です
  • OSは全て「RHEL CoreOS（RHCOS）」を使用します*7

インストーラー、イメージの入手

この記事の検証環境ではRHCOSはISO起動、BIOSマシンを使用します。 実際に必要なファイルの例は下記のようになります。

名前 インストールor配置先 実際のファイル名(参考: v4.1.3) 備考
oc client 踏み台サーバー*8 openshift-client-linux-4.1.3.tar.gz linux,mac,windows版有り
openshift-install 踏み台サーバー*9 openshift-install-linux-4.1.3.tar.gz linux,mac版有り
RHCOS ISOイメージ Bootstrap,Master,Worker Node rhcos-4.1.0-x86_64-installer.iso OpenShiftのリリースバージョンと
必ずしも一致するものではありません。*10
BIOSファイル 踏み台サーバー（Web公開ディレクトリ） rhcos-4.1.0-x86_64-metal-bios.raw.gz BIOS,UEFI版有り
バージョンについてはRHCOSと同様
  • oc client,openshift-installは、展開してREADMEを参考にバイナリファイルを配置してください
  • RHCOS ISOイメージは、用意したベアメタルのノードに合わせて、メディアやISO起動ができるようにしてください
  • BIOSファイルは、この後のWeb Serverの項目を参考にしてファイルを配置してください

※※※ 製品のダウンロードについては、試用や評価に関する解説記事ができましたのでこちらを参照ください。※※※

rheb.hatenablog.com

ネットワーク要件

UPIインストールに必要なネットワークの要件について説明します。 対応するドキュメントは、3.1.4. ユーザーによってプロビジョニングされるインフラストラクチャーの作成です。

1. 基本要件

検証環境における検証用ネットワーク 内では、各ノードの全ての通信が通る構成となります。*11 また、検証用ネットワーク からインターネットへは自由に通信ができる構成です。*12

2. ネットワーク設計

検証用ネットワーク を設ける場合は、OpenShiftの内部で使用するネットワークアドレスと被らないようにする必要があります。 ドキュメントでは下記のアドレスが例として載っています。

  • 10.128.0.0/14 ：クラスターネットワーク（Pod IP の割り当てに使用される IP アドレスのブロック）
  • 172.30.0.0/16：サービスネットワーク（サービス IP アドレスに使用する IP アドレスプール）

検証環境でも上記をそのまま使用します。検証環境のネットワーク設計は下記のようになります。

  • 192.168.1.0/24：社内ネットワーク
  • 172.16.0.0/24：検証用ネットワーク
3. DHCP

RHCOSマシンは初回起動時にDHCPによるIPアドレスの割り当てが必要です。 検証環境では、MACアドレスを指定して固定でホスト名、IPアドレスを割り当てる方法を行います。

検証環境のDHCPの設定例は下記のようになります。

マシン ホスト名 IPアドレス サブネットマスク ゲートウェイ DNSサーバー
Bootstrap Node bootstrap.test.example.local 172.16.0.100 255.255.255.0 172.16.0.1 172.16.0.1
Master Node master-0.test.example.local
master-1.test.example.local
master-2.test.example.local		 172.16.0.101
172.16.0.102
172.16.0.103		 255.255.255.0 172.16.0.1 172.16.0.1
Worker Node worker-0.test.example.local
worker-1.test.example.local		 172.16.0.104
172.16.0.105		 255.255.255.0 172.16.0.1 172.16.0.1
4. DNS

下記の指定されたレコードの名前解決が必須です。

コンポーネント レコード 対象ノード
Kubernetes API api.<cluster_name>.<base_domain>
api-int.<cluster_name>.<base_domain>		 Bootstrap,Master
Routes *.apps.<cluster_name>.<base_domain> Worker
etcd etcd-<index>.<cluster_name>.<base_domain>
_etcd-server-ssl._tcp.<cluster_name>.<base_domain>		 Master

検証環境で登録したDNSの設定例は下記のようになります。

ホスト名 IPアドレス 備考
api.test.example.local 192.168.1.21 LBの外側アドレスを指定
api-int.test.example.local 172.16.0.1 LBの内側アドレスを指定
*.apps.test.example.local 172.16.0.1 LBの内側アドレスを指定。ワイルドカードDNSレコード。
etcd-0.test.example.local 172.16.0.101 システム内部でetcd-0,1,2で固定名で名前解決を行うので、
Master Nodeのホスト名とは別で登録必要
etcd-1.test.example.local 172.16.0.102 同上
etcd-2.test.example.local 172.16.0.103 同上
レコード 優先度 重み ポート DNS名
_etcd-server-ssl._tcp.test.example.local 0 10 2380 etcd-0.test.example.local
_etcd-server-ssl._tcp.test.example.local 0 10 2380 etcd-1.test.example.local
_etcd-server-ssl._tcp.test.example.local 0 10 2380 etcd-2.test.example.local
5. Load Balancer

下記のポート番号のロードバランサーが必要です

用途 ポート番号 対象ノード
Kubernetes APIServer 6443 Bootstrap,Master
マシン設定サーバー 22623 Bootstrap,Master
ingressルーターのhttpアクセス用 80 Worker
ingressルーターのhttpsアクセス用 443 Worker

検証環境で登録したLoad Balancerの設定は下記のようになります

ポート番号 SSL バックエンド
6443 Yes bootstrap.test.example.local
master-0.test.example.local
master-1.test.example.local
master-2.test.example.local
22623 Yes bootstrap.test.example.local
master-0.test.example.local
master-1.test.example.local
master-2.test.example.local
80 - worker-0.test.example.local
worker-1.test.example.local
443 Yes worker-0.test.example.local
worker-1.test.example.local
  • ブートストラッププロセス終了後はBootstrap Nodeの設定は不要ですので、Load Balancerの登録から削除できます
6. Web Server

ドキュメントには詳細な記載はありませんが、インストール作業に必要なファイルをHTTPサーバーに配置する必要があります。 検証環境では、nginxでWeb Serverを稼動し、Web公開ディレクトリに必要なファイルの配置を行います。 なお、nginx のポート番号はLoad Balancerの設定と被らないように、検証環境ではTCP 80→8008へ変更しています。*13

検証環境で使用するWeb公開ディレクトリのサンプルは下記のようになります。

/usr/share/nginx/html/
├── ocp
    └── rhcos
        ├── ignitions
        │   ├── bootstrap.ign
        │   ├── master.ign
        │   └── worker.ign
        └── images
            ├── latest
            │   ├── bios.raw.gz -> ../release/410/rhcos-4.1.0-x86_64-metal-bios.raw.gz
            └── release
                └── 410
                    └── rhcos-4.1.0-x86_64-metal-bios.raw.gz
  • ignitions以下の*.ign ファイルは、この後のインストール作業で作成したものを配置します
  • CoreOS Imageの元のファイル名は長いので、リンクで短縮名にしています。リネームして配置しても問題ありません。*14

踏み台サーバー

検証環境では、RHEL8のサーバーを1台用意してネットワーク要件で必要なサービスを全てここで稼動しています。 踏み台サーバーとして備えるべき、必要な要件は下記の通りです。

  • 2つのネットワークカード（社内ネットワーク、検証用ネットワークに接続）
  • 社内ネットワークからインターネットへアクセスが可能な固定IPを一つ
  • ネットワーク要件で上げたサービスが稼動できるリソースを持つマシン

詳細な設定内容については、記事の最後の「参考：踏み台サーバーの構築」を参考にしてください。

操作端末

社内ネットワークから踏み台サーバーを経由して、検証用ネットワークにアクセスするために使用します。 社内ネットワークのルーターなどに検証用ネットワークへのルーティングの追加が難しい場合は、操作端末に静的ルートを追加して対応してください。

  • SSH Client：踏み台サーバーにログインしてopenshift-installコマンドの実行、他。踏み台サーバーから各ノードにSSH接続してデバッグ操作、ログ確認など。*15
  • Webブラウザ ：新規クラスタ作成後、Web Consoleへの接続用。

SSHキーペアの準備

この作業では、各ノードに対してSSH公開鍵認証でアクセスするために必要なSSHキーペアの作成を行います。 対応するドキュメントは、3.1.5. SSH プライベートキーの生成およびエージェントへの追加です。 指定したSSH公開鍵が、各ノード（Bootstrap,Master,Worker）のcoreユーザーの ~/.ssh/authorized_keys に追加されます。*16

ドキュメントでは下記のコマンドが例として載っています。

$ ssh-keygen -t rsa -b 4096 -N '' -f ~/.ssh/new_rsa
  • ドキュメントではキーの生成後にssh-agentの起動の手順がありますが、UPIインストールをする目的においては必須ではありませんので、飛ばしても大丈夫です。*17

UPIインストールの実施手順

ここから、実際のインストール作業について説明していきます。

インストールのステップ

インストールの進行は下記の順で行います。また、各項目はドキュメントの3.1.8〜3.1.15に対応します。 各項目の作業内容は基本的にドキュメント通りとなりますので、詳細はドキュメントの該当箇所を参照ください。

1. 準備
項目 対応ドキュメント章
1.a インストール設定ファイルの手動作成 3.1.8
1.b Ignition 設定ファイルの作成 3.1.9
1.c Red Hat Enterprise Linux CoreOS (RHCOS) マシンの作成 3.1.10

※ 1.bで作成したIgnition 設定ファイルには、24 時間後に期限が切れる証明書が含まれます。万が一24時間を超えてインストールを実行する場合は、再度1.bから行ってください。

2. インストール作業
項目 Bootstrap Node 対応ドキュメント章
2.a クラスターの作成 必要 3.1.11
2.b クラスターへのログイン 不要 3.1.12
2.c マシンの CSR の承認 不要 3.1.13
2.d Operator の初期設定 不要 3.1.14
2.e UPIのインストールの完了 不要 3.1.15

1.a インストール設定ファイルの手動作成

この作業は踏み台サーバーで行います。 ここでの作業の目標は、インストールディレクトリの作成と、インストール設定ファイルinstall-config.yamlを作成することです。注意点は、ドキュメントにも記述がある通り、install-config.yamlをインストールディレクトリ以外に保存しておくことです。

  • インストールディレクトリ：bare-metal
$ mkdir bare-metal
$ vi install-config.yaml
$ cp install-config.yaml bare-metal/

検証環境のinstall-config.yamlは下記のような内容になります。*18

  • ドメイン名: example.local
  • クラスタ名：test
apiVersion: v1
baseDomain: example.local
compute:
- hyperthreading: Enabled
  name: worker
  replicas: 0
controlPlane:
  hyperthreading: Enabled
  name: master
  replicas: 3
metadata:
  name: test
networking:
  clusterNetworks:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  networkType: OpenShiftSDN
  serviceNetwork:
  - 172.30.0.0/16
platform:
  none: {}
pullSecret: '{"auths":{"cloud.openshift.com":{"auth":
..<省略>..
==","email":"XXX@XXX"}}}' 
sshKey: 'ssh-rsa AAAA...'

pullSecret:には、下記のページからCopy Pull Secretを押してコピーした内容を貼り付けます。

https://cloud.redhat.com/openshift/install/metal/user-provisioned

sshKey:には、事前準備で用意したSSH公開鍵の内容（~/.ssh/new_rsa.pub）を貼り付けます。

1.b Ignition 設定ファイルの作成

引き続きこの作業も踏み台サーバーで行います。 ここで行うことは、1.aで作成した内容を元に、インストールに必要なIgnition 設定ファイルなどを作成します。 行うことは下記のコマンドを1行実行するだけです。

$ openshift-install create ignition-configs --dir=bare-metal

このコマンドの実行後に、インストールディレクトリ内のinstall-config.yamlは削除されます。 実行後のインストールディレクトリは下記のようになります。

bare-metal
├── auth
│   ├── kubeadmin-password
│   └── kubeconfig
├── bootstrap.ign
├── master.ign
├── metadata.json
└── worker.ign

ドキュメントには記載がありませんが、実際の手順では作成した各ignitionファイルをWeb Serverの公開ディレクトリにコピーします。 検証環境では下記のようになります。

cp bare-metal/*ign /usr/share/nginx/html/ocp/rhcos/ignitions/

1.c Red Hat Enterprise Linux CoreOS (RHCOS) マシンの作成

この作業は各ノードのコンソール画面で行います。 ここでは、各ノードのベースOSのRHCOSを用意して、起動→初期パラメーターの入力を行うところまでを行います。

用意した各ノードをISOイメージで起動します。 ドキュメントでは起動順に特に指定はありませんが、ブートストラッププロセスにおいて、Master,Worker NodeがBootsrap Nodeからコンフィグファイルを取得するプロセスがあります。 起動順を設ける場合は、Bootstrap Nodeを先に起動するのが望ましいです。*19

この後の手順は全ノード共通です（ignition config URLの指定先を除く）。 ISO起動後、RHEL CoreOS InstallerのGUI画面が表示されます。Install RHEL CoreOSが選択されていますので、そのままエンターキーを押します。

RHEL CoreOS Installer GUI画面
RHEL CoreOS Installer GUI画面

次に、CoreOS Image URLの入力を求められますので、デフォルトの入力内容を消して指定のURLパスを入力し、エンターキーを押します。

CoreOS Image URLの入力
CoreOS Image URLの入力

  • このタイミングでファイルにアクセスできるかチェックが行われます。エラーになる場合は、URLパスやポート番号に間違いが無いか確認してください

さらに、CoreOS ignition config URLの入力を求められます。先程と同様に、デフォルトの入力内容を消して指定のURLパスを入力し、エンターキーを押します。 ここではBootstrap Nodeのignition設定ファイルを指定

CoreOS ignition config URLの入力
CoreOS ignition config URLの入力

  • ここも、先程と同様にファイルにアクセスできるかチェックが行われます。
  • 指定する *.ignファイルは、各ノードの種類に合わせて変更します

最後に、インストール先デバイスの指定を求められます。sdaを選択し、OKを押します。

インストール先デバイスの指定
インストール先デバイスの指定

CoreOS Image のダウンロード始まり、問題なく取得が完了すると自動で再起動が行われ、RHEL CoreOSが起動します。 この作業を全ノードについて行います。

2.a クラスターの作成

ここからWeb Consoleへのログインまでは、踏み台サーバーでの作業となります。

前項1.cの終了時点から、ブートストラッププロセスは自動的に進行しています。 ここでは、下記のコマンドを実行し、ブートストラッププロセスの進行と完了をモニタリングします。

$ openshift-install --dir=bare-metal wait-for bootstrap-complete

下記のような表示になるとブートストラッププロセスが完了したことが分かります。

 openshift-install --dir=bare-metal wait-for bootstrap-complete 
INFO Waiting up to 30m0s for the Kubernetes API at https://api.test.example.local:6443... 
INFO API v1.13.4+d4417a7 up                       
INFO Waiting up to 30m0s for bootstrapping to complete... 
INFO It is now safe to remove the bootstrap resources
  • 30分以上掛かっても完了しない場合は、事前準備が不足か間違っている可能性が高いです。
  • 途中で止めてやり直す場合は、1.cのISO起動からやり直します

2.b クラスターへのログイン

ここでは、kubeadmin認証情報をエクスポートし、デフォルトシステムユーザーでログインできることを確認します。

$ export KUBECONFIG=bare-metal/auth/kubeconfig

$ oc whoami
system:admin

oc whoamiの結果、system:adminが返ってくれば完了です。 ブートストラッププロセスの完了直後すぐだと、エラーが返ってくることがあります。その場合は、少し時間を置いて再度実行します。

2.c マシンの CSR の承認

ここでは、各ノードがクラスタに追加された際に作成される証明書署名要求が、全て承認されているか確認します。

まず、クラスターにノードが追加されているか確認します

$ oc get nodes

NAME      STATUS    ROLES   AGE  VERSION
master-0  Ready     master  63m  v1.13.4+b626c2fe1
master-1  Ready     master  63m  v1.13.4+b626c2fe1
master-2  Ready     master  64m  v1.13.4+b626c2fe1
worker-0  NotReady  worker  76s  v1.13.4+b626c2fe1
worker-1  NotReady  worker  70s  v1.13.4+b626c2fe1

証明書署名要求の承認状態を確認します。

$ oc get csr

全ての項目が、証明状態になっていることを確認します もし、なっていなければ、ドキュメントの手順で手動で承認を行なってください。*20

2.d Operator の初期設定

ここでは、全てのOperatorが正常に稼動していること確認します。

$ watch -n5 oc get clusteroperators

上記のコマンドで、5秒ごとに実行されるoc get clusteroperatorsの結果をモニタリングします。 Operatorが次々と立ち上がっていく様子が確認できます。 最終的に全てのOperatorのステータスにおいてAVAILABLEがTRUE、DEGRADEDがFALSEになることがゴールです。*21

※ストレージのイメージレジストリーへの提供（対象ドキュメント：3.1.14.1）

image-registryoperatorについては、自動的にAVAILABLEがTRUEにはなりません。 下記のコマンドを実行して、空のディレクトリを指定します。

$ oc patch configs.imageregistry.operator.openshift.io cluster --type merge --patch '{"spec":{"storage":{"emptyDir":{}}}}'

ドキュメントにも記載はありますが、このオプションは実稼働用以外のクラスターにのみ設定します。 この記事ではインストールの完了を目標としますので、このオプションを実行します。 本番運用時は適切な設定に変更してください。 詳細な設定方法は下記を参照。

2.4.2. ベアメタルの場合のレジストリーストレージの設定

  • Operatorが正常に起動した状態は下記のようになります。
# oc get clusteroperators
NAME                                 VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE
authentication                       4.1.3     True        False         False      46s
cloud-credential                     4.1.3     True        False         False      12m
cluster-autoscaler                   4.1.3     True        False         False      12m
console                              4.1.3     True        False         False      4m17s
dns                                  4.1.3     True        False         False      11m
image-registry                       4.1.3     True        False         False      7m17s
ingress                              4.1.3     True        False         False      7m34s
kube-apiserver                       4.1.3     True        False         False      11m
kube-controller-manager              4.1.3     True        False         False      9m31s
kube-scheduler                       4.1.3     True        False         False      9m40s
machine-api                          4.1.3     True        False         False      12m
machine-config                       4.1.3     True        False         False      10m
marketplace                          4.1.3     True        False         False      7m26s
monitoring                           4.1.3     True        False         False      5m32s
network                              4.1.3     True        False         False      12m
node-tuning                          4.1.3     True        False         False      8m57s
openshift-apiserver                  4.1.3     True        False         False      8m54s
openshift-controller-manager         4.1.3     True        False         False      11m
openshift-samples                    4.1.3     True        False         False      2m33s
operator-lifecycle-manager           4.1.3     True        False         False      10m
operator-lifecycle-manager-catalog   4.1.3     True        False         False      11m
service-ca                           4.1.3     True        False         False      11m
service-catalog-apiserver            4.1.3     True        False         False      9m4s
service-catalog-controller-manager   4.1.3     True        False         False      9m5s
storage                              4.1.3     True        False         False      8m6s

2.e UPIのインストールの完了

インストール作業の最終段階です。 前項2.dで全てのOperatorが正常に動作していることを確認後、下記のコマンドを実行します。

$ openshift-install --dir=bare-metal wait-for install-complete

その後、インストールプロセスが正常に完了すると、Web Consoleへのログイン情報が表示されます。 これでUPIのインストール作業は完了です。

INFO Waiting up to 30m0s for the cluster at https://api.test.example.local:6443 to initialize... 
INFO Waiting up to 10m0s for the openshift-console route to be created... 
INFO Install complete!                            
INFO To access the cluster as the system:admin user when using 'oc', run 'export KUBECONFIG=/root/OCP/bare-metal/auth/kubeconfig' 
INFO Access the OpenShift web-console here: https://console-openshift-console.apps.test.example.local 
INFO Login to the console with user: kubeadmin, password: XXXXX-XXXXX-XXXXX-XXXXX
  • 最後に表示されたuser: kubeadmin,password: XXXXX-XXXXX-XXXXX-XXXXXを使用して、Web Consoleへログインします。
Web Consoleへのログイン

最後に、WebブラウザでWeb Consoleにアクセスして、クラスタが正常に稼動しているか確認します。 検証環境では、下記のアドレスにアクセスします。

https://console-openshift-console.apps.test.example.local

Web Consoleへのログイン
Web Consoleへのログイン

ログイン後、Administration > Cluster Statusでクラスターのステータスに問題が無ければ正常稼動しています。

Cluster Status
Cluster Status

まとめ

以上、OpenShift 4.1をベアメタル環境にインストールする手順の紹介でした。 ここから先はOpenShiftに実際に触れる世界になります。 是非、身近な環境にOpenShiftをインストールしてどんどん使ってみて下さい！

Let's get Big Ideas!

参考：踏み台サーバーの構築

本記事の検証環境で使用した踏み台サーバーを構築するための設定のサンプルを載せておきます。

RHELの設定

1. サブスクリプション登録
# subscription-manager register
# subscription-manager attach --pool <ID>
2. IPv6無効化、IPv4ルーティング
# vi /etc/sysctl.d/99-custom.conf

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv4.ip_forward = 1

# sysctl -p /etc/sysctl.d/99-custom.conf
3. SELinux
# setsebool -P httpd_read_user_content 1
# setsebool -P haproxy_connect_any 1
4. 不要なサービスの停止
  • avahi-daemon
systemctl disable avahi-daemon.service 
systemctl stop avahi-daemon*
  • cups
# systemctl stop cups.service
# systemctl disable cups.service
  • rpcbind
# systemctl stop rpcbind.service
# systemctl stop rpcbind.socket
# systemctl disable rpcbind.service
# systemctl disable rpcbind.socket
  • libvirtd
# systemctl stop libvirtd.service
# systemctl disable libvirtd.service
5. NIC設定
  • 社内ネットワーク側（ens192）
# nmcli con modify ens192 ipv4.method manual
# nmcli con modify ens192 ipv4.addresses 192.168.1.21/24
# nmcli con modify ens192 ipv4.gateway 192.168.1.1
# nmcli con modify ens192 ipv4.dns 127.0.0.1
# nmcli con modify ens192 ipv6.method ignore
  • 検証用ネットワーク側（ens224）
# nmcli con modify ens224 ipv4.method manual
# nmcli con modify ens224 ipv4.addresses 172.16.0.1/24
# nmcli con modify ens224 ipv6.method ignore

firewalld

# firewall-cmd --set-default-zone=trusted
# firewall-cmd --add-masquerade --zone=trusted --permanent
# firewall-cmd --reload

dnsmasq

# vi /etc/dnsmasq.conf
  • サンプルコンフィグ（コメント行を除く）
port=53
domain-needed
bogus-priv
resolv-file=/etc/resolv.dnsmasq
no-poll
address=/apps.test.example.local/172.16.0.1
user=dnsmasq
group=dnsmasq
no-dhcp-interface=ens192
expand-hosts
domain=test.example.local
dhcp-range=172.16.0.100,172.16.0.200,255.255.255.0,12h
dhcp-host=XX:XX:XX:XX:XX:XX,bootstrap,172.16.0.100
dhcp-host=XX:XX:XX:XX:XX:XX,master-0,172.16.0.101
dhcp-host=XX:XX:XX:XX:XX:XX,master-1,172.16.0.102
dhcp-host=XX:XX:XX:XX:XX:XX,master-2,172.16.0.103
dhcp-host=XX:XX:XX:XX:XX:XX,worker-0,172.16.0.104
dhcp-host=XX:XX:XX:XX:XX:XX,worker-1,172.16.0.105
dhcp-option=option:dns-server,172.16.0.1
dhcp-leasefile=/var/lib/dnsmasq/dnsmasq.leases
srv-host=_etcd-server-ssl._tcp.test.example.local,etcd-0.test.example.local,2380,0,10
srv-host=_etcd-server-ssl._tcp.test.example.local,etcd-1.test.example.local,2380,0,10
srv-host=_etcd-server-ssl._tcp.test.example.local,etcd-2.test.example.local,2380,0,10
log-dhcp
log-facility=/var/log/dnsmasq.log
conf-dir=/etc/dnsmasq.d,.rpmnew,.rpmsave,.rpmorig
  • resolv.conf
# vi /etc/resolv.conf

nameserver 127.0.0.1
  • resolv.dnsmasq
# vi /etc/resolv.dnsmasq 

nameserver 192.168.1.1
  • hosts
# vi /etc/hosts

127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

#for OCP4
192.168.1.21    api
172.16.0.1  api-int
172.16.0.101    etcd-0
172.16.0.102    etcd-1
172.16.0.103    etcd-2
  • サービス登録、起動
# systemctl enable dnsmasq.service 
# systemctl start dnsmasq.service

HAproxy

# yum install haproxy
# vi /etc/haproxy/haproxy.cfg
  • サンプルコンフィグ（global,defaultsは初期コンフィグから変更無し。frontend,backendのみ記載）
frontend K8s-api
    bind *:6443
    option tcplog
    mode tcp
    default_backend     api-6443

frontend Machine-config
    bind *:22623
    option tcplog
    mode tcp
    default_backend     config-22623

frontend Ingress-http
    bind *:80
    option tcplog
    mode tcp
    default_backend http-80

frontend Ingress-https
    bind *:443
    option tcplog
    mode tcp
    default_backend     https-443


backend api-6443
    mode tcp
    balance     roundrobin
    option  ssl-hello-chk 
    server  bootstrap bootstrap.test.example.local:6443 check
    server  master-0 master-0.test.example.local:6443 check
    server  master-1 master-1.test.example.local:6443 check
    server  master-2 master-2.test.example.local:6443 check

backend config-22623
    mode tcp
    balance     roundrobin
    server  bootstrap bootstrap.test.example.local:22623 check
    server  master-0 master-0.test.example.local:22623 check
    server  master-1 master-1.test.example.local:22623 check
    server  master-2 master-2.test.example.local:22623 check

backend http-80
    mode tcp
    balance     roundrobin
    server  worker-0 worker-0.test.example.local:80 check
    server  worker-1 worker-1.test.example.local:80 check

backend https-443
    mode tcp
    balance     roundrobin
    option      ssl-hello-chk
    server  worker-0 worker-0.test.example.local:443 check
    server  worker-1 worker-1.test.example.local:443 check
  • サービス登録、起動
# systemctl enable haproxy.service 
# systemctl start haproxy.service

nginx

# yum install nginx
# vi /etc/nginx/nginx.conf
  • サンプルコンフィグ（初期コンフィグから変更点のみ記載）
http {

    server {
        listen       8008 default_server;   # ポート番号変更：80->8008
#        listen       [::]:80 default_server;   # コメントアウト

    }

    disable_symlinks off;   # 追加
}
  • サービス登録、起動
# systemctl enable nginx
# systemctl start nginx

*1:UPIでベアメタル環境へのインストールができるようになると、OpenShift 4の基本のアーキテクチャについて理解が深まり、他の環境へのインストールにも応用ができるようになると思います

*2:openshift.comにも英語のみですが同様のドキュメントがあります。Red Hat OpenShift Cluster Managerからリンクしているドキュメントはこちらになります。本記事の内容と合わせて読み進め下さい。Installing a cluster on bare metal - Installing on bare metal | Installing | OpenShift Container Platform 4.1

*3:Microsoft Azure上へのインストールは現在Developer Previewです

*4:テスト済みの環境情報についてはこちら（カスタマーポータルへのログインが必要）https://access.redhat.com/articles/4128421

*5:この記事の最大のポイントはココで、「必要最低限の構成、変更でいかにOpenShift 4を構築するか」、に重点をおいています

*6:環境にも寄りますが、手元の検証環境では20-30分程度でクラスタの作成が完了します

*7:Worker NodeにRHEL7.6を使用するオプションもあります

*8:UPIインストール後は操作端末に導入してあれこれ操作するのもありです

*9:操作端末がMacかLinuxであればそこでの利用は可能ですが、この検証環境では踏み台サーバー上で作業を完結することを想定して構成しています

*10:ドキュメントより：「RHCOS イメージは OpenShift Container Platform の各リリースごとに変更されない可能性があります。インストールする OpenShift Container Platform バージョンと等しいか、それ以下のバージョンの内で最も新しいバージョンのイメージをダウンロードする必要があります。利用可能な場合は、OpenShift Container Platform バージョンに一致するイメージのバージョンを使用します。」

*11:全てのマシン間で必要な通信ポートはドキュメントに記載があります→表3.1

*12:quay.ioからのイメージプルと、cloud.redhat.comへのTelemetryデータの通信が必要です

*13:SELinuxでhttp_port_t に登録されている番号を使用

*14:リリースが増えてた場合を見越して指定しやすいようにしています

*15:RHCOSの各ノードへは公開鍵認証方式でのSSH接続が必要です。SSH Agentに対応しているものがベターです

*16:ドキュメントでは「このキーを使用して、ユーザー core としてマスターノードに対して SSH を実行できます。」とありますが、実際にはBootstrap,Master,WorkerいづれのノードにもSSHでアクセスできます。

*17:ログの確認などの手順はまた別記事でまとめられればと思います

*18:baseDomain（ドメイン名）とname（クラスタ名）以外はドキュメントのサンプル通り。pullSecretとsshKeyの内容はシングルクォーテーションで囲まれるように。

*19:全台同時起動でも問題無いです。コンフィグファイルの取得ができるまで、Master,Worker Nodeは待機します。

*20:あくまで経験上ですが、繰り返し新規クラスタを作成している中ではここは必ず全て承認状態になっていました。

*21:ドキュメントには「全てのOperatorがAVAILABLEの場合インストールを完了することができます」と記載があります。実際、一部にDEGRADEDがある状態でもコマンド上はインストール完了になります。しかしながら、Web Console上ではエラーが発生していたり、OpenShiftとしての構築が未完了の状態になることがあります。

* 各記事は著者の見解によるものでありその所属組織を代表する公式なものではありません。その内容については非公式見解を含みます。