Amazon EKSとTerraformを組み合わせたとある事例

これは、Amazon EKS Advent Calendar 2019 6日目の記事です。 現在関わっているプロジェクトにおいて進行中のKubernetes移行で取り入れた技術や方法について、少し紹介したいと思います。 現状の構成がベストプラクティスであるということではなく、試行錯誤した結果の途中経過となりますが、何らかのヒントになれば幸いです。

前提

• Amazon EKS 1.14
• ワーカーノードはEC2（Fargateではない）
• IaCはTerraform 0.12系を使う

Terraformでどこまで適用するか

はじめ、EKSクラスタについてはAWS CLIでの構築を考えていました。その理由としては、

• Terraformの適用環境はCodeBuildである（IAMロールを使う）
• kubectl実行環境は別にある（EC2+SessionManager+SSHの踏み台的な環境）

という前提で、kubectlの実行環境でクラスタを作成したほうがaws-authのConfigMapの適用で考えることが少なくて済む、という考えがありました。

しかし、現在はTerraformで管理する対象を増やしています。大きな理由としては、

• アプリケーションをデプロイする手前までの環境は自動化したい

というところです。

Terraformで適用するリソース

AWS Providerを使う

• EKSクラスタ
• ワーカーノード
  • Auto Scaling Group
  • Security Group
  • IAM Role

Kubernetes Providerを使う

https://www.terraform.io/docs/providers/kubernetes/index.html

• ConfigMap: aws-auth
• Helm
  • Service Account
  • Cluster Role Binding
• External DNS
  • Service Account
  • Cluster Role
  • Cluster Role Binding
  • Deployment

Helm Providerを使う

https://www.terraform.io/docs/providers/helm/index.html

• Helm Chart
  • kube-state-metrics
  • argocd
  • newrelic-infrastructure
  • aws-alb-ingress-controller
  • sealed-secrets

（できたらContainer Insights on Amazon EKSもHelmで導入したい…!）

これらを一通りTerraformで、 AWS modulesを活用しつつ構築することで、アプリケーション側のデプロイに専念できる形にする、というのが現時点での答えとなっています。

Kustomizeの利用

アプリケーションのマニフェストをdev/staging/productionといった環境ごとに重複しない形で管理できるようにKustomizeを利用しています。

デプロイ

デプロイはArgoCDを選定しています。

Argo CD - Declarative GitOps CD for Kubernetes https://argoproj.github.io/argo-cd/

これがベストかどうかはまだわかりませんが、利用事例の多さ、開発の頻度、Helmで一発で導入できること、Kustomizeへの対応、見やすいWebUIなどが魅力的だと感じています。

まだ確定はしていませんが、ECRへのイメージプッシュからLambdaを起動して、argocdのCLIからプッシュされたイメージのタグを指定してデプロイする方法（GitOps）が良さそうだと考えています。

Parameter Overrides https://argoproj.github.io/argo-cd/user-guide/parameters/

おわりに

とても簡単な解説にはなりますが、以上の組み合わせでKubernetesまわりの環境を構築しています（しようとしています）。 ここはどうなっているの？という質問や疑問がありましたら、Twitter @isaoshimizu まで優しくお気軽にメンションしていただけたら、こちらとしても大変ありがたい限りです。