Upgrade to Pro — share decks privately, control downloads, hide ads and more …

頑張らないKubernetes/ Real World Kubernetes

頑張らないKubernetes/ Real World Kubernetes

Shinichi Morimoto

December 18, 2018
Tweet

More Decks by Shinichi Morimoto

Other Decks in Technology

Transcript

  1. Fringe81 • 六本木の会社 • Ad Tech系/HR Tech系の領域で様々なサー ビスを展開 ◦ Ad

    Tech系: docomo Ad Network, GrowLio, etc ◦ HR Tech系: Unipos • 絶賛エンジニア募集中
  2. Kubernetes採用前(過去のプロダクトの構成) インスタンス/VM docker Web Server • デプロイが大変 ◦ 手順書に沿って、手動でデプロイ ◦

    オレオレ deploy shell scripts • リソースマネージメントが大変 ◦ 手動でスケールアップ or スケールア ウト • 障害時の対応が大変 ◦ 手動で復旧 App Server other インスタ ンス/VM docker C C C 同一セット …
  3. Kubernetes採用後(イメージ) インスタンス /VM Kubernetes Web Server • デプロイが大変 => YAML適用のみ

    => ローリングデプロイも可能 • リソースマネージメントが大変 => Podのオートスケール • 障害時の対応が大変 => 落ちても自動でPodが復旧する App Server other インスタンス /VM インスタンス /VM 同一 Pod
  4. Kubernetes採用に関しての障壁 • Kubernetesの知見がない ◦ ほぼアプリケーションエンジニア ◦ 全員k8s実運用経験なし! • 対象とするシステムがシビア ◦

    後述 障害が起きたときに 対応できるか 不安 k8sにのせて、パ フォーマンス要求を 満たせるだろうか? 不安
  5. ざっくり配信プラットフォームの構成 • 広告配信システム ◦ 広告を配信する ◦ 低レイテンシ(レスポンスがもの凄く速い 数十 ) ◦

    ミッションクリティカル(落ちると非常にまずい) • 各種バッチ ◦ 配信した結果を集計するバッチ等 ◦ の単位で実行されるバッチ • 入稿管理システム ◦ 広告を入稿するシステム ◦ 管理画面
  6. ざっくり配信プラットフォームの構成 • 広告配信システム ◦ 広告を配信する ◦ 低レイテンシ(レスポンスがもの凄く速い 数十 ) ◦

    ミッションクリティカル(落ちると非常にまずい) • 各種バッチ ◦ 配信した結果を集計するバッチ等 ◦ の単位で実行されるバッチ • 入稿管理システム ◦ 広告を入稿するシステム ◦ 管理画面 停止した際の影響度 少し大変 非常に大変!!
  7. ざっくり配信プラットフォームの構成 • 広告配信システム ◦ 広告を配信する ◦ 低レイテンシ(レスポンスがもの凄く速い 数十 ) ◦

    ミッションクリティカル(落ちると非常にまずい) • 各種バッチ ◦ 配信した結果を集計するバッチ等 ◦ の単位で実行されるバッチ • 入稿管理システム ◦ 広告を入稿するシステム ◦ 管理画面 停止した際の影響度 少し大変 非常に大変!! k8sで稼働できそう
  8. Kubernetes採用に関しての障壁 => 導入 • Kubernetesの知見がない ◦ 影響がないシステムから導入する ◦ 最悪落ちた際のリカバリ手段を用意 =>

    docker on インスタンス(過去の構成)で動かせる用に準備しておく ◦ 運用を通して知見をためる • 対象とするシステムがシビア ◦ パフォーマンス要求が厳しいものについては、k8sにのせない ◦ 知見が貯まった際に再度検討
  9. Kubernetes採用に関しての障壁 => 導入 • Kubernetesの知見がない ◦ 影響がないシステムから導入する ◦ 最悪落ちた際のリカバリ手段を用意 =>

    docker on インスタンス(過去の構成)で動かせる用に準備しておく ◦ 運用を通して知見をためる • 対象とするシステムがシビア ◦ 要求が厳しいものについては、k8sにのせない ◦ 知見が貯まった際に再度検討 影響が低いシステム リカバリ手段 自信を持って運用 運用力がLv Upしたら再度挑戦!
  10. Namespace Namespace Kubernetes構成詳細 Deployment Kubernetes Web Server App Server CronJob

    Batch • Kubernetes ◦ 運用負荷を下げる為にマネージド・ サービスを利用 ◦ 基盤としてAzureを利用していたので、 AKSを採用 ◦ 2018年6月末にGA ▪ 開発期間が5月〜7月だったので ギリギリGA間にあった Namespace Daemon Set Data Dog
  11. Namespace Namespace Kubernetes構成詳細 Deployment Kubernetes Web Server App Server CronJob

    Batch Namespace Daemon Set Data Dog • AKS(Azure Kubernetes Service ) ◦ マスターノードを管理 ◦ クラスタのアップグレード機能 ◦ クラスタのスケール機能 ◦ マスターノードには課金されない ▪ 懐に優しい ◦ Azure Kubernetes Service (AKS) virtual nodeでより便利に?
  12. Namespace Namespace Kubernetes構成詳細 Deployment Kubernetes Web Server App Server CronJob

    Batch Namespace Daemon Set Data Dog • Namespaces ◦ Prd環境・Stg環境のクラスタを分けてい る ◦ サービス毎に依存関係はないので、 Namespaceはサービス毎に切っている
  13. Namespace Namespace Kubernetes構成詳細 Deployment Kubernetes Web Server App Server CronJob

    Batch Namespace Daemon Set Data Dog • Deployment ◦ 入稿管理画面サービスはDeployment で管理 ◦ PodのReplica数の管理 ◦ ローリングアップデート ◦ オートヒーリングの実現
  14. Namespace Namespace Kubernetes構成詳細 Deployment Kubernetes Web Server App Server CronJob

    Batch Namespace Daemon Set Data Dog • CronJob ◦ バッチ系については、CronJobで管理 ◦ 定期的にバッチを実行
  15. Namespace Namespace Kubernetes構成詳細 Deployment Kubernetes Web Server App Server CronJob

    Batch Namespace Daemon Set Data Dog • Daemon Set ◦ 監視にはDatadogを利用 ◦ Datadogの課金体系から、ノード毎に1 つ用意したい ◦ ノード毎にdeployしたいので、Daemon Setを利用
  16. マニフェスト管理(YAML管理) Production Kubernetes Staging Kubernetes dev(Local) Kubernetes Web Application Datadog

    Batch • Kubernetes クラスタ ◦ 本番環境 ◦ ステージング環境 ◦ 開発環境(各自のローカルPC) ◦ 3環境のKubernetesクラスタ
  17. マニフェスト管理(YAML管理) Production Kubernetes Staging Kubernetes dev(Local) Kubernetes Web Application Datadog

    Batch • 稼働サービス(コンテナ) ◦ Webサーバ ◦ アプリケーション(管理画面) ◦ バッチ ◦ 監視(Datadog) ◦ 4種類
  18. マニフェスト管理(YAML管理) Production Kubernetes Staging Kubernetes dev(Local) Kubernetes Web Application Datadog

    Batch • 管理しなければならないYAML(という か設定内容) ◦ 環境 × 稼働サービス数 ◦ 要するに一杯 ◦ 各環境に共通する項目は共通化し、差 分のみを効率良く管理したい
  19. 監視(Datadog) • Datadog ◦ 監視はDatadogに全ておまかせ ◦ SaaSなので、すぐに利用可能 ◦ プラグインが豊富にある(Kubernetes 用のもあり)

    ◦ 社内がマルチクラウド(AWS, GCP, Azure)なので、監視系はクラウドベン ダーにロックインされたくない 公式ドキュメントより (https://www.datadoghq.com/ja/blog/monitoring-kubernetes-data dog/)
  20. Kubernetes構成まとめ • 構成自体はシンプル ◦ Deployment、 CronJob、DaemonSetをそれぞれの役割にマッチした用途で利用 • マニフェスト管理もシンプル ◦ kustomizeで適切に環境毎のYAMLを管理

    ◦ 本当に必要になるまで、Helm等は入れない • 監視もシンプル ◦ Datadog(SaaS)を利用することにより、監視システムの構築工数を削減 ◦ インターフェースも分かりやすいので、キャッチアップも楽
  21. Kubernetes構成まとめ • シンプル、分かりやすい構成からスタート => 知見がなくても、運用できそうな 攻めない!程良い構成とする => ステートレスな機能のみを利用 • マネージド

    + SaaSを活用 => マネージドでk8s自体の管理をお任せ => SaaSで知見がなくても、プリセットを利用して、必要最低限の監視は可能
  22. Kubernetes(というかAKS)を導入した効果 番外編 • 深刻な脆弱性が発見される ◦ 2018/12/4発表 ◦ 深刻度は9.8(最大10) ◦ 権限昇格の脆弱性

    ◦ 任意のユーザがノード及びポッドを自 由に操作できる Github Kubernetes Repoより (https://github.com/kubernetes/kubernetes/issues/71411)
  23. Kubernetes(というかAKS)を導入した効果 番外編 • 簡単にアップデート ◦ Azure Consoleよりアップデート ◦ 所要時間数分 ◦

    特にサービスダウンなく、アップデート 完了 ◦ 脆弱性情報を知ってから、その日の内 に対応完了
  24. Kubernetesを導入した効果 番外編 • ポータビリティ性の良さを実感 ◦ 開発時、本番環境(AKS)でのみ、アプリケーションが正常に動作しない事象が発生 ◦ ローカルでは問題なく動く ◦ 切り分けの為、別のマネージドKubernetes環境で検証した際に再現

    ◦ アプリケーション側での問題だと分かり、速やかに原因特定できた ◦ 同じマニフェストファイルを適用するだけで、他のKubernetes環境でも動作する ◦ 他の環境に持っていくのに、ほぼノーコストですみ、ポータビリティの良さを実感
  25. Kubernetes(AKS)を3ヶ月近く運用した感想 • 思っていたより、問題起きない ◦ とても安定している ◦ この3ヶ月、困った事象は特に発生しなかった • メンバーへのスキルトランスファーもスムーズに行えた ◦

    ハンズオン形式のチーム内勉強会を2回程実施 ◦ 後はリリース作業を通して、実地で学ぶ • オートヒーリングは便利 ◦ Podが落ちたことがあったが、自動的に復旧してくれるので、やはり便利