seminar/2020/10/24/1100_K8s運用事例 - 豚吐露＠wiki

【MTG】K8s運用経験2年のOps担当が質問に答えます／水野 源(日本仮想化技術株式会社)

2020-10-24(土) 11:00～11:45

なぜコンテナ？
→ベアメタルを選択しない理由
上位分離可能
→アプリ、ミドルウェア、OS
Devがやりたいこと vs Opsの事情
→アプリケーション実行環境のカプセル化ができる
　→責任分界点が作れる
→コンテナ使ってみたかったってのも一因

WF失敗→アジャイル→スクラム

DBがネック
→スケールアップで対応しきれなくなったらどうしよう...

IPとノードポートは勝手に関連付けられる
→ノードはプライベートサブネットに配置
　→外部接続はすべてロードバランサ経由

ワーカーノードセキュリティグループ
→中の者同士の通信は許容される

■事例

タブレット用アプリのバックエンド
ユーザ数3万over
同時接続1000
サーバサイド環境のインフラ設計、構築。運用
CI/CD環境の設定、運用
監視システムの設定運用

AWS→AWS EKS
CircleCI
コンフィグ：CloudFormation
モニタリング：Datadog

Podは死ぬのが前提
→複数のPodがあれば、一つ死んでも問題にならない。
　→しばらくしたら他のPodが起動する
ロードバランサ
ingress
→ipのrouteが公開される
→ingressは設定、一緒に入るingress ctrlerがingressを見てロードバランスを構築する

route53
→external-dns：このpodはこのipでアクセスしたいをroute53に登録してくれる

k8sを自前で管理するのは辛い
→外部サービスへオフロード
→外部サービスEKS使っても辛い
　→3ヶ月ごとにupdate
　　→インフラ担当からしたら辛いのは変わらん
→CloudFormationだけではカバーできない部分もあった
　→クラスタ修正：作り直し
→CI、監視に外部CircleCIやDatadogを採用したのは正解

k8sは万能ではない

AWS→ECR ECS Fargate

ノードの管理をk8sに任すのは次の案件でも使いたい

クラスタノードグループ：リソースを振り分けることができる
→このグループはCPUすごい、こっちはメモリすごい的な

Fargate ECR vs EC2
Fargate
→Podが動くインスタンスを管理しなくて良い
→パフォーマンスを管理できない
→特定のノードに集中して起動するということが起こりうる
→揮発性のjobだとfargateは楽
EC2
→EC2ならCPU数などリソース管理ができる
　→反面、podをどう配置するか？という課題も出てくる

---

更新日： 2020年10月25日 (日) 11時27分46秒