BackstageでKubernetesプラットフォームを解き明かす

これは「BackstageでKubernetesプラットフォームを解き明かす」です。 マット・クラークです。 私はSpotifyのシニアエンジニアです。 私は、 Financial TimesのSpotifyが登場する前で、約7年間Kubernetesに携わってきました。 そして、私はBackstageがオープンソースになる前を含め、4年間働いてきました。 私はSpotifyのデプロイメントインフラストラクチャチームに所属しています。 私はKubernetesプラグインのBackstageプロジェクトエリアメンテナーであり、VMwareで働くJamie Klassenと一緒にここにいませんでした。

始める前に、SpotifyとKubernetesについて少しお話しします。 私たちは、マルチテナント Kubernetes クラスタと呼ばれるもの、つまり Google Kubernetes Engine(GKE)上の約 40 つのクラスタを担当しており、すべてのバックエンドとウェブサービスを実行しています。 私たちの高水準点、高トラフィックレベルでは、約 270、000 ポッドがあります。 つまり、これらはかなり巨大なKubernetesクラスターです。 Spotifyには、MLやデータパイプラインなどを行う他の多くのKubernetesクラスターがあります。 Spotifyでのデプロイメントは盛り上がりです。 エンジニアは、1日に約 3回、000 回も突き刺します。 そして、私たちのサービスの大部分はKubernetes上にあります。 当社のサービスの一部は、従来のコンテナオーケストレーションシステムであるHeliosを利用しています。

プラットフォームエンジニアリング

これは、プラットフォームエンジニアリングについての話でもあります。 プラットフォームエンジニアリングとはどういう意味ですか? これは、開発者の生産性を向上させ、労力を減らすために、組織内の他の開発者向けのツールを構築するという考え方です。 つまり、社内のユーザーを顧客として扱う必要があるのです。 私たちは毎日お客様の隣に座ることができるので、とても幸運です。 パネルや顧客関係マネージャーを通じて顧客と話し、フィードバックを得なければならない人もいます。

プラットフォームエンジニアとして、あなたは非常に幸運です。 そうすれば、そのようなハードルはありません。 通常は、それらを緩めることができます。 直接のコミュニケーションラインがあるのは素晴らしいことです。 また、社内のユーザーはお客様であるため、サポートを提供し、ツールを製品のように扱う必要があります。 これは主にSlackを通じて行われます。 そして、なぜそれが重要なのかについては、もう少し後で戻ってきます。

まず、Kubernetesで謎を解くために何があるのか、考えているかもしれません。 私は Kubernetes に 5 年間携わっています。 そして、それはそれほど難しくありません。 それは、私たちが x 年間 Kubernetes に取り組んできたからかもしれません。 学べば学ぶほど少し楽になりますが、時間がかかります。 問題は、Kubernetesの学習曲線が急で長いことだと思います。 そして、物事をどんどん掘り下げていくと、それは進み続けます。

プラットフォームエンジニアとして、ツールを提供し、学習曲線を短縮し、エンジニアの生産性を向上させることが私たちの仕事です。 これには通常、ユーザーが行うべきではないと考えている作業を取り除くことが含まれますが、時にはそうすることもあります。 また、ユーザーが誰であるかを知ることも重要です。 開発者の関心事はさまざまです。 彼ら全員を開発者としてひとくくりにして、同じように扱うことはできません。 当社のエンジニアの中には、インフラツールに非常に興味を持っている人もいます。 彼らはKubernetesを掘り下げます。 彼らはそれを深く理解したいのです。 そうすれば、プラットフォームを活用でき、機能の提供に過度に集中している他のエンジニアほど多くの質問を抱くことがないかもしれません。 彼らはユーザー向けにデプロイしたいと考えており、インフラストラクチャツールにはあまり焦点を当てていないのかもしれません。 どちらも完全に有効な視点であり、それは問題ありません。人は違います。

Kubernetesへの道のり

この画像はパラクから見ました。 そして、これはKubernetesのこの急な学習曲線を見事に表現していると思いました。 それはKubernetesの氷山と呼ばれています。 そして、その上部にDockerがあります。 ポッドがあります。 デプロイメントがあります。 kubectl runがあります。 これらは、人々がすでに知っているかもしれないこと、または非常に簡単に習得できることです。 あなたは彼らをかなり簡単に拾って走ることができます。 しかし、そのスライスを理解したら、次のスライスに移り、イングレスやジョブ、設定はどうだろうと考えるようになるのです。 その後、アフィニティなし、ステートフルなワークロード、永続ボリューム、監視に入ります。 そして、 DockerとKubernetes 自体のビルディングブロックに取り掛かるまで、それは続きます。 私たちは、ユーザーをこの氷山に押し上げようとし、その低い氷山のものを自分たちで利用します。 しかし、これはちょっと難しいです。 しかし、私たちがどのようにしてここまでたどり着いたのかを理解すると、これは非常に典型的なKubernetesへの旅かもしれません。

これは、どの組織でもどのようなものかについて話します。 Kubernetes を使用することを決定したとき、どのような感じですか? そして、それを組織全体に展開したいと考えています。 ですから、通常、Kubernetesは私が何らかのビジネス目標を達成するのに役立つと思うでしょうし、あるいは単にクールだと思うかもしれません。私はそう思いますが、Kubernetesも役立ちます。 高度なスケジューリング、自動スケーリング、ある種のKubernetesネイティブツールのインストールに使用したい場合があります。 そして、あなたは、Kubernetesを使用するだけで、これははるかに簡単になると思います。 それからそれは私にこれらの素晴らしい機能を提供します。 そして、実験的な方法で実行する傾向があります。 もしかしたら、1つのチームがKubernetes上で独自のサービスを実行しているかもしれません。 Kubernetesダッシュボードまたはkubectlを使用してKubernetesデプロイメントを監視します。 そして、そのクラスターにあるすべてのものを掘り下げます。 クラスターは彼ら自身が所有します。 これらのクラスターで実行されるすべてのサービスを所有します。 したがって、Kubernetesダッシュボードとkubectlは、この場合に非常に適している可能性があります。

問題は、実はKubernetesがスケーリングやスケジューリングなどに非常に優れていることに気づくと、採用が増え始めることです。 そして、導入が順調に進み始め、より多くのサービスが Kubernetes に移行し始めます。 あるいは、あるチームが、これらのことをKubernetes上で実行していて、それがうまくいっているので、私たちも同じことをするかもしれないと言います。 しかし、古いクラスターを維持したくはありません。 彼らのものだけを使いましょう。 物事はうまくいっていますが、その後、ああ、実際には1つのクラスターでは十分ではないと考えるような、より複雑なケースに陥ります。 なぜなら、レイテンシーを減らすために、リージョンに対してローカルで実行する必要があるからです。 あるいは、あるチームが独自のクラウドプロバイダーを必要としているかもしれませんし、あるチームが独自のクラスターを望んでいるかもしれません。 事態は非常に複雑になり始め、最終的には組織の本番環境に複数のKubernetesクラスターが存在することになります。

そして、このような岐路に立たされるのは、ここでどのようなプラットフォームエンジニアリングの哲学を持つのかを考えるときです。 マルチテナントクラスタは持つのでしょうか? プラットフォーム エンジニアは、中央クラスターを管理します。 そして、誰もが自分のものをそれらに取り付けるだけです。 彼らのためにそれをインストールするつもりですか? それとも、シングルテナントクラスターを使用するのでしょうか? また、プラットフォームチームは、これらのクラスターのライフサイクルのツールを管理します。 必ずしも正しい答えや間違った答えがあるとは思いません。 何事もそうですが、それはあなたの組織とあなたが何をしたいかによります。 また、マルチテナントクラスターについても説明します。 しかし、これから紹介する内容の多くは、シングルテナント クラスターにとって依然として非常に重要です。

問題は、これらのKubernetesプラットフォームを提供し始めると、開発者はこれらのKubernetesリソースを待って対話する必要が生じ始めるということです。 また、前に述べたように、Kubernetesについてより詳しい開発者もいるかもしれません。 もしかしたら、Kubernetesについてあまり知らない開発者もいるかもしれません。 そして、それは複雑になります。 非常に複雑になり、私のサービスが実際にどのクラスターで実行されているのかなど、簡単な質問に答えるのに苦労します。 忘れました。 あるいは、このサービスがこのクラスタで実行され、このサービスがそのクラスタで実行されるというメンタルマッピングを維持しているようなものです。 そして、新しい人が加わると、「ああ、これらはあなたが知る必要があることだ」と言うでしょう。 秘密の握手は、このサービスがここで実行され、これがここで実行されていることを知っています。 なぜなら、先ほど述べたように、プラットフォームエンジニアとしての私たちの仕事の1つは、開発者にとってより簡単にすることであり、開発者にとってより困難にし、サービスと名前空間からクラスタへのマッピングを維持しなければならないようにすることではないからです。

そのため、数年前の非常に早い段階でこれらのKubernetesクラスターを展開したときに、サービスがどのクラスターにあるかなどの簡単な質問など、フィードバックが寄せられるようになりました。 また、大丈夫ですか? 本番環境ですか? 実行されていますか? 大丈夫です。 何か問題がありますか? 何かする必要がありますか? そこで、Backstageの出番です。

楽屋

Backstage についてご存じない方もいらっしゃると思いますが、これは開発者ポータルを構築するためのプラットフォームです。 Spotifyのエンジニアは毎日Backstageを使用しています。 CIに関する情報の表示、ドキュメントの表示、Kubernetesデプロイメントの監視などに使用します。 これは、すべてのKubernetesサービスを管理するための1つの場所になります。

Backstageについての話を見たことがある人や、自分で掘り下げたことがある人なら、Backstageのコア機能の1つがソフトウェアカタログであり、誰がサービスを所有しているか、Gitリポジトリがどこにあるか、他のサービスとの関係など、サービスに関する情報を保存していることをご存知でしょう。 カタログの興味深い点の 1 つは、カスタマイズ可能で拡張可能であることです。 そのため、実際にプラグインを構築したり、今日お話しするKubernetesプラグインを含む、組織に適したオープンソースプラグインを使用したりできます。

先ほど提起した2つの質問に答えて、残りの話では次のようにします。 そして、同じことを行う方法について少しお話しします。

Dockerコンテナの構築、ローカルへのデプロイについてよく耳にします。 CI/CDに関する素晴らしい講演が行われました。 そして今、コンテナをデプロイしました。 私たちは、ユーザーである開発者が、監視メンテナンスの観点から何をしているのかを実際に理解するための機能を提供し始めています。 そこで、Backstageの出番です。 それは私たちのサービスへのインターフェースになります。 ですから、先ほど述べたように、私たちはサービスのソフトウェアカタログを維持し、他のツールと統合します。ユーザーは、Backstageを通じてKubernetesリソースを表示します。 この例については、こちらでご覧いただけます。

これは、Backstage用のオープンソースのKubernetesプラグインです。 私はサイコロローラーと呼ばれるサービスを持っており、その責任は私のためにサイコロを振ることです。 だから、バックステージに入るんだ。 所有しているサービスが表示されます。 サイコロローラーに移動し、Kubernetesのタブをクリックします。 そのKubernetesサービスがどこで実行されているか、どのクラスター、デプロイメントサービス、オートスケーラー、すべてについての情報が得られます。 このサービス、このクラスターに 19 ポッドがあることがすぐにわかります。 これらのデプロイがあり、この 1 つのデプロイにも水平オートスケーラーが設定されています。 また、Backstage がこれらの Kubernetes リソースで検出したいくつかのエラーに関する概要情報を次に示します。

ここで行った興味深いことの1つは、ユーザーがKubernetesと対話する方法を実際に変更したことです。 前に述べたように、Kubernetesダッシュボードに移動する代わりに、このサービスがこのクラスター上にあることを覚えておきます。 したがって、正しいKubernetesダッシュボードに移動することを忘れないでください、さもなければ私のサービスは表示されません。 ユーザーはBackstageに移動するだけです。 実際には、サービスがどのクラスターにデプロイされているかについて心配する必要はありません。 Backstageは彼らのためにそれを見つけ、ユーザーのためのサービスのコンテキストでユーザーに情報をもたらします。 そして、それが実際に何を意味するのかについては、後ほど説明します。

これについて興味深いのは、インタラクションが同じになるように変更したことです。 それがサービス1であろうと、サービス2であろうと、Backstageに行くと、BackstageはユーザーのKubernetesリソースを見つけます。 先ほども言ったように、私たちはここで何かを変えました。 したがって、ユーザーは、関心のあるサービスに対してこれらのタスクを実行しているときに、サービス指向を維持しています。 問題の 1 つは、サービスで作業しているときにユーザーがコンテキストを切り替えられることです。 CIを通過したと思ったら、今度はデプロイが正常で、すべてが正常であることを確認したいと思います。 エラーはありません。 クラッシュしていません。

残念なことに、彼らにKubernetesクラスターと直接対話させるだけでは、まず第一に、私のコードを正しいコンテキストに設定するか、適切なKubernetesダッシュボードを開くことを覚えておく必要があります。 その中間ステップを取り除き、BackstageでCIを見た後、このタブをクリックするだけで、すべてのKubernetesリソースが表示されるとします。 そして、この2つのことの間には一歩も踏み出せません。 彼らは自分が気にかけているサービスに完全に集中しています。

よくある質問

もう 1 つの質問は、私のサービスは正常かどうかです。 ですから、この例は非常に簡単でした。 この部屋には、Kubernetesで多くのことがうまくいかない可能性があることを知っている人がおそらくたくさんいるでしょうし、うまくいかない可能性のあるすべてのことを説明するのは難しいというような人はたくさんいます。 そこで、Slackでサポートに関する質問が多く寄せられ、生産性が低下するという考えが浮かびました。 これは、開発者がKubernetesサービスについて質問をし、その後、私たちがそれを読み、調査し、回答するのを待たなければならず、そこには開発者の生産性に大きく影響するキュー時間があるためです。 基本的に、私たちがサービスを見て、私たちが彼らに戻るまで、彼らは何もできません。

そこで、同僚と私は、Kubernetesの問題のデバッグをはるかに簡単にできないか、というハックのアイデアを持っていました。 すでに、開発者がBackstageにアクセスして、サービスの展開を監視しています。 もし、同じ文脈でエラーを見せたらどうなるでしょうか。 そうすれば、サービスの詳細を深く掘り下げたり、Kubernetes のすべてを理解したりする必要がなくなります。

私たちが受けていた共通の質問は、私のデプロイメントが失敗した、そして実際にはなぜなのかわからないというものでした。 「進捗期限を超えました」と表示されます。 助けていただけますか。 Kubernetes にデプロイしているときに "進行状況の期限を超えました" を引き起こす可能性のある多くの要因があることをご存知かもしれません。

では、どうすればいいのでしょうか? まず、私たちが持っていたものから始めましょう。 これはオープンソースのKubernetesテーブルで、基本的には実行中のポッドのテーブルです。 大丈夫です。 私はそれについてあまり興奮していません。 しかし、私たちが気づいたことの1つは、エラーをスキャンするのが難しいということでした。 テーブルでは、実行中のすべてのポッドの全体像を把握できるわけではありません。 ページを戻したり進めたりすると、ああ、このポッドに何か問題があることがわかります。 他のポッドも間違っていません。

私たちは、全体像を捉えられるもの、より視覚的なもの、そして見てすぐに何かが間違っているとわかるものについて考えたかったのです。 この表で実際に見ることができると思いますが、見た目は問題ありません。 あなたは「ああ、私のサービスはうまくいっている」と思うでしょう。 しかし、実際には、すべてのコンテナが3回再起動しています。 そして、それは実際にはどこにも強調されていません。 だから、それを完全にスキップして、すべてが素晴らしいと考えることができます。 私たちは、そのようなことがもう起こらないようにしたかったのです。 そして、ユーザーが実際にそれらのエラーを見つけていたのは、私たちがそれを彼らに強調していたからです。

問題の1つは、先ほども言ったように、うまくいかない可能性のあることが非常に多いことです。 そこで、私たちはこれについて少しデータ駆動型になろうとしました。 kube-state-metricsでは、ポッドが終了する理由や起動に失敗する理由を公開しています。 私たちは、問題のあるすべての問題を解決できない場合でも、公開されている指標を見て、これらを調べて、ユーザーのためにこれらの領域を強調する方法を見つけ出すだけで、大多数を解決できるのではないかと考えました。

ここでの戦略は、これらのエラーをどのようにデバッグするかを考え、そのプロセスをどのように自動化できるかを検討することでした。 以前に確認したエラーでは、基本的にマニフェストログまたはKubernetesイベントを確認するための3つのカテゴリに分類しました。 そして、私たちが見られたような簡単なエラーは、以下の通りでした。

• InvalidImageName -- もしかしたら、そこに存在しない間違った Docker コンテナを置いたのかもしれません。
• ImagePullBackOff -- 実行したいと言っている画像を実際に引っ張る許可がないかもしれません。
• ItemMemory — これは、メモリリークが発生しているサービスの問題である可能性がありますが、通常は、サービスに十分なメモリをプロビジョニングしなかっただけであることがわかります。
• CreateContainerConfigError — これは通常、シークレットまたは設定マップを使用しようとしていて、それが存在しない場所です。

このようなインフラストラクチャのエラーが見られましたが、その後、Kubernetesからはかなり良いエラーメッセージが出ていることに気づきました。 そして、KubernetesからのCrashLoopBackOff、Error、Readinessプローブのエラーメッセージがなぜそれほど良くないのか、本当に疑問に思っていました。

そのとき、私たちは何となくピンときたのですが、振り返ってみると、CrashLoopBackOffとReadinessプローブの失敗というエラーは、実際にはインフラストラクチャツールからサービスのランタイムに境界を越えるエラーであることは明らかかもしれません。 そして、基本的には、トレースに統合するか、何らかの優れた監視設定がなければ、何が問題なのかを知ることはできません。

ユーザーが私たちのところに来て、「ポッドがクラッシュしました」と言い、エラーと表示されたとき、何が問題になっていますか? 私はインフラエンジニアですが、実は彼らのサービスが通常何をしているのかは知りません。 だから、ここで何が問題なのか教えてほしいんだ、なぜクラッシュしたのかもわからないから、なんとなくて。 ですから、それを掘り下げてみて、「ああ、このログが役立つかもしれない」と言うかもしれません。

これらは、このエラーが発生した理由をユーザーに提供することはできませんが、非常に近いエラーに近づけることができるエラーです。 また、ログを表示したり、Kubernetesイベントを表示したり、少なくともこれらのエラーが発生している理由についてユーザーにできるだけ多くのコンテキストを提供したりすることで、以前よりもはるかに近づくことができます。 もう 1 つは、正しいドキュメントに適切なタイミングでリンクしたかったということです。 そのため、ユーザーは私たちが何かを見せたとは感じず、私たちが何を言っているのかまだ理解していませんでした。 私たちは常に、問題をより深く説明できる別の場所へのリンクを用意し、いつでもSlackチャンネルに戻ってくることができるようにしたいと考えていました。 それが私たちの素晴らしいセーフティネットでした。

ユーザーへのエラーの表示

これが、私たちが最初のイテレーションとして最終的に行ったものです。 私たちのポッドのテーブルからはかなり大きく逸脱していることがわかります。 したがって、これは内部のSpotifyBackstageインスタンスの最初のイテレーションです。 これは現時点ではオープンソースにはありません。 これについては、後ほど少しお話しします。

Kubernetesについて何も知らなくても、ポッドでコンテナを実行していることしか知らないかもしれません。 そして、それが本番環境で表面が打撃を受ける方法です。 ここで何が起こっているのかは、7つのポッドがあることを知っているので、すぐにわかります。 そして、そのうちの3つは良さそうだと思います。 緑色です。 そして、そのうちの4つは、大きな警告メッセージがあるため、あまり良く見えません。 そして、そのうちの1つは2つと書かれており、他の1つは1と書かれているため、2倍良く見えません。

私たちは、ユーザーがKubernetesについてあまり知らなくても、何が起こっているのかを視覚的に表現するだけで、何が起こっているのかをかなり明確にしたかったのです。 また、ユーザーがBackstageを通じてKubernetesについて実際に学ぶのにも役立ちます。これは、私たちが乗り越えようとしていることの1つです。 そして、これらのエラーが何であるか、これらの数字が何を意味するのか、または警告について混乱することはありませんでした。 また、右側にユーザーに表示されているすべてのエラーの集約リストもあります。

エラーを見てみましょう。 これはKubernetesのエラーであり、これが実際に何を意味するのかをユーザーに説明できます。 ですから、これが私たちが検出したエラーです。 私のコンテナであるmclarkeエラーテスターは2回再起動しました。 そして、これはKubernetesがエラーと呼ぶものです。 そして、それは実際にはどういう意味なのか、説明します。 コンテナがゼロ以外の終了コードで終了し、その終了コードは2つだったとします。

エラーが何であったかを報告するだけでなく、さらに一歩進んで、私のペットのイライラの1つは、何か問題が発生したときに何をすべきかを教えてくれないエラー報告であるため、クラッシュログをチェックしてスタックトレースがあるかどうかを確認し、エラーコード2で終了した理由を教えてくれるかもしれません。 ちなみに、クラッシュする直前のサービスのログがこちらです。 ですから、私たちは、ユーザーがここで何が起こっているのかを理解するために必要なすべての情報を提供するだけです。 彼らはそれを探しに行く必要はありません、それは本当に私たちが達成しようとしていたことです。 つまり、これはインフラストラクチャからサービスにある程度交差するエラーです。

はるかに単純なエラーは、何が間違っているのかをすぐに見分けることができる InvalidImageName です。これは、有効な画像ではないため、画像のドル記号プレースホルダーをプルできなかったためです。 そして、おそらく何が間違っていたのかを正確に伝えることができるでしょう。 プレースホルダーを置き換えるのを忘れました。 だから、これが何を意味するのかというと、まあ、画像は有効ではありません。 また、有効な画像名の表示に関するリンクもこちらです。

これをリリースしたとき、私たちは心配でした、本当に人々はこれを好きになるのでしょうか? 人々は私たちが以前持っていたテーブルをなんとなく気に入っていました。 しかし、社内で機能フラグを付けてリリースしたとき、他のKubernetes管理者と話し合ったところ、他の人の問題をデバッグしているときに、サポートに関する質問が来たと言いました。 kubectlやダッシュボードを使用する代わりに、この機能フラグをオンにして、Kubernetes、Kubernetesページ、Backstageに移動し、これが実際に役立つかどうかを確認してください。 これを理解することさえできますか? うまくいけば、あなたができるなら、彼らもできるでしょう。 そして、Kubernetesの管理者から、これは本当に便利だという素晴らしいフィードバックを得るようになりました。 たぶん、これを内部ユーザーのデフォルトのビューにする必要があります。

4月には、それを実現しました。 そして、Kubernetesプラグインとのインタラクションがほぼx100 増加するなど、この大幅な増加がすぐに見られました。 それ以前は、人々が入ってきて、何かがおかしい、はい、いいえと言うだけで、何が間違っているのかを正確に教えてくれなかったと私たちが考えていました。 そして、彼らはすぐにkubectlに行き、それ以上プラグインと対話することはありません。 しかし、これにより、先ほど述べたように、ユーザーはBackstageでのサービスに集中することができました。 コンテキストを切り替える必要はありませんでした。 そして、彼らは何が起こっているのかについてのエラーレポートをすぐに受け取りました。 彼らはそれを探す必要さえありませんでした。

講演の冒頭で私が言ったことの1つは、ユーザーと話し、フィードバックを得ることについてでした。これは非常に重要なことです。 このビューと前のビューの違いは、右上にいくつかの優れた新機能があることに気付くでしょう。 これはプラットフォームエンジニアリングの重要な部分の1つであり、ユーザーからフィードバックを得ることです。なぜなら、最初のイテレーションをリリースしたときに、「これは素晴らしい」と思ったからです。 これ以上何を望むことができるでしょうか? その後、ユーザーが私たちのところに来て、彼らがもっと何を望んでいるかを正確に教えてくれました。 そして、彼らがそれをしたのは全く正しかったのです。 ユーザーが重要だと考えていたことを見逃していたため、ユーザーと話しなければ簡単にできるからです。

追加機能

これらはすべて、ユーザーからのフィードバックを通じて追加された機能です。 そこで、この2つの異なるタイプのユーザーについて話しました。 インフラストラクチャに本当に興味を持っているユーザー。 彼らはKubernetes、Dockerを深く理解しています。 そして、もしかしたら、これらのエラーを見つけるために私たちの助けさえ必要ないのかもしれません。 そこで、彼らの邪魔にならないように、この小さな接続ボタンだけを提供し、少なくともkubectlコマンドを提供したらどうなるかを決定しました。 コンテキストと名前空間の設定を実行する必要があります。 少なくとも、もう少し早くそこに行くことができます。 そして、私たちはあなたの邪魔をしません。

そして、その反対側にいるユーザーは、クラッシュログを見るために各ポッドをクリックする必要がなかったのです。 そこで、クラッシュログの集約ビューを提供し、すべてを同時に表示できるようにしました。 また、Backstageはログ集約プラットフォームではないため、歴史的に何が起こっていたのかを深く掘り下げる必要がある場合に備えて、実際のログ集約プラットフォームへのリンクも用意しています。

おそらく私のお気に入りの機能は、「グループ化」オプションであり、これは、表示されているポッドをさまざまな方法でグループ化するオプションです。 このビューでは、実際には本番環境でグループ化していることがわかります。 ユーザーから得たものの1つは、このインシデントが発生したということです。 それはこの地域にあり、すべてのポッドが環境によって集約されているため、この地域にあると見分けるのは困難でした。 そこで、これらのアイコンを環境ごとではなく、リージョン、クラスター、またはコミットIDごとにグループ化できるオプションを提供したらどうなるか、と言いました。 これにより、ユーザーは、グループ化されたさまざまな値に基づいて、これらのエラーがどこで発生しているかを推測することができました。 彼らはすぐに、ああ、実際には、これらのクラスター内のすべてのポッドは大丈夫だと言うことができます。 これは、このクラスターに何かが起こっているかもしれないし、この環境やロールアウトしているこのコミット ID に何かがあるかもしれません。 リバートする必要があります。 ですから、フィードバックを得ることは非常に重要です。 私が言ったように、私のお気に入りの機能は、私たちが思いつきませんでした。 それは私たちのユーザーから私たちに与えられました。

さて、この話は「私たちの」KubernetesプラットフォームをBackstageでどのように解明したかとは呼ばれていないので、同じことをどのように行うことができるかについて話しましょう。 独自のプラットフォームを構築するという点では、BackstageにKubernetesプラグインを実装する際の難しさの1つは、他の組織が使用できるほど汎用的に保持することでした。それでも、実際には便利でした。 そして、その理由は、私のKubernetesセットアップがあなたのKubernetesセットアップとは異なるためです。 たぶん、あなたは別の認証メカニズムを持っています。 クラスターの数が多い場合もあれば、クラスターの数が少ない場合もあります。 さまざまなクラウドプロバイダーを使用しています。 他のクラスターに異なるものをインストールします。 別のマルチテナント設定があります。 それは本当に場合によります。 そのため、このプラグインの正しい抽象化を形成することで、Spotifyのようにすべてを行う場合にKubernetesプラグインをリリースするだけでは済まないようにしました。

実際に

これは、Kubernetes プラグインのオープンソース化に関する 2020 年の元の RFC からのものです。 私たちは、この3つの抽象化を思いつきました。 基本的には、3つの質問に答えることができれば、これを実行することができます。 そして、クラスターに対してどのように認証するのでしょうか? ユーザーにクライアント IAM (Google アカウントなど) を使用させ、その後、クラスターにプロキシを取得し、すべてのリクエストがそのユーザーから送信されるようにしますか。 サーバー側のサービス アカウントを持つ予定ですか? すべてを読み取り専用にしておくかもしれませんが、誰もがすべてを見ることができます。 それも問題ありません。 次に、クラスタープロバイダーがあり、これは基本的にクラスターのサービスディスカバリーです。

これはBackstageに伝えていることですが、実際にクラスターと対話するためには、どのようにクラスターを見つけるのでしょうか? これは config で行うことができます。 また、AWS EKSクラスターを指すだけでも実行できます。 GCPプロジェクトに向けると、すべてのクラスタをスキャンして通信を開始します。 また、KubernetesクラスタをBackstageソフトウェアカタログに取り込み、それを情報源として使用することもできますが、これはかなりメタ的ですが、非常に興味深い方法です。

次に、サービスロケーターがあります。 これはおそらく、マルチテナンシーの設定に最も依存するものであり、基本的には、どのクラスタでサービスが実行されているかを示しています。 デフォルトでは、少量のクラスターに対しては、すべてのクラスターを見ていきます。 そして、何かを見つけたら、それを報告します。 そして、そうでないときは何も言いません。 ただし、実装を追加して、サービスのクラスターへのマッピングをサポートすることもできます。 私たちは、ソフトウェアカタログを使用してこれをかなりハンズフリーな方法で行う方法について、他にもたくさんのアイデアを持っています。

教訓

だから、これらすべてからの教訓。 その中でも特に大きいのは、ユーザーと話し、フィードバックを求めることだと思います。 私が言ったように、私のお気に入りの機能は私のアイデアではなく、実際には素晴らしかったです。 本当に素晴らしい機能でした。 毎日使っていて、とても便利です。 また、プラットフォームを製品のように扱います。 社内のツールだからといって、ただ捨てるわけではありません。 そして、あなたはこれを使うことができると言います。 ご利用いただけません。 がんばって。 実際にサポートを提供し、更新し、今後これらのツールをどのようにサポートするかについてフィードバックを得る必要があります。 また、インタラクションをインフラストラクチャ指向ではなく、サービス指向にシフトすることもお勧めします。 それは言うべきことだと思います、なぜなら、インフラストラクチャの問題に二の足を踏み入れることに興味を持っているユーザーがまだいるからです。 しかし、誰もがそうではないことを知っておかなければなりません。

もう一つは、この問題を一般的にどのように解決するかを考えることでデバッグプロセスを自動化することです。そして、それを自動化して、すべてのユーザーの問題を解決できるかもしれません。

では、疑問に思われるかもしれませんが、この新しいエラー報告UIはいつオープンソースプラグインに登場するのでしょうか? 実はもうすぐです。 私たちはそれをオープンソース化する過程にあります。 しかし、オープンソース化する前に、UIについてフィードバックしたり、提案をしたりする機会を全員に提供したかったのです。 つまり、BackstageのGitHubの問題にあることがわかります。

ご意見をお気軽にお寄せください。 そして、あなたが考えているなら、私はどのように助けることができますか? Kubernetesのセットアップに対してBackstageを統合できます。 Backstage Discordで私と話すことができます。 Backstage to Kubernetes プラグインにコントリビュートできます。 私は、すべての貢献がコードである必要はなく、あるいはコードであるべきでさえないと言いたいです。 そのため、テスト、ドキュメント、設計、製品戦略に貢献できます。 人々が貢献できるさまざまな方法があります。

最後に、Kubernetesで開発者の生産性を高めるのを手伝ってほしいとお願いします。 本当にありがとうございました。

質疑応答

ここで少し時間があります。 誰かが何か質問をしたいなら。

あなたはBackstageがどのように統合されているかについて簡単に話していますが、提供されているプロバイダーが機能しない場合、独自のプラグインなどを書くことができるプロバイダーがあると思います。 コミュニティでは、Spotifyで最初に作成したプロバイダーにプロバイダーを追加することについて、かなり活発になっていることがわかりましたか? 特に、BackstageのユーザーがRancherに対して認証を行い、Rancherのプロジェクトなどで彼らのものにアクセスできるように、特にRancherをオフの中間レイヤーとして使用している人を見かけたことはありますか? しかし、コミュニティの一部はすでにその作業の一部を行っているのではないかと思います。

ええ、それは素晴らしい質問です。 すごいポイントです。 コミュニティは活発で、さまざまなクラウドプロバイダーにさまざまな実装を提供していることがわかりましたか? 答えはイエスです、なぜなら私は実際にはGoogleのものだけを実装したのは、AWSのもの、AKSのものを実装したくなかったからです。 それは私が毎日やっていたことではありません。 私は、他の誰かにそれに貢献する機会を与えたかったのです。 そして、はい、すぐに、コミュニティはすでにEKS、ベアメタル、AKSの実装を提供しています。 そして、Rancherもそこにいると思います。 コンポーネントをRancherダッシュボードに直接リンクするための貢献は間違いなくあると思います。 私自身はRancherを使ったことはありませんが、間違いなくあると思います。 涼しい。

また、Kubernetesプラグインと呼んでいるものを少しダブルクリックしていただけますか? しかし、それをダブルクリックできますか? つまり、これはKubernetesクラスタにデプロイするエージェントのようなもので、その後、独立したソフトウェアの一部になるのでしょうか? しかし、それはあなたのKubernetesクラスターに埋め込まれているように見えます。 それについてもう少しお話しいただけますか。

ええ、それは素晴らしい質問です。 したがって、実際にはKubernetesクラスターにインストールするものではありません。 BackstageへのKubernetesプラグインは、いくつかの異なるコンポーネントで構成されています。 フロントエンドコンポーネントがあり、プロキシのように機能するバックエンドもあります。 これらのさまざまなKubernetesクラスターを検出します。 これは、これらのクラスターに対して使用するように指定した認証を、それをクラスターに実際に送信する方法にマップします。 そして、基本的には、これらのKubernetesクラスターと通信するための多くの面倒な作業を行うのはプロキシです。

しかし、私が言ったように、これを機能させるために、実際にはKubernetesクラスターに何もインストールする必要はありません。 必要な作業は、リソースに関連する Backstage コンポーネントにタグを付けて、見つけやすくすることだけです。 それを行うには、複数の異なる方法があります。 また、ドキュメントには、その方法とデバッグ方法について多くの情報があります。

さて、それをプラグインと呼ぶとき、そのプラグインはKubernetesプラグインではありません。 ええ、その通りです。 つまり、これはBackstage用のBackstage Kubernetesプラグインであり、Kubernetesではありません。 素晴らしい。 ありがとうございました。

さらに詳しく

• Docker Newsletter を購読してください。
• Docker デスクトップの最新リリースを入手します。
• 次のものに投票してください! 公開ロードマップをご覧ください。
• 質問がありますか? Docker コミュニティがお手伝いします。
• ドッカーは初めてですか? 始めましょう。