Kubernetes が優れている理由は何ですか?

[[225472]]

私が初めて Kubernetes について学び始めたとき (約 1 年半前?)、なぜ Kubernetes を気にする必要があるのか​​よくわかりませんでした。

Kubernetes をフルタイムで使用して 3 か月以上経ち、ようやく Kubernetes を使用する理由がわかってきました。 (私は Kubernetes の専門家からは程遠いですが!) この投稿が Kubernetes で何ができるのか理解する助けになれば幸いです。

「クラウド ネイティブ」、「オーケストレーション」、「コンテナ」などの Kubernetes 固有の用語を使わずに、Kubernetes に興味を持っている理由のいくつかを説明してみたいと思います :)。私の現在の仕事は Kubernetes を構成して適切に動作させることであるため、主に Kubernetes オペレーター/インフラストラクチャ エンジニアの視点からこれらの観点について説明します。

「Kubernetes を本番環境で使用すべきか?」といった質問には答えません。それは非常に複雑な問題です。 (特に「本番システム」では、使用事例に応じて要件が常に異なるためです)

Kubernetes を使用すると、新しいサーバーをセットアップせずに本番環境でコードを実行できます。

私が初めて Kubernetes に触れたのは、パートナーの Kamal との次のような会話でした。

それは次のようになります:

1. Kamal: Kubernetes を使用すると、1 つのコマンドで新しいサーバーをセットアップできます。
2. ジュリア：それはあり得ないと思うわ。
3. Kamal: このように、構成ファイルを作成して適用すると、この時点で、実稼働システムで HTTP サービスが実行されるようになります。
4. Julia: しかし、今は新しい AWS インスタンスを作成し、Puppet マニフェストを明示的に記述し、サービス検出をセットアップし、負荷分散を構成し、デプロイメント ソフトウェアを構成し、DNS が動作していることを確認し、何も問題がなければ少なくとも 4 時間は本番環境に投入する必要があります。
5. Kamal: はい、Kubernetes ではそれほど多くの作業を行う必要はなく、5 分で新しい HTTP サービスをセットアップして自動的に実行できます。クラスター内に空きリソースがある限り、問題なく動作します。
6. ジュリア: これは罠に違いない。

ここで注意すべき点があります。本番環境の Kubernetes クラスターをセットアップするのは、実際には簡単ではありません (私の経験では)。 (始めるときに何が複雑であるかを知るには、「Kubernetes の困難な旅」を参照してください。) ただし、ここではそれについては説明しません。

Kubernetes の優れた点の 1 つは、新しく開発されたソフトウェアを本番システムに導入したい人にとって、それが簡単になる可能性があることです。これは素晴らしいことです。実際に、Kubernetes クラスターが機能するようになれば、構成ファイルだけを使用して、本番環境で HTTP サービスを文字通りセットアップできます (5 分でアプリを実行し、ロード バランサーをセットアップし、DNS 名を付与するなど)。本当に面白そうですね。

Kubernetesは、本番システムで実行されるコードの可視性と管理性を向上させます。

私の意見では、etcd を理解しなければ Kubernetes を理解することはできないでしょう。それでは、まずetcdについてお話しましょう。

私が今あなたにこう尋ねたと想像してください。「本番環境で実行しているすべてのアプリケーションについて教えてください。どのホストで実行されていますか? 正常ですか? DNS 名が割り当てられていますか?」私はそのことについて何も知りませんが、これらの質問に答えるにはおそらくさまざまな場所を調べる必要があり、それには長い時間がかかるでしょう。クエリは必要なく、API だけで十分であると確信を持って言えます。

Kubernetes では、実行中のアプリケーション (「ポッド」)、ノード、DNS 名、cron ジョブなど、クラスターのすべての状態が単一のデータベース (etcd) に保存されます。各 Kubernetes コンポーネントはステートレスであり、基本的に次のように動作します。

1. etcd から状態を読み取る (例: 「ノード 1 に割り当てられたポッドのリスト」)
2. 変更を加える（例：「ノード 1 でポッド A を実行する」）
3. etcd のステータスを更新します (例: 「ポッド A のステータスを「実行中」に設定する」)

つまり、「そのアベイラビリティーゾーンで nginx を実行しているポッドはいくつありますか?」などの質問に答えたい場合、統合 API (Kubernetes API) をクエリすることで回答できます。さらに、他のすべての Kubernetes コンポーネントでその API を実行して、同じアクセスを取得できます。

これは、Kubernetes で実行されているすべてのものを簡単に管理できることも意味します。たとえば、次のような場合:

1. デプロイメントでは、複雑なカスタム デプロイメント戦略 (1 つをデプロイして 2 分待機、5 つ以上をデプロイして 3.7 分待機、など) を実装します。
2. GitHub にブランチをプッシュするたびに新しい Web サーバーを自動的に起動します
3. 実行中のすべてのアプリケーションを監視して、メモリ使用量の制限が適切であることを確認します。

必要なのは、Kubernetes API (「コントローラー」) と通信するプログラムを作成することだけです。

Kubernetes API のもう 1 つの魅力的な点は、Kubernetes が提供する既存の機能に制限されないことです。デプロイ/作成/監視するソフトウェア用の独自のソリューションがある場合は、Kubernetes API を使用してコードを記述し、目標を達成できます。やりたいことは何でもできるようになります。

すべてのKubernetesコンポーネントがダウンしても、コードは引き続き実行されます。

Kubernetes について私が約束したことの 1 つは (さまざまなブログ投稿で :))、「Kubernetes API サーバーやその他のコンポーネントが「停止」しても、コードは実行され続けます」ということです。理論的にはクールだと思うのですが、実際にそのように機能するかどうかはわかりません。

今のところ、それは本当のようです!

実行中のいくつかの etcd を切断したところ、次のようなことが起こりました。

1. すべてのコードは実行され続けます
2. 新しいことができない (新しいコードをデプロイしたり変更をビルドしたりできず、cron ジョブが動作しなくなる)
3. 回復すると、クラスターはその間に失われたものをキャッチアップします。

これを行うと、etcd がダウンし、アプリケーションの 1 つがクラッシュしたり、その他の問題が発生したりした場合、etcd が再起動するまで回復できなくなります。

Kubernetesはバグに対して耐性があるように設計されている

他のソフトウェアと同様に、Kubernetes にもバグがあります。たとえば、これまではクラスタ制御マネージャにメモリ リークが発生し、スケジューラが頻繁にクラッシュしていました。バグは確かに悪いことですが、Kubernetes の設計により、多くのコア コンポーネントにおけるバグの影響を軽減できることがわかりました。

いずれかのコンポーネントを再起動すると、次のようになります。

1. etcdから関連するすべてのステータスを読み取ります
2. これらの状態（ポッドのスケジュール、完了したポッドのリサイクル、cronジョブのスケジュール、オンデマンドのデプロイなど）に基づいて、実行する必要があると思われることを実行します。
3. すべてのコンポーネントがメモリ内に状態を保持するわけではないため、いつでもコンポーネントを再起動することができ、さまざまなバグの影響を軽減するのに役立ちます。

たとえば、コントロール マネージャーでメモリ リークが発生している場合などです。コントロール マネージャーはステートレスなので、1 時間ごとなど定期的に再起動したり、不整合の原因となる問題が発生したと思われる場合はいつでも再起動できます。あるいは、スケジューラにバグがあり、特定のポッドを忘れてスケジュールされないことがあるかもしれません。スケジューラを 10 分ごとに再起動することで、この問題を軽減できます。 (私たちはこれをしません。バグを修正するつもりですが、あなたはそれをすることができます:))

したがって、コアコンポーネントにバグがあったとしても、Kubernetes の設計を信頼して、クラスターの状態の一貫性を確保できると感じています。そして、一般的に、ソフトウェアの品質は時間の経過とともに向上します。操作する必要がある唯一のステートフルなものは etcd です。

「状態」にこだわりすぎるつもりはありませんが、Kubernetes の素晴らしい点の 1 つは、バックアップ/復元プランを用意する必要があるのは etcd だけであるということです (ポッドに永続ボリュームを使用しない限り)。これにより、Kubernetes の操作が思ったよりも少し簡単になると思います。

Kubernetes上に新しい分散システムを実装するのは非常に簡単です

分散 cron ジョブ スケジューリング システムを実装したいとします。ゼロから始めるのは膨大な作業量になります。ただし、Kubernetes で分散 cron ジョブ スケジューリング システムを実装するのは非常に簡単です。 （それでも、分散システムなので、それほど簡単ではありません）

Kubernetes cron ジョブ コントローラーのコードを初めて読んだとき、そのシンプルさに感動しました。読んでみてください。メインロジックは約 400 行の Go コードです。読んでみてください！ => cronjob_controller.go <=

cron ジョブ コントローラが基本的に行うことは次のとおりです。

10秒ごとに:

• 既存のすべてのcronジョブを一覧表示する
• 今すぐ実行する必要があるタスクがあるかどうかを確認します
• もしそうなら、新しいジョブオブジェクトを作成してスケジュールし、他のKubernetesコントローラーを介して実際に実行します。
• 完了したジョブをクリーンアップする

上記の手順を繰り返します

Kubernetes モデルは非常に制約されています (etcd でリソース スキーマが定義されており、コントローラーがこのリソースを読み取って etcd を更新します)。この固有の制約モデルにより、Kubernetes フレームワークで独自の分散システムを開発しやすくなると思います。

Kamal は、「Kubernetes は使用できる分散システムです」ではなく、「Kubernetes は独自の分散システムを作成するための優れたプラットフォームです」と言っていましたが、これは本当に興味深いと思いました。彼は、GitHub にプッシュされたブランチごとに HTTP サーバーを実行するシステムのプロトタイプを作成しました。これには週末を費やし、約 800 行の Go コードを作成しましたが、これはすごいことだと思います。

Kubernetes を使用すると、非常に素晴らしいことが可能になります (ただし簡単ではありません)

私は「Kubernetes を使用すると、素晴らしいことが可能になります。1 つの構成ファイルで非常に多くのインフラストラクチャを実行できます。素晴らしいです」と言って始めました。これは本当です！

「Kubernetes は簡単ではない」と言われるのはなぜでしょうか? Kubernetes には多くの部分があり、高可用性の Kubernetes クラスターを正常に運用する方法を習得するには多くの作業が必要です。問題をデバッグして正しく構成するために理解する必要のある抽象化が数多く提供されていることがわかりました。私は新しいことを学ぶのが大好きなので、それが私を狂わせたり怒らせたりすることはありませんが、知っておくことは重要だと思います :)

「抽象的な概念だけに頼ることはできない」という具体的な例としては、Kubernetes ネットワークの設定にある程度自信を持てるようになるために、Linux でのネットワークの仕組みについて一生懸命に学んだことが挙げられます。これは、私がこれまでにネットワークについて学んだことよりもはるかに多くのことでした。この方法は楽しいですが、非常に時間がかかります。将来的には、Kubernetes ネットワークのセットアップの難しい/興味深い側面についてさらに詳しく書くかもしれません。

あるいは、Kubernetes CA を正常にセットアップするために、Kubernetes 用の CA をセットアップするさまざまな方法について学ぶ必要があったすべての詳細について、2000 語のブログ記事を書きました。

GKE (Google の Kubernetes サービス) などのマネージド Kubernetes システムは、多くの決定を自動で行うため、よりシンプルになると思いますが、試したことはありません。