6 周年を迎えた Kubernetes

土曜日に、Kubernetes プロジェクトは開始から 6 周年を迎えました。この夏には他のマイルストーンも予定されているのですが、今日は、このプロジェクトでコードが初めて書かれたときのことなど、今までの 6 年間の出来事の中で Red Hat のお気に入りを共有する機会にしたいと思います。このプロジェクトがこれからも長く続いていきますように。

Red Hat クラウド・プラットフォーム シニアバイスプレジデント Ashesh Badani (アシェシュ・バダニ)

Kubernetes とそのエコシステムが形になるかなり前、おそらくまだ自分たちの準備もできていないときに、私たちは大きな賭けに出ました。OpenShift は 2012 年から市場に出ていましたが、それを駆動させる「フライホイール」が欠けていることはわかっていました。だから標準化されたコンテナランタイム、フォーマット、オーケストレーションを再設計するチャンスを見出したとき、私たちはそこにすべてを賭けたのです。ちょうど OpenShift 3 の一般提供を開始するタイミングだったのですが、そのリリースに合わせて OpenShift で独自のサービスプラットフォームを立ち上げた Amadeus と提携できたのは信じられないほど嬉しいことでした。

過去 5 年間に、多くの組織が Red Hat や Kubernetes コミュニティと連携を始めました。その広がりを見ると、本当に驚くべきことだという思いを強くします。世界最大級の銀行、航空会社、ホテル、物流会社、さらには政府機関でさえもこのプロジェクトの進路を完全に受け入れ、ミッションクリティカルなアプリケーションを Kubernetes プラットフォームに委ねています。今は、アナリティクスと AI/ML のユースケースが急増しています。5 年前には、こうなることを想像すらできませんでした。しかし、私が今でも思い出して温かい気持ちになるのは、Kubernetes が現れる前に OpenShift を採用した最初期のお客様各社に、私たちがコンテナ・オーケストレーションで何をしようとしているのかを説明しに行ったときのことです。訪問したお客様のほぼすべてが、Kubernetes ベースにアーキテクチャに移行しようという Red Hat の取り組みを受け入れるだけでなく、そこから将来的に目指そうとしている方向性にも賛同してくださったのです。これはまったく予期していなかった、本当に嬉しいことでした。あとはご存知の通り、お客様は 2,000 社を超えて現在も増え続けており、Kubernetes はあらゆるクラウド環境にデプロイされています。

Red Hat OpenShift および Kubernetes 向けコンテナ化アプリケーションインフラストラクチャ アーキテクト Clayton Coleman (クレイトン・コールマン)

Red Hat ディスティングイッシュドエンジニア Derek Carr (デレク・カー)

Kubernetes の歴史を振り返るとき、しっかりした技術者たちがいてくれたことが、コミュニティとしていかに幸運であったかについて考えます。彼らは連携して新しい視点から問題を解決する権限を与えられ、多様な技術的背景を持っていました。私は Kubernetes で初めてオープンソースと関わったのですが、プロジェクトの早い段階でプルリクエストを読んだときの興奮を覚えています。私は大好きなテレビ番組の新しいエピソードを見るときのようにワクワクしていました。現在ではコアプロジェクトのプルリクエストが 9 万を超えており、もうすべての変更を追いかけることはできませんが、コミュニティを構築するために私たちが行ってきた取り組みを非常に誇りに思っています。しばしば、私はプロジェクトの最初期を振り返り、その成功が決して保証されていなかったことを思い出します。私たちはエンジニアリング・コミュニティとして分散システムの問題を調査していましたが、プロジェクトとしての私たちの成功は、各エンジニアが実際に共有した一連の価値観と強く結び付いていました。

私がプロジェクトに対して行った最初期の貢献の 1 つは、名前空間リソースの導入でした。関連するプルリクエストの検証コードを振り返ると、プロジェクトの 4 番目の API リソースであり、オープンソース・コミュニティを通じて追加された最初の API だったように思えます。最初のメンテナーたちに私を信頼してもらう必要があり、その信頼はメンターシップを通じて得られましたが、そのメンターシップにはずっと感謝しています。名前空間サポートを実装するには、アドミッション・コントロール、ストレージ API、クライアント・ライブラリ・パターンなどの概念を構築する必要がありました。これらの部材は、プロジェクトの何世代にもわたるリーダーたちから力を与えられたエンジニアの非常に大きなコミュニティから助けを借りて、カスタムリソース定義、Webhook、Client-go に進化しました。これにより、分散システムの問題を解決するための広範なエコシステムを、Kubernetes に基づいて構築することが可能になり、その恩恵はコアプロジェクトで想定していたよりはるかに幅広いユーザーに行き渡りました。

名前空間サポートの導入に関するこの初期の経験を振り返ると、Kubernetes プロジェクトの価値観、つまり、 一元化よりも分散、製品や企業よりもコミュニティ、プロセスよりも自動化、排他的であることよりも包括的であること、停滞よりも進化が優れているという考え方が実践されていることがよくわかります。Kuberentes がこれらの価値観を実践し続ける限り、私たちはこれからも末永く Kubernetes の誕生日を祝い続けることができるでしょう。

Red Hat コアクラウドプラットフォーム シニアバイスプレジデント兼ゼネラルマネージャー Joe Fernandes (ジョー・フェルナンデス)

私は過去 6 年間、Kubernetes について多くのことを書いてきました。その内容は Red Hat が Kubernetes を選択した理由から、Red Hat が Kubernetes でどのような構築を行っていたか、そして Red Hat Summit 2015 で、Kubernetes ネイティブのコンテナプラットフォームとしてゼロから完全に再構築された OpenShift 3 をローンチしたときのことに至るまで様々です。また、1.0 のリリースが予定日に間に合わなかったために、やむを得ず OpenShift 3 を Kubernetes 0.9 でローンチしなければならなくなったこともありました。しかし、ローンチの前後にお客様を訪問して Kubernetes を紹介したときのことは、いい思い出として残っています。

Red Hat のお客様はみな高度な技術と情報を持っていて、製品の機能とメリットの観点からだけでなく、製品の動作に関する下位レベルの詳細まですべて知りたいと考えています。私は常にそれを有難く思っていますが、プロダクトマネージャーやセールスチームは完璧な準備を整えて臨まなくてはなりません。私たちは、ポッドからサービス、レプリケーションコントローラ、ヘルスチェック、デプロイ、スケジューリング、イングレスなど、Kubernetes の主要な機能を説明するプレゼンテーションを用意しました。Kubernetes は、技術に最も熟達したユーザーでも最初から簡単に理解できるものではありません。しかし最終的には、ばらばらだったピースがはまりだし、これらの基本的なプリミティブの機能が持つパワーと、それによってアプリケーションのデプロイにもたらされる自動化の可能性を理解する瞬間が必ずやってきます。幸運なことに、私はこれまでの 6 年間、非常に多くのお客様との会話を通じて、その瞬間を何度も目の当たりにしてきました。そしてさらに、そうしたお客様の多くが OpenShift ユーザーになり、きわめて困難でミッションクリティカルなアプリケーションでそれらのメリットを実現するのを見ることができました。その瞬間が私は大好きでしたが、それは今でも私たちの製品チーム全体のモチベーションになっています。

Red Hat ソフトウェアエンジニア Maciej Szulik (マチェイ・ズーリック)

私が初めて本格的にオープンソースにかかわったのが、Kubernetes プロジェクトでした。それまでに何度かパッチに携わったことはありましたが、すべてマイナーな修正でした。私は友人との会話でこう話したことを覚えています。「今やっていることは、以前関わったことがあるプロジェクトとまったく同じだが、今のプロジェクトはオープンで誰でも利用できるんだ。しかもこのプロジェクトではこれまで以上に多くの開発者やユーザーからフィードバックを収集できるんだ。」これは Cron Jobs を開発していたときのことです。Cron Jobs はその後、Scheduled Jobs と呼ばれるようになった監査機能の初期バージョンで、今ではもっと便利で機能豊富なものがあるため、おそらくもう誰も覚えていないと思います。

このプロジェクトに参加することで、私は職業人としても人間としても成長できました。分散システムや Go プログラミングなどについて、とても多くのことを学びました。私は世界中にたくさんの友達ができ、ここ数年、ほぼすべての KubeCon を見る機会に恵まれています。私はこの素晴らしい体験ができたことに本当に感謝しています。これからこのプロジェクトがどこに向かい何を見せてくれるのか、それを知る日が待ちきれません。

Red Hat シニアプリンシパルソフトウェアエンジニア Paul Morie (ポール・モリー)

「コア」API リソースと、Secrets、Configmaps、Downward API などの機能を追加したことについては、たくさんのいい思い出があります。それらを使用している人たちを見ると、いまだにその頃のことを思い出して懐かしくなります。

また、開発者としてそれらにかかわる中で、特に思い出深い変更、リファクタリング、出来事もあります。まず思い浮かぶのは、コードに残した「keep the space shuttle flying」(スペースシャトルを飛ばし続けよ) というコメントが、何年も経ってからソーシャルメディアで多くの注目を集めたことです。このコメントは永続ボリュームシステムのオーバーホールを行った際に書いたもので、今後ロジックの単純化を行う際には細心の注意を払うようにと、開発者に向けて残したメモでした (単純化を行ったために、そのオーバーホールにかかわった我々コミュニティメンバーの間で混乱が生じたため)。その 2 年後、それを見つけて面白がった人が共有し、ソーシャルメディアで楽しい議論が展開されました。スペースシャトルのとてもかわいい絵を描いた人もいましたが、それを見るたびに頬が緩みます。

個人的にもう 1 つ、私が非常に満足しているのは、kubelet のリファクタリングです。完了するまでにいくつかのリリースが必要でしたが、時間の経過に十分に耐えられるものができたと思います。Download API の PodIP のバグを追いかけていたときだったと思うのですが、5,000 行を超える kubelet.go ファイルのコードがどうしようもなく複雑だったので、何とかしてもう少しすっきりさせられないものかと考え、どうしてもやらずにはいられなくなりました。最終的にはこの巨大ファイルをリファクタリングしていくつかのわかりやすい小さめのファイルに分割し、理解とメンテナンスが容易になりました (と私は思っています)。大規模なハッキングなどはせず、ファイル間でコードを移動するだけでしたが、記憶に残る思い出深い作業になりました。

Kubernetes コミュニティではたくさんの素晴らしいことが行われました。しかしそれとは別に、やらなかったからこそ Kubernetes の成功につながったこともあると私は思っています。Kubernetes は、コンテナイメージ、構成言語、ミドルウェアなどのビルドエンジンを公式に定めていません。これは大きな成功であり、Kubernetes が非常に広く導入されている理由でもあると思います。これらのことは決して当たり前に得られたものではありません。このコミュニティには、プロジェクトスコープの管理に関して賢明な (時には厳しい) 選択ができる素晴らしいリーダーシップがありました。

Kubernetes コミュニティは、見つかったありとあらゆる問題 (少なくとも、ある時点で一般的な問題) を解決しようとするのではなく、賢明な投資を行って、Kubernetes の自由な拡張を可能にし、後にそれをさらに簡単にできるようにしました。たとえば 2016 年には、kubernetes/kubernetes プロジェクトの外部でサービスカタログ SIG の API を開発する際の選択肢が非常に限られており、独自の API サーバーを作成する必要がありました。今ではカスタムリソース定義 (CRD) を記述すれば、数分後には、はるかに少ない労力で、きちんと機能する API ができあがります。これは本当に素晴らしいことです。

これらの拡張メカニズムにおいて Kubernetes コミュニティが行った投資は、プロジェクトの成功の一端を担う重要なものです。このようなメカニズムは、多数の異なるスタックとの統合を実現し、より広範な導入を可能にしただけでなく、完全に新しいエコシステムの形成も促進しました。たとえば、現在の十分に開発された拡張メカニズムがなければ、Knative プロジェクトと Operator エコシステムが今と同じ形で存在することはなく、ユーザーベースもここまで広がることはなかったでしょう。

Red Hat OpenShift プロダクトマネージャー Rob Szumski (ロブ・シュムスキ)

Kubernetes プロジェクトの来し方を振り返るとき、プロジェクトで行われた主要な変更が印象深く記憶に残っています。1 つ目は、API サーバーとの通信に使用していた etcd 3 を gRPC に切り替えたときです。etcd コミュニティと Kubernetes コミュニティの間で行われたコラボレーションによってスケーラビリティが大幅に改善されたのです。この変更により、1,000 ノードクラスタのスケジューリング時間が劇的に短縮され、以前は失敗していた 5,000 ノードクラスタでのスケーリングテストも実行できるようになりました。基本的には Kubernetes コードベースの外での変化ですが、開発にとって素晴らしい結果でした。

Kubernetes 機能の次の大きな変化は、Kubernetes を「セルフホスト」するというアイデアでした。セルフホストとは、Kubernetes コントロールプレーンと各種コンポーネントを Kubernetes 自体で実行することを意味します。これにより、プラットフォームにそれ自体を管理させることができるようになりました。これは、CoreOS Tectonic でまず開発され、OpenShift にもたらされました。Kubernetes はクラウド全体に広くデプロイされているため、管理のしやすさはきわめて重要です。組織内の数百または数千のクラスタを最新の状態に保つことは、プラットフォーム自体の自動化を通じてのみ可能です。最後の主要な出来事は、CRD 拡張メカニズムに関連してオペレーターの概念が導入されたことです。これにより、Kubernetes 上の分散システムと複雑なステートフル・アプリケーションのワークロードが大幅に増加しました。ハイブリッドクラウドには、Kubernetes を実行できる場所であればどこでもクラウドサービスを実行できるという、クラスタのこの拡張機能が不可欠です。