3.6. プライベートクラスターの設定


OpenShift Container Platform バージョン 4.3 クラスターのインストール後に、そのコアコンポーネントの一部を private に設定できます。

重要

この変更は、クラウドプロバイダーにプロビジョニングするインフラストラクチャーを使用するクラスターにのみ設定できます。

3.6.1. プライベートクラスター

デフォルトで、OpenShift Container Platform は一般にアクセス可能な DNS およびエンドポイントを使用してプロビジョニングされます。クラスターのデプロイ後に DNS、Ingress コントローラー、および API サーバーを private に設定できます。

DNS

OpenShift Container Platform をインストーラーでプロビジョニングされるインフラストラクチャーにインストールする場合、インストールプログラムは既存のパブリックゾーンにレコードを作成し、可能な場合はクラスター独自の DNS 解決用のプライベートゾーンを作成します。パブリックゾーンおよびプライベートゾーンの両方で、インストールプログラムまたはクラスターが Ingress の *.apps、および API サーバーの api の DNS エントリーを作成します。

*.apps レコードはパブリックゾーンとプライベートゾーンのどちらでも同じであるため、パブリックゾーンを削除する際に、プライベートゾーンではクラスターのすべての DNS 解決をシームレスに提供します。

Ingress コントローラー

デフォルトの Ingress オブジェクトはパブリックとして作成されるため、ロードバランサーはインターネットに接続され、パブリックサブネットで使用されます。デフォルト Ingress コントローラーは内部コントローラーに置き換えることができます。

API サーバー

デフォルトでは、インストールプログラムは内部トラフィックと外部トラフィックの両方で使用するための API サーバーの適切なネットワークロードバランサーを作成します。

Amazon Web Services (AWS) では、個別のパブリックロードバランサーおよびプライベートロードバランサーが作成されます。ロードバランサーは、クラスター内で使用するために追加ポートが内部で利用可能な場合を除き、常に同一です。インストールプログラムは API サーバー要件に基づいてロードバランサーを自動的に作成または破棄しますが、クラスターはそれらを管理または維持しません。クラスターの API サーバーへのアクセスを保持する限り、ロードバランサーを手動で変更または移動できます。パブリックロードバランサーの場合、ポート 6443 は開放され、ヘルスチェックが HTTPS について /readyz パスに対して設定されます。

Google Cloud Platform では、内部および外部 API トラフィックの両方を管理するために単一のロードバランサーが作成されるため、ロードバランサーを変更する必要はありません。

Microsoft Azure では、パブリックおよびプライベートロードバランサーの両方が作成されます。ただし、現在の実装には制限があるため、プライベートクラスターで両方のロードバランサーを保持します。

3.6.2. DNS をプライベートに設定する

クラスターのデプロイ後に、プライベートゾーンのみを使用するように DNS を変更できます。

手順

  1. クラスターの DNS カスタムリソースを確認します。

    $ oc get dnses.config.openshift.io/cluster -o yaml
    apiVersion: config.openshift.io/v1
    kind: DNS
    metadata:
      creationTimestamp: "2019-10-25T18:27:09Z"
      generation: 2
      name: cluster
      resourceVersion: "37966"
      selfLink: /apis/config.openshift.io/v1/dnses/cluster
      uid: 0e714746-f755-11f9-9cb1-02ff55d8f976
    spec:
      baseDomain: <base_domain>
      privateZone:
        tags:
          Name: <infrastructureID>-int
          kubernetes.io/cluster/<infrastructureID>: owned
      publicZone:
        id: Z2XXXXXXXXXXA4
    status: {}

    spec セクションには、プライベートゾーンとパブリックゾーンの両方が含まれることに注意してください。

  2. DNS カスタムリソースにパッチを適用して、パブリックゾーンを削除します。

    $ oc patch dnses.config.openshift.io/cluster --type=merge --patch='{"spec": {"publicZone": null}}'
    dns.config.openshift.io/cluster patched

    Ingress コントローラーは Ingress オブジェクトの作成時に DNS 定義を参照するため、Ingress オブジェクトを作成または変更する場合、プライベートレコードのみが作成されます。

    重要

    既存の Ingress オブジェクトの DNS レコードは、パブリックゾーンの削除時に変更されません。

  3. オプション: クラスターの DNS カスタムリソースを確認し、パブリックゾーンが削除されていることを確認します。

    $ oc get dnses.config.openshift.io/cluster -o yaml
    apiVersion: config.openshift.io/v1
    kind: DNS
    metadata:
      creationTimestamp: "2019-10-25T18:27:09Z"
      generation: 2
      name: cluster
      resourceVersion: "37966"
      selfLink: /apis/config.openshift.io/v1/dnses/cluster
      uid: 0e714746-f755-11f9-9cb1-02ff55d8f976
    spec:
      baseDomain: <base_domain>
      privateZone:
        tags:
          Name: <infrastructureID>-int
          kubernetes.io/cluster/<infrastructureID>-wfpg4: owned
    status: {}

3.6.3. Ingress コントローラーをプライベートに設定する

クラスターのデプロイ後に、その Ingress コントローラーをプライベートゾーンのみを使用するように変更できます。

手順

  1. 内部エンドポイントのみを使用するようにデフォルト Ingress コントローラーを変更します。

    $ oc replace --force --wait --filename - <<EOF
    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      namespace: openshift-ingress-operator
      name: default
    spec:
      endpointPublishingStrategy:
        type: LoadBalancerService
        loadBalancer:
          scope: Internal
    EOF
    ingresscontroller.operator.openshift.io "default" deleted
    ingresscontroller.operator.openshift.io/default replaced

    パブリック DNS エントリーが削除され、プライベートゾーンエントリーが更新されます。

3.6.4. API サーバーをプライベートに制限する

クラスターを Amazon Web Services (AWS) または Microsoft Azure にデプロイした後に、プライベートゾーンのみを使用するように API サーバーを再設定することができます。

前提条件

  • OpenShift CLI (oc) のインストール。
  • admin 権限を持つユーザーとして Web コンソールにアクセスできること。

手順

  1. AWS または Azure の Web ポータルまたはコンソールで、以下のアクションを実行します。

    1. 適切なロードバランサーコンポーネントを見つけ、削除します。

      • AWS の場合は、外部ロードバランサーを削除します。プライベートゾーンの API DNS エントリーは、同一の設定を使用する内部ロードバランサーをすでに参照するため、内部ロードバランサーを変更する必要はありません。
      • Azure の場合、ロードバランサーの api-internal ルールを削除します。
    2. パブリックゾーンの api.$clustername.$yourdomain DNS エントリーを削除します。
  2. ターミナルで、クラスターマシンを一覧表示します。

    $ oc get machine -n openshift-machine-api
    NAME                            STATE     TYPE        REGION      ZONE         AGE
    lk4pj-master-0                  running   m4.xlarge   us-east-1   us-east-1a   17m
    lk4pj-master-1                  running   m4.xlarge   us-east-1   us-east-1b   17m
    lk4pj-master-2                  running   m4.xlarge   us-east-1   us-east-1a   17m
    lk4pj-worker-us-east-1a-5fzfj   running   m4.xlarge   us-east-1   us-east-1a   15m
    lk4pj-worker-us-east-1a-vbghs   running   m4.xlarge   us-east-1   us-east-1a   15m
    lk4pj-worker-us-east-1b-zgpzg   running   m4.xlarge   us-east-1   us-east-1b   15m

    以下の手順で、名前に master が含まれるコントロールプレーンマシンを変更します。

  3. 各コントロールプレーンマシンから外部ロードバランサーを削除します。

    1. master Machine オブジェクトを編集し、外部ロードバランサーへの参照を削除します。

      $ oc edit machines -n openshift-machine-api <master_name> 1
      1
      変更するコントロールプレーン、またはマスター、マシンの名前を指定します。
    2. 以下の例でマークが付けられている外部ロードバランサーを記述する行を削除し、オブジェクト仕様を保存し、終了します。

      ...
      spec:
        providerSpec:
          value:
          ...
            loadBalancers:
            - name: lk4pj-ext 1
              type: network 2
            - name: lk4pj-int
              type: network
      1 2
      この行を削除します。
    3. 名前に master が含まれるマシンにこのプロセスを繰り返します。
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.