Kubernetes ソースコード分析: リソースと API

この記事は、Kubernetes の基本原理をより深く理解するために、学習目的で Kubernetes ソースコードを分析する一連の記事です。

この記事では、マスターブランチ (https://github.com/kubernetes/kubernetes) を使用して、主に kubernates の関連コンポーネントを紹介します。ご興味があれば、ネットワークシリーズや展開シリーズも参考にしてください。

ご存知のとおり、Kubernetes は API ベースのインフラストラクチャです。 Kubernetes のすべての概念は、さまざまなリソースに抽象化されています。私たちがよく知っていてよく使用するデプロイメント リソース、サービス リソース、configmap リソース、statefulset リソース、サービス アカウント リソースなど、さまざまなリソースにはさまざまな機能があります。 Kubernetes の世界では、さまざまなリソースに対するすべての操作は API に基づいて完了します。 Kubernetes は、リソースに対する基本的な操作を完了するための一連の RESTfull API を提供します。

リソースの分割には基本的に 2 つの次元があります。1 つは名前空間に基づき、もう 1 つはコア リソースであるかどうかに基づきます。まず、名前空間に基づくディメンションを見てみましょう。

• リソース インスタンスが名前空間で定義されている場合、つまり、名前空間レベルに属している場合、このリソースは、共通デプロイメント、サービス、ポッドなど、現在の名前空間に基づくリソース オブジェクト インスタンスと見なすことができます。
• リソース インスタンスが Kubernetes クラスター全体で定義されている場合、つまりクラスター レベルに属している場合、このリソースは、共通ノード、クラスター ロール、クラスター ロール バインディング、永続ボリュームなどの非名前空間リソース オブジェクト インスタンスと見なすことができます。

次に、そのリソースがコアリソースであるかどうかという観点から、コアリソースと非コアリソースに分けることができます。

• 共通のコア リソースには、pod、podtemplate、service、endpoint、configmap などがあります。これらのリソースは、Kubernetes の最も基本的な機能を提供します。たとえば、ポッドはコンピューティング機能を提供し、サービスとエンドポイントはネットワークとアクセス機能を提供し、構成マップは構成機能を提供します。
• デプロイメント、ステートフルセット、デーモンセットなどの非コア リソースは、より高度な機能を提供します。コア以外のリソースの場合、Kubernetes はグループとバージョンに基づく管理概念を提供し、異なるリソースを同じグループにグループ化します。同じグループ内では、同じリソースに異なるバージョンが存在します。このリソースの構成と構造は、Kubernetes 機能の進化と変更、つまり、さまざまなリソース バージョンを通じてリソース機能を進化および強化するのに非常に役立ちます。

Kubernetes は標準の RESTfull API を提供するため、API の観点から見ると、上記のさまざまなディメンションに基づくさまざまなリソースの操作 API テンプレートは次のようになります。

• Item1 と Item2 は、コア リソースの操作定義形式です。どちらも URI パス プレフィックスとして /api を使用します。コア リソースにはグループの概念はありませんが、バージョンの概念があるため、バージョン パス変数 ${version} があります。
• 項目 1 は名前空間に基づくコア リソースに対する操作であるため、定義には名前空間パス変数 ${namespace-name} が含まれます。
• Item2 は名前空間ベースではないコア リソースに対する操作であるため、定義には名前空間パス変数がありません。
• 項目 3 と項目 4 は、URI パス プレフィックスとして /apis を持つ、コア以外のリソースの操作定義です。
• iems3 は、名前空間に基づくコア以外のリソースの操作定義であるため、アクセス パスには、グループ、バージョン、および名前空間のパス変数定義 (つまり、${group-name}、${version}、および ${namespace-name}) が含まれます。
• Items4 はクラスター全体のコア以外のリソースに基づく操作であるため、定義にはグループ パス変数とバージョン パス変数 ${group-name} と ${version} が含まれますが、名前空間パス変数は含まれません。

さらに、Kubernetes リソースは通常、RESTfull API に直接基づいてではなく、YAML ファイルに基づいて操作します (結局のところ、YAML ファイルは人間よりもユーザーフレンドリーです)。ただし、YAML ファイルの背後では、RESTfull API に変換されます。一般的に、YAML ファイルの形式は次のとおりです。

一般的に、リソースの典型的な YAML ファイルは、タイプ メタ、オブジェクト メタ、および仕様の 3 つの部分に分かれています。

• タイプ メタは通常、リソースのグループ バージョンと種類情報を定義します。これは、API アクセス パスで定義された ${group-name}、${version}、${resource-kind} などのパス変数に直接対応します。
• オブジェクト メタは通常、リソース名、それが属する名前空間、ラベルなどのメタデータ情報を定義します。これらは、API アクセス パス内の ${namespace-name} や ${resource-name} などのパス変数に直接対応します。
• 仕様は一般に、リソースの特定のプロパティと特性を定義します (リソース仕様が異なれば必ず異なります)。また、リクエスト本文の形式で API に対応します。

とりあえずここで止めておきます。次回は、引き続き、リソース内の型メタやオブジェクトメタなどの重要な情報の定義をソースコードの観点から整理していきます。

この記事はWeChatの公開アカウント「TA码字」から転載したもので、以下のQRコードからフォローできます。この記事を転載する場合はTAの公式アカウントまでご連絡ください。