OpenShift 4.2 UPIインストール（4.1からの変更点）

Red Hatの福岡オフィスでソリューションアーキテクトをしている田中司恩です。 OpenShift 4.2がGAになってからしばらく経ちました。みなさま検証などは進んでいますでしょうか？今回はOpenShift 4.2をUPIインストールするにあたり、4.1から変更があった内容についていくつかピックアップして解説いたします。

本記事で紹介する内容以外は、4.1の手順で4.2 UPIインストールが可能です。説明に使用する環境構成は以前の記事と同様ですので、合わせてこちらもご参照ください。 rheb.hatenablog.com

本記事では下記の内容について説明いたします。

UPIインストール環境
ネットワーク制限環境下およびProxy環境下でのインストール
マスターノードがスケジュール対象になる

4.2 UPIベアメタルインストールの日本語ドキュメントは下記になります。

第6章ベアメタルへのインストール 4.2 | Red Hat Customer Portal

UPIインストール環境

UPIインストールでサポートされる環境にGCPが追加されました。現時点でサポートされる環境は下記の通りです。

AWS
GCP
VMware vSphere
ベアメタル

ネットワーク制限環境下およびProxy環境下でのインストール

企業内の環境において、クラスタからインターネットへ接続ができない環境や、Proxyを経由してアクセスする環境でのインストールができるようになりました。

1.2. 新機能および改良された機能 4.2 | Red Hat Customer Portal

1.2.1.3. ネットワークが制限されたインストール
- OpenShift Container Platform 4.2 では、接続するネットワークが制限された環境での OpenShift Container Platform クラスターのインストールおよび更新のサポートが導入されました。
ローカルにミラーのコンテナレジストリを構築し、OpenShift 4.2のインストール時にそこからイメージリポジトリをミラーする方法です。*1

2019/11/24追記ネットワークが制限された環境下でのインストールについて、別記事を書きました。手順などの詳細は下記の記事を参考にしてください。

rheb.hatenablog.com

1.2.1.4. クラスター全体の egress プロキシー
- OpenShift Container Platform 4.2 では、ユーザーによってプロビジョニングされるインフラストラクチャーでの企業プロキシーサーバーを使用した OpenShift Container Platform クラスターのインストールおよび更新のサポートが導入されました。
こちらについてはすでに別記事を書いていますので、下記記事を参考にしてください。 rheb.hatenablog.com

マスターノードがスケジュール対象になる

これは地味な変更点なのですが、4.1と同じ感覚で4.2のインストールテストをしていて「あれ？」となったので、詳しく説明いたします。*2

まず、OpenShift 4.2を4.1と同じ手順でUPIインストールすると、ノードのROLESが下記のようになります。

# oc get nodes
NAME       STATUS   ROLES           AGE   VERSION
master-0   Ready    master,worker   20m   v1.14.6+463c73f1f
master-1   Ready    master,worker   20m   v1.14.6+463c73f1f
master-2   Ready    master,worker   20m   v1.14.6+463c73f1f
worker-0   Ready    worker          20m   v1.14.6+463c73f1f
worker-1   Ready    worker          20m   v1.14.6+463c73f1f

注目頂きたいのが、master-0,1,2 のROLESです。 4.1までであればmaster となるべきところがmaster,workerとなっています。これはマスターノードもスケジュール対象となり、アプリケーションのPodが稼働する状態となっていることを表しています。

1.2. 新機能および改良された機能 4.2 | Red Hat Customer Portal

1.2.6.3. マスターノードがスケジュール対象になる
- OpenShift Container Platform 4.2 では、マスターノードがスケジュール対象になりました。詳細は、「Working with nodes」を参照してください。

4.2.4. Configuring master nodes as schedulable *3

By default, master nodes are not schedulable. However, if your cluster does not contain any worker nodes, then master nodes are marked schedulable by default.

デフォルトではマスターノードはスケジュール対象ではないですが、1台もワーカーノードが無いとマスターノードがスケジュール対象になる、ということです。

UPIでインストールの作業時にインストール設定ファイルinstall-config.yamlを作成しますが、この事象はその内容に関係します。

インストール設定ファイルの内容はこのような内容です。

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...'

workerのreplicasが0になっているのが確認できます。*4 この設定でインストールを行うため、その結果マスターノードがスケジュール対象になってしまうということです。回避策はインストール前か後に行う、2通りの方法があります。

1. インストール前に行う方法

インストールディレクトリを作成し、作成したインストール設定ファイルをコピーします。

インストールディレクトリ：bare-metal

$ mkdir bare-metal
$ vi install-config.yaml
$ cp install-config.yaml bare-metal/

マニフェストファイルを作成します

$ openshift-install create manifests --dir=bare-metal

マニフェスト作成後のインストールディレクトリ内は、下記のようになります。

$ tree bare-metal
bare-metal
├── manifests
│   ├── 04-openshift-machine-config-operator.yaml
│   ├── 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
│   ├── etcd-ca-bundle-configmap.yaml
│   ├── etcd-client-secret.yaml
│   ├── etcd-host-service-endpoints.yaml
│   ├── etcd-host-service.yaml
│   ├── etcd-metric-client-secret.yaml
│   ├── etcd-metric-serving-ca-configmap.yaml
│   ├── etcd-metric-signer-secret.yaml
│   ├── etcd-namespace.yaml
│   ├── etcd-service.yaml
│   ├── etcd-serving-ca-configmap.yaml
│   ├── etcd-signer-secret.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_master.yaml
    └── 99_openshift-machineconfig_worker.yaml
 
2 directories, 30 files

インストールディレクト内のmanifests/cluster-scheduler-02-config.ymlを編集します。

mastersSchedulable: true となっている行を、 mastersSchedulable: false に変更します。

Ignition 設定ファイルを作成します

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

このコマンド実行後は、マニフェストファイルは全て消えます。後は、Ignition 設定ファイルを配置して通常通りインストール作業を実行します。

2. インストール後に行う方法

この方法は、ドキュメントの 4.2.4. Configuring master nodes as schedulable に記載の方法です。

下記のコマンドを実行し、リソースを編集します

$ oc edit schedulers.config.openshift.io cluster

mastersSchedulable: true となっている行を、 mastersSchedulable: false に変更します。変更後はすぐに反映され、マスターノードのROLESがmasterのみになります。

なお、インストール前に設定変更せずにopenshift-install create ignition-configsを実行した場合、下記のように警告が出ます。このことからインストール前に注意喚起が行われていることが分かります。

$ 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

まとめ

OpenShift 4.2 UPIインストールにおける、4.1からの変更点をいくつかピックアップして紹介しました。 4.2では様々な機能面での追加だけでなく、GUIの見た目の変更も多数あります。特にDeveloper Consoleは触ってみたくなるUIになっていますので、是非4.2をインストールして新機能を体験してみてください。

Let's get Big Ideas!

*1:アップデートイメージの入手元の環境は、インターネットへのアクセスができる必要があります

*2:小規模環境でのテストならそのままでもほとんど影響は無いと思われますが、気になったので調べてみました

*3:2019年10月30日現在、英語版のみ公開のため

*4:UPIでのインストール仕様のため、wokerのreplicasを0にする必要があり、現時点で回避方法が無い…