【ITニュース解説】Configuring EKS Managed Node Groups to Use a Proxy with Terraform

企業環境において、セキュリティとネットワークの規則は非常に重要だ。例えば、サーバーがインターネットに直接アクセスできないプライベートなネットワークに配置され、すべての外部通信が中央で管理・監視されるプロキシサーバーを経由するように設定されていることは珍しくない。Amazon EKSのようなサービスも例外ではなく、Kubernetesのワーカーノードは、コンテナイメージの取得、AWSのAPIとの通信、初期設定のタスクなどを実行する必要があるため、このプロキシ環境に対応しなければならない。

単純にHTTP_PROXYやHTTPS_PROXYといった環境変数を設定するだけでは、EKSノード全体がプロキシを意識して動作するようにはならない。EKSノードは、Amazon Linux 2 EKS Optimized AMIというOSの上に、いくつかの主要なコンポーネントが動いている複合的なシステムだからだ。具体的には、シェルセッションや一般的なシステムユーティリティが使う「ベースOS」、コンテナの実行とイメージの取得を行う「Containerd（コンテナランタイム）」、EKSクラスターへのノード参加を管理する新しいブートストラップエージェント「nodeadm」、そしてパッケージのインストールを行う「yum」といった要素があり、これらすべてがプロキシ設定を正しく認識する必要がある。特にContainerdがプロキシ設定を持たないと、Docker Hubのような外部の公開レジストリだけでなく、VPC外のプライベートレジストリ（例えばAmazon ECR）からコンテナイメージをダウンロードできず、ノードの起動に失敗してしまう。一方で、nodeadmが行うEKSコントロールプレーンとの通信は、プロキシをバイパスして直接行われるべきだ。

この課題を解決するための堅牢な方法は、Terraformのterraform-aws-modules/eks/awsモジュールが提供するcloudinit_pre_nodeadmという特別なフック（特定の処理が実行される前に、独自のスクリプトを差し込む仕組み）を活用することだ。このフックは、EKSノードの起動プロセスにおいて、中心的な役割を果たす二つの重要な要素と密接に関わっている。

まず「cloud-init」について。これは、クラウドで仮想サーバー（EC2インスタンスなど）が初めて起動する際に、自動的に初期設定を行うための業界標準のツールだ。例えば、OSの設定、パッケージのインストール、ファイルの作成、ユーザーアカウントのセットアップなどを、サーバーが「利用可能」になる前に実行してくれる。

次に「nodeadm」について。EKS Optimized Amazon Linux 2023 AMI以降で導入されたnodeadmは、EKSクラスターにノードを参加させるための公式なブートストラップエージェントだ。以前使われていたbootstrap.shスクリプトに代わり、クラスターの証明書の取得、Kubernetesエージェント（kubelet）の設定、ノードのラベルやテイント（ノードの特性を示す情報）の適用といった、多岐にわたる重要なタスクを担っている。

cloudinit_pre_nodeadmフックは、このcloud-initとnodeadmの間に絶妙なタイミングでカスタムスクリプトを実行できる機能だ。具体的には、基本的なOSの初期設定が完了した後、しかしnodeadmサービスがまだ開始する前にスクリプトを実行できる。このタイミングが非常に重要で、nodeadmやContainerd、そしてkubeletが起動する前に、必要なプロキシ設定を含むネットワーク環境を完全に整えることができる。これにより、これらのコンポーネントは起動直後から正しい設定を継承し、制限されたネットワーク環境下でも問題なく機能するようになる。

具体的なTerraformの実装では、eks_managed_node_groupsブロック内でcloudinit_pre_nodeadmパラメータを使い、シェルスクリプトを直接記述する。このスクリプトは、KubernetesクラスターのサービスCIDR（クラスター内部のサービスが使用するIPアドレス範囲）のような情報を、Terraformの設定から動的に受け取ることができる。

スクリプトの内容を見ていこう。まずset -exというコマンドは、スクリプトの実行中にエラーが発生したらすぐに停止し、各コマンドが実行される前に画面に表示することで、デバッグを容易にするための一般的なベストプラクティスだ。次に、プロキシサーバーのアドレスをPROXYという変数に定義する。例えばhttp://your-proxy-url:3128のようになる。

重要なのは、NO_PROXYリストの設定だ。これは、プロキシを経由させたくない通信先を指定するリストで、HTTP_PROXYの設定と同等かそれ以上に重要だ。このスクリプトでは、IMDSv2（Instance Metadata Service Version 2）という、よりセキュアな方法を使って、EC2インスタンスのメタデータサービスからVPCのIPアドレス範囲（CIDRブロック）を動的に取得する。このCIDRはNO_PROXYリストに追加され、VPC内の他のリソースへのトラフィックがプロキシを迂回するようにする。さらに、KubernetesのサービスCIDR、localhost、メタデータサービスのアドレス（169.254.169.254）、そしてEKSコントロールプレーンやAWSのAPI（例えば.amazonaws.com）との直接通信を保証するためのAWSサービスエンドポイントもNO_PROXYリストに含める。

これらの変数が定義された後、プロキシ設定は以下の手順で適用される。

1. システム全体のプロキシ設定: /etc/environmentファイルにHTTP_PROXY、HTTPS_PROXY、NO_PROXYの環境変数を設定する。このファイルは、システム全体で利用される環境変数の基礎となる。
2. Containerdへのプロキシ設定: systemdというLinuxのサービス管理システムを利用し、Containerdサービスにプロキシ設定を適用する。直接Containerdのサービスファイルを編集するのではなく、systemdのオーバーライドファイルを作成し、先ほど設定した/etc/environmentファイルを読み込むように指定する。これは、オリジナルのサービスファイルを変更せずに設定を適用する、現代的で保守性の高い方法だ。
3. nodeadmへのプロキシ設定: Containerdと同様に、nodeadmサービスにもsystemdのオーバーライドファイルを使って/etc/environmentを読み込ませる。これにより、nodeadmも起動時にプロキシ設定を認識する。
4. yumへのプロキシ設定: パッケージマネージャーであるyumもプロキシ経由で動作するように、/etc/yum.confファイルにプロキシのアドレスを追加する。
5. 設定の反映: 最後に、systemctl daemon-reloadコマンドでsystemdに設定ファイルの変更を再読み込みさせ、systemctl restart containerdコマンドでContainerdサービスを再起動し、新しい環境変数を即座に適用する。nodeadmはスクリプト完了後すぐに起動するため、この設定を自動的に引き継ぐ。

この方法により、HTTPプロキシの背後にあるネットワークでEKSワーカーノードをデプロイするという、企業環境でよくある課題を解決できる。terraform-aws-modules/eks/awsモジュールのcloudinit_pre_nodeadmフックを効果的に利用することで、ノードのブートストラップシーケンスを正確に制御できる。これは、オペレーティングシステム、Containerd、nodeadmといった主要なコンポーネントが起動する前に、必要なプロキシ設定を動的に注入する、宣言的で自動化された、そして堅牢なソリューションだ。インフラストラクチャをコードとして管理する（Infrastructure as Code）このアプローチは、単に技術的な問題を解決するだけでなく、安全で規制に準拠したKubernetesプラットフォームをAWS上に構築するための、再現性とバージョン管理が可能なパターンを確立することにつながる。