This documentation is for a release that is no longer maintained
See documentation for the latest supported version 3 or the latest supported version 4.第17章 Amazon Web サービス (AWS) の設定
17.1. 概要 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform は、AWS ボリュームをアプリケーションデータの永続ストレージとして使用するなど、AWS EC2 インフラストラクチャーにアクセスできるように設定できます。これを実行するには、AWS を設定した後に OpenShift Container Platform ホストで追加の設定を行う必要があります。
17.2. パーミッション リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform で AWS を設定するには以下のパーミッションが必要です。
Elastic Compute Cloud(EC2) |
|
Elastic Load Balancing |
|
Elastic Compute Cloud(EC2) |
|
-
マスターホスト、ノードホスト、サブネットにはすべて、
kubernetes.io/cluster/<clusterid>,Value=(owned|shared)
のタグが必要です。 1 つのセキュリティーグループ (ノードにリンクされていることが望ましい) に
kubernetes.io/cluster/<clusterid>,Value=(owned|shared)
タグが必要です。-
すべてのセキュリティーグループに
kubernetes.io/cluster/<clusterid>,Value=(owned|shared)
のタグを付けないでください。その場合、Elastic Load Balancing (ELB) がロードバランサーを作成できなくなります。
-
すべてのセキュリティーグループに
17.3. セキュリティーグループの設定 リンクのコピーリンクがクリップボードにコピーされました!
AWS に OpenShift Container Platform をインストールする際は、適切なセキュリティーグループがセットアップされていることを確認してください。
セキュリティーグループにはいくつかのポートを設定しておく必要があり、それらがないとインストールは失敗します。また、インストールしようとしているクラスターの設定によっては、追加のポートが必要になる場合があります。セキュリティーグループの詳細、およびその適切な調整方法については、「必要なポート」を参照してください。
すべての OpenShift Container Platform ホスト |
|
etcd セキュリティーグループ |
|
マスターのセキュリティーグループ |
|
ノードのセキュリティーグループ |
|
インフラストラクチャーノード (OpenShift Container Platform ルーターをホストできるノード) |
|
CRI-O |
CRI-O を使用している場合は、tcp/10010 を開き、 |
マスターまたはルートの負荷分散のために外部のロードバランサー (ELB) を設定する場合は、ELB の Ingress および Egress のセキュリティーグループを設定することも必要になります。
17.3.1. 検出された IP アドレスとホスト名の上書き リンクのコピーリンクがクリップボードにコピーされました!
AWS では、以下のような場合に変数の上書きが必要になります。
変数 | 使用法 |
---|---|
|
ユーザーが |
|
複数のネットワークインターフェースを設定しており、デフォルト以外のインターフェースを使用することを検討している。ユーザーは |
|
|
|
|
openshift_hostname
がメタデータで提供される private-dns-name
値以外の値に設定される場合、それらのプロバイダーのネイティブクラウド統合は機能しなくなります。
EC2 ホストの場合にはとくに、DNS host names
と DNS resolution
の両方が有効にされている VPC にデプロイされる必要があります。openshift_hostname
は上書きできません。
17.4. AWS 変数の設定 リンクのコピーリンクがクリップボードにコピーされました!
必要な AWS 変数を設定するには、OpenShift Container Platform のマスターとノード両方のすべてのホストに、/etc/origin/cloudprovider/aws.confファイルを以下の内容で作成します。
[Global] Zone = us-east-1c
[Global]
Zone = us-east-1c
- 1
- これは AWS インスタンスのアベイラビリティーゾーンであり、EBS ボリュームがある場所です。この情報は AWS マネジメントコンソールから取得されます。
17.5. OpenShift Container Platform での AWS の設定 リンクのコピーリンクがクリップボードにコピーされました!
AWS は OpenShift Container Platform に 2 通りの方法で設定できます。
17.5.1. Ansible を使用した AWS についての OpenShift Container Platform の設定 リンクのコピーリンクがクリップボードにコピーされました!
AWS は、通常インストール (Advanced installation) の実行中に、openshift_cloudprovider_aws_access_key
、openshift_cloudprovider_aws_secret_key
、openshift_cloudprovider_kind
、openshift_clusterid
の各パラメーターを使って設定することができます。これらはインベントリーファイルで設定できます。
Ansible を使用した AWS の設定例
Ansible が AWS を設定する際に、必要な変更が以下のファイルに自動的に実行されます。
- /etc/origin/cloudprovider/aws.conf
- /etc/origin/master/master-config.yaml
- /etc/origin/node/node-config.yaml
- /etc/sysconfig/atomic-openshift-master-api
- /etc/sysconfig/atomic-openshift-master-controllers
- /etc/sysconfig/atomic-openshift-node
17.5.2. 手動による AWS についての OpenShift Container Platform マスターの設定 リンクのコピーリンクがクリップボードにコピーされました!
すべてのマスターでマスター設定ファイル (デフォルトは /etc/origin/master/master-config.yaml) を編集するか、または作成し、apiServerArguments
と controllerArguments
の各セクションの内容を更新します。
現時点では、クラウドプロバイダーの統合を正常に機能させるため、nodeName
は AWS のインスタンス名と一致している必要があります。また、この名前は RFC1123 に準拠している必要もあります。
コンテナー化インストールをトリガーする場合、/etc/origin と /var/lib/origin のディレクトリーのみがマスターとノードのコンテナーにマウントされます。したがって、aws.conf は /etc/ ではなく /etc/origin/ になければなりません。
17.5.3. 手動による AWS についての OpenShift Container Platform ノードの設定 リンクのコピーリンクがクリップボードにコピーされました!
すべてのノードでノード設定ファイル (デフォルトは /etc/origin/node/node-config.yaml) を編集するか、または作成し、kubeletArguments
セクションの内容を更新します。
kubeletArguments: cloud-provider: - "aws" cloud-config: - "/etc/origin/cloudprovider/aws.conf"
kubeletArguments:
cloud-provider:
- "aws"
cloud-config:
- "/etc/origin/cloudprovider/aws.conf"
コンテナー化インストールをトリガーする場合、/etc/origin と /var/lib/origin のディレクトリーのみがマスターとノードのコンテナーにマウントされます。したがって、aws.conf は /etc/ ではなく /etc/origin/ になければなりません。
17.5.4. キーと値のアクセスペアの手動設定 リンクのコピーリンクがクリップボードにコピーされました!
以下の環境変数が、マスターの /etc/sysconfig/atomic-openshift-master-api ファイルと /etc/sysconfig/atomic-openshift-master-controllers ファイル、およびノードの /etc/sysconfig/atomic-openshift-node ファイルに設定されていることを確認します。
AWS_ACCESS_KEY_ID=<key_ID> AWS_SECRET_ACCESS_KEY=<secret_key>
AWS_ACCESS_KEY_ID=<key_ID>
AWS_SECRET_ACCESS_KEY=<secret_key>
アクセスキーは、AWS IAM ユーザーを設定する際に取得されます。
17.6. 設定変更の適用 リンクのコピーリンクがクリップボードにコピーされました!
マスターおよびノードのすべてのホストで OpenShift Container Platform サービスを起動または再起動し、設定の変更を適用します。「OpenShift Container Platform サービスの再起動」を参照してください。
systemctl restart atomic-openshift-master-api atomic-openshift-master-controllers systemctl restart atomic-openshift-node
# 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 describe node <node_name> | grep -Poz '(?s)Labels.*\n.*(?=Taints)'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ノードを削除します。
oc delete node <node_name>
$ oc delete node <node_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 各ノードホストで OpenShift Container Platform サービスを再起動します。
systemctl restart atomic-openshift-node
# systemctl restart atomic-openshift-node
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 以前に使用していた各ノードのラベルを再度追加します。
17.7. クラスターに対する AWS のラベリング リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform バージョン 3.7 以降の atomic-openshift-installer
では、AWS プロバイダー認証情報を設定している場合に、すべてのホストにラベルが付けられていることを確認することも必要になります。
クラスターに関連付けられているリソースを正確に特定するには、キー kubernetes.io/cluster/<clusterid>
でリソースにタグを付けます。
-
<clusterid>
はクラスターに固有の名前です。
該当の値を、ノードがこのクラスターだけに所属する場合には owned
に、また、他のシステムとリソースが共有されている場合には shared
に設定します。
すべてのリソースに kubernetes.io/cluster/<clusterid>,Value=(owned|shared)
タグを付けることで、複数ゾーンまたは複数クラスターに関連する潜在的な問題を回避できます。
OpenShift Container Platform 3.6 よりも前のバージョンでは、これは Key=KubernetesCluster,Value=clusterid
でした。
OpenShift Container Platform へのラベル付けとタグ付けに関する詳細は、「Pods and Services」を参照してください。
17.7.1. タグを必要とするリソース リンクのコピーリンクがクリップボードにコピーされました!
タグ付けが必要なリソースは以下の 4 種類です。
- インスタンス
- セキュリティーグループ
- ロードバランサー
- EBS ボリューム
17.7.2. 既存クラスターへのタグ付け リンクのコピーリンクがクリップボードにコピーされました!
クラスターは kubernetes.io/cluster/<clusterid>,Value=(owned|shared)
タグの値を使用して、AWS クラスターに所属するリソースを判断します。したがって、関連のリソースはすべて、そのキーの同じ値を使用して kubernetes.io/cluster/<clusterid>,Value=(owned|shared)
タグでラベルを付ける必要があります。これらのリソースには以下が含まれます。
- 全ホスト
- AWS インスタンスで使用する関連のロードバランサーすべて
EBS ボリュームすべて。タグ付けが必要な EBS ボリュームは以下を使用して見つけることができます。
oc get pv -o json|jq '.items[].spec.awsElasticBlockStore.volumeID'
$ oc get pv -o json|jq '.items[].spec.awsElasticBlockStore.volumeID'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow AWS インスタンスで使用する関連のセキュリティーグループすべて
注記すべての既存セキュリティーグループに
kubernetes.io/cluster/<name>,Value=<clusterid>
のタグを付けないでください。その場合、Elastic Load Balancing (ELB) がロードバランサーを作成できなくなります。
リソースにタグを付けた後に、マスターサービスをマスター上で、ノードサービスをすべてのノード上で再起動します。「設定変更の適用」を参照してください。