ドキュメントで私が理解したのは、

• kubectl create =クラスタに新しいk8sリソースを作成します
• kubectl replace =ライブクラスタ内のリソースを更新します
• kubectl apply = create + replaceを実行する場合（リファレンス）

私の質問は

1. クラスターで同じタスクを実行するために3つの操作があるのはなぜですか？
2. これらの操作のユースケースは何ですか？
3. フードの下でお互いにどのように違うのですか？

これらは2つの異なるアプローチです。

命令的管理

kubectl create命令型管理と呼ばれるものです。このアプローチでは、K8sクラスターの世界をどのように見せたいかではなく、作成、置換、または削除する対象をKubernetes APIに伝えます。

宣言的管理

kubectl applyは宣言的管理アプローチの一部であり、ライブオブジェクトに適用した可能性のある変更（つまり、を介してscale）は、オブジェクトに他の変更を加えても「維持」さapplyれます。

命令型および宣言型の管理の詳細については、Kubernetes Object Managementのドキュメントをご覧ください。

CIスクリプトで実行する場合、リソースが既に存在する場合、createはエラーを発生させるため、命令コマンドで問題が発生します。

あなたができることは、命令コマンドの出力を（宣言的なパターンで）適用することです。--dry-run=trueと-o yamlオプション：

kubectl create whatever --dry-run=true -o yaml | kubectl apply -f -

上記のコマンドは、リソースがすでに存在する場合はエラーを発生させません（必要に応じてリソースを更新します）。

これは、宣言パターンを使用できない場合（たとえば、docker-registryシークレットを作成する場合）に非常に役立ちます。

私の理解から、より直接的な答えを与えるために：

apply-既存のオブジェクトを段階的に変更します
create-まったく新しいオブジェクトを作成します（以前は存在しなかった/削除されました）


これを、KubernetesのWebサイトによってリンクされたDigitalOceanの記事から取得します。

ここではcreateの代わりにapplyを使用して、将来的にIngress Controllerオブジェクトに変更を完全に上書きする代わりに増分的に適用できるようにします。

これらは必須のコマンドです：

kubectl run = kubectl create deployment

利点：

• シンプルで覚えやすく、覚えやすい。
• クラスターを変更するのに必要な手順は1つだけです。

短所：

• 変更レビュープロセスと統合しないでください。
• 変更に関連する監査証跡を提供しないでください。
• ライブのものを除いて、レコードのソースを提供しないでください。
• 新しいオブジェクトを作成するためのテンプレートを提供しないでください。

これらは必須のオブジェクト設定です：

kubectl create -f your-object-config.yaml

kubectl delete -f your-object-config.yaml

kubectl replace -f your-object-config.yaml

命令型コマンドと比較した利点：

• Gitなどのソース管理システムに保存できます。
• プッシュおよび監査証跡の前に変更をレビューするなどのプロセスと統合できます。
• 新しいオブジェクトを作成するためのテンプレートを提供します。

命令型コマンドと比較した短所：

• オブジェクトスキーマの基本的な理解が必要です。
• YAMLファイルを書き込む追加の手順が必要です。

宣言型オブジェクト構成と比較した利点：

• シンプルで理解しやすい。
• Kubernetesバージョン1.5以降はさらに成熟しています。

宣言的なオブジェクト構成と比較した短所：

• ディレクトリではなくファイルで最適に機能します。
• ライブオブジェクトへの更新は構成ファイルに反映する必要があります。そうしないと、次回の置換時に失われます。

これらは宣言的なオブジェクト構成です

kubectl diff -f configs/

kubectl apply -f configs/

命令型オブジェクト構成と比較した利点：

• ライブオブジェクトに直接加えられた変更は、構成ファイルにマージされない場合でも保持されます。
• ディレクトリでの操作、およびオブジェクトごとの操作タイプ（作成、パッチ、削除）の自動検出のサポートの向上。

命令型オブジェクト構成と比較した短所：

• 予期しない結果をデバッグして理解するのが難しくなります。
• 差分を使用した部分的な更新は、複雑なマージおよびパッチ操作を作成します。

公式ドキュメントからの以下の説明は私を理解するのに役立ちましたkubectl apply。

このコマンドは、プッシュしている構成のバージョンを以前のバージョンと比較し、指定していないプロパティへの自動変更を上書きせずに、行った変更を適用します。

kubectl create 一方、リソースは作成されます（存在しないはずです）。

kubectl createは、一度に1つのオブジェクト構成ファイルを処理できます。これは、必須管理とも呼ばれます

kubectl create -f filename | url

kubectl applyは、オブジェクト設定yamlファイルを含むディレクトリとそのサブディレクトリで機能します。これは宣言的管理とも呼ばれます。ディレクトリから複数のオブジェクト構成ファイルを取得できます。 kubectl apply -f directory /

詳細：
https //kubernetes.io/docs/tasks/manage-kubernetes-objects/declarative-config/ https://kubernetes.io/docs/tasks/manage-kubernetes-objects/imperative-config/

Kubernetesが大好きなのは、Kubernetesに必要なものを渡したら、関与せずにそれを達成する方法を見つけ出すためです。

「創造する」とは、物事を自分の手で取り、神を演じるようなものです。これは、PODのみを操作し、abt Deployment / Replication Controllerを気にしない場合のローカルデバッグに適しています。

「適用」はルールに従っています。「適用」は、ポッドの管理と作成に役立つマスターツールのようなもので、ポッドを管理するために何も必要としません。