EKS 運用お困り事例紹介 に参加しました。簡単に所感をまとめます。
所感
どういうメトリクスをどう見るかみたいなところは各社のサービスやそのシステムの特性によって違うんだろうと思います。試行錯誤の結果なのでまさにノウハウの塊。ただ、最後のパネルディスカッションでも言ってたけど、独自の設定や環境になりやすいのが確かにネックなのかもしれない。なるほど。
マルチアーキテクチャに関しては Graviton とかの名前は聞いたことあったけど詳しくないのであまり理解できず...。というか、k8s や EKS 関連はまだまだ知らないことが多いのでインプットしないと...。
以下、メモから抜粋。
Pod のオートスケーリングに苦戦し続けている話
- オートスケーリング
- コスト最適化
- ユーザー体験に影響を与えないことが大前提
- 減らしすぎ注意
- HPA
- Webサーバー
- ユーザーリクエストを直接受ける
- 遅延は許容されない
- ジョブワーカー
- 非同期ジョブ実行
- 多少の遅延は許容される
- サービス負荷とは関係ない要因でCPU利用率が下がる
- KEDA
- Prometheus で収集したメトリクスをもとに HPA に反映する
- メトリクス
- ジョブキューの長さ
- 待機中のジョブ数
- ジョブの滞留数に連動してPod数が安定しない
- ワーカー稼働率
- ジョブワーカーのプロセスのうちジョブを処理しているプロセスの割合
- ワーカー稼働率が80%になるように調整する
- 補正付きワーカー稼働率
- ジョブが滞留している場合に重みを掛ける
Argo Workflows のバージョンアップで困った話
- Argo Workflows
- archiveLabelSelector
- archive-strategy
- あるラベルが付与されている場合のみアーカイブを残す
マルチCPUアーキテクチャ構成の実現に向けて
- AWSのコストが高い
- Graviton アーキテクチャ (arm64)
- Priority based expander
- spot 優先利用
- spot が枯渇した場合は ondemand にフォールバックさせる
- x86/arm64 両アーキテクチャを使えるようにして枯渇リスクを下げる
- マルチアーキテクチャ対応
- Karpenter
EKS の運用で困ってたり悩んでたりする話
- EKSバージョンアップ
- Kubernetes External Secrets → External Secrets Operator
- Kustomize
- argocd
- argocd-cm plugins 機能廃止
- IaC
- EKSクラスタ自体をコード管理したい
- サードパーティ製品の組み合わせ
- 内部の異常をどう検知するか
- 何を監視したら異常を検知できるか
パネルディスカッション
- EKS
- エコシステム/コミュニティが活発
- ECSはAWSに縛られる
- デファクトスタンダードをAWSに任せられる
- EKSは自分たちの力量が試される (独自環境が作られやすい)
- AWSとの親和性
- オートスケールによるコスト最適化
- EKS fargate
- 対応していない機能がある
- コスト最適化
- spot
- オートスケール/夜間縮退
- インスタンスあたりのCPU/メモリをちゃんと使い切れるように
- ECS/EKS
- 複雑なシステムはEKSが向いてそう
- EKSはバージョンアップコストがネック
- コストがかけられないならECSの方が無難
あとで読む。
