Kubectl创建可以一次使用一个对象配置文件。这也被称为命令式管理

Kubectl create -f filename|url

Kubectl应用程序与包含对象配置yaml文件的目录及其子目录一起工作。这也称为声明式管理。可以从目录中提取多个对象配置文件。 Kubectl应用-f directory/

细节: https://kubernetes.io/docs/tasks/manage-kubernetes-objects/declarative-config/ https://kubernetes.io/docs/tasks/manage-kubernetes-objects/imperative-config/

对于初学者来说，这是理解命令式模式和声明式模式之间区别的最好方法之一。

参考:https://www.digitalocean.com/community/tutorials/imperative-vs-declarative-kubernetes-management-a-digitalocean-comic

EDIT

有错误的例子中提到的图像。请参考评论以便更好地理解。

你也可以参考下面的例子。

必要的:

拿一个平底锅。 打开炉子。 锅中加入水、糖、咖啡粉、牛奶 等到咖啡准备好 用杯子盛咖啡。

声明:

告诉服务员你要一杯咖啡。他给你端咖啡。

从K8s的角度来看:

命令式:你必须自己管理不同的资源，如pod、服务、副本集等。

声明性:K8将负责所有的资源，所有您需要指定的是您的实际需求。

这是两种不同的方法:

必要的管理

kubectl create就是我们所说的命令式管理。在这种方法中，你告诉Kubernetes API你想要创建、替换或删除什么，而不是你想要你的K8s集群世界是什么样子。

声明式管理

kubectl apply是声明式管理方法的一部分，在这种方法中，即使对对象应用了其他更改，也会“维护”对活动对象应用的更改(即通过缩放)。

您可以在Kubernetes对象管理文档中阅读更多关于命令式和声明式管理的内容。

在外行他们做不同的事情。如果资源存在，kubectl create会出错，而kubectl apply不会出错。

在CI脚本中运行时，如果资源已经存在，则创建会引发错误，因此使用命令式命令会遇到麻烦。

你能做的是应用(声明式模式)命令的输出，通过使用——dry-run=true和-o yaml选项:

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

如果资源已经存在，上面的命令不会引发错误(如果需要，将更新资源)。

这在某些不能使用声明式模式的情况下非常有用(例如在创建docker-registry secret时)。

┌─────────┬───────────────────────┬────────────────────────┐
│ command │ object does not exist │ object already exists  │
├─────────┼───────────────────────┼────────────────────────┤
│ create  │ create new object     │          ERROR         │ 
│         │                       │                        │
│ apply   │ create new object     │ configure object       │
│         │ (needs complete spec) │ (accepts partial spec) │
│         │                       │                        │
│ replace │         ERROR         │ delete object          │
│         │                       │ create new object      │
└─────────┴───────────────────────┴────────────────────────┘

这些是命令式命令:

Kubectl run = Kubectl create deployment

优点:

简单、易学、易记。 只需要一个步骤就可以对集群进行更改。

缺点:

不要与变更评审过程集成。 不要提供与变更相关的审计跟踪。 除了实时的记录，不要提供其他记录来源。 不要为创建新对象提供模板。

这些是命令式对象配置:

Kubectl create -f your-object-config.yaml

Kubectl delete -f your-object-config.yaml

Kubectl替换-f your-object-config.yaml

与命令式命令相比的优点:

可以存储在源代码控制系统中，比如Git。 可以与流程集成，例如在推送之前检查更改和审计跟踪。 提供用于创建新对象的模板。

与命令式命令相比的缺点:

要求对对象模式有基本的了解。 需要编写YAML文件的额外步骤。

与声明式对象配置相比的优势:

更简单，更容易理解。 Kubernetes 1.5版本之后更加成熟。

与声明式对象配置相比的缺点:

在文件上工作最好，而不是目录上。 对活动对象的更新必须反映在配置文件中，否则它们将在下一次替换期间丢失。

这些是声明性的对象配置

Kubectl diff -f configs/

Kubectl应用-f configs/

与命令式对象配置相比的优点:

直接对活动对象所做的更改将被保留，即使它们没有合并回配置文件中。 更好地支持对目录进行操作，并自动检测每个对象的操作类型(创建、修补、删除)。

与命令式对象配置相比的缺点:

当结果出乎意料时，更难调试和理解。 使用差异的部分更新会创建复杂的合并和补丁操作。