EKSの運用で困ってたり悩んでたりする話.pdf

Transcript

1. アソビュー株式会社 EKSの運用で困ってたり悩んでたりする話
 SRE
 鈴木剛志(@takesuzu90)

2. © ASOVIEW Inc. 2 About Me Name :　鈴木剛志（すずきたけし） Company：アソビュー株式会社 SRE (Service SREマネージャ) @takesuzu90 2022年3月にアソビューに入社。入社以来、 SREチームで仕事してます。守備範囲はアソ ビュー！というサイトのインフラの各種面倒を見る感じです。最近は、可用性関連、各種ミ ドルやインフラのバージョンアップ、セキュリティ周りの運用改善を行っています。 前職は、ワークスアプリケーションズで開発・運用・導入など幅広く仕事をしながら最終的 にはインフラ関連の仕事を多くするようになっていきました。
3. © ASOVIEW Inc. 3 最近の対外的活動
 最近、findy-toolsにてシステム運用について寄稿しました！ 
 
 
 
 
 
 
 
 
 
 https://findy-tools.io/articles/asoview-sre/21
 

4. © ASOVIEW Inc. 4 本日お話すること
 
 EKS運用で困っていたり悩んでいる話 
 • EKSのバージョンアップで困った（大変だった）話 
 • IaC周りで困っている話
 • 内部の異常の検知に困っている話 

5. © ASOVIEW Inc. 5 EKSのバージョンアップで困った（大変だった）話
6. © ASOVIEW Inc. 6 EKSのバージョンアップで困った話
 バージョンアップで仕様がよく変わる（ EKS 1.24）
 EKS 1.24　dockershimが廃止されcontainerdの移行が必須化 　　 →ログのフォーマットが大幅に変わり fluentdでログが解釈できなくなり、結果、ログが解析できないエラーが発生し て、そのログも解析できないでエラーみたいなことが発生して、無限再起エラーとなり、 Datadogに送信してたログ量 がとんでもないことになり、請求額も爆発してしまった。 →DatadogのAgentのやりとり部分についても変更が必要になり、 Unix ドメインソケットを介してやり取りするように変 更する必要があった。 ブログ：EKS1.24にバージョンアップした時に発生した各種問題について https://tech.asoview.co.jp/entry/2023/02/10/134922
7. © ASOVIEW Inc. 7 EKSのバージョンアップで困った話
 バージョンアップで仕様がよく変わる（ EKS 1.25）
 Apiの廃止対応 　　 APIの廃止に伴う対応が結構大変。機械的な変更だったりするものもありますが、一通り変更して動作確認というよう なものが必要になるので地味に大変だったりします。 Kubernetes External Secretをもともと利用してたのですが、もともと、終了していたプロジェクトも APIの廃止に伴い、 継続利用ができなくなっていったので、 External Secrets Operatorに置き換えていきました。 こちらも、全体的に利用してたので、一括の置換作業がとても大変でした。 その後、 kustomizeを利用した Template対応を行うことにより、修正を Template側でできるように改善したりして ます。
8. © ASOVIEW Inc. 8 EKSのバージョンアップで困った話
 バージョンアップで仕様がよく変わる（ EKS 1.28）
 ArgoCDもEKSに応じたサポートバージョンと いうのがあります。 Argocd 2.8でkustomizeのargocd-cm plugins機能の 廃止があり、こちらもマイグレーションガイドに 従って同じように動作するようにマイグレーションが 発生しました。 結構、デバッグしにくかったりして、うまく動作せず にいろいろと苦労した部分です。
9. © ASOVIEW Inc. 9 IaC周りで困っている話
10. © ASOVIEW Inc. 10 IaC周りで困っている話
 EKSクラスタ自体の管理
 EKSはセットアップする際には、 eksctlというコマンドラインで実施する手順がドキュメント上では公開されています。 最近、RedashをEKSに乗せることになり、検討の結果 PostgreSQLはEKS内部に持つことにしたため、 • aws-ebs-csi-driverのアップグレード • snapshot-controllerのインストール などを実施する必要がでてきたのですが、ここらへんコード管理はうまくできておらず、手作業＋ Shellの管理みたいな 感じになってしまってます。 一方でEKSに乗せる側のアプリケーションは、 ArgoCdを使ってコード管理ができているので、そこは非常にやりやす い部分です。
11. © ASOVIEW Inc. 11 IaC周りで困っている話
 現在の管理方法
 基本的には、yaml＋Shell+Terraformみたいな感じで管理しています。 terraform: 　IAM系やロールの管理・セキュリティグループ yaml : 　Eksクラスタの構成をYamlで管理 shell: 適用時やクラスタバージョンアップ時の手順を Shellで管理
12. © ASOVIEW Inc. 12 内部の異常の検知に困っている話 219.123.237.162
13. © ASOVIEW Inc. 13 内部の異常の検知に困っている話
 前提：いろいろな3rd partyの製品を組み合わせて構築されている 
 • Argo CD • Argo Workflows • Argo Rollouts • cluster autoscaler • fluentd • aws guard duty • datadog • etc それぞれのログについて何を監視すると異常に気付けるのかとかがあまり理解してないまま運用してしまっていま す。 冒頭にあったfluentdとかも実際にテスト環境で異常にリアルタイムで気付けてないという課題が有りました。 現在もまだ、運用しながら適切な監視項目を追加していくという日々が続いています。
14. © ASOVIEW Inc. 14 内部の異常の検知に困っている話
 問題が発生した後に検知が足りないと気づいて追加したエラーの例 
 • HPAに利用してる datadogmetricsの取得失敗を検知するようにした • ログの量のスパイクを監視して、通常の量を超えた場合には警告を通知するようにした。 • kubernetes上でout of memoryが発生して PodがKillされたときに通知を追加した。 などなど。
15. © ASOVIEW Inc. 15 サービスアカウントをDefault利用をやめようとしてハマった話
 kubernetes上のServiceAccountを設定して、検証が終わったのでもとに戻したときには まりました。
 Argo CDを利用しているので、 yaml上にServiceAccountの作成と割当を一緒に書いて GitにPushして、検証が終わっ たのでもとに戻したら、動きがおかしくなってました。 エラーを見ると 2247 FailedCreate: Error creating: pods "XXXXXx" is forbidden: error looking up service account XXXXX/XXXXXXX: serviceaccount "XXXXXXXX" not found という文字があり、状況が理解できました。 普段あまり見てない部分だったので、気付くのに遅れてしまいました。
16. © ASOVIEW Inc. 16 サービスアカウントをDefault利用をやめようとしてハマった話
 kubernetes上のServiceAccountを設定して、検証が終わったのでもとに戻したときには まりました。
 内部的には、ArgoCDでは下記の動きになっていた 最初：何も書いてない →defaultが使われた 設定後：ServiceAccountを明示的に書いた(sa_name)→明示的に書いたもの sa_nameが利用された 最初の状態に戻す：何も書いてない →直前の状態（明示的に書いたもの sa_name）が利用されている 設定検証後にRevertしてGitにPushしたら最初の状態に戻ることを期待してましたが、 YamlがDefault値に依存した記述になっていた場合にはもとに戻らないことがありそう。 ここらへんは、結構、ハマりどころかなと思ってます。 xxxx.yaml spec: serviceAccountName: < app_name > //ここを行追加するイメージ terminationGracePeriodSeconds: < termination_grace_period_seconds 40 >
17. 生きるに、遊びを。