7.2. 実稼働環境用のインフラストラクチャーマシンセットの作成
実稼働デプロイメントでは、インフラストラクチャーコンポーネントを保持するために 3 つ以上のマシンセットをデプロイすることが推奨されます。OpenShift Logging と Red Hat OpenShift Service Mesh の両方が Elasticsearch をデプロイします。これには、3 つのインスタンスを異なるノードにインストールする必要があります。これらの各ノードは、高可用性のために異なるアベイラビリティーゾーンにデプロイできます。このような設定では、各アベイラビリティーゾーンに 1 つずつ、3 つの異なるマシンセットが必要です。複数のアベイラビリティーゾーンを持たないグローバル Azure リージョンでは、アベイラビリティーセットを使用して高可用性を確保できます。
7.2.1. 異なるクラウドのマシンセットの作成
クラウドのサンプルマシンセットを使用します。
7.2.1.1. AWS 上のマシンセットカスタムリソースのサンプル YAML
このサンプル YAML は us-east-1a
Amazon Web Services (AWS) ゾーンで実行され、node-role.kubernetes.io/infra:""
というラベルが付けられたノードを作成するマシンセットを定義します。
このサンプルでは、infrastructure_id
はクラスターのプロビジョニング時に設定したクラスター ID に基づくインフラストラクチャー ID であり、<infra>
は追加するノードラベルです。
apiVersion: machine.openshift.io/v1beta1 kind: MachineSet metadata: labels: machine.openshift.io/cluster-api-cluster: <infrastructure_id> 1 name: <infrastructure_id>-infra-<zone> 2 namespace: openshift-machine-api spec: replicas: 1 selector: matchLabels: machine.openshift.io/cluster-api-cluster: <infrastructure_id> 3 machine.openshift.io/cluster-api-machineset: <infrastructure_id>-infra-<zone> 4 template: metadata: labels: machine.openshift.io/cluster-api-cluster: <infrastructure_id> 5 machine.openshift.io/cluster-api-machine-role: <infra> 6 machine.openshift.io/cluster-api-machine-type: <infra> 7 machine.openshift.io/cluster-api-machineset: <infrastructure_id>-infra-<zone> 8 spec: metadata: labels: node-role.kubernetes.io/infra: "" 9 taints: 10 - key: node-role.kubernetes.io/infra effect: NoSchedule providerSpec: value: ami: id: ami-046fe691f52a953f9 11 apiVersion: awsproviderconfig.openshift.io/v1beta1 blockDevices: - ebs: iops: 0 volumeSize: 120 volumeType: gp2 credentialsSecret: name: aws-cloud-credentials deviceIndex: 0 iamInstanceProfile: id: <infrastructure_id>-worker-profile 12 instanceType: m4.large kind: AWSMachineProviderConfig placement: availabilityZone: us-east-1a region: us-east-1 securityGroups: - filters: - name: tag:Name values: - <infrastructure_id>-worker-sg 13 subnet: filters: - name: tag:Name values: - <infrastructure_id>-private-us-east-1a 14 tags: - name: kubernetes.io/cluster/<infrastructure_id> 15 value: owned userDataSecret: name: worker-user-data
- 1 3 5 12 13 14 15
- クラスターのプロビジョニング時に設定したクラスター ID を基にするインフラストラクチャー ID を指定します。OpenShift CLI がインストールされている場合は、以下のコマンドを実行してインフラストラクチャー ID を取得できます。
$ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster
- 2 4 8
- インフラストラクチャー ID、
<infra>
ノードラベル、およびゾーンを指定します。 - 6 7 9
<infra>
ノードラベルを指定します。- 10
- ユーザーのワークロードが infra ノードにスケジュールされないようにテイントを指定します。
- 11
- OpenShift Container Platform ノードの AWS ゾーンに有効な Red Hat Enterprise Linux CoreOS (RHCOS) AMI を指定します。
$ oc -n openshift-machine-api \ -o jsonpath='{.spec.template.spec.providerSpec.value.ami.id}{"\n"}' \ get machineset/<infrastructure_id>-worker-<zone>
AWS で実行されるマシンセットは保証されていない Spot インスタンス をサポートします。AWS の On-Demand インスタンスと比較すると、Spot インスタンスをより低い価格で使用することでコストを節約できます。spotMarketOptions
を MachineSet
YAML ファイルに追加して、Spot インスタンスを設定 します。
7.2.1.2. Azure 上のマシンセットのカスタムリソースのサンプル YAML
このサンプル YAML は、リージョンの 1
Microsoft Azure ゾーンで実行され、node-role.kubernetes.io/infra: ""
というラベルの付けられたノードを作成するマシンセットを定義します。
このサンプルでは、infrastructure_id
はクラスターのプロビジョニング時に設定したクラスター ID に基づくインフラストラクチャー ID であり、<infra>
は追加するノードラベルです。
apiVersion: machine.openshift.io/v1beta1 kind: MachineSet metadata: labels: machine.openshift.io/cluster-api-cluster: <infrastructure_id> 1 machine.openshift.io/cluster-api-machine-role: <infra> 2 machine.openshift.io/cluster-api-machine-type: <infra> 3 name: <infrastructure_id>-infra-<region> 4 namespace: openshift-machine-api spec: replicas: 1 selector: matchLabels: machine.openshift.io/cluster-api-cluster: <infrastructure_id> 5 machine.openshift.io/cluster-api-machineset: <infrastructure_id>-infra-<region> 6 template: metadata: creationTimestamp: null labels: machine.openshift.io/cluster-api-cluster: <infrastructure_id> 7 machine.openshift.io/cluster-api-machine-role: <infra> 8 machine.openshift.io/cluster-api-machine-type: <infra> 9 machine.openshift.io/cluster-api-machineset: <infrastructure_id>-infra-<region> 10 spec: metadata: creationTimestamp: null labels: node-role.kubernetes.io/infra: "" 11 taints: 12 - key: node-role.kubernetes.io/infra effect: NoSchedule providerSpec: value: apiVersion: azureproviderconfig.openshift.io/v1beta1 credentialsSecret: name: azure-cloud-credentials namespace: openshift-machine-api image: offer: "" publisher: "" resourceID: /resourceGroups/<infrastructure_id>-rg/providers/Microsoft.Compute/images/<infrastructure_id> 13 sku: "" version: "" internalLoadBalancer: "" kind: AzureMachineProviderSpec location: <region> 14 managedIdentity: <infrastructure_id>-identity 15 metadata: creationTimestamp: null natRule: null networkResourceGroup: "" osDisk: diskSizeGB: 128 managedDisk: storageAccountType: Premium_LRS osType: Linux publicIP: false publicLoadBalancer: "" resourceGroup: <infrastructure_id>-rg 16 sshPrivateKey: "" sshPublicKey: "" subnet: <infrastructure_id>-<role>-subnet 17 18 userDataSecret: name: worker-user-data 19 vmSize: Standard_DS4_v2 vnet: <infrastructure_id>-vnet 20 zone: "1" 21
- 1 5 7 13 15 16 17 20
- クラスターのプロビジョニング時に設定したクラスター ID を基にするインフラストラクチャー ID を指定します。OpenShift CLI がインストールされている場合は、以下のコマンドを実行してインフラストラクチャー ID を取得できます。
$ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster
以下のコマンドを実行してサブネットを取得できます。
$ oc -n openshift-machine-api \ -o jsonpath='{.spec.template.spec.providerSpec.value.subnet}{"\n"}' \ get machineset/<infrastructure_id>-worker-centralus1
以下のコマンドを実行して vnet を取得できます。
$ oc -n openshift-machine-api \ -o jsonpath='{.spec.template.spec.providerSpec.value.vnet}{"\n"}' \ get machineset/<infrastructure_id>-worker-centralus1
- 2 3 8 9 11 18 19
<infra>
ノードラベルを指定します。- 4 6 10
- インフラストラクチャー ID、
<infra>
ノードラベル、およびリージョンを指定します。 - 12
- ユーザーのワークロードが infra ノードにスケジュールされないようにテイントを指定します。
- 14
- マシンを配置するリージョンを指定します。
- 21
- マシンを配置するリージョン内のゾーンを指定します。リージョンがゾーンをサポートすることを確認してください。
Azure で実行されるマシンセットは、保証されていない Spot 仮想マシン をサポートします。Azure の標準仮想マシンと比較すると、Spot 仮想マシンをより低い価格で使用することでコストを節約できます。spotVMOptions
を MachineSet
YAML ファイルに追加して、Spot 仮想マシンを設定 できます。
7.2.1.3. GCP 上のマシンセットのカスタムリソースのサンプル YAML
このサンプル YAML は、Google Cloud Platform (GCP) で実行され、node-role.kubernetes.io/infra: ""
というラベルが付けられたノードを作成するマシンセットを定義します。
このサンプルでは、infrastructure_id
はクラスターのプロビジョニング時に設定したクラスター ID に基づくインフラストラクチャー ID であり、<infra>
は追加するノードラベルです。
apiVersion: machine.openshift.io/v1beta1 kind: MachineSet metadata: labels: machine.openshift.io/cluster-api-cluster: <infrastructure_id> 1 name: <infrastructure_id>-w-a 2 namespace: openshift-machine-api spec: replicas: 1 selector: matchLabels: machine.openshift.io/cluster-api-cluster: <infrastructure_id> 3 machine.openshift.io/cluster-api-machineset: <infrastructure_id>-w-a 4 template: metadata: creationTimestamp: null labels: machine.openshift.io/cluster-api-cluster: <infrastructure_id> 5 machine.openshift.io/cluster-api-machine-role: <infra> 6 machine.openshift.io/cluster-api-machine-type: <infra> 7 machine.openshift.io/cluster-api-machineset: <infrastructure_id>-w-a 8 spec: metadata: labels: node-role.kubernetes.io/infra: "" 9 taints: 10 - key: node-role.kubernetes.io/infra effect: NoSchedule providerSpec: value: apiVersion: gcpprovider.openshift.io/v1beta1 canIPForward: false credentialsSecret: name: gcp-cloud-credentials deletionProtection: false disks: - autoDelete: true boot: true image: <path_to_image> 11 labels: null sizeGb: 128 type: pd-ssd gcpMetadata: 12 - key: <custom_metadata_key> value: <custom_metadata_value> kind: GCPMachineProviderSpec machineType: n1-standard-4 metadata: creationTimestamp: null networkInterfaces: - network: <infrastructure_id>-network 13 subnetwork: <infrastructure_id>-worker-subnet 14 projectID: <project_name> 15 region: us-central1 serviceAccounts: - email: <infrastructure_id>-w@<project_name>.iam.gserviceaccount.com 16 17 scopes: - https://www.googleapis.com/auth/cloud-platform tags: - <infrastructure_id>-worker 18 userDataSecret: name: worker-user-data zone: us-central1-a
- 1 2 3 4 5 8 13 14 16 18
- クラスターのプロビジョニング時に設定したクラスター ID を基にするインフラストラクチャー ID を指定します。OpenShift CLI がインストールされている場合は、以下のコマンドを実行してインフラストラクチャー ID を取得できます。
$ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster
- 6 7 9
<infra>
ノードラベルを指定します。- 10
- ユーザーのワークロードが infra ノードにスケジュールされないようにテイントを指定します。
- 11
- 現在のマシンセットで使用されるイメージへのパスを指定します。OpenShift CLI がインストールされている場合は、以下のコマンドを実行してイメージへのパスを取得できます。
$ oc -n openshift-machine-api \ -o jsonpath='{.spec.template.spec.providerSpec.value.disks[0].image}{"\n"}' \ get machineset/<infrastructure_id>-worker-a
- 12
- オプション:
key:value
のペアの形式でカスタムメタデータを指定します。ユースケースの例については、カスタムメタデータの設定 について GCP のドキュメントを参照してください。 - 15 17
- クラスターに使用する GCP プロジェクトの名前を指定します。
GCP で実行されるマシンセットは、保証されていない プリエンプション可能な仮想マシンインスタンス をサポートします。GCP の通常のインスタンスと比較して、プリエンプション可能な仮想マシンインスタンスをより低い価格で使用することでコストを節約できます。preemptible
を MachineSet
YAML ファイルに追加して、プリエンプション可能な仮想マシンインスタンスを設定 できます。
7.2.1.4. RHOSP 上のマシンセットのカスタムリソースのサンプル YAML
このサンプル YAML は、Red Hat OpenStack Platform (RHOSP) で実行され、node-role.kubernetes.io/infra: ""
というラベルが付けられたノードを作成するマシンセットを定義します。
このサンプルでは、infrastructure_id
はクラスターのプロビジョニング時に設定したクラスター ID に基づくインフラストラクチャー ID であり、<infra>
は追加するノードラベルです。
apiVersion: machine.openshift.io/v1beta1 kind: MachineSet metadata: labels: machine.openshift.io/cluster-api-cluster: <infrastructure_id> 1 machine.openshift.io/cluster-api-machine-role: <infra> 2 machine.openshift.io/cluster-api-machine-type: <infra> 3 name: <infrastructure_id>-infra 4 namespace: openshift-machine-api spec: replicas: <number_of_replicas> selector: matchLabels: machine.openshift.io/cluster-api-cluster: <infrastructure_id> 5 machine.openshift.io/cluster-api-machineset: <infrastructure_id>-infra 6 template: metadata: labels: machine.openshift.io/cluster-api-cluster: <infrastructure_id> 7 machine.openshift.io/cluster-api-machine-role: <infra> 8 machine.openshift.io/cluster-api-machine-type: <infra> 9 machine.openshift.io/cluster-api-machineset: <infrastructure_id>-infra 10 spec: metadata: creationTimestamp: null labels: node-role.kubernetes.io/infra: "" taints: 11 - key: node-role.kubernetes.io/infra effect: NoSchedule providerSpec: value: apiVersion: openstackproviderconfig.openshift.io/v1alpha1 cloudName: openstack cloudsSecret: name: openstack-cloud-credentials namespace: openshift-machine-api flavor: <nova_flavor> image: <glance_image_name_or_location> serverGroupID: <optional_UUID_of_server_group> 12 kind: OpenstackProviderSpec networks: 13 - filter: {} subnets: - filter: name: <subnet_name> tags: openshiftClusterID=<infrastructure_id> 14 primarySubnet: <rhosp_subnet_UUID> 15 securityGroups: - filter: {} name: <infrastructure_id>-worker 16 serverMetadata: Name: <infrastructure_id>-worker 17 openshiftClusterID: <infrastructure_id> 18 tags: - openshiftClusterID=<infrastructure_id> 19 trunk: true userDataSecret: name: worker-user-data 20 availabilityZone: <optional_openstack_availability_zone>
- 1 5 7 14 16 17 18 19
- クラスターのプロビジョニング時に設定したクラスター ID を基にするインフラストラクチャー ID を指定します。OpenShift CLI がインストールされている場合は、以下のコマンドを実行してインフラストラクチャー ID を取得できます。
$ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster
- 2 3 8 9 20
<infra>
ノードラベルを指定します。- 4 6 10
- インフラストラクチャー ID および
<infra>
ノードラベルを指定します。 - 11
- ユーザーのワークロードが infra ノードにスケジュールされないようにテイントを指定します。
- 12
- MachineSet のサーバーグループポリシーを設定するには、サーバーグループの作成 から返された値を入力します。ほとんどのデプロイメントでは、
anti-affinity
またはsoft-anti-affinity
が推奨されます。 - 13
- 複数ネットワークへのデプロイメントに必要です。複数ネットワークにデプロイする場合、この一覧には、
primarySubnet が
の値として使用されるネットワークが含まれる必要があります。 - 15
- ノードのエンドポイントを公開する RHOSP サブネットを指定します。通常、これは
install-config.yaml
ファイルのmachinesSubnet
の値として使用される同じサブネットです。
7.2.1.5. RHV 上のマシンセットのカスタムリソースのサンプル YAML
このサンプル YAML は、RHV で実行され、node-role.kubernetes.io/<node_role>: ""
というラベルが付けられたノードを作成するマシンセットを定義します。
このサンプルでは、<infrastructure_id>
はクラスターのプロビジョニング時に設定したクラスター ID に基づくインフラストラクチャー ID であり、<role>
は追加するノードラベルです。
apiVersion: machine.openshift.io/v1beta1 kind: MachineSet metadata: labels: machine.openshift.io/cluster-api-cluster: <infrastructure_id> 1 machine.openshift.io/cluster-api-machine-role: <role> 2 machine.openshift.io/cluster-api-machine-type: <role> 3 name: <infrastructure_id>-<role> 4 namespace: openshift-machine-api spec: replicas: <number_of_replicas> 5 selector: 6 matchLabels: machine.openshift.io/cluster-api-cluster: <infrastructure_id> 7 machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role> 8 template: metadata: labels: machine.openshift.io/cluster-api-cluster: <infrastructure_id> 9 machine.openshift.io/cluster-api-machine-role: <role> 10 machine.openshift.io/cluster-api-machine-type: <role> 11 machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role> 12 spec: metadata: labels: node-role.kubernetes.io/<role>: "" 13 providerSpec: value: apiVersion: ovirtproviderconfig.machine.openshift.io/v1beta1 cluster_id: <ovirt_cluster_id> 14 template_name: <ovirt_template_name> 15 instance_type_id: <instance_type_id> 16 cpu: 17 sockets: <number_of_sockets> 18 cores: <number_of_cores> 19 threads: <number_of_threads> 20 memory_mb: <memory_size> 21 os_disk: 22 size_gb: <disk_size> 23 network_interfaces: 24 vnic_profile_id: <vnic_profile_id> 25 credentialsSecret: name: ovirt-credentials 26 kind: OvirtMachineProviderSpec type: <workload_type> 27 userDataSecret: name: worker-user-data
- 1 7 9
- クラスターのプロビジョニング時に設定したクラスター ID を基にするインフラストラクチャー ID を指定します。OpenShift CLI (
oc
) がインストールされている場合は、以下のコマンドを実行してインフラストラクチャー ID を取得できます。$ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster
- 2 3 10 11 13
- 追加するノードラベルを指定します。
- 4 8 12
- インフラストラクチャー ID およびノードラベルを指定します。これら 2 つの文字列は 35 文字を超えることができません。
- 5
- 作成するマシンの数を指定します。
- 6
- マシンのセレクター。
- 14
- この仮想マシンインスタンスが属する RHV クラスターの UUID を指定します。
- 15
- マシンの作成に使用する RHV 仮想マシンテンプレートを指定します。
- 16
- オプション: 仮想マシンインスタンスタイプを指定します。警告
instance_type_id
フィールドは非推奨となり、今後のリリースで削除されます。このパラメーターを含めると、CPU およびメモリーを含む仮想マシンのハードウェアパラメーターを指定する必要はありません。このパラメーターは、すべてのハードウェアパラメーターを上書きするためです。
- 17
- オプション: CPU フィールドには、ソケット、コア、スレッドを含む CPU の設定が含まれます。
- 18
- オプション: 仮想マシンのソケット数を指定します。
- 19
- オプション: ソケットあたりのコア数を指定します。
- 20
- オプション: コアあたりのスレッド数を指定します。
- 21
- オプション: 仮想マシンのメモリーサイズを MiB 単位で指定します。
- 22
- オプション: ノードのルートディスク。
- 23
- オプション: ブート可能なディスクのサイズを GiB 単位で指定します。
- 24
- オプション: 仮想マシンのネットワークインターフェイスの一覧。このパラメーターを含めると、OpenShift Container Platform はテンプレートからすべてのネットワークインターフェイスを破棄し、新規ネットワークインターフェイスを作成します。
- 25
- オプション: vNIC プロファイル ID を指定します。
- 26
- RHV 認証情報を保持するシークレットの名前を指定します。
- 27
- オプション: インスタンスが最適化されるワークロードタイプを指定します。この値は
RHV VM
パラメーターに影響します。サポートされる値:desktop
、server
(デフォルト)、high_performance
です。high_performance
により、仮想マシンのパフォーマンスが向上しますが、制限があります。たとえば、グラフィカルコンソールを使用して仮想マシンにはアクセスできません。詳細は、仮想マシン管理ガイドの ハイパフォーマンス仮想マシン、テンプレート、およびプールの設定 を参照してください。
RHV は仮想マシンの作成時にテンプレートを使用するため、任意のパラメーターの値を指定しない場合、RHV はテンプレートに指定されるパラメーターの値を使用します。
7.2.1.6. vSphere 上のマシンセットのカスタムリソースのサンプル YAML
このサンプル YAML は、VMware vSphere で実行され、 node-role.kubernetes.io/infra: ""
というラベルが付けられたノードを作成するマシンセットを定義します。
このサンプルでは、infrastructure_id
はクラスターのプロビジョニング時に設定したクラスター ID に基づくインフラストラクチャー ID であり、<infra>
は追加するノードラベルです。
apiVersion: machine.openshift.io/v1beta1 kind: MachineSet metadata: creationTimestamp: null labels: machine.openshift.io/cluster-api-cluster: <infrastructure_id> 1 name: <infrastructure_id>-infra 2 namespace: openshift-machine-api spec: replicas: 1 selector: matchLabels: machine.openshift.io/cluster-api-cluster: <infrastructure_id> 3 machine.openshift.io/cluster-api-machineset: <infrastructure_id>-infra 4 template: metadata: creationTimestamp: null labels: machine.openshift.io/cluster-api-cluster: <infrastructure_id> 5 machine.openshift.io/cluster-api-machine-role: <infra> 6 machine.openshift.io/cluster-api-machine-type: <infra> 7 machine.openshift.io/cluster-api-machineset: <infrastructure_id>-infra 8 spec: metadata: creationTimestamp: null labels: node-role.kubernetes.io/infra: "" 9 taints: 10 - key: node-role.kubernetes.io/infra effect: NoSchedule providerSpec: value: apiVersion: vsphereprovider.openshift.io/v1beta1 credentialsSecret: name: vsphere-cloud-credentials diskGiB: 120 kind: VSphereMachineProviderSpec memoryMiB: 8192 metadata: creationTimestamp: null network: devices: - networkName: "<vm_network_name>" 11 numCPUs: 4 numCoresPerSocket: 1 snapshot: "" template: <vm_template_name> 12 userDataSecret: name: worker-user-data workspace: datacenter: <vcenter_datacenter_name> 13 datastore: <vcenter_datastore_name> 14 folder: <vcenter_vm_folder_path> 15 resourcepool: <vsphere_resource_pool> 16 server: <vcenter_server_ip> 17
- 1 3 5
- クラスターのプロビジョニング時に設定したクラスター ID を基にするインフラストラクチャー ID を指定します。OpenShift CLI (
oc
) がインストールされている場合は、以下のコマンドを実行してインフラストラクチャー ID を取得できます。$ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster
- 2 4 8
- インフラストラクチャー ID および
<infra>
ノードラベルを指定します。 - 6 7 9
<infra>
ノードラベルを指定します。- 10
- ユーザーのワークロードが infra ノードにスケジュールされないようにテイントを指定します。
- 11
- マシンセットをデプロイする vSphere 仮想マシンネットワークを指定します。この仮想マシンネットワークは、他のコンピューティングマシンがクラスター内に存在する場所である必要があります。
- 12
user-5ddjd-rhcos
などの使用する vSphere 仮想マシンテンプレートを指定します。- 13
- マシンセットをデプロイする vCenter Datacenter を指定します。
- 14
- マシンセットをデプロイする vCenter Datastore を指定します。
- 15
/dc1/vm/user-inst-5ddjd
などの vCenter の vSphere 仮想マシンフォルダーへのパスを指定します。- 16
- 仮想マシンの vSphere リソースプールを指定します。
- 17
- vCenter サーバーの IP または完全修飾ドメイン名を指定します。
7.2.2. マシンセットの作成
インストールプログラムによって作成されるものに加え、独自のマシンセットを作成して、選択する特定のワークロードに対するマシンのコンピュートリソースを動的に管理することができます。
前提条件
- OpenShift Container Platform クラスターをデプロイすること。
-
OpenShift CLI (
oc
) をインストールしている。 -
cluster-admin
パーミッションを持つユーザーとして、oc
にログインする。
手順
説明されているようにマシンセット カスタムリソース (CR) サンプルを含む新規 YAML ファイルを作成し、そのファイルに
<file_name>.yaml
という名前を付けます。<clusterID>
および<role>
パラメーターの値を設定していることを確認します。特定のフィールドに設定する値が不明な場合は、クラスターから既存のマシンセットを確認できます。
$ oc get machinesets -n openshift-machine-api
出力例
NAME DESIRED CURRENT READY AVAILABLE AGE agl030519-vplxk-worker-us-east-1a 1 1 1 1 55m agl030519-vplxk-worker-us-east-1b 1 1 1 1 55m agl030519-vplxk-worker-us-east-1c 1 1 1 1 55m agl030519-vplxk-worker-us-east-1d 0 0 55m agl030519-vplxk-worker-us-east-1e 0 0 55m agl030519-vplxk-worker-us-east-1f 0 0 55m
特定のマシンセットの値を確認します。
$ oc get machineset <machineset_name> -n \ openshift-machine-api -o yaml
出力例
... template: metadata: labels: machine.openshift.io/cluster-api-cluster: agl030519-vplxk 1 machine.openshift.io/cluster-api-machine-role: worker 2 machine.openshift.io/cluster-api-machine-type: worker machine.openshift.io/cluster-api-machineset: agl030519-vplxk-worker-us-east-1a
新規
MachineSet
CR を作成します。$ oc create -f <file_name>.yaml
マシンセットの一覧を表示します。
$ oc get machineset -n openshift-machine-api
出力例
NAME DESIRED CURRENT READY AVAILABLE AGE agl030519-vplxk-infra-us-east-1a 1 1 1 1 11m agl030519-vplxk-worker-us-east-1a 1 1 1 1 55m agl030519-vplxk-worker-us-east-1b 1 1 1 1 55m agl030519-vplxk-worker-us-east-1c 1 1 1 1 55m agl030519-vplxk-worker-us-east-1d 0 0 55m agl030519-vplxk-worker-us-east-1e 0 0 55m agl030519-vplxk-worker-us-east-1f 0 0 55m
新規のマシンセットが利用可能な場合、
DESIRED
およびCURRENT
の値は一致します。マシンセットが利用可能でない場合、数分待機してからコマンドを再度実行します。
7.2.3. 専用インフラストラクチャーノードの作成
インストーラーでプロビジョニングされるインフラストラクチャー環境またはコントロールプレーンノード (別名マスターノード) がマシン API によって管理されているクラスターについては、インフラストラクチャーマシンセットの作成を参照してください。
クラスターの要件により、インフラストラクチャー ( infra
ノードとも呼ばれる) がプロビジョニングされます。インストーラーは、コントロールプレーンノードとワーカーノードのプロビジョニングのみを提供します。ワーカーノードは、ラベル付けによって、インフラストラクチャーノードまたはアプリケーション (app
とも呼ばれる) として指定できます。
手順
アプリケーションノードとして機能させるワーカーノードにラベルを追加します。
$ oc label node <node-name> node-role.kubernetes.io/app=""
インフラストラクチャーノードとして機能する必要のあるワーカーノードにラベルを追加します。
$ oc label node <node-name> node-role.kubernetes.io/infra=""
該当するノードに
infra
ロールおよびapp
ロールがあるかどうかを確認します。$ oc get nodes
デフォルトのクラスタースコープのセレクターを作成するには、以下を実行します。デフォルトのノードセレクターはすべての namespace で作成された Pod に適用されます。これにより、Pod の既存のノードセレクターとの交差が作成され、Pod のセレクターをさらに制限します。
重要デフォルトのノードセレクターのキーが Pod のラベルのキーと競合する場合、デフォルトのノードセレクターは適用されません。
ただし、Pod がスケジュール対象外になる可能性のあるデフォルトノードセレクターを設定しないでください。たとえば、Pod のラベルが
node-role.kubernetes.io/master=""
などの別のノードロールに設定されている場合、デフォルトのノードセレクターをnode-role.kubernetes.io/infra=""
などの特定のノードロールに設定すると、Pod がスケジュール不能になる可能性があります。このため、デフォルトのノードセレクターを特定のノードロールに設定する際には注意が必要です。または、プロジェクトノードセレクターを使用して、クラスター全体でのノードセレクターの競合を避けることができます。
Scheduler
オブジェクトを編集します。$ oc edit scheduler cluster
適切なノードセレクターと共に
defaultNodeSelector
フィールドを追加します。apiVersion: config.openshift.io/v1 kind: Scheduler metadata: name: cluster ... spec: defaultNodeSelector: topology.kubernetes.io/region=us-east-1 1 ...
- 1
- このサンプルノードセレクターは、デフォルトで
us-east-1
リージョンのノードに Pod をデプロイします。
- 変更を適用するためにファイルを保存します。
これで、インフラストラクチャーリソースを新しくラベル付けされた infra
ノードに移動できます。
7.2.4. インフラストラクチャーマシンのマシン設定プール作成
インフラストラクチャーマシンに専用の設定が必要な場合は、infra プールを作成する必要があります。
手順
特定のラベルを持つ infra ノードとして割り当てるノードに、ラベルを追加します。
$ oc label node <node_name> <label>
$ oc label node ci-ln-n8mqwr2-f76d1-xscn2-worker-c-6fmtx node-role.kubernetes.io/infra=
ワーカーロールとカスタムロールの両方をマシン設定セレクターとして含まれるマシン設定プールを作成します。
$ cat infra.mcp.yaml
出力例
apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfigPool metadata: name: infra spec: machineConfigSelector: matchExpressions: - {key: machineconfiguration.openshift.io/role, operator: In, values: [worker,infra]} 1 nodeSelector: matchLabels: node-role.kubernetes.io/infra: "" 2
注記カスタムマシン設定プールは、ワーカープールからマシン設定を継承します。カスタムプールは、ワーカープールのターゲット設定を使用しますが、カスタムプールのみをターゲットに設定する変更をデプロイする機能を追加します。カスタムプールはワーカープールから設定を継承するため、ワーカープールへの変更もカスタムプールに適用されます。
YAML ファイルを用意した後に、マシン設定プールを作成できます。
$ oc create -f infra.mcp.yaml
マシン設定をチェックして、インフラストラクチャー設定が正常にレンダリングされていることを確認します。
$ oc get machineconfig
出力例
NAME GENERATEDBYCONTROLLER IGNITIONVERSION CREATED 00-master 365c1cfd14de5b0e3b85e0fc815b0060f36ab955 3.2.0 31d 00-worker 365c1cfd14de5b0e3b85e0fc815b0060f36ab955 3.2.0 31d 01-master-container-runtime 365c1cfd14de5b0e3b85e0fc815b0060f36ab955 3.2.0 31d 01-master-kubelet 365c1cfd14de5b0e3b85e0fc815b0060f36ab955 3.2.0 31d 01-worker-container-runtime 365c1cfd14de5b0e3b85e0fc815b0060f36ab955 3.2.0 31d 01-worker-kubelet 365c1cfd14de5b0e3b85e0fc815b0060f36ab955 3.2.0 31d 99-master-1ae2a1e0-a115-11e9-8f14-005056899d54-registries 365c1cfd14de5b0e3b85e0fc815b0060f36ab955 3.2.0 31d 99-master-ssh 3.2.0 31d 99-worker-1ae64748-a115-11e9-8f14-005056899d54-registries 365c1cfd14de5b0e3b85e0fc815b0060f36ab955 3.2.0 31d 99-worker-ssh 3.2.0 31d rendered-infra-4e48906dca84ee702959c71a53ee80e7 365c1cfd14de5b0e3b85e0fc815b0060f36ab955 3.2.0 23m rendered-master-072d4b2da7f88162636902b074e9e28e 5b6fb8349a29735e48446d435962dec4547d3090 3.2.0 31d rendered-master-3e88ec72aed3886dec061df60d16d1af 02c07496ba0417b3e12b78fb32baf6293d314f79 3.2.0 31d rendered-master-419bee7de96134963a15fdf9dd473b25 365c1cfd14de5b0e3b85e0fc815b0060f36ab955 3.2.0 17d rendered-master-53f5c91c7661708adce18739cc0f40fb 365c1cfd14de5b0e3b85e0fc815b0060f36ab955 3.2.0 13d rendered-master-a6a357ec18e5bce7f5ac426fc7c5ffcd 365c1cfd14de5b0e3b85e0fc815b0060f36ab955 3.2.0 7d3h rendered-master-dc7f874ec77fc4b969674204332da037 5b6fb8349a29735e48446d435962dec4547d3090 3.2.0 31d rendered-worker-1a75960c52ad18ff5dfa6674eb7e533d 5b6fb8349a29735e48446d435962dec4547d3090 3.2.0 31d rendered-worker-2640531be11ba43c61d72e82dc634ce6 5b6fb8349a29735e48446d435962dec4547d3090 3.2.0 31d rendered-worker-4e48906dca84ee702959c71a53ee80e7 365c1cfd14de5b0e3b85e0fc815b0060f36ab955 3.2.0 7d3h rendered-worker-4f110718fe88e5f349987854a1147755 365c1cfd14de5b0e3b85e0fc815b0060f36ab955 3.2.0 17d rendered-worker-afc758e194d6188677eb837842d3b379 02c07496ba0417b3e12b78fb32baf6293d314f79 3.2.0 31d rendered-worker-daa08cc1e8f5fcdeba24de60cd955cc3 365c1cfd14de5b0e3b85e0fc815b0060f36ab955 3.2.0 13d
新規のマシン設定には、接頭辞
rendered-infra-*
が表示されるはずです。オプション: カスタムプールへの変更をデプロイするには、
infra
などのラベルとしてカスタムプール名を使用するマシン設定を作成します。これは必須ではありませんが、説明の目的でのみ表示されていることに注意してください。これにより、インフラストラクチャーノードのみに固有のカスタム設定を適用できます。注記新規マシン設定プールの作成後に、MCO はそのプールに新たにレンダリングされた設定を生成し、そのプールに関連付けられたノードは再起動して、新規設定を適用します。
マシン設定を作成します。
$ cat infra.mc.yaml
出力例
apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: name: 51-infra labels: machineconfiguration.openshift.io/role: infra 1 spec: config: ignition: version: 3.2.0 storage: files: - path: /etc/infratest mode: 0644 contents: source: data:,infra
- 1
- ノードに追加したラベルを
nodeSelector
として追加します。
マシン設定を infra のラベルが付いたノードに適用します。
$ oc create -f infra.mc.yaml
新規のマシン設定プールが利用可能であることを確認します。
$ oc get mcp
出力例
NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE infra rendered-infra-60e35c2e99f42d976e084fa94da4d0fc True False False 1 1 1 0 4m20s master rendered-master-9360fdb895d4c131c7c4bebbae099c90 True False False 3 3 3 0 91m worker rendered-worker-60e35c2e99f42d976e084fa94da4d0fc True False False 2 2 2 0 91m
この例では、ワーカーノードが infra ノードに変更されました。
関連情報
- カスタムプールでインフラマシンをグループ化する方法に関する詳細は、Node configuration management with machine config pools を参照してください。