プロキシの背後でインストールする

ブートストラップに使用するマシンとクラスタノードがプロキシ サーバー経由でインターネットにアクセスしている場合は、次の操作を行う必要があります。

  • クラスタノードでパッケージ マネージャー用のプロキシを構成する
  • クラスタ構成ファイルにプロキシの詳細を構成する。

前提条件

プロキシ サーバーで、次のアドレスへの接続を許可する必要があります。

住所 目的
*.gcr.io Container Registry からイメージを pull します。
accounts.google.com OpenID の認可リクエストを処理し、トークン検証用の公開鍵を検出します。
cloudresourcemanager.googleapis.com クラスタが接続されている Google Cloud プロジェクトに関するメタデータを解決します。
compute.googleapis.com Cloud Logging と Cloud Monitoring のリソースのリージョンを確認します。
dl.fedoraproject.org Red Hat Enterprise Linux(RHEL)ディストリビューションを使用する場合に、Extra Packages for Enterprise Linux(EPEL)をインストールします。
download.docker.com Docker リポジトリを追加します。これは、プロキシの背後で管理ワークステーションを実行する場合に必要です。Docker がコンテナ ランタイムに使用される場合、プロキシの背後で実行されるノードマシンに必要です。
gkeconnect.googleapis.com Google Cloud からのリクエストの受信に使用するチャネルを確立し、レスポンスを発行します。
gkehub.googleapis.com Google Cloud に接続するクラスタに対応する Google Cloud 側のハブ メンバーシップ リソースを作成します。
iam.googleapis.com Google Cloud への認証と API 呼び出しに使用できるサービス アカウントを作成します。
iamcredentials.googleapis.com 監査ログのアドミッション コントロールとテレメトリー レポートを提供します。
logging.googleapis.com ログエントリを書き込み、Cloud Logging 構成を管理します。
monitoring.googleapis.com Cloud Monitoring のデータと構成を管理します。
packages.cloud.google.com Google Cloud パッケージ ミラーからパッケージをダウンロードします。
oauth2.googleapis.com OAuth トークン交換によってアカウントへのアクセスを認証します。
opsconfigmonitoring.googleapis.com Pod、Deployment、Node などの Kubernetes リソースのメタデータを収集して、指標クエリを拡充します。
securetoken.googleapis.com Workload Identity 承認の更新トークンを取得します。
servicecontrol.googleapis.com 監査ログエントリを Cloud Audit Logs に書き込みます。
serviceusage.googleapis.com サービスと API を有効にして検証します。
stackdriver.googleapis.com Google Cloud のオペレーション スイートのメタデータ(Stackdriver アカウントなど)を管理します。
storage.googleapis.com Container Registry オブジェクトなどのオブジェクト ストレージとバケットを管理します。
sts.googleapis.com 有効期間が短いアクセス トークンと Google またはサードパーティの認証情報を Google Cloud リソースと交換します。
www.googleapis.com 受信した Google Cloud サービス リクエストからサービス トークンを認証します。

これらの URL に加えて、プロキシ サーバーは、オペレーティング システムのパッケージ マネージャーが必要とするパッケージのミラーリングも許可する必要があります。パッケージ マネージャーの構成を更新すると、より確定的なリストを使用でき、管理が容易になります。

クラスタノードでパッケージ マネージャー用のプロキシを構成する

Ubuntu の場合、ベアメタル版 Anthos クラスタは APT パッケージ マネージャーを使用します。CentOS と Red Hat Linux の場合は、DNF パッケージ マネージャーを使用します。OS Package Manager のプロキシ構成が正しいことを確認してください。

プロキシ構成の詳細については、OS ディストリビューションのドキュメントをご覧ください。次の例は、プロキシを構成する 1 つの方法を示しています。

APT

以下のコマンドは、APT のプロキシを構成する方法を示しています。

sudo touch /etc/apt/apt.conf.d/proxy.conf
echo 'Acquire::http::Proxy "http://[username:password@]domain";' >> /etc/apt/apt.conf.d/proxy.conf
echo 'Acquire::https::Proxy "http://[username:password@]domain";' >> /etc/apt/apt.conf.d/proxy.conf

[username:password@]domain は、構成に固有の詳細に置き換えます。

DNF

このコマンドは、DNF のプロキシを構成する方法を示しています。

echo "proxy=http://[username:password@]domain" >> /etc/dnf/dnf.conf

[username:password@]domain は、構成に固有の詳細に置き換えます。

クラスタ構成ファイルにプロキシの詳細を構成する

クラスタの構成ファイルで次の値を設定して、プロキシを使用するようにクラスタを構成します。

proxy.url

プロキシ URL を指定する文字列。ブートストラップとノードマシンは、このプロキシを使用してインターネットにアクセスします。

proxy.noProxy

プロキシ サーバーを経由しない IP アドレス、ホスト名、ドメイン名のリスト。

ほとんどの場合、このリストに項目を追加する必要はありません。Service と Pod CIDR を追加しないでください。

noProxy のユースケース:

  • 同じプライベート ネットワークにあるプライベート パッケージ ミラーの使用(アクセスにプロキシを必要としない)

  • 同じプライベート ネットワークにあるプライベート レジストリ ミラーの使用(アクセスにプロキシを必要としない)

次に、クラスタ構成ファイルのプロキシ設定の例を示します。

  proxy:
     url: http://[username:password@]domain
     noProxy:
     - example1.com
     - example2.com

プロキシ構成をオーバーライドする

クラスタ構成ファイルのプロキシ設定をオーバーライドすることで、ノードマシンで使用されているプロキシとは異なるプロキシの背後でブートストラップ マシンを実行できます。プロキシ設定をオーバーライドするには、ブートストラップ マシンで次の環境変数を設定します。

export HTTPS_PROXY=http://[username:password@]domain

[username:password@]domain は、構成に固有の詳細に置き換えます。

export NO_PROXY=example1.com,example2.com

example1.com,example2.com は、プロキシ サーバーを経由しない IP アドレス、ホスト名、ドメイン名に置き換えます。

副作用

root として実行すると、bmctl はブートストラップ マシンの Docker プロキシ構成を更新します。bmctl を root として実行しない場合は、Docker プロキシを手動で構成します