这是两种不同的方法:

强制性管理

kubectl create 这就是我们所说的 Imperative Management . 在这种方法中,您可以告诉Kubernetes API您想要创建、替换或删除什么,而不是告诉K8s集群世界的样子。

声明式管理

kubectl apply 是 Declarative Management 方法,其中您可能已应用于活动对象的更改(即通过 scale )是“ 保持 “即使你 apply 对对象的其他更改。

您可以在 Kubernetes Object Management 文档

在外行,他们做不同的事情。如果资源存在, kubectl创建 将出错并 kubectl应用

在CI脚本中运行时,命令命令会出现问题 创造 如果资源已存在,则引发错误。

你能做的是 应用 (声明模式)命令命令的输出,使用 --dry-run=true 和 -o yaml

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

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

在某些无法使用声明模式的情况下(例如,在创建docker注册表密码时),这非常有用。

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

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

编辑

图中提到的示例存在错误。请参考评论以更好地理解。

您也可以参考下面的示例。

命令:

• 打开炉子。
• 在锅中加入水、糖、咖啡粉、牛奶
• 在杯子里端上咖啡。

声明的:

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

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

K8将负责所有资源,您需要指定的是您的实际需求。

根据我的理解,我只想给出一个更直接的答案:

apply
create -创建一个全新的对象(以前不存在/已删除)


从一个 DigitalOcean article Kubernetes网站链接:

我们在这里使用apply而不是create,以便将来可以将更改增量应用到入口控制器对象,而不是完全覆盖它们。

┌─────────┬───────────────────────┬────────────────────────┐
│ 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 replace -f your-object-config.yaml

与命令命令相比的优势:

• 可以存储在Git等源代码管理系统中。
• 可以与流程集成,例如推送前审查更改和审计跟踪。
• 提供用于创建新对象的模板。

与命令命令相比的缺点:

• 需要对对象模式有基本了解。
• 需要编写YAML文件的附加步骤。

• 更简单、更容易理解。

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

• 最适用于文件,而不是目录。
• 对活动对象的更新必须反映在配置文件中,否则在下次更换过程中会丢失。

这些是声明性对象配置

kubectl diff -f configs/

kubectl apply -f configs/

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

• 即使未合并回配置文件,直接对活动对象所做的更改也会保留。

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

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

下面的解释来自 official documentation 帮助我理解 kubectl apply .

kubectl create 另一方面,将创建(应该是不存在的)资源。

kubectl创建 一次可以处理一个对象配置文件。这也称为强制管理

kubectl应用 使用包含对象配置yaml文件的目录及其子目录。这也称为声明式管理。可以从目录中提取多个对象配置文件。 kubectl apply-f目录/

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

我们爱库伯内特是因为一旦我们给了他们我们想要的东西,他们就会想出如何在没有我们任何参与的情况下实现它。

“创造”就像扮演上帝一样,把东西掌握在自己手中。当您只想使用POD而不关心abt部署/复制控制器时,这有利于本地调试。

“应用”是按规则玩的。“apply”就像一个主工具,可以帮助您创建和修改pod,并且不需要您管理pod。