大阪からKubernetes Meetup Tokyoに参加できるとのことで、こちらに参加してきました。 Kubernetesの生みの親である3人の内の1人のJoe Bedaから、Kubernetesの歴史の経緯について教えて頂きました。 その話がとてもわかりやすく、なるほどなと思ったので、ぜひとも共有したいと思います。
※ 以降の内容は、私なりの解釈が入っており誤った認識かもしれません。ご了承下さい。 発表の内容は全てYoutubeにありますので、そちらが正しいものです。ご参考下さい。 www.youtube.com
Who is Joe Beda ?
Joe Beda は、Kubernetes の co-founder（共同創設者/最初に開発した3人のうちの1人）/ 昨年 VMware に買収された Heptio の CTO / O'Reilly「Kubernetes: Up & Running」 (邦題「入門Kubernetes」）の共著者で、現在も Kubernetes をリードしている1人です。今回は、Kubernetes のこれまでと未来についてお話いただきます。
※ https://k8sjp.connpass.com/event/126207/
Kubernetesの最初のコミッターで、超有名人。 Googleで働いていたときは、KubernetesやCompute Engineを作っていたそうです。
Joeさん曰く、プラットフォームで開発する上でおもしろいことは、下記２点のバランスだと仰っていました。
- ユーザーが簡単に使ってもらえる事
- 想定していなかった使われ方があった場合の柔軟性
私なりの解釈で言うと、例えば、GCPというプラットフォームの中で、GKEを使うとします。 ボタンをポチポチするだけでクラスターが作成されますよね。簡単で使ってみたくなります。
ただ、簡単だけだと細かい要求を満たせないので、オプションを設定できるようにしたり、 カスタマイズしやすいものへ改善されていきます。柔軟性ってことでしょうか？ この柔軟性をしすぎると複雑になってしまい、ユーザーが使ってくれなくなる恐れがあります（マニアックなユーザーは残るかもしれないけど）。 そこのバランスが大切なのかなと思いました。
Joeさんの詳細な説明はこちらです。
The origins and future of Kubernetes (en/英語)
Joeさんは英語で話されてました。 CPCAmerica(?)の田中さんが通訳をされていたのですが、ものすごくわかりやすかったです。感謝です！ あと、記憶力はんぱねぇ...。
通訳さんの記憶力すごい…… #k8sjp
— Yusuke KUOKA (@mumoshu) May 31, 2019
※ 以下、@apstndb さんの要約Tweetを参考にしました。神!!!
@apstndbさんの訳がわかりやすくて、めっちゃ見てる。
— silverbirder (@silver_birder) May 31, 2019
#k8sjp #osaka
kubernetesの歴史
Borgの誕生
Googleでは、BigDataを処理するためのMapReduceを開発していました。 MapReduceを扱うために、GlobalWorkQueue(GWQ)というものを開発され、これは主にバッチのために作成されたものでした。そこからバッチだけでなく、リアルタイムに実行したい(検索など)サービスに対応するために生まれたのがBorgだそうです。 Googleのような大規模な検索であれば、数％の効率Upでも大きなコスト削減につながるメリットがあります。 これが、Kubernetesの元となりました。
Kubernetesの誕生
GoogleでBorgを開発を進めていく中で、世の中は仮想マシンを扱うユーザーが多かったそうです。 Borgはプロプライエタリなソフトウェアだったため、Borgの世界を知ってほしい、開発者を引き込みたいという願いから、 OSSとしてKubernetesが誕生しました。 またKubernetesは、APIドリブンで開発者の生産性を上げるというのが先で、効率やセキュリティは後からついてきたそうです。
Kubernetesの魅力
Kubernetesとは、「コンテナオーケストレーター」と多くの人は知っていると思います。普及した大きなポイントですね。 他の観点で「１つのデータベースだけでクラスタを管理している設計」が魅力的だという話がありました。 （勝手な解釈かもしれません。すみません）
Kubernetesでは、クラスタの状態を管理するために分散型KVSであるetcdを使っています(その他の状態管理はキャッシュしているそうです。)。 etcdには、APIServerを経由しなければアクセスできないため、一貫したデータの維持が実現できます。 そのetcdの周りにある、ビジネスロジックを実現するコントローラー(Scheduler, Controller Manager)が価値を提供します。 例えば、PodをNodeにアサインしたり、エンドポイントを提供したり、レプリケーションしたりなどなど...。
kubernetesのcontrol planeである、APIServer, Scheduler, Controller Managerがあれば、シングルノードでもマルチノードでも動きます。 kubernetesをDockerForMacで動かしたときは、そういえばシングルノードでしたね。マルチノードってイメージでしたけど。
Kubernetesはコンテナオーケストレーションとよく言われますが、事前にすべてがプランされたオーケストレーションではなく、ジャズのように即興で計画して組み立てていくものに近い思想だそうです。 私は音楽に疎い人なのですが意味は理解しました。（笑）性格的には即興は苦手っす。
CRDとOperators
PodやReplication,Deploymentなど様々なリソースがあります。 ただ、Kubernetes が持っていないものを実装するにはどうすればよいのでしょうか。 そこで、Custom Resource Definitions (CRD)です。 なんだそれは...?
要は、PodやDeploymentのようなリソースを独自に作ることができるのですね。おぉなんだそれ！ 独自に機能を作るためには、Custom Resource と Costom Controllerが必要になり、両方をあわせて Operatorsというものが生まれました。
例えば、下記のようなものがあります。 github.com github.com
Yahooでは、gimbalというOSSを使ってKubernetesを導入したみたいです。 github.com techblog.yahoo.co.jp
詳しくは分かりませんが、こういった拡張しやすい機能があるおかげでドンドン普及するのだなと勉強になりました。
Q&A
Q1. StatefulSets には今回触れられなかったが、どういう扱いなのか
StatefulSets には今回触れられなかったが、どういう扱いなのかという質問。
— _ (@apstndb) May 31, 2019
StatefulSets はデータベースなどに使えるが、 Kubernetes のように動的に変化する環境で何が起こるかを理解して使う必要がある。 Operators のようなものを使う必要もあると。#k8sjp #yjmu
Q2. スケーラビリティに関して
回答が難しい…
— _ (@apstndb) May 31, 2019
スケーラビリティに関してはノード数5000台を現在の目安にしているが、 Pod 数とかによっても変わる。
必要に応じてマルチクラスタでシャーディングして解決することも考える必要がある。#k8sjp #yjmu
Q3. Kubernetes はなぜ etcd を使っているか
Kubernetes はなぜ etcd を使っているか。Kubernetes が etcd を使っているところで Borg は Google internal な Chubby を使った。OSS でいう ZooKeeper でいわゆる Paxos ベースですね。#ymju #k8sjp
— _ (@apstndb) May 31, 2019
Kubernetes ではロジックを含んだ DB は避けたかったが、一貫性は必須だった。 ZooKeeper も検討したけど非常に複雑なので、当時 CoreOS が開発していた etcd を採用した。
— _ (@apstndb) May 31, 2019
もしもやりなおすとしても etcd を選ぶだろうけど、差し替えられるようにすることは考えたかもという話。#ymju #k8sjp
Controller が使うことを考えると、 etcd における変化を watch できる機能が重要だったという話 #ymju #k8sjp
— _ (@apstndb) May 31, 2019
Q4. Virtual Kubelet とか k3s みたいなエッジで活用する動きがコミュニティでは感じられるが、どう見ている?
Virtual Kubelet や k3s は既存の Kubernetes のコンポーネントではうまく要件を致さないようなところでコンポーネントを置き換えることで要件に対応する。これは API ドリブンな Kubernetes の設計をうまく生かしている。#ymju #k8sjp
— _ (@apstndb) May 31, 2019
Kubernetes はデータセンターの中で動かすことが前提なので、 IoT のエッジで動かすものとしてはベストなのかは答えが出ていないという感じ#ymju #k8sjp
— _ (@apstndb) May 31, 2019
そのほか
参加者からの質問は、どれも鋭いものばかり。 適度な質問をしたいなとつぶやきました...。届かなかったけど...。
kubernetesの正しい発音を聞いたら笑われるかな。
— silverbirder (@silver_birder) May 31, 2019
#k8sjp #osaka
Osaka会場
会場提供は、株式会社Aimingさんでした。
会場場所は、グランフロント大阪タワーBの18階にありました。(高い!) 今回使わさせて頂いた場所は、会議室でしょうか。 30,40人ぐらい入れるスペースで、清潔感がありました。
東京との中継は、ときどき音声が途切れてしまうときもありますが、しっかりと写っていました。 ただ、コンテンツとしては、YouTubeにあげらているので、わざわざOsakaに出席しなくても良いのでは？とも思いました。
しかし、それでもOsakaに出席しても良い面もあるのかなと思います。
- 他の方とのコミュニケーションが取れる
- 一緒に発表を聞いて議論ができる
まあ、私はコミュ障なので、ほぼなかったですが...。
改善ポイントとしては、中継地からも質問ができるようになってくれたら良いなと期待しています。
最後に
Kubernetesについて、どういった経緯で誕生したのか、またCRDについても勉強になりました。 また、Kubernetesとは違うのですが、「OSSのちから」というものがエンジニアの世界では大事だと強く感じました。 普段エンジニアが開発する上で、ほぼ間違いなくOSSを使っています。 エンジニアにとって、OSSは不可欠な存在であり、利用するばかりです。
Googleがしたように、「広く使ってほしい、エンジニアを巻き込みたい」という願いから、 OSSとしてKubernetesが広まっていった一要因と思いました。これが有償ならどうだったのでしょうか。 ここまで普及したのでしょうか。
OSSに貢献する企業は、日本にも多く存在します。 個人でもOSSへ貢献できますし、OSS Gateという初心者向けのものもあります。 Kubernetesのコントリビューターは、ちょっとハードルが高いですが、 私もエンジニアとしてOSSへ貢献し続けていこうと思います。
そのほか
拙い文章なのに、最後まで読んでいただき、ありがとうございます。 twitterをしていますので、フォローしてもらえるとうれしいです。(silver_birder)