このページでは、Google Kubernetes Engine(GKE)ノードの containerd コンテナ ランタイムの構成をカスタマイズする方法について説明します。このドキュメントをお読みになる前に、コンテナ ランタイムの概要とカスタマイズする理由を理解している必要があります。
GKE での containerd 構成について
Container-Optimized OS などのオペレーティング システムを実行する GKE ノードでは、containerd ランタイムで一連のオプションを手動で構成できます。ランタイムをカスタマイズすると、限定公開イメージ レジストリへのアクセスなどの特別な要件を構成できます。これらのオプションを設定するには、ランタイム構成ファイルと呼ばれる YAML ファイルを作成し、クラスタを作成または更新するときにこのファイルを GKE に渡します。
この方法で containerd をカスタマイズすると、セキュリティ リスクとなる特権 DaemonSet のデプロイを回避できます。GKE にランタイム構成ファイルを指定すると、GKE はノードを再作成し、すべてのノードで containerd config.toml
ファイルを構成で更新します。この構成は、ノードの終了、アップグレード、再作成後も保持されます。
ランタイム構成ファイルを使用する場合は、containerd でのみオプションを構成できます。GKE では、ノードシステム構成ファイルと呼ばれる別のファイルを使用して、特定の kubelet オプションと低レベルの Linux カーネル オプションを構成することもサポートされています。詳細については、ノードシステム構成のカスタマイズをご覧ください。
制限事項
ランタイム構成ファイルを使用して Ubuntu ノードイメージの containerd 設定を変更することはできません。containerd を含む Container-Optimized OS のみがサポートされています。これは、すべての GKE クラスタのデフォルトのノードイメージです。
利用可能な containerd 構成オプション
次の表に、ランタイム構成ファイルを使用して構成できるオプションを示します。
ランタイム構成ファイルのオプション | |
---|---|
|
Secret Manager に保存したプライベート認証情報を使用して、限定公開イメージ レジストリにアクセスします。 手順については、プライベート CA 証明書を使用して限定公開レジストリにアクセスするをご覧ください。 privateRegistryAccessConfig: enabled: true certificateAuthorityDomainConfig: - gcpSecretManagerCertificateConfig: secretURI: " この構成には次のフィールドがあります。
|
新しいクラスタに containerd 構成を適用する
このセクションでは、新しい GKE クラスタの作成時に containerd 構成ファイルを適用する方法について説明します。
次のコマンドを実行します。
gcloud container clusters create-autoCLUSTER_NAME
\ --location=LOCATION
\ --scopes="cloud-platform" \ --containerd-config-from-file="PATH_TO_CONFIG_FILE
"
次のように置き換えます。
CLUSTER_NAME
: 新しいクラスタの名前。LOCATION
: 新しいクラスタの Compute Engine のロケーション。PATH_TO_CONFIG_FILE
: 作成した構成ファイルのパス(~/containerd-configuration.yaml
など)。
新しい Standard クラスタで限定公開レジストリ構成を有効にするには、同じオプションを指定して gcloud container clusters create
コマンドを実行します。
既存のクラスタに containerd 構成を適用する
このセクションでは、既存のクラスタとノードに containerd 構成を適用する方法について説明します。
アクセス スコープを確認する
この機能を使用するには、既存のクラスタに cloud-platform
アクセス スコープが必要です。このセクションでは、アクセス スコープを確認し、新規または変更された限定公開レジストリ構成ファイルを使用して既存のクラスタを更新する方法について説明します。
新しいクラスタのデフォルトのアクセス スコープの詳細については、GKE のアクセス スコープをご覧ください。
Autopilot のアクセス スコープを確認する
次のコマンドを実行します。
gcloud container clusters describeCLUSTER_NAME
\ --location=LOCATION
\ --flatten=nodeConfig \ --format='csv[delimiter="\\n",no-heading](oauthScopes)'
クラスタに https://www.googleapis.com/auth/cloud-platform
アクセス スコープがない場合は、このアクセス スコープを持つ新しいクラスタを作成します。
Standard アクセス スコープを確認する
Standard クラスタのアクセス スコープを確認するには、ノードプールを確認します。
gcloud container node-pools describeNODE_POOL_NAME
\ --cluster=CLUSTER_NAME
\ --location=LOCATION
\ --flatten=nodeConfig \ --format='csv[delimiter="\\n",no-heading](oauthScopes)'
NODE_POOL_NAME
は、ノードプールの名前に置き換えます。
クラスタに https://www.googleapis.com/auth/cloud-platform
アクセス スコープがない場合は、cloud-platform
アクセス スコープで新しいノードプールを作成し、既存のノードプールを削除します。
構成ファイルを使用するようにクラスタを更新する
次のコマンドを実行します。
gcloud container clusters updateCLUSTER_NAME
\ --location=LOCATION
\ --containerd-config-from-file="PATH_TO_CONFIG_FILE
"
Standard クラスタでノードを再作成する
Standard クラスタで自動アップグレードを使用しない場合は、ノードプールを手動で再作成して新しい構成を適用する必要があります。ノードの手動再作成をトリガーするには、クラスタがすでに使用している GKE バージョンにクラスタをアップグレードします。
gcloud container clusters upgradeCLUSTER_NAME
\ --location=LOCATION
\ --cluster-version=VERSION
VERSION
は、クラスタがすでに使用している GKE パッチ バージョンに置き換えます。
containerd 構成オプションを無効にする
カスタム構成を削除する手順は次のとおりです。
-
次の例に示すように、構成ファイルを更新して、無効にする構成アイテムに
enabled: false
を指定し、アイテム内の他のフィールドを削除します。以下に例を示します。privateRegistryAccessConfig: enabled: false
- 更新された構成ファイルをクラスタに適用します。手順については、既存のクラスタに containerd 構成を適用するをご覧ください。