web-dev-qa-db-ja.com

「kubectl apply」と「kubectl create」の違い

以下のyamlを使用してkubectl create -f pod.xmlおよびkubectl apply -f pod.xmlでポッドを作成しましたが、違いは見られません。ポッドは両方のコマンドで作成されます。 K8Sドキュメント は、命令型および宣言型のコマンドに言及しています。ただし、作成と適用は同じように動作します。

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
  containers:
  - name: myapp-container
    image: busybox
    command: ['sh', '-c', 'echo Hello Kubernetes! && sleep 3600']

違いは何ですか？また、kubectl applyは宣言型で、kubectl createは命令型です。どちらも、オブジェクトの詳細が含まれている1つまたは複数のyamlファイルを取ります。

kubernetesdeclarativeimperative
8
Praveen Sripati

kubectl createコマンドとkubectl applyコマンドには微妙な違いがあります。

kubectl createコマンドは、新しいリソースを作成します。したがって、コマンドを再度実行すると、リソース名は名前空間で一意である必要があるため、エラーがスローされます。

kubectl get pods
No resources found.

kubectl create -f pod.xml 
pod/myapp-pod created

kubectl create -f pod.xml 
Error from server (AlreadyExists): error when creating "pod.xml": pods "myapp-pod" already exists

2）kubectl applyコマンドは、構成をリソースに適用します。リソースがそこにない場合は、作成されます。 kubectl applyコマンドは、次に示すように構成を適用するだけなので、2回目に実行できます。この場合、構成は変更されていません。したがって、ポッドは変更されていません。

kubectl delete pod/myapp-pod
pod "myapp-pod" deleted

kubectl apply -f pod.xml 
pod/myapp-pod created

kubectl apply -f pod.xml 
pod/myapp-pod unchanged

kubectl createでは、特定のアクションを指定します。この場合はcreateなので、命令です。 kubectl applyコマンドでは、システムのターゲット状態を指定し、特定のアクションを指定していないため、declarativeです。実行するアクションをシステムに決定させます。リソースが存在しない場合は作成され、リソースが存在する場合は既存のリソースに構成が適用されます。

実行の観点から見ると、上に示したように、kubectl createとkubectl applyの間でリソースが初めて作成されるときの違いはありません。ただし、2回目のkubectl createはエラーをスローします。

それを回避するのに少し時間がかかりましたが、今では理にかなっています。

16
Praveen Sripati

簡単に言えば、createとapplyは、単一のファイルに対して操作を実行してリソースを作成する場合、基本的に同じです。ただし、applyを使用すると、ディレクトリ内の複数のファイルを同時に作成してパッチを適用できます。

ディレクトリからリソースを削除する apply もありますが、この記事の執筆時点ではアルファ版です。

kubectl apply -f <directory/> --Prune -l your=label)

この質問にはさらに洞察があります： Kubectl apply vs kubectl create？

4
Rico

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

kubectl applyは Declarative Management アプローチの一部であり、ライブオブジェクトに適用された可能性のある変更（つまり、スケールによる）は、オブジェクトに他の変更を適用した場合でも維持されます。

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

0
Sunil Gajula