専門家が論ずるKubernetesのトップトレンドと運用上の問題

原文(投稿日：2021/02/26)へのリンク

先日公開されたCloud Native Computing (CNCF)サーベイの見出しには、"運用環境でのコンテナの利用が2016年以降、300パーセント増加した"と述べられています。この急激な拡大によって発生した課題に対して、ユーザ個々のみならず、コミュニティとしても取り組みが行われています。

InfoQは先頃、何人かのKubernetes専門家を招いて、このプラットフォームの中心的なトレンドと、ユーザが直面している最も重要な課題について議論しました。

パネリストは以下の方々です。

• Katie Gamanji — CNCF、エコシステムアドボケート
• Brian Gracely — Red Hat、OpenShift担当プロダクトストラテジディレクタ
• William Jimenez — Rancher/Suse、テクニカルプロダクトマネージャ
• Qi Ke — Microsoft、Azure担当エンジニアリングディレクタ
• Suhail Patel — Monzo Bank、スタッフエンジニア
• Sunil Shah — Airbnb、エンジニアリングマネージャ

InfoQ: Kubernetesとの最初の出会い、その時の感想、それ以降の関わり方について、それぞれ手短に話して頂けますか？

Katie Gamanji: 私がKubernetesの機能を最初に調査したのは、既存のアプリケーション用にもっと優秀なリソース管理と自己修復機能を導入したいと考えていた時でした。当時のKubernetesのインストールは、コアコンポーネント用にsystemdを手作業で設定するなど、"大変な作業"でした。それ以来、複数のインフラストラクチャプロバイダ上にホストされた数十のクラスタを設定や管理やメンテナンスをしたり、さまざまなクラウドネイティブなテクノロジとの統合を行ったりしています。

Brian Gracely: Googleがこの風変わりな名前の新プロジェクトを発表した時、Docker SwarmとMesos/Marathonがすでに存在していました。数か月後にKubeConが発表された(CNCF以前)のですが、正直なところ"コンテナスケジューラだけのイベントが本当に必要なのだろうか？"と思いました。それが事実だと思うようになったのは、ある大手金融サービス会社がv1.0の頃から使用していると聞いてからです。私は2016年から、Red HatのKubernetesプラットフォームであるOpenShiftのリーダを務めていて、プライベートクラウドとパブリッククラウドにわたってKubernetesをデプロイする数千の企業とともに仕事をしています。

William Jimenez: Kubernetesに最初に出会ったのは、ディジタル教育の会社(Chegg)でDevOps近代化プロジェクトのリーダをしていた頃でした。それまでは複雑な依存関係を抱えた世界で、増え続ける重さや脆弱性に悩まされていました。コンテナ化の成果はすぐに現れて、オーケストレーションのためにAWS ECSに多額の投資をしていた時でしたので、Kubernetesが登場した時には、すでに別のものを導入した後でした。移り変わりの激しいビジネスにおいて、コンテナを使用可能にするために必要なセキュリティ、CI/CD、開発者用ツールといった基本は、当時としてはそれだけで非常に大きな課題であったので、Kubernetesが対処しようとする懸念はあまりにも高尚で、手の届かないものであるように思っていました。今から考えれば、私は長い間、Kubernetesに本当の意味で注目してはいなかったのだと思います。Rancher Labsで働くようになって初めて、Googleのエンジニアリングレベルに及ばない企業でもその真の価値が理解できるように、Kubernetesを親しみやすいものにできるのだ、ということが分かりました。

Qi Ke: KubernetesとGKEが発表された頃、私はGoogleで働いていました。初めてGKEに出会ったのは、GKE上で動作するアプリケーションのトレースを評価するためでした。当時はサービスメッシュというものは存在しなかったので、コール間でトレースコンテキストを転送するというのは、アプリケーションコードの修正なしには実現不可能でした。数年後にKubernetes上で毎日作業することになるとは、当時は考えてもいませんでした。

Suhail Patel: MonzoにKubernetesが導入されたのは、バージョン1.0のかなり早い時期です。Brianの言った金融サービス企業というのは、当社のことです！私の最初の出会いは、Monzoに入社して、この素晴らしいオーケストレータがマイクロサービスアーキテクチャに最適であるということを見た時でした。当社ではKubernetesを利用して、銀行業務のあらゆる面を網羅する1,500以上のサービスを運用しています。 

エンドユーザとしての当社は、KubernetesやPrometheus、Envoyなどのプロジェクトの改善とオフィシャルな記事の提供、運用システムへのフィードバックという形で、常にクラウドネイティブコミュニティと共に開発を進めています。

Sunil Shah: 2014年、私がMesosphere (Apache Mesosプロジェクトに合わせたオープンコアのスタートアップ)でエンジニアとして働き始めてから1週間か2週間後のことでした。最初の印象は、不安と期待の入り混じったものでした -- Googleのような業界の大企業が、自分たちのコアプロダクトと競合するものを潤沢な資金で開発して、無償公開すると発表すれば、多少は不安を持つのが当然でしょう！その一方で、Googleがこの分野に進出したというのは、私たちが取り組んでいることへの良い兆候だとも思いました！

それ以降、KubernetesがMesosに対して勝利を収めたことは明らかですし、コミュニティがこれほど急速に成長したというのは驚くべきことです。Yelpでは、新たなワークロードに関して、MesosをKubernetesにリプレースする取り組みが始まっています。今はAirbnbで、当社のほぼすべてのワークロードを運用して世界中のトラフィックを処理する、数十のKubernetesクラスタを管理するチームのサポートをしています。

InfoQ: 開発者やアーキテクトが注目すべきKubernetesのトレンドのトップ3を挙げてください。

Gamanji: 過去数年間、Kubernetesの採用数は成長を続けていて、2020年のCNCFの調査では、その83パーセントが実運用環境で使用されています。スイートのコアが安定したことによって、コミュニティの関心の重点は、開発者エクスペリエンスやワークロードのライトウェイトな実行へと移っています。ですから、今後も追及が続くテクノロジは、GitOps、クラウドネイティブポータル、IDE、そしてKubernetesアズ・ア・エッジプラットフォームといったものになります。

GitOpsパターンは当分、その兆しを見せるに留まっているでしょう。クラウドネイティブなエコシステムにおいては、ArgoCDやFluxといったツールによって、gitリポジトリを使用したアプリケーション状態の宣言的表現が可能になるでしょう。これらのツールは、CI/CDパイプラインの自動化レベルを再定義することになります。

コード開発やデプロイメント、可観測性、トラブルシューティングステージといった開発者エクスペリエンスは、あらゆるアプリケーションリリースプロセスにおいて、常に最前線に置かれるべきものです。クラウドネイティブの分野では、GitPod(開発)、Octant(可観測化とトラブルシューティング)、operator boilerplates(リリース)など数多くのツールが、DXの改善に目標を合わせています。

多くの組織にとって、顧客近接性(customer proximity)とレイテンシ低減は、アプリケーションの成功を図る上で重要なメトリクスですから、サービス品質やサービスのエクスペリエンス改善のために、クラスタの運用を物理的な距離によって選択するようになるかも知れません。これらの機能は、k3s、KubeEdge、OpenYurtなど、エッジ指向の数多くのプロジェクトがカバーすることになるでしょう。

Gracely: 最初に挙げたいのは、開発者がコンテナやKubernetesを意識せずに、コードを書くことだけに集中できるようなツール(Buildpacks、s2iなど)です。その次には、導入を簡単にしてくれる一連のツール(VSCodeプラグイン、Red Hat Code-Ready Containers、minikube、Katacoda)があります。そしてKnative。これは開発者がOpsについて心配する必要をなくしてくれます。

Kubernetsがそのライフサイクルに入って5年以上経ちますが、ほとんどの開発者がPodやCRDについて意識していないことを忘れてはなりません。そのためツールは、学習曲線やビジネス目標における彼らの現在の立ち位置に合ったものでなければなりません。

buildpacksやs2iといったツールでは、開発者はただコードを書くだけです。あとはツールが、コードと依存関係を自動的にコンテナに変換してくれます。

IDEプラグインとWebベースのIDE(VSCode、Code-Ready Containersなど)は、単に導入期間を短縮するだけでなく、Kubernetesがデプロイをいかに拡張するのか、というコンテキストを与えてくれます。

そして、Knativeのような新機能を使うことで、このようなコンテナを新たなイベント駆動型アプリケーションに適用できるようになります。

Jumenez: まずは開発者支援です。エンジニアリングの世界の主役は、間違いなく開発者なのです。Kubernetesの導入はITの最新化という方向から語られることが多いのですが、それは氷山の一角にすぎません。導入が本当に始まるのは、開発者がその価値に気付き始めた時なのです。開発者をストーリに引き込むには、ツールや言語がもっと必要です。

次はクラウドネイティブなストレージ。Kubernetesはステートレスなアプリケーション用のソリューションとしてスタートしました。分散システムでは状態の維持は困難だからです。Kubernetesの使用方法が確立すれば、ユーザはこの新たな課題を以前にも増して求めるようになるでしょうし、そのROIは看過できないものになるはずです。

そして最後は、Kubernetesがどこでも使えるようになることです。Kubernetesがコモディティ化して、データセンタやエッジ、組み込み、IoTなどのコンピューティング環境において、ごく普通に期待できるものになるでしょう。テクノロジコミュニティとしては、それぞれの環境にソフトウェアを適応させるためにこれまで費やされてきた大量のリソースを、これによってその作業から解放することができれば、と期待しています。これほどの規模とスコープを持ったクラスタと連携して、すべてのKubernetes環境を等しく扱えるようなツールも必要でしょう。

Ke:

• 1. マルチクラスタ管理、クラスタ間ネットワーキング、ストレージ
  Kubernetesのユーザは一般的に、運用システムとして複数のクラスタをクラウド内で管理しています。障害時の影響範囲を小さくするため、地域性や局所性のため、セキュリティ領域のため、規模の制限を回避するためなど、理由はさまざまです。そして、クラスタの数が増えれば、クラスタのライフサイクル管理、構成管理、アプリケーションの管理、すべてのクラスタに対するポリシ施行などの作業に要する労力は増大し、エラーも起こりやすくなるのです。
• 2. 悪意のある(あるいは意図しない)アプリケーションからの自己防衛と自己修復
  すべてのアプリケーションが、Kubernetesフレンドリな方法で記述されているとは限りません。Kuberenetsのマネージドサービスを提供している当社は、アプリケーションの意図しない動作によってクラスタの安定運用が脅かされるケースを数多く経験しています。大規模クラスタ上のDaemonSetによる、APIサーバ上のクエリやウォッチが原因である場合もありますし、大量のログ取得がOSディスクに関わるIOのスロットリングを発生させ、dockerがフリーズするような場合もあります。クラスタ上で動作するアプリケーションからの意図的な、あるいは意図しない攻撃から防御するために、Kubernetesクラスタの設定やインフラストラクチャのレイアウト、監視のセットアップをどのようにすればよいのか。そして、どのようにして迅速に回復すればよいのか。
• 3. DevOpsツール
  言うまでもなく、Kubernetesの開発者エクスペリエンスはもっと愛されるべきです。マニフェストファイルは柔軟性がある半面、複雑であって、メンテナンスが大変です。VSCodeプラグインがあれば、開発者がすぐに作業できるだけでなく、誤ったインデントや入力ミスを検出することで生産性も向上します。これにサーバ側のドライランとkubectl diffを加えれば、さらに充実した機能になります。

Patel: Kubernetesを安定して運用するためには、多くの時間的投資が必要です。さまざまなプロバイダから多くの価格帯で提供されるマネージドサービスの遍在性は、Kubernetesを世界中のエンジニアがアクセス可能なものにしました。大手クラウドプロバイダや、大人数のプラットフォームチームを所有する企業だけのものではありません。自身でホストしたいのであれば、長年の経験に基づいて構成され、パッケージされたディストリビューションがたくさんあって、数個のコマンドを入力するだけで使用することができます。

特にコントローラとオペレータには素晴らしいものがあります。コントローラは独自のコントロールループのKubernetesへの導入を可能にしてくれますし、オペレータは他システムをKubernetesに導入して、そのライフサイクルに組み込めるようにしてくれます。Kubernetesは、運用中のすべての他システムのSREになることができます。

Kubernetesはベースプラットフォームとして普及しており、高い完成度を持っています。組織全体におけるデプロイメント、ツーリング、監視、可観測性、さらにそれ以上の分野にわたって、統一的なプラクティスの導入を実現します。これによって、より多くの企業や技術者がCNCFのエコシステムと直接関わりを持って、自らの経験をフィードバックしてくれるようになれば、さらに素晴らしいと思っています。

Shah: 個人的に期待している分野が3つあります — Podリソースの最適化、ステートフルサービスのオーケストレーション、運用の自動化です。

まず最初に、リソース要件(CPU、メモリなど)は、ほとんどのユーザが通常は考えない部分です。Kubernetesをマルチテナント環境で適切に運用するには、競合下で動作するサービスを保護するために、合理的なリソース要求を設定することが必須といっても過言ではありません。ユーザがリソースを管理し考慮する方法を改善するためのツーリングは、私たちが大きな期待を寄せている部分です。リソースについて何も考える必要なく、システムが処理してくれるようになれば、それが理想的です！この方向に進もうとしているスタートアップもありますが、単にユーザがリソース消費を監視する以上の部分でも、まだ改善の余地は残っています。

2番目はステートフルサービス(Spark、Flinkを考えてください)の統合です。数年前に比べれば非常によくなっているのですが、システムをオーケストレーションするファーストクラスの方法として、オペレータなどKubernetesのプリミティブを使用している分散システムの開発者を今でも目にします。Sparkには現在、完成度の高い「Kubernetesのスケジューラがあるので、インフラストラクチャに対する運用上の効率性をもたらしてくれることを期待して、ぜひ使用してみたいと思っています。

3番目は、Stackpulseなどを用いたrunbook(あるいはplaybook)の自動化です。まだ始まったばかりですが、大きな可能性を秘めています。大規模な組織は例外なく運用プロトコルの定期的な検証に苦労しています。それをコード化できれば、API変更毎のテストを自動化することが可能になるのです。

InfoQ: Kuberenetsを運用環境にデプロイする上で、最も大きな課題は何でしょうか？

Gamanji: クラウドプラットフォーム/インフラストラクチャチームにとっての最大の課題は、Kubernetesを常に最新リリースに更新しておくことです。多くの組織では、EKSやGKE、AKSといったマネージドサービスを使用して、クラスタのメンテナンスをクラウドプロバイダに委譲する方法を選択しています。しかし、このソリューションが適切でない場合には、クラスタのアップグレードにチームの多くのリソースを割り当てる必要があります。その対応としてKubernetesコミュニティでは、リリースの回数を年4回から3回に削減することで、エンドユーザ組織が最新機能を習得し統合するための十分な時間を確保できるようにしています。

Gracely: 多くの企業はKubernetesを、自社の既存プロセスの新バージョンとして扱っています。それらのプロセスのほとんどは、ソフトウェアの頻繁な変更を前提とはしていません。セキュリティを"左シフト(shift left)"してソフトウェアサプライチェーンの一部とするだけでなく、Kubernetesプラットフォームに統合する必要もあります。

Jimenez: 運用への投入は、数年前に比べればはるかに楽になっています。kubespray、kubeadm、RKEといった自動化テクノロジが、Kubernetes管理というエラーの多く複雑なテリトリへと、勇気を持って進出した結果です。しかしながら、これらは"簡単な"問題であって、私たちはそれらによい対処をした、と言って過言ではないでしょう。本当の課題だと私が思うのは、Kubernetesが単に機能するというだけではなく、その約束しているものを提供するにはどうすればよいのか、という点です。

Google内にあった頃のような変革力を持つためには、組織における採用を大幅に拡大する必要があります。そうでなければ、すでに数多く存在する"プラットフォーム"の新たな一員として、その背後にただ置かれるだけの存在になるリスクがあります。Kubernetesの強みは、ソフトウェアを開発して多くのユーザ用にスケールアップするまでの早さです。このビジョンを実現させるためには、開発者、セキュリティ研究者、SREがKubernetesのツーリングや機能のすべてを受け入れ、利用できるようにすることが必要です。実装に多くの時間とエネルギを費やしたにも関わらず、Kubernetesがサイロ化していたり、限られた場所で限られた価値を提供するにとどまっていることが非常に多いのです。

Ke: 可視性、これに尽きます。マネージドKubernetesのプロバイダという立場から、私たちには、顧客のエスカレーションの大部分の原因が、クラスタで起きていることに対する可視性の欠如によるものであることが分かっています。コネクションがリセットされたのはSLBのためか？ディスクアクセスは制限されているか？スケールアップ障害はクオータの不足によるものか？kubeletがハングしたのはメモリが原因か、CPUの利用過多によるものか？クラウドインフラストラクチャとKubernetesクラスタ上のパフォーマンス、QoS、ログに対する可視性は、障害の根本原因への鍵となります。私たちはその後、これらのメトリクスやログから得たシグナルをまとめてプロブレムディレクタ(problem director)たちに渡しました。その結果として、一般的な問題に対する自己修復機能が開発され、自己回復(self-healing)が実現したのです。当社はこのような方法で、大規模クラスタを管理しています。

Patel: Kubernetesは、インフラストラクチャに関する問題を取り除くためのコンポーネント開発から、あなたを開放してくれるものではありません。多くのアプリケーションエンジニアは、Kubernetesの動作原理を知らない/知りたくないのですから、すべてのメリットを活用するために、企業内で統合するための作業を行うことが重要です。Kubernetesによってインフラストラクチャチームの扱うインフラストラクチャの抽象度がレベルアップすると同時に、豊富なオーケストレーション機能のセットが、自ら構築しなくても手に入るようになります。

自分でクラスタを運用するのには時間とエネルギが必要です。共通的に難しい部分のひとつだと私が思うのは、たったひとつやふたつのクラスタ(開発クラスタやプロダクションクラスタ)をサポートするために、サポートやツールを構築しなければならないことです。そうではなく、クラスタを畜牛のように扱い、新たなクラスタをシームレスに立ち上げることを可能にできれば、新しい機能やプロセスのテストを容易にするための有意義な時間投資になります。

Shah: 私の考える最大の課題は、Kubernetesの普及と関係しています。最初は、Kubernetesの変化が速過ぎること！Kubernetesのアップグレードに走って追いついているように感じることがよくあります。Airbnbのような規模の組織は、パッチや独自のインテグレーションをたくさん抱えているので、新しいバージョンが出るたびに詳細なテストが必要になります。オートメーションが助けにはなりますが、それでも、それ自体がフルタイムの仕事です。

第2に、エンジニアリングコミュニティにおいて、Kubernetesが、クラウドリソースの管理方法のデファクトとして評価されていることが、結果として、実用レベルのクラスタの運用には労力が必要だ、という理解に転じていることです。これが逆効果となって、自動化や、あるいは原価配分や可観測性など、大規模な企業において必要な他のインフラストラクチャシステムとのインテグレーション構築に対する時間投資を見合わせる結果になる場合があるのです。ベンダの管理するソリューションであっても、複雑に分類されているような場合であれば、この問題と無縁ではありません。

そして最後に、大規模なエンジニアリング組織内でKubernetesを実運用する場合、チームは"Kubernetesのエキスパート"として、高度なサポート責務を負うことになります。従来のLinux環境であれば大部分のエンジニアが知っていても、Kubernetesに関しては自信がない、あるいは慣れていない、基本的な操作(サービスの状態変更など)のために、私たちが呼び出させることが少なくありません。開発者ツールが充実すれば状況は改善されると思いますが、危険性のあるコマンドのリスクとのバランスが必要でしょう！

まとめ

パネリストたちがKubernetesとの最初の出会いを語り、トップトレンドや、特に運用環境において直面する課題について議論しています。デプロイメントを最新に保つことから、エンドツーエンドの可視性の必要まで、特にマネージドサービスにおいては、さまざまな運用上の課題があります。プラットフォーム上のSDLC(Software Development LifeCycle)にも改善の余地がありますし、クラウドネイティブな世界でセキュリティに対応するための"左シフト"も必要です。パネリストたちは、これらギャップの橋渡しをするために実行中の活動について語ってくれています。

パネリストについて

Katie Gamanji — 現在CNCFのエコシステムアドボケートであるKatie Gamanji氏は、エンドユーザコミュニティに近い位置にいます。氏の大きな目標は、エンドユーザコミュニティの可視性と成長を拡張するためのプログラムを開発し、実践することによって、TOCやSIGといった他のエコシステムユニットとの橋渡しをすることです。過去の役割において、氏は、Kubernetesを中心として、クラウドネイティブの原則やオープンソースのツーリングに誘うようなプラットフォームの構築に貢献してきました。これらのプロジェクトは、OpenStackベースのインフラストラクチャにおけるメンテナンスとアプリケーションデリバリの自動化から始まったものですが、その後Condé Nastにおいて、世界規模で分散された集中型プラットフォームの構築へと移行しています。Gamanji氏の近況はTwitter、LinkedIn、Mediumなどで知ることができます。

Brian Gracely — Red HatのプロダクトストラテジディレクタとしてOpenShiftを担当するGracely氏は、世界中の巨大企業を対象として、既存および新規開発されるアプリケーションのKubernetes上での運用を支援しています。氏はストラテジ、プロダクト管理、システムエンジニアリング、マーケティング、M&Aに20年以上のキャリアを持っています。Cloudcast(クラウドコンピューティング)とPodCTL(Kubernetes)両ポッドキャストのホストのひとりでもあります。Gracely氏の発言はTwitter、LinkedIn、YouTubeなどで見ることができます。

William Jimenez氏は、SUSEのテクニカルプロダクトマネージャです。コンピュータやソフトウェア、そして何よりも自身が手がけた複雑なシステムによる問題解決を楽しんでいます。自由時間はアマチュアラジオをいじったり、オープンロードをサイクリングしたり、家族と一緒の時間を楽しんだり(ですから氏の家族は、氏が自分たちのことを忘れているとは思っていません)しています。Jimenez氏はLinkedInで見つけられます。

Qi Ke氏は、Azureのエンジニアリングディレクションで、Maneged Kubernetes Serviceのリーダを務めています。以前はGoogleのクラウド、APM、開発ツール、エンタープライズ、ソーシャルと検索、高性能分散システム、エンジニアリングシステムなど、さまざまな分野で働いていました。その前にはBingで、Q Buildシステム(別名CloudBuild)開発で設計、アーキテクト、業務管理などの仕事をしていました。Ke氏については、LinkedInで確認することができます。

Suhail Patel氏は、Monzoのスタッフエンジニアとして、コアプラットフォームを中心に働いています。氏の役割はMonzoのインフラストラクチャの構築とメンテナンスに関わるもので、そこでは1,500を越えるサービスが、KubernetesやCassandra、Etcd、Envoy Proxyなどの重要なインフラストラクチャコンポーネントを活用しています。Patel氏に関しては、TwitterやLinkedInで知ることができます。

Sunil Shah氏は、Airbnbのエンジニアリングマネージャです。氏のチームは、Airbnb.comを支えるKubernetesベースのプラットフォームの構築とメンテナンスを行っています。Airbnb以前のSunil氏はYelpでコンピュータを管理し、MesophereでApache Mesos商業化を支援し、UC Berkeleyでロボティクスを学び、音楽レコメンデーションサービスのLast.fmで統合パイプラインの構築をしていました。Eメールを書いていない時のSunil氏は、泳いだり、自転車に乗ったり、(ゆっくり)走ったり、妻とOvercooked 2をプレーしたりしています。Shah氏の近況はLinkedInで見ることができます。