‫では､ Kubernetesの次はどうなるのでしょうか｡
‫このような疑問は､ この製品が急速に成長し､
‫それを取り巻くエコシステム全体が､ 一人の人間には手に負えないほど大きくなっているのを見て､
‫多くの人が抱いているのではないでしょうか｡
‫未来はどうなる？
‫まあ､ 良いニュースは､ 私がそれを予測しなければならないとしたら､
‫それはつまらなくなり始める必要があるという未来だと思います｡
‫人前で会うと､
‫創業者の多くがこの話をしているのを聞くことができます｡
‫インフラをなるべくつまらなくして､ その上でもっと頼れるものを作るべきだという話になるんですよね｡
‫というのも､
‫これはすべて､ 私たちのアプリを世に送り出すためにあるのですからね｡
‫Kubernetesのポイントは､ Kubernetesそのものではありません｡
‫それは､ やりたいことをより早くできるようにするためです｡
‫Kubernetesの場合､
‫ここ数回のリリースを見ると､ 信頼性､ 安定性､ セキュリティに焦点を当て始めていて､ 基本的にはそこにあるだけで十分なほど安定していますね｡
‫そんなに気にする必要はありません｡
‫そんなに直さなくていいんですよ｡
‫定期的にリリースしているので､ リリーススケジュールや､
‫このビデオの中でリンクしているリリースノートをぜひチェックしてみてください｡
‫今年､ 2019年に起こったことの1つは､ 多くのコアコードに対する大規模なセキュリティ監査で､
‫多くのことが明らかになりました｡
‫実際､ 彼らのブログには､ 何が起こったのかについての詳細な分析が掲載されています｡
‫これほど重要で大きなオープンソースプロジェクトが､
‫第三者によるセキュリティ分析を行っただけでなく､ 潜在的な問題点と結果をすべて明らかにしたことは､
‫本当に素晴らしいと思います｡
‫その結果､ 前倒しですぐに修正できるものから､ 時間をかけて最終的に修正するものまで､
‫多くのPRを行うことになったと思います｡
‫必ずしも脆弱性ベースというわけではなく､ もっとこの辺は改善できるだろうから､
‫時間をかけて変えていこうということです｡
‫もうひとつは､ もっとシンプルなツールだった頃の古いコンセプトが､
‫削除されるにつれて色あせていくことです｡
‫CSIでないストレージプラグインはいずれ撤退すると思うので､
‫ビルトインのものではなく､ CSIに頼らざるを得なくなるのではと思います｡
‫kubectl runのようなコマンドが変更され､ 警告が出なくなるのがわかると思います｡
‫それから､ ここで紹介した他のもの､ 例えばサービスサイドのドライランが安定してきて､
‫その周辺の機能も増えてくるでしょう｡
‫なぜなら､
‫より良い監査や経年変化の把握が強く求められていると思うからです｡
‫やる前に何が変わるのか､
‫やった後に何が変わったのか､ そういう報告指標を｡
‫サードパーティに関しては､ 今後もどんどん広がっていくでしょうし､
‫私たちの誰もが知り得ないことです｡
‫ヘルム 3． 0は完成間近です｡
‫Kubernetesでのデプロイや管理を容易にするサードパーティツールのためのオペレータが増えることは間違いないでしょう｡
‫これは希望的観測ですが､ 今後は宣言型ワークフローが注目されるようになるのではないかと思っています｡
‫というのも､ DevOpsにまつわるこの新しいテーマ､ もっと言えばgit-ops､ これは私のポッドキャストでも話しているのですが､
‫git opsのことなんです｡
‫git-opsワークフローは比較的新しいコンセプトですが､ 私たちオペレーター､
‫つまりKubernetesクラスターを管理している人たちは､
‫本当にオペレーターとして行動しているという考えです｡
‫オペレータは､ ソフトウェアチームがコードや時間の経過によるコードの変更､ リリースを管理しなければならなかったことから､
‫GitHubのようなツールが台頭してきましたが､ 同じツールを使って宣言的にインフラを管理するようになりました｡
‫そんな話を聞いたことがありますね｡
‫Kubernetesの経年変化を見ると､
‫より宣言的なスタイルになりつつあり､
‫その宣言的なワークフローに機能セットとフォーカスが当たっていることが分かると思います｡
‫より良いツールを手に入れ､ 今あるツールも時間をかけてより多くの機能を手に入れたいと考えています｡
‫ここでもう一つ大きいのは､ Windows Serverへの対応です｡
‫2019年はWindows Serverのserver
‫2019への対応を軸に大きな発表がありましたが､
‫それはまだ始まったばかりです｡
‫それは､ KubernetesよりもSwarmの方が技術的に先を行っていることです｡
‫DockerとSwarmはもう何年も前からWindows Serverをサポートしており､
‫時間とともに確実に向上しているところです｡
‫しかし､ Server 2016からそれを始め､ より良いものになるよう推し進めてきました｡
‫一方､ Windows Server 2019のKubernetesは､
‫ちょうど今､ 本当にサポートがあると言っています｡
‫実稼働中のServerの話を聞いていると､ Windows ServerがLinuxと同等になるには､
‫Kubernetesの世界でもっと多くの作業をしなければならないようです｡
‫Windowsの企業がコンテナオーケストレーターを採用するようになると､
‫この部分が大きな焦点になると思います｡
‫ここで最後にいくつか､ Edgeのケースは間違いなく作業することになります｡
‫機械学習のようなもの｡
‫Edgeや小規模インフラといったものは､ Kubernetesの当初は非常に大規模で非常に面倒なものでしたが､
‫それを大幅に引き下げてデプロイしやすくしているので､ すべて集中していくことになるでしょうね｡
‫そのため､ kubeadmのようなHAクラスタをデプロイできるツールが登場しているのでしょう｡
‫セキュリティも万全で､ フォールトトレラントもすぐに使えます｡
‫これらはすべて､
‫今実現しつつあるものなのです｡
‫他の関連プロジェクトを知ることも､ その未来の一部です｡
‫このコースで紹介していないもので､
‫チェックしておいた方がいいものを本当にざっと挙げてみただけなんです｡
‫なぜなら､
‫Kubernetes自体が､ 他のあらゆるものがその上に構築され始めるプラットフォームになっているからです｡
‫実は､
‫このプロジェクトの著者が最初に目指したのは､ まさにこれだったのです｡
‫彼らは､ 生のオープンソースのKubernetesを直接使うことを想定していなかったのです｡
‫これは､ 私たちがワークロードを実行するために､ 他の人たちがその上に抽象的な機能を構築することを意味しています｡
‫だから､ ディストリビューターが出てくるのは､ そのために別のレイヤーを上に構築しているケースが多いのです｡
‫この場合､
‫他のことをするためのインフラがいろいろと出てくるわけです｡
‫まずは､ Knativeです｡
‫これはサーバーリストのあたりで､ 間違いなくCNCFの公式プロジェクトなので､
‫Kubernetesの世界と密接に関係しています｡
‫サーバーリストに興味があるなら､ ぜひともチェックしておきたいプロジェクトのひとつです｡
‫次に､ ランチャーのプロジェクトは､ K3sとK3osの2つです｡
‫K3sは､ Kubernetesの複雑なデプロイと管理を､ 不要なものをすべて取り除いてシンプルにしたチームです｡
‫レガシーコマンドやコードの一部かもしれません｡
‫CSIがあれば不要になったストレージドライバもあるかもしれませんね｡
‫そういうことです｡ 全部引き出して､ 本当に簡単なデータベースを作ってくれるんです｡
‫etcdもすぐに使えません｡
‫よりシンプルなデータベースを使用しています｡
‫元々IoTのようなものには本当に意味があるんです｡
‫しかし現在､ KubernetesをSwarmのようにシンプルにすることを目標としており､
‫これは今年のDockerConでCTO兼共同創設者のDarren
‫Shepherd氏が述べたものです｡
‫なかなか面白い発言でした｡
‫彼は､ Swarmはデプロイメント､ 使いやすさ､ 影響の少なさにおいて非常に優れている､
‫と言っていました｡
‫とても小さなバイナリです｡
‫インフラの面でもオーバーヘッドがほとんどない｡
‫Kubernetesはそれとは全く逆のものです｡
‫その中間を探そうとしているのです｡
‫Kubernetesから必要なものを取り除いて､ ARMやRaspberry
‫Pisなどの小さなシステムにも簡単にデプロイできるようにすることは可能でしょうか｡
‫ということで､ 注目のプロジェクトですね｡
‫K3osは､ K3sを搭載したオペレーティングシステムです｡
‫これは､ 小さな家電でK3sを動かすために設計された､
‫非常に最小限のLinuxのインストールです｡
‫かなり新しいものですが､
‫それにしても面白い企画ですね｡ もう1つの大きな注目分野は､
‫私のポッドキャストで詳しくお話ししますが､
‫サービスメッシュです｡ これはここ数年の新しい概念で､
‫本当に新しい言葉です｡
‫これまで業界ではあまり使われなかった言葉です｡
‫サービスメッシュは､
‫インターネットからの接続だけでなく､ アプリのすべての部分に対して､
‫クラスタ全体にプロキシ層を設けるという考え方です｡
‫セキュリティ､ 監視､ 適切な場所へのルーティングなど､
‫分散アプリケーションのすべての部分のトラフィックを制御するための仲介役となるのです｡
‫マイクロサービスという問題意識から生まれた一連のプロジェクトです｡
‫マイクロサービスの経験者であれば､
‫本当の課題の1つは､ 1つのサーバー上の1つのバイナリで､ トラブルシューティングが比較的簡単だったものが､ 何十ものサーバー上の何十ものコンテナになることです｡
‫これは､ 優れたネットワーク・ツールがない限り､ トラブルシューティングが非常に難しくなります｡
‫サービスメッシュはこの問題に着目し､
‫分散アプリケーションやマイクロサービスの可視性､
‫監視､ トラブルシューティング､
‫セキュリティを向上させるためのレイヤーを構築し､
‫その背後にある標準になろうとしているのです｡