I will tell you the passion of Kubernetes

Transcript

1. JAWS FESTA OSAKA 2018/10/26
   ABEJA, Inc.
   Shogo Muranushi
   Kubernetes界隈のPassionate(熱量)伝えます
   

   View Slide

2. View Slide

3. View Slide

4. 4
   略歴トピック
   • インフラエンジニア
   • AWSを採⽤しハマる
   • AWSをたくさん使う
   • 資格を5冠取得
   • AWSでDeepLearning

   プラットフォーム作る
   • インフラ => SRE Tech Lead
   • マイクロサービスで遊ぶ
   • プロダクトオーナーになる
   

   View Slide

5. 5
   アジェンダ
   1. Dockerとは
   2. Dockerオーケストレーションツール云々
   3. Kubernetesについて
   

   View Slide

6. 6
   まずは質問
   •Docker使ったことある⼈？
   •KubernetesやECSのようなサービス・ツール使ったこ
   とある⼈？
   

   View Slide

7. 7
   今⽇のゴール
   

   View Slide

8. View Slide

9. 9
   •Dockerとは
   •Dockerの歴史
   •なぜDockerを使うのか
   •Dockerを本番運⽤する上で何が課題になるのか
   

   View Slide

10. • 2013年リリース
    • コンテナ型仮想環境を提供
    • コンテナにアプリケーションを内包させる
    • LinuxコンテナやWindowsコンテナあり
    • 様々なインフラやOSで動作
    10
    とは
    

    View Slide

11. 11
    の歴史
    • 2013年
    • dotCloudがOSSで公開
    • 2014年
    • Googleは毎週20億のコンテナを起動していた
    • 1.0リリース
    • 2015年
    • マイクロソフト、Google、Red Hat、VMware、Amazon Web Servicesらと共同でコン
    テナの標準化団体「Open Container Initiative」の発⾜
    • （2011年）
    • Heroku エンジニアが The Twelve-Factor App を提唱
    出展元:https://www.sdxcentral.com/cloud/containers/definitions/containers-vs-vms/
    

    View Slide

12. 12
    The Twelve-Factor App (2011)
    Webアプリケーションを使いやすい形でスケーラブルにするための⽅法論
    • I. コードベース
    • バージョン管理されている1つのコードベースと複数のデプロイ
    • II. 依存関係
    • 依存関係を明⽰的に宣⾔し分離する
    • III. 設定
    • 設定を環境変数に格納する
    • IV. バックエンドサービス
    • バックエンドサービスをアタッチされたリソースとして扱う
    • V. ビルド、リリース、実⾏
    • ビルド、リリース、実⾏の3つのステージを厳密に分離する
    • VI. プロセス
    • アプリケーションを1つもしくは複数のステートレスなプロセスとして実⾏する
    

    View Slide

13. 13
    • VII. ポートバインディング
    • ポートバインディングを通してサービスを公開する
    • VIII. 並⾏性
    • プロセスモデルによってスケールアウトする
    • IX. 廃棄容易性
    • ⾼速な起動とグレースフルシャットダウンで堅牢性を最⼤化する
    • X. 開発/本番⼀致
    • 開発、ステージング、本番環境をできるだけ⼀致させた状態を保つ
    • XI. ログ
    • ログをイベントストリームとして扱う
    • XII. 管理プロセス
    • 管理タスクを1回限りのプロセスとして実⾏する
    The Twelve-Factor App (2011)
    Webアプリケーションを使いやすい形でスケーラブルにするための⽅法論
    

    View Slide

14. 14
    なぜDockerを使うのか
    • リソース集約効率が上がる
    • 必要な⾔語やライブラリを閉じ込めるため、

    ⼀つのサーバで複数の⾔語やバージョンを稼働させられる
    • 複数環境載せてもセキュリティ上分離可能（厳密には・・）
    • 環境の再現性が⾼い
    • アプリの実⾏環境構築が容易で、構築⾃体や問題発⽣の再現性が⾼い
    • ポータビリティ性が⾼い
    • どの環境でも動かすことが可能で、移⾏や複数環境構築が容易
    • ローカルと本番の環境を限りなく合わせることも可能で、開発・テストが容易
    

    View Slide

15. 15
    Dockerを本番運⽤する上で何が課題になるのか
    • 複数コンテナの管理
    • 本番利⽤するときは1コンテナではなくWeb、App、DBなど複数
    コンテナ
    • 可⽤性
    • 正しく稼働していること、⾃動でリカバリすること
    • オートスケール
    • 負荷に応じて⾃動でスケールすること
    • モニタリング、セキュリティ、etc
    • それらを管理するツールが必要になってきた
    

    View Slide

16. 16
    オーケストレーションツール
    

    View Slide

17. 17
    以下の課題を解決
    • 複数コンテナの管理
    • 本番利⽤するときは1コンテナじゃなく複数コンテナ
    • Web、App、DBなど種類も複数
    • 可⽤性
    • 正しく稼働していること、⾃動でリカバリすること
    • オートスケール
    • 負荷に応じて⾃動でスケールすること
    • モニタリング、etc
    • それらを管理するツールが必要になってきた
    

    View Slide

18. 18
    オーケストレーションツールの歴史
    • 2014
    • GoogleがKubernetes、DockerがDocker swarm、AWSがECSを発表
    • Mesos 0.21、Rancher 0.4リリース
    • 2015
    • Docker swarm、Kubernetes 1.0リリース
    • CNCF（Cloud Native Computing Foundation）設⽴
    • 2016
    • Apache Mesos1.0 + Dockerサポート
    • Rancher1.0リリース
    

    View Slide

19. 19
    オーケストレーションツールの歴史
    • 2017
    • Fortune 100企業のKubernetesの採⽤率は54％を突破と報道（Redmonk）
    • DockerがKubernetesの統合を発表
    • Azure、AWSもKubernetesマネージドサービス提供
    • 2018
    • Rancher2.0リリース + Kubernetesを標準に
    

    View Slide

20. 20
    なぜKubernetesがデファクトスタンダードになったのか
    • 定期的なメジャーアップデート
    • 3ヶ⽉ごとにアップデートを繰り返し、エンタープライズからのフィードバックも反
    映。本番稼働に耐えうるソフトウェアとして信頼を得た。
    •        によるエコシステムの拡⼤
    • Kubernetesの成⻑と共にCNCFに各⼤⼿企業が参加
    • Alibaba、AWS、Google、IBM、Microsoft、Oracle、Redhat、VMware、etc
    • 様々な良質なOSSがCNCFのエコシステムに
    • Prometheus、Fluentd、GRPC、containerd、cni、envoy、helm、etc
    • その他の要素含め、これらにより企業と開発者が集まるサイクルができて、圧倒的な速度
    で成⻑を遂げた
    

    View Slide

21. 21
    と、⾔われていますが個⼈的には
    • 設計がイマドキ
    • ベストプラクティスに添えば、良い設計になる
    • エコシステムのOSSもセンスが良い
    • Istio(Envoy)、Kubeflow、Knative、etc
    • マイクロサービスの課題を解決しやすい
    • UNIXの哲学、The Twelve-Factor App、コンテナデザインパターンを採⽤
    • マイクロコンテナになる
    • マイクロサービス化していく
    • マイクロサービスの管理⾟い
    • Istio登場 <<=== イマココ
    

    View Slide

22. 22
    Kubernetesは完璧か？使いこなすには？
    • Kubernetesは銀の弾丸ではない
    • マイクロサービスに耐えうる組織設計と⽂化形成と相性が良い（メルカリさん）
    • 組織設計 = コンウェイの法則
    • ⽂化形成 = 価値提供の速度向上・⽣産性向上を徹底する⽂化
    • ただし、マイクロサービスには課題がある
    • 分散システムのトレーシング、多数のシステム管理、⼀貫性、テスト、、、
    • 完璧ではないけど、徐々に良い⽅向に向かっています
    • コンウェイの法則
    • 組織の設計するシステムは、その組織のコミュニケーション構造をそのまま反映した設計になる
    

    View Slide

23. 23
    は？
    • ECSは良い⼦です
    • うちのシステムの8割はECSで動いています
    • Kubernetesは学習コスト⾼い。ECSはシンプルで簡単。マスター管理不要
    • まず使ってみるには超オススメ
    • Fargateは⾼いし制限はあるが、EC2が不要なのでかなり楽になる
    • しかし
    • ある程度運⽤していくと⾊々⾜りないことに気付く
    • ECSとAutoScaleの溝 => Spotinstを使って埋めよう
    • エコシステムがKubernetesに⽐べて弱い
    

    View Slide

24. 24
       使うならSpotinstは絶対オススメ
    

    View Slide

25. View Slide

26. 26
       は何ができるのか
    • 複数のKubernetes Nodeの管理
    • コンテナのスケジューリング
    • ローリングアップデート
    • オートスケーリング
    • コンテナの死活監視
    • 障害時のセルフヒーリング
    • サービスディスカバリ
    • ロードバランシング
    • ワークロードの管理
    • ログの管理
    • Infrastructure as Code
    • その他エコシステムとの連携や拡張
    • ネットワークセキュリティ
    • モニタリング
    • 分散トレース
    • サービスメッシュ
    

    View Slide

27. 27
      を使うには？
    • マネージドサービス
    • AWS EKS、Google / GKE、Azure / AKS
    • ⾃前で作る
    • kubeadm、kube-aws、rancher、etc
    • 簡易に試す
    • minikube、Docker on Mac
    

    View Slide

28. 28
    Kubernetesの⾯⽩いと思うところ掻い摘み
    • いわゆるコンテナオーケストレーションに関する部分はパスします
    • ⾯⽩いと思うところ
    • UNIXの哲学、The Twelve-Factor App、コンテナデザインパターンを踏襲しやすい
    • Kubernetesの実装内容が最新技術の勉強になる
    • 宣⾔型アーキテクチャ
    • エコシステムが盛り上がっていて、最新の課題に対するアプローチやコンセプトが勉強
    になる
    • マイクロサービスの課題に対してIstio、サーバレスの課題に対してKnativeなど
    

    View Slide

29. 29
    Design patterns for container-based
    distributed systems
    

    View Slide

30. 30
    Design patterns for container-based
    distributed systems
    • 2016年に USENIX Conference で発表された論⽂
    • Single-container management patterns（コンテナ管理⽤の単⼀コンテナパターン）
    • Single-node, multi-container application patterns（シングルノードでのマルチコンテナパターン）
    • Sidecar pattern（サイドカーパターン）
    • Ambassador pattern（アンバサダーパターン）
    • Adapter pattern（アダプターパターン）
    • Multi-node application patterns（分散システムのためのマルチノードでのパターン）
    • Leader election pattern（リーダー選出パターン）
    • Work queue pattern（ワークキューパターン）
    • Scatter/gather pattern（スキャッター/ギャザーパターン）
    

    View Slide

31. 31
    Sidecar pattern（サイドカーパターン）
    • メインコンテナの横に配置
    • 例）Webサーバをメインコンテナとして配置し、サイドカーとしてホスト側のログを保存
    するコンテナを配置する（Fluentdなど）
    • メリット
    • 開発の責任を分けやすくなり、独⽴してテストできる
    • サイドカーが異常になった場合にメインコンテナに

    影響しない。ロールバックも個別に可能
    • メインコンテナに CPUを優先的に割り当て、

    サイドカーコンテナは空いた時間で処理する
    出展元:https://qiita.com/MahoTakara/items/03fc0afe29379026c1f3
    

    View Slide

32. 32
    Ambassador pattern（アンバサダーパターン）
    • メインコンテナが外部とコミュニケーションをするときのプロキシになる
    • 例）Memcached や Redis のシャーディング⽤のツールとして利⽤される twemproxy など
    • そのうち Kafka / AWS Kinesis / Google Cloud PubSub などを抽象化するパターンもあるかも
    • メリット
    • 開発者は外部とコミュニケーションをする

    という関⼼事をアンバサダーにオフロード

    できる（今回の例ではシャーディング）
    出展元:https://qiita.com/MahoTakara/items/03fc0afe29379026c1f3
    

    View Slide

33. 33
    Adapter pattern（アダプターパターン）
    • アンバサダーとは異なり、外部とのインターフェースを標準化する
    • 例）システム内の全てのコンテナが同じモニタリングインターフェースを持つ
    • 今回の場合はモニタリングの共通I/Fに対応するためのアダプタコンテナを⽤意。アダプタ
    コンテナで各アプリケーションの仕様を抽象化
    出展元:https://qiita.com/MahoTakara/items/03fc0afe29379026c1f3
    

    View Slide

34. 34
    Kubernetesの⾯⽩い実装
    宣⾔型アーキテクチャ
    

    View Slide

35. Kubernetesの⾯⽩い実装：宣⾔型アーキテクチャ
    kubectl apply -f nginx.yaml
    kube-apiserver
    etcd
    apiVersion: v1
    kind: Pod
    metadata:
    name: nginx
    spec:
    nodeName: “”
    containers:
    - name: nginx-container
    1) kube-apiserverにリクエスト
    2) etcdにnodeNameが無い状態で書き込み
    

    View Slide

36. Kubernetesの⾯⽩い実装：宣⾔型アーキテクチャ
    kubectl apply -f nginx.yaml
    kube-apiserver
    etcd
    apiVersion: v1
    kind: Pod
    metadata:
    name: nginx
    spec:
    nodeName: “nodeA”
    containers:
    - name: nginx-container
    kube-scheduler
    3) nodeName未割り当てを探して割り当て
    

    View Slide

37. Kubernetesの⾯⽩い実装：宣⾔型アーキテクチャ
    kubectl apply -f nginx.yaml
    kube-apiserver
    etcd
    apiVersion: v1
    kind: Pod
    metadata:
    name: nginx
    spec:
    nodeName: “nodeA”
    containers:
    - name: nginx-container
    4) nodeNameが⾃分⾃⾝に割り当てられ
    ているPodがあれば、そのPodを起動する
    37
    kubelet
    In Server
    kubelet
    In Server
    kubelet
    In Server
    

    View Slide

38. 38
    Kubernetes
    エコシステム
    

    View Slide

39. View Slide

40. 40
       とは
    • 2017年3⽉にOSSとして公開、2017年12⽉に⼀躍時の⼈に、2018年7⽉にGA、12,000 star
    • コアの部分はLyft社が開発したEnvoyに、EnvoyをマネジメントするためにIstioを開発
    • マイクロサービスの課題を解決するために⽣まれたサービスメッシュであるIstio
    • 負荷分散と特定バージョンへの安全なルーティング
    • 多様な⾔語で実装、分散システムのネットワーク越しでのエラーハンドリング
    • どのシステムで遅延しているのか、状況はどうなのか、どこで何が起こったのか
    • サービス間の認証認可
    • サイドカープロキシとして、コンテナのProxyとして実装
    

    View Slide

41. 41
    サービスメッシュ
    出展元:https://www.redhat.com/en/topics/microservices/what-is-a-service-mesh
    

    View Slide

42. 42
         の主な機能
    • HTTP、gRPC、TCPのトラフィックに対する⾃動的なロードバランスとヘルスチェック
    • 豊富なルーティングルール
    • カナリアリリース、Blue/Green、A/Bテスト
    • トラフィックコントロール
    • タイムアウト、リトライ、サーキットブレーカー、フォルトインジェクション
    • 各種メトリクスの収集と分散トレーシング
    • トラフィックの暗号化、サービス同⼠の認証および認可
    出展元:https://www.redhat.com/en/topics/microservices/what-is-a-service-mesh
    

    View Slide

43. 43
           のエコシステム
    

    View Slide

44. View Slide

45. 45
         とは
    • 2017年12⽉にGoogleがKubeconで発表
    • 2018年5⽉にOSSで0.1を公開、現在は0.3、2018年12⽉にGA予定、4,700 star
    • Kubernetesのクラスターの上で機械学習のジョブを動かせる
    • 機械学習のジョブをコラボレーションと対話により訓練するJupyter Hubや、Tensorflow
    の訓練とホスティングなどが含まれる
    • まだ発展途上だが注⽬度が⾮常に⾼い
    

    View Slide

46. View Slide

47. View Slide

48. 48
       とは
    • プロダクト名は「Knative」
    • 2018年7⽉にGoogleが「現代的なサーバレスワークロードを構築、デプロイ、管理するた
    めの、Kubernetesベースのプラットフォーム」として公開
    • まだまだベータレベル
    • Kubernetes上でServerlessを実現するプロダクト
    • KubernetesでServerlessって、それServerlessじゃなくね・・？
    

    View Slide

49. 49
    個⼈的⾒解
    • Googleはオープン戦略をとっている？（というよりCNCFが標準化思考）
    

    View Slide

50. 50
    結果
    • みんなが集まる
    • さらに良いプロダクトが⽣まれる
    • Istio、Kubeflow、Knative、etc
    • より便利になる
    •
    • みんなが集まる
    • さらに良いプロダクトが⽣まれる
    • より便利になる
    •
    

    View Slide

51. 51
    今後どうなるか
    • 流⾏り廃りが激しいし数年後にはKubernetesに代わる何かが出てるかも
    • コンテナは古くなってサーバレスが主流になってるかも
    • でも、流⾏りの技術を通して業界の課題や解決⼿法のアプローチ、業界の流れが⾒えてくる
    • 概念やコンセプトは⾮常に参考になるし、⾃分の設計に活きてくる
    • ということで、Kubernetes始めてみませんか？
    

    View Slide

52. 52
    Tokyoリージョンまだ？！
    

    View Slide

53. 53
    個⼈にとってKubernetesを学ぶと何が良いのか
    • 最新のコンセプトや概念を学べる
    • 命令型ではなく宣⾔型の設計
    • マイクロサービスとその課題に対してのアプローチ
    • コンテナデザインパターン
    • 拡張性を考えた実装
    • 規格の標準化による拡⼤
    

    View Slide

54. 54
    個⼈の成⻑なくして会社の成⻑なし
    

    View Slide

55. 55
    どうすれば学べるか
    •（勉強）本を読む
    •（⾏動）触る
    •（実践）業務に⼊れてみる
    •（痛み）失敗して理解し成⻑する
    •（圧倒的成⻑）当たり前に使う環境に変える
    

    View Slide

56. 56
    ご静聴ありがとうございました
    

    View Slide