翻訳:コア原則分析、何を学びましたか?

1. 背景

分散アーキテクチャでは、サービスの数とシステム区分の両方の観点から、管理する必要があるサービスが多数あります。

サービス機能の観点から見ると、階層的な管理と制御を実装できますが、かなりの数のサービス層がほとんど更新されないため、認識が明確ではありません。

私が現在開発に携わっているシステムを例に挙げてみましょう。

K8S によって管理されるサービスは 100 近くあり、そのうちのいくつかはクラスター モードを使用します。この規模のシステムであっても、完全に手動での操作と保守に頼ることはほぼ不可能であり、自動化されたプロセスが不可欠です。

継続的インテグレーション

私は以前、このトピックに関する完全な実践的なケーススタディを書きました。Jenkins、Docker、K8S などのコンポーネントの使用に焦点を当て、ソースコードのコンパイル、パッケージ化、イメージの構築、およびデプロイメントの自動管理プロセスをまとめました。

Jenkins: ビルド、テスト、デプロイメントなどのさまざまなタスクを自動化するために使用される、非常にスケーラブルなソフトウェアです。

Docker: オープンソースのアプリケーション コンテナ エンジンとして、アプリケーションと関連する依存関係をパッケージ化してイメージ ファイルを生成できます。持続可能な配信機能を提供する標準的な運用環境です。

Kubernetes: コンテナ化されたアプリケーションの展開、スケーリング、管理を自動化するために使用されるオープンソースのコンテナ オーケストレーション エンジン。

3. K8Sアーキテクチャ

1. コアコンポーネント

コントロールプレーンコンポーネント: コントロールプレーンコンポーネント

リソースのスケジュール設定、検出、イベント応答など、クラスター内の任意のノードで実行できるクラスターに関するグローバルな決定を行います。

• API: K8S API を開き、コンポーネントはコントロール プレーンのフロント エンドに相当する API を介して相互に対話します。
• ControllerManager: 論理的には別のプロセスであるコントローラー プロセスを実行します。
• スケジューラ: 実行中のノードが指定されていない新しく作成されたポッドを監視し、ポッドの実行中のノードを選択します。
• etcd: 一貫性と高可用性を兼ね備えたキーバリューデータベース。K8S データを格納するためのバックエンドライブラリとして使用されます。

ノード: ノードコンポーネント

このコンポーネントは各ノードで実行され、実行中の Pod を維持し、Kubernetes オペレーティング環境を提供する役割を担います。

• Kubelet: コンテナが Pod 内で実行されるように各ノードで実行されるエージェント。
• kube-proxy: 各ノード上で実行され、ノード上のネットワーク ルールを管理するネットワーク プロキシ。

コンテナ ランタイム: コンテナ ランタイム

コンテナ ソフトウェアの実行を担当し、Docker、containerd、CRI-O、Kubernetes-CRI を実装するコンテナ ランタイム環境インターフェースなどの複数のコンテナ ランタイム環境をサポートします。

2. 階層構造

全体的な機能の観点から見ると、K8S クラスターはユーザー、コントロール プレーン、ノードの 3 つのモジュールに分けられます。

ユーザー側: CLI と UI の両方がコントロール パネルの API サーバーと対話し、API サーバーが他のコンポーネントと対話して、最終的に対応する操作コマンドを実行します。

コントロール プレーン: 以前はマスターとも呼ばれていましたが、コア コンポーネントには API サーバー、コントローラー、スケジューラー、etcd が含まれており、主にクラスター全体のスケジュール設定とグローバルな決定を行うために使用されます。

ノード: ワークロードは、ノード上で実行されているポッドにコンテナを配置することによって実行されます。簡単に言えば、ワークロードとはさまざまなアプリケーションです。ノード上のコア コンポーネントには、Pod、kubelet、Container-Runtime、kube-proxy などがあります。

3. コアコンピテンシー

R&D の観点から見ると、K8S は非常に強力なアプリケーション サービス管理機能を提供します。

3.1 検出とロード

サービスは、1 つまたは複数の Pod 上で実行されているネットワーク アプリケーションを、通常はラベルを使用してリソース オブジェクトをフィルター処理し、ネットワーク サービス メソッドとして公開できます。

3.2 スケジュール

スケジューラは監視メカニズムを使用して、まだノードにスケジュールされていないクラスター内の新しく作成されたポッドを検出します。 Pod 内のコンテナと Pod 自体のリソース要件は異なる場合があるため、スケジューラは Pod を適切なノードに配置します。

3.3 自動スケーリング

K8S は、CPU 使用率、応答時間、メモリ使用率などの指標を通じてワークロードのリソース要件を確認し、スケーリングが必要かどうかを判断できます。垂直方向の次元ではリソース割り当てが増え、水平方向の次元ではクラスターの展開が増えます。

K8S は自動的にスケーリングおよび修復できます。ノードまたはアプリケーション サービスに障害が発生すると、それが検出され、ノードが移行または再起動される可能性があります。

IV.応用事例

1. サービスの展開

これまでの実践例では、デプロイメント アクションは CLI コマンド ラインとスクリプト ファイルを使用して完了していました。プロセス全体には、クラスターの複数のコンポーネント間のコラボレーション、複数の通信、およびスケジュール設定が含まれていました。

 kubectl create -f pod.yaml

2. 対話プロセス

[1] CLIコマンドラインとUIインターフェースはどちらも、前述のPodデプロイメント操作など、APIサーバーインターフェースを介してクラスターの内部コンポーネントと対話します。

[2] リクエストを受信した後、APIサーバーはシリアル化された状態オブジェクトをetcdに書き込み、ストレージ操作を完了します。

【3】スケジューラはウォッチメカニズムを使用して、クラスター内でまだノードにスケジュールされていない新しく作成されたポッドを検出します。

[4] クラスター内のポッドのスケジュール可能なノードをすべて検索し、これらのスケジュール可能なノードにスコアを付け、スコアが最も高いノードを選択してポッドを実行し、スケジューラはAPIサーバーにスケジュールの決定を通知します。

【5】APIサーバーは情報の保存を完了すると、対応するノードのKubeletに通知します。

【6】Kubelet は PodSpecs に基づいて動作し、これらの PodSpecs に記述されたコンテナが実行され、正常であることを保証します。各 PodSpec は、Pod を記述する YAML または JSON オブジェクトです。

【7】Podは、Kubernetesで作成および管理できる、1つ以上のコンテナを含む、展開可能な最小のコンピューティングユニットです。

5. 参照ソースコード

文档仓库： https://gitee.com/cicadasmile/butte-java-note脚本仓库： https://gitee.com/cicadasmile/butte-auto-parent