Red Hat Training
A Red Hat training course is available for OpenShift Container Platform
第20章 Google Compute Engine の設定
アプリケーションデータ用に 永続ストレージとして GCE ボリュームを使用するなど OpenShift Container Platform が既存の Google Compute Engine (GCE) インフラストラクチャー にアクセスするように設定します。
20.1. 作業を開始する前の注意事項
20.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 ドキュメントの新規サービスアカウントの作成セクション を参照してください。
20.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 ディスクは、1 つのゾーン内に作成されるので、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 の環境には、最低でも以下のハードウェア要件を満たす必要があります。
表20.1 インスタンスサイズ
ロール | サイズ |
---|---|
マスター |
|
ノード |
|
GCP では、カスタムのインスタンスサイズを作成して、異なる要件に適合できるようにします。詳細は、「カスタムのマシンタイプでのインスタンス作成」を参照するか、インスタンスサイズに関する詳細は、「マシンタイプ」および「OpenShift Container Platform のハードウェア最小要件」を参照してください。
- ストレージオプション
デフォルトでは、GCP インスタンスごとに、オペレーティングシステムを含む小規模な Root 永続ディスクが含まれます。インスタンスで実行するアプリケーションで、より多くのストレージ容量が必要な場合に、このインスタンスにさらにストレージオプションを追加できます
- 標準の永続ディスク
- SSD 永続ディスク
- ローカル SSD
- クラウドストレージバケット
詳細情報は、GCP ドキュメントのストレージオプション を参照してください。
20.2. OpenShift Container Platform での GCE の設定
OpenShift Container Platform は、GCE 用に 2 種類の方法で設定できます。
20.2.1. オプション 1: Ansible を使用した OpenShift Container Platform での GCP の設定
OpenShift Container Platform での Google Compute Platform (GCP) の設定は、インストール時またはインストール後に、Ansible インベントリーファイルを変更することで実行できます。
手順
最低でも、
openshift_cloudprovider_kind
,openshift_gcp_project
とopenshift_gcp_prefix
のパラメーター、マルチゾーンのデプロイメントにはオプションでopenshift_gcp_multizone
、デフォルトのネットワーク名を使用しない場合はopenshift_gcp_network_name
を定義する必要があります。インストール時に Ansible インベントリーファイルに以下のセクションを追加して、OpenShift Container Platform 環境で GCP を設定します。
[OSEv3:vars] openshift_cloudprovider_kind=gce openshift_gcp_project=<projectid> 1 openshift_gcp_prefix=<uid> 2 openshift_gcp_multizone=False 3 openshift_gcp_network_name=<network name> 4
- 1
- 既存のインスタンスを実行している GCP プロジェクト ID を指定します。この ID は、Google Cloud Platform Console でプロジェクトを作成すると生成されます。
- 2
- 一意の文字列を指定して、各 OpenShift Container Platform クラスターを特定します。これは、GCP 全体で一意でなければなりません。
- 3
- オプションで
True
の設定して、GCP でのマルチゾーンのデプロイメントをトリガーします。デフォルトではFalse
に設定されています。 - 4
- オプションで、
default
ネットワークを使用しない場合に、ネットワーク名を指定します。
Ansible でインストールすると、GCP 環境に適合されるように、以下のファイルが作成されて設定されます。
- /etc/origin/cloudprovider/gce.conf
- /etc/origin/master/master-config.yaml
- /etc/origin/node/node-config.yaml
-
GCP を使用してロードバランサーサービスを実行 する場合は、Compute Engine VM ノードインスタンスには
ocp
のサフィックスが必要です。たとえば、openshift_gcp_prefix
パラメーターの値をmycluster
に設定する場合は、このノードにmyclusterocp
のタグを付ける必要があります。Compute Engine VM インスタンスにネットワークタグを追加する方法に関する詳細は、「ネットワークタグの追加と削除」を参照してください。 オプションで、マルチゾーンサポートを設定できます。
クラスターのインストールプロセスでは、単一ゾーンのサポートがデフォルトで設定されますが、単一障害点を避けるためにマルチゾーンを設定することができます。
GCP ディスクがゾーン内に作成されるので、異なるゾーンで GCP に OpenShift Container Platform をデプロイすると、ストレージで問題が発生する可能性があります。OpenShift Container Platform ノードのホストがゾーン A でダウンし、Pod がゾーン B に移動した場合に、ディスクが異なるゾーンに配置されているので、永続ストレージはこれらの Pod にアタッチできません。詳細情報は、Kubernetes ドキュメントの マルチゾーンの制限 を参照してください。
Ansible インベントリーを使用してマルチゾーンサポートを有効にするには、以下のパラメーターを追加します。
[OSEv3:vars] openshift_gcp_multizone=true
シングルゾーンサポートに戻すには、
openshift_gcp_multizone
の値をfalse
に設定して、Ansible インベントリーファイルに戻ります。
20.2.2. オプション 2: OpenShift Container Platform での GCE の手動設定
20.2.2.1. GCE 向けのマスターホストの手動設定
全マスターホストで以下の手順を実行します。
手順
デフォルトでは、
/etc/origin/master/master-config.yaml
のマスター設定ファイルのapiServerArguments
とcontrollerArguments
に GCE パラメーターを追加します。apiServerArguments: cloud-provider: - "gce" cloud-config: - "/etc/origin/cloudprovider/gce.conf"* controllerArguments: cloud-provider: - "gce" cloud-config: - "/etc/origin/cloudprovider/gce.conf"*
Ansible を使用して GCP 用に OpenShift Container Platform を設定する場合には、/etc/origin/cloudprovider/gce.conf ファイルは自動的に作成されます。GCP 用の OpenShift Container Platform を手動で設定するので、このファイルを作成して、以下を入力する必要があります。
[Global] project-id = <project-id> 1 network-name = <network-name> 2 node-tags = <node-tags> 3 node-instance-prefix = <instance-prefix> 4 multizone = true 5
- 1
- 既存のインスタンスを実行している GCP プロジェクト ID を指定します。
- 2
- デフォルトを使用しない場合には、ネットワーク名を指定します。
- 3
- GCP ノードにタグを付けます。サフィックスに
ocp
を含める必要があります。たとえば、node-instance-prefix
パラメーターの値をmycluster
に設定する場合は、ノードはmyclusterocp
のタグを付ける必要があります。 - 4
- 一意の文字列を指定して、OpenShift Container Platform クラスターを特定します。
- 5
True
の設定して、GCP でのマルチゾーンのデプロイメントをトリガーします。デフォルトではFalse
に設定されています。
クラスターインストールでは、シングルゾーンのサポートがデフォルトで設定されます。
異なるゾーンで GCP に OpenShift Container Platform をデプロイすると、単一障害点を回避しやすくなりますが、ストレージで問題が発生する可能性があります。これは、GCP ディスクがゾーン内に作成されるためです。OpenShift Container Platform ノードのホストがゾーン A でダウンし、Pod がゾーン B に移動した場合に、ディスクが異なるゾーンに配置されているので、永続ストレージはこれらの Pod にアタッチできません。詳細情報は、Kubernetes ドキュメントの マルチゾーンの制限 を参照してください。
重要GCP を使用してロードバランサーサービスを実行 する場合は、Compute Engine VM ノードインスタンスには
ocp
のサフィックス:<openshift_gcp_prefix>ocp
が必要です。たとえば、openshift_gcp_prefix
パラメーターの値をmycluster
に設定する場合は、このノードにmyclusterocp
のタグを付ける必要があります。Compute Engine VM インスタンスにネットワークタグを追加する方法に関する詳細は、「ネットワークタグの追加と削除」を参照してください。OpenShift Container Platform サービスを再起動します。
# master-restart api # master-restart controllers # systemctl restart atomic-openshift-node
シングルゾーンサポートに戻すには、multizone
の値を false
に設定して、マスターとノードホストサービスを再起動します。
20.2.2.2. GCE 向けのノードホストの手動設定
全ノードホスト上で以下を実行します。
手順
適切なノード設定マップを編集して、
kubeletArguments
セクションの内容を更新します。kubeletArguments: *cloud-provider: - "gce" cloud-config: - "/etc/origin/cloudprovider/gce.conf"*
重要クラウドプロバイダーの統合を正常に機能させるため、
nodeName
は GCP のインスタンス名と一致していなければなりません。また、この名前は RFC1123 に準拠している必要もあります。すべてのノードで OpenShift Container Platform サービスを再起動します。
# systemctl restart atomic-openshift-node
20.2.3. GCP の OpenShift Container Platform レジストリーの設定
Google Cloud Platform (GCP) は、OpenShift Container Platform が OpenShift Container Platform コンテナーレジストリーを使用してコンテナーイメージを保存するために、使用可能なオブジェクトクラウドストレージを提供します。
詳細情報は、GCP ドキュメントのクラウドストレージ を参照してください。
前提条件
インストールする前に、バケットを作成して、レジストリーイメージをホストする必要があります。以下のコマンドでは、設定したサービスアカウントを使用してリージョンバケットを作成します。
gsutil mb -c regional -l <region> gs://ocp-registry-bucket cat <<EOF > labels.json { "ocp-cluster": "mycluster" } EOF gsutil label set labels.json gs://ocp-registry-bucket rm -f labels.json
デフォルトでは、バケットのデータは、Google が管理するキーを使用して自動的に暗号化されます。データの暗号化に別のキーを指定する場合には、GCP で利用可能な データ暗号化オプション を参照してください。
詳細情報は、ストレージバケットの作成ドキュメント を参照してください。
手順
レジストリーが Google Cloud Storage (GCS) バケットを使用できるように、Ansible インベントリーファイル を設定します。
[OSEv3:vars] # GCP Provider Configuration openshift_hosted_registry_storage_provider=gcs openshift_hosted_registry_storage_kind=object openshift_hosted_registry_replicas=1 1 openshift_hosted_registry_storage_gcs_bucket=<bucket_name> 2 openshift_hosted_registry_storage_gcs_keyfile=<bucket_keyfile> 3 openshift_hosted_registry_storage_gcs_rootdirectory=<registry_directory> 4
詳細情報は、GCP ドキュメントのクラウドストレージ を参照してください。
20.2.3.1. GCP 向けの OpenShift Container Platform レジストリーの手動設定
GCP オブジェクトストレージを使用するには、レジストリーの設定ファイルを編集してレジストリー Pod にマウントします。
ストレージドライバーの設定ファイルに関する詳細情報は、「Google Cloud ストレージドライバーのドキュメント」を参照してください。
手順
現在の/etc/registry/config.yml ファイルをエクスポートします。
$ oc get secret registry-config \ -o jsonpath='{.data.config\.yml}' -n default | base64 -d \ >> config.yml.old
以前の /etc/registry/config.yml ファイルから新規の設定ファイルを作成します。
$ cp config.yml.old config.yml
このファイルを編集して GCP パラメーターを追加します。レジストリーの設定ファイルの
storage
セクションに、バケットと keyfile を指定します。storage: delete: enabled: true cache: blobdescriptor: inmemory gcs: bucket: ocp-registry 1 keyfile: mykeyfile 2
registry-config
シークレットを削除します。$ oc delete secret registry-config -n default
シークレットを再作成して、更新された構成ファイルを参照します。
$ oc create secret generic registry-config \ --from-file=config.yml -n default
更新された設定を読み取るためにレジストリーを再デプロイします。
$ oc rollout latest docker-registry -n default
20.2.3.1.1. レジストリーが GCP オブジェクトストレージを使用していることを確認します。
レジストリーが GCP バケットストレージを使用しているかどうかを確認します。
手順
GCP ストレージを使用して正常にレジストリーをデプロイした後に、GCP バケットストレージではなく
emptydir
が使用される場合には、deploymentconfig
のレジストリーは、何も情報を表示しません。$ oc describe dc docker-registry -n default ... Mounts: ... /registry from registry-storage (rw) Volumes: registry-storage: Type: EmptyDir 1 ...
- 1
- Pod の寿命を共有する一時ディレクトリー
/registry のマウントポイントが空かどうかを確認します。これは、GCP ストレージが使用するボリュームです。
$ oc exec \ $(oc get pod -l deploymentconfig=docker-registry \ -o=jsonpath='{.items[0].metadata.name}') -i -t -- ls -l /registry total 0
空の場合は、GCP バケット設定が
registry-config
シークレットで実行されているためです。$ oc describe secret registry-config Name: registry-config Namespace: default Labels: <none> Annotations: <none> Type: Opaque Data ==== config.yml: 398 bytes
インストーラーは、「インストールドキュメントのストレージ」セクションで記載されているように、拡張されたレジストリー機能を使用して、希望の設定で config.yml ファイルを作成します。以下のコマンドで、ストレージバケット設定が保存されている
storage
セクションを含めて設定ファイルを表示します。$ oc exec \ $(oc get pod -l deploymentconfig=docker-registry \ -o=jsonpath='{.items[0].metadata.name}') \ cat /etc/registry/config.yml version: 0.1 log: level: debug http: addr: :5000 storage: delete: enabled: true cache: blobdescriptor: inmemory gcs: bucket: ocp-registry auth: openshift: realm: openshift middleware: registry: - name: openshift repository: - name: openshift options: pullthrough: True acceptschema2: True enforcequota: False storage: - name: openshift
または、以下でシークレットを表示できます。
$ oc get secret registry-config -o jsonpath='{.data.config\.yml}' | base64 -d version: 0.1 log: level: debug http: addr: :5000 storage: delete: enabled: true cache: blobdescriptor: inmemory gcs: bucket: ocp-registry auth: openshift: realm: openshift middleware: registry: - name: openshift repository: - name: openshift options: pullthrough: True acceptschema2: True enforcequota: False storage: - name: openshift
GCP コンソールで Storage を表示して Browser をクリックし、バケットを選択するか、
gsutil
コマンドを実行して、イメージのプッシュが正常に行われたことを確認します。$ gsutil ls gs://ocp-registry/ gs://ocp-registry/docker/ $ gsutil du gs://ocp-registry/ 7660385 gs://ocp-registry/docker/registry/v2/blobs/sha256/03/033565e6892e5cc6dd03187d00a4575720a928db111274e0fbf31b410a093c10/data 7660385 gs://ocp-registry/docker/registry/v2/blobs/sha256/03/033565e6892e5cc6dd03187d00a4575720a928db111274e0fbf31b410a093c10/ 7660385 gs://ocp-registry/docker/registry/v2/blobs/sha256/03/ ...
emptyDir
ボリュームを使用する場合には、/registry
マウントポイントは以下のようになります。
$ oc exec \ $(oc get pod -l deploymentconfig=docker-registry \ -o=jsonpath='{.items[0].metadata.name}') -i -t -- df -h /registry Filesystem Size Used Avail Use% Mounted on /dev/sdc 30G 226M 30G 1% /registry $ oc exec \ $(oc get pod -l deploymentconfig=docker-registry \ -o=jsonpath='{.items[0].metadata.name}') -i -t -- ls -l /registry total 0 drwxr-sr-x. 3 1000000000 1000000000 22 Jun 19 12:24 docker
20.2.4. OpenShift Container Platform が GCP ストレージを使用するように設定する
OpenShift Container Platform は、永続ボリュームメカニズムを活用して GCP ストレージを使用できます。OpenShift Container Platform は、GCP にディスクを作成して、正しいインスタンスにこのディスクをアタッチします。
GCP ディスクは ReadWriteOnce
アクセスモードで、1 つのノードで読み取り/書き込み可能な状態でボリュームをマウントできます。詳細情報は、『アーキテクチャーガイド』の「アクセスモード」のセクション を参照してください。
手順
OpenShift Container Platform は、
gce-pd
プロビジョナーを使用しており、Ansible インベントリーでopenshift_cloudprovider_kind=gce
およびopenshift_gcp_*
変数を使用する場合に、以下のstorageclass
を作成します。それ以外の場合、Ansible を使用せずに OpenShift Container Platform を設定しており、storageclass
はインストール時に作成されていない場合には、以下のように、手動で作成できます。$ oc get --export storageclass standard -o yaml apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: annotations: storageclass.kubernetes.io/is-default-class: "true" creationTimestamp: null name: standard selfLink: /apis/storage.k8s.io/v1/storageclasses/standard parameters: type: pd-standard provisioner: kubernetes.io/gce-pd reclaimPolicy: Delete
PV を要求して、以前の手順で示した storageclass を使用すると、OpenShift Container Platform は GCP インフラストラクチャーにディスクを作成します。ディスクが作成されたことを確認するには以下を実行します。
$ gcloud compute disks list | grep kubernetes kubernetes-dynamic-pvc-10ded514-7625-11e8-8c52-42010af00003 us-west1-b 10 pd-standard READY
20.3. サービスとしての GCP 外部のロードバランサー使用
LoadBalancer
サービスを使用してサービスを外部に公開することで、OpenShift Container Platform が GCP ロードバランサーを使用するように設定できます。OpenShift Container Platform は GCP にロードバランサーを作成し、必要なファイアウォールルールを作成します。
手順
新規アプリケーションを作成します。
$ oc new-app openshift/hello-openshift
ロードバランサーサービスを公開します。
$ oc expose dc hello-openshift --name='hello-openshift-external' --type='LoadBalancer'
このコマンドは、以下の例とよく似た
LoadBalancer
サービスを作成します。apiVersion: v1 kind: Service metadata: labels: app: hello-openshift name: hello-openshift-external spec: externalTrafficPolicy: Cluster ports: - name: port-1 nodePort: 30714 port: 8080 protocol: TCP targetPort: 8080 - name: port-2 nodePort: 30122 port: 8888 protocol: TCP targetPort: 8888 selector: app: hello-openshift deploymentconfig: hello-openshift sessionAffinity: None type: LoadBalancer
サービスが作成されたことを確認します。
$ oc get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE hello-openshift ClusterIP 172.30.62.10 <none> 8080/TCP,8888/TCP 20m hello-openshift-external LoadBalancer 172.30.147.214 35.230.97.224 8080:31521/TCP,8888:30843/TCP 19m
LoadBalancer
タイプと外部 IP の値は、サービスが GCP ロードバランサーを使用してアプリケーションを公開することを示します。
OpenShift Container Platform は、GCP インフラストラクチャーに、必要なオブジェクトを作成します。以下に例を挙げます。
ファイアウォール:
$ gcloud compute firewall-rules list | grep k8s k8s-4612931a3a47c204-node-http-hc my-net INGRESS 1000 tcp:10256 k8s-fw-a1a8afaa7762811e88c5242010af0000 my-net INGRESS 1000 tcp:8080,tcp:8888
注記これらのファイアウォールは、
<openshift_gcp_prefix>ocp
のタグがついたインスタンスに適用されます。たとえば、openshift_gcp_prefix
パラメーターがmycluster
に設定されている場合には、ノードにmyclusterocp
のタグを付ける必要があります。Compute Engine VM インスタンスにネットワークタグを追加する方法については、「ネットワークタグの追加と削除」を参照してください。ヘルスチェック:
$ gcloud compute http-health-checks list | grep k8s k8s-4612931a3a47c204-node 10256 /healthz
ロードバランサー:
$ gcloud compute target-pools list | grep k8s a1a8afaa7762811e88c5242010af0000 us-west1 NONE k8s-4612931a3a47c204-node $ gcloud compute forwarding-rules list | grep a1a8afaa7762811e88c5242010af0000 a1a8afaa7762811e88c5242010af0000 us-west1 35.230.97.224 TCP us-west1/targetPools/a1a8afaa7762811e88c5242010af0000
ロードバランサーが正しく設定されたことを確認するには、外部ホストから以下のコマンドを実行します。
$ curl 35.230.97.224:8080 Hello OpenShift!