パブリック/プライベートクラウドでつかうKubernetes

by Ryosuke Suto

Slide 1

Slide 1 text

パブリック/プライベートクラウドでつかう Kubernetes Ryosuke Suto 2017/10/12 Kubernetes Meetup Tokyo #7

Slide 2

Slide 2 text

•須藤涼介 @strsk •株式会社サイバーエージェント •技術本部 •サービスリライアビリティーグループ（SRG） •QC室 •エンジニア/マネージャー

Slide 3

Slide 3 text

Kubernetes

Slide 4

Slide 4 text

Public Cloud

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

•- node 200台 over •- 同時接続数十万 •- デプロイ •- kubetool -> Deploykun •- ChatOps •- リリース共有、カナリアリリース AbemaTV • https://www.wantedly.com/companies/abema/post_articles/73396

Slide 8

Slide 8 text

•- ロギング •- CloudLogging + CloudPub/Sub •- Podの標準出力はLogging •- アプリケーションのログはPub/Subへ •- Pub/Sub -> BigQuery, etc… •- 監視ツール •- Stackdriver, Prometheus AbemaTV • https://www.wantedly.com/companies/abema/post_articles/73396

Slide 9

Slide 9 text

Private Cloud (OpenStack)

Slide 10

Slide 10 text

•- 既存サービスのリプレース用 •- 開発環境構築中 •- レガシー環境、開発手法のモダン化 •- クラスター構築 •- kubespray(Ansible) OpenStack

Slide 11

Slide 11 text

•- Dockerイメージ •- GCR •- ロギング •- 魔改造したFluentdからCloudLoggingへ •- 監視ツール •- Datadog OpenStack

Slide 12

Slide 12 text

Private Cloudでのk8s運用 •- kubesprayでのデプロイが遅め •- 使わない部分も汎用的に記述されているため工夫が必要 •- すべて内部で完結させてしまうと運用コストが高くなる •- 適度に組み合わせて外に逃がす

Slide 13

Slide 13 text

Kubernetes採用の背景

Slide 14

Slide 14 text

•- 組織/システム的にマイクロサービスアーキテクチャを採用するようになる •- であれば各機能ごとにリリースもしやすいDocker一択 •- 開発初期は逆に属人性を生みやすい一面も •- 社内でもノウハウが溜まってくる •- 何より開発が活発

Slide 15

Slide 15 text

課題との歴史

Slide 16

Slide 16 text

デプロイフロー初期 •- あたたかみのある手動デプロイ •- Dockerイメージ自体はCircle CIでビルドしレジストリにPush •- 運用が初めてだったこともあり、開発時はkubectlによるリリースがデフォ •- 開発スケジュールが優先され、デプロイ周りを整えられないままローンチ •- リリース時にSlackに連絡、手動でデプロイして様子を見て反映 •- 当然ながらオペミスが多発

Slide 17

Slide 17 text

デプロイフロー中期 •- 手動カナリアリリース •- ミスしても問題ないよう1Podだけリリースできるツールを開発 •- リリース時は1Podのみリリースし、しばらく問題がなければ全台に適用 •- 大きなミスは起きないまでも根本解決になっていない…

Slide 18

Slide 18 text

デプロイフロー後期 •- ChatOps •- リリース作成もカナリアリリースもSlack上からできるように！ •- 手動からの解放 •- オペミスの削減

Slide 19

Slide 19 text

デプロイフロー後期

Slide 20

Slide 20 text

デプロイフロー今後 •- パイプラインベースのCI •- Spinnaker, Concourse CI, etc… •- 新規サービスで採用予定 •- カナリアリリース、判定、ロールバックを自動化 •- 社内に有識者がいたためConcourse CIを採用

Slide 21

Slide 21 text

デプロイフロー今後 •- Concourse CI •- Pivotalが開発 •- Go言語製 •- YAMLでジョブ、パイプラインを記述し結果をUIで見れる

Slide 22

Slide 22 text

デプロイフロー今後 •- Helmの導入検証 •- Kubernetesのパッケージマネージャ（rpmに対してyumのような） •- yamlファイルの作成コストを減らしたい •- Kubernetesの採用がより増えることを見越して

Slide 23

Slide 23 text

大量のロギング •- ログはFluentdで各ログストレージへ •- ログの量が多すぎてFluentdが高負荷に •- 標準出力は変わらずFluentdからCloud Loggingへ •- アプリケーションログはCloud Pub/Subへ送り、Big Queryにバルクインサート

Slide 24

Slide 24 text

大量のメトリクス •- Podの監視はStackdriverでOK •- サービスが拡大し、Podが大量になるとStackdriverの表示が遅延 •- Prometheusの導入 •- ServiceにExporter用のendpointを追加 •- Podが増減しても自動的に収集される •- より詳細かつ円滑な表示が可能に

Slide 25

Slide 25 text

まとめ

Slide 26

Slide 26 text

まとめ •- デプロイフローはまだまだ改善の余地あり •- 規模が大きくなった時のスケーリングが大事（当たり前） •- 自前でkubernetesを立てるときは全部管理しようとしない

Slide 27

Slide 27 text

一緒にはたらく仲間を募集しています！ https://cyberagent-career.jp/ recruit/joboffer/81/112359/71-361