Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

設定

Red Hat build of MicroShift 4.14

MicroShift の設定

Red Hat OpenShift Documentation Team

概要

このドキュメントでは、MicroShift を設定する手順を説明します。

第1章 設定ツールの仕組み
リンクのコピー

YAML ファイルは、優先設定、設定、およびパラメーターを使用して MicroShift インスタンスをカスタマイズします。

注記

kustomize マニフェスト以外のツールを使用し、MicroShift API を介して設定を変更したり、アプリケーションをデプロイしたりする場合は、greenboot ヘルスチェックが完了するまで待つ必要があります。これにより、greenboot が rpm-ostree システムを以前の状態にロールバックしても、変更が失われなくなります。

1.1. デフォルトの設定
リンクのコピー

config.yaml ファイルを作成しない場合は、デフォルト値が使用されます。次の例は、デフォルトの設定を示しています。

  • デフォルト値を確認するには、次のコマンドを実行します。 

    $ microshift show-config
    Copy to Clipboard Toggle word wrap

    YAML 形式でのデフォルト値の出力例

    dns:
  baseDomain: microshift.example.com
    1 
    
network:
  clusterNetwork:
    - 10.42.0.0/16
    2 
    
  serviceNetwork:
    - 10.43.0.0/16
    3 
    
  serviceNodePortRange: 30000-32767
    4 
    
node:
  hostnameOverride: ""
    5 
    
  nodeIP: ""
    6 
    
apiServer:
  advertiseAddress: 10.44.0.0/32
    7 
    
  subjectAltNames: []
    8 
    
debugging:
  logLevel: "Normal"
    9
    Copy to Clipboard Toggle word wrap

    1
    クラスターのベースドメイン。すべての管理対象 DNS レコードは、このベースのサブドメインになります。
    2
    Pod IP アドレスの割り当てに使用する IP アドレスのブロック。
    3
    Kubernetes サービスの仮想 IP アドレスのブロック。
    4
    タイプ NodePort の Kubernetes サービスに許可されるポート範囲。
    5
    ノードの名前。デフォルト値はホスト名です。
    6
    ノードの IP アドレス。デフォルト値は、デフォルトルートの IP アドレスです。
    7
    API サーバーがクラスターのメンバーにアドバタイズされる IP アドレスを指定する文字列。デフォルト値は、サービスネットワークのアドレスに基づいて計算されます。
    8
    API サーバー証明書のサブジェクト代替名。
    9
    ログの詳細レベル。このフィールドの有効な値は、Normal、Debug、Trace、または TraceAll です。

1.2. YAML 設定ファイルの使用
リンクのコピー

MicroShift は、起動時にシステム全体の /etc/microshift/ ディレクトリーで config.yaml という名前の設定ファイルを検索します。カスタム設定を使用するには、MicroShift を起動する前に、設定ファイルを作成し、デフォルトをオーバーライドするための設定を指定する必要があります。

1.2.1. カスタム設定
リンクのコピー

カスタム設定を作成するには、MicroShift を起動または再起動する前に、/etc/microshift/ ディレクトリーに config.yaml ファイルを作成し、デフォルトをオーバーライドするための設定を変更する必要があります。

重要

設定を変更したら、MicroShift を再起動して有効にします。config.yaml は MicroShift 起動時の読み取り専用ファイルです。

1.2.2. アドバタイズアドレスネットワークフラグの設定
リンクのコピー

apiserver.advertiseAddress フラグは、API サーバーをクラスターのメンバーにアドバタイズする IP アドレスを指定します。このアドレスは、クラスターから到達可能である必要があります。ここでカスタム IP アドレスを設定できますが、その IP アドレスをホストインターフェイスに追加する必要もあります。このパラメーターをカスタマイズすると、MicroShift がデフォルトの IP アドレスを br-ex ネットワークインターフェイスに追加しなくなります。

重要

advertiseAddress IP アドレスをカスタマイズする場合は、ホストインターフェイスに IP アドレスを追加して、MicroShift の起動時にクラスターからその IP アドレスに到達できることを確認してください。

設定されていない場合、デフォルト値はサービスネットワークのすぐ後のサブネットに設定されます。たとえば、サービスネットワークが 10.43.0.0/16 の場合、advertiseAddress は、10.44.0.0/32 に設定されます。

1.2.3. NodePort サービスのポート範囲の拡張
リンクのコピー

serviceNodePortRange 設定では、NodePort サービスで使用できるポート範囲が拡張します。このオプションは、30000-32767 範囲内で特定の標準ポートを公開する必要がある場合に役立ちます。たとえば、クライアントデバイスは別のポートを使用できないため、デバイスはネットワーク上で 1883/tcp MQ Telemetry Transport (MQTT) ポートを公開する必要があります。

重要

NodePort がシステムポートと重複し、システムまたは MicroShift の誤動作を引き起こす可能性があります。

NodePort サービス範囲を設定するときは、次の点を考慮してください。

  • nodePort を明示的に選択せずに NodePort サービスを作成しないでください。明示的な nodePort が指定されていない場合、このポートは kube-apiserver によってランダムに割り当てられるため、予測できません。
  • デバイスの HostNetwork で公開するシステムサービスポート、MicroShift ポート、またはその他のサービスに対して NodePort サービスを作成しないでください。

  • 表 1 は、ポート範囲の拡張時に避けるべきポートを示しています。

    Expand
    表1.1 回避するポート
    ポート説明

    22/tcp

    SSH ポート

    80/tcp

    OpenShift Router HTTP エンドポイント

    443/tcp

    OpenShift Router HTTPS エンドポイント

    1936/tcp

    現在公開されていない openshift-router のメトリクスサービス

    2379/tcp

    etcd ポート

    2380/tcp

    etcd ポート

    6443

    kubernetes API

    8445/tcp

    openshift-route-controller-manager

    9537/tcp

    cri-o metrics

    10250/tcp

    kubelet

    10248/tcp

    kubelet healthz ポート

    10259/tcp

    kube スケジューラー

第2章 kubeconfig を使用したクラスターアクセス
リンクのコピー

MicroShift デプロイメントで kubeconfig ファイルがどのように使用されるかを説明します。CLI ツールは、kubeconfig ファイルを使用してクラスターの API サーバーと通信します。これらのファイルには、クラスターの詳細、IP アドレス、および認証に必要なその他の情報が含まれています。

2.1. クラスターアクセスを設定するための Kubeconfig ファイル
リンクのコピー

MicroShift で使用される kubeconfig ファイルの 2 つのカテゴリーは、ローカルアクセスとリモートアクセスです。MicroShift が起動するたびに、API サーバーへのローカルおよびリモートアクセスのための kubeconfig ファイルのセットが生成されます。これらのファイルは、既存の設定情報を使用して /var/lib/microshift/resources/kubeadmin/ ディレクトリーに生成されます。

各アクセスタイプには、異なる認証局 (CA) によって署名された異なる認証証明書が必要です。複数の kubeconfig ファイルを生成することで、このニーズに対応できます。

それぞれの場合に必要なアクセスタイプに適切な kubeconfig ファイルを使用して、認証の詳細を提供できます。MicroShift kubeconfig ファイルの内容は、デフォルトの組み込み値または config.yaml ファイルによって決まります。

注記

クラスターにアクセスするには、kubeconfig ファイルが存在する必要があります。値は、組み込みのデフォルト値、または config.yaml (作成されている場合) から適用されます。

kubeconfig ファイルの内容の例

/var/lib/microshift/resources/kubeadmin/
├── kubeconfig
1 

├── alt-name-1
2 

│   └── kubeconfig
├── 1.2.3.4
3 

│   └── kubeconfig
└── microshift-rhel9
4 

    └── kubeconfig
Copy to Clipboard Toggle word wrap

1
ローカルホスト名。ホストのメイン IP アドレスは常にデフォルトです。
2
API サーバー証明書のサブジェクト代替名。
3
DNS 名。
4
MicroShift のホスト名。

2.2. ローカルアクセスの kubeconfig ファイル
リンクのコピー

ローカルアクセスの kubeconfig ファイルは /var/lib/microshift/resources/kubeadmin/kubeconfig に書き込まれます。この kubeconfig ファイルは、localhost を使用した API サーバーへのアクセスを提供します。クラスターをローカルに接続する場合は、このファイルを選択します。

ローカルアクセス用の kubeconfig の内容例

clusters:
- cluster:
    certificate-authority-data: <base64 CA>
    server: https://localhost:6443
Copy to Clipboard Toggle word wrap

localhost の kubeconfig ファイルは、同じホストから API サーバーに接続するクライアントからのみ使用できます。ファイル内の証明書はリモート接続では機能しません。

2.2.1. MicroShift クラスターへのローカルアクセス
リンクのコピー

以下の手順に従って、kubeconfig ファイルを使用して MicroShift クラスターをローカルでアクセスします。

前提条件

  • oc バイナリーがインストールされている。

手順

  1. オプション: RHEL マシンに ~/.kube/ フォルダーがない場合に作成するには、次のコマンドを実行します。 

    $ mkdir -p ~/.kube/
    Copy to Clipboard Toggle word wrap

  2. 次のコマンドを実行して、生成されたローカルアクセス kubeconfig ファイルを ~/.kube/ ディレクトリーにコピーします。 

    $ sudo cat /var/lib/microshift/resources/kubeadmin/kubeconfig > ~/.kube/config
    Copy to Clipboard Toggle word wrap

  3. 次のコマンドを実行して、~/.kube/config ファイルの権限を更新します。 

    $ chmod go-r ~/.kube/config
    Copy to Clipboard Toggle word wrap

検証

  • 次のコマンドを入力して、MicroShift が実行されていることを確認します。 

    $ oc get all -A
    Copy to Clipboard Toggle word wrap

2.3. リモートアクセスの kubeconfig ファイル
リンクのコピー

MicroShift クラスターが外部ソースから API サーバーに接続する場合は、SAN フィールド内のすべての代替名を持つ証明書が検証に使用されます。MicroShift は、hostname 値を使用して外部アクセス用のデフォルトの kubeconfig を生成します。デフォルトは、デフォルトの kubeconfig ファイルの <node.hostnameOverride>、<node.nodeIP>、および api.<dns.baseDomain> パラメーター値に設定されます。

/var/lib/microshift/resources/kubeadmin/<hostname>/kubeconfig ファイルは、マシンの hostname、またはオプションが設定されている場合は node.hostnameOverride を使用して、API サーバーにアクセスします。kubeconfig ファイルの CA は、外部からアクセスされたときに証明書を検証できます。

リモートアクセス用の kubeconfig デフォルトファイルの内容例

clusters:
- cluster:
    certificate-authority-data: <base64 CA>
    server: https://microshift-rhel9:6443
Copy to Clipboard Toggle word wrap

2.3.1. リモートアクセスのカスタマイズ
リンクのコピー

異なる IP アドレスまたはホスト名でクラスターにアクセスするために、複数のリモートアクセス kubeconfig ファイル値を生成できます。apiServer.subjectAltNames パラメーターのエントリーごとに追加の kubeconfig ファイルが生成されます。IP 接続中にホストからリモートアクセス kubeconfig ファイルをコピーし、それを使用して他のワークステーションから API サーバーにアクセスできます。

2.4. リモートアクセス用の追加の kubeconfig ファイルの生成
リンクのコピー

デフォルトのリモートアクセスファイルが提供するものより多くのホスト名または IP アドレスが必要な場合は、追加の kubeconfig ファイルを生成して使用できます。

重要

設定の変更を実装するには、MicroShift を再起動する必要があります。

前提条件

  • MicroShift の config.yaml が作成されている。

手順

  1. オプション: config.yaml の内容を表示できます。以下のコマンドを実行します。 

    $ cat /etc/microshift/config.yaml
    Copy to Clipboard Toggle word wrap

  2. オプション: リモートアクセス kubeconfig ファイルの内容を表示できます。以下のコマンドを実行します。 

    $ cat /var/lib/microshift/resources/kubeadmin/<hostname>/kubeconfig
    Copy to Clipboard Toggle word wrap
    重要

    追加のリモートアクセス kubeconfig ファイルには、Red Hat build of MicroShift config.yaml ファイルにリストされているサーバー名のいずれかを含める必要があります。追加の kubeconfig ファイルも検証に同じ CA を使用する必要があります。

  3. 追加の DNS 名、SAN、または外部 IP アドレス用に追加の kubeconfig ファイルを生成するには、必要なエントリーを apiServer.subjectAltNames フィールドに追加します。次の例では、使用される DNS 名は alt-name-1、IP アドレスは 1.2.3.4 です。

    追加の認証値を含む config.yaml の例

    dns:
  baseDomain: example.com
node:
  hostnameOverride: "microshift-rhel9"
    1 
    
  nodeIP: 10.0.0.1
apiServer:
  subjectAltNames:
  - alt-name-1
    2 
    
  - 1.2.3.4
    3
    Copy to Clipboard Toggle word wrap

    1
    ホスト名
    2
    DNS name
    3
    IP アドレスまたは範囲

  4. MicroShift を再起動して設定の変更を適用し、次のコマンドを実行して必要な kubeconfig ファイルを自動生成します。 

    $ sudo systemctl restart microshift
    Copy to Clipboard Toggle word wrap

  5. 追加のリモートアクセス kubeconfig ファイルの内容を確認するには、config.yaml にリストされている名前または IP アドレスを cat コマンドに挿入します。たとえば、次のコマンド例では alt-name-1 が使用されています。 

    $ cat /var/lib/microshift/resources/kubeadmin/alt-name-1/kubeconfig
    Copy to Clipboard Toggle word wrap

  6. クラスターの接続に使用する SAN または IP アドレスを含む、使用する kubeconfig ファイルを選択します。この例では、cluster.server フィールドに `alt-name-1` を含む kubeconfig が正しいファイルです。

    追加の kubeconfig ファイルの内容の例

    clusters:
- cluster:
    certificate-authority-data: <base64 CA>
    server: https://alt-name-1:6443
    1
    Copy to Clipboard Toggle word wrap

    1
    /var/lib/microshift/resources/kubeadmin/alt-name-1/kubeconfig ファイルの値は、apiServer.subjectAltNames 設定値からのものです。
注記

これらのパラメーターはすべて、API サーバーの外部提供証明書に共通名 (CN) およびサブジェクト代替名 (SAN) として含まれています。

2.4.1. MicroShift クラスターへのリモートアクセス用にファイアウォールを開く
リンクのコピー

リモートユーザーが MicroShift クラスターにアクセスできるように、次の手順を使用してファイアウォールを開きます。この手順は、ワークステーションユーザーがリモートでクラスターにアクセスする前に完了する必要があります。

この手順では、user@microshift は、MicroShift ホストマシン上のユーザーであり、別のワークステーション上のリモートユーザーがアクセスできるようにそのマシンをセットアップする責任があります。

前提条件

  • oc バイナリーがインストールされている。
  • クラスター管理者の権限がある。

手順

  • MicroShift ホストの user@microshift として、次のコマンドを実行して、Kubernetes API サーバー (6443/tcp) のファイアウォールポートを開きます。 

    [user@microshift]$ sudo firewall-cmd --permanent --zone=public --add-port=6443/tcp && sudo firewall-cmd --reload
    Copy to Clipboard Toggle word wrap

検証

  • user@microshift として次のコマンドを実行して、MicroShift が入力されていることを確認します。 

    [user@microshift]$ oc get all -A
    Copy to Clipboard Toggle word wrap

2.4.2. MicroShift クラスターへのリモートアクセス
リンクのコピー

以下の手順に従って、kubeconfig ファイルを使用してリモートワークステーションから MicroShift クラスターにアクセスします。

user@workstation ログインは、ホストマシンにリモートからアクセスするのに使用されます。手順の <user> 値は、user@workstation が MicroShift ホストにログインするユーザーの名前になります。

前提条件

  • oc バイナリーがインストールされている。
  • @user@microshift は、ローカルホストからファイアウォールを開いている。

手順

  1. RHEL マシンに ~/.kube/ フォルダーがない場合は、user@workstation として、次のコマンドを実行してフォルダーを作成します。 

    [user@workstation]$ mkdir -p ~/.kube/
    Copy to Clipboard Toggle word wrap

  2. user@workstation として、次のコマンドを実行して、MicroShift ホストのホスト名の変数を設定します。 

    [user@workstation]$ MICROSHIFT_MACHINE=<name or IP address of MicroShift machine>
    Copy to Clipboard Toggle word wrap

  3. user@workstation として、次のコマンドを実行して、MicroShift を実行している RHEL マシンからローカルマシンに接続するホスト名または IP アドレスを含む生成された kubeconfig ファイルをコピーします。 

    [user@workstation]$ ssh <user>@$MICROSHIFT_MACHINE "sudo cat /var/lib/microshift/resources/kubeadmin/$MICROSHIFT_MACHINE/kubeconfig" > ~/.kube/config
    Copy to Clipboard Toggle word wrap
注記

この手順で kubeconfig ファイルを生成するには、関連資料のセクションの「リモートアクセス用に追加の kubeconfig ファイルの生成」を参照してください。

  1. user@workstation として、次のコマンドを実行して ~/.kube/config ファイルのパーミッションを更新します。 

    $ chmod go-r ~/.kube/config
    Copy to Clipboard Toggle word wrap

検証

  • user@workstation として、次のコマンドを入力して、MicroShift が実行されていることを確認します。 

    [user@workstation]$ oc get all -A
    Copy to Clipboard Toggle word wrap

第3章 greenboot スクリプトのステータスの確認
リンクのコピー

kustomize マニフェスト以外のツールを使用して MicroShift API を通じてアプリケーションをデプロイしたり、その他の変更を加えたりするには、greenboot ヘルスチェックが完了するまで待つ必要があります。これにより、greenboot が rpm-ostree システムを以前の状態にロールバックしても、変更が失われなくなります。

greenboot-healthcheck サービスは 1 回実行してから終了します。greenboot が終了し、システムが正常な状態になったら、設定の変更とデプロイメントを続行できます。

3.1. greenboot ヘルスチェックのステータスの確認
リンクのコピー

システムに変更を加える前、またはトラブルシューティング中に、greenboot ヘルスチェックのステータスを確認します。次のコマンドのいずれかを使用すると、greenboot スクリプトの実行が完了したことを確認できます。

手順

  • ヘルスチェックステータスのレポートを表示するには、次のコマンドを使用します。 

    $ systemctl show --property=SubState --value greenboot-healthcheck.service
    Copy to Clipboard Toggle word wrap
    • start が出力される場合、greenboot チェックがまだ実行中であることを意味します。
    • exited が出力される場合、チェックが合格し、greenboot が終了したことを意味します。Greenboot は、システムが正常な状態の場合、green.d ディレクトリー内のスクリプトを実行します。
    • failed の出力は、チェックが合格しなかったことを意味します。システムがこの状態にある場合、Greenboot は red.d ディレクトリー内のスクリプトを実行し、システムを再起動する可能性があります。

  • サービスの数値終了コードを示すレポートを表示するには、次のコマンドを使用します。0 は成功を、0 以外の値は失敗を意味します。 

    $ systemctl show --property=ExecMainStatus --value greenboot-healthcheck.service
    Copy to Clipboard Toggle word wrap

  • Boot Status is GREEN - Health Check SUCCESS など、ブートステータスに関するメッセージを表示するレポートを表示するには、次のコマンドを使用します。 

    $ cat /run/motd.d/boot-status
    Copy to Clipboard Toggle word wrap

法律上の通知
リンクのコピー

Copyright © 2025 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2026 Red Hat