BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース Blue Matadorが実施した、自己管理型KubernetesからTerraformを使ったAWS EKSへのマイグレーション

Blue Matadorが実施した、自己管理型KubernetesからTerraformを使ったAWS EKSへのマイグレーション

ブックマーク

原文(投稿日:2019/06/08)へのリンク

Blue Matadorは、さまざまな機能比較を行った結果、同社のKubernetesインフラストラクチャを、AWSインスタンス上のkopsで管理するクラスタから、AWSのマネージドKubernetesサービスであるEKS移行した。同社では、より優れたセキュリティモデル、管理されたコントロールプレーン、特定のユースケースにおける低コストを理由として、EKSを選択したのだ。Kubernetesクラスタの新規セットアップ作業に関してはkopsが優位だったが、EKSはクラスタ管理とセキュリティにおいて、より高いスコアを獲得した。InfoQでは、Blue MatadorのソフトウェアエンジニアであるKeilan Jackson氏にコンタクトを取って、同社の経験について詳しく聞くことにした。

マイグレーションの大きな理由は、EKSの共有責任モデルと、管理されたコントロールプレーンにあった。移行前のBlue Matadorチームは、3つのc4.large AWSインスタンス上で、自身のKubernetesマスタノードを運用していた。Kubernetesのアップグレード(機能、バグ修正、セキュリティパッチすべて)はチームの責任だった。インフラストラクチャがAWS内にあることから、セキュリティレイヤについてはAWSが提供していたが、Kubernetes固有のセキュリティ問題は自分たちで管理しなければならなかった。 プライベートネットワーク、暗号化されたルートボリューム、セキュリティグループコントロールなどのリソースに関しては、"kopsで作成したKubernetesクラスタは、デフォルトでEKSと非常によく似た設定になっています"と、Jackson氏は記している。EKSを使用して新しいクラスタを設定するためには準備作業が必要だが、初期設定が完了してしまえば、クラスタの管理は以前より容易になった。

Blue Matadorでは、主にTerraformを使ってAWSリソースを管理している。Terraformには、クラウドプロバイダに対応した多数のリソースタイプ実装があるが、実際の運用では課題もある。Jackson氏は、氏らが直面したEKS固有の課題について話してくれた。

コミュニティが作成したEKSモジュールを、可能な限り活用しようとしました。私が抱えていた主な問題は、AWSプロバイダとTerraformの古いバージョンを使用していたことでした。そのため、このモジュールからメインALBやRDSインスタンスなど、外部の管理リソースに管理リソースを接続するとが難しかったのです。EKSを構成したモジュールから、いくつかのテラフォーム変数を出力して、次のように他モジュールから参照できるようにしておくことをお勧めします。

output "worker_role_arn" {
    value = "${module.eks_cluster.worker_iam_role_arn}"
}
 

TerraformはEKSクラスタの生成と管理が可能だが、後者については、結合の必要な周辺リソースに依存する。Jackson氏が詳しく説明している。

EKSの実行には、EKSクラスタ自体の他にも多くのリソースが必要です。ワーカノード、セキュリティグループ、VPCネットワーキングを構成する必要がありますし、EKSがKubernetesの新バージョンをサポートしている場合には更新計画も必要になります。これら重要なリソースの多くを正しく接続するためには、コミュニティモジュールを可能な限り使用することが必須ですが、セキュリティ上のニーズに対して、設定を再確認することは忘れないでください。例えば、セキュリティグループが必要とするものに対してのみ開かれていること、ワーカノードがパブリックIPアドレスを取得しないこと、ルートデバイスに暗号化されたAMIを使用していることを確認してください。

クラスタの規模について、Jackson氏は、"クラスタの合計サイズは、kopsクラスタで3つより多くのマスタが必要となるポイントには達していませんが、必要な場合に簡単かつ短期間でスケールアップできることや、Kubernetesの新バージョンのリリース時にバージョンアップ可能であることは非常に重要です"、と述べている。

マネージドKubernetesサービスは、そのプラットフォームの監視ソリューションに統合されているのが一般的だ。Jackson氏らがどのようにクラスタを監視しているか、氏は次のように説明している。

Kubernetesクラスタ上でのアラートの送信は、主として自社製品のBlue Matadorに頼っています。異常なデプロイメント、重要なノードイベント、ポッドのメモリ不足などを検出してくれるので、クラスタの使用率の把握に役立っています。Datadogも使用しますが、いくつかのカスタムメトリックをグラフ化するためのみです。Amazon EKSのCloudWatch Container Insightsには注目していますが、一般的にCloudWatchはKubernetesにとって十分に動的ではないため、運用上のアラートには使用しないと思います。

移行によって、チームのインフラストラクチャと監視のコストも削減されている。

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

BT