検索

第17章 Amazon Web サービス (AWS) の設定

download PDF

17.1. 概要

OpenShift Container Platform は、AWS ボリュームをアプリケーションデータの永続ストレージとして使用するなど、AWS EC2 インフラストラクチャーにアクセスできるように設定できます。これを実行するには、AWS を設定した後に OpenShift Container Platform ホストで追加の設定を行う必要があります。

17.2. パーミッション

OpenShift Container Platform で AWS を設定するには以下のパーミッションが必要です。

表17.1 マスターのパーミッション

Elastic Compute Cloud(EC2)

ec2:DescribeVolumeec2:CreateVolumeec2:CreateTagsec2:DescribeInstanceec2:AttachVolumeec2:DetachVolumeec2:DeleteVolumeec2:DescribeSubnetsec2:CreateSecurityGroupec2:DescribeSecurityGroupsec2:DescribeRouteTablesec2:AuthorizeSecurityGroupIngressec2:RevokeSecurityGroupIngressec2:DeleteSecurityGroup

Elastic Load Balancing

elasticloadbalancing:DescribeTagselasticloadbalancing:CreateLoadBalancerListenerselasticloadbalancing:ConfigureHealthCheckelasticloadbalancing:DeleteLoadBalancerListenerselasticloadbalancing:RegisterInstancesWithLoadBalancerelasticloadbalancing:DescribeLoadBalancerselasticloadbalancing:CreateLoadBalancerelasticloadbalancing:DeleteLoadBalancerelasticloadbalancing:ModifyLoadBalancerAttributeselasticloadbalancing:DescribeLoadBalancerAttributes

表17.2 ノードのパーミッション

Elastic Compute Cloud(EC2)

ec2:DescribeInstance*

重要
  • マスターホスト、ノードホスト、サブネットにはすべて、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 ホスト

  • インストーラー/Ansible を実行しているホストの tcp/22

etcd セキュリティーグループ

  • マスターの tcp/2379
  • etcd ホストの tcp/2380

マスターのセキュリティーグループ

  • tcp/8443 (0.0.0.0/0)
  • 3.2 よりも前にインストールされた環境、または 3.2 にアップグレードされた環境向けのすべての OpenShift Container Platform ホストの tcp/53
  • 3.2 よりも前にインストールされた環境、または 3.2 にアップグレードされた環境向けのすべての OpenShift Container Platform ホストの udp/53
  • 3.2 を使ってインストールされた新しい環境向けのすべての OpenShift Container Platform ホストの tcp/8053
  • 3.2 を使ってインストールされた新しい環境向けのすべての OpenShift Container Platform ホストの udp/8053

ノードのセキュリティーグループ

  • マスターの tcp/10250
  • ノードの udp/4789

インフラストラクチャーノード (OpenShift Container Platform ルーターをホストできるノード)

  • tcp/443 (0.0.0.0/0)
  • tcp/80 (0.0.0.0/0)

CRI-O

CRI-O を使用している場合は、tcp/10010 を開き、oc exec および oc rsh 操作を実行できるようにします。

マスターまたはルートの負荷分散のために外部のロードバランサー (ELB) を設定する場合は、ELB の Ingress および Egress のセキュリティーグループを設定することも必要になります。

17.3.1. 検出された IP アドレスとホスト名の上書き

AWS では、以下のような場合に変数の上書きが必要になります。

変数使用法

hostname

ユーザーが DNS hostnamesDNS resolution の両方に対して設定されていない VPC にインストールしている。

ip

複数のネットワークインターフェースを設定しており、デフォルト以外のインターフェースを使用することを検討している。

public_hostname

  • VPC サブネットが Auto-assign Public IP 向けに設定されていないマスターインスタンス。このマスターへの外部アクセスについては、ユーザーは ELB か、または必要な外部アクセスを提供する他のロードバランサーを使用する必要があります。または、VPN 接続を介してホストの内部名に接続する必要があります。
  • メタデータが無効にされているマスターインスタンス。
  • この値は、実際にはノードによって使用されません。

public_ip

  • VPC サブネットが Auto-assign Public IP について設定されていないマスターインスタンス。
  • メタデータが無効にされているマスターインスタンス。
  • この値は、実際にはノードによって使用されません。

EC2 ホストの場合はとくに、DNS ホスト名DNS 解決 の両方が有効にされている VPC にデプロイされる必要があります。

17.4. AWS 変数の設定

必要な AWS 変数を設定するには、OpenShift Container Platform のマスターとノード両方のすべてのホストに、/etc/origin/cloudprovider/aws.confファイルを以下の内容で作成します。

[Global]
Zone = us-east-1c 1
1
これは AWS インスタンスのアベイラビリティーゾーンであり、EBS ボリュームがある場所です。この情報は AWS マネジメントコンソールから取得されます。

17.5. OpenShift Container Platform での AWS の設定

AWS は OpenShift Container Platform に 2 通りの方法で設定できます。

17.5.1. Ansible を使用した OpenShift Container Platform での AWS の設定

クラスターのインストール時に、openshift_cloudprovider_aws_access_keyopenshift_cloudprovider_aws_secret_keyopenshift_cloudprovider_kindopenshift_clusterid のパラメーターを使用して、AWS を設定できます。これは、インベントリーファイルで設定可能です。

Ansible を使用した AWS の設定例

# Cloud Provider Configuration
#
# Note: You may make use of environment variables rather than store
# sensitive configuration within the ansible inventory.
# For example:
#openshift_cloudprovider_aws_access_key="{{ lookup('env','AWS_ACCESS_KEY_ID') }}"
#openshift_cloudprovider_aws_secret_key="{{ lookup('env','AWS_SECRET_ACCESS_KEY') }}"
#
#openshift_clusterid=unique_identifier_per_availablility_zone
#
# AWS (Using API Credentials)
#openshift_cloudprovider_kind=aws
#openshift_cloudprovider_aws_access_key=aws_access_key_id
#openshift_cloudprovider_aws_secret_key=aws_secret_access_key
#
# AWS (Using IAM Profiles)
#openshift_cloudprovider_kind=aws
# Note: IAM roles must exist before launching the instances.

注記

Ansible が AWS を設定する際に、必要な変更が以下のファイルに自動的に実行されます。

  • /etc/origin/cloudprovider/aws.conf
  • /etc/origin/master/master-config.yaml
  • /etc/origin/node/node-config.yaml

17.5.2. OpenShift Container Platform マスターでの AWS の手動設定

すべてのマスターで、マスター設定ファイル (デフォルトは /etc/origin/master/master-config.yaml) を編集するか、または作成し、apiServerArgumentscontrollerArguments の各セクションの内容を更新します。

kubernetesMasterConfig:
  ...
  apiServerArguments:
    cloud-provider:
      - "aws"
    cloud-config:
      - "/etc/origin/cloudprovider/aws.conf"
  controllerArguments:
    cloud-provider:
      - "aws"
    cloud-config:
      - "/etc/origin/cloudprovider/aws.conf"

現時点では、クラウドプロバイダーの統合を正常に機能させるため、nodeName は AWS のインスタンス名と一致している必要があります。また、この名前は RFC1123 に準拠している必要もあります。

重要

コンテナー化インストールをトリガーする場合、/etc/origin/var/lib/origin のディレクトリーのみがマスターとノードのコンテナーにマウントされます。したがって、aws.conf/etc/ ではなく /etc/origin/ になければなりません。

17.5.3. OpenShift Container Platform ノードでの AWS の手動設定

適切なノード設定マップを編集して、kubeletArguments セクションの内容を更新します。

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/origin/master/master.env ファイルおよびノードの /etc/sysconfig/atomic-openshift-node ファイルに設定されていることを確認します。

AWS_ACCESS_KEY_ID=<key_ID>
AWS_SECRET_ACCESS_KEY=<secret_key>
注記

アクセスキーは、AWS IAM ユーザーを設定する際に取得されます。

17.6. 設定変更の適用

マスターおよびノードのすべてのホストで OpenShift Container Platform サービスを起動または再起動し、設定の変更を適用します。「OpenShift Container Platform サービスの再起動」を参照してください。

# master-restart api
# master-restart controllers
# systemctl restart atomic-openshift-node

クラウドプロバイダーを使用しない状態から、使用するように切り替えると、エラーメッセージが表示されます。クラウドプロバイダーを追加すると、ノードが hostnameexternalID として使用する (クラウドプロバイダーが使用されていなかった場合のケース) 代わりに、クラウドプロバイダーの instance-id (クラウドプロバイダーによって指定される) の使用に切り替えるため、ノードの削除が試みられます。この問題を解決するには、以下を実行します。

  1. CLI にクラスター管理者としてログインします。
  2. 既存のノードラベルをチェックし、これらをバックアップします。

    $ oc describe node <node_name> | grep -Poz '(?s)Labels.*\n.*(?=Taints)'
  3. ノードを削除します。

    $ oc delete node <node_name>
  4. 各ノードホストで OpenShift Container Platform サービスを再起動します。

    # systemctl restart atomic-openshift-node
  5. 以前に使用していた各ノードのラベルを再度追加します。

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 へのラベル付けとタグ付けに関する詳細は、「Pod およびサービス」を参照してください。

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'
  • AWS インスタンスで使用する関連のセキュリティーグループすべて

    注記

    すべての既存セキュリティーグループに kubernetes.io/cluster/<name>,Value=<clusterid> のタグを付けないでください。その場合、Elastic Load Balancing (ELB) がロードバランサーを作成できなくなります。

リソースにタグを付けた後に、マスターサービスをマスター上で、ノードサービスをすべてのノード上で再起動します。「設定変更の適用」を参照してください。

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.