Kubectl适用于kubectl创建吗？

Question

我在文档中理解的是kubectl apply = kubectl create + kubectl replace.参考

我的理解是

如果我想在集群中创建新的k8s资源,我应该使用kubectl创建操作.现在,如果我想更新现场k8s资源中的内容,我应该使用kubectl替换操作.

如果我想做两个操作(创建一个新的k8s资源以及更新实时k8s资源)那么我应该使用kubectl应用操作

我的问题是为什么在集群中执行相同任务有三个操作？这些操作的用例是什么？他们如何在引擎盖下相互区别？

目前我正在使用kubectl create操作在集群中创建新资源.谢谢

Answer 1

这是两种不同的方法.kubectl create我们称之为命令式管理.在这种方法中,您可以告诉Kubernetes API您要创建,替换或删除的内容,而不是您希望K8s群集世界的样子.

kubectl apply是声明式管理方法的一部分,scale即使您apply对对象进行了其他更改,也可以保留应用于活动对象(即通过)的更改.

您可以在Kubernetes对象管理文档中阅读有关命令式和声明式管理的更多信息.

Answer 2

一种了解初学者差异的最佳方式。

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

编辑

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

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

至关重要的 ：

• 拿一个平底锅。
• 打开炉子。
• 在锅中加入水、糖、咖啡粉、牛奶
• 等到准备咖啡
• 在杯子里供应咖啡。

声明：

• 告诉服务员您需要一杯咖啡。他为你提供咖啡。

从 K8s 的角度来看：

当务之急：您必须自己管理不同的资源，例如 pod、服务、副本集等。

声明性： K8 将处理所有资源，您需要指定您的实际需求。

Answer 3

在CI脚本中运行时,您将遇到命令性命令的问题,因为如果资源已存在,则create会引发错误.

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

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

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

这在您无法使用声明性模式的某些情况下非常有用(例如,在创建docker-registry秘密时).

Answer 4

这些是命令式命令：

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 文件的附加步骤。

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

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

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

• 最适用于文件，而不是目录。
• 对活动对象的更新必须反映在配置文件中，否则它们将在下次替换时丢失。

这些是声明性对象配置

kubectl diff -f configs/

kubectl apply -f configs/

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

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

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

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

Answer 5

根据我的理解，只是给出一个更直接的答案：

apply-进行增量更改
create-覆盖所有更改


从Kubernetes网站链接的DigitalOcean文章中获取以下内容：

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

Answer 6

????????????????????????????????????????????????????????????
? 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      ?
????????????????????????????????????????????????????????????

Answer 7

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

让我们创建一个简单的 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 create -f pod.yaml

现在创建了一个名为 nginx 的 pod，您可以通过以下方式获取有关 pod 运行的信息 -

kubectl get pods -o wide

以及有关 pod 的详细视图

kubectl describe 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 create -f pod.yaml

应用 pod.yaml 中的更改。

它将有一个输出 -

来自服务器的错误（AlreadyExists）：创建“pod.yaml”时出错：pod“nginx”已存在

但使用命令 -

kubectl apply -f pod.yaml

输出是 -

已配置 pod/nginx

正如第一条评论中一样，它非常详细地解释了，create就像命令式命令专注于分配的任务一样，您不能为它们分配进一步的任务来调整集群的世界，但apply像声明性命令一样，旨在使其能够调整集群的世界。