Zadara での Kubernetes: ブログシリーズ #5

Kubernetes の新しいブログシリーズの 5 回目 (最終回) へようこそ！このシリーズでは、Zadara での Kubernetes デプロイの世界と AWS 互換クラウドでコンテナ化されたアプリケーションを管理するために Kubernetes をどのように使用できるかを探ります。このシリーズは Kubernetes が初めての方にも経験豊富な方にも Zadara クラウドでコンテナ化アプリケーションを管理するための貴重な洞察とベストプラクティスを提供します。エキサイティングなコンテンツにご期待ください！

このブログでは、EKS-D ソリューションのカスタマイズに焦点を当て、プロダクションレベルの Kubernetes クラスタを作成する際の様々なお客様のニーズに対応します。

カスタム設定

これまでのブログでは、全てオートデプロイメントワークフローに組み込まれたデフォルト値を使用して Kubernetes をそのままデプロイしていました。このような構成は、迅速なデモや PoC レベルの環境には適しているかもしれませんが、プロダクションレベルのセットアップには適していません。最もわかりやすい例は、コントロールプレーンのセットアップ (可用性の高い 3ノード構成ではなく、シングルノードがデフォルト) ですが、他にもさらなるカスタマイズも必要かもしれません。

EKS-D ソリューションをカスタマイズするための第一歩として、クラスタをデプロイするオールインワンのラッパースクリプト (apply-all.sh) を実行するときに何が起こっているのかを理解する必要があります。

このラッパースクリプトはワークフローの実行を容易にするためにいくつかの基本的な変数しか利用していませんが、2つの内包している Terraform プロジェクト (インフラと EKS-D デプロイ) は様々なユースケースとコンフィギュレーションのために多くの変数をサポートしています。

変数の完全なリストは、2つのプロジェクトの変数ファイル（infra & eksd）で見ることができます。

• infra-terraform の expose_k8s_api_publicly : API Server の NLB を公開するかどうかを制御する (デフォルトは true)

• infra-terraform の vpc_cidr : VPC の CIDR を制御する (デフォルトは 192.168.0.0/16)

• eksd-terraform の masters_count : 初期コントロールプレーンノードの量を制御 (デフォルトは 1、高可用性コントロールプレーンの場合は 3 に設定)

• eksd-terraform の ebs_csi_volume_type : EBS CSI で使用する VolumeType を指定 (デフォルトは gp2) 

• eksd-terraform の workers_instance_type : データプレーンのインスタンスタイプを指定 (デフォルトは z8.large)

デフォルト値を変更するにはプロジェクトの variables.tf ファイルを変更するか、terraform の環境変数に設定する必要があります。例:

$ TF_VAR_masters_count=3 ./apply-all.sh

環境変数を使用することはファイルを編集せずにデプロイメントに影響を与える簡単な方法ですが、変更した値をプロジェクト内で保持しない場合、環境変数なしでデプロイメントを再実行すると元の値が上書きされ、デプロイメントに悪影響を及ぼす可能性があることに留意してください。そのため、通常は変数ファイルを編集することをお勧めします。

カスタマイズされた変数のもう 1 つの使用例は、デプロイオプションのアドオンを eksd-terraform 変数の一部として制御することです。

• install_ebs_csi : AWS EBS CSI ドライバをインストールするかどうか (デフォルトは true)

• install_lb_controller : AWS Load Balancer Controller をインストールするかどうか (デフォルトは true)

• install_autoscaler : Cluster Autoscaler をインストールするかどうか (デフォルトは true) 

• install_kasten_k10 : Kasten K10 をインストールするかどうか (デフォルトは false)

オプションのアドオンとは異なり、EKS-D のデプロイでは、いくつかの必須アドオンも暗黙的にインストールされます。例えば、Kubernetes 用の AWS クラウドプロバイダーである CCM (Cloud Controller Manager) コンポーネントや、EKS-D にバンドルされている CoreDNS や kube-proxy などがそうです。これらのアドオンのいくつかは EKS-D イメージを変更することで制御できますが（詳細は後述）、その他のアドオンは cloud-init スクリプトの一部を深いレベルで変更する必要があることに注意してください。

オプションではないですが Terraform で管理可能な最後のアドオンとして、CNI (Container Network Interface) があります。これはネットワークスタック全体を扱う Kubernetes のコアコンポーネントなので、これがないとクラスタは初期化されません。EKS-D クラスタにどの CNI を使うかは、cni_provider 変数を使って、サポートされている以下のものの中から決めることができます。

• flannel :  デフォルトの CNI で、高速でシンプルかつ信頼性の高いレイヤー 3実装

• calico : ルーティングとセキュリティ機能を追加した先進的なマルチレイヤ CNI

• cilium (実験的サポート) : eBPF ネイティブで、高度なルーティング、セキュリティ、可観測性機能を追加した高度なマルチレイヤ CNI

Cilium については、実験的なものと考えられていますが (Zadara はテスト手順の一環として、必要不可欠なネットワーク機能のみを検証)、このデプロイメントによって Hubble UI の可観測性機能も有効になり、cilium CLI からその名前空間を参照してアクセスすることができます。

$ cilium hubble ui --namespace cilium-system

このコマンドを実行すると、hubble-ui サービスが localhost にポートフォワードされクラスタのネットワーキングの痕跡をモニターできるようになります。

デフォルト以外の CNI を使用して EKS-D を導入する場合、初期化フェーズの一部として追加のリソースとダウンロードが必要になる可能性があることに注意してください。サイジングなどを検討する際に留意してください。

カスタムワークフロー

場合によってはラッパースクリプトを使わず、ユーザー自身でワークフローを実行したり、デプロイメントプロジェクトを様々な方法で変更する必要があるかもしれません。そのような場合、ワークフローは以下の 2つのフェーズに分けることができます。

最初のフェーズはインフラのデプロイで、EKS-D のデプロイに必要ないくつかの前提条件 (例えば Kubernetes クラスタを作成する VPC やサブネット) を処理します。ドキュメントのステップに従って infra-terraform プロジェクト (またはそのバリエーション) を実行できますが、2回目の Terraform 実行後も NLB IP を取得する必要があることに注意してください。手動 (例えば zCompute コンソール経由) で取得するか、Terraform の出力に記載されているパラメータを指定して get_loadbalancer.sh スクリプトを実行できます。

infra-terraform プロジェクトを使用する代わりに、( zCompute の VPC ウィザードを使用して手動で、または他のクラウド自動化機能を使用して) 独自のインフラストラクチャートポロジーを使用したい場合は、以下の要件に注意してください。

• プライベートとパブリックのサブネットは、AWS CCM/LBC が検出できるように、AWS ドキュメントに従ってタグ付けされなければなりません (タグはプライベートとパブリックのサブネットで異なることに注意) 。

• EKS-D の api-server のエンドポイントにパブリック NLB またはインターナル NLB を使用することも、ロードバランサーを使用しない場合は完全にスキップすることもできますが、ロードバランサーまたはマスターインスタンスのプライベートIP (場合によってはパブリックIPも) を少なくとも EKS-D のデプロイメントフェーズに提供する必要があります。

第 2フェーズは EKS-D のデプロイで、コントロールプレーンとデータプレーンの両方のノードを起動します。コントロールプレーンの VM を EKS-D の api-server の NLB に紐付けする作業も含まれます。eksd-terraform プロジェクト (またはそのバリエーション) をドキュメントの手順に従って実行することができます。Terraform 実行後にマスターノードから初期 kubeconfig ファイルを取得する必要があることに注意してください。手動で取得するか、Terraform の出力に記載されているパラメータを指定して get_kubeconfig.sh スクリプトを実行してください。

スクリプト使用ではなく手動で kubeconfig ファイルを取得したい場合、通常のインフラストラクチャトポロジでは、コントロールプレーン VM に到達するために bastion VM を経由する必要があることに注意してください。各マスター VM の内部では、/etc/kubernetes/zadara/kubeconfig として必要なファイルが表示されます (Kubernetes 1.29以上の場合、ユーザーは通常の admin ユーザーではなく super-admin になることに注意) 。

eksd-terraform プロジェクトを使用する代わりに、EKS-D クラスタを (手動または他のクラウド自動化機能を使用して) 自分でデプロイする場合は、以下の要件に注意してください。

• CCM がステータスを追跡するためには、全ての VM が kubernetes.io/cluster/<kubernetes-name> キーと owned 値でタグ付けされていなければなりません。

• 手動デプロイメントの参考例として、ここの手動デプロイメント手順を参照することができます。

カスタムイメージ

Zadara はクラウドマーケットプレイスで EKS-D のプリベイクイメージをいくつか提供していますが、ユーザーは様々な理由で自分用にカスタマイズしたイメージを使いたいと思うかもしれません。例えば、Zadara が提供していない特定の EKS-D バージョン (例えば、バージョン 1.27) を使用したい、いくつかのアドオンを変更したい (例えば、すべての最新バージョンを使用しない)、セキュリティを強化するためにベース OS イメージを固定させたいなどです。

BYOI (Bring Your Own Image) 手法では、EKS-D Packer プロジェクトのガイドラインに従い、イメージを新しい AMI にベイクし、その後 EKS-D のデプロイメントをそのカスタマイズされた AMI に向けることで、そのようなカスタマイズが可能になります。実際、Zadara では同じ Packer プロジェクトを使用して、マーケットプレイス用の EKS-D イメージをベイクしているため常に最新の状態に保たれています。プロジェクトには以下のフェーズが含まれます。

デフォルトでは、すべてのユーティリティとアドオンは最新のリリースバージョンでインストールされます。プロジェクトの bash スクリプトファイルを編集することで、この動作を変更することができます。

Packer プロジェクトで独自のイメージをビルドする場合、以下のガイドラインに従って .auto.pkvars.hvl パラメータファイルを入力する必要があります。

• Zadara は、セキュリティおよびコンプライアンス上の理由から、EKS-D イメージを最新の Ubuntu 22.04 (zCompute のマーケットプレイスで入手可能) をベースにすることを推奨しています。Packer プロジェクト内の既存のスクリプトのほとんどは Debian 指向のものであり (apt や yum など) 、このようなオペレーティングシステムファミリーのために大幅な変更は必要ありません。実際の AMI ID は、zCompute コンソールの Images パネルで確認できます。

• Packer が中間 VM を作成するために使用する Debian ベースの (Zadara の toolbox や Ubuntu のような) bastion VM を用意してください。ルートテーブルとセキュリティグループについて、この VM にアクセスできることを確認してください (SSH 用のポート 22 が許可されている必要があります)。

• Packer の中間 VM が使用する既存のサブネット ID を提供する必要があります。Bastion VM がルートテーブルに関してそのサブネットにアクセスできることを確認してください (通常、Bastion VM と同じサブネットを使用するのが最善策です)。

変数ファイルの例として、以下を参照してください。

この例では、エラスティック IP (bastion のパブリック IP) を持つ既存の Fedora Zadara toolbox VM を使用して、デモクラウド上で EKS-D イメージをベイクしています。ビルド自体は、アカウントのデフォルト VPC とパブリックサブネット上で Ubuntu 22.04 AMI を使用します (サブネットの AWS ID が必要なことに注意してください) 。最も重要なことは、EKS-D の GitHub リポジトリで見ることができるように EKS-D 1-29 release 3 をベイクするように設定する事です (このページは常に最新のリリースを反映しているため、変更される可能性があることに注意してください) 。

packer build . コマンドでビルドプロセスを開始する際、ローカルの AWS プロファイルが、関連する zCompute クラウドの AWS CLI 認証情報を指す必要があることに注意してください (以下の例では、そのためのアドホック環境変数を使用しています) 。

コンテンツの変更内容、ネットワーク帯域幅、VM サイズ (デフォルトは z8.large) にもよりますが、ベイク処理には 15〜30分ほどかかり、新しい AMI ができあがります。

完了後、新しい AMI は、zCompute コンソールの Images パネルで使用できるようになります。

この AMI ID を通常の EKS-D デプロイメントで使用することでカスタマイズしたイメージを利用できます。

配置ルール

デプロイスクリプトではカバーされない、プロダクションレベルのデプロイメントにとって重要な要素が 1つあります。これは Kubernetes のアンチアフィニティルールに相当すると考えて欲しいものです。クラウドレベルのルールを作成することで、AWS の配置グループと同様に、特定のタグが付けられた VM が異なるインフラノードに配置されるように設定できます。唯一の違いは、Zadara のようなエッジクラウドでは、ルールはより広いアベイラビリティゾーンのパーティションではなく、基礎となる物理ノード上の VM 配置を制御することです。

コントロールプレーンの VM のような複数の重要なインスタンスが同じ物理ノード上に同居するケース (インフラ障害が発生した場合に問題となる可能性がある) を防ぐために、ミッションクリティカルなワークロードに対する一般的な推奨は、ユーザーの要求に基づいてクラウドに組み込まれたスケジューリングをする専用のルールを作成することであります。強制的に (“ハード” ルール、つまりルールに違反して VM が作成されることはない)、またはベストエフォートで (“ソフト” ルール) を作成できます。

この例では、”k8s” クラスタの各コントロールプレーン VM を異なるインフラノードに配置するよう Zadara クラウドに指示するソフトルールを作成しました。

Kubernetes クラスターをデプロイする前に、既存のタグを使用することも、新しいタグを作成することもできます。この特定のタグは、環境 (クラスター) 名をキーとし、コントロールプレーン/データプレーンタイプを値として、新しいコントロールプレーン VM に対して常に作成されます。

ハードルールではなくソフトルールを使用したことに注意してください。通常のクラウド上で本番ワークロードを何年も運用してきた経験から、個人的にはハードルールの方が好きです。

例えば、このクラウドには大きなインフラノードが数台しかないため、ハードルールによってマスターノードを (すぐに、あるいは後で) 生成できないかもしれない。エンドユーザーはクラウドの基盤となるインフラストラクチャノードやその能力を確認することができないため、このようなケースでは (特に小規模なエッジクラウドでは) ハードルールが諸刃の剣となる可能性があります。

この警告を念頭に置くと、配置ルールは Kubernetes のコントロールプレーン VM のようなセンシティブな本番ワークロードにとって重要な保護レイヤです。ルールの基礎としてクラスタレベルのタグを使用することを忘れないでください。そうしないと、環境内の全ての Kubernetes クラスタに跨って全てのマスターノードに同じルールが適用されることになるかもしれません。

最後の考察

このブログでは、EKS-D ソリューションの一部である様々なカスタマイズ技術とソリューションの部分ではないですが Zadara クラウド上でプロダクショングレベルのクラスタを確立するための関連する技術をレビューしました。より多くの知識を得て理解を深める余地は常にありますが、このブログ記事とシリーズ全体が、Zadara クラウド上で Kubernetes を実行することがいかに簡単かを実感する一助となれば幸いです。

さらなるコンテンツやヒント、トリックについては、私たちの zadara-examples GitHub リポジトリにご期待ください！