ポッド、デプロイメント、およびレプリカセット：Kubernetesリソースの説明
Kubernetesは親しみやすいことで知られていません。Kubernetesをマスターするには、その抽象化がどのように組み合わさっているのかを理解する必要があります。Kubernetesには、アプリケーション内で使用できる数十種類のリソースタイプが付属しています。最も頻繁に使用されるリソースの役割を見てみましょう。
ポッド
Kubernetesで学ぶべき用語が一つあるとすれば、それは「Pod」です。PodはKubernetesが使用する基本的な計算単位で、実行中のコンテナをホストします。この理由から、PodをDockerコンテナのインスタンスに例えることが一般的です。
この類似性は正確ではありません。なぜなら、単一のKubernetesポッドには複数のコンテナが実行される場合があるからです。ポッドは、共有の実行コンテキストを持つコンテナの「グループ」として見る方が適切です。ポッドの環境は隔離されており、その中の個々のコンテナ環境はさらにサブ隔離されています。
ポッド内のコンテナは常に同じKubernetesノードにスケジュールされます。それらは同じ物理マシン上で実行され、ストレージとネットワークのリソースを共有できます。
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: my-container
image: my-image:latest
上記のマニフェストは、手動で単一のPodを作成します。そのPodは、コンテナを使用して実行されます。
my-image:latest画像。
Kubernetesでは通常、Podを直接管理することはありません。Podは、Deploymentなどの他のリソースを追加する結果として作成されます（以下参照）。Podは一時的な単位として扱うべきです。KubernetesはPodを管理しており、クラスターのリソースが制約されると、Podを別のノードに再スケジュールすることがあります。
レプリカセット
レプリカセット（通常は次のように書かれます）
ReplicaSets（スペースなし）はPodsの上にある別の抽象化レイヤーです。ReplicaSetsは、特定の数の同一のPodが任意の時点で実行されていることを保証します。
ReplicaSetsを使用すると、アプリケーションのために最低限のPod数を強制することができます。同時に実行されるべきPodの数を指定します。Kubernetesは、定義した最小の可用性を満たすために必要な数のPodをスケジュールします。アプリケーションの設定によっては、各Podが複数の実行中のコンテナで構成される場合があることを覚えておいてください。
ReplicaSetによってPodが作成されると、KubernetesはPodの
metadata.ownerReferencesReplicaSetのアイデンティティを含むフィールド。これにより、ReplicaSetは自分が管理するPodを確立し、最小の可用性目標が達成されたかどうかを把握できます。
レプリカセットには
replicasポッドを実行する数を定義するフィールドです。この値を変更し、更新されたReplicaSetマニフェストをクラスターに適用することで、Kubernetesは新しいレプリカ数に合わせてポッドを再スケジュールします。
この詳細は、ReplicaSets に関する重要なポイントを強調しています: Kubernetes は、実行中の Pods の数が最終的に指定したレプリカ数と一致することを保証します。レプリカ数を変更すると、マニフェストが示すよりも多くまたは少ない Pods が実行される期間があります。ReplicaSet は、望ましい数の Pods が稼働するまで Pods を作成または削除します。
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: my-replicaset
labels:
my-label: my-value
spec:
replicas: 3
selector:
matchLabels:
my-label: my-value
template:
metadata:
labels:
my-label: my-value
spec:
containers:
- name: app-container
image: my-image:latest
上記のマニフェストは、3つのレプリカを実行します。
my-image:latestReplicaSetを使用したコンテナイメージ。マニフェスト内の値を更新して再適用することでレプリカの数を変更できます。
kubectl apply -f my-manifest.yml).
展開
ReplicaSetsはPodとの作業を容易にしますが、これも直接使用されることはほとんどありません。DeploymentはReplicaSetsの上にある抽象化です。通常、新しいワークロードをクラスターに追加する際には、Deploymentを作成します。
デプロイメントリソースは、PodとReplicaSetの宣言的な更新を可能にします。これにより、サービスのダウンタイムなしでPodが再スケジュールされるReplicaSetのローリングアップデートを実行できます。PodとReplicaSetは個別に置き換えられ、古いバージョンと新しいバージョンが一時的に共存することができます。
デプロイメントの必要性は、Kubernetesのレプリカに対する歴史的アプローチから生じました。ReplicaSetはReplication Controllerから進化しました。Replication Controllerは、レプリカセットと似た機能を提供しましたが、スケーリングサポートが組み込まれていました。
レプリケーションコントローラーは宣言的スケーリングを提供しませんでした。そのため、手動で使用する必要がありました。
kubectl rolling-updateダウンタイムなしでレプリカをスケールすること。これは、他のKubernetesリソースの宣言的なマニフェストベースのアプローチと対立していました。
ReplicaSetと比較して、Deploymentの主な利点は、ローリングアップデートをサポートしていることです。ReplicaSetでレプリカの数を変更しても、ロールアウト中に特定の状態にあるPodの数が保証されるわけではありません。Deploymentを使用すれば、たとえDeploymentがまだ完了していなくても、アプリケーションがトラフィックを処理し続けることができることが確実です。
今日、Kubernetesは、ワークロードを表すためにDeploymentの使用を勧めています。あなたのDeploymentはReplicaSetを自動的に実行およびスケールします; ReplicaSetはその結果、Podを管理します。Deploymentのローリングアップデートは、
replicasマニフェスト内のフィールド。Kubernetesは、アプリケーションが変更の間ずっと利用可能であることを保証し、新しいPodと古いPodが一時的に共存できるようにします。
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-deployment
labels:
my-label: my-value
spec:
replicas: 3
selector:
matchLabels:
my-label: my-value
template:
metadata:
labels:
my-label: my-value
spec:
containers:
- name: app-container
image: my-image:latest
上記のマニフェストは、3つのレプリカからなるデプロイメントを作成し、各レプリカが実行されることになります。
my-image:latestコンテナイメージ。変更することが
replicas値が基になるReplicaSetsとPodsのローリングアップデートをトリガーします。
その他のリソースの種類
私たちが見てきた3種類のリソースは、Kubernetesで作業する際に遭遇する最も一般的なオブジェクトです。これらは、アプリケーションのワークロードを構成し、コンテナを管理するために使用されます。
Kubernetesを利用するにつれて、他の種類のリソースタイプも使用する必要があります。ConfigMapとSecretsを使用すると、Podに設定を注入でき、外部の値にアクセスできるようになります。ボリュームと永続ボリュームは、Podに共有可能な書き込み可能なファイルシステムを提供し、Podが終了すると失われるデフォルトの一時ストレージの代わりにデータを保存できます。
さらなるリソースセットは、ワークロードのネットワークオプションを管理するのに役立ちます。サービスは、単一のIPアドレスで一連のポッドを単一のネットワークサービスとして公開することを可能にします。Ingressは、外部にサービスを公開することを許可します。これらは、ホスト名、ポート、およびURLパスのような属性に基づいて、トラフィックをクラスター内の宛先サービスにルーティングします。
最後に、クラスターを説明するメタリソースがあります。ネームスペースは個々のワークロードを隔離するために使用され、名前の衝突を防ぎます。通常、独立した各ワークロードのために新しいネームスペースを作成すべきです。ノードは、ポッドを実行している物理マシンを表す一種のリソースです。各ノードは通常、複数のポッドをホストします。Kubernetesは、各ノードの可用性とあなたが施行する制約に基づいてワークロードをスケジュールする方法を決定します。
クラスターの完全なリソースリストは、実行することで表示できます
kubectl api-resources組み込みリソースに加えて、ワークロードは独自のカスタムリソース定義（CRD）を追加でき、これにより新しい種類のオブジェクトを作成できます。Kubernetesはカスタムリソース定義のためのAPIエンドポイントを自動的に提供します。
結論
Kubernetesを学ぶことは、新しい抽象概念や用語に慣れることを意味します。これにより広範なAPIの表面積が生まれますが、各Kubernetesオブジェクトには比較的狭い目的があります。
高レベルの抽象概念、例えばデプロイメントを維持することができる場合が多いです。デプロイメントやレプリカセットだけでは解決できない複雑な要件がない限り、ポッドなどの基本的なリソースタイプを細かく管理する必要はありません。