エンタープライズ対応の Kubernetes コンテナプラットフォーム

Red Hatの須江です。

本記事はOpenShift Advent Calendar 2019の8日目です。 諸事情により12/9になってしまいましたが、本来は12/8分です。諸事情についてはのちほど。

OpenShift4をIPI(Installer Provisioned Infrastructure)でGCPにインストールする方法

基本的にはドキュメントの「第3章 GCP へのインストール」に従って粛々と進めればよいです。

https://access.redhat.com/documentation/ja-jp/openshift_container_platform/4.2/html/installing/installing-on-gcp

が、、、2019/12/9現在、GCPのIPIインストーラにバグがあり、この手順通りにすすめてもインストールが正常に完了しません。

• Bug 1779866 - When installing openshift via IPI on GCP, compute nodes fail to join the cluster https://bugzilla.redhat.com/show_bug.cgi?id=1779866

• Failed IPI install on GCP #2747 https://github.com/openshift/installer/issues/2747

そこで今回は、GCPへのOpenShift4インストール時に注意すべきポイントと、今回のようにインストールが正常に完了できない場合に何が起こっているのか確認する方法についてまとめます。

GCPへのIPIインストールの事前準備

GCPプロジェクト新規作成

IPIインストールではインストーラが多数のリソースを作成するため、リソース管理やアクセス管理を楽にするために専用のプロジェクトを作成しておいたほうがよいです。

APIサービスの有効化

インストーラがGoogle CloudのAPIを利用して環境を構築するので、ドキュメントに指定のあるAPIを有効化しておきます。 ドキュメンに"Google DNS API"とありますが、現在は"Google Cloud DNS API"に名前が変わっているようです。

一部APIは課金を有効にしていないと使えないため、クレジットカード等で決済手段を登録しておいてください。

Cloud DNSにManaged DNSゾーンを追加

インストーラが必要なDNSレコードを自動で登録するため、プロジェクトにOpenShift4クラスタ用のPublic Managed DNSゾーンを作成してください。 GCPでドメインを取得してもよいですし、外部DNSでサブドメインを作成して委譲してもよいです。

リソースリミットの緩和申請

• Compute Engine API Persistent Disk SSD (GB) 上限がデフォルト500GBと少ないので、1000GBくらいに拡張するようサポートチケットを発行してください。ドキュメントによると、デフォルトの構成(Master3台+Worker3台)で最低896GB必要とのことです。

• Compute Engine API: CPUs こちらも上限がデフォルト24で、Bootstrap Nodeの消滅後でぎりぎり足りる量です。ドキュメントによると28必要とあるので、事前に拡張しておくことをおすすめします。

申請してから実際に拡張されるまで2 business dayかかるよ、と言われますが、実際には数分から数十分程度で対応してもらえるようです。

サービスアカウント作成

インストーラが利用するサービスアカウントを作成し、プロジェクトオーナーのロールを付与しておきます。

ロールを細かく割り当てる場合には以下を参照してください。 - https://access.redhat.com/documentation/ja-jp/openshift_container_platform/4.2/html/installing/installing-on-gcp#installation-gcp-service-account_installing-gcp-account

インストーラから参照するため、サービスアカウントのキーをJSON形式で生成し、~/.gcp/osServiceAccount.json にコピーしておいてください。

GCPへのIPIインストール

try.openshift.com からGCPを選択してインストーラとCLI、Pull Secretなどを入手します。

インストール方法自体は他の環境とほぼ同じです。 GCP特有のパラメータは、インストーラがAPI経由で自動取得してデフォルト値を提示してくれますので、特に事前に調査しておかなくても大丈夫です。

問題発生! その時には

今回発生した現象

インストーラの進捗が99%から進まなくなり、"Still waiting for the cluster to initialize: Some cluster operators are still updating: authentication, console, image-registry, ingress, monitoring"が繰り返し表示されたあと、タイムアウトになってインストーラが異常終了します。

time="2019-12-09T01:03:42+09:00" level=debug msg="Still waiting for the cluster to initialize: Working towards 4.2.10: 99% complete, waiting on authentication, console, image-registry, ingress, monitoring"
time="2019-12-09T01:04:42+09:00" level=debug msg="Still waiting for the cluster to initialize: Working towards 4.2.10: 99% complete"
time="2019-12-09T01:07:27+09:00" level=debug msg="Still waiting for the cluster to initialize: Some cluster operators are still updating: authentication, console, image-registry, ingress, monitoring"
time="2019-12-09T01:09:13+09:00" level=debug msg="Still waiting for the cluster to initialize: Working towards 4.2.10: 99% complete"

何が起こっていたのか

Workerの仮想マシンは起動していましたが、クラスタのNodeとして追加されていない状態でした。 そのため、MasterにデプロイできないPodがpending状態になっており、それ以上インストーラの処理が進まない状態になっていました。

どうやって調べたか

OpenShift4クラスタの管理コンソールやCLIでの接続情報はインストール完了時に表示されるため、インストールが途中で止まった場合には通常の手段でクラスタにログインすることができません。

しかし、今回のようにMasterの構築が完了している場合には、インストーラが生成したkubeconfigを利用してクラスタを操作することができます。

$ export KUBECONFIG=${INSTALL_DIR}/auth/kubeconfig

$ oc get machine -n openshift-machine-api
NAME                   STATE     TYPE            REGION            ZONE                AGE
test-nldkb-m-0         RUNNING   n1-standard-4   asia-northeast1   asia-northeast1-a   3h7m
test-nldkb-m-1         RUNNING   n1-standard-4   asia-northeast1   asia-northeast1-b   3h7m
test-nldkb-m-2         RUNNING   n1-standard-4   asia-northeast1   asia-northeast1-c   3h7m
test-nldkb-w-a-sq659   RUNNING   n1-standard-4   asia-northeast1   asia-northeast1-a   3h5m
test-nldkb-w-b-55w5k   RUNNING   n1-standard-4   asia-northeast1   asia-northeast1-b   3h5m
test-nldkb-w-c-snj7m   RUNNING   n1-standard-4   asia-northeast1   asia-northeast1-c   3h5m
=>Machineは起動している(GCP管理コンソールからも確認できる)

$ oc get nodes
NAME                                                           STATUS   ROLES    AGE   VERSION
test-nldkb-m-0.asia-northeast1-a.c.openshift-261412.internal   Ready    master   3h    v1.14.6+31a56cf75
test-nldkb-m-1.asia-northeast1-b.c.openshift-261412.internal   Ready    master   3h    v1.14.6+31a56cf75
test-nldkb-m-2.asia-northeast1-c.c.openshift-261412.internal   Ready    master   3h    v1.14.6+31a56cf75
=>Node一覧にWorkerが存在しない

あとは、確認したいリソースをdescribeしたり、Podのログを見たりして、問題点を絞り込んでいきます。

網羅的に情報を取得したい場合

個別にリソースのダンプやログを取得するのが面倒な場合には、以下コマンドでクラスタ全体の情報をダンプすることもできます。

$ oc adm must-gather

実行すると must-gather.local.3528907227254367601 という感じでディレクトリが作成され、その下にクラスタ全体のリソースやログが階層化されたディレクトリに格納されます。

本来の用途はRed Hatのカスタマーサポートに情報を提供いただくためですが、コスト節約のためにクラスタを削除したいけど情報は残しておきたい、という場合などにも有用です。

おわりに

自分は普段AWSをメインに使っているのですが、「GCPでもIPIなら簡単にクラスタ建てられるぜイェーイ」と軽く考えていて撃沈しました。 いつか雪辱を果たしたいと思いますので、これからOpenShift4 on GCPの情報をこまめにウォッチします。(反省)

GCPへのOpenShift4インストール時に注意すべきポイントと、インストールが正常に完了できない場合に何が起こっているのか確認する方法を解説しています。

記事のリンク