Kubernetes を採用しますか?避けるべき落とし穴をいくつか紹介します

ツールの使い方を知ることは、それをうまく使うための鍵であり、この概念は週末の趣味のプロジェクトだけに当てはまるものではありません。 Kubernetes のような DevOps の基本と同様に、アーティストのお気に入りの絵筆や木工職人の旋盤でも同様です。システムを徹底的に理解することで、生産性を高めることができます。

...少なくともそうあるべきです。多くの開発者は、お気に入りのツールキットの基礎を学ぶ時間さえほとんどなく、それを企業で使用できるようにするための複雑な部分まで掘り下げる余裕はありません。実のところ、Kubernetes を習得するのは簡単ではありません。このような強力なツールの複雑さはそれほど過剰ではありませんが、自分の足場を見つけようとしている人々を遠ざけてしまうことがよくあります。

そのため、私たちは 2022 Kubernetes ベンチマーク調査を作成しました。導入が順調に拡大するにつれ、クラウドネイティブワークフローを活用するチームが増えています (ただし、期待どおりの結果が得られない場合もあります)。そこで私のチームと私は、業界全体の 1,160 を超える開発チームを数か月かけて調査し、K8s の設定と実践をベンチマークしました。その過程で、私たちは以下の質問を検討しました。

高パフォーマンス組織における K8s の使用法の違いは何ですか?
チームの構造、文化、アプローチは、K8 の管理の成功にどのように影響しますか?
パフォーマンスの低い K8s 初心者がコンテナ化の達人として成功する現実的な道はあるのでしょうか?
将来を見据えた K8s セットアップを作成する正しい方法はありますか?

私たちの調査には、カスタム Kubernetes パフォーマンススコア (KPS) が組み込まれました。質問に対する回答と幅広いデータポイントに基づいて、組織に 0 (低パフォーマンス) から 100 (高パフォーマンス) までの KPS を付与します。次に、完全な情報を提供したチームに分析の焦点を当てました。これにより、回答者のグループが大幅に制限されますが、現在の K8s エコシステムにおける使用状況のより公平な状況が描写されると考えています。

成功には善意以上のものが必要: パフォーマンス測定としてのコンテナ化の実装と計画能力

私たちの研究では、パフォーマンスの低い人と高い人の間に多くの明確な違いがあることが明らかになりました。最も憂慮すべきなのは実装の領域です。トップパフォーマンスのリーダー企業の 66% 以上がすべてのサービスをコンテナ化しているのに対し、低パフォーマンスの企業では 22% 強しかそれに追随していません。

Kubernetes の導入でも同じ傾向が見られ、コンテナ化への適応が K8s を最大限に活用するための鍵となります。 K8s はコンテナオーケストレーションシステムなので、これは当然のことですが、K8s 移行を成功に導く際によく聞かれる反対意見がいくつかあります。

K8 の複雑さを過小評価する: パフォーマンスの高いグループと低いグループの両方がこれを経験しましたが、2 つのグループ間にほとんど違いはありませんでした。したがって、クラスターの立ち上げやクラウドプロバイダーの購入を開始する前に、徹底的なトレーニングを受ける価値があるかもしれません。
導入前に非現実的または不正確な期待を持つ: 多くの潜在的な導入者は、K8 の使用が難しい、または少なくとも思っていたよりも難しいなどの問題に遭遇します。予想していたよりも節約できる金額が少なくなったり、途中でクラウドサービスの非互換性に悩まされたりするケースもありました。

つまり、地に足をつけたほうがおそらくうまくいくでしょう。 K8s は多くの問題を解決できますが、適切な計画と、さらに重要なことに、コンテナ化に全面的にコミットする意欲があれば可能です。

技術的な障壁: セキュリティ、チーム管理、開発者のセルフサービス

私たちが発見した興味深いことの 1 つは、K8s 移行プロセス中にいくつかの一般的な技術的障害が繰り返し発生したことです。状況はさまざまですが、導入を検討する際には、次のような潜在的な課題を念頭に置く必要があります。

適切なセキュリティを実装するのは見た目よりも難しい

K8s セキュリティは回答者の 70% 以上にとって重要なトピックですが、全員が適切に対処しているわけではありません。リーダーが使用する秘密の管理ツールにもかかわらず、パフォーマンスの低い従業員の多くは依然として重大な失態を犯しています。たとえば、多くの企業はリポジトリにプレーンテキストのシークレットを保存し、変更を手動で適用したり、環境固有の構成と環境に依存しない構成を分離できなかったりします。さらに、ベストプラクティスが何であるかを明確に理解していない人もいます。

間違った組織文化はKubernetesへの移行を阻止する可能性があります

K8s への移行は大きな文化的変化となる可能性があります。しかし、こうした変化のほとんどと同様に、こうした変化は上から下へ起こった方がうまく機能するようです。

対照的に、パフォーマンスの低い企業は、K8s の知識を必要に応じて広めるという間違いを犯すことが多く、後で大きな弱点となる可能性のある重要な個別の依存関係を導入します。低得点者は高得点者と比べて、設定を正確に記録して視覚化することができませんでした。また、K8s での開発者のオンボーディングに費やす時間も短縮されます。

開発者にとってセルフサービスがより良く機能する必要がある

セルフサービスももう一つの重要な分割要因です。上位の業績を上げている企業の約 90% が、自社の開発者が独自に、またはオンデマンドでデプロイできると主張しているのに対し、下位の業績を上げている企業では、同じことを主張しているのはわずか 39% です。

心配なことに、パフォーマンスの低い企業の 31% 以上が、チームメンバーのほとんどが何かを壊すことを恐れて K8s クラスターへのデプロイをためらっていると考えています。これは組織の観点からは良い兆候ではありませんが、コンテナ化された運用では他のどの領域よりも多くの潜在的な問題を引き起こします。人的リソースのボトルネックに依存する集中型ワークフローは、自律的に作業してインフラストラクチャを迅速にプロビジョニングする機能など、コンテナ化の主な利点の一部を無効にします。

問題点を超えて

では、チームはどのように K8s のパフォーマンスを向上させるのでしょうか?最も成功したロールアウトは、プラットフォームエンジニアリングチームによって構築された社内開発者プラットフォーム (IDP) のより大きなフレームワーク内に存在することがわかりました。言い換えれば、優れたパフォーマンスを発揮する企業は、開発者が効果的にセルフサービスできるようにするツール、サポートシステム、インフラストラクチャを構築します。

これは驚くべきことではありません。当社の 2022 年ベンチマークレポートは、DevOps の熟練度とセルフサービス機能を備えた社内プラットフォームとの相関関係を調査した最初の調査ではありません (たとえば、Puppet の 2021 年 DevOps の現状レポートや Humanitec の 2021 年 DevOps ベンチマーク調査をご覧ください)。

同時に、効果的な開発者エコシステムは全体的な理想を追求しなければならないことも指摘しておかなければなりません。効果的な IDP は、デフォルトで標準化とベストプラクティスを適用します。その過程で、開発者は否定できない複雑さの落とし穴を回避しながら、K8s を操作できるようになりました。このようにして、開発チームの認知負荷を最小限に抑え、重要なことに集中できるようになります。