なぜ k8s はクラウド時代のオペレーティング システムと呼ばれるのでしょうか?

[[420872]]

過去 2 年間で、Kubernetes は Swarm と Mesos を打ち負かし、コンテナ オーケストレーションの事実上の標準になりつつあります。 BAT、Didi、JD.com、Toutiao などの大手企業は、コンテナと K8S プロジェクトを技術的な重点分野とすべく競争しています。

Kubernetes が数あるコンテナ プラットフォームの中で際立っている理由は、Kubernetes のインターフェースとコンセプト設計が、運用や保守の観点ではなく、アプリケーションの観点に完全に基づいていることです。

Kubernetes を従来の運用・保守担当者の視点から見ると、奇妙な場所だと思うでしょう。コンテナを作成する前に、読むべき概念やドキュメントが多数あります。オーケストレーション ファイルも複雑で、コンポーネントも多数あるため、多くの人がオーケストレーションを敬遠しています。

ただし、開発者の観点から、特にマイクロサービス アプリケーションのアーキテクチャの観点から Kubernetes を見ると、Kubernetes がマイクロサービスの運用ライフサイクルとそれに対応するリソース管理に対して非常に優れた抽象化を提供していることがわかります。

図に示すように、リソースの作成とネットワーク アクセスの確保のみを必要とする従来のアプリケーションを仮想マシンで実行する方法とは異なり、マイクロサービスの操作には、左側の一連のツール チェーンの完了が必要です。

これらのツール チェーンを使用する理由と方法については、他の 2 つの記事「ビジネス中心のクラウド ネイティブ システムの構築」と「1 から 2,000 のマイクロサービス: 史上最も実用的な方法でクラウド ネイティブを実装するための 25 の手順」を参照してください。

Kubernetes には対応するツール チェーンがあることがわかります。

マイクロサービス設計における重要なポイントは、ステートレスとステートフルを区別することです。 K8S では、ステートレスはデプロイメントに対応し、ステートフルは StatefulSet に対応します。

デプロイメントは主にレプリカの数を通じて水平拡張の問題を解決します。

StatefulSet は、一貫したネットワーク ID、一貫したストレージ、順次アップグレード、拡張、ロールバックなどのメカニズムを通じて、ステートフル アプリケーションを保証し、独自の高可用性メカニズムを有効に活用します。ほとんどのクラスターの高可用性メカニズムは、一時的なノード障害を許容できますが、ほとんどのノードが同時に障害を起こすことは許容できないためです。さらに、高可用性メカニズムは、クラッシュ後にノードが復帰することを保証し、特定の修復メカニズムを備えていますが、どのノードがクラッシュしたかを把握する必要があります。 StatefulSet メカニズムは、コンテナ内のスクリプトにこれらの状況に対処するのに十分な情報を提供できるため、状態が発生した場合でも、できるだけ早く修復できます。

マイクロサービスはサービス検出なしでは実行できません。アプリケーション層でのサービス検出に SpringCloud または Dubbo を使用するだけでなく、コンテナ プラットフォーム層で Service を使用して、負荷分散、自己修復、自動関連付けを実現します。

サービスオーケストレーション。 K8S はオーケストレーションの標準です。 yml ファイルは管理のためにコード リポジトリに配置することができ、デプロイメント コピーの数によって柔軟なスケーリングを実現できます。

構成センターでは、K8S は configMap を提供しており、コンテナの起動時に環境変数またはボリュームに構成を挿入できます。ただし、唯一の欠点は、環境変数に挿入された構成を動的に変更できないことです。幸いなことに、ボリューム内の構成は動的に変更できます。コンテナ内のプロセスにリロード メカニズムがある限り、構成を動的に分散できます。

統合ログ センター、監視センター、および APM では、ログとインジケーターを収集するために、ノードにエージェントを展開する必要があることがよくあります。もちろん、各ノードにはそれがあります。 daemonset の設計により、実装が容易になります。

Kubernetes 自体は、サービス ガバナンスに関しては比較的弱いです。サービス メッシュは、より洗練されたサービス ガバナンスを実現し、サーキット ブレーキング、ルーティング、ダウングレードなどの戦略を実装できます。サービス メッシュは、サービス トラフィックをインターセプトしてガバナンスを実行するために、サイドカーを通じて実装されることがよくあります。これもPodのコンセプトによるものです。 Pod には複数のコンテナを含めることができます。元の設計に Pod がなかった場合、コンテナを直接起動するのは非常に不便です。

そのため、コンテナ技術の習得は、多くの企業にとって採用時の重要な選択肢となっています。

過去 2 年間、友人と K8S の実装について話し合ったとき、次のような問題が繰り返し言及されました。

• コンテナ内で実行できるのはなぜ「1 つのプロセス」だけなのでしょうか?
• 以前使用していた特定の JVM パラメータがコンテナ内で機能しないのはなぜですか?
• Kubernetes はなぜ IP アドレスを修正できないのでしょうか?コンテナネットワークが接続されていない場合にデバッグするにはどうすればよいですか?
• K8S の StatefulSet と Operator の違いは何ですか? PVとPVCの使い方は？

これらの質問に対する答えや原則は複雑ではありませんが、1、2 文で明確に説明するのは困難です。コンテナ テクノロジーには、オペレーティング システム、ネットワーク、ストレージ、スケジューリング、分散原則などの知識が関係するため、まさにフルスタック テクノロジーです。

コンテナ自体に対する Linux プロセス モデルの重要性、K8S プロジェクト全体をまとめる際の「コントローラー」モードの役割など、「一部を動かすと全体に影響する」その技術システムの主要なスレッドは、Docker や Kubernetes の公式ドキュメントでは詳しく紹介されていませんが、これらこそがコンテナ技術システムを習得するための本質なのです。