I will tell you the passion of Kubernetes

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

4 略歴トピック • インフラエンジニア • AWSを採⽤しハマる • AWSをたくさん使う • 資格を5冠取得 • AWSでDeepLearning  プラットフォーム作る • インフラ => SRE Tech Lead • マイクロサービスで遊ぶ • プロダクトオーナーになる

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

7 今⽇のゴール

Slide 8

Slide 8 text

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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/deﬁnitions/containers-vs-vms/

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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リリース

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

29 Design patterns for container-based distributed systems

Slide 30

Slide 30 text

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（スキャッター/ギャザーパターン）

Slide 31

Slide 31 text

31 Sidecar pattern（サイドカーパターン） • メインコンテナの横に配置 • 例）Webサーバをメインコンテナとして配置し、サイドカーとしてホスト側のログを保存するコンテナを配置する（Fluentdなど） • メリット • 開発の責任を分けやすくなり、独⽴してテストできる • サイドカーが異常になった場合にメインコンテナに  影響しない。ロールバックも個別に可能 • メインコンテナに CPUを優先的に割り当て、  サイドカーコンテナは空いた時間で処理する出展元:https://qiita.com/MahoTakara/items/03fc0afe29379026c1f3

Slide 32

Slide 32 text

32 Ambassador pattern（アンバサダーパターン） • メインコンテナが外部とコミュニケーションをするときのプロキシになる • 例）Memcached や Redis のシャーディング⽤のツールとして利⽤される twemproxy など • そのうち Kafka / AWS Kinesis / Google Cloud PubSub などを抽象化するパターンもあるかも • メリット • 開発者は外部とコミュニケーションをする  という関⼼事をアンバサダーにオフロード  できる（今回の例ではシャーディング）出展元:https://qiita.com/MahoTakara/items/03fc0afe29379026c1f3

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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が無い状態で書き込み

Slide 36

Slide 36 text

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未割り当てを探して割り当て

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

38 Kubernetes エコシステム

Slide 39

Slide 39 text

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

43 のエコシステム

Slide 44

Slide 44 text

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

Slide 47

Slide 47 text

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

52 Tokyoリージョンまだ？！

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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