はじめに
これは、Amazon EKS Advent Calendar 2019 5日目の記事です。
今回は、Amazon EKSをサクッと使おうと思ったら思いの外ハマったことを振り返りつつシェアしようと思います。
EKS on Fargateについて知りたい方はこちらも合わせてどうぞ！
ハマったこと
1. 構成管理に使うべきツールの正解がわからない
EKSを構築、運用する上で構成管理のコストは無視できない概念です。何より、日々の運用が大変なものは選びたくありません。
今年の10月にこちらのアナウンスで公式ツールに採用された今、特に大きな理由がない限りはeksctlを使っておけば安牌のように思います。
EKSの技術選定をしていたのは今年の夏頃なのですが、当時はeksctlは公式のツールではなくサードパーティのツールとして提供されていました。この時点でEKSの構成管理を行うには大きく分けて3種類の方法がありました。
| 方法 | メリット | デメリット | 備考 |
|---|---|---|---|
| Terraform | 既存の技術スタックを使い回せる(チームでGCPメインでやってる) | OSSベースなのでコントリビューターの頑張りに左右される 初期の構築コストが高い |
|
| CloudFormation | AWS公式の構成管理ツール、SecretsManagerなどが使いやすい、eksctlで吐き出したYAMLを使い回すことも可能 | Terraformよりも記述量が少し多かった AWS専用の技術スタック |
|
| eksctl | とにかく初期構築コストが低い(体感、GKE + Terraformくらい楽) | いろいろ抽象化される分自分でいじるのが難しい (当時は)公式ツールではなかったのでOSSコントリビューターの頑張りに左右される EKSでしか使わない概念、CLIベースなので宣言的に扱えない部分がある |
eksctlは内部的にCloudFormationとkubectlを呼び出している |
eksctlは当時から非常に魅力的な選択肢だったのですが、やはり抽象化されすぎている印象が拭えず踏み切れないまま、このときは一旦Terraformで動かし始めることにしました。
2. Kubernetes以外に知らないといけないことが多すぎる
さて、eksctlを使わないので、EKSを構築する上で知らないといけない多くのことをノウハウとして蓄積する必要があります。
i. IAMポリシーが大変
甘えといえば甘えですが、AWSの柔軟かつ自由度の高いIAMは、裏を返すと検証コストの高い存在でもあります。
逃げ道はなく、基本的にはがんばるしかありませんでした。しかしeksctlのプリセットを読み込むことで自分たちの実現したいポリシーに必要なものを理解することができたのは良かったかなと思います(本来そういう使い方をすべきではないのはそうなんですが)。
ii. VPCやサブネットへのタグ付けなど、とにかく制約条件が多い
AWS的にそういう実装をするほうが黒魔術にならないんだろうなというのは理解しつつも、タグつけるのかぁ。。。みたいな感じで初期構築のトラシューが結構たいへんだった記憶があります。
このへんをやっていると、AWSが難しいのかEKSが難しいのかKubernetesが難しいのかよくわからなくなってきます。
Ref: 公式ドキュメント
iii. クラスター作成時にRBACのAdminの指定ができない(CloudFormationを作成したロールが管理者になる)
Issueも作ったんですが、クラスター作成時に「このロールの人にkubectl叩ける権限をあげてください」という指定ができるようになってほしいです。
CloudFormationのスタックを作成する権限を使ってしまうと多くの場合Adminレベルの強い権限を渡さないといけないため、スコープとしてKubernetesクラスターの管理をするには強すぎる権限を一時的にでも与えることになってしまいます。
正直いい状態とは言えないので、改善されると良いなあと思っています。
3. ワーカーノード追加するためには実質EC2ノードを自分たちで管理しないといけなかった(過去形)
マネージドノードグループが追加されたので今はこの必要はありません。端的に言ってこの追加は神だったと思います！！！！
Before: https://gist.github.com/inductor/83b2b14fdf0893cfd417ab66b951f199
After: https://gist.github.com/inductor/2959e397a59be756ba8b6afab0db0a81
多少ポリシーは色々違いますが記述量が全く違いますよね・・・。
EKS on Fargate
Containers Roadmapが立ち上がってから比較的昔からずっと要望があったこちらのIssueがついにCloseされました。神。
eksctlも既にFargate対応済み版が出ており、とてもいい感じ! homebrewでも公開されていました！
Ref: https://github.com/weaveworks/eksctl/releases/tag/0.11.0
EKS on Fargateについてはたくさん書きたいことがありましたが@amsy810氏のブログに詳しく書かれているのでまあいいか、という感じです。
現状だとまだCLB/NLBに対応していないのと、eksctlにattachPolicyARNsがほしいなと個人的には思いました。
https://github.com/weaveworks/eksctl/issues/1631
Feature request、Issueなどは積極的に作っていきましょう！！！
4. eksctl(CloudFormation+Kubernetes YAML)を使ったとしても初期構築のいずれかの部分は命令的にやらないといけない部分がある
先日のアナウンスを踏まえてeksctlを見直しているのですが、まだいくつかクラスター管理において課題に感じていることがあります。
課題: どうせなら全部宣言的に構成管理をしたい
クラスター作成からアプリケーションの最も基本的なYAMLを流すまでの流れを全部Declarativeにやりたい（クラスター構築して引き渡すまでを全部自動化したい）のですが、現状権限周りや初期の部分で一部命令的に実行する必要のある箇所があってGitOpsなどを使ったクラスター自体の管理とアプリケーション自体の管理を始めるまでに少し手数があります。
具体的な方法: https://www.weave.works/blog/automate-eks-cluster-configuration-with-gitops-and-eksctl
解決策は？
ノードグループの管理まで全部含めて宣言的に管理したいなあ、具体的にはeksctlにもapply句が増えてくれればCRUDの忖度がいらないので便利になるだろうな、と思っています。
KubeConのときにWeaveworksの人にそういう話をしたら、わかるけどEKS側でAPI増やしてくれないと厳しい、と言われました。AWSさんお願いします