めっちゃわかる Kubernetes! / Mix Leap Study #32

Slide 1

Slide 1 text

Mix Leap Study #32 - めっちゃわかるAIとKubernetes(GCPUG共催) 2019/1/31 Kazuki Suda @superbrothers めっちゃわかる Kubernetes！

Slide 2

Slide 2 text

Kazuki Suda / @superbrothers ▶ ソフトウェアエンジニア@Z Lab & Yahoo Japan ▶ 第８代黒帯〜インフラストラクチャ Kubernetes〜 ▶ Kubernetes Meetup Tokyo 主催 ▶ Cloud Native Deep Dive 主催

Slide 3

Slide 3 text

ゼットラボ株式会社 ▶ 2015年に設⽴されたヤフー株式会社100%⼦会社 ▶ インフラ基盤技術の調査・研究開発 ▶ https://zlab.co.jp/ ▶ https://qiita.com/organizations/zlab

Slide 4

Slide 4 text

No content

Slide 5

Slide 5 text

@superbrothers アジェンダ 1. Kubernetes とはなにか 2. ヤフーと Kubernetes 3. コンテナとはなにか 4. なぜコンテナなのか 5. なぜ Kubernetes なのか 6. なぜ Kubernetes なのか（機能⾯） 7. Kubernetes のアーキテクチャとオブジェクト 8. より詳しく知るには

Slide 6

Slide 6 text

Kubernetes とはなにか

Slide 7

Slide 7 text

@superbrothers Kubernetes ▶ コンテナオーケストレーションツール + 複数のマシン（ノード）で構成されるクラスタに対して  コンテナ（アプリケーション）の配備、設定、管理を⾏う ▶ κυβερνήτης: ギリシャ語で操舵⼠ ▶ Google の社内システムからインスパイアされた ▶ 2014年6⽉に最初のコミットがあり、2015年7⽉に1.0.0をリリース + 2019年1⽉時点の最新バージョンは 1.13.0 “Kubernetes is open source—a contrast to Borg and Omega,  which were developed as purely Google-internal systems. “ Borg, Omega, and Kubernetes

Slide 8

Slide 8 text

@superbrothers Kubernetes ▶ 初期は Google のソフトウェアだったが、その後  Cloud Native Computing Foundation（CNCF）に譲渡され、  現在は CNCF がホストするオープンソースプロジェクト + CNCF は Linux Foundation 傘下の組織 ▶ オンプレでの利⽤はもちろん、  GCP や AWS、Azure でマネージドサービスとしても提供されている ▶ 「10年以上に渡りコンテナを本番環境で運⽤してきた Google の経験と  多くの企業によるコミュニティの優れたアイデアと⼿法が組み込まれている」

Slide 9

Slide 9 text

@superbrothers ! ノードA ノードB ノードC を2つ実⾏したいを実⾏するのに適切なノードはどれだろう？は1CPU、1GBメモリが必要

Slide 10

Slide 10 text

@superbrothers https://twitter.com/brendandburns/status/585479466648018944 ▶ Kubernetes: クーバネティス、クバネテス ▶ k8s: ケイエイツ、けいはちえす

Slide 11

Slide 11 text

ヤフーと Kubernetes

Slide 12

Slide 12 text

@superbrothers ヤフーと Kubernetes 2017年10⽉頃から⼀部サービスの本番環境として Kubernetes の利⽤を  開始。現在では、多くのサービスで利⽤している。 ▶ 10 データセンタ ▶ 100,000+ サーバ ▶ 160+ OpenStack クラスタ ▶ 200+ Kubernetes クラスタ

Slide 13

Slide 13 text

ヤフー株式会社向けにゼットラボが開発するマネージド Kubernetes サービス。  オンプレミスの OpenStack 環境に Kubernetes クラスタを作成、管理する。 ▶ セルフサービス ▶ マネージド ▶ スケーラブル ▶ シングルテナントヤフーの Kubernetes-as-a-Service

Slide 14

Slide 14 text

@superbrothers Japan ContainerDays v18.04 2018/4/17 OpenStack Days Tokyo, Cloud Native Days Tokyo 2018 2018/8/3

Slide 15

Slide 15 text

コンテナとはなにか

Slide 16

Slide 16 text

https://www.ﬂickr.com/photos/aidanwojtas/34885389822

Slide 17

Slide 17 text

@superbrothers Linux コンテナシステムの他の部分から分離されたプロセス ▶ マシンのリソースを共有していることでプロセスが正常に実⾏されない + ファイルシステム、ネットワーク、PID、ユーザなど + 例えば、常に 8080番ポートを使えることを保証できない + CPU、メモリ、ファイルシステム + うるさい隣⼈問題

Slide 18

Slide 18 text

@superbrothers Linux コンテナプロセスがシステムの他の部分に影響されないように隔離し、制限する ▶ 隔離（isolation）: Linux namespaces + 他のシステムからファイルシステムやネットワークを隔離する ▶ 制限（limit）: Linux cgroups + CPU やメモリといったリソースを使⽤を制限

Slide 19

Slide 19 text

@superbrothers Docker コンテナの実⾏と管理を⾏うソフトウェア ▶ コンテナイメージのビルドから、配信、実⾏を⾏う + アプリケーションの実⾏に必要なランタイムやライブラリ、ソフトウェアなどを全て含む ▶ ソフトウェア開発の標準化された単位にアプリケーションをパッケージ化する + BUILD（組み⽴て）→ SHIP（出荷）→ RUN（実⾏）

Slide 20

Slide 20 text

@superbrothers BUILD（組み⽴て）/ Dockerﬁle ▶ テキスト形式のコンテナイメージの構成を記述するファイル ▶ 開発者は docker build コマンドを使い、複数のコマンド⾏の命令を順次実⾏し、イメージを作成する

Slide 21

Slide 21 text

@superbrothers SHIP（出荷）/ コンテナレジストリ ▶ ビルドしたコンテナイメージがアップロードされるレジストリ ▶ パッケージでいうところのパッケージ管理システムに相当する ▶ docker pull コマンドでレジストリからイメージを取得できる

Slide 22

Slide 22 text

@superbrothers RUN（実⾏）/ Docker デーモン ▶ コンテナの実⾏を管理するデーモンプロセス ▶ パッケージでいうところのプロセス管理ツールに相当する ▶ docker コマンドラインツールから操作する

Slide 23

Slide 23 text

なぜコンテナなのか

Slide 24

Slide 24 text

@superbrothers なぜコンテナなのか ▶ 素早いアプリケーションの作成と展開 + コンテナイメージの作成の容易さと効率性は、仮想マシンイメージの使⽤と⽐較して向上する ▶ 開発（Dev）と運⽤（Ops）の分離 + デプロイ時ではなくビルド時にコンテナイメージを作成することで、アプリケーションをインフラから切り離す

Slide 25

Slide 25 text

@superbrothers なぜコンテナなのか ▶ 継続的な開発とインテグレーション、デプロイメント + 信頼性の⾼いひんぱんなコンテナイメージのビルドと展開が迅速かつ容易なロールバック（イメージ不変性による）を提供する ▶ 開発、テスト、本番の環境の⼀貫性 + ラップトップでも本番でも同じように動作する

Slide 26

Slide 26 text

@superbrothers コンテナとは ▶ アプリケーションにイミュータブル（不変）でポータブルな性質（いつどこで実⾏しても同じものとなる）をもたらした ▶ オーケストレータによる複数マシンでのアプリケーションの⾃動的なスケジューリングと実⾏、管理を可能にした + コンテナだけの利⽤では、開発者がマシンを「丁寧に」管理する必要がある

Slide 27

Slide 27 text

なぜKubernetesなのか

Slide 28

Slide 28 text

@superbrothers Kubernetes はオープンである ▶ オープンソースソフトウェア + github.com/kubernetes/kubernetes (Apache License 2.0) ▶ オープンデザイン + github.com/kubernetes/community ▶ オープンコミュニティ + Cloud Native Computing Foundation + Special Interest Groups (SIGs) ▶ Slack, StackOverﬂow, 全世界で300以上のミートアップ + Kubernetes Slack ワークスペース（slack.k8s.io） #jp-users + Kubernetes Meetup Tokyo

Slide 29

Slide 29 text

@superbrothers Kubernetes はポータブルである ▶ cloud-controller-manager（クラウドの操作） + L4 LB, ブロックストレージなどの操作を抽象化 + GCP、AWS、Azure、OpenStack など ▶ CNI（Container Network Interface） + コンテナネットワークの標準化 + Calico、Flannel、Weave Net など ▶ CRI（Container Runtime Interface） + コンテナ操作の標準化 + Docker（containerd）、cri-o、rkt

Slide 30

Slide 30 text

@superbrothers Kubernetes は成⻑している Kubernetes Docker Swarm Apache Mesos All Time Statistics Contributors 2,235 209 357 Commits 70,766 3,501 31,890 12 Month Statistics Contributors 871 25 117 Commits 14,477 230 6,890 https://www.openhub.net/p/_compare?project_0=Kubernetes&project_1=docker+swarm&project_2=Apache+Mesos As of 19/1/23

Slide 31

Slide 31 text

@superbrothers https://www.ﬂickr.com/photos/143247548@N03/31365923847/

Slide 32

Slide 32 text

@superbrothers https://www.ﬂickr.com/photos/143247548@N03/31365923847/ https://kccna18.sched.com/event/GsxP/keynote-kubernetes-project-update-janet-kuo-software-engineer-google

Slide 33

Slide 33 text

https://kccna18.sched.com/event/GsxP/keynote-kubernetes-project-update-janet-kuo-software-engineer-google

Slide 34

Slide 34 text

@superbrothers なぜ Kubernetes なのか ▶ Kubernetes はオープンである ▶ Kubernetes はポータブルである ▶ Kubernetes は成⻑している（今も）

Slide 35

Slide 35 text

なぜKubernetesなのか（機能⾯）

Slide 36

Slide 36 text

@superbrothers なぜ Kubernetes なのかひんぱんなデプロイに耐えられる⾮常に優れた機能を持つ ▶ これまでの開発は、アプリケーションのデプロイに数⽇、数週間かかることも ▶ 時間のかかるデプロイは、問題があったときの修正も遅くなる ▶ 逆にいうとひんぱんなデプロイは問題をすぐに修正でき、リスクを取れる + 1つひとつのデプロイが軽くなり（ボリューム、リスク） + 間違いから迅速に復旧できるようになり + より多くのリスクをとることができる ▶ 開発した成果をいかにはやく本番に届けられるかが競合に勝つための⼤きな要因になっている

Slide 37

Slide 37 text

@superbrothers ひんぱんなデプロイに耐えられる⾮常に優れた機能 ▶ ひんぱんなデプロイを可能にする「宣⾔的設定」 ▶ 強⼒な⾃⼰回復機能「セルフヒーリング」 ▶ VM（仮想マシン）中⼼ではなく「コンテナ中⼼」のインフラ

Slide 38

Slide 38 text

@superbrothers ひんぱんなデプロイを可能にする「宣⾔的設定」これまでの A を実⾏してから B を実⾏するような⼀連の⼿続きによるデプロイは、各⼿続きが以前の状態に依存する。 ▶ もしホストの⼀部だけ変更が加えられていても確実にデプロイが成功することが保証できるか？ ▶ アプリケーションに問題があったときに確実にロールバックできるか？

Slide 39

Slide 39 text

@superbrothers ⼀連の⼿続きによるデプロイ B A C ⋆ ♥ 操作の順序が変わっても必ず C の状態までたどり着ける？ A まで正確にロールバックするには？ AからBの変更 BからCの変更

Slide 40

Slide 40 text

@superbrothers 宣⾔的設定によるデプロイデプロイした結果のアプリケーションの「望ましい状態」を記述した設定ファイルを反映する。 ▶ 事前にどんな変更が加えられていても、ゼロからの構築であっても必ず設定ファイルに記述された「望ましい状態」になる ▶ ロールバックは以前の戻したい時点での設定ファイルを反映するだけになる

Slide 41

Slide 41 text

@superbrothers 宣⾔的設定によるデプロイ A C C 望ましい状態が記述された設定ファイル AからCになるように⾃律的に動作する

Slide 42

Slide 42 text

@superbrothers 宣⾔的設定によるロールバック C A A ロールバックは以前の状態の設定ファイルを反映するだけ CからAになるように⾃律的に動作する

Slide 43

Slide 43 text

@superbrothers apiVersion: apps/v1 kind: Deployment metadata: name: nginx spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.13.3 ports: - containerPort: 80 Kubernetes における宣⾔的設定レプリカ数（3つデプロイする）デプロイするコンテナイメージ（nginx のバージョン 1.13.3）

Slide 44

Slide 44 text

@superbrothers 強⼒な⾃⼰回復機能「セルフヒーリング」障害により VM やマシンは壊れる。壊れた VM 上でサービスの継続に必要なアプリケーションが実⾏されていたらどうするか？望ましい状態: 3 2 現在の状態: 2 1

Slide 45

Slide 45 text

@superbrothers Kubernetes はクラスタの状態を継続的に望ましい状態であり続けようと動作する。ノード（マシン）が数台ダウンしてもアプリケーションの実⾏に必要なリソースが残っている限り、翌営業⽇に復旧すればいい。強⼒な⾃⼰回復機能「セルフヒーリング」望ましい状態: 3 2 現在の状態: 3 2

Slide 46

Slide 46 text

@superbrothers VM中⼼ではなく「コンテナ中⼼」のインフラ Kubernetes は、複数の VM (ノード) を1つの⼤きなリソースプール (クラスタ) として扱うことで VM を抽象化する。 ▶ クラスタに対してコンテナをデプロイすると、そのコンテナの実⾏に必要なリソースが空いているノードにスケジュールされる ▶ 開発者は、特定のコンテナがクラスタ内のどのノードで実⾏されているかを気になる必要がない

Slide 47

Slide 47 text

@superbrothers クラスタはノードの集合体クラスタ CPU: 8 RAM: 30GB ノード CPU: 80 RAM: 300GB GPU: 3 CPU: 8 RAM: 30GB GPU: 3 異なるタイプのマシンも同居できる

Slide 48

Slide 48 text

@superbrothers サーバリソースの隙間問題の解消各サーバのリソースの隙間を有効活⽤できないアプリケーションの CPU 使⽤量 Kubernetes スケジューラがリソース効率を考慮した配置でコンテナをスケジュールコンテナ化により同居できるようになりリソースを有効活⽤できる

Slide 49

Slide 49 text

@superbrothers VMの抽象化に加えて、ITインフラも抽象化 VM の抽象化に加えて、サービスの構成を「アプリケーション指向」に抽象化された Kubernetes オブジェクトで扱う。 ▶ ロードバランサや永続ストレージなどの IT インフラを抽象化 ▶ ステートレスからステートフルまでさまざまな種類のアプリケーションに対応する多くのオブジェクトが⽤意されている

Slide 50

Slide 50 text

@superbrothers ひんぱんなデプロイに耐えられる⾮常に優れた機能 ▶ ひんぱんなデプロイを可能にする「宣⾔的設定」 + デプロイした結果を「宣⾔的に」記述した設定ファイルによるデプロイ + 確実なロールバックも容易に実現 ▶ 強⼒な⾃⼰回復機能「セルフヒーリング」 + 常に健全な数のアプリケーションが実⾏されている状態を保とうとする ▶ VM（仮想マシン）中⼼ではなく「コンテナ中⼼のインフラ」 + 個々のマシンの管理は⾏わなわず、クラスタを⼤きなマシンとして扱う + ロードバランサなどのITインフラを抽象化し、サービス構成の管理を⾃動化

Slide 51

Slide 51 text

@superbrothers 他のプラットフォームとの⽐較 ▶ Infrastructure as a Service ▶ VM, ディスク, ネットワーク Kubernetes ▶ Container as a Service ▶ コンテナの管理、実⾏ ▶ あらゆるアプリケーション Cloud Foundry ▶ Platform as a Service ▶ コードからデプロイ ▶ HTTP、API、Web OpenStack

Slide 52

Slide 52 text

▶ コンテナで⾃由度と抽象化をバランスよく実現する ▶ 抽象度が⾼く、⽣産性が⾼い ▶ ⼀⽅で⾃由度が低い物理インフラ OS サーバ仮想化ミドルウェアランタイムアプリケーション物理インフラ OS サーバ仮想化ミドルウェアランタイムアプリケーション物理インフラ OS サーバ仮想化ミドルウェアランタイムアプリケーションコンテナ化 IaaS Kubernetes PaaS ▶ ⾃由度は⾼いが管理するものが多い⾃由度⽣産性

Slide 53

Slide 53 text

Kubernetes のアーキテクチャとオブジェクト

Slide 54

Slide 54 text

@superbrothers Kubernetes のアーキテクチャ controller  Manager scheduler apiserver kubelet コンテナ  ランタイム etcd API kube-proxy ノード B .. マスタコンポーネントノード A ! kubectl

Slide 55

Slide 55 text

@superbrothers Kubernetes オブジェクトワークロードやITインフラを「アプリケーション指向」に抽象化したもので、開発者はオブジェクトをマニフェストと呼ばれる YAML または JSON 形式のファイルで記述する。 ▶ Pod: 複数のコンテナと複数のボリューム ▶ Label: 唯⼀のグルーピング機能 ▶ ReplicaSet: N個の Pod が実⾏されている状態を保つ ▶ Deployment: ローリングアップデート、ロールバック ▶ Service: 仮想IPとポート、サービスのエントリポイント

Slide 56

Slide 56 text

@superbrothers Pod（ポッド） ▶ 複数のコンテナと  複数のボリューム ▶ デプロイの最⼩単位 ▶ IP-per-Pod Pod A ボリュームコンテナコンテナ IP: 10.60.0.5

Slide 57

Slide 57 text

@superbrothers Pod A ボリュームコンテナコンテナノード1 ノード2 IP: 10.60.0.5 Pod B IP: 10.60.1.7 Pod C IP: 10.60.1.8 Podに含まれるコンテナは  必ず同じノード上で実⾏される各PodはフラットなネットワークのIPアドレスを持ち、ノードをまたいで通信できる

Slide 58

Slide 58 text

@superbrothers Pod（ポッド） ▶ 複数のコンテナと  複数のボリューム ▶ デプロイの最⼩単位 ▶ IP-per-Pod apiVersion: v1 kind: Pod metadata: name: nginx spec: containers: - name: nginx image: nginx:1.15.8 ports: - containerPort: 80

Slide 59

Slide 59 text

@superbrothers Label（ラベル） ▶ 唯⼀のグルーピング機構 ▶ セレクタによるクエリ + app=frontend Pod C app frontend Pod A app backend Pod B app frontend

Slide 60

Slide 60 text

@superbrothers Label（ラベル） ▶ 唯⼀のグルーピング機構 ▶ セレクタによるクエリ + app=frontend apiVersion: v1 kind: Pod metadata: name: nginx labels: app: frontend spec: containers: - name: nginx image: nginx:1.15.8 ports: - containerPort: 80

Slide 61

Slide 61 text

@superbrothers ReplicaSet（レプリカセット） ▶ N個のPodが実⾏されている状態を保つ ReplicaSet レプリカ数: 3  セレクタ: app=nginx ノードA PodテンプレートノードB Pod C app: nginx app: nginx Pod B app: nginx Pod A app: nginx 望ましい数: 3 現在の数: 3

Slide 62

Slide 62 text

@superbrothers ReplicaSet（レプリカセット） ▶ N個のPodが実⾏されている状態を保つ ReplicaSet レプリカ数: 3  セレクタ: app=nginx ノード1 Podテンプレートノード2 Pod C app: nginx app: nginx Pod A app: nginx 望ましい数: 3 現在の数: 2

Slide 63

Slide 63 text

@superbrothers ReplicaSet（レプリカセット） ▶ N個のPodが実⾏されている状態を保つ ReplicaSet レプリカ数: 3  セレクタ: app=nginx ノード1 Podテンプレートノード2 Pod C app: nginx app: nginx Pod D app: nginx Pod A app: nginx 望ましい数: 3 現在の数: 3

Slide 64

Slide 64 text

@superbrothers ReplicaSet ▶ N個のPodが実⾏されている状態を保つ apiVersion: apps/v1 kind: ReplicaSet metadata: name: nginx spec: replicas: 2 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.15.8 ports: - containerPort: 80 Podテンプレートレプリカ数

Slide 65

Slide 65 text

@superbrothers Pod A-A web:v1 Deployment（デプロイメント） ▶ ローリングアップデート ▶ ロールバック Deployment A containers - image: web:v1 レプリカ数: 2 ReplicaSet A containers - image: web:v1 レプリカ数: 2 Pod A-B web:v1

Slide 66

Slide 66 text

@superbrothers Deployment（デプロイメント） ▶ ローリングアップデート ▶ ロールバック Deployment A containers - image: web:v2 レプリカ数: 2 ReplicaSet A containers - image: web:v1 レプリカ数: 2 ReplicaSet B containers - image: web:v2 レプリカ数: 1 Pod A-A web:v1 Pod A-B web:v1

Slide 67

Slide 67 text

Slide 68

Slide 68 text

@superbrothers Deployment（デプロイメント） ▶ ローリングアップデート ▶ ロールバック Deployment A containers - image: web:v2 レプリカ数: 2 ReplicaSet A containers - image: web:v1 レプリカ数: 1 ReplicaSet B containers - image: web:v2 レプリカ数: 1 Pod A-B web:v1 Pod B-A web:v2 Deployment（デプロイメント）

Slide 69

Slide 69 text

Slide 70

Slide 70 text

@superbrothers Deployment（デプロイメント） ▶ ローリングアップデート ▶ ロールバック Deployment A containers - image: web:v2 レプリカ数: 2 ReplicaSet A containers - image: web:v1 レプリカ数: 0 ReplicaSet B containers - image: web:v2 レプリカ数: 2 Pod B-A web:v2 Pod B-B web:v2

Slide 71

Slide 71 text

@superbrothers Deployment ▶ ローリングアップデート ▶ ロールバック apiVersion: apps/v1 kind: Deployment metadata: name: nginx spec: replicas: 2 selector: matchLabels: app: nginx strategy: type: RollingUpdate rollingUpdate: maxSurge: 25% maxUnavailable: 25% template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.15.8 ports: - containerPort: 80 デプロイ戦略レプリカ数 Pod テンプレート

Slide 72

Slide 72 text

@superbrothers Service（サービス） ▶ 仮想IPとポート ▶ ラベルセレクタによる Pod のグルーピング ▶ サービスタイプ + ClusterIP + NodePort + LoadBalancer + Service my-svc タイプ: ClusterIP  セレクタ: app=nginx ポート: 8080/tcp→80/tcp clusterIP: 10.0.171.239 10.0.171.239:8080 Pod A IP: 10.60.0.5 Pod B IP: 10.60.1.7 10.60.0.5:80 10.60.1.7:80 ReplicaSet app: nginx app: nginx

Slide 73

Slide 73 text

@superbrothers Service nginx タイプ: ClusterIP  セレクタ: app=nginx ポート: 8080/tcp→80/tcp clusterIP: 10.0.171.239 10.0.171.239:8080 Pod A IP: 10.60.0.5 Pod B IP: 10.60.1.7 10.60.0.5:80 10.60.1.7:80 ReplicaSet app: nginx app: nginx nginx:8080 Pod α Service 名によるサービスディスカバリ

Slide 74

Slide 74 text

@superbrothers Service（サービス） ▶ 仮想IPとポート ▶ ラベルセレクタによる Pod のグルーピング ▶ サービスタイプ + ClusterIP + NodePort + LoadBalancer + apiVersion: v1 kind: Service metadata: name: nginx spec: type: ClusterIP selector: app: nginx ports: - protocol: TCP port: 8080 targetPort: 80

Slide 75

Slide 75 text

@superbrothers その他の主なオブジェクト ▶ Namespace: クラスタを論理的に分割する ▶ ConﬁgMap: アプリケーションと設定の分離 ▶ Secret: アプリケーションとシークレットの分離 ▶ PersistentVolume, PersistentVolumeClaim, StorageClass: 永続ボリューム ▶ StatefulSet: ステートフルアプリケーション ▶ Job: ワンショットジョブ ▶ CronJob: ジョブの定期実⾏ ▶ DaemonSet: 全てのノードで Pod を実⾏ ▶ Ingress: HTTP負荷分散、バーチャルホスト、TLS 終端 ▶ HolizontalPodAutoScaler (HPA): オートスケール

Slide 76

Slide 76 text

より詳しく知るには

Slide 77

Slide 77 text

No content

Slide 78

Slide 78 text

@superbrothers より詳しく知るには ▶ すぐ始めるには + Minikube: ローカルに開発⽤クラスタを構築 + Google Kubernetes Engine: 信頼と実績 ▶ 公式ドキュメント: kubernetes.io ▶ ⽇本コミュニティ Kubernetes Slack チャンネル: slack.k8s.io #jp-users ▶ ミートアップ: Kubernetes Meetup Tokyo - bit.ly/k8sjp ▶ 書籍 + ⼊⾨ Kubernetes（オライリー・ジャパン） + Mastering Kubernetes（O’Reilly） + Kubernetes 完全ガイド（インプレス）

Slide 79

Slide 79 text

まとめ

Slide 80

Slide 80 text

@superbrothers Kubernetes ▶ コンテナオーケストレーションツール + 複数のマシン（ノード）で構成されるクラスタに対して  コンテナ（アプリケーション）の配備、設定、管理を⾏う ▶ κυβερνήτης: ギリシャ語で操舵⼠ ▶ Cloud Native Computing Foundation（CNCF）がホストする  オープンソースプロジェクト ▶ オンプレでの利⽤はもちろん、  GCP や AWS、Azure でマネージドサービスとしても提供されている ▶ 「10年以上に渡りコンテナを本番環境で運⽤してきた Google の経験と  多くの企業によるコミュニティの優れたアイデアと⼿法が組み込まれている」

Slide 81

Slide 81 text

@superbrothers We’re hiring Yahoo Japan, Z Lab