既存のEKSクラスタにterraformでFargateのPodを導入する際に、ハマったところを紹介します。
TL;DR
クラスタセキュリティグループ の設定を見直しましょう。
mapRoleへの付与漏れ
Farage導入においては以下の記事がわかりやすいのですが、書いてあるとおりfargate profileを生成すると自動でmapRoleに pod execution roleが入ります。
しかし、terraformで導入していてmapRoleもterraformで管理していると、
- terraformでfargate profileを作成
- aws側がmapRoleにpod execution roleの権限を追加
- terraformに記載されているmapRoleで上書き
となってしまい、mapRoleが消えてしまいます。
この事象が発生しているかは、 $ kubectl get event で Unauthorized 的な文言が出ているとmapRoleの付与漏れです。
fargate Podが起動しない
Podは作成されるけれど、以下のようなログを吐きfargateのノードが立ち上がらない問題が発生しました。
$ kubectl describe pod xxx のEventsで吐かれていました。
Warning FailedScheduling 55m fargate-scheduler Pod provisioning timed out (will retry) for pod
AWSのサポートに問い合わせてコントロールプレーン側のログを見てもらっても何も出ていませんでした。
結果としては、クラスタセキュリティグループのアウトバウンドがなぜか消えていたからでした。
fargateのノードはクラスタセキュリティグループがノードのセキュリティグループとして評価されるので、これのインバウンドとアウトバウンドはしっかり設定する必要があります。
EKS生成時に作られるクラスタセキュリティグループに対しては最低でも以下を許可する必要があります terraformで記載します
ingress {
from_port = 0
to_port = 0
protocol = "-1"
self = true
}
egress {
from_port = 0
to_port = 0
protocol = "-1"
cidr_blocks = ["0.0.0.0/0"]
}
クラスタセキュリティグループ
上の節でも紹介しましたが、fargateはクラスタセキュリティグループがノード（Pod）のセキュリティグループとして評価されます。 なので、ALBなどからつなぐにはクラスタセキュリティグループに対してALBのセキュリティグループを許可する必要があります。
EKSのネットワーク設定にある追加のセキュリティグループに設定されていても、そこはfargateでは評価されないので注意が必要です。
他にもクラスタ上の別のノードと通信するためにはfargateのクラスタセキュリティグループを許可させるために付与する必要があります。
kube-systemなど各ノードに散らばりがちなpodに対して通信するためには、クラスタセキュリティグループは全ノードに付与しておいたほうがおすすめです。
またfargateのpodを運用する場合、色々なセキュリティグループを随時許可する必要が出ると思うので、
terraformで運用する場合はクラスタセキュリティグループを terraform import しておいたほうがいいでしょう。
まとめ
fargateでのハマりどころは、ほぼ クラスタセキュリティグループ と言っていいかもしれません。 そこさえ気をつければ、他のハマりどころは少ないと思います。
