検索

第21章 Azure の設定

download PDF

OpenShift Container Platform を、Microsoft Azure ロードバランサーおよび永続的なアプリケーションデータのディスクを使用するように設定できます。

21.1. 作業を開始する前の注意事項

21.1.1. Microsoft Azure の承認の設定

Azure ロール

OpenShift Container Platform 向けに Microsoft Azure を設定するには、以下の Microsoft Azure ロールが必要です。

Contributor

すべての種類の Microsoft Azure リソースを作成し、管理します。

詳細は、「Classic subscription administrator roles vs. Azure RBAC roles vs. Azure AD administrator roles documentation」を参照してください。

パーミッション

Microsoft Azure を OpenShift Container Platform 用に設定するには、Kubernetes サービスロードバランサーおよび永続ストレージのディスクの作成および管理を可能にするサービスプリンシパルが必要になります。サービスプリンシパルの値はインストール時に定義され、OpenShift Container Platform マスターおよびノードホストの /etc/origin/cloudprovider/azure.conf にある Azure 設定ファイルにデプロイされます。

手順

  1. Azure CLI を使用して、アカウントのサブスクリプション ID を取得します。

    # az account list
    [
    {
      "cloudName": "AzureCloud",
      "id": "<subscription>", 1
      "isDefault": false,
      "name": "Pay-As-You-Go",
      "state": "Enabled",
      "tenantId": "<tenant-id>",
      "user": {
        "name": "admin@example.com",
        "type": "user"
      }
    ]
    1
    新規パーミッションを作成するために使用するサブスクリプション ID。
  2. コントリビューターの Microsoft Azure ロールおよび Microsoft Azure サブスクリプションおよびリソースグループのスコープでサービスプリンシパルを作成します。インベントリーを定義する際に使用されるこれらの値の出力を記録します。以下の値の代わりに、直前の手順の <subscription> 値を使用します。

    # az ad sp create-for-rbac --name openshiftcloudprovider \
         --password <secret> --role contributor \
         --scopes /subscriptions/<subscription>/resourceGroups/<resource-group>
    
    Retrying role assignment creation: 1/36
    Retrying role assignment creation: 2/36
    {
      "appId": "<app-id>",
      "displayName": "ocpcloudprovider",
      "name": "http://ocpcloudprovider",
      "password": "<secret>",
      "tenant": "<tenant-id>"
    }

21.1.2. Μicrosoft Azure オブジェクトの設定

OpenShift Container Platform と Microsoft Azure を統合する際に、可用性が高く、全機能装備の環境を作成するには以下のコンポーネントまたはサービスが必要です。

重要

十分な量のインスタンスを起動できるようにするために、インスタンスの作成前に Microsoft から CPU クォータの引き上げを要求します。

リソースグループ
リソースグループには、ネットワーク、ロードバランサー、仮想マシンおよび DNS を含む、デプロイメント用のすべての Microsoft Azure コンポーネントが含まれます。クォータおよびパーミッションをリソースグループに適用し、Microsoft Azure でデプロイされるリソースを制御し、管理できます。リソースグループは地理的リージョンごとに作成され、定義されます。OpenShift Container Platform 環境用に作成されるすべてのリソースは同じ地理的リージョン内および同じリソースグループ内に置かれる必要があります。

詳細は、「Azure Resource Manager overview」を参照してください。

Azure 仮想ネットワーク
Azure 仮想ネットワークは Azure クラウドネットワークを相互に分離するために使用されます。インスタンスおよびロードバランサーは仮想ネットワークを使用して、相互の通信およびインターネットでの通信を許可します。仮想ネットワークは 1 つまたは多くのサブネットがリソースグループ内のコンポーネントによって使用されることを許可します。仮想ネットワークは各種の VPN サービスに接続することもでき、オンプレミスサービスとの通信が可能にします。

詳細は、「What is Azure Virtual Network?」を参照してください。

Azure DNS
Azure は、内部のインターネットでアクセス可能なホスト名およびロードバランサーを解決するマネージド DNS サービスを提供します。リファレンス環境は DNS ゾーンを使用して 3 つの DNS A レコードをホストし、パブリック IP の OpenShift Container Platform リソースおよび bastion へのマッピングを許可します。

詳細は、「What is Azure DNS?」を参照してください。

負荷分散
Azure ロードバランサーは、Azure 環境内の仮想マシンで実行されているサービスのスケーリングおよび高可用性に必要なネットワークの接続性を確保します。

詳細は、「What is Azure Load Balancer?」を参照してください。

ストレージアカウント
ストレージアカウントは、仮想マシンなどのリソースが Microsoft Azure で提供される各種のストレージコンポーネントにアクセスできるようにします。インストール時に、ストレージアカウントは OpenShift Container Platform レジストリーに使用されるオブジェクトベースの blob ストレージの場所を定義します。

詳細は、「Introduction to Azure Storage」を参照してください。レジストリーのストレージアカウントを作成する手順については、「OpenShift Container Platform レジストリーでの Microsoft Azure の設定」セクションを参照してください。

サービスプリンシパル
Azure は、Azure 内でコンポーネントにアクセスし、管理し、または作成するサービスアカウントを作成する機能を提供します。サービスアカウントは、特定のサービスへの API アクセスを付与します。たとえば、サービスプリンシパルは Kubernetes または OpenShift Container Platform インスタンスが永続ストレージおよびロードバランサーを要求できるようにします。サービスプリンシパルは、インスタンスまたはユーザーに特定の機能についての綿密なアクセスを付与することを可能にします。

詳細は、「Application and service principal objects in Azure Active Directory」を参照してください。

可用性セット
可用性セットにより、デプロイされた VM をクラスター内の複数の分離したハードウェアノードに分散できます。この分散により、クラウドプロバイダーハードウェアのメンテナンスが行われる場合など、複数のインスタンスすべてが特定のノードで実行されないようにするのに役立ちます。

インスタンスをそれぞれのロールに基づいて異なる可用性セットにセグメント化する必要があります。たとえば、3 つのマスターノードを含む 1 つの可用性セット、インフラストラクチャーホストを含む 1 つの可用性セット、アプリケーションホストを含む 1 つの可用性セットにセグメント化できます。可用性セットによってセグメント化が可能になり、OpenShift Container Platform 内で外部ロードバランサーを使用することができます。

詳細は、「Manage the availability of Linux virtual machines」を参照してください。

ネットワークセキュリティーグループ
ネットワークセキュリティーグループ (NSG) は、Azure 仮想ネットワーク内にデプロイされたリソースへのトラフィックを許可/拒否するルールの一覧を提供します。NSG は数値の優先度の値およびルールを使用して相互の通信を許可される項目を定義します。通信を許可する場所を制限することができ、仮想ネットワーク内のみ、ロードバランサーから、または別の場所からなどと通信を制限することができます。

優先度の値により、管理者はポート通信が許可/拒否される順序について細かい値を付与することができます。

詳細は、「Plan virtual networks」を参照してください。

インスタンスサイズ
正常な OpenShift Container Platform の環境には、最低でも以下のハードウェア要件を満たす必要があります。

詳細は、OpenShift Container Platform ドキュメントの「Minimum Hadware Requirements」セクション、または「Sizes for Cloud Services」を参照してください。

21.2. 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 が正常に機能しなくなる可能性があります。

21.3. Microsoft Azure 上の OpenShift Container Platform のインベントリーサンプル

以下のインベントリーサンプルでは、以下の項目が作成されていることを前提としています。

  • リソースグループ
  • Azure 仮想ネットワーク
  • 必要な OpenShift Container Platform ポートが含まれる 1 つ以上のネットワークセキュリティーグループ
  • ストレージアカウント
  • サービスプリンシパル
  • 2 つのロードバランサー
  • ルーターおよび OpenShift Container Platform Web コンソールの 2 つ以上の DNS エントリー
  • 3 つの可用性セット
  • 3 つのマスターインスタンス
  • 3 つのインフラストラクチャーインスタンス
  • 1 つ以上のアプリケーションインスタンス

以下のインベントリーはデフォルトの storageclass を使用して、サービスプリンシパルで管理されるメトリクス、ロギング、およびサービスカタログコンポーネントで使用される永続ボリュームを作成します。レジストリーは Microsoft Azure Blob ストレージを使用します。

重要

Microsoft Azure インスタンスがマネージドディスクを使用する場合、インベントリーに以下の変数を指定します。

openshift_storageclass_parameters={'kind': 'managed', 'storageaccounttype': 'Premium_LRS'}

または、以下が表示されます。

openshift_storageclass_parameters={'kind': 'managed', 'storageaccounttype': 'Standard_LRS'}

これにより、storageclass はデプロイされたインスタンスに関連する PVs の適切なディスクタイプを作成します。アンマネージドディスクが使用される場合、storageclassshared パラメーターを使用して、アンマネージドディスクが PVs に作成されることを許可します。

[OSEv3:children]
masters
etcd
nodes

[OSEv3:vars]
ansible_ssh_user=cloud-user
ansible_become=true
openshift_cloudprovider_kind=azure

#cloudprovider
openshift_cloudprovider_kind=azure
openshift_cloudprovider_azure_client_id=v9c97ead-1v7E-4175-93e3-623211bed834
openshift_cloudprovider_azure_client_secret=s3r3tR3gistryN0special
openshift_cloudprovider_azure_tenant_id=422r3f91-21fe-4esb-vad5-d96dfeooee5d
openshift_cloudprovider_azure_subscription_id=6003c1c9-d10d-4366-86cc-e3ddddcooe2d
openshift_cloudprovider_azure_resource_group=openshift
openshift_cloudprovider_azure_location=eastus
#endcloudprovider

openshift_master_api_port=443
openshift_master_console_port=443
openshift_hosted_router_replicas=3
openshift_hosted_registry_replicas=1
openshift_master_cluster_method=native
openshift_master_cluster_hostname=openshift-master.example.com
openshift_master_cluster_public_hostname=openshift-master.example.com
openshift_master_default_subdomain=apps.openshift.example.com
openshift_deployment_type=openshift-enterprise
openshift_master_identity_providers=[{'name': 'idm', 'challenge': 'true', 'login': 'true', 'kind': 'LDAPPasswordIdentityProvider', 'attributes': {'id': ['dn'], 'email': ['mail'], 'name': ['cn'], 'preferredUsername': ['uid']}, 'bindDN': 'uid=admin,cn=users,cn=accounts,dc=example,dc=com', 'bindPassword': 'ldapadmin', 'ca': '/etc/origin/master/ca.crt', 'insecure': 'false', 'url': 'ldap://ldap.example.com/cn=users,cn=accounts,dc=example,dc=com?uid?sub?(memberOf=cn=ose-user,cn=groups,cn=accounts,dc=example,dc=com)'}]
networkPluginName=redhat/ovs-networkpolicy
openshift_examples_modify_imagestreams=true


# Storage Class change to use managed storage
openshift_storageclass_parameters={'kind': 'managed', 'storageaccounttype': 'Standard_LRS'}

# service catalog
openshift_enable_service_catalog=true
openshift_hosted_etcd_storage_kind=dynamic
openshift_hosted_etcd_storage_volume_name=etcd-vol
openshift_hosted_etcd_storage_access_modes=["ReadWriteOnce"]
openshift_hosted_etcd_storage_volume_size=SC_STORAGE
openshift_hosted_etcd_storage_labels={'storage': 'etcd'}

# metrics
openshift_metrics_install_metrics=true
openshift_metrics_cassandra_storage_type=dynamic
openshift_metrics_storage_volume_size=20Gi
openshift_metrics_hawkular_nodeselector={"node-role.kubernetes.io/infra": "true"}
openshift_metrics_cassandra_nodeselector={"node-role.kubernetes.io/infra": "true"}
openshift_metrics_heapster_nodeselector={"node-role.kubernetes.io/infra": "true"}

# logging
openshift_logging_install_logging=true
openshift_logging_es_pvc_dynamic=true
openshift_logging_storage_volume_size=50Gi
openshift_logging_kibana_nodeselector={"node-role.kubernetes.io/infra": "true"}
openshift_logging_curator_nodeselector={"node-role.kubernetes.io/infra": "true"}
openshift_logging_es_nodeselector={"node-role.kubernetes.io/infra": "true"}

# Setup azure blob registry storage
openshift_hosted_registry_storage_kind=object
openshift_hosted_registry_storage_azure_blob_accountkey=uZdkVlbca6xzwBqK8VDz15/loLUoc8I6cPfP31ZS+QOSxL6ylWT6CLrcadSqvtNTMgztxH4CGjYfVnRNUhvMiA==
openshift_hosted_registry_storage_provider=azure_blob
openshift_hosted_registry_storage_azure_blob_accountname=registry
openshift_hosted_registry_storage_azure_blob_container=registry
openshift_hosted_registry_storage_azure_blob_realm=core.windows.net

[masters]
ocp-master-1
ocp-master-2
ocp-master-3

[etcd]
ocp-master-1
ocp-master-2
ocp-master-3

[nodes]
ocp-master-1 openshift_node_group_name="node-config-master"
ocp-master-2 openshift_node_group_name="node-config-master"
ocp-master-3 openshift_node_group_name="node-config-master"
ocp-infra-1 openshift_node_group_name="node-config-infra"
ocp-infra-2 openshift_node_group_name="node-config-infra"
ocp-infra-3 openshift_node_group_name="node-config-infra"
ocp-app-1 openshift_node_group_name="node-config-compute"

21.4. OpenShift Container Platform での Microsoft Azure の設定

以下の 2 つの方法で OpenShift Container Platform で Microsoft Azure を設定できます。

21.4.1. Ansible を使用した OpenShift Container Platform での Azure の設定

OpenShift Container Platform での Azure の設定は、インストール時またはインストール後に Ansible インベントリーファイルを実行して行うことができます。

以下をデフォルトで /etc/ansible/hosts にある Ansible インベントリーファイルに追加し、Microsoft Azure 用に OpenShift Container Platform 環境を設定します。

[OSEv3:vars]
openshift_cloudprovider_kind=azure
openshift_cloudprovider_azure_client_id=<app_ID> 1
openshift_cloudprovider_azure_client_secret=<secret> 2
openshift_cloudprovider_azure_tenant_id=<tenant_ID> 3
openshift_cloudprovider_azure_subscription_id=<subscription> 4
openshift_cloudprovider_azure_resource_group=<resource_group> 5
openshift_cloudprovider_azure_location=<location> 6
1
サービスプリンシパルのアプリ ID。
2
サービスプリンシパルのパスワードを含むシークレット。
3
サービスプリンシパルが終了するテナント。
4
サービスプリンシパルによって使用されるサブスクリプション
5
サービスアカウントが存在するリソースグループ。
6
リソースグループが存在する Microsoft Azure の場所。

Ansible でインストールすると、Microsoft Azure 環境に適合するように、以下のファイルが作成されて設定されます。

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

21.4.2. OpenShift Container Platform での Microsoft Azure の手動設定

21.4.2.1. Microsoft Azure 向けのマスターホストの手動設定

全マスターホストで以下の手順を実行します。

手順

  1. すべてのマスター上の /etc/origin/master/master-config.yaml にデフォルトで置かれているマスター設定ファイルを編集し、apiServerArguments および controllerArguments セクションの内容を更新します。

    kubernetesMasterConfig:
      ...
      apiServerArguments:
        cloud-provider:
          - "azure"
        cloud-config:
          - "/etc/origin/cloudprovider/azure.conf"*
      controllerArguments:
        cloud-provider:
          - "azure"
        cloud-config:
          - "/etc/origin/cloudprovider/azure.conf"*
    重要

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

  2. Ansible を使用して Microsoft Azure について OpenShift Container Platform を設定する場合に、/etc/origin/cloudprovider/azure.conf ファイルが自動的に作成されます。OpenShift Container Platform で Microsoft Azure を手動で設定するため、すべてのノードインスタンスでファイルを作成し、以下を含める必要があります。

    tenantId: <tenant_ID> 1
    subscriptionId: <subscription> 2
    aadClientId: <app_ID> 3
    aadClientSecret: <secret> 4
    aadTenantId: <tenant_ID> 5
    resourceGroup: <resource_group> 6
    location: <location> 7
    1
    サービスプリンシパルが終了するテナント。
    2
    サービスプリンシパルによって使用されるサブスクリプション
    3
    サービスプリンシパルの appID の値。
    4
    サービスプリンシパルのパスワードを含むシークレット。
    5
    サービスプリンシパルが終了するテナント。
    6
    サービスアカウントが存在するリソースグループ。
    7
    リソースグループが存在する Microsoft Azure の場所。
  3. 次に OpenShift Container Platform マスターサービスを再起動します。

    # master-restart api
    # master-restart controllers

21.4.2.2. Microsoft Azure 向けのノードホストの手動設定

全ノードホスト上で以下を実行します。

手順

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

    kubeletArguments:
      cloud-provider:
        - "azure"
      cloud-config:
        - "/etc/origin/cloudprovider/azure.conf"
    重要

    インスタンスへのアクセスに使用される NIC には内部 DNS 名が設定されている必要があります。これがないと、ノードはクラスターに再結合できず、コンソールにビルドログを表示できず、oc rsh が正常に機能しなくなる可能性があります。

  2. すべてのノードで OpenShift Container Platform サービスを再起動します。

    # systemctl restart atomic-openshift-node

21.4.3. Microsoft Azure の OpenShift Container Platform レジストリーの設定

Microsoft Azure は、OpenShift Container Platform が OpenShift Container Platform コンテナーレジストリーを使用してコンテナーイメージを保存するために使用できるオブジェクトクラウドストレージを提供します。

詳細は、Azure ドキュメントでクラウドストレージについて参照してください。

レジストリーは、Ansible を使用するか、またはレジストリー設定ファイルを手動で設定して設定することができます。

前提条件

インストール前にレジストリーイメージをホストするためのストレージアカウントを作成する必要があります。以下のコマンドは、インストール時にイメージストレージに使用されるサービスアカウントを作成します。

コンテナーイメージを保存するために Microsoft Azure Blob ストレージを使用できます。OpenShift Container Platform レジストリーは Blob ストレージを使用して、管理者の介入なしにレジストリーのサイズを動的に拡張できるようにします。

  1. Azure ストレージアカウントを作成します。

    az storage account create
    --name <account_name> \
    --resource-group <resource_group> \
    --location <location> \
    --sku Standard_LRS

    これによってアカウントキーが作成されます。アカウントキーを表示するには、以下を実行します。

    az storage account keys list \
        --account-name <account-name> \
        --resource-group <resource-group> \
        --output table
    
    KeyName    Permissions    Value
    key1       Full           <account-key>
    key2       Full           <extra-account-key>

OpenShift Container Platform レジストリーの設定には、1 つのアカウントキー値のみが必要になります。

オプション 1: Ansible を使用した Azure の OpenShift Container Platform レジストリーの設定

手順

  1. レジストリーでストレージアカウントを使用できるように Ansible インベントリーを設定します。

    [OSEv3:vars]
    # Azure Registry Configuration
    openshift_hosted_registry_replicas=1 1
    openshift_hosted_registry_storage_kind=object
    openshift_hosted_registry_storage_azure_blob_accountkey=<account_key> 2
    openshift_hosted_registry_storage_provider=azure_blob
    openshift_hosted_registry_storage_azure_blob_accountname=<account_name> 3
    openshift_hosted_registry_storage_azure_blob_container=<registry> 4
    openshift_hosted_registry_storage_azure_blob_realm=core.windows.net
    1
    設定するレプリカ数
    2
    <account-name> に関連付けられたアカウントキー。
    3
    ストレージアカウント名。
    4
    データの保存に使用するディレクトリー。デフォルトは registry

オプション 2: Microsoft Azure についての OpenShift Container Platform レジストリーの手動設定

Microsoft Azure オブジェクトストレージを使用するには、レジストリーの設定ファイルを編集してレジストリー Pod にマウントします。

手順

  1. 現在の config.yml をエクスポートします。

    $ oc get secret registry-config \
        -o jsonpath='{.data.config\.yml}' -n default | base64 -d \
      >> config.yml.old
  2. 古い config.yml から新規の設定ファイルを作成します。

    $ cp config.yml.old config.yml
  3. ファイルを編集して Azure パラメーターを含めます。

    storage:
      delete:
        enabled: true
      cache:
        blobdescriptor: inmemory
      azure:
        accountname: <account-name> 1
        accountkey: <account-key> 2
        container: registry 3
        realm: core.windows.net 4
    1
    ストレージアカウント名に置き換えます。
    2
    <account-name> に関連付けられたアカウントキー。
    3
    データの保存に使用するディレクトリー。デフォルトは registry
    4
    デフォルトのストレージレルム core.windows.net
  4. registry-config シークレットを削除します。

    $ oc delete secret registry-config -n default
  5. シークレットを再作成して、更新された構成ファイルを参照します。

    $ oc create secret generic registry-config \
        --from-file=config.yml -n default
  6. 更新された設定を読み取るためにレジストリーを再デプロイします。

    $ oc rollout latest docker-registry -n default

レジストリーが Blob オブジェクトストレージを使用していることの確認

レジストリーが Microsoft Azure Blob ストレージを使用しているかどうかを確認するには、以下を実行します。

手順

  1. レジストリーの正常なデプロイ後に、レジストリー deploymentconfig は常にレジストリーが Microsoft Azure Blob ストレージではなく emptydir を使用していることを示します。

    $ oc describe dc docker-registry -n default
    ...
    Mounts:
      ...
      /registry from registry-storage (rw)
    Volumes:
    registry-storage:
    Type:       EmptyDir 1
    ...
    1
    Pod の寿命を共有する一時ディレクトリー
  2. /registry のマウントポイントが空かどうかを確認します。これは、Microsoft Azure ストレージが使用するボリュームです。

    $ oc exec \
        $(oc get pod -l deploymentconfig=docker-registry \
        -o=jsonpath='{.items[0].metadata.name}')  -i -t -- ls -l /registry
    total 0
  3. 空の場合は、Microsoft Azure Blob 設定が registry-config シークレットで実行されていることを示します。

    $ oc describe secret registry-config
    Name:         registry-config
    Namespace:    default
    Labels:       <none>
    Annotations:  <none>
    
    Type:  Opaque
    
    Data
    ====
    config.yml:  398 bytes
  4. インストーラーは、「インストールドキュメントのストレージ」セクションで記載されているように、拡張されたレジストリー機能を使用して、希望の設定で 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
        azure:
          accountname: registry
          accountkey: uZekVBJBa6xzwAqK8EDz15/hoHUoc8I6cPfP31ZS+QOSxLfo7WT7CLrVPKaqvtNTMgztxH7CGjYfpFRNUhvMiA==
          container: registry
          realm: core.windows.net
      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
      azure:
        accountname: registry
        accountkey: uZekVBJBa6xzwAqK8EDz15/hoHUoc8I6cPfP31ZS+QOSxLfo7WT7CLrVPKaqvtNTMgztxH7CGjYfpFRNUhvMiA==
        container: registry
        realm: core.windows.net
    auth:
      openshift:
        realm: openshift
    middleware:
      registry:
      - name: openshift
      repository:
      - name: openshift
        options:
          pullthrough: True
          acceptschema2: True
          enforcequota: False
      storage:
      - name: openshift

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

21.4.4. OpenShift Container Platform を Microsoft Azure ストレージを使用するように設定する

OpenShift Container Platform は、永続ボリュームメカニズムを活用して Microsoft Azure ストレージを使用できます。OpenShift Container Platform は、リソースグループにディスクを作成して、正しいインスタンスにこのディスクを割り当てます。

手順

  1. 以下の storageclass は、インストール時に、Ansible インベントリーで openshift_cloudprovider_kind=azure および openshift_cloud_provider_azure 変数を使用して Azure クラウドプロバイダーを設定する場合に作成されます。

    $ oc get --export storageclass azure-standard -o yaml
    apiVersion: storage.k8s.io/v1
    kind: StorageClass
    metadata:
      annotations:
        storageclass.kubernetes.io/is-default-class: "true"
      creationTimestamp: null
      name: azure-standard
    parameters:
      kind: Shared
      storageaccounttype: Standard_LRS
    provisioner: kubernetes.io/azure-disk
    reclaimPolicy: Delete
    volumeBindingMode: Immediate

    Ansible を使用して OpenShift Container Platform と Microsoft Azure の統合を有効にしていない場合には、storageclass を手動で作成できます。詳細は、「動的プロビジョニングとストレージクラスの作成」セクションを参照してください。

  2. 現時点で、デフォルトの storageclass の種類は shared であり、これは Microsoft Azure インスタンスがアンマネージドディスクを使用する必要があることを意味しています。インストール時に Ansible インベントリーファイルに openshift_storageclass_parameters={'kind': 'Managed', 'storageaccounttype': 'Premium_LRS'} または openshift_storageclass_parameters={'kind': 'Managed', 'storageaccounttype': 'Standard_LRS'} 変数を指定し、インスタンスがマネージドディスクを使用できるようにすることで、この設定をオプションで変更することができます。
注記

Microsoft Azure ディスクは ReadWriteOnce アクセスモードで、1 つのノードで読み取り/書き込み可能な状態でボリュームをマウントできます。詳細情報は、『アーキテクチャーガイド』の「アクセスモード」のセクション を参照してください。

21.5. Microsoft Azure 外部ロードバランサーのサービスとしての使用

OpenShift Container Platform は、LoadBalancer サービスを使用してサービスを外部に公開することで Microsoft Azure ロードバランサーを利用できます。OpenShift Container Platform は、ロードバランサーを Microsoft Azure で作成し、適切なファイアウォールルールを作成します。

重要

現時点で、Microsoft Azure インフラストラクチャーをクラウドプロバイダーとして使用し、またこれを外部ロードバランサーとして使用する際に追加の変数がこれに組み込まれるというバグがありました。詳細は、以下を参照してください。

前提条件

/etc/origin/cloudprovider/azure.conf にある Azure 設定ファイルが適切なオブジェクトで適切に設定されていることを確認します。/etc/origin/cloudprovider/azure.conf ファイルのサンプルについては、「OpenShift Container Platform での Microsoft Azure の手動設定」のセクションを参照してください。

値が追加されたら、すべてのホストで OpenShift Container Platform を再起動します。

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

21.5.1. ロードバランサーを使用したアプリケーションサンプルのデプロイ

手順

  1. 新規アプリケーションを作成します。

    $ oc new-app openshift/hello-openshift
  2. ロードバランサーサービスを公開します。

    $ 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
  3. サービスが作成されたことを確認します。

    $ oc get svc
    NAME                       TYPE           CLUSTER-IP       EXTERNAL-IP     PORT(S)                         AGE
    hello-openshift            ClusterIP      172.30.223.255   <none>          8080/TCP,8888/TCP               1m
    hello-openshift-external   LoadBalancer   172.30.99.54     40.121.42.180   8080:30714/TCP,8888:30122/TCP   4m

    LoadBalancer タイプおよび External-IP フィールドは、サービスが Microsoft Azure ロードバランサーを使用してアプリケーションを公開することを示しています。

これにより、Azure インフラストラクチャーで以下の必要なオブジェクトが作成されます。

  • ロードバランサー:

    az network lb list -o table
    Location    Name         ProvisioningState    ResourceGroup    ResourceGuid
    ----------  -----------  -------------------  ---------------  ------------------------------------
    eastus      kubernetes   Succeeded            refarch-azr      30ec1980-b7f5-407e-aa4f-e570f06f168d
    eastus      OcpMasterLB  Succeeded            refarch-azr      acb537b2-8a1a-45d2-aae1-ea9eabfaea4a
    eastus      OcpRouterLB  Succeeded            refarch-azr      39087c4c-a5dc-457e-a5e6-b25359244422

ロードバランサーが正しく設定されたことを確認するには、外部ホストから以下を実行します。

$ curl 40.121.42.180:8080 1
Hello OpenShift!
1
上記の EXTERNAL-IP 検証手順の値およびポート番号に置き換えます。
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.