Satellite ホスト用の HTTP プロキシーの構成
Satellite ホストからのすべてのアウトバウンド・トラフィックがプロキシーを経由するように HTTP プロキシーを構成できます。
HTTP プロキシーのセットアップは、許可リストに登録されているアカウントでのみ使用できます。
HTTP プロキシーを使用するには、どのタイプのロケーションを使用する必要がありますか?
以下のタイプのロケーションを考慮してください。
- 既存の RHEL ベースのロケーション
- プロキシーをセットアップするには、ロケーションで Red Hat CoreOS (RHCOS) が有効になっている必要があります。 既存のロケーションが RHCOS 対応でない場合は、HTTP プロキシーを構成できません。 RHCOS 対応のロケーションを作成してから、HTTP プロキシーの構成を作成します。
- ホストが接続されている既存の Red Hat CoreOS 対応ロケーション
- HTTP プロキシーをセットアップするには、まず、ロケーションからホストの削除を行う必要があります。 ホストを削除した後、HTTP プロキシーの構成を参照してください。 ロケーション・コントロール・プレーンを構成するホストも更新する必要があることに注意してください。 Satellite ロケーション・コントロール・プレーン・ホストの更新を参照してください。
- 新しい Red Hat CoreOS 対応ロケーション
- ホストをロケーションに接続する前に、 HTTP プロキシーを構成します。
どのタイプのホストを使用できますか?
HTTP プロキシーをセットアップするときに、RHEL または Red Hat CoreOS ホストを使用できます。 コントロール・プレーンを構成するホストを含め、ロケーションに接続されている各ホストを編集する必要があります。 proxy.conf
ファイルに http
または https
を含めることを忘れないでください。
HTTP プロキシーについて他に知っておく必要があることは何ですか?
Satellite ロケーションおよびクラスターがプロキシーと連動するには、 Satellite ロケーションにデプロイされたコントロール・プレーン・インフラストラクチャー・ノード上の kubelet が、 IBM Cloud コントロール・プレーン・ノード API サーバーと通信できる必要があります。 この通信を有効にするには、以下のいずれかの要件を満たす必要があります。
-
オプション 1: 削減されたファイアウォール接続スクリプトを使用します。
-
オプション 2: 現行プロキシーは、長時間存続する TCP 接続 (TCP トンネリング) をサポートできます。
-
オプション 3: 長期 TCP 接続をサポートする Satellite ホストと同じネットワーク内の VSI に 2 次プロキシーを作成できます。
-
オプション 4: TCP 接続を許可するためにファイアウォール・アウトバウンドを開くことができます。 詳しくは、 すべてのリージョンのホストに必要なアウトバウンド接続 を参照してから、リージョンに固有のアウトバウンド・ネットワーク要件を確認してください。
ワーカーからマスターへの通信用、またはパッケージ・ミラーへの接続用に HTTP プロキシーを構成することはできません。
TCP トンネリングのセットアップ
プロキシーは、TCP トンネリングを使用してセットアップする必要があります。 特定のステップはプロバイダーによって異なる場合がありますが、TCP トンネリングをセットアップするには、以下の一般的なステップに従ってください。
-
4 つのロケーション・パブリック・サービス・エンドポイントすべてのトラフィックをトンネリングするように HTTP プロキシーをセットアップします。 エンドポイントを見つけるには、
ibmcloud sat location get --location LOCATION_NAME
出力で、パブリック・サービス・エンドポイント URL フィールドを見つけます。 そのフィールドから、エンドポイントを派生させることができます。 例えば、フィールド値が
https://c131-e.us-south.satellite.cloud.ibm.com:31726
の場合、エンドポイントはhttps://c131-1.us-south.satellite.cloud.ibm.com:31726
、https://c131-2.us-south.satellite.cloud.ibm.com:31726
、およびhttps://c131-3.us-south.satellite.cloud.ibm.com:31726
です。 -
HTTP プロキシーのリスナー・ポートが IBM Cloudと同じであることを確認してください。
-
すべての Satellite ホスト上の
/etc/hosts
を更新して、IBM Cloud エンドポイントではなくプロキシーにトラフィックを転送するロケーション・パブリック・サービス・エンドポイントを含めます。
ご使用の構成は、プロバイダーによって異なる場合があります。 ご使用のインフラストラクチャーで構成が機能するように、Satellite 環境の外部でプロキシーをセットアップすることを検討してください。 次に、Satellite 環境でプロキシーを構成します。 HTTP プロキシーのセットアップおよび構成について詳しくは、ブログ Proxying In Cluster Kube-APIServer Traffic in IBM Cloud Satellite
を参照してください。
許可リストへのアクセスの要求
HTTP プロキシーの許可リストにアクセスするには、 IBM サポートに チケットを作成 してください。
例えば、以下の要求をテンプレートとして使用します。
Title: Request for addition of HTTP_PROXY config to
location <LOCATION_ID>
Request Body:
We are requesting the following HTTP_PROXY info be added to
the location_ID listed in the title of this ticket.
Use the following HTTP_PROXY info
BE SURE to include the protocol (http:// or https://)
AND the port (`:PORT_NUMBER`) in the endpoint.
HTTP_PROXY: https://my-proxy-endpoint.com:PORT_NUMBER
HTTPS_PROXY: https://my-proxy-endpoint.com:PORT_NUMBER
サポートがチケットを処理した後、ロケーションが更新されたことを示す通知を受け取ります。 変更が必要な場合は、新しいパラメーターを指定して新しいチケットをオープンする必要があります。 ibmcloud sat locations
を実行してLOCATIONID
を見つけます。
HTTP プロキシーの構成
HTTP プロキシーを構成するには、コントロール・プレーン内のホストを含め、各ホストを編集する必要があります。 コントロール・プレーンを構成するホストを含め、ホストが既にロケーションに接続されている場合は、編集する前に場所からそれらを削除するする必要があります。 プロキシーを構成した後、ロケーションへのホストの再接続。 コントロール・プレーン・ホストの更新について詳しくは、 Satellite ロケーション・コントロール・プレーン・ホストの更新 を参照してください。
-
プロキシーに使用する ミラー・ロケーション を選択します。 このミラー・ロケーションは、プロキシーのセットアップ時に使用されます。
-
NO_PROXY
の値を見つけます。-
コントロール・プレーン・ホストの場合、RHCOS には
172.20.0.1
、RHEL にはNO_PROXY=172.20.0.1,$<REDHAT_PACKAGE_MIRROR_LOCATION>
を使用します。 -
Red Hat OpenShift ホストの場合、
NO_PROXY
for Red Hat OpenShift ホストには、Red Hat OpenShift クラスターに使用されるサービス・サブネットの最初の IP が含まれている必要があります。 この IP を見つけるには、**cluster get
**コマンドを実行します。ibmcloud ks cluster get --cluster <ClusterID>
出力例
Name: hyp-20220306-1-d2 ID: <ClusterID> ... Service Subnet: 172.21.0.0/16 ...
この出力から、最初の IP は
172.21.0.1
であることに注意してください。この例では、RHEL ホストの場合はNO_PROXY=172.20.0.1,172.21.0.1,$REDHAT_PACKAGE_MIRROR_LOCATION
、RHCOS ホストの場合はNO_PROXY=172.20.0.1,172.21.0.1,.REGION.satellite.appdomain.cloud
、この特定のクラスターに関連付けられているホストの完全な出力が作成されます。 例えば、NO_PROXY=172.20.0.1,172.21.0.1,.eu-gb.satellite.appdomain.cloud
は、RHCOS ホストのロンドンのミラー・ロケーションに適しています。 RHCOS 値には、領域の前に.
が含まれていることに注意してください。ワーカー・ノードからクラスター・サービスへのトラフィックはすべて、
NO_PROXY
に含める必要があります。 例えば、イメージ・レジストリー・サービスを使用してイメージを保管するには、ワーカー・ノードごとにimage-registry.openshift-image-registry.svc
をNO_PROXY
に追加します。この値はコントロール・プレーンに含める必要はありません。
-
-
ホスト上の
/etc/systemd/system.conf.d
にナビゲートします。 そのファイルが存在しない場合は、以下のコマンドを使用して作成します。 ステップ 2 の<VALUE>
forNO_PROXY
を入力します。mkdir -p /etc/systemd/system.conf.d cat >"/etc/systemd/system.conf.d/proxy.conf" <<EOF [Manager] DefaultEnvironment="HTTP_PROXY=https://my-proxy-endpoint.com:PORT_NUMBER" "HTTPS_PROXY=https://my-proxy-endpoint.com:PORT_NUMBER" "NO_PROXY=<VALUE>" EOF chmod 0644 /etc/systemd/system.conf.d/proxy.conf
-
以下のコマンドを実行して、
ibm-proxy.sh
ファイルを作成します。 ステップ 2 の<VALUE>
forNO_PROXY
を入力します。mkdir -p /etc/profile.d cat >"/etc/profile.d/ibm-proxy.sh" <<EOF #!/usr/bin/env bash HTTP_PROXY="https://my-proxy-endpoint.com:PORT_NUMBER" HTTPS_PROXY="https://my-proxy-endpoint.com:PORT_NUMBER" NO_PROXY="<VALUE>" export HTTP_PROXY export HTTPS_PROXY export NO_PROXY EOF chmod 0755 /etc/profile.d/ibm-proxy.sh
-
この変更を反映するには、ホストをリブートしてください。
-
ホストをその場所に接続または再接続します。
-
ホストを、以前に割り当てられていた コントロール・プレーン または サービス に割り当てます。
-
ホストごとに、これらのステップを繰り返します。
REDHAT_PACKAGE_MIRROR_LOCATION
の値は、Red Hat パッケージ・ミラーの場所によって異なります。 複数のミラーを使用する場合は、REDHAT_PACKAGE_MIRROR_LOCATION
をワイルドカードにすることができます。 詳しくは、 システム全体のプロキシーを適用する方法を参照してください。
共通ミラー・ロケーション
以下のリストは、いくつかの一般的なミラー・ロケーションを示しています。
- Azure
- 個別に定義:
rhui-1.microsoft.com
、rhui-2.microsoft.com
、rhui-3.microsoft.com
baseurl
の下の/etc/yum.repos.d/rh-cloud.repo
- Google クラウド・プロバイダー
cds.rhel.updates.googlecloud.com
mirrorlist
の下の/etc/yum.repos.d/rh-cloud.repo
- Amazon Web サービス
- ワイルドカード:
aws.ce.redhat.com
rhui3.REGION.aws.ce.redhat.com
mirrorlist
の下の/etc/yum.repos.d/redhat-rhui.repo
- IBM Cloud
- ワイルドカード:
service.networklayer.com
- dal10:
rhncapdal1001.service.networklayer.com
baseurl
の下の/etc/yum.repos.d/redhat.repo