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

大規模環境でのコンテナの利用において、Kubernetes がデファクトスタンダードになりました。
本セッションでは、Kubernetes とは何か、なぜ Kubernetes なのか、
また具体的に何ができるのかをデモを通じて紹介します。
また Yahoo! JAPAN は、2017年10月頃から本番環境で Kubernetes を利用しています。
その後1年強経過し、現在どのような状況なのか、どのように利用しているのかを紹介します。

https://yahoo-osaka.connpass.com/event/113370/

Transcript

1. Mix Leap Study #32 - めっちゃわかるAIとKubernetes(GCPUG共催) 2019/1/31 Kazuki Suda <ksuda@zlab.co.jp> @superbrothers めっちゃわかる Kubernetes！
2. Kazuki Suda / @superbrothers ▶ ソフトウェアエンジニア@Z Lab & Yahoo Japan ▶ 第８代黒帯〜インフラストラクチャ Kubernetes〜 ▶ Kubernetes Meetup Tokyo 主催 ▶ Cloud Native Deep Dive 主催
3. ゼットラボ株式会社 ▶ 2015年に設⽴されたヤフー株式会社100%⼦会社 ▶ インフラ基盤技術の調査・研究開発 ▶ https://zlab.co.jp/ ▶ https://qiita.com/organizations/zlab
5. @superbrothers アジェンダ 1. Kubernetes とはなにか 2. ヤフーと Kubernetes 3. コンテナとはなにか 4. なぜコンテナなのか 5. なぜ Kubernetes なのか 6. なぜ Kubernetes なのか（機能⾯） 7. Kubernetes のアーキテクチャとオブジェクト 8. より詳しく知るには
6. Kubernetes とはなにか
7. @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
8. @superbrothers Kubernetes ▶ 初期は Google のソフトウェアだったが、その後
 Cloud Native Computing Foundation（CNCF）に譲渡され、
 現在は CNCF がホストするオープンソースプロジェクト + CNCF は Linux Foundation 傘下の組織 ▶ オンプレでの利⽤はもちろん、
 GCP や AWS、Azure でマネージドサービスとしても提供されている ▶ 「10年以上に渡りコンテナを本番環境で運⽤してきた Google の経験と
 多くの企業によるコミュニティの優れたアイデアと⼿法が組み込まれている」
9. @superbrothers ! ノードA ノードB ノードC を2つ実⾏したい を実⾏するのに 適切なノードは どれだろう？ は1CPU、1GBメモリが必要
10. @superbrothers https://twitter.com/brendandburns/status/585479466648018944 ▶ Kubernetes: クーバネティス、クバネテス ▶ k8s: ケイエイツ、けいはちえす
11. ヤフーと Kubernetes
12. @superbrothers ヤフーと Kubernetes 2017年10⽉頃から⼀部サービスの本番環境として Kubernetes の利⽤を
 開始。現在では、多くのサービスで利⽤している。 ▶ 10 データセンタ ▶ 100,000+ サーバ ▶ 160+ OpenStack クラスタ ▶ 200+ Kubernetes クラスタ
13. ヤフー株式会社向けにゼットラボが開発するマネージド Kubernetes サービス。
 オンプレミスの OpenStack 環境に Kubernetes クラスタを作成、管理する。 ▶ セルフサービス ▶ マネージド ▶ スケーラブル ▶ シングルテナント ヤフーの Kubernetes-as-a-Service
14. @superbrothers Japan ContainerDays v18.04 2018/4/17 OpenStack Days Tokyo, Cloud Native Days Tokyo 2018 2018/8/3
15. コンテナとはなにか
16. https://www.flickr.com/photos/aidanwojtas/34885389822
17. @superbrothers Linux コンテナ システムの他の部分から分離されたプロセス ▶ マシンのリソースを共有していることでプロセスが正常に実⾏されない + ファイルシステム、ネットワーク、PID、ユーザなど + 例えば、常に 8080番ポートを使えることを保証できない + CPU、メモリ、ファイルシステム + うるさい隣⼈問題
18. @superbrothers Linux コンテナ プロセスがシステムの他の部分に影響されないように隔離し、制限する ▶ 隔離（isolation）: Linux namespaces + 他のシステムからファイルシステムやネットワークを隔離する ▶ 制限（limit）: Linux cgroups + CPU やメモリといったリソースを使⽤を制限
19. @superbrothers Docker コンテナの実⾏と管理を⾏うソフトウェア ▶ コンテナイメージのビルドから、配信、実⾏を⾏う + アプリケーションの実⾏に必要なランタイムやライブラリ、ソフトウェアな どを全て含む ▶ ソフトウェア開発の標準化された単位にアプリケーションをパッケージ化する + BUILD（組み⽴て）→ SHIP（出荷）→ RUN（実⾏）
20. @superbrothers BUILD（組み⽴て）/ Dockerfile ▶ テキスト形式のコンテナイメージの構成を記述するファイル ▶ 開発者は docker build コマンドを使い、複数のコマンド⾏の命令を順次実⾏ し、イメージを作成する
21. @superbrothers SHIP（出荷）/ コンテナレジストリ ▶ ビルドしたコンテナイメージがアップロードされるレジストリ ▶ パッケージでいうところのパッケージ管理システムに相当する ▶ docker pull コマンドでレジストリからイメージを取得できる
22. @superbrothers RUN（実⾏）/ Docker デーモン ▶ コンテナの実⾏を管理するデーモンプロセス ▶ パッケージでいうところのプロセス管理ツールに相当する ▶ docker コマンドラインツールから操作する
23. なぜコンテナなのか
24. @superbrothers なぜコンテナなのか ▶ 素早いアプリケーションの作成と展開 + コンテナイメージの作成の容易さと効率性は、仮想マシンイメージの使⽤と ⽐較して向上する ▶ 開発（Dev）と運⽤（Ops）の分離 + デプロイ時ではなくビルド時にコンテナイメージを作成することで、アプリ ケーションをインフラから切り離す
25. @superbrothers なぜコンテナなのか ▶ 継続的な開発とインテグレーション、デプロイメント + 信頼性の⾼いひんぱんなコンテナイメージのビルドと展開が迅速かつ容易な ロールバック（イメージ不変性による）を提供する ▶ 開発、テスト、本番の環境の⼀貫性 + ラップトップでも本番でも同じように動作する
26. @superbrothers コンテナとは ▶ アプリケーションにイミュータブル（不変）でポータブルな性質（いつどこで 実⾏しても同じものとなる）をもたらした ▶ オーケストレータによる複数マシンでのアプリケーションの⾃動的なスケ ジューリングと実⾏、管理を可能にした + コンテナだけの利⽤では、開発者がマシンを「丁寧に」管理する必要がある
27. なぜKubernetesなのか
28. @superbrothers Kubernetes はオープンである ▶ オープンソースソフトウェア + github.com/kubernetes/kubernetes (Apache License 2.0) ▶ オープンデザイン + github.com/kubernetes/community ▶ オープンコミュニティ + Cloud Native Computing Foundation + Special Interest Groups (SIGs) ▶ Slack, StackOverflow, 全世界で300以上のミートアップ + Kubernetes Slack ワークスペース（slack.k8s.io） #jp-users + Kubernetes Meetup Tokyo
29. @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
30. @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
31. @superbrothers https://www.flickr.com/photos/143247548@N03/31365923847/
32. @superbrothers https://www.flickr.com/photos/143247548@N03/31365923847/ https://kccna18.sched.com/event/GsxP/keynote-kubernetes-project-update-janet-kuo-software-engineer-google
33. https://kccna18.sched.com/event/GsxP/keynote-kubernetes-project-update-janet-kuo-software-engineer-google
34. @superbrothers なぜ Kubernetes なのか ▶ Kubernetes はオープンである ▶ Kubernetes はポータブルである ▶ Kubernetes は成⻑している（今も）
35. なぜKubernetesなのか（機能⾯）
36. @superbrothers なぜ Kubernetes なのか ひんぱんなデプロイに耐えられる⾮常に優れた機能を持つ ▶ これまでの開発は、アプリケーションのデプロイに数⽇、数週間かかることも ▶ 時間のかかるデプロイは、問題があったときの修正も遅くなる ▶ 逆にいうとひんぱんなデプロイは問題をすぐに修正でき、リスクを取れる + 1つひとつのデプロイが軽くなり（ボリューム、リスク） + 間違いから迅速に復旧できるようになり + より多くのリスクをとることができる ▶ 開発した成果をいかにはやく本番に届けられるかが競合に勝つための⼤きな要 因になっている
37. @superbrothers ひんぱんなデプロイに耐えられる⾮常に優れた機能 ▶ ひんぱんなデプロイを可能にする「宣⾔的設定」 ▶ 強⼒な⾃⼰回復機能「セルフヒーリング」 ▶ VM（仮想マシン）中⼼ではなく「コンテナ中⼼」のインフラ
38. @superbrothers ひんぱんなデプロイを可能にする「宣⾔的設定」 これまでの A を実⾏してから B を実⾏するような⼀連の⼿続きによるデプロイは、 各⼿続きが以前の状態に依存する。 ▶ もしホストの⼀部だけ変更が加えられていても確実にデプロイが成功すること が保証できるか？ ▶ アプリケーションに問題があったときに確実にロールバックできるか？
39. @superbrothers ⼀連の⼿続きによるデプロイ B A C ⋆ ♥ 操作の順序が変わっても必ず C の状態までたどり着ける？ A まで正確にロールバックするには？ AからBの変更 BからCの変更
40. @superbrothers 宣⾔的設定によるデプロイ デプロイした結果のアプリケーションの「望ましい状態」を記述した設定ファイ ルを反映する。 ▶ 事前にどんな変更が加えられていても、ゼロからの構築であっても必ず設定ファ イルに記述された「望ましい状態」になる ▶ ロールバックは以前の戻したい時点での設定ファイルを反映するだけになる
41. @superbrothers 宣⾔的設定によるデプロイ A C C 望ましい状態 が記述された設定ファイル AからCになるように⾃律的に動作する
42. @superbrothers 宣⾔的設定によるロールバック C A A ロールバックは以前の状態の設定ファイルを反映するだけ CからAになるように⾃律的に動作する
43. @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）
44. @superbrothers 強⼒な⾃⼰回復機能「セルフヒーリング」 障害により VM やマシンは壊れる。壊れた VM 上でサービスの継続に必要なアプリ ケーションが実⾏されていたらどうするか？ 望ましい状態: 3 2 現在の状態: 2 1
45. @superbrothers Kubernetes はクラスタの状態を継続的に望ましい状態であり続けようと動作する。 ノード（マシン）が数台ダウンしてもアプリケーションの実⾏に必要なリソースが 残っている限り、翌営業⽇に復旧すればいい。 強⼒な⾃⼰回復機能「セルフヒーリング」 望ましい状態: 3 2 現在の状態: 3 2
46. @superbrothers VM中⼼ではなく「コンテナ中⼼」のインフラ Kubernetes は、複数の VM (ノード) を1つの⼤きなリソースプール (クラスタ) とし て扱うことで VM を抽象化する。 ▶ クラスタに対してコンテナをデプロイすると、そのコンテナの実⾏に必要なリ ソースが空いているノードにスケジュールされる ▶ 開発者は、特定のコンテナがクラスタ内のどのノードで実⾏されているかを気 になる必要がない
47. @superbrothers クラスタはノードの集合体 クラスタ CPU: 8 RAM: 30GB ノード CPU: 80 RAM: 300GB GPU: 3 CPU: 8 RAM: 30GB GPU: 3 異なるタイプのマシンも同居できる
48. @superbrothers サーバリソースの隙間問題の解消 各サーバのリソースの隙間を 有効活⽤できない アプリケーションの CPU 使⽤量 Kubernetes スケジューラがリソース効率を 考慮した配置でコンテナをスケジュール コンテナ化により同居できるようになり リソースを有効活⽤できる
49. @superbrothers VMの抽象化に加えて、ITインフラも抽象化 VM の抽象化に加えて、サービスの構成を「アプリケーション指向」に抽象化され た Kubernetes オブジェクトで扱う。 ▶ ロードバランサや永続ストレージなどの IT インフラを抽象化 ▶ ステートレスからステートフルまでさまざまな種類のアプリケーションに対応 する多くのオブジェクトが⽤意されている
50. @superbrothers ひんぱんなデプロイに耐えられる⾮常に優れた機能 ▶ ひんぱんなデプロイを可能にする「宣⾔的設定」 + デプロイした結果を「宣⾔的に」記述した設定ファイルによるデプロイ + 確実なロールバックも容易に実現 ▶ 強⼒な⾃⼰回復機能「セルフヒーリング」 + 常に健全な数のアプリケーションが実⾏されている状態を保とうとする ▶ VM（仮想マシン）中⼼ではなく「コンテナ中⼼のインフラ」 + 個々のマシンの管理は⾏わなわず、クラスタを⼤きなマシンとして扱う + ロードバランサなどのITインフラを抽象化し、サービス構成の管理を⾃動化
51. @superbrothers 他のプラットフォームとの⽐較 ▶ Infrastructure as a Service ▶ VM, ディスク, ネット ワーク Kubernetes ▶ Container as a Service ▶ コンテナの管理、実⾏ ▶ あらゆるアプリケーション Cloud Foundry ▶ Platform as a Service ▶ コードからデプロイ ▶ HTTP、API、Web OpenStack
52. ▶ コンテナで⾃由度と抽象化を バランスよく実現する ▶ 抽象度が⾼く、⽣産性が ⾼い ▶ ⼀⽅で⾃由度が低い 物理インフラ OS サーバ仮想化 ミドルウェア ランタイム アプリケーション 物理インフラ OS サーバ仮想化 ミドルウェア ランタイム アプリケーション 物理インフラ OS サーバ仮想化 ミドルウェア ランタイム アプリケーション コンテナ化 IaaS Kubernetes PaaS ▶ ⾃由度は⾼いが管理す るものが多い ⾃由度 ⽣産性
53. Kubernetes のアーキテクチャとオブジェクト
54. @superbrothers Kubernetes のアーキテクチャ controller
 Manager scheduler apiserver kubelet コンテナ
 ランタイム etcd API kube-proxy ノード B .. マスタコンポーネント ノード A ! kubectl
55. @superbrothers Kubernetes オブジェクト ワークロードやITインフラを「アプリケーション指向」に抽象化したもので、開発 者はオブジェクトをマニフェストと呼ばれる YAML または JSON 形式のファイルで 記述する。 ▶ Pod: 複数のコンテナと複数のボリューム ▶ Label: 唯⼀のグルーピング機能 ▶ ReplicaSet: N個の Pod が実⾏されている状態を保つ ▶ Deployment: ローリングアップデート、ロールバック ▶ Service: 仮想IPとポート、サービスのエントリポイント
56. @superbrothers Pod（ポッド） ▶ 複数のコンテナと
 複数のボリューム ▶ デプロイの最⼩単位 ▶ IP-per-Pod Pod A ボリューム コンテナ コンテナ IP: 10.60.0.5
57. @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アドレスを持ち、ノードをまたいで通信できる
58. @superbrothers Pod（ポッド） ▶ 複数のコンテナと
 複数のボリューム ▶ デプロイの最⼩単位 ▶ IP-per-Pod apiVersion: v1 kind: Pod metadata: name: nginx spec: containers: - name: nginx image: nginx:1.15.8 ports: - containerPort: 80
59. @superbrothers Label（ラベル） ▶ 唯⼀のグルーピング機構 ▶ セレクタによるクエリ + app=frontend Pod C app frontend Pod A app backend Pod B app frontend
60. @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
61. @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
62. @superbrothers ReplicaSet（レプリカセット） ▶ N個のPodが実⾏されている状態を保つ ReplicaSet レプリカ数: 3
 セレクタ: app=nginx ノード1 Podテンプレート ノード2 Pod C app: nginx app: nginx Pod A app: nginx 望ましい数: 3 現在の数: 2
63. @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
64. @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テンプレート レプリカ数
65. @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
66. @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
67. @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 Pod B-A web:v2
68. @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（デプロイメント）
69. @superbrothers Deployment（デプロイメント） ▶ ローリングアップデート ▶ ロールバック Deployment A containers - image: web:v2 レプリカ数: 2 ReplicaSet A containers - image: web:v1 レプリカ数: 1 ReplicaSet B containers - image: web:v2 レプリカ数: 2 Pod A-B web:v1 Pod B-A web:v2 Pod B-B web:v2
70. @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
71. @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 テンプレート
72. @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
73. @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 名によるサービスディスカバリ
74. @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
75. @superbrothers その他の主なオブジェクト ▶ Namespace: クラスタを論理的に分割する ▶ ConfigMap: アプリケーションと設定の分離 ▶ Secret: アプリケーションとシークレットの分離 ▶ PersistentVolume, PersistentVolumeClaim, StorageClass: 永続ボリューム ▶ StatefulSet: ステートフルアプリケーション ▶ Job: ワンショットジョブ ▶ CronJob: ジョブの定期実⾏ ▶ DaemonSet: 全てのノードで Pod を実⾏ ▶ Ingress: HTTP負荷分散、バーチャルホスト、TLS 終端 ▶ HolizontalPodAutoScaler (HPA): オートスケール
76. より詳しく知るには
78. @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 完全ガイド（インプレス）
79. まとめ
80. @superbrothers Kubernetes ▶ コンテナオーケストレーションツール + 複数のマシン（ノード）で構成されるクラスタに対して
 コンテナ（アプリケーション）の配備、設定、管理を⾏う ▶ κυβερνήτης: ギリシャ語で操舵⼠ ▶ Cloud Native Computing Foundation（CNCF）がホストする
 オープンソースプロジェクト ▶ オンプレでの利⽤はもちろん、
 GCP や AWS、Azure でマネージドサービスとしても提供されている ▶ 「10年以上に渡りコンテナを本番環境で運⽤してきた Google の経験と
 多くの企業によるコミュニティの優れたアイデアと⼿法が組み込まれている」
81. @superbrothers We’re hiring Yahoo Japan, Z Lab