Skip to main content
日本語は機械翻訳による参考訳です。内容に矛盾や不一致があった場合には、英語の内容が優先されます。

AzureでのRed Hat OpenShift Containerプラットフォームの導入と設定

共同作成者
PDF

AzureでのRed Hat OpenShift Containerプラットフォームの導入と設定

このセクションでは、AzureでOpenShiftクラスタをセットアップおよび管理し、それらにステートフルアプリケーションを導入する方法の概要的なワークフローについて説明します。ここでは、Trident / Astra Control Provisionerを使用して、NetApp Cloud Volumes ONTAPストレージを使用して永続ボリュームを提供する方法を示します。ステートフルアプリケーションに対してデータ保護と移行のアクティビティを実行するためのAstra Control Centerの使用方法について詳しく説明します。

次の図は、Azureに導入され、VPNを使用してデータセンターに接続されたクラスタを示しています。

入力/出力ダイアログを示す図、または書き込まれた内容を表す図

メモ Red Hat OpenShift ContainerプラットフォームクラスタをAzureに導入するには、いくつかの方法があります。このセットアップの概要概要 には、使用した具体的な方法のドキュメントへのリンクが記載されています。その他の方法については、に記載されている関連リンクを参照して "リソースセクション"ください。

セットアッププロセスは、次の手順に分けることができます。

CLIを使用してAzureにOCPクラスタをインストールします。

  • 記載されているすべての前提条件を満たしていることを確認します。 "こちらをご覧ください"。

  • VPN、サブネット、ネットワークセキュリティグループ、およびプライベートDNSゾーンを作成します。VPNゲートウェイおよびサイト間VPN接続を作成します。

  • オンプレミスとAzure間のVPN接続のために、pfsense VMを作成して設定しました。手順については、を参照してください "こちらをご覧ください"。

  • インストールプログラムとプルシークレットを入手し、ドキュメントに記載されている手順に従ってクラスタを導入する "こちらをご覧ください"。

  • クラスタのインストールが完了し、クラスタのコンソールにログインするためのkubeconfigファイルとユーザ名とパスワードが表示されます。

install-config.yamlファイルの例を以下に示します。

apiVersion: v1
baseDomain: sddc.netapp.com
compute:
- architecture: amd64
  hyperthreading: Enabled
  name: worker
  platform:
    azure:
      encryptionAtHost: false
      osDisk:
        diskSizeGB: 512
        diskType: "StandardSSD_LRS"
      type: Standard_D2s_v3
      ultraSSDCapability: Disabled
      #zones:
      #- "1"
      #- "2"
      #- "3"
  replicas: 3
controlPlane:
  architecture: amd64
  hyperthreading: Enabled
  name: master
  platform:
    azure:
      encryptionAtHost: false
      osDisk:
        diskSizeGB: 1024
        diskType: Premium_LRS
      type: Standard_D8s_v3
      ultraSSDCapability: Disabled
  replicas: 3
metadata:
  creationTimestamp: null
  name: azure-cluster
networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  machineNetwork:
  - cidr: 10.0.0.0/16
  networkType: OVNKubernetes
  serviceNetwork:
  - 172.30.0.0/16
platform:
  azure:
    baseDomainResourceGroupName: ocp-base-domain-rg
    cloudName: AzurePublicCloud
    computeSubnet: ocp-subnet2
    controlPlaneSubnet: ocp-subnet1
    defaultMachinePlatform:
      osDisk:
        diskSizeGB: 1024
        diskType: "StandardSSD_LRS"
      ultraSSDCapability: Disabled
    networkResourceGroupName: ocp-nc-us-rg
    #outboundType: UserDefinedRouting
    region: northcentralus
    resourceGroupName: ocp-cluster-ncusrg
    virtualNetwork: ocp_vnet_ncus
publish: Internal
pullSecret:
BlueXPを使用してAzureにCloud Volumes ONTAPを導入

  • Azureにコネクタをインストールします。手順を参照してください "こちらをご覧ください"。

  • コネクタを使用してAzureにCVOインスタンスを導入します。手順リンク：https://docs.netapp.com/us-en/bluexp-cloud-volumes-ontap/task-getting-started-azure.html [こちら]を参照してください。

AzureのOCPクラスタへのAstra Control Provisionerのインストール

  • このプロジェクトでは、すべてのクラスタ（オンプレミスクラスタ、Astra Control Centerが導入されているオンプレミスクラスタ、およびAzureのクラスタ）にAstra Control Provisioner（ACP）をインストールしました。Astra Control Provisionerの詳細 "こちらをご覧ください"。

  • バックエンドとストレージクラスを作成手順を参照してください"こちらをご覧ください"。

AzureのOCPクラスタをAstra Control Centerに追加します。
マルチゾーンアーキテクチャにTridentのCSIトポロジ機能を使用

今日のクラウドプロバイダは、Kubernetes / OpenShiftのクラスタ管理者がゾーンベースのクラスタのノードを生成できるようにしています。ノードは、リージョンによって異なるアベイラビリティゾーンに配置することも、リージョンによって配置することもできます。マルチゾーンアーキテクチャでワークロード用のボリュームのプロビジョニングを容易にするために、TridentではCSIトポロジを使用しています。CSI トポロジ機能を使用すると、領域およびアベイラビリティゾーンに基づいて、ボリュームへのアクセスをノードのサブセットに制限できます。詳細については、を参照してください"こちらをご覧ください"。

メモ Kubernetesは2つのボリュームバインドモードをサポートします。-VolumeBindingMode_が_Immediate（デフォルト）に設定されている場合、Tridentはトポロジを認識せずにボリュームを作成します。永続ボリュームは、要求側ポッドのスケジュール要件に依存せずに作成されます。-VolumeBindingMode_が_WaitForFirstConsumerに設定されている場合、PVCの永続ボリュームの作成とバインドは、そのPVCを使用するポッドがスケジュールされて作成されるまで遅延します。これにより、トポロジの要件に応じたスケジュールの制約を満たすようにボリュームが作成されます。Tridentストレージバックエンドは、アベイラビリティゾーン（トポロジ対応バックエンド）に基づいて選択的にボリュームをプロビジョニングするように設計できます。ストレージクラスがそのようなバックエンドを使用する場合、ボリュームは、サポートされているリージョン / ゾーンでスケジュールされているアプリケーションから要求された場合にのみ作成されます。（Topology-Aware StorageClass）詳細については、を参照してください"こちらをご覧ください"。

デモビデオ

Astra Controlを使用したアプリケーションのフェイルオーバーとフェイルバック