なぜますます多くの企業が Kubernetes をホストしているのでしょうか?

Kubernetes クラスターをマネージド サービス プロバイダーに引き渡すのは、子供を大学に送るようなものです。最初は心配しますが、結局自分でやるべきことは少なくなります。

過去数年間で、3 大パブリック クラウド プロバイダーである Amazon Web Services (AWS)、Google Cloud、Microsoft Azure は、マネージド Kubernetes ソリューション (Kubernetes as a Service、KaaS とも呼ばれる) で大きな進歩を遂げ、顧客が YAML 構成ファイルの基礎となる詳細を理解したり、自動スケーリング、更新、クラスター管理について心配したりすることなく、コンテナー化されたワークロードを実行およびオーケストレーションできるように支援してきました。

[[415034]]

開発者向け調査会社 RedMonk の共同設立者、スティーブン・オグレイディ氏は次のように述べている。「企業がシステムを戦略的とみなす場合、そのシステムを自社で運用することが目的です。しかし、慣れてくると、自社で運用しても競争上の優位性は生まれず、ベンダーの方がおそらく自社よりもうまく運用できるということに気付くのです。」同氏はさらに、「すべての企業がこの道を進んでいるだろうか。今のところはそうではないが、この道を進む意欲と方向性は明らかだ」と付け加えた。

マネージド Kubernetes サービスを検討すべき 6 つの理由は次のとおりです。

管理コストを削減

明白な理由から始めましょう。 「はっきり言って、やるべき仕事は減っている」と旅行技術会社アマデウスの技術プラットフォームおよびエンジニアリング担当上級副社長、シルヴァン・ロイ氏は語った。 「Kubernetes を運用する上で必要な人材を全員雇用するのは難しいため、Kubernetes を運用してくれる人材がいます。これは重要なことです。」

同様に、建設会社 Strabag のエンジニアの小グループは 2006 年から独自のコンテナを運用しており、過去 4 年間で自己管理型のオープンソース Docker および Kubernetes 環境に切り替えました。現在、同グループはクラスタ管理を可能な限り自動化することを検討しており、既存のアプリケーションを最新化して基盤となる Kubernetes クラスタの管理を Google Cloud にオフロードするか、特にローカル データ転送が必要な場合に開発者が Anthos サービスを使用してクラウドまたはハイブリッド環境で新しいアプリケーションを実行できるようにするかを決定しています。

「引き継ぎに適したタスクは、まず引き継がれなければならない」と、ストラバグのクラウドサービスチームの責任者、マリオ・クライナッサー氏は語った。

金融データ大手ブルームバーグのコンピューティング インフラストラクチャ責任者、アンドレイ リブカ氏も、「SRE (ソフトウェア信頼性エンジニアリング) チームや Kubernetes のリリース サイクルを管理するチームがない場合、アプリケーションの実行に重点を置き、Kubernetes の管理を望まない企業にとって、マネージド プロバイダーを最大限に活用するのは合理的な動きです」と述べています。

現在、ブルームバーグは Kubernetes ワークロードのほとんどをオンプレミスで実行していますが、適切な場合にはホスト型ワークロードに 3 大クラウド プロバイダーすべてを使い始めています。

必要なのは少数の専門家だけ

Kubernetes 管理スキルは、特に独自の YAML 構成ファイルを作成する場合には、入手が難しく、習得に費用がかかります。 Kubernetes クラスターを手動で調整できる人材がいる場合でも、より日常的なワークロード クラスター管理タスクをベンダーにオフロードして、社内の人材を解放し、社内プラットフォームや特に重要なワークロードや困難なワークロードを管理できるようにしたい場合があります。

「こうした技術に必要な人材を獲得し、維持するのは容易なことではない。これは明らかに課題だ」とアマデウスのロイ氏は語った。

信頼性の向上

つまり、大規模なクラウド プロバイダーは、エンジニアリング チームの規模、顧客展開の多様性、それらの展開の基盤となるテレメトリへのアクセスに基づいて、Kubernetes クラスターを独自に管理するよりも適切に対応できることが多いのです。

「このベンダーはKubernetesクラスタの実行に優れている可能性が高い」とRedMonkのO'Grady氏は述べた。 「ベンダーはテレメトリデータを持っており、個々の企業が独自のデータモデルのみを扱うのとは対照的に、すべての顧客がどのようにクラスターを実行しているかを確認できるという利点があります。」

たとえば、Bloomberg は Kubernetes がまだアルファ版だった 2015 年の全盛期に Kubernetes に切り替えました。必要な継続的インテグレーション、監視、テストが期待どおりであることが証明されると、Kubernetes は 2017 年に本番環境に導入されました。ブルームバーグのエンジニアは、オンプレミス アプリケーション用に独自の Kubernetes クラスターを依然として大部分管理していますが、ワークロードがパブリック クラウドで実行される場合、特に「信頼性の観点から」、マネージド ソリューションを使用する方がますます理にかなっていると Rybka 氏は述べています。

アップグレードやパッチの心配は不要

アップグレードとパッチ適用は、Kubernetes を独自に管理している企業にとって最も面倒な 2 つのタスクです。そのため、マネージド ホスティング プロバイダーは、これらのタスクをお客様に代わって処理することを優先しています。

「Kubernetes のパッチ適用、更新、管理を自分で行うのは非常に複雑で、まったく楽しくない作業です」と、AWS のコンピューティング サービス担当副社長 Deepak Singh 氏は述べています。

クラウドの勢いを維持する

パブリック クラウド ファースト戦略を追求している組織の場合、マネージド サービスをさらに導入することで勢いをつけることができます。

Amadeus は最近、まさにそれを実現するために Microsoft と契約を結びました。 「パブリッククラウドは急速に成長しており、我々はその恩恵を受けたいと考えている。そのため、マネージドサービスの利用を検討するたびに、これがその勢いから恩恵を受ける方法だと考えている」とロイ氏は語った。

現在、ベンダーは Kubernetes のベスト プラクティスに関する知識と経験を、GKE Autopilot などの簡素化された導入パスを備えた、より自己完結型の Kubernetes サービス バージョンに変換しています。

「オートパイロットをバックアップと考える人もいるが、私はシートベルトだと考えている」とグーグルの主任エンジニア、ケルシー・ハイタワー氏は語った。 「車のスピードは同じですが、デフォルトでより安全です。これはフェイルセーフ構成です。ベストプラクティスとは何なのか、どのような決定を下すべきなのか、と常に尋ねられますが、オートパイロットは答えを提供します。」

同様に、AWS のシン氏は、同社は Kubernetes を大規模に実行することで学んだことを応用する能力が向上しており、「その運用経験を EKS に組み込むことで、当社のサービス プロバイダーが EKS をマネージド サービスに直接統合できるようになります。これが、このトレンドが加速するもう 1 つの理由です」と述べています。

しかし、このようなサービスではベンダーロックインに関する懸念が生じることがよくあります。 「Autopilot の選択を難しくしているのは、次のような疑問です。ベンダーを切り替えようとする人がいないのに、なぜミドルウェア レイヤーとして Kubernetes を気にする必要があるのか​​。その答えは、ただやめることができるということです」と RedMonk の O'Grady 氏は語ります。 「ベンダー固有のオプションに頼れば頼るほど、選択肢が狭まるため、企業にとっては難しい選択となります。」

オープンソースでポータブル

ホスティング プロバイダーは、移植性を向上させ、ロックインを回避するために、使用する Kubernetes ディストリビューションが一般的なオープン ソース バージョンに可能な限り近いことを保証したいと考えているオープン ソース コミュニティと顧客の信頼を獲得する必要があります。

「Kubernetesが登場したとき、それは詐欺であり、ベンダー対オープンコミュニティの縄張り争いであり、オープンコアに変貌してしまうのではないかという懸念があった」とGoogleのハイタワー氏は語った。 「そうではないことが証明されるまでに、5、6年かかりました。」

同様に、AWS のシン氏は、EKS が「違いを生むような奇妙な魔法なしで」Kubernetes のオープンソースディストリビューションに近い状態を維持することが一部の顧客にとって重要だと述べた。 AWS は最近、GitHub で EKS ディストリビューションをオープンソース化することでこれを実証しました。

「ロックインについて言及せずにこの話題を語るのは難しい」とKubernetesの共同創設者でVMware Tanzuの主任エンジニアであるジョー・ベダ氏は認めた。彼は、そのような購入決定をする人は誰でもリスクを適切に評価するよう促した。

「離脱する可能性はどのくらいですか？離脱する場合、移行にはどのくらいの費用がかかりますか？どのくらいのコードを書き直す必要がありますか？どのくらいの再トレーニングが必要ですか？これに投資する人は誰でも、要件、リスク、トレードオフを理解する必要があります」とベダ氏は語った。

Cloud Native Computing Foundation (CNCF) は、認定ベンダーに関係なく、1 つのインストールが次のインストールと相互運用可能であることを保証する Kubernetes 認定プログラムを運営しています。

では、なぜ一部の企業はそれを選択しないのでしょうか?

Amadeus や Bloomberg のような大規模で複雑な組織では、機密データのセキュリティに関する懸念、扱いにくいローカル依存関係、独自のクラスターを手動で調整したい過保護なプラットフォーム チームなど、マネージド サービス プロバイダーに任せられないワークロードが存在する可能性があります。

Google の Hightower 氏は、「部品やコンポーネントを自分で管理したい人は、データ プレーンについて心配しています。カスタマイズや特定の領域での専門化が必要なのです。管理されたコントロール プレーンは気にしません」と述べています。

しかし、実際には、Kubernetes を自分で実行する理由はますます説得力のないものになってきています。

「既存の投資であり、誰も埋没費用として帳消しにしたくないと考えているのかもしれないし、保守的な組織が一連の作業負荷やビジネスを外部に委ねることに懸念を抱いているのかもしれない」とレッドモンクのオグレイディ氏は語った。 「あるいは、戦略的なインフラの一部を管理できないことを懸念する人もいるかもしれません。しかし、同業者がマネージド ソリューションを採用しているのを見ると、その懸念は消え、より多くの人がその恩恵を受けることになります。」