GKE ノードで containerd 構成をカスタマイズする

このページでは、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: "SECRET_LOCATION"
    fqdns:
    - "FQDN1"
    - "FQDN2"

この構成には次のフィールドがあります。

  • enabled: true: 限定公開レジストリ構成を有効にします。enabled: false を設定する場合、privateRegistryAccessConfig アイテム内の他のフィールドをすべて削除します。
  • certificateAuthorityDomainConfig: 証明書と FQDN の定義が最大 5 つ含まれます。
  • gcpSecretManagerCertificateConfig: Secret Manager に保存されている証明書と FQDN の配列が含まれます。
  • secretURI: Secret Manager 内の証明書の場所。
  • fqdns: プライベート レジストリの完全修飾ドメイン名のリスト。IPv4 アドレスを使用することもできますが、FQDN を使用することをおすすめします。

新しいクラスタに containerd 構成を適用する

このセクションでは、新しい GKE クラスタの作成時に containerd 構成ファイルを適用する方法について説明します。

次のコマンドを実行します。

gcloud container clusters create-auto CLUSTER_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 describe CLUSTER_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 describe NODE_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 update CLUSTER_NAME \
    --location=LOCATION \
    --containerd-config-from-file="PATH_TO_CONFIG_FILE"

Standard クラスタでノードを再作成する

Standard クラスタで自動アップグレードを使用しない場合は、ノードプールを手動で再作成して新しい構成を適用する必要があります。ノードの手動再作成をトリガーするには、クラスタがすでに使用している GKE バージョンにクラスタをアップグレードします。

gcloud container clusters upgrade CLUSTER_NAME \
    --location=LOCATION \
    --cluster-version=VERSION

VERSION は、クラスタがすでに使用している GKE パッチ バージョンに置き換えます。

containerd 構成オプションを無効にする

カスタム構成を削除する手順は次のとおりです。

  1. 次の例に示すように、構成ファイルを更新して、無効にする構成アイテムに enabled: false を指定し、アイテム内の他のフィールドを削除します。以下に例を示します。

    privateRegistryAccessConfig:
  enabled: false
  2. 更新された構成ファイルをクラスタに適用します。手順については、既存のクラスタに containerd 構成を適用するをご覧ください。