Kubernetesは2014年のオープンソースリリース以来、クラウドネイティブ分野における地位を着実に確立してきました。マクロ的な視点から見ると、Kubernetesソリューションの導入経路は非常に明確であり、多くの企業における導入実績が実証されています。現在、エンタープライズグレードのKubernetesソリューションは主流になりつつありますが、多くの企業は依然として導入に躊躇しています。では、2023年のKubernetes管理はどうなるのでしょうか？

最近、 Rancher Greater ChinaのR＆DディレクターであるZhang Zhibo氏がライブ放送のゲストとして登場し、同社で実施された実践的な経験を共有し、現在の開発と将来の動向について議論しました。

Q: 企業に Kubernetes が必要なのはなぜだと思いますか?

張志博：企業はIT変革技術を絶えず導入しており、Kubernetesに完全に依存するのではなく、生産性を向上させるためにコンテナ技術を必要としています。実際、コンテナ技術はエンタープライズアプリケーションの配布、パッケージ化、そして全体的な本番環境の反復作業の効率を飛躍的に向上させています。

業界の現状を踏まえると、包括的なコンテナ管理にはKubernetes（K8s）が依然として最良の選択肢です。以前は類似のソフトウェアが存在しましたが、近年徐々に姿を消しています。他にもニッチな選択肢は存在しますが、エコシステムの維持管理や大手クラウドベンダーによるサポートが不足しています。仮に導入できたとしても、すぐに利用可能で比較的安定した技術ツールやスタックは限られています。そのため、K8sは現時点で唯一実行可能な選択肢であると考えられます。

Q: 企業がKubernetesを利用する場合、オープンソースの自社開発ルートを選ぶべきでしょうか、それとも商用サービスルートを選ぶべきでしょうか？Kubernetesのオープンソース版と商用版の違いは何でしょうか？なぜKubernetesの商用化が今や避けられないトレンドとなっているのでしょうか？

張志博：企業にとって、新しい技術の導入には、どのような選択をしても必ずコストがかかります。企業が人件費を優先するか、ITコストを優先するかは、それぞれの状況によって異なります。ITコストを重視する企業は、新しいソフトウェアの購入費用がIT費用に含まれると考え、オープンソースの自社開発を選択するかもしれません。つまり、オープンソースの自社開発は、オープンソースライセンスさえ取得すれば無料で利用できます。しかし、人件費を重視し、コアビジネスに集中したい企業は、商用サービスを利用する方が有利です。

独自のオープンソース・プロジェクトを構築するということは、生産性向上を推進する新しいテクノロジーに依存する主要戦略を特定の個人に委ねることになるので、企業にとって一定のリスクを伴います。オープンソース・ソフトウェアは完璧ではなく、永続的に維持することは困難であり、継続的なメンテナンスが必要です。オープンソース・プロジェクトに深く関与しなければ、独自のプロジェクトを構築することは長期的な技術的リスクを伴います。こうした状況において、ビジネスリーダーは、自社が独自のプロジェクトを構築するための技術的能力を本当に備えているかどうかを徹底的に評価する必要があります。多くのオープンソース・ソフトウェア・プログラムは、確かにそのままでも優れた機能を備えていますが、だからといってそれに伴う技術コストが伴わないわけではありません。

商用サービスはオープンソースの自社開発ソリューションとは異なり、生産性向上を推進するための重要な戦略を外部のサードパーティ企業に委ねることになります。このプロセスにおいて、サプライヤーの製品やイテレーションの方向性の変更、企業の期待に応えられないこと、あるいは利用期間中の価格設定の固定化などは、IT変革に影響を及ぼす可能性があります。企業が単一の商用企業の独自技術に縛られるリスクは甚大です。

私の職務経験に基づき、SUSEのような企業の将来については依然として非常に楽観的です。ITにおける主流の選択肢は、ユーザーがオープンソース製品の商用サービスを選択し、オープンソース製品のサブスクリプションを購入することです。これにより、ベンダーロックインの問題を効果的に緩和できます。多くの企業がオープンソースソフトウェアの商用サポートを提供しています。たとえ、ある企業で問題が発生したり、その製品がニーズを満たせなかったりしたとしても、オープンソースの技術や製品のみに依存しているため、ベンダーを簡単に切り替えることができます。

企業が将来的にサプライヤーや商用サービス企業に縛られたくない、あるいは自社技術を構築できる能力を持ち事業が好調な場合でも、過去に再利用したオープンソース製品の技術基盤を活用し、商用サービスそのものを放棄することも可能だ。つまり、これは本質的にはリスクヘッジの一種と言える。したがって、真のトレンドはオープンソース製品の商用化にあると私は考えている。

オープンソース版と商用版の主な違いは、ユーザーとしての支払い意思の有無にあります。オープンソース製品にはライセンスがあり、商用利用や二次配布が認められているものもあります。支払いによるセキュリティ確保を期待し、喜んで支払いを申し出るユーザーもいます。しかし、オープンソースなので支払いは不要だと考えるユーザーもいます。もちろん、製品の機能にも違いがあります。一般的に、商用版はより安定した製品バージョンとサービスを提供しており、本番環境でのスムーズな運用を保証します。内部機能の違いについては、ベンダーによって説明が異なります。つまり、オープンソース版と商用版の主な違いは支払い意思の有無であり、二次的な違いは強化された機能にあります。

3つ目の質問についてですが、オープンソース製品の商用サービスは必然的な流れだと個人的に考えています。Kubernetes（K8s）の商用化は避けられないという考えについては、私の第一印象は間違っていると思います。K8s自体は成功したオープンソースソフトウェアであり、その採用は必然的に増加していくでしょう。採用が進むにつれて、一定数の商用顧客が自然に出現するでしょう。商用顧客の増加と有料市場の拡大は、全体的な環境を改善するでしょう。しかし、真のトレンドは、より多くのユーザーがオープンソースソフトウェアの商用サービスにお金を払うようになることです。

ユーザーからの質問：エンタープライズレベルのオープンソースソフトウェアは企業運営において重要な役割を果たしていますが、セキュリティに関する懸念があります。企業ユーザーにとって、これらの懸念にはどのように対処すればよいでしょうか？

張志博：ますます多くの企業がオープンソースソフトウェアを採用しており、多くのパブリッククラウドサービスもオープンソースソフトウェア上に構築されています。これは世界のIT業界における大きなトレンドです。

まず、オープンソースソフトウェアのコードは公開されており、利便性をもたらしますが、同時に潜在的なリスクも抱えています。すべてのコードが公開されているため、ハッカーなどの悪意のある人物もコードを読み取ることができ、脆弱性を迅速に発見して悪用し、ITシステムに侵入する可能性があります。そのため、優れたオープンソースソフトウェアは定期的にセキュリティ情報を公開し、セキュリティ担当者によって継続的に更新され、ユーザーに脆弱性を修正するためのアップデートを促すようにしています。これはガバナンスの問題を伴います。オープンソースソフトウェアの特定のバージョンに固執し、更新を行わない場合、必然的にセキュリティリスクが生じます。

2つ目のリスクはコンプライアンスです。オープンソースソフトウェアには独自のライセンスがあり、業界全体がこれらのライセンスをますます複雑化させ、連鎖的な問題を引き起こし、二次的な商用配布を禁止していることは周知の事実です。仮に商用配布が行われるとしても、収益分配を伴う可能性があります。したがって、オープンソースソフトウェアを利用したい企業は、自社と業界がオープンソースソフトウェアの使用を許可されていることを確認する必要があります。そうでなければ、コンプライアンスリスクが発生します。

第三に、オープンソースソフトウェアのサプライチェーンにおけるセキュリティの問題があります。製品を購入する際に成分表を確認するのと同じように、ソフトウェアにも同様のことが当てはまります。ソフトウェア部品表（BOM）を作成し、ユーザーがソフトウェアが使用しているコンポーネントを確認できるようにすることがますます重要になっています。しかし、すべてのオープンソースソフトウェアがこのリストを提供しているわけではないため、導入を検討している企業は慎重に検討する必要があります。企業内での長期的な運用を確保するには、いくつかのパラメータを変更したり、新機能を追加したりするだけでは不十分で、セキュリティリスクを考慮する必要があります。

最後に、この問題の解決方法についてですが、いわゆる「銀の弾丸」は存在せず、決まった解決策も存在しないというのが私の見解です。オープンソースソフトウェアを導入した上で、継続的なガバナンスの仕組みを構築する必要があります。

Q: 過去1年間、企業は人件費と運用コストの最適化に注力し、コスト削減と効率性の向上に注力してきました。この包括的な目標を踏まえ、Kubernetesは企業のコスト削減と効率性の向上にどのように貢献するのでしょうか？「Kubernetesの商用化」とエンタープライズグレードのKubernetes管理ソフトウェアは、企業のコスト削減と効率性の向上に実際にどの程度貢献できるのでしょうか？

張志博氏：コスト削減と効率向上は、今年まさに広く議論されているテーマです。まず、ソフトウェアによるコスト削減と効率向上の実現は非常に複雑であることを理解することが重要です。本質的に、コンテナ技術こそが真の効率向上と全体的な反復コストの削減を実現します。コンテナ技術は生産性を向上させ、効率もそれに従います。したがって、コスト削減と効率向上のメリットは、コンテナ化を完了した後に初めて実感できます。コスト削減と効率向上を実現するには、Kubernetesインスタンスをいくつか作成し、そこにいくつかのサービスをデプロイするだけでは不十分です。一部のユーザーは、純粋な機能を多数の仮想マシンで実行することでリソース利用率が低下しているにもかかわらず、Kubernetesインスタンスの作成に固執し、結果としてコストを増加させる場合があります。

そのため、最初のステップは、Kubernetes（K8s）に移行する前に、どの程度コンテナ化を実施すべきかという合理的な計画を立てることです。マシン使用率を下げ、リソース使用率を高めることは、コスト削減と効率向上に不可欠です。コンテナ化は、単にK8sインスタンスをいくつか構築して終わりにするのではなく、真に体系的な見直しと変革であるべきであることに留意することが重要です。システム変革後、K8sに展開すると、現在すべてのクラウドベンダーがK8sサービスを提供していることがわかります。つまり、業務システム全体をK8s上にコンテナ化すれば、マルチクラウド展開の利便性を享受できるようになります。マルチクラウド展開は必然的に交渉力と利用の多様性を高め、ビジネスにとって最も低コストの展開場所を選択できるようになります。

さらに、インフラに関して言えば、弊社の社内インフラは高度に抽象化されています。以前はDevOpsと呼んでいましたが、今ではプラットフォームエンジニアリングとリブランドされているかもしれません。ベンダーの視点から見ると、それほど大きな違いはありません。なぜなら、プラットフォームエンジニアリングという正式な概念が存在する以前から、弊社のお客様の中にはこの概念を持っていた方もいらっしゃるからです。彼らはシステムをコンテナ化し、Kubernetes（K8s）上に配置することで、業務ロジックをK8sに沿わせています。開発やテストを含む環境全体の展開は、API経由で連携可能です。K8sインフラを基盤として、上位層のアプリケーションを含む業務システム全体を、あらゆるクラウドに展開できます。これが、インフラとコードが持つ可能性です。

まとめると、企業のコスト削減と効率向上の鍵は、ITシステム全体とビジネスプロセスを真にエンジニアリングできるかどうか、つまり、人による導入と統合に大きく依存するのか、それとも自動化されたプラットフォームに大きく依存するのかにかかっています。Kubernetes（K8s）を使えば、APIを抽象化する必要も、エコシステム接続を構築する必要もありません。K8sがすべてを処理します。これは、K8sが企業のコスト削減と効率向上に効果的に貢献できることを示しています。

Q: あなたの意見では、エンタープライズ グレードの Kubernetes 管理ソフトウェアの最も重要な機能は何ですか?

張志博：それは間違いなくマルチクラスタ管理です。なぜマルチクラスタ管理なのか？Kubernetesの歴史的な開発プロセスを振り返ると、大手企業がKubernetesを導入した当初、ユーザーをどのように導いたかが分かります。私たちは数千、あるいは数万ノードを含む超大規模クラスタを構築しました。これらの超大規模クラスタは、多くの綿密な技術的最適化、カーネル最適化、そしてKubernetesを模倣することさえあるため、最終的な実装では確かに非常に高いリソース利用率を実現しました。しかし、こうしたいわゆるベストプラクティスやエンジニアリングエクスペリエンスは、より多くのエンタープライズユーザーに再利用できるものではありません。

その理由は、大企業がほとんどのユーザーには不足している人材と技術力を有しているからです。マルチクラスタアーキテクチャの概念は、まさにその管理がほとんどのユーザーにとってより適しているために生まれました。オープンソースソフトウェアに大幅な変更を加えることはお勧めしません。一度変更を加えると、長期的なメンテナンス、アップデート、アップグレードが不可能になり、エコシステムとの互換性が失われ、バージョンロックインの可能性につながるからです。たとえ知識豊富な人材がいても、退職後の技術サポートが不足すると、技術的な負担となります。

その後の発展の中で、Kubernetesディストリビューションを研究する商用ベンダーが増え、それぞれが独自の機能を備えています。しかし、管理ソフトウェアがマルチクラスタ管理をサポートしていない場合、必要な機能を備えたディストリビューションを管理システムに組み込むことができません。本来、私たちはオープンソースソフトウェアのオープン性を活かし、より広範なエコシステムを吸収してビジネスを支えることを目指していましたが、この技術的な道を選択しなかったことで、自らに課した制約に囚われ、オープンソースエコシステムのメリットを享受できなくなってしまいました。

したがって、長期的には、マルチクラスター管理は企業にとっても、IT 業界の長期的なリスク管理とコスト管理にとっても間違いなく有益です。

Q: Kubernetesをマルチクラウド環境で実行すると、複雑さが著しく増大し、企業の運用・保守の難易度が高まります。現在、これらの問題に対処できるエンタープライズグレードのKubernetes管理ソフトウェアソリューションはありますか？これらの問題を解決する上で、主にどのような課題に直面していますか？他に優れたソリューションはありますか？

張志博：現在、Kubernetes（K8s）はクラウドベンダーにとって重要なインフラとなり、サービスへと進化を遂げています。クラウドアカウントを持つユーザーは誰でも簡単にリソースにアクセスできます。しかし、企業にとって、どの「クラウド」を選択するかが事業範囲を決定づけるという点を明確にする必要があります。海外ではAWS、Azure、GCP、国内ではAlibaba Cloud、Huawei Cloud、Tencent Cloud、そして近年台頭してきたChina Telecom Cloudなどがあり、それぞれに特徴があります。それぞれの「クラウド」には独自の技術的優位性があり、異なる顧客ニーズに応えています。

エンタープライズレベルのKubernetes（K8s）管理ソフトウェアでは、多くのクラウドがそれぞれ類似のサービスを提供しているため、どのクラウドをサポートすべきかという疑問が生じます。海外市場、国内市場、それともすべてのクラウドに重点を置くべきでしょうか？各クラウドには独自のK8sディストリビューションエコシステム進化計画があり、他のクラウドとの統合や通信は行われません。K8sは上流に存在しているにもかかわらず、各クラウドには独自のバージョン追跡計画があるため、これは大きな課題となっています。管理ソフトウェアがサポートするクラウドの数が増えるほど、複雑さは増します。

クラウドベンダーはKubernetes（K8s）を提供していますが、クラウド上でセルフホスティングすることを好むユーザーもいます。彼らは、より自由で制御性の高いソリューションを得られると考えています。実際、私たちはRancherの製品理念をかなり早い段階で変更しました。市場シェアの観点から見ると、K8sの市場シェアの大部分はパブリッククラウドにあるため、クラウドユーザーを優先しています。プライベートデプロイメントに関心を持つユーザーもいますが、大多数のユーザーはパブリッククラウドに留まっています。パブリッククラウド内にはセルフホスティング型とマネージド型の両方のデプロイメントがあり、管理ソフトウェアには新たな課題が加わります。パブリッククラウドホスティングをサポートするだけでなく、パブリッククラウド仮想マシン向けのサービスもサポートし、ユーザーがK8sをセルフホスティングできるようにする必要があります。これにより、ソフトウェアのナレッジマトリックスが非常に複雑になり、それに応じてソフトウェアメンテナーへの要件も増加します。

具体的な課題をまとめると、前述の内容を参考にします。まず、クラウドの種類が多く、統合エコシステムが非常に複雑になります。次に、知識マトリックスが複雑で、ユーザーにはセルフ構築とマネージドの両方のニーズがあります。特に良い解決策はあるのでしょうか？実際、市場に出回っている主流の管理ソフトウェアはすべて、多様なKubernetes管理機能を備えていると主張しています。しかし、実際にどのくらい多くの種類のクラウドをサポートしているのか、セルフ構築モデルとパブリッククラウドのマネージドモデルのどちらをサポートしているのかを詳しく調べることが重要です。この点では、Rancherの方が優れていると思います。

Q: Rancherには、K3sという非常に有名なオープンソース製品があります。その軽量性から、多くのユーザーがエッジコンピューティングのシナリオに導入しています。エンタープライズグレードのKubernetes管理ソフトウェアがエッジ環境で解決すべき主な課題は何でしょうか？現在市場に出回っている製品は、これらの課題に既に対処していますか？

張志博： Kubernetesのマルチクラスタ管理に特化したRancherに加え、K3sも私たちが開発した優れたソフトウェアです。当初、K3sは非常に軽量なソフトウェアとして構想していました。エッジコンピューティングがまだ発展途上だった頃、エッジシナリオにコンテナ化を実装しようとする動きが活発化し、K3sも自然とこれらのシナリオで活用されるようになりました。しかし、エッジシナリオのニーズに対する理解はベンダーやユーザーによって異なり、各ベンダーは自社の理解に基づき、自社のユーザーがこの問題を解決できるよう支援しています。

K3sは非常に明確なポジショニングを持っています。基本的に、K3sはKubernetes適合性テスト標準を満たすディストリビューションと定義しています。これは、CNCFがKubernetes適合性テストをリリースした際に、標準ディストリビューションであることを確認するために、一連のエンドツーエンドテストを実行する必要があることを意味します。K3sは常にこの点に重点を置いています。また、特定のシナリオに合わせてK3sを大幅に変更することはないため、そのような変更は互換性の問題を引き起こす可能性があります。K3sをエッジに強制的に適用すると、一部のユーザーシナリオで問題が発生する可能性があります。したがって、この説明は製品固有の設計に基づいています。

エッジ環境において管理ソフトウェアが解決する具体的な問題に関しては、ベンダーごとにアプローチが異なるため、業界全体の観点から包括的な概要を提供することはできません。私たちの観点からは、エッジでKubernetes（K8s）を使用したり、ビジネスロジックをK8sの抽象APIにパッケージ化してからデプロイしたりする場合、すべてのエッジシナリオを解決できるわけではなく、ニアエンドのエッジシナリオにしか対応できないと考えています。私たちの視点では、 K3sが現在このレイヤーにしか到達できないのは、K8sオーケストレーションエンジンとコンテナ化されたコンポーネントを実行するのに十分なコンピューティングパワーを持つデバイスに依存しているためです。このコンピューティングパワーがなければ、ビジネスロジックしか提供できず、基本的なエンジンを追加してもリソースの無駄遣いになってしまいます。

現在、私たちはエッジに近いシナリオにおける問題解決に重点を置いています。これらのシナリオは、かなりのコンピューティングパワーを備えているためです。通常、ARMアーキテクチャとx86アーキテクチャの両方で、ビジネスロジックをサポートするためにオペレーティングシステムとオーケストレーションエンジンが必要です。私たちはこれを、基本的にOSとK3sを組み合わせた不変のインフラストラクチャに抽象化しています。SUSEはLinux OSベンダーであるため、このソリューションの製品化は非常に成功しています。

現在、エッジコンピューティング分野の課題は確かに解決可能ですが、エッジ市場は巨大であるため、これ以上詳しく説明することはできません。リモート管理やIoTデバイス管理を含むエッジのあらゆる問題を、純粋なコンテナ化やKubernetesだけで解決しようとするのは非常に複雑であり、少なくとも私たちの観点からは、まだ特に安定した市場機会は見出せていません。

Q: 全体的に、国内企業における Kubernetes の実装と管理に対する要件は何ですか?

張志博：国内企業については個別に検討する必要があります。独立した制御を求める企業もあれば、標準化された商用生産シナリオを求める企業もあります。問題を解決できればそれで十分です。実際、国内企業と海外企業の間に大きな違いはありません。独立した制御に関しては、多くのユーザーがKubernetesの実行にARMに依存しているため、国内企業はARMサポートに重点を置いています。

現在、ARMはパブリッククラウドでますます普及しており、ソフトウェアエコシステム全体がARMをサポートしています。そのため、要件に関して言えば、まずARMのサポートが重要だと考えています。ARMのサポートがあって初めて、こうした自立的で制御可能な企業活動に参加する機会が得られるのです。次に、より深い自立性と制御性、つまりソフトウェアサプライチェーンのニーズが挙げられます。これは、工業製品やその他の規制対象製品のサプライチェーンに似ています。

ソフトウェアサプライチェーンの品質、特にソフトウェアの構築・コンパイルプロセスのトレーサビリティ、納品製品のソフトウェア部品表（BOM）の入手可能性、そしてユーザー認証における改ざん防止能力の重要性がますます高まっています。これらは、中国が現在、自立的かつ制御可能なソフトウェア開発を目指して取り組んでいる重要な分野です。

私たちはまさに、全く新しい探求に取り組んでいます。例えば、国産で開発され、制御可能な技術の分野では、openEulerやその派生製品がOSレベルでより広く利用されつつあります。同時に、 Kubernetes（K8s）ディストリビューションの構築も試みており、openEulerエコシステムを実質的に生産拠点としています。K8sが依存する上流のソースコードはすべてこの生産拠点に投入され、K8sディストリビューションはそこから生産されます。ディストリビューション内では、ソフトウェアの部品表やエンジニアリング数量などの情報を公開できます。現在、openEuler向けRancherディストリビューションは一般提供（GA）されています。

ユーザーが質問しました：「Kubernetesの導入と管理は、企業の技術マネージャーにどのような要件を課しますか？技術の普及活動や人事管理に関して、何か新しい要件はありますか？」

張志博：それは企業によって異なります。標準化された商用シナリオを必要とする企業なのか、それとも独立した管理を重視する企業なのか。企業によって調達ニーズは当然異なります。テクノロジーマネージャーの要件を議論するには、最初の質問に戻る必要があります。商用ソフトウェアを購入して自社のビジネスに統合するのか、それともオープンソースの自社開発アプローチを完全に採用するのか。前者を優先する場合は、サプライチェーンを検討する必要があります。標準化されたシナリオの場合、懸念されるのはサプライチェーンが固定化されるかどうかです。独立した管理の場合、懸念されるのはサプライチェーンがコンプライアンス要件を満たしているかどうかです。

オープンソースソフトウェアの自社開発を検討する場合、コストを慎重に計算する必要があります。商用ソフトウェアを購入するよりもコストは抑えられますが、人件費は莫大です。また、自社開発には技術的なリスクがあり、自社の資金と運用が長期的な開発を支えられるかどうかも重要です。一度自社開発に乗り出すと、止めることは難しく、中断すればこれまでの努力が無駄になってしまいます。さらに、自立性と自主性を重視する企業であれば、ソフトウェアコンポーネントの使いやすさや、ダウンロードしてそのまま使うのではなく、自社の生産施設で製造できるかどうかをしっかりと確認する必要があります。

テクノロジーの伝道活動に関しては、伝道者は話題作りと新しい技術コンセプトの普及に注力すべきだと私は考えています。Kubernetes（K8s）はもはや新しい分野ではないため、今は伝道活動を行うのに適切な時期ではなく、革新的な側面を探求する方が良いかもしれません。

Q: 製品の観点から、今回の商用化をサポートするために Kubernetes にはどのような機能強化が必要ですか?

張志博氏：技術の発展には一定のパターンがあります。今年の商用化の新たなトレンドを理解するには、オープンソースコミュニティが昨年どのような新しい研究を行っていたかを見てみると良いでしょう。Kubernetesは昨年バージョン1.24に到達した後、ソフトウェアサプライチェーン情報をリリースプロセスに統合し始めました。多くの商用Kubernetes企業が今年、ソフトウェアサプライチェーンを重視していることは容易に理解できます。商用企業は、アップストリームコミュニティの技術進化の方向性を絶対に見逃すことはできません。なぜなら、商用企業は自社の地位をさらに強化するために、アップストリームコミュニティが何を実現できるか、いわゆるソフトウェアサプライチェーンを少なくとも示さなければならないからです。

どのように「強化」するかという点において、現在の大きな潮流は技術伝道です。Kubernetes（K8s）は急速なイノベーションの段階を終え、今やエンタープライズ導入に注力し、その導入を加速させる必要があります。Kubernetesの導入企業が増えるにつれて、セキュリティとコンプライアンスの重要性が高まり、本番環境を保護するための様々な保護対策が必要になります。これは、あらゆる新技術が成熟するにつれて必ず従う客観的な法則と言えるでしょう。

この分野の商用開発をどのようにサポートしていくかについてですが、上流Kubernetes（K8s）エコシステムのイテレーション速度が非常に速いため、Rancherを含むクラウドベンダーは、商用K8sプロバイダーとして長年の経験を積んできたにもかかわらず、依然として上流バージョンのイテレーションに追いつくのに苦労しています。これが深刻な断片化につながっています。Android時代と同様に、スマートフォンの普及に伴い、Androidで最も厄介なのは、4.xや6.xといった複数のバージョンが存在することです。ユーザーにとっては、頻繁なアップデートを必要とするユーザーもいれば、そうでないユーザーもいますが、現在のバージョンはライフサイクルを過ぎている可能性があります。このような状況では、比較的古いバージョンに対する長期的なサポートを提供することが不可欠です。

Q: 近年、国内のソフトウェアサプライチェーンのセキュリティ、コンテナセキュリティ、コンプライアンス問題への注目が高まっています。これは、エンタープライズレベルのKubernetes管理ソフトウェアの開発にどのような新たな要件をもたらすのでしょうか？

張志博：この1年間の個人的な経験から、エンジニアリングの難易度は大幅に高まり、最も重要な側面となっています。人材は限られているため、既存バージョンの継続的な進化をサポートするために、エンジニアリングを継続的に改善する必要があります。どんなソフトウェアでも、人材を投入する限り効率性を確保しなければならず、金銭的および時間的なコストが常に発生します。したがって、無制限の投資ではなく、妥当な利益率が不可欠です。Kubernetesのバージョン断片化の解決、コンテナのセキュリティとコンプライアンスの確保、ソフトウェアサプライチェーンの導入などは、人材だけに頼っていては十分に対応できない問題です。私は個人的に、この1年間、エンジニアリングの分野で製品開発に携わり、製品の研究開発チームを率いてきました。昨年のエンジニアリングの量は、おそらく過去数年間の合計を上回ったでしょう。昨年と比較すると、単純なCIタスクだったものが、今でははるかに大きなワークロードを伴うようになり、エンジニアリングの重要性が浮き彫りになっています。

Q: 2023年のKubernetes商用化の今後の開発動向について、どのようにお考えですか？どのような技術的進化を遂げるでしょうか？その理由は？

張志博： 1年という期間は短く、トレンドへの進化と呼ぶには短いと言えるでしょう。しかし、この2ヶ月間、お客様との対話を含めて振り返ると、確かに一定のフィードバックをいただいています。企業のKubernetesに対するニーズは、数年前の「Kubernetesこそが全て」だった頃とは異なります。当時は誰もが新しいテクノロジーで多くのことが可能になると信じ、様々なことを想像していました。しかし、今は違います。人々はテクノロジーに複雑なイノベーションを求めるのではなく、高効率なツールとして導入・実装することを求めています。コンテナ管理は確かに企業の生産性向上をもたらしており、Kubernetesの真髄であるコンテナ管理こそが、企業にとっての根本的なニーズなのです。

多くのお客様は、もはや過度に先進的なイノベーションへの投資をやめ、ソフトウェアのできることとできないことを徐々に認識し始めています。そのため、今年は商用化が順調に進展するはずです。

Q: 現在、市場にはどのような種類の Kubernetes ベースのソリューションが存在しますか? 市場はどの開発段階にありますか?

張志博：ソリューションといえば、まず商用化が思い浮かびます。商用化はパブリッククラウドのマネージドサービスという形で行われます。AWSのEKSやAlibaba CloudのACKのように、どのクラウドベンダーでもアカウントさえあればKubernetes（K8s）サービスを構築できます。SUSEもRancherのようなエンタープライズグレードのコンテナ管理ソフトウェアを提供しています。プライベートクラウドかパブリッククラウドかに特別な配慮は必要ありません。RancherはすべてのK8sリソースを一元管理できます。K8sフレームワークをベースに革新的な機能を提供するディストリビューションも存在します。これらはすべて商用化の形態です。

現在の市場発展段階は、商用市場の台頭と技術革新をめぐる熱気の明確な衰退にあると私は考えています。ガートナーのレポートによると、2020年には世界の企業の約5%がコンテナ化技術を導入しており、この数字は2024年までに15%から20%に達すると予測されていました。ガートナーのインタビューは、一般のコミュニティユーザーだけでなく、経済的に余裕のあるユーザーに焦点を当てていたと考えられます。したがって、商用市場と有料導入の可能性は依然として大きく、Kubernetesが成熟し続けることが不可欠です。

Q: Kubernetes エンタープライズ ソリューション配信分野における世界的な競争環境はどのようなものですか?

张智博： SUSE 在国内与海外都有涉猎，算是一个在全球卖这种产品的公司。从我们接触到的很多客户来看，公有云应该是一个真正的赢家。关于公有云，无论是打开虚拟机还是打开任何一个服务资源，我们都默认是需要付费的。它的商业模式决定了它很容易把开源软件和K8s 变现，因此它是真正的赢家。​

从全球范围来看，我们目前在海外碰到更多的厂商是OpenShift 这类的，国内目前竞争还是非常激烈的。我有统计，去年几乎每个月都有厂商突然要开源自己的K8s 管理平台。随着厂商越来越多，大家开始内卷竞争，低价的情况随之出现。由于没有长期的正向收益，国内的这类软件就无法成长为有国际竞争力的产品，企业也难以在国际市场站稳脚跟。结合国内市场来看，当前的竞争格局难言乐观。​

Q：刚提到国内的市场形式，在Kubernetes 领域，国内介入也是比较早的，和海外相比，出现当前状况的原因？​

张智博：这也是我个人在这几年的职业生涯中感到非常遗憾的一点。国内对这一波技术的介入非常早，而且原先K8s 落在国内是全球最好的一个user case。但是，为什么在后续成长中我们没有出现具有国际竞争力的产品？​

除了前面提到的厂商过多以外，还有一个原因就是我们的市场规模没有发展起来。海外虽然也有一些小众厂商，但是它的市场规模是可观的，无论是小厂商还是头部厂商都能拿到正向的收益。​

我的理解是，我们没能在关键阶段制定出行业标准。对于长期从事这个领域的技术人员而言，可能认为这个东西不需要标准。但是市场要在各行各业铺开，并非只针对IT 企业和互联网企业。如果没有一个行业标准，对于其他企业来说，采用K8s 和容器技术可谓天方夜谭，这也就造成了市场规模发展不起来的局面。​

我最近在做一些研究，发现美国的国防部从2020 年开始大力引入K8s，它制定了非常详细的厂商准入标准及产品标准。而且这个标准是完全公开的，公开则意味着国防部这一套基于K8s 建设的软件交付平台，其他非IT 行业可以直接参考。这套标准在国内并没有看到，所以市场规模一定是上不来的，大家就只能在仅有的付费客户领域里不断地相互挤压。​

Rancher 在海外有很多客户，这些客户既可能是某个农业公司，也可能是某地区的一个县政府，这在国内很少能看到。行业没有标准化，就没有办法实现可复制，从而导致市场规模发展不起来。​

Q：SUSE 在这个领域也是关键厂商，在整个领域的发展和企业用户痛点来看，你们是否有提出相应对策？​

张智博：今年，产品层面我们还是定位于多集群和多云。目前这已经是一个标配，是一个固定的基础需求。入到这个行业门槛，就得提供这个能力。​

在此基础上，我们尝试扩展边缘领域的产品能力。前面我们提到SUSE 有自己的操作系统，也有K3s，因此我们尝试用产品化解决近端边缘领域的一些问题。这就是我们在做的2.7 版本，它将是我们整个2023 年运作的一个大版本。​

然后再走入生产化这个大趋势，我们判断产品质量、迭代质量是非常重要的一块。为什么今年要特别提出来，确实是现在生态和K8s 碎片化很复杂。我们前面也提到了工程化，如果不做好，Rancher 是开源软件，我们在全球非常多的用户，每个版本出来大家都会发现有一些瑕疵。不过开源软件也有好处，这些信息都是公示出来的，会有临时解决方案，发现问题了可以及时规避。​

而且场景确实太多了，有的用户用AWS，有的用户用Azure，不同的云效果也不同。现在如果不去做更多的工程化来治理产品质量，情况就会愈发艰难。如果把软件范围限定在某个特定领域，就失去了K8s 企业管理软件的核心。我们要让大家在不同的场景、不同的资源池里去使用它。​

除了前面讲到的2.7 版本，我们也在尝试去凸显社区版本和商业版本间的差异性。Rancher 本身开源，它相当于提供了一个社区版本，但我们也研发了一个商业版本，叫Rancher prime 。不过它完全是在社区版本的基础之上，再去为商业客户服务。它更加关注于企业付费客户看中的东西，包括安全性的增强、漏洞的及时修复、合规性、软件供应链等。​

当然我们也面临着激烈的竞争，我们的策略是，在国内的生态里面用本地的研发团队去治理。国内的IT 环境有其特殊性，因此我们要有一个独立的治理体系去做这个产品。很明显，在国内大家用的都是国内的几朵“云”，很少去用AWS、Azure 之类的。操作系统基本选择自主可控的Linux，而不会采用国际上主流标准的几个大的Linux。当然也有一些想出海的企业，它们要面临海外的监管标准，那么就需要有软件帮忙辅助。针对于此我们也在积极探索，作为一个外企的软件本身具有优势，在支持国内企业出海的时候，我们也可以把这个经验复用给它。​

​​深度了解，敬请下载《Rancher Prime 产品概述白皮书》​​​

Q：Rancher Prime 目前是V2.7 版本，下一个版本或者是说Rancher Prime 未来的迭代方向规划是怎样的？主要会解决哪些问题？​

张智博： 2.7 版本是去年10 月份发布的，2.8 版本预计在2023 年的11 月底或者12 月发布。现在是2023 年初，其实谈不上特别大的未来迭代。​

不过总体思路是不会变的。我们判断现在的趋势是K8s 向生产环境落地，所以我们所有的产品都将朝着这个方向努力。当然，除了自身的产品迭代以外，我们也会通过技术收购来围绕Rancher 去建设整体的产品能力。​

网友提问：除了Rancher Prime，SUSE 在2023 年还有什么大动作吗？​

张智博：其实，我们在去年年底就已经有了对今年的预测。 2023 年不会是激进扩张的一年，不止我们，包括全球许多企业也都倾向于持防御姿态，因此并没有特别夸张的大动作。目前我们的目标就是真正扎实地做好商业化的落地，在市场商业化的份额上升的时候，我们能够吃掉匹配我们现在市场地位的份额，对我们来说已经非常值得努力的一件事了。​

在这个过程中，安全肯定是我们非常看重的，未来我们将继续围绕着这个点去做，在Rancher 的基础能力上做安全扩展。​

Q：回溯到主题，企业想要实现降本增效的目标，企业进行Kubernetes 落地，您有什么建议？​

张智博：技术要关注其本质，即K8s 在解决什么问题，它其实就是为企业采用容器化带来便利。容器化在真正变革企业的应用交付方式，而在这个过程中，使用K8s 肯定是必不可少的经历。K8s 在走入生产环境后，我们要去关注它整体的稳定性，包括K8s 整个社区API 组件的稳定性以及管理平台的稳定性。此外就是安全问题，容器运行时的安全问题、镜像安全的治理、容器网络安全、包括现在提倡的供应链安全。​

现在追求的是整体的安全性，它并不是简单几个点。容器化改造，供应链势必会更加复杂。不像以前用虚拟机只需固定一个版本，容器化打包会有多个版本。由于供应链变得愈发复杂，整个行业也急需跟进治理。​

考虑完整的稳定性，前提要看清本质。你要知道依靠K8s 不能帮你立即达成效果，而是在建设过程中，基础设施经过不断地演进，K8s 才能够跟你的业务完整地整合起来。容器化是先行，再是迁移，迁移后具备了标准化的基础设施，进而把它面向多云。​

多云之后就拥有了议价权。你可以在不同的云上尝试无状态应用的多元部署，还可以去做ARM 的实例迁移。我们知道云上ARM 的价格比X86 要便宜大概30%，在这种操作之下，节省成本立竿见影。而且对业务的影响、对架构的影响均是完全可控的。​

网友提问：Rancher prime 有较为成熟的应用案例吗？目前已经合作的企业里面主要应用于哪些行业？​

张智博： SUSE 有一个专门的站点来收集、展示客户的应用案例。大家知道，Rancher 这个软件已经存在很多年了，那么它必然积累了大量的、成熟的案例。它遍布的行业也很多，包括金融、保险、银行、制造业、汽车等。​

了解SUSE 成功案例，请点击​​https://www.suse.com/zh-cn/success/​​​

について

SUSE 是全球范围内创新且可靠的企业级开源解决方案领导者，财富500 强中有60% 以上的企业依靠SUSE 为其关键任务的工作负载赋能。SUSE 专注于企业级 Linux、企业容器管理和边缘解决方案，通过与合作伙伴和社区合作，帮助客户随时随地在任意场景进行创新——无论是在数据中心、云端还是边缘环境。​

SUSE 让“开源”重新“开放”，使客户能够灵活地应对当今的创新挑战，并能够自由地在未来发展其 IT 战略和解决方案。SUSE 在全球拥有2000余名员工，2021 年在法兰克福证券交易所的监管市场（Prime Standard）上市。​