我从文档中了解到:

kubectl创建 在集群中创建一个新的k8s资源 kubectl取代 更新活动集群中的资源 kubectl应用 如果我想创建+替换(参考)

我的问题是

为什么在集群中执行相同的任务有三种操作? 这些操作的用例是什么? 它们在本质上有什么不同?


这是两种不同的方法:

必要的管理

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时)。


以我的理解,给一个更直接的回答:

Apply -对现有对象进行增量更改 创建—创建一个全新的对象(以前不存在/已删除) 从Kubernetes网站上的一篇DigitalOcean文章中摘录如下:

我们在这里使用apply而不是create,以便将来我们可以增量地对Ingress Controller对象应用更改,而不是完全覆盖它们。


下面来自官方文档的解释帮助我理解kubectl apply。

此命令将比较您正在推送的配置版本与以前的版本,并应用您所做的更改,而不会覆盖对未指定属性的任何自动更改。

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


这些是命令式命令:

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/

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

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

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

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


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/


我们喜欢Kubernetes是因为一旦我们给了他们我们想要的东西,它就会在没有我们参与的情况下找到实现它的方法。

“创造”就像扮演上帝,把事情掌握在自己手中。当您只想使用POD而不关心Deployment/Replication Controller时,它很适合用于本地调试。

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


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



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


EDIT

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

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

必要的:

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

声明:

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


从K8s的角度来看:

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

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


┌─────────┬───────────────────────┬────────────────────────┐
│ 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      │
└─────────┴───────────────────────┴────────────────────────┘

这可以用简单的例子来总结:-

让我们创建一个简单的yaml来部署一个包含nginx图像的pod。

pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
    type: front-end
spec:
  containers:
    - name: nginx-container
      image: nginx

现在我们使用kubectl命令-创建一个pod

Kubectl创建-f pod.yaml

现在一个名为nginx的pod被创建了,你可以通过-获取运行的pod的信息

库贝特尔,把吊舱弄宽

和详细的查看豆荚由

kubectl描述pod nginx

现在如果我想在我的pod中做一些改变。Yaml文件是这样的-

pod.yaml

apiVersion: v1 
kind: Pod 
metadata:
  name: nginx
  labels:
    app: nginx
    tier: frontend
    title: frontend
spec:
  containers:
    - name: nginx
      image: nginx

现在试试命令

Kubectl创建-f pod.yaml

要应用pod.yaml中的更改。

它的输出是-

来自服务器的错误(AlreadyExists):创建pod时出错。Yaml ": pods "nginx"已经存在

但是有了命令-

Kubectl应用-f pod.yaml

输出为-

豆荚/ nginx配置

在第一个评论中,它非常详细地解释了create之类的命令式命令专注于分配给它们的任务,你不能给它们分配更多的任务来调整集群的世界,但apply之类的声明性命令旨在使其工作来调整集群的世界。


这个问题很深刻,也很好。下面是我对这个问题的思考:

K8s有三种资源管理方法

基于命令的对象管理:直接使用命令对kubernetes资源进行操作。例如: Kubectl运行nginx-pod——image=nginx:1.17.1——port=80 命令类型对象配置:通过命令配置和配置文件操作Kubernetes资源。例如: Kubectl create/patch -f nginx-pod.yaml 声明式对象配置:通过apply命令和配置文件操作kubernetes资源。例如: Kubectl应用-f nginx-pod.yaml

Type Operate Object Suitable for environment Advantage disadvantage
Command Based Object Management Object test env Simple Only active objects can be operated, but not audited or tracked
Command Type Object Configuration File develop evn Can be audited and tracked When the project is large, there are many configuration files and the operation is troublesome
Declarative Object Configuration Directory develop evn Support directory operations It is difficult to debug under unexpected circumstances