Mastering Kubernetes Objects

Kubernetes クラスタのコアコンポーネントについて学習しておきます。このレッスンでは、Kubernetes オブジェクトとその連携方法について学習します。

Kubernetes オブジェクトは、Kubernetes クラスタ内に保持されるエンティティです。より正確には、これらは etcd key-value ストア内に保持されます。Kubernetes オブジェクトは、Pod、サービス、デプロイメントなど、さまざまなリソースを表すことができます。

これらのオブジェクトは YAML または JSON 形式を使用して定義され、Kubernetes コントロールプレーンの kube-apiserver コンポーネントによって公開される RESTful Kubernetes API を使用して管理することができます。つまり、API を使用してオブジェクトを作成、更新、削除、およびクエリすることができます。

以下は、Pod オブジェクトに関する情報をフェッチする要求の例です。

1
GET https://<kubernetes-cluster>.com/api/v1/namespaces/<namespace>/pods/<pod-name>

各 Kubernetes オブジェクトは、YAML または JSON 形式の設定ファイルで定義されます。設定ファイルには、宣言的な方法でオブジェクトの指定が含まれています。これにより、オブジェクトの目的のステータスを定義することができます。その後、Kubernetes により、オブジェクトの実際のステータスが目的のステータスと一致するかどうかが永続的にチェックされます。そうでない場合、Kubernetes は実際のステータスを目的のステータスと一致させようとします。これは照合ループと呼ばれます。

単純な Kubernetes Pod オブジェクトは、以下のように宣言されます。

12345678
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
    containers:
    - name: my-container
      image: nginx:1.21.3

Pod オブジェクトのさまざまな部分を分割します。

• apiVersion フィールドでは、オブジェクトの定義に使用される Kubernetes API のバージョンが指定されます。各オブジェクトには、異なる API バージョンを含めることができます。
• kind フィールドでは、Kubernetes オブジェクトのタイプが指定されます。
• メタデータフィールドには、オブジェクトのメタデータが含まれます。
• spec 項目には、オブジェクトの指定が含まれます。spec 項目は、オブジェクトタイプごとに異なります。たとえば、Pod オブジェクトの spec フィールドには、Pod の一部であるコンテナの仕様が含まれています。

これらは、Kubernetes オブジェクトの必須フィールドです。ただし、オブジェクトに項目を追加することもできます。

上記のオブジェクトにより、名前が my-pod の Pod が作成されます。Pod には、名前が my-container の単一のコンテナが含まれています。コンテナでは、バージョン 1.21.3 の nginx イメージが使用されます。

ほとんどすべての Kubernetes クラスタにあるコアオブジェクトがいくつかあります。最も重要な Kubernetes オブジェクトの概要を確認します。

ポッド

以前に説明したとおり、Pod は Kubernetes の最小のデプロイ可能ユニットであり、1 つ以上のコンテナを囲む細いラッパです。ポッドは常にノードにスケジュールされます。Pod は、Kubernetes API を使用して作成、更新、および削除できます。

1 つの Pod で複数のコンテナを実行することは、アンチパターンです。主な理由は、コンテナをスケーリングおよび更新しやすくするためです。また、コンテナは密結合されているため、管理も困難です。例として、Web サーバとデータベースなどの 2 つのコンテナを実行する Pod があります。Web サーバをスケーリングする場合は、必要でない場合でも、データベースのスケーリングも行う必要があります。

ただし、1 つの Pod で複数のコンテナを実行することに意味がある一般的なシナリオがいくつかあります。たとえば、メインコンテナに追加機能 (ロギング、監視、プロキシトラフィックなど) を提供するサイドカーコンテナを実行する場合。Istio によるサービスメッシュについては、後でサイドカーインジェクションについて詳しく説明します。

サービス

サービスでは、一連の Pod がグループ化され、それらにアクセスするための安定したエントリポイントが提供されます。以下の図の Service では、複数の Pod にトラフィックを分散する負荷分散機能も提供されています。ポッドはラベルとセレクタを使用してグループ化され、後で説明します。

これは、クラスタ内の複数の Pod にわたって実行されるようにアプリケーションをスケーリングする場合に特に役立ちます。これは、サービスが効果的にグループ化し、それらにアクセスするための安定したエントリポイントを提供できるためです。

ヒント

Kubernetes サービスは、Kubernetes クラスタ内で一貫した DNS 名および IP を持つネットワークサービスとしてアプリケーション Pod を公開します。内部 Kubernetes サービスをインターネットに公開するには、APIRule カスタムリソースを作成する必要があります。このアプローチは、Cloud Foundry ランタイムでのルートの作成に似ています。サービスの公開の詳細については、Kubernetes でのサービスの発見の章を参照してください。

ReplicaSets

ReplicaSet は、常にクラスタ全体で実行される、特定のタイプの Pod のセットです。ReplicaSet は、必要な数の Pod が常に実行されるようにします。Pod が削除されると、ReplicaSet によって新しい Pod が作成され、置き換えられます。このチェックは、照合ループ内で実行され、目的の状態 (Pod の数) と実際の状態 (実行中の Pod の数) が比較されます。ReplicaSets は、アプリケーションの高可用性を確保し、Kubernetes の自己回復機能を使用する良い方法です。

注記

また、ReplicaSet がポッドを所有していないことも知っておくことが重要です。代わりに、必要な数のポッドが実行されていることを確認する責任があります。Pod を削除すると、ReplicaSet によって新しい Pod が作成され、置き換えられます。また、Pod を削除せずに ReplicaSet を削除することもできます。

デプロイメント

デプロイメントは、ReplicaSets の上での高レベルの抽象化です。デプロイメントを使用して、アプリケーションの目的のステータスを宣言型で定義することができます。これには、レプリカの数、コンテナイメージ、および追加設定が含まれます。デプロイメントは ReplicaSets を管理し、ReplicaSets は Pod を管理します。

デプロイメントを使用すると、アプリケーションの新しいバージョンをロールアウトできます。このようなロールアウトは、高度に制御された方法で実行されます。デプロイメントにより、古いReplicaSet の横に新しい ReplicaSet が作成されます。その後、新しい ReplicaSet が開始され、必要な数のレプリカまでスケーリングされます。新しい ReplicaSet が起動して実行されると、古い ReplicaSet のスケールダウンが開始されます。これにより、少なくとも 1 つの ReplicaSet が常に実行されます。これはローリング更新と呼ばれ、ゼロダウンタイム (ゼロダウンタイムデプロイメント) でアプリケーションの新規バージョンをロールアウトする安全な方法であるため、デプロイメントの強力な機能です。

ヒント

Kyma でデプロイメントを適用するには、コマンド kubectl apply -f deployment.yaml を使用します。このコマンドは、Cloud Foundry ランタイムのコマンド cf push に似ています。ただし、Kubernetes では、デプロイメントにアーティファクト (Docker イメージ) に関する情報が含まれている必要があります。アーティファクトの作成および保存は、Cloud Foundry ランタイムでは必要ありません。

注記

他にも多数の Kubernetes オブジェクトがあり、その一部については、このコースの後半で説明します。Kubernetes は、実際には拡張も可能です。カスタムリソース定義 (CRD) を使用して、カスタムオブジェクトを定義し、Kubernetes API を拡張することができます。

他のオブジェクトまたは CRD の詳細については、正式な Kubernetes 文書を参照してください。

各 Kubernetes オブジェクトには、キーと値のペアでラベルを付けることができます。ラベルは、オブジェクトを識別するために使用されます。たとえば、特定のアプリケーションのすべての Pod にラベル app: my-app のラベルを付けることができます。

これは、サービスが Pod をグループ化する方法の例です。サービスでは、ラベルセレクタを使用して、「サービス」に含める必要がある Pod を特定する。ラベルセレクタは、ラベルに従ってオブジェクトを選択するために使用されるクエリです。たとえば、ラベルセレクタ app: my-app では、ラベル app: my-app のすべての Pod が選択されます。

ラベルは、オブジェクト定義のメタデータセクションで定義できます。

12345678910
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
  labels:
    app: my-app
spec:
    containers:
    - name: my-container
      image: nginx

アノテーションはラベルに似ていますが、ラベルとは異なり、アノテーションはオブジェクトの識別、フィルタリング、または選択には使用されません。アノテーションは、セマンティックメタデータでオブジェクトを拡張します。通常、さまざまなツールでアノテーションが使用され、オブジェクトに関する追加の詳細が保存されます。

さまざまな Kubernetes オブジェクトとその目的を区別できるようになりました。また、それらが相互にどのように関連するか、およびそれらのラベル付けおよび名称領域でのグループ化の方法についても理解しています。