第23章 Google Compute Engine の設定
アプリケーションデータ用に 永続ストレージとして GCE ボリュームを使用する など OpenShift Container Platform が既存の Google Compute Engine (GCE) インフラストラクチャー にアクセスするように設定します。
23.1. 作業を開始する前に
23.1.1. Google Cloud Platform の認証の設定
ロール
OpenShift Container Platform に GCP を設定するには、以下の GCP ロールが必要です。
|
| サービスアカウント、クラウドストレージ、インスタンス、イメージ、テンプレート、Cloud DNS エントリーの作成や、ロードバランサーとヘルスチェックのデプロイに必要です。 |
ユーザーがテストフェーズ中に環境の再デプロイを想定している場合には、delete パーミッションが必要な場合もあります。
サービスアカウントを使用することで、GCP オブジェクトのデプロイ時に個人ユーザーの使用を回避することもできます。
ロールの設定方法に関する手順など、詳細は、GCP ドキュメントのロールの理解のセクション を参照してください。
スコープおよびサービスアカウント
GCP はスコープを使用して、承認済みのアイデンティティーが認証され、リソース内で操作が実行できるかどうかを判断します。たとえば、読み取り専用のスコープのアクセストークンを持つアプリケーション A は、読み取りだけできますが、読み取り/書き込みスコープのアクセストークンを持つアプリケーション B はデータの読み取りと変更が可能です。
スコープは、GCP API レベルで https://www.googleapis.com/auth/compute.readonly として定義されます。
インスタンスの作成時に --scopes=[SCOPE,…] オプションを使用してスコープを指定するか、インスタンスが GCP API にアクセスしないようにする場合には、--no-scopes オプションを使用してスコープなしでインスタンスを作成できます。
詳細情報は、GCP ドキュメントのスコープのセクション を参照してください。
GCP の全プロジェクトには、プロジェクトエディターパーミッションの付いた [PROJECT_NUMBER]-compute@developer.gserviceaccount.com サービスアカウントが含まれています。
デフォルトでは、新規作成されたインスタンスは自動的に有効化されて以下のアクセススコープが割り当てられたデフォルトのサービスアカウントとして実行されます。
- https://www.googleapis.com/auth/devstorage.read_only
- https://www.googleapis.com/auth/logging.write
- https://www.googleapis.com/auth/monitoring.write
- https://www.googleapis.com/auth/pubsub
- https://www.googleapis.com/auth/service.management.readonly
- https://www.googleapis.com/auth/servicecontrol
- https://www.googleapis.com/auth/trace.append
- https://www.googleapis.com/auth/bigquery
- https://www.googleapis.com/auth/cloud-platform
- https://www.googleapis.com/auth/compute.readonly
- https://www.googleapis.com/auth/compute
- https://www.googleapis.com/auth/datastore
- https://www.googleapis.com/auth/logging.write
- https://www.googleapis.com/auth/monitoring
- https://www.googleapis.com/auth/monitoring.write
- https://www.googleapis.com/auth/servicecontrol
- https://www.googleapis.com/auth/service.management.readonly
- https://www.googleapis.com/auth/sqlservice.admin
- https://www.googleapis.com/auth/devstorage.full_control
- https://www.googleapis.com/auth/devstorage.read_only
- https://www.googleapis.com/auth/devstorage.read_write
- https://www.googleapis.com/auth/taskqueue
- https://www.googleapis.com/auth/userinfo.email
インスタンスの作成時に、--service-account=SERVICE_ACCOUNT オプションで別のサービスアカウントを指定するか、gcloud CLI で --no-service-account オプションを使用してインスタンスのサービスアカウントを明示的に無効化します。
詳細情報は、GCP ドキュメントの新規サービスアカウントの作成セクション を参照してください。
23.1.2. Google Compute Engine オブジェクト
OpenShift Container Platform と Google Compute Engine (GCE) を統合するには、以下のコンポーネントまたはサービスが必要です。
- GCP プロジェクト
- GCP プロジェクトは、全 GCP サービスの作成、有効化、使用の基盤を形成するベースレベルの組織エンティティーです。これには、API の管理、課金の有効化、コラボレーターの追加/削除、パーミッションの管理が含まれます。
詳細情報は、GCP ドキュメントのプロジェクトリソースセクション を参照してください。
プロジェクト ID は一意識別子で、Google Cloud Engine すべてで一意でなければなりません。つまり、myproject という名前のプロジェクトがすでに作成されている場合には、このプロジェクト ID を使用できません。
- 請求書
- アカウントに課金がアタッチされていない限り、新規リソースを作成できません。新規プロジェクトは、既存のプロジェクトにリンクすることも、新規情報を入力することもできます。
詳細情報は、GCP ドキュメントの請求アカウントの作成、変更、終了 を参照してください。
- クラウドのアイデンティティーおよびアクセス管理
- OpenShift Container Platform のデプロイには、適切なパーミッションが必要です。ユーザーは、サービスアカウント、クラウドストレージ、インスタンス、イメージ、テンプレート、Cloud DNS エントリーの作成、ロードバランサーやヘルスチェックのデプロイができる必要があります。テスト中に環境を再デプロイできるようにするには、削除のパーミッションが役立ちます。
特定のパーミッションを割り当ててサービスアカウントを作成し、このアカウントを使用して、通常のユーザーではなくインフラストラクチャーコンポーネントをデプロイします。また、異なるユーザーまたはサービスアカウントへのアクセスを制限するためのロールを作成することも可能です。
GCP インスタンスは、サービスアカウントを使用して、アプリケーションが GCP API を呼び出せるようにします。たとえば、OpenShift Container Platform ノードホストは、GCP ディスク API を呼び出して、アプリケーションに永続ボリュームを提供することができます。
IAM サービスを使用することで、さまざまなインフラストラクチャーやサービスリソースへのアクセス制御、粒度の細かいロールを利用できます。詳細情報は、GCP ドキュメントのクラウドの概要へのアクセスのセクション を参照してください。
- SSH キー
- GCP は、作成したインスタンスで SSH を使用してログインできるように、SSH 公開キーを認証キーとして注入します。インスタンス別またはプロジェクト別に SSH キーを設定できます。
既存の SSH キーを使用できます。GCP メタデータは、ブート時にインスタンスに注入して SSH アクセスを可能にする、SSH キーの保存に役立ちます。
詳細情報は、GCP ドキュメントのメタデータセクション を参照してください。
- GCP リージョンおよびゾーン
- GCP には、リージョンとアベイラビリティーゾーンに対応するグローバルインフラストラクチャーがあります。GCP にある OpenShift Container Platform を異なるゾーンにデプロイすると、単一障害点を回避できますが、ストレージに関して注意点があります。
GCP ディスクがゾーン内に作成されます。そのため、OpenShift Container Platform ノードのホストがゾーン A でダウンし、Pod がゾーン B に移動した場合に、ディスクが異なるゾーンに配置されているので、永続ストレージはこれらの Pod にアタッチできません。
OpenShift Container Platform をインストールする前に、複数のゾーンからなる OpenShift Container Platform 環境のゾーンの 1 つをデプロイするかどうか判断するのは重要です。複数ゾーン環境をデプロイする場合には、単一のリージョンに 3 つの異なるゾーンを使用する設定が推奨されます。
詳細情報は、GCP ドキュメントのリージョンとゾーン および Kubernetes ドキュメントの複数ゾーン を参照してください。
- 外部 IP アドレス
- GCP インスタンスがインターネットと通信できるように、インスタンスに外部 IP アドレスをアタッチする必要があります。また、外部 IP アドレスは、Virtual Private Cloud (VPC) ネットワーク外から、GCP にデプロイされたインスタンスと通信するのに必要です。
インターネットアクセスに 外部 IP アドレス が必要になるので、 プロバイダーには制限となります。受信トラフィックが必要ない場合には、ファイアウォールルールを設定して、インスタンスで受信する外部トラフィックをブロックすることができます。
詳細情報は、GCP ドキュメントの外部 IP アドレス を参照してください。
- クラウド DNS
- GCP クラウド DNS は、GCP DNS サーバーを使用してドメイン名をグローバル DNS に公開するために使用する DNS サービスです。
パブリッククラウドの DNS ゾーンには、Google のドメインサービスまたはサードパーティーのプロバイダーを使用して購入したドメイン名を使用する必要があります。ゾーンを作成する時に、Google が提供するネームサーバーをレジストラーに追加 する必要があります。
詳細情報は、GCP ドキュメントの Cloud DNS セクションを参照してください。
GCP VPC ネットワークには、内部ホスト名を自動的に解決する内部の DNS サービスがあります。
インスタンスに対する内部の完全修飾ドメイン名 (FQDN) は、[HOST_NAME].c.[PROJECT_ID].internal 形式に従います。
詳細情報は、GCP ドキュメントの内部 DNS を参照してください。
- 負荷分散
- GCP 負荷分散サービスにより、GCP クラウド内の複数のインスタンスに、トラフィックを分散することができます。
負荷分散には 5 つのタイプがあります。
HTTPS および TCP Proxy 負荷分散は、マスターノードに HTTPS ヘルスチェックを使用する唯一の方法で、/healthz のステータスを確認します。
HTTPS 負荷分散には、カスタムの証明書が必要なので、この実装は、TCP Proxy 負荷分散を使用して、このプロセスを簡素化します。
詳細情報は、GCP ドキュメントの負荷分散 を参照してください。
- インスタンスサイズ
- 正常な OpenShift Container Platform の環境には、最低でも以下のハードウェア要件を満たす必要があります。
| ロール | Size |
|---|---|
| マスター |
|
| ノード |
|
GCP では、カスタムのインスタンスサイズを作成して、異なる要件に適合します。詳細は、カスタムのマシンタイプでのインスタンス作成 を参照するか、インスタンスサイズに関する詳細は、マシンタイプ および OpenShift Container Platform のハードウェア最小要件 を参照してください。
- ストレージオプション
デフォルトでは、GCP インスタンスごとに、オペレーティングシステムを含む小規模な Root 永続ディスクが含まれます。インスタンスで実行するアプリケーションで、より多くのストレージ容量が必要な場合に、このインスタンスにさらにストレージオプションを追加できます
- 標準の永続ディスク
- SSD 永続ディスク
- ローカル SSD
- クラウドストレージバケット
詳細情報は、GCP ドキュメントのストレージオプション を参照してください。
