Member-only story
OperationCodeでのKubernetesインフラストラクチャのリファクタリング（後半）
OperationCodeでのKubernetesインフラストラクチャのリファクタリングに関する記事です。長い記事なので前半と後半に分けてお送りします。今回は後半の最終章です。新しいクラスタの生成などどについて見ていきます。
Part 3: Building out the new cluster
eksctl のおかげで、新しい EKS クラスタの構築が信じられないほど簡単になりました。コンフィグファイルを利用することで Infrastructure as Code を実践できたことに感謝しています。また、eksctl は本当に便利な eksctl utils write-kubeconfig を提供してくれるので、新規ユーザーの登録が信じられないほど簡単になりました。
クラスタを構築した後（これには実質的に全く時間がかかりませんでした！）、AWSのドキュメントでは以下のコンポーネントをインストールすることを推奨しています。
これらは、external-dnsを除いて、指示に従って設定するのは比較的簡単でした。提供されているコンフィギュレーション例は、古いイメージを指しており、残念ながらexternal-dnsのドキュメントは、Fargate内で動作させる方法についてのガイダンスについては触れられていませんでした。いくつかの実験を行い、 Kubernetes slack (#eks チャンネル) の親切な人たちの助けを借りて、外部 DNS 用のロールを作成するために eksctl create iamserviceaccount コマンドを使い、その後 eks.amazonaws.com/role-arn アノテーションを使って kubernetes サービスアカウントを IAM ロール (コードはこちら)にマッピングする必要があることが分かりました。
最終的に私たちはk8s上で動作するバックエンドサービスの継続的なデリバリに Argo CDを使用しているので、それをデプロイすることが重要でした。知られているEKS+Fargateの制限の一つは、持続的なボリュームクレームに対応していないことです。私は、ポッドが循環するたびにArgoがすべてのデータを失うことがないように、クラスタに1つのt3a.mediumノードを追加することにしました :)
ArgoのHAインストールテンプレート(これは私たちにとってはやりすぎでした)を使う代わりに、クイックスタートテンプレートのRedisサーバセクションを、永続的なボリュームクレーム(ここにコードを書いてあります)を持つStatefulSe…
