第20章 Azure の設定
20.1. 概要
OpenShift Container Platform は、「Microsoft Azure ディスクをアプリケーションデータの永続ストレージとして使用する」など、「Azure インフラストラクチャー」にアクセスするように設定できます。これを実行するには、Microsoft Azure を適切に設定した後に OpenShift Container Platform ホストで追加の設定を行う必要があります。
20.2. パーミッション
OpenShift Container Platform 向けに Microsoft Azure を設定するには、以下のロールが必要です。
Contributor |
すべての種類の Microsoft Azure リソースを作成し、管理します。 |
管理者ロールの追加に関する詳細情報は、「Azure サブスクリプション管理者の追加または変更」を参照してください。
20.3. 前提条件
- OpenShift Container Platform バージョン 3.5 以降で、Microsoft Azure Disk を永続ボリュームとして使用する場合には、Azure Cloud Provider を有効化する必要があります。
- Microsoft Azure で実行している OpenShift Container Platform ノードの仮想マシン (VM) はすべて、単一のリソースグループに所属する必要があります。
- Microsoft Azure 仮想マシンは、OpenShift Container Platform ノードと同じにする必要があり、これには大文字を含めることはできません。
Azure Managed Disks を使用する予定の場合:
- OpenShift Container Platform バージョン 3.7 以降が必要です。
- Azure Managed Disks で、仮想マシンを作成する必要があります。
アンマネージドディスクを使用する予定の場合:
- アンマネージドディスクで、仮想マシンを作成する必要があります。
- OpenShift Container Platform クラスターに、カスタムの DNS 設定を使用する場合やクラスターノードが別の Microsoft Azure Virtual Networks (VNet) に含まれる場合には、クラスター内の各ノードが他のノードの IP アドレスを解決できるように、DNS を設定する必要があります。
20.4. Azure 設定ファイル
Azure ついて OpenShift Container Platform を設定するには、各ノードホストに /etc/azure/azure.conf ファイルが必要です。
ファイルが存在しない場合は、ファイルを作成し、以下を追加します。
tenantId: <> 1 subscriptionId: <> 2 aadClientId: <> 3 aadClientSecret: <> 4 aadTenantId: <> 5 resourceGroup: <> 6 cloud: <> 7 location: <> 8 vnetName: <> 9 securityGroupName: <> 10 primaryAvailabilitySetName: <> 11
- 1
- クラスターがデプロイされているサブスクリプションの AAD テナント ID。
- 2
- クラスターがデプロイされている Azure サブスクリプション ID。
- 3
- Azure RM API と対話するための RBAC アクセス権を持つ AAD アプリケーションのクライアント ID。
- 4
- Azure RM API と対話するための RBAC アクセス権を持つ AAD アプリケーションのクライアントシークレット。
- 5
- これがテナント ID と同一であることを確認します (オプション)。
- 6
- Azure VM が属する Azure のリソースグループ名。
- 7
- 特定のクラウドリージョン。
AzurePublicCloud
など。 - 8
- コンパクトな形式の Azure リージョン。
southeastasia
など (オプション)。 - 9
- インスタンスを含む仮想ネットワーク。ロードバランサー作成時に使用します。
- 10
- インスタンスとロードバランサーに関連付けられているセキュリティーグループ名。
- 11
- ロードバランサーなどのリソースの作成時に使用するように設定されている可用性 (オプション)。
インスタンスへのアクセスに使用される NIC には internal-dns-name
が設定されている必要があります。これがないと、ノードはクラスターに再結合できず、コンソールにビルドログを表示できず、oc rsh
が正常に機能しなくなる可能性があります。
20.5. マスターの設定
すべてのマスターでマスター設定ファイル (デフォルトは /etc/origin/master/master-config.yaml) を編集するか、または作成し、apiServerArguments
と controllerArguments
の各セクションの内容を更新します。
kubernetesMasterConfig: ... apiServerArguments: cloud-provider: - "azure" cloud-config: - "/etc/azure/azure.conf" controllerArguments: cloud-provider: - "azure" cloud-config: - "/etc/azure/azure.conf"
コンテナー化インストールをトリガーすると、/etc/origin と /var/lib/origin のディレクトリーのみがマスターとノードのコンテナーにマウントされます。したがって、master-config.yaml は/etc/ ではなく /etc/origin/master になければなりません。
20.6. ノードの設定
すべてのノードでノード設定ファイル (デフォルトは /etc/origin/node/node-config.yaml) を編集するか、または作成し、
kubeletArguments
セクションの内容を更新します。kubeletArguments: cloud-provider: - "azure" cloud-config: - "/etc/azure/azure.conf"
重要コンテナー化インストールをトリガーすると、/etc/origin と /var/lib/origin のディレクトリーのみがマスターとノードのコンテナーにマウントされます。したがって、node-config.yaml は/etc/ ではなく /etc/origin/node になければなりません。
20.7. 設定変更の適用
マスターおよびノードのすべてのホストで OpenShift Container Platform サービスを起動または再起動し、設定の変更を適用します。「OpenShift Container Platform サービスの再起動」を参照してください。
# systemctl restart atomic-openshift-master-api atomic-openshift-master-controllers # systemctl restart atomic-openshift-node
クラウドプロバイダーを不使用から使用に切り替えるとエラーメッセージが表示されます。クラウドプロバイダーを追加すると、ノードが hostname を externalID
として使用する (クラウドプロバイダーが使用されていなかった場合のケース) 代わりに、クラウドプロバイダーの instance-id
(クラウドプロバイダーによって指定される) の使用に切り替えるため、ノードの削除が試みられます。この問題を解決するには、以下を実行します。
- CLI にクラスター管理者としてログインします。
既存のノードラベルをチェックし、これらをバックアップします。
$ oc describe node <node_name> | grep -Poz '(?s)Labels.*\n.*(?=Taints)'
ノードを削除します。
$ oc delete node <node_name>
各ノードホストで OpenShift Container Platform サービスを再起動します。
# systemctl restart atomic-openshift-node
- 以前に使用していた各ノードのラベルを再度追加します。