ポッドとデプロイメントの違いは何ですか？

私はでポッドを作成してtype:deploymentいますが、一部のドキュメントではtype:pod、具体的にはマルチコンテナポッドのドキュメントを使用しています。

apiVersion: v1
kind: Pod
metadata:
  name: ""
  labels:
    name: ""
  namespace: ""
  annotations: []
  generateName: ""
spec:
  ? "// See 'The spec schema' for details."
  : ~

しかし、ポッドを作成するには、デプロイメントタイプを使用するだけです。

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: ""
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: ""
    spec:
      containers:
        etc

私はポッドのドキュメントが言うことに気づきました：

createコマンドを使用して、ポッドを直接作成することも、Deploymentを介して1つまたは複数のポッドを作成することもできます。デプロイを使用してポッドを作成することを強くお勧めします。失敗したポッドを監視し、指定された数を維持するために必要に応じて新しいポッドを起動します。デプロイでポッドを監視したくない場合（たとえば、ポッドが再起動後も持続しない永続的でないデータを書き込んでいる、またはポッドが非常に短期間であることが意図されている）場合は、直接ポッドを作成できます。作成コマンド。

注：ポッドを作成するにはデプロイメントを使用することをお勧めします。以下の手順は、Deploymentを作成しない場合にのみ使用してください。

しかし、これは何kind:podが良いのかという疑問を投げかけますか？デプロイでポッドを何らかの方法で参照できますか？道がわからなかった。ポッドで得られるものはいくつかの追加のメタデータですが、replicaまたは再起動ポリシーなどのデプロイメントオプションはありません。データを保持せず、再起動後も存続するポッドは何が良いですか？デプロイでマルチコンテナポッドを作成することもできると思います。

ポッドとデプロイメントはどちらも、Kubernetes APIの本格的なオブジェクトです。デプロイでは、ReplicaSetを使用してポッドの作成を管理します。つまり、Deploymentはテンプレートから取得したスペックを使用してポッドを作成します。本番環境のユースケースで直接ポッドを作成する必要が生じることはまずありません。

Radekの答えは非常に良いですが、私は経験から提案したいと思います。実際には意味のないため、種類のポッドでオブジェクトを使用することはほとんどありません。

レプリカ（ポッド）を存続させる必要のあるデプロイメントオブジェクト（またはレプリケーションコントローラやレプリカセットなどの他のKubernetes APIオブジェクト）が必要なため（これは、kubernetesを使用する一種のポイントです）。

一般的なアプリケーションで実際に使用するものは次のとおりです。

1. 他の仕様でアプリのコンテナをホストするデプロイメントオブジェクト（アプリコンテナを指定する場所）。

2. サービスオブジェクト（これはグループ化オブジェクトのようなpodsもので、特定のラベルが付いたにいわゆる仮想IP（クラスターIP）を与えます。これらpodsは基本的に、以前のデプロイメントオブジェクトでデプロイしたアプリコンテナーです）。

デプロイメントオブジェクトのfromは強制終了、スケールアップ、スケールダウンでき、永続的ではないためIPアドレスに依存できないため、サービスオブジェクトが必要podsです。

したがって、それらに安定したIP を与えるサービスのようなオブジェクトが必要podsです。

周りの状況を説明したかったpodsので、物事がどのように連携するかがわかります。

それがあなたのためにいくつかのことをクリアしてくれることを願っています。

Kubernetesには、知っておくべき3つのオブジェクトタイプがあります。

• ポッド-1つ以上の密接に関連するコンテナを実行します
• サービス -Kubernetesクラスターでネットワークを設定します
• デプロイ -一連の同一のポッドを維持し、それらが正しい構成を持ち、正しい数のポッドが存在することを確認します。

ポッド：

• コンテナの単一セットを実行します
• 1回限りの開発目的に適しています
• 生産で直接使用されることはほとんどありません

展開：

• 同じポッドのセットを実行します
• 各ポッドの状態を監視し、必要に応じて更新します
• 開発者にとって良い
• 生産に適しています

そして、私は他の答えに同意し、ポッドを忘れて、単にデプロイメントを使用します。どうして？2番目の箇条書きを見て、各ポッドの状態を監視し、必要に応じて更新します。

したがって、次のようなエラーメッセージに悩まされる代わりに：

禁止：ポッドの更新では、 spec.containers[*].image

したがって、ポッドをデプロイするデプロイメントに完全にリファクタリングまたは完全に再作成して、必要なことを実行するポッドを作成します。Deploymentを使用すると、任意の構成を変更でき、そのエラーメッセージが表示されることを心配する必要はありません。

ポッドはコンテナインスタンスです。

それはの出力です replicas: 3

deployment多くの実行中のインスタンス（レプリカ）を持つことができると考えてください。

//deployment.yaml
apiVersion: apps/v1beta2
kind: Deployment
metadata:
  name: tomcat-deployment222
spec:
  selector:
    matchLabels:
      app: tomcat
  replicas: 3
  template:
    metadata:
      labels:
        app: tomcat
    spec:
      containers:
      - name: tomcat
        image: tomcat:9.0
        ports:
        - containerPort: 8080

ポッドは、Kuberntesのコンテナと基本オブジェクトのコレクションです。ポッドのすべてのコンテナは同じノードにあります。

• 生産には適していません
• ローリング更新なし

デプロイはKubernetesの一種のコントローラです。

Controllers use a Pod Template that you provide to create the Pods for which it is responsible.

デプロイメントにより、ReplicaSetが作成されます。これにより、CurrentReplicasがdesiredReplicasと常に同じであることを確認します。

利点：

• デプロイメントを使用して変更をロールアウトおよびロールバックできます
• 各ポッドの状態を監視します
• 生産に最適
• ローリング更新をサポート

Kubernetes In Actionブックからいくつかの情報を追加して、ポッド、Deployment、ReplicationController（ReplicaSet）などのKubernetesリソース間のすべての画像と接続関係を確認できるようにします

ポッド

Kubernetesの基本的なデプロイ可能なユニットです。ただし、実際の使用例では、デプロイメントを自動的に稼働させ続け、手動による介入なしで健全性を維持する必要があります。このための推奨されるアプローチは、内部でレプリカセットを作成するデプロイメントを使用することです。

A さらにreplicaSet、名前が示すように、自分で維持レプリカのセット（ポッド）であるリビジョンの歴史を。

（ReplicaSetは、ReplicationControllerと呼ばれる古いオブジェクトを拡張します-これはまったく同じですが、改訂履歴がありません。）

ReplicaSetは常に実行中のポッドのリストを監視し、特定の仕様に一致する実行中のポッドの数が常に目的の数と一致することを確認します。

Removing a pod from the scope of the ReplicationController comes in handy
when you want to perform actions on a specific pod. For example, you might 
have a bug that causes your pod to start behaving badly after a specific amount 
of time or a specific event.

A の展開

アプリケーションのデプロイと宣言による更新を目的とした上位レベルのリソースです。

Deploymentを作成すると、ReplicaSetリソースがその下に作成されます（最終的にはさらに多く）。 レプリカセットは、ポッドも複製および管理します。展開を使用する場合は、実際のポッドはによって作成および管理されている展開のReplicaSets、しないことによって展開直接

何が起こったのか考えてみましょう。Deploymentリソースのポッドテンプレートを変更することで、1つのフィールドを変更することで、アプリを新しいバージョンに更新しました。

最後に、デプロイメントをロールバックします Deploymentリソースを使用すると、Deploymentを前のリビジョンまたは以前のリビジョンに簡単できます。

これらの画像は、Kubernetes In Actionブックからのものでもあります。

ノード障害やポッドの終了時に、ポッドの種類のオブジェクトは再スケジュール（または自己修復）されないため、コンテナを管理する代わりに、ポッドを回避してデプロイメントを実装してください。

Deploymentは、希望する数のポッドが常に利用可能になるようにReplicaSetを定義し、RollingUpdateなどのポッドを置き換えるための戦略を指定するため、一般的に推奨されます。

kubernetesでは、ポッドはデプロイ可能な最小単位です。Deployment、レプリカセット、ステートフルセット、デーモンセットなどのkubernetesオブジェクトを作成するたびに、ポッドが作成されます。

上記のように、デプロイメントは、デプロイメントオブジェクトに記述されている望ましい状態に基づいてポッドを作成します。したがって、たとえば、アプリケーションの5つのレプリカが必要な場合replicas: 5は、デプロイメントマニフェストで言及します。現在、デプロイメントコントローラーは、RBACポリシー、ネットワークポリシー、ラベル、注釈、ヘルスチェック、リソースクォータ、汚染/許容などのすべてのメタデータを使用して、指定されたアプリケーションの5つの同一のレプリカを作成し、それを各ポッドに関連付けます。それが作成します。

ポッドを作成したい場合があります。たとえば、アプリケーションを永久に実行する必要がないテストサイドカーを実行していて、複数のレプリカを必要とせず、その中で実行したいときにアプリケーションを実行している場合などです。ケースポッドが適しています。例えばhelm test、実行する特定のコマンドでコンテナを指定するポッド定義です。