ブートストラップに使用するマシンとクラスタノードがプロキシ サーバー経由でインターネットにアクセスしている場合は、次の操作を行う必要があります。
- クラスタノードでパッケージ マネージャー用のプロキシを構成する
- クラスタ構成ファイルにプロキシの詳細を構成する。
前提条件
プロキシ サーバーで、次のアドレスへの接続を許可する必要があります。
住所 | 目的 |
---|---|
*.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 プロキシを手動で構成します。