K8s は私たちを混乱に陥れました!

マーティン・スウェイツ著

編纂者：ヤン・ジェン

私たちは Kubernetes にとても興奮しており、チームの動きも速かったため、新たな相違が生じていることに気づきませんでした。

1. K8sは普及したが、分裂ももたらした

Kubernetes が登場してからほぼ 10 年になります。過去 5 年間で、あらゆる規模のエンジニアリング チームにおける導入が劇的に増加しました。この爆発的な成長は、静的 Web サイトから本格的なマイクロサービス ソリューションまで、さまざまなアプリケーション タイプにわたるデプロイメントの標準化とスケーリングの実現によって推進されてきました。

Kubernetes は現在、「ハイプ サイクル」段階にあります。エンジニアにとっては、クラウド インフラストラクチャを使用しているかオンプレミス インフラストラクチャを使用しているかに関係なく、Kubernetes をプラットフォームとして提案するのが簡単になります。実店舗の小売店がレジシステムを管理するために単一ノードの Kubernetes クラスターを導入しているのを目にしてきましたし、e コマース サイトが稼働時間を管理するために数百のデータセンターに数千のノードを導入しているのも目にしてきました。

Kubernetes が止められないことは間違いありませんが、熱狂が収まると、Kubernetes が私たちに残したものは、たとえ混乱ではないとしても、違いに満ちていることにも気づくでしょう。

2. 標準化できないものもある

Kubernetes を推進する場合、多くの場合、標準化という話題を避けることはできません。実行するすべてのものをコンテナ化して、すべてのサービスが標準的な形状と標準的なコネクタを持つようにするという考え方です。

実際、Kubernetes は、標準化された方法で大規模なソフトウェアの導入の問題を解決します。しかし、ここに問題があります。ソフトウェアが期待通りに動作しているかどうかを知る方法については触れられていません。アプリケーションによって解決する問題が異なるため、何かが想定どおりに機能しているかどうかを標準化することはできません。

3. K8sがDevOpsに混乱をもたらす

私はアプリケーション エンジニアであり、DevOps の動きを全面的に受け入れているアプリケーション エンジニアです。私にとってそれはまさに運動なので、私はそれを運動と呼んでいます。これは新しい役割や責任ではなく、CI/CD パイプラインや IaC に関するものでもありません。私にとって DevOps とは、私が書いたコードをローカル マシンを超えて活用する専門家とより緊密に連携し、彼らと連携してアプリケーションが最適に実行され、ユーザーに迅速に提供されるようにすることです。

これは私にとって素晴らしいことです。なぜなら、彼らが直面している課題を私が理解でき、彼らは私が直面している限界を理解して解決策を提案できるからです。私たちは一緒に、ユーザーが望むアプリを作ります。

Kubernetes では、開発チームの動きが速すぎて、今度は「プラットフォーム エンジニアリング」という新しい名前の新しい部門が出現していることに気づきませんでした。現在、クラスターを作成できる Kubernetes 管理者はいますが、コンテナーを中心にすべてを標準化しているため、クラスター上で何が実行されているかについては何も知りません。

アプリケーション (コンテナ) とインフラストラクチャ (クラスター) の境界がより明確になったため、これは素晴らしいことだと考える人もいるかもしれません。しかし私はこれに同意しません。私の意見では、エンジニアはデプロイメント、サービス、サイドカー、サービス メッシュ、ノード、ノードの依存関係などについて考える必要があるからです。

「しかし、それは彼らが心配すべきことではなく、プラットフォームの仕事です！」と言うこともできます。しかし、それは私が上で述べた点を証明するだけです。つまり、現在、分断が存在しているのです。私たちは、インフラストラクチャ エンジニアとアプリケーション エンジニアが協力し、お互いの世界を深く理解し、それぞれの部分を理解し、お互いにインテリジェントな質問をできるようにしています。今では私たちは「他の人に任せましょう。彼らは何をすべきか分かっています」と言いますが、それは 10 年前も同じでした。何か問題が発生すると、サイロ化されたチームは互いに非難し合うことになります。アプリケーション エンジニアは、「自分のマシンでは動作したが、本番環境では動作しなくなったので、修正するのはプラットフォームの仕事です」と言えるようになり、プラットフォーム エンジニアはダッシュボードを指して、すべて正常に動作していると主張できるようになります。

誤解しないでください。これらのチーム間で良好な対話を行い、それぞれのタスクを達成するには異なるツールが必要であることを認識して受け入れることが、プロジェクトを実行可能にするのです。プラットフォーム エンジニアは、自動スケーリングからネットワーク ルーティングまですべてを管理し、アプリケーション エンジニアは製品の機能と顧客が最高のエクスペリエンスを得られるよう責任を負います。

しかし、Kubernetes への移行は終わりと見なされているようです。しかし、次の日はどうでしょうか?すべてがそこで実行されれば、私たちには他に何もすることはありませんよね? Kubernetes を毎年アップグレードする必要はありませんよね?

4. K8s が登場しましたが、監視ツールは壊れています。

Kubernetes への移行と、アプリケーションのホストに使用していたインフラストラクチャ (Pod など) の一時的な性質により、アプリケーションを監視およびデバッグする方法が機能しなくなりました。私たちはインフラストラクチャ レベルで使用する方法をアプリケーションのデバッグ技術に適用しています。現在はすべてが標準化されており、すべてがインフラストラクチャになっているためです。これは、Kubernetes で構築するアプリケーション開発者や、システムに関する詳細なコンテキストを開発者に提供したいプラットフォーム エンジニアに深刻な影響を及ぼします。

K8s は最新のアプリケーション開発をサポートするため、メンテナンスのアプローチも進化する必要があります。 Kubernetes はアプリケーションの監視性を高めるのではなく、アプリケーションのデプロイと反復処理を容易にするだけです。これは悪いことではありません。

アプリケーションを簡単に更新し、より多くのデプロイメントを促進し、レッド/グリーン デプロイメントやカナリアを実行する機能はすべて、アプリケーション エンジニアがアプリケーションをサポートする能力を向上させる優れた機能です。アプリケーション開発者がアプリケーションをデバッグしやすくなるわけではありません。最良のシナリオでは、Kubernetes がデプロイメント システムの選択肢になる前に、私たちはこの状態でした。最悪のシナリオでは、調査が必要となる障害点がさらに増えることになります。

固定数のサーバーを扱う場合、各サーバーをアプリケーション メトリックのディメンションとして追加します。次に、アプリケーションのバージョン番号を追加します。そこからドリルダウンして、どのバージョン/どのサーバーに問題があるか、またはすべてのサーバーに問題があるかどうかを確認できます。サーバー名とアプリケーション バージョンの組み合わせは、時系列集計データベースに適した低カーディナリティ データです。ただし、現在はポッドをいつでも再スケジュールできる状況になっており、新しいノードを使用する可能性があります。デプロイメントごとに新しい Pod 名が付けられますが、ほとんどの場合、これは従来のメトリックベースのシステムでは処理が難しい高カーディナリティ データです。

5. プラットフォームチームとアプリケーションチームが分離しており、コンテキストが不足している

先ほど言ったように、ユーザーはインフラストラクチャを気にしません。ポッドは、Kubernetes における最小のリソース管理コンポーネントです。 CPU、ネットワーク帯域幅、または Pod でサービス メッシュが使用されているかどうかは考慮されません。サービスごとに 1 つでも 10 つでも構いません。彼らが気にするのは、システム全体が彼らの要求に応答するかどうかだけです。

コード内に例外、HTTP エラー、またはその他のタイプのエラーがない限り、インフラストラクチャの問題としてプラットフォーム チームにプッシュされる可能性が高くなります。レイテンシに関連するもの、またはアプリケーション エンジニアにとって意味をなさない応答はすべて、調査のためにプラットフォーム チームにプッシュされました。この時点では、プラットフォーム チームはアプリケーションに関する情報をほとんど持っておらず、粗いメトリックに基づいてインフラストラクチャの問題を調査することしかできませんでした。再び、私たちは孤立したチームに分かれており、お互いに話をしませんでした。

現実には、問題はポッドにある可能性もありますが、コードにある可能性もあります。この段階では、問題が単一のインフラストラクチャ コンポーネント (ポッドやノードなど) に限定されているのか、それともすべてに影響しているのかを把握できる必要があります。ここで、アプリケーション テレメトリの Pod 名などの高カーディナリティ データを考慮することが重要になります。

だからこそ、このギャップを埋める必要があるのです。プラットフォーム エンジニアとアプリケーション エンジニアは連携して作業する必要があります。アプリケーションとインフラストラクチャに関するコンテキストに基づいた詳細なデータが必要です。顧客の不満の理由を完全に理解するには、顧客中心のデータ (アプリケーション エンジニアがアプリケーション固有のコンテキストを提供するためにカスタマイズしたトレースなど) とインフラストラクチャ中心のデータ (プラットフォーム チームが管理する Kubernetes メトリックなど) を相関させる必要があります。

6. 最後に: K8s は万能薬ではない

企業が Kubernetes への移行を完了し、運用モードに移行する際には、サイロ化されたアプローチを避けるように注意する必要があります。プラットフォーム エンジニアリングには、アプリケーション エンジニアのサポートと、アプリケーション エンジニアが連携してお客様に最善のサービスを提供する方法が含まれます。これらのチームが連携して作業できるように、プロセス、ツール、文化を提供することが重要です。これにより、「私たちと彼ら」という意識がなくなり、全体的な顧客体験の低下につながることがなくなります。

これは制御ではなくコラボレーションを通じて行われます。覚えておいてください: 人々がツールを使いたいのではなく、コマンドによってツールを使用しなければならない場合、そのツールに何か問題がある可能性があります。

シームレスに連携する高性能チームを構築するには、共通の技術言語を橋渡しとして使用する必要があります。トレース (開発者中心、顧客中心) とメトリック (プラットフォーム インフラストラクチャ中心) を通じて統合された考え方を提供する OpenTelemetry などのツールを使用すると役立ちます。

プラットフォーム エンジニアリング チームとアプリケーション/製品エンジニアリング チームは、最高の顧客エクスペリエンスを提供するために連携しますが、これらの関係は育む必要があり、無料ではありません。

つまり、Kubernetes はソフトウェアからより優れたパフォーマンスを得るための万能薬ではありません。複数のチームが協力して作業することが重要です。

元のリンク:

https://thenewstack.io/what-happens-to-devops-when-the-kubernetes-adrenaline-rush-ends/