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

Kubernetes の新しいブログシリーズの2回目へようこそ！このシリーズでは、Zadara 上でのKubernetes デプロイの世界と、AWS 互換クラウドでコンテナ化されたアプリケーションを管理するために Kubernetes をどのように使用できるかを探ります。Kubernetes とコンテナオーケストレーションの基本から、スケーリング、回復力、ライフサイクル管理といった高度なトピックまで、幅広いトピックを取り上げます。また、お客様のニーズに応じて Kubernetes を zCompute 上にデプロイし、カスタマイズするさまざまな方法についても掘り下げます。

このシリーズでは、Kubernetes が初めての方にも経験豊富な方にも、Zadara クラウドでコンテナ化されたアプリケーションを管理するための貴重な洞察とベストプラクティスを提供します。さらなるエキサイティングなコンテンツにご期待ください！

第2回目のブログポストは、Zadara クラウド上の EKS-D ソリューションの紹介に焦点を当てます。ソリューションの概要、アーキテクチャをカバーし、当社の自動化されたブループリントを使用して Kubernetes をいかに簡単にデプロイできるかを強調するために、簡略化されたデプロイシナリオを実演します。

ソリューション概要

Zadara は zCompute バージョン 23.08 以上（VSC モード）から、セルフマネージド型 EKS-D クラスタ自動展開のための高度にカスタマイズ可能なソリューションを提供しています。

EKS-Dソリューションは、以下の主な要素に基づいています。

最初の要素は EKS-D の VM イメージで、Kubernetes の前提条件 EKS-D の成果物と関連するカスタマイズ機能がすべて含まれています。Zadara は EKS と同じ方法論に従い、これらのイメージ（EKS-D のメジャーリリースごと）の AMI を事前に用意し、各クラウドのイメージマーケットプレイスで提供しています。また、実際のベイクスクリプトをオープンソースのPacker プロジェクトとして提供しているので顧客は当社のイメージ作成プロセスを確認し、特定のニーズに基づいて独自の AMI を作成することもできます。

2つ目の要素は自動デプロイスクリプトで、2つの Terraform プロジェクト（1つは必要なインフラストラクチャ用、もう1つは実際の EKS-D デプロイ用）と、ワンクリックでデプロイするためのオプションのラッパースクリプトで構成されています。オートデプロイスクリプトを実行すると Zadara クラウド上で Kubernetes クラスタが作成され、Kubernetes 管理ユーザー用の kubeconfig ファイルがローカルに作成されます。

3つ目の要素は Kubernetes アドオンで、これはイメージに組み込まれオートデプロイによって制御される Kubernetes ネイティブのアプリケーションになります。

• CNI – ネットワーキングプロバイダー（Flannel、Calico、Cilium のいずれかを使用可能）
• EBS CSI driver – ブロックストレージのインテグレーション
• Load Balancer Controller – ロードバランサーのインテグレーション（NLB と ALB の両方に対応）
• Cluster Autoscaler – クラスタレベルのオートスケーリング機能
• Kasten K10 – アプリケーションレベルのバックアップ＆リストア機能

これらのアドオンについては、次回のブログポストで詳しく説明する予定です。現時点では、EKS-D ソリューションの一部として導入しやすくするためカスタマイズ可能でありますが、これらの機能のほとんどをデフォルトで有効にし、すぐに使用できるようになっていることに注意してください。

リファレンスアーキテクチャー

下図は、EKS-D のオートデプロイメントのハイレベルな最終結果を示しており、Terraform プロジェクトによって作成されるこれらのコンポーネントで構成されていいます。

• Kubernetes 環境用の専用 VPC（CIDR のデフォルトは 192.168.0.0/16 ですが、カスタマイズ可能です。）

• インターネットゲートウェイを備えたパブリックサブネット
  • このサブネットは、小さなな Bastion（ジャンプサーバ）インスタンスをホストし、必要に応じてユーザが内部サブネットの VM にアクセスできるようにします。デフォルトのセキュリティグループは世界中からの SSH 接続を許可していますので必要に応じて変更してください。
  • このサブネットは、Kubernetes API Server 用のロードバランサー（ポート 6443 を利用しプライベートサブネット上のコントロールプレーンの VM をターゲットとする NLB）によっても使用されます。デフォルトでは、この NLB はパブリック IP を取得しますが、必要に応じてインターナる専用に変更することができます。

• NAT ゲートウェイとルーティングテーブルを備えたプライベートサブネットは、パブリックサブネットのインターネットゲートウェイを経由してインターネットに接続されます（イグレス専用接続）。
  • このサブネットは、コントロールプレーン（マスター）とデータプレーン（ワーカー）の両方の VM をホストし、専用のオートスケーリンググループ（それぞれが独自の起動設定と設定可能な容量を持つ）によって制御されます。

• インスタンスプロファイルを介してインスタンスにアタッチされた、マスター/ワーカー VM 用の IAM ポリシーとロール – デフォルトでは、マスターとワーカー VM の両方で EC2、ELBv2、ASG API を使用するようになっていますが必要に応じて変更できます。

デプロイメントの前提条件

オートデプロイメント・ワークフロー自体を実行する前に、1回限りの準備として、 zadara-examples GitHub リポジトリに記載されているように、関連するすべてのクラウド前提条件をカバーしていることを確認してください。

• VSC 対応の VolumeType API エイリアス（これは表示名ではないことに注意）を取得します。ほとんどの場合これはデプロイメントのデフォルト値である「gp2」になりますが、クラウド管理者に相談するかドキュメントで説明されているように Symp コマンドを実行してデフォルト値以外を検証することもできます。
  
  
  
• 関連するイメージをダウンロードします。デプロイには Ubuntu 22.04（bastion ホスト用）と利用予定の EKS-D バージョン（Kubernetes マスター＆ワーカーノード用）の AMI ID が必要です。もし、どちらもイメージリストにないのであればクラウドの Marketplace で見つけることができます。
  
  
  
  
• キーペアを作成するかアップロードします。これらは必要に応じて bastion、マスター、ワーカーの各 VM に SSH 接続するために使用されます（すべてのキーペアに同じ鍵ペアを使用することも、異なるキーペアを作成することもできます）。
  
  
  
  
• AWS 認証情報を作成します。アクセスキーとシークレットキーの両方を作成し、安全な場所に保存します。
  
  
  
  

少なくとも MemberFullAccess と IAMFullAccess の AWS 権限（または AdministratorAccess 若しくはそれ以上の AWS 権限）が必要になります。

デプロイワークフローを実行するには、Git と Terraform または OpenTofu がプリインストールされた Bash ベースの実行マシンが必要です。Zadara Toolbox イメージ（Marketplaceで入手可能）には Git と Terraform の両方が含まれているのでこのような目的で使用することもできます。

準備ができたら、zadara-examples リポジトリをクローンし、自動デプロイメントのワークフローを開始するために /k8s/eksd フォルダに移動してください。

デプロイメントワークフロー

ほとんどの場合、自動化された EKS-D デプロイを実行する最もシンプルな方法は All-in-One ラッパースクリプトになります。このスクリプトはいくつかの基本的なパラメータを設定するだけで、インフラストラクチャと EKS-D デプロイの両方の Terraform プロジェクトを実行してくれます。このスクリプトは次の章で説明するようにデフォルト以外の値も使用できますが、便宜上今回はそのまま実行します。

オートデプロイメントを実行するには、いくつかの基本的な手順を踏む必要があります。

1. terraform.tfvars.template ファイルをコピーし terraform.tfvars を作成
2. terraform.tfvars ファイルに、今回の環境に関連する情報を記入
3. apply-all.sh スクリプトを AWS 認証情報と共に実行

環境のセットアップを確認しましょう。

このコンフィギュレーションでは、以下の変数を設定しています。

• api_endpoint – デプロイメントを自身のクラウドのベース URL に向ける (プロジェクトは AWS 認証情報によって暗黙的に決定されることに注意)
• environment – 自身の Kubernetes クラスター名 (及びクラウドリソースのプレフィックス)
• bastion_keyname – Bastion VM のキーペア名
• bastion_keyfile – 実行マシン上の自身の秘密鍵ペアの場所
• bastion_ami – Ubuntu 22.04 の AMI ID
• bastion_user – Ubuntu 22.04 のユーザー名 (デフォルトのユーザー名は ubuntu)
• eksd_ami – コンピュートクラウドから入手した EKS-D の AMI ID
• masters_keyname – マスター VM 用のキーペア名
• masters_keyfile – マスター VM 用の自身の秘密鍵ファイルの場所
• workers_keyname – ワーカー VM 用のキーペア名
• workers_keyfile – ワーカー VM 用の自身の秘密鍵ファイルの場所

このデモでは便宜上同じキーペアを使用していますが、必要に応じて bastion、マスター、ワーカーの VM に異なるキーペアを使用しても構いません。また、秘密鍵ペアの位置は Terraform が要求する相対パスではなく、絶対パスでなければならないことに注意してください。

また、実行する前に、Ubuntu と EKS-D の両方のイメージが Compute クラウドのイメージリストに準備できている（クラウドへのアップロードが完了している）ことを確認してください。

すべての設定が完了したらユーザーの AWS 認証情報を引数として、あるいは自身の好きなように（セキュリティを高めるために）暗黙の環境変数として apply-all.sh スクリプトを実行することができる。

デフォルトのデプロイメント仕様の場合、スクリプトは約 10分間実行され、ユーザーに何もインタラクションも求めずに以下の処理を実行します。

1. インフラデプロイメントの Terraform プロジェクトを初期化して適用する（VPC、サブネット、NAT-GW、NLB などを作成する）。
2. Terraform の出力を使って NLB のパブリック IP を割り出す（Bastion VM 上で定義済みのスクリプトを実行する）。
3. EKS-D のデプロイメント Terraform プロジェクトを初期化して適用する（マスター/ワーカーの ASG、IAM ポリシー/ロールなどを作成する）。
4. Terraform の出力を使って、最初のマスター VM から最初の Kubernetes 管理ユーザのkubeconfig を取得する（Bastion VM から別の定義済みスクリプトを実行する）。

Kubeconfig ファイルを取得する最終フェーズでは、Kubernetes のコントロールプレーンがブートストラップを実行しているため、基本的な設定であれば数分（約20回のリトライラウンド）かかることに注意してください。最終結果は kubeconfig ファイルの出力で、作業ディレクトリにも保存されます。

この kubeconfig ファイルを使って、新しく作成した Kubernetes クラスタ上で kubectl（または他の Kubernetes クライアント、例えば k9s や OpenLens）を使って作業することができます。

CNI 以外の他のアドオンはすべて Helm を使ってデプロイされているので、必要に応じてアドオンをリストアップしたり、アップグレードしたり、操作したりすることができます。

これで期待通り、ゼロから 10分もかからずに Zadara クラウド上で完全に稼働する Kubernetes クラスタが完成しました！このクラスタを使用して実際の Kubernetes ワークロードを実行し、インストールされているすべてのアドオンを利用してシームレスなクラウドサービスの統合を行うことができます。

次回のブログポストでは、このような Zadara 上での Kubernetes 利用の主なユースケースについて説明します！