3個のパラメータでEKSクラスタをサクッと構築するクイックスタートの紹介
「そろそろ、EKS初めてみたいんだけれど、正直めんどくさそう…」
コンテナ界隈、特にKubernetes周辺の昨今の盛り上がりは凄いものがありますね。エライコッチャです。AWSにもマネージドKubernetesサービスとしてEKS(Amazon Elastic Container Service for Kubernetes)があるわけですが、先日、AWSよりEKSの導入をより簡単にするクイックスタートが新しく発表されました。
必須パラメータ3個で、いつでも簡単にEKS環境を構築することができます。公式マニュアルのGetting Started(Amazon EKS の使用開始)よりはるかに簡単なので、「まずはEKS体験してみたい!」という方は、本記事参考にしつつ最初の一歩を踏み出してもらえればと思います。
簡単EKSきたか…!! ( ゚д゚) ガタッ / ヾ __L| / ̄ ̄ ̄/_ \/ /
AWSのクイックスタートとは?
クイックスタートは、人気の高いテクノロジーの AWS へのデプロイを支援するために、AWS ソリューションアーキテクトおよびパートナーによって構築されたもので、セキュリティと高可用性に関する AWS のベストプラクティスに基づいています。これらのアクセラレーターは、手作業の何百もの手順をほんの数ステップに削減するため、本番環境やテスト環境を素早く構築して、すぐに使用を始めることができます。
雰囲気を掴むには、ページを眺めてみるのが一番ですが、AWSのベストプラクティスに基づいたいろんなユースケースに応じた構成を、手作業を省いて短時間で構築することができます。
単純に言えば、「CloudFormationを使って一発ドーンで、ベストプラクティスを手に入れる」という感じですね。
今回は、このクイックスタートにEKSが追加されました。マニュアルに記載があるGetting Started(Amazon EKS の使用開始)とは別なものです。
EKSのクイックスタートで構築されるアーキテクチャは?
Amazon EKS Architecture - Quick Start
(以下、画像は上記ページより引用してます)
最初にクイックスタートで構築されるアーキテクチャを理解しておきましょう。
- 3AZにまたがる高可用性構造
- AWSのベストプラクティスに基づいたパブリックサブネットとプライベートサブネットの2層構造
- パブリックサブネットにNATGatewayを配置し、プライベートサブネットからのアウトバウンド通信で利用
- パブリックサブネットにオートスケーリンググループ定義された、SSHアクセス可能な踏み台サーバを配置。踏み台サーバには
kubectl
をセッティング - EKSクラスターは、Kubernetesのコントロールプレーンを提供
- プライベートサブネットには、Kubernetesノードを配置
派手な構成ですね。EKSのコントロールプレーンは仕様でもともと3AZに冗長化されていますが、踏み台サーバもPodを配置するNodeも、それぞれのサブネットでオートスケーリンググループで3AZ利用しているのは、まさにベストプラクティス。
SSHアクセスできる踏み台サーバにはkubectlがセットアップされ、すぐにKubernetesの管理ができるのも魅力的。
アーキテクチャの全体像や構築手順。ClooudFormationの各種パラメータやトラブルFAQなどは、下記デプロイメントガイドに記載されているので、合わせて確認してみてください。
Modular and Scalable Amazon EKS Architecture
構築に関わる料金は?
クイックスタートページの「Cost and licenses」をクリックします。
ここでかかる料金ですが、AWS利用料で通常課金される以上のライセンスコストなどは発生しません。CloudFormationにももともと料金は発生しません。
この構成上の主な課金要素は以下のとおり。
- EKSクラスター(1時間あたり0.20USD)
- 1月あたり144USD
- 1日あたり5.76USD
- Kubernetesワーカーノード実行用のAWSリソース(EC2、EBS)
- デフォルトでt3.mediumが選択されているが、任意のインスタンスタイプに変更可能
- NatGateway(1AZあたり1つ、東京リージョン)
- 1月あたり44.64USD
- 1日あたり1.488USD
お試しや勉強目的でやるには、それなりに高価なので注意。
実際に構築してみる
それでは、実際にクイックスタートの内容で構築していきましょう
キーペアの作成
今回の構成では踏み台サーバにSSHでアクセスするため、事前にキーペアの作成が必要です。クイックスタート自体はオハイオリージョンでの構築がデフォルトなので、今回もオハイオリージョンでeks-quickstart-key
あたりの名前で、事前につくっておきましょう。
(注意:おそらく東京リージョンでも動作すると思いますが、トラブルシューティングに一定の知識が求められる可能性が高いので、その点は覚悟しておきましょう)
CloudFormationの実行
クイックスタートページの「How to deploy」をクリックし、デプロイ方法を確認。デプロイ方法は大きく分けて2種類あります。
- 新しいVPCにデプロイ
- CloudFormation - スタック create
- 既存のVPCにデプロイ
- CloudFormation - スタック create
今回はまっさらなところにデプロイしていきたいので、新しいVPCにデプロイを選択します。作成対象のAWSアカウントにログインした状態で、上のリンクをクリックします。
オハイオリージョンが選択された状態で、CloudFormationのスタック作成画面が表示されるので、「次へ」をクリック。
そうすると、スタックの詳細画面を指定する画面が表示されます。ある程度初期値が埋まっていますが、事前に指定必須なパラメータがあるので、そこだけ解説します。
- Avalilability Zones
- 構築対象のAZを選択
- とりあえず、3AZ選びます
- Allowed external access CIDR
- アクセス元として信頼できるIPアドレスレンジを指定
- 自分のクライアント環境のIPアドレスを指定しておきましょう(例:xx.yy.zz.xx/32)
- SSH key name
- 踏み台サーバ、およびNodeにSSHアクセスするためのキーを選択
- 前の手順で作成したキーペアを入力
とりあえず、自分で選択が必要なのはこの程度でしょう。他のパラメータの詳細な解説は、Modular and Scalable Amazon EKS Architectureに記載されています。
後は「次へ」「次へ」といき、最後にIAMリソースが作成されることに合意して、「スタックの作成」をクリック。
パラメーターに特に問題がなければ、スタックの詳細画面に遷移し、イベントが更新されながら各リソースが作成されていきます。お茶でも飲みながら待ちましょう。
私の場合は、だいたい20分ほどで全てのCloudFormationスタックの作成が完了しました。
kubectlコマンドでクラスタの状態を確認してみる
踏み台サーバにアクセスして、EKSクラスタを確認してみます。
CloudFormationのAmazon-EKS
スタックの出力にBastionIP
が表示されているので、このIPアドレスにSSHアクセスします。秘密鍵は、CloudFormation実行前に作成したeks-quickstart-key.pem
の想定です。
$ssh -i eks-quickstart-key.pem ec2-user@<BastionIP>
kubectl version
コマンドで無事、クラスターが認識されていればOKです。お手軽!!
$ kubectl version Client Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.5", GitCommit:"753b2dbc622f5cc417845f0ff8a77f539a4213ea", GitTreeState:"clean", BuildDate:"2018-12-06T01:33:57Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"11+", GitVersion:"v1.11.8-eks-7c34c0", GitCommit:"7c34c0d2f2d0f11f397d55a46945193a0e22d8f3", GitTreeState:"clean", BuildDate:"2019-03-01T22:49:39Z", GoVersion:"go1.10.8", Compiler:"gc", Platform:"linux/amd64"}
もちろん、Nodeも確認できます。CloudFormation実行時にパラメータとして3AZを指定しNode数を3と指定したため、3つのEC2インスタンスがNodeとして登録されています。
$ kubectl get nodes NAME STATUS ROLES AGE VERSION ip-10-0-53-76.us-east-2.compute.internal Ready <none> 1h v1.11.5 ip-10-0-6-12.us-east-2.compute.internal Ready <none> 1h v1.11.5 ip-10-0-93-124.us-east-2.compute.internal Ready <none> 1h v1.11.5
もちろん、Namespace
も登録されています。
$ kubectl get namespace NAME STATUS AGE default Active 1h kube-public Active 1h kube-system Active 1h
あとは、思う存分EKSなりKubernetesを堪能すれば良いと思います!
作成した環境を削除するには
十分に堪能してた後、EKS環境一式を削除したい場合は、CloudFormationのAmazon-EKS
スタックを削除するだけで、全部のリソースが削除されます。環境削除が一瞬で終わるのも、CloudFormationで環境を作ることのメリットですね。素晴らしい!
AWSクイックスタートでEKSを始めるメリット3点
EKSクラスタの環境構築が圧倒的に簡単
以前、EKSがGA(一般公開)されたときに、このような記事を書きました。
【まずは触って体験】リリース直後のAmazon EKSでサンプルアプリケーションを動かしてみた | DevelopersIO
上の手順ベースでEKS環境を作るのもよいのですが、以下の手順を個別にやる必要があり手順もそれなりに細かいので、時間がかかります。ちょっと手順間違うと、まぁまぁハマります。正直Kuberenetes初心者にはこれでもそれなりにハードルが高い手順かと思います。
- EKSクラスターの作成
- kubectlの個別設定
- EKSワーカーノードの起動と設定
クイックスタートの新VPCでの構築であれば、、CloudFormationに必須パラメータ3つを渡すだけで、あとはよしなにEKSクラスターの作成、kubectlの踏み台サーバへのセットアップ、EKSワーカーノードの作成全てやってくれるので非常に手間が省けます。
ある程度のEKSクラスタのチューニングはパラメーターで設定可能
このクイックスタートですが、パラメータ周辺も非常に良くできていて、ある程度のカスタマイズはパラメータを変えてあげるだけで設定できます。デプロイメントガイドに詳細が記載されていますが、上で説明した必須パラメータ以外に、以下の設定が変更可能です。
- Nodeのインスタンスタイプ
- デフォルト:t3.medium
- Nodeのグループ名
- デフォルト:default
- Nodeの数
- デフォルト:3
- Nodeのボリュームサイズ
- デフォルト:20GB
検証や学習用途で使う場合、EKSクラスターの価格以外にワーカーノードも課金も気になるところですが、インスタンスタイプやNodeの数を変更してセットアップできるのは、柔軟性があって心強いです。自分もコマンドの確認用途だけで使う場合は、インスタンスタイプをt3.micro
、Nodeの数を1
で動かしています。
さらなるカスタマイズはLambdaによるカスタムリソースの編集で可能
このクイックスタートでは、KubernetesベースのアプリケーションをCloudFormationで構築するために、Lambdaを利用することが可能です。ソースコードもこちら(quickstart-amazon-eks/example-workload.template.yaml at master · aws-quickstart/quickstart-amazon-eks)で公開されているので、気になる方は中身を参照しながらカスタマイズをすることが可能です。
導入の敷居が高いEKSについて確実に動くものを作ってから試すのに最適
クイックスタートを使うことの一番のデメリットは、「なにが出来上がったのか、なにをやったのかわかりにくい…」というところですね。最小のオペレーションで作成されるため、各Nodeがどうやって構成されたか、EKSのセットアップに何が必要なのか、という部分はクイックスタートだけではわかりません。
ただ、確実に動くものを作るのは非常に簡単です。最初に環境を作るトラブルは最短距離で実施することで回避し、一旦作ってしまった後に、各種設定内容やNodeのAutoScaling内容を確認したり、それら値をカスタマイズすることで理解も深まります。
クラウド上でのKubernetes体験であるEKSに踏み出す際ことが敷居高く感じる人も多いと思いますが、今回紹介したクイックスタートは、Kubernetesのコマンド体系を学習しながら、AWSマネージドサービスとの連携を学ぶ環境を作るには最適かと思いますので、一度試してみてはいかがでしょうか。
それでは、今日はこのへんで。濱田(@hamako9999)でした。