Kubernetes オブジェクト モデルを説明する記事

Kubernetes のオブジェクト モデル (以下、K8s と呼びます) は、K8s のもう一つの独創的な設計です。 K8s によって確立されたコンテナ化されたエコシステムは複雑で変更可能であり、オブジェクト モデルは一連のリソース エンティティを K8s で認識できるオブジェクトに抽象化することがわかっています。 K8s の設計コンセプトをより包括的に理解できるように、この記事では K8s のオブジェクト モデルを整理します。記事の最後には、面接でよく聞かれる質問の要約が追加されています。章の内容は次のように分布しています。

• K8s オブジェクト モデルの概要 - オブジェクト モデルを理解する必要がある理由
• K8s の一般的なオブジェクト モデルの紹介 - どのオブジェクト モデルを使用できますか
• K8sオブジェクトモデルの構成とYAML作成方法 - オブジェクトの使い方
• 要約する

K8s オブジェクト モデルの概要 - オブジェクト モデルを理解する必要がある理由

この質問について考える必要はあるでしょうか?存在は合理的です。まず、それがなぜ存在するのかを見てみましょう。

公式ドキュメントでは、K8s のオブジェクト モデルは次のように定義されています。

「Kubernetes オブジェクトは、Kubernetes システム内の永続的なエンティティです。Kubernetes はこれらのエンティティを使用して、クラスター全体の状態を表します。特に、次の情報を記述します。

• どのコンテナ化されたアプリケーションが実行されているか（そしてどのノードで実行されているか）
• アプリケーションで使用できるリソース
• 再起動戦略、アップグレード戦略、フォールト トレランス戦略など、アプリケーション実行時のパフォーマンスに関する戦略

つまり、オブジェクト モデルには 2 つの主な目標があります。

1. K8s クラスターの提供

オブジェクト モデルの機能の 1 つは、K8s クラスターのステータス、エンティティ、およびエンティティ間の関係を抽象的に記述することです。このカテゴリの代表的なものはラベルであり、クラスター オブジェクト間に柔軟で疎結合された多次元関係を確立します。ラベル セレクターを使用してクエリとフィルターを実行し、オブジェクト間の関係を確立できます。

2. ユーザーにサービスを提供します。

K8s は、ユーザーが独自のアプリケーションをクラスターにデプロイしやすくするために、さまざまな抽象オブジェクトを提供します。これらの抽象オブジェクトは、ユーザーを複雑な基礎ロジックから保護し、ユーザーがオブジェクトの使用方法に集中できるようにします。このタイプの例は、Pod、Node、Deployment など多数あります。たとえば、8s クラスターにアプリケーションをデプロイする場合、まずアプリケーションを Pod などの K8s で管理できるエンティティ オブジェクトに変換する必要があります。複数のレプリカを持つアプリケーションの場合、デプロイメントなどの統合管理を考慮する必要があります。さらに、レプリカ間の負荷分散とサービス検出を考慮すると、Service を使用して実装することを検討できます。これにより、ユーザーは内部実装に注意を払う必要がなくなり、独自のアプリケーションに集中できるようになります。

K8s 共通オブジェクトモデル - どのオブジェクトモデルを使用できますか

K8s オブジェクト モデルは非常に高く評価されているので、本当に優れているかどうか見てみましょう。 K8s の一般的なオブジェクトを見てみましょう。

K8s 内の各オブジェクトの位置をより鮮明に紹介する別の図を以下に示します。

ワークロード クラス オブジェクト

ポッド

場所: 写真のポッドでマークされた場所にあります

説明: Pod は、クラスター内で作成およびデプロイできる Kubernetes オブジェクトの最小かつ最も単純な単位です。これは、密に結合されリソースを共有する単一のコンテナーまたはコンテナーの小さなコレクションを表します。

抽象化とカプセル化: Pod は、アプリケーション コンテナー、ストレージ リソース、独立したネットワーク IP、およびコンテナー操作のポリシー オプションをカプセル化します。現在、Kubernetes Pod で最も一般的に使用されているコンテナ ランタイムは Docker であるため、この記事で説明するコンテナはすべて Docker コンテナです。現在、Kubernetes Pod で最も一般的に使用されているコンテナ ランタイムは Docker であるため、この記事で言及されているコンテナは Docker コンテナを指します。

K8s では、各ポッドに Pause コンテナが事前構成されており、その名前空間、IPC リソース、ネットワーク、およびストレージ リソースはポッド内の他のコンテナによって共有されます。 Pod 内のすべてのコンテナは密接に連携し、全体として管理、スケジュール、実行されます。

コントローラー

位置: 図のマスターのコントローラー マネージャーの位置に存在します。

注: コントローラー マネージャーはクラスター内の管理および制御センターであり、クラスター内のノード、ポッド、サービス エンドポイント、名前空間、サービス アカウント、およびリソース クォータの管理を担当します。彼らの責任は、クラスター内のさまざまなリソースのステータスがユーザー定義 (yaml) ステータスと一致していることを確認することです。各コントローラは、API サーバーが提供するインターフェースを通じて、クラスター全体の各リソース オブジェクトの現在のステータスをリアルタイムで監視します。さまざまな障害が発生し、システムの状態が変化すると、システムの状態を「期待される状態」に修復しようとします。たとえば、ノードが予期せずダウンした場合、ノード コントローラーはすぐにそれを検出して自動修復プロセスを実行し、ノードが常に期待どおりの動作状態にあることを確認します。次の図は、コントローラーの凡例の一部を示しています。

抽象化とカプセル化: 論理的には、各コントローラーは、ユーザーのリソース オブジェクトの管理ロジックをカプセル化する個別のプロセスです。ユーザーがリソース オブジェクトを作成すると、コントローラーはクラスター全体の各リソース オブジェクトの現在のステータスをリアルタイムで監視し、リソース オブジェクトが常に期待どおりの動作状態にあることを自動的に確認できるように支援します。また。 K8s はユーザー定義の拡張コントローラーをサポートします。

デプロイメント/ステートフルセット/デーモンセット/ジョブ

場所：Deploymentは図の④の位置、Statefulsetは図の⑤の位置、Daemonset/Jobは図の緑色のPodの位置にあります。

注: このタイプのリソース オブジェクトは、Pod の宣言的な定義メソッドを提供しますが、同時にさまざまな使用シナリオを処理する役割も担います。 Deployment は、以前の ReplicationController を置き換える Pod と ReplicaSet の宣言型定義メソッドを提供し、主に Kubernetes でステートレス サービスを処理するために使用されるリソースのアプリケーション管理を容易にします。一般的なアプリケーション シナリオは次のとおりです。

• ポッドとレプリカセットを作成するためのデプロイメントを定義する
• ローリングアップグレードとロールバック
• スケールアップとスケールダウン
• デプロイメントの一時停止と再開

StatefulSet は、ステートフル サービスをサポートするために使用されるリソースです。代表的なアプリケーションシナリオは Zookeeper と Kafka です。展開とスケールの順序を確保できます。適用シナリオは次のとおりです。

• 安定した永続ストレージ。
• 安定したネットワークサイン。
• 秩序ある展開と拡張。
• 秩序ある縮小と削除。

DaemonSet は前の 2 つの方法とは異なります。クラスター内のすべてのノードに同時に基本サービスとデーモンを提供するシナリオを解決します。 DaemonSet は、クラスター内のすべてのノードまたは一部のノードが同じ Pod コピーを実行できることを保証できます。たとえば、kube-router と flannel は DaemonSet とともにデプロイされます。

ジョブはバッチ処理タスク、つまり 1 回だけ実行されるタスクを担当します。バッチ処理タスクの 1 つ以上のポッドが正常に完了することを保証します。データ収集などのシナリオに適用できます。一部のユーザーは、crontab と同様に、スケジュールに従ってタスクを自動的に実行したい場合があります。心配しないでください。K8s はスケジュールされたタスク用の cronjob リソース オブジェクトも提供しており、crontab と同じスケジュール機能をサポートできます。

検出と負荷分散クラスオブジェクト

サービス/エンドポイント/イングレス

場所：サービスは図の①と②の位置にあります。進入地点は図の③の地点です。

説明: Kubernetes Service は、Pod の論理グループを抽象化したものであり、通常マイクロサービスと呼ばれる Pod にアクセスするための戦略を提供します。

K8s はサービスの概念を抽象化し、バックエンドにバインドされたポッド サービスに対してサービス検出および負荷分散機能を提供します。同じ機能を持つコンテナ アプリケーションのグループに統一されたエントリ アドレスを提供し、バックエンドの各コンテナ アプリケーションのコントローラーへのリクエストの負荷を分散します。このポッドのグループには、通常はラベル セレクターを介してサービスからアクセスできます。

エンドポイントは、etcd に保存される K8s クラスター内のリソース オブジェクトであり、サービスに対応するすべてのポッドのアクセス アドレスを記録するために使用されます。サービスはセレクターを構成し、エンドポイント コントローラーは対応するエンドポイント オブジェクトを自動的に作成します。それ以外の場合、エンドポイント オブジェクトは生成されません。

Ingress も Service に関連するリソース オブジェクトです。これは、クラスター サービスに到達するための受信接続を許可する一連のルールです。外部からアクセス可能な URL、負荷分散、SSL、名前ベースの仮想ホストなどを使用した Ingress 構成を提供できます。ユーザーは、Ingress リソースを API サーバーに POST することで Ingress を要求します。面倒なので、インターネットからの画像を使用して、3 つの関係を説明したいと思います (画像内の Pod は EndPoint として理解できます)。

構成とストレージクラスオブジェクト

Configmap/シークレット/ボリューム/永続ボリューム

場所: Configmap と Secret は、図の Configmap と Secret でマークされた場所にあります。 PersistentVolume は、図の PV1、PV2、PV3 にあります。

注: K8s では、ボリュームはコンテナのストレージ問題を解決するために定義されており、Volume と呼ばれます。コンテナ内のファイルの一時的な問題を解決するだけでなく、同じポッド内の複数のコンテナがファイルを共有できるようにします。ここで言及されているボリュームは、実際にはより具体的な概念です。これは永続的なストレージではなく、Pod が削除されると削除される可能性があります。一般的なボリュームには、EmptyDir、HostPath、ConfigMap、Secret などがあります。これらのボリュームのライフサイクルは、それが属するポッドと同じです。 Volume に対応するのは永続ボリュームの概念、つまり PersistentVolume です。これは永続的なストレージ ソリューションを提供し、Pod とボリュームの宣言ライフサイクルを分離します。

抽象化とカプセル化: Volume と PersistentVolume は、クラスター内のコンテナ ストレージの基礎となるロジックからユーザーを保護します。クラスター内の各ボリュームは、ポッドによって使用されるときに、マウントとアンマウントの 2 つの操作が実行されます。 Configmap や Secret など、一部のものもアタッチおよびデタッチ操作の対象となります。ただし、ユーザーはこれらの操作を気にする必要はありません。 yaml でデータ ソースとマウント パスを設定するだけで済みます。同時に、ストレージオブジェクトの管理もオブジェクトによって自動的に実行されます。ストレージ リソースを作成および削除するには、ユーザーは単純な作成および削除操作を実行するだけで済みます。実際、ストレージ リソースの割り当てと回復も K8s によって自動的に完了します。

クラスタークラスオブジェクト

ノード/名前空間/ロール/クラスターロール

場所: ノードは図の黄色のブロック内に位置し、ノードの場所がマークされています。名前空間は、図の「名前空間」というラベルの付いたボックス内にあります。 Role は図のシールドの位置にあり、ClusterRole は図のシールドの完全なセットです。

注: クラスター オブジェクトは、K8s 内のいくつかのグローバル リソース オブジェクトを表します。言うまでもなく、Node は K8s の存在の物理的な基盤です。名前空間はプログラミング言語のスコープに似ています。 K8s は、名前空間を通じて物理クラスターを複数の仮想クラスターに分割することをサポートしています。これらの仮想クラスターは個別の名前空間を使用します。名前空間間のコンテナーは不透明であるため、ユーザーはよりきめ細かい権限制御を簡単に実行できます。

Role と ClusterRole は、ユーザーにクラスター内の権限管理を提供する役割を担います。 Role オブジェクトは、単一の名前空間内のリソースへのアクセス権限を付与するために使用されますが、Kubernetes クラスター全体で有効なロールは ClusterRole オブジェクトを通じて実装されます。使用時には、次のリソースに権限を付与できます。

• クラスター全体のリソース（ノードなど）
• 非リソースエンドポイント
• 名前空間をまたぐリソース（名前空間をまたぐポッドなど）

抽象化とカプセル化: クラスター タイプのオブジェクトは、ユーザーをクラスター管理ロジックから保護します。クラスター全体がフラットな構造に抽象化されます。クラスターはチェス盤に例えることができます。まず、ポッド (チェスの駒) がそれぞれの領域 (名前空間) にデプロイされます。一部のポッド（チェスの駒）はそれぞれのエリア内でのみ操作できますが、一部のポッド（チェスの駒）はエリアをまたいで操作できます。ユーザーはこれらのポッド（チェスの駒）の使い方を学ぶだけでよく、具体的なルールと実行ロジックは K8s によって設定されます。

K8sオブジェクトモデルの構成とYAML作成方法 - オブジェクトの使い方

K8s では、ユーザーに提供されるオブジェクトを整理および作成する方法は、yaml ファイルを使用することです。記述されたyamlファイルの場合、以下の手順でオブジェクトリソースを作成できます。

 kubectl作成/apply -f ***.yaml

次のコマンドを使用すると、Pod オブジェクトがどのように構成されているかを確認できます。

 kubectl describe pod *** -n <名前空間>

次に、このセクションでは、オブジェクト YAML の各フィールドの詳細な分析と、各リソースの作成方法について説明します。まず、コンセプトを確立する必要があります。 YAML ファイルはオブジェクトの説明を視覚化したものです。つまり、オブジェクトを記述する概念が kv フィールドとして YAML にマッピングされます。 K8s オブジェクトを記述する場合、オブジェクトの構成を管理する 2 つの必須のネストされたフィールド (spec と status) があります。 spec は必須であり、オブジェクトの望ましい状態、つまりオブジェクトに持たせたい特性を記述します。 status は、K8s システムによって提供および更新されるオブジェクトの実際の状態を表します。いつでも、K8s 管理モジュールは常にアクティブであり、オブジェクトの実際の状態を期待される状態と一致するように管理します。

例えば：

デプロイメント オブジェクトの仕様とステータスの説明構造を確認できます。

YAML の場合、オブジェクトごとに YAML 設定の内容は異なりますが、以下の項目は必須です。

 apiVersion # このオブジェクトを作成するために使用された Kubernetes API のバージョン
 
 kind # 作成したいオブジェクトのタイプ
 
メタデータ #名前文字列、UID、オプションの名前空間など、オブジェクトを一意に識別するデータ

https://kubernetes.io/docs/api/)。以下に、各リソースを作成する方法の例を示します。

ワークロード クラス オブジェクト

典型的な busybox 作成テンプレートのケースを使用して、Pod リソースについて簡単に説明します。

このテンプレートは、まず YAML の 3 つの要素 (apiVersion、kind、metadata) を指定します。必要なイメージ busybox は Pod 固有の仕様で指定され、イメージのプルとコンテナの再起動の戦略が簡単に設定されます。使用中に、簡単な設定を行うと、K8s がイメージのプルやコンテナの再起動によって発生する異常な管理問題を自動的に解決し、前述のオブジェクトの実際の状態が期待する状態と一致することがわかります。

以下に、古典的な nginx テンプレートの使用例をもう 1 つ示します。

デプロイメントはポッドのセットを記述するために使用されるため、ここでレプリカの数を指定し、セレクターを設定してポッドとデプロイメントの関係を定義します。

検出と負荷分散クラスオブジェクト

このタイプのリソースは、ネットワーク特性を持つオブジェクトを表します。その中で代表的なオブジェクトはサービスです。ここでは、それを説明するために、Service の典型的な使用例も示します。

Service オブジェクトの YAML テンプレートでは、1 つの Pod または Pod のグループの通信ポートと通信プロトコルを指定し、サービスの公開方法を定義できます。

構成とストレージクラスオブジェクト

Configmap は非永続ストレージの代表例です。例を挙げて説明しましょう:

Configmap のデプロイメントユースケースには仕様フィールドがなく、データの内容を直接指定します。上記の YAML を使用した作成に加えて、ConfigMap または Secret をボリュームにパッケージ化してディレクトリにマウントすると、実際にボリュームが作成されます。これらのボリュームは Kubernetes 内のオブジェクトではありません。これらは現在の Pod にのみ存在し、Pod が削除されると削除されます。ただし、これらの一時ボリュームを削除しても、関連する ConfigMap または Secret オブジェクトは削除されないことに注意してください。

もう一度、永続ストレージの例を見てみましょう。

永続ストレージを作成するユースケースは、Pod オブジェクトの場合と多少似ています。ストレージの予想される状態を定式化する必要があります。ここでは、1Gの容量を設定し、複数のノードに読み書き可能にマウントし、nfsでマウントされたPVを使用して保存します。作成が完了したら、PVC を使用してストレージを Pod にバインドできます。

クラスタークラスオブジェクト

ほとんどの Cluster オブジェクトは Cluster リソース オブジェクトに属します。デフォルトでは、ユーザーは YAML を使用して作成する必要はありません。たとえば、コマンド kubectl create ns **** を使用して名前空間を直接作成できます。ここでは ClusterRole の YAML の例を示します。

この例では、シークレット リソース オブジェクトに対する取得、監視、および一覧表示の権限を付与する ClusterRole オブジェクトを定義します。次に、ClusterRoleBinding を使用してこれを使用します。 ClusterRoleBinding は、ロールで定義された権限をユーザーまたはユーザー グループに付与できます。 ClusterRoleBinding には、権限を付与するさまざまな形式のリソース タイプ (USER、GROUP、SERVICEACCOUNT など) を含む一連の権限リスト (サブジェクト) が含まれています。 ClusterRoleBinding はクラスター全体の承認に適用できますが、対応する RoleBinding は名前空間内の承認に適用できます。例えば：

このユースケースでは、ClusterRole シークレットをユーザー dazhuang にバインドし、ユーザー dazhuang が myspace 内のシークレットにのみアクセスできるように許可します。

要約する

K8s のオブジェクト モデルは、K8s の非常に重要な部分であり、K8s を構築するための基盤となります。 K8s の各オブジェクトは、ユーザーを複雑な基礎詳細から保護し、クラスターの実行ステータスを継続的に取得して期待されるステータスと比較することで、オブジェクトが期待される状態で実行できることをユーザーが確認できるようにします。この記事が読者の皆さんの K8s オブジェクト モデルに対するより包括的な理解に役立つことを願っています。