概要
日時：2023/01/19(Thu) 19:00~20:15
https://findy.connpass.com/event/269803/
スピーカー
- サイバーエージェント：青山さん
- Ubie：坂田さん
メモ
コメント欄から知ったサービス
GKE Autopilot
https://cloud.google.com/kubernetes-engine/docs/concepts/autopilot-overview?hl=ja
話すこと/話さないこと
話すこと
- Kubernetesの導入タイミングや運用方法
- 運用における課題
- よくある失敗ポイント
話さないこと
- 具体的な実装方法
- 詳細なツールの使い方
Kubernetesとは
Kubernetesは、宣言的な構成管理と自動化を促進し、コンテナ化されたワークロードやサービスを管理するための、ポータブルで拡張性のあるオープンソースのプラットフォームです。Kubernetesは巨大で急速に成長しているエコシステムを備えており、それらのサービス、サポート、ツールは幅広い形で利用可能です。
検討のタイミング(青山さん)
- 新規プロダクト
- 今後はコンテナ化を検討していくべき
- コンテナにすると環境差異の排除、DXの向上などのメリットがある
- オンプレだとK8sが第一の選択肢になってくると思う(VMを建てた上でDocker/k8sを使う)
- 更新がないプロダクト
- わざわざk8s化しなくてもよい
- 今後も更新があるプロダクト
- 順次ステートレスなものを移設していくことを検討
- 運用上デプロイ頻度・開発環境に課題を感じていたり集約率を上げてコスト低下をしたい場合
- ステートフルなDBなどはVMのままで良いと思う
更新がないプロダクトならk8s化しなくても良いのでは？
運用上、デプロイ頻度を上げたい、環境差異を無くしたい、集約率を上げてコストを抑えたいなどの要件の場合は導入を検討すると良い。
検討のタイミング(坂田さん)
- 新しくプロダクトを立ち上げる場合
- k8sに移行しやすいようにサーバーレス(Cloud Runなど)のプロダクトをまず利用検討
- k8s移行を視野に入れておく
- サーバーレスのランタイムで厳しくなったら
- 既存のプロダクト(何かしらの理由でプラットフォーム移行をする)場合
- 最初からk8sを検討
- まずはできるだけ同じ形で移行して理想の形に持っていく
エンジニアとして新しいものを使いたいと言うモチベーションで選定するのは？
- 今後人を増やしていきたいときに魅力的になるのでは？と言う考えはあった(坂田さん)
- チームとか個人ではより良い技術を使いたいと言うモチベーションはあった
- ただし、本質的に良いものなのかはしっかりと考える(青山さん)
運用体制(青山さん)
-
約５年半の運用実績
-
約4000コア〜
-
k8s関連開発チーム
- KaaS(5.5人)
- ML Platform(5.5人)
-
その他インフラ関連チームなど
- プライベートクラウド
- マネージドサービス
-
広告・メディア・ゲームなどのサービス
- サービスチームA
- etc.
社内で使うユーザーが多い場合は自動的に環境を払い出す方が良い
より使う側が使いやすくなるような構成
運用体制(坂田さん)
-
病院向けサービス
-
一般患者向けサービス
-
新規開発
-
共通チーム
- SRE(3名)
-
初期の頃は坂田さん一人、今もクラスター自体は2~3名
-
開発チームはクラスタ管理はしない(基盤チームが担当)
-
GKEを使用
-
NodeのBlue/Greenもある
運用の課題感
青山さん
- Deprecated APIの修正は最近は安定していて手間ではない
- たまに大きなアップデートが来る
- エコシステムのアップグレードの方が大変
- 互換性はあるが、k8sと比較して破壊的変更をしがち
- k8s, CloudNativeなOSSは常に新しいものが出てくる
- キャッチアップが大変
坂田さん
- k8sそのものよりも周りのエコシステムの改善
- CI/CDやマニフェスト管理
- サービスが大きくなると大変
- CRDのアップデート
サービスごとにyamlのレベル、管理が煩雑になったりしてしまう(yaml地獄)
書き方が変わったりするため、どの書き方が良いのか？みたいになる
安全なアップデート
専門用語がわからない・・・が、GKEは結構自動的にやってくれる部分もあるらしい。
オンプレの場合、アップグレードをいつやるかなどは運用方針次第
自由度が高いのがオンプレのメリットだが、自分で考えないといけない部分があるデメリットがある
よくある失敗ポイント
青山さん
k8sをこんな感じで使っておけるな！と、思ってもあとから後悔して修正することがある
- クラスタサイズを見積もった上でネットワーク設計を疎かにしてしまうことがる
- 最悪は作り直しレベルになる？
- マニフェストをGitリポジトリで管理するときの分割戦略
- マルチテナントの分割
- エコシステムを手動で導入し、マニフェストのソースが不明確になる
- できれば更新を自動化しておく
- キャッチアップしていくことになるので、人数に見合ったOSS数かを考える
- クラウドプロバイダーやストレージベンダーごとの機能さの調査
- 違いがまとめられておらず、後々気がつくことが多い
namespaceは細かい方が良い
坂田さん
- APIのdeprecationはしっかり確認
- 忘れてCIが落ちることがある
- クラスターは作り直す前提で構築する
- 最初はいらない機能でも料金が変わらなければ有効化しておく
- とりあえず作ったクラスターを本番に入れる(NG)
- クラウドだと簡単に作れてしまう
- ○本番のクラスターにはベストプラクティスのページを見てから作る(セキュリティなど)
個人的にはdefault namespaceは使わない。
誤操作防止のため。(namespaceの指定忘れがあるとやらかすから？)
→CIで落とすようにするなどの工夫をすると良い
個人としてどこから学ぶのが良いか
青山さん
- Docker for Desktopのk8sが楽
- 公式Docs(kubernetes.io)
- Z Lab/PFNが出している変更点まとめ
- 勉強会やカンファレンス
- Kubernetes Novice
- Kubernetes Meetup
- CloudNative Days
- KubeCon + CNCon
坂田さん
- まずはGKEクラスターを立ててみる
- 実際にやってみるとCI/CDで必要なことが見えてくる
- ハンズオンやgetting startedをしてみる
- これだけだとNginxを建てるだけなので足りない
- Meetup
- 青山さんの書籍
- Kubernetes完全ガイド
- みんなのDocker/Kubernetes
- リリースノート
メモ
- 最初の導入する時の担当者をどうするか？
- キャッチアップが必要なので、熱量がある人
- コニュニティに出て情報交換ができるとなおよし
- インフラ・バックエンドどちらでも大丈夫
- OSSなのでソースコードを読むケースがある(読めるとなおよし)
- 英語のドキュメントを読むのが苦では無いこと
- 教育
- 基盤チームとして抽象化しすぎてしまうと便利な反面、使う側への教育も必要
- 使い方、アーキテクチャを組織として知っておくように教育
- ベストプラクティスを作ってとして、それがなぜそうすべきなのかをちゃんと説明・理解
QA
- ECS+Fargateと比較して導入するメリットは？
- k8sはオープンソースなのでGKEやオンプレへの移行も可能
- 運用中のk8sクラスタの安全なクラスタバージョンアップグレード方法
- CKA持っている人3人でどれくらいの規模のクラスタを管理できるか？
- CKA:k8sの管理者向けの資格
- 30~50クラスタあっても運用はできると思う
- k8sを使うのにおすすめのクラウドは？
- そんなに差は無い
- 他にどんなマネージドサービスを使うか、データ基盤をどうするかで考えると良い