dry-run、Kubectl diff、kubectl apply、kubectl delete -f、kubectl get -f、kubectl run

本文主要是介绍dry-run、Kubectl diff、kubectl apply、kubectl delete -f、kubectl get -f、kubectl run，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

使用示例

为了平常使用yaml时，由于手抖，造成的格式错误，建议尽量使用–dry-run参数来生成一个基础的yaml，再修改。

注意点：

• 如何使用dry-run
• 如何使用-o name、-o json、-o yaml、-o go template 或 -o jsonpath。
• 关于 kubectl run 显式设置 --generator 参数或者不指定生成器。（pod）

• yaml格式+dry run试运行

  kubectl create service clusterip my-svc --clusterip="None" -o yaml --dry-run=client |     kubectl set selector --local -f - 'environment=qa' -o yaml | kubectl create -f -
  

  1. 命令 kubectl create service -o yaml --dry-run=client 创建 Service 的配置，但 将其以 YAML 格式在标准输出上打印而不是发送给 API 服务器。
  2. 命令 kubectl set selector --local -f - -o yaml 从标准输入读入配置，并将更新后的 配置以 YAML 格式输出到标准输出。
  3. 命令 kubectl create -f - 使用标准输入上获得的配置创建对象。

• dry run试运行+yaml格式

  #运行 ngins Pod 并将其规约写入到名为 pod.yaml 的文件
  kubectl run nginx --image=nginx --dry-run=client -o yaml > pod.yaml
  kubectl run deployment nginx-app --image=nginx --dry-run=client -o yaml > deployment-pod.yaml#仔细看下这两都有什么区别呢，不要错误理解为第二种是创建的deployment!!!
  

  root@master:/shl4yaml# cat pod.yaml 
  apiVersion: v1
  kind: Pod
  metadata:creationTimestamp: nulllabels:run: nginxname: nginx
  spec:containers:- image: nginxname: nginxresources: {}dnsPolicy: ClusterFirstrestartPolicy: Always
  status: {}
  ----------------------------------------------
  root@master:/shl4yaml# cat deployment-pod.yaml 
  apiVersion: v1
  kind: Pod
  metadata:creationTimestamp: nulllabels:run: deploymentname: deployment
  spec:containers:- args:- nginx-appimage: nginxname: deploymentresources: {}dnsPolicy: ClusterFirstrestartPolicy: Always
  status: {}
  

• dry-run

  #创建 Service 的配置，但 将其以 YAML 格式在标准输出上打印而不是发送给 API 服务器
  kubectl create service -o yaml --dry-run=client
  

• 创建 Pod，名字为 nginx-666，镜像为 nginx，部署到 label disk=ssd的node上

  #运行 ngins Pod 并将其规约写入到名为 nginx-666.yaml的文件
  kubectl run nginx-666 --image=nginx -o yaml --dry-run=client >nginx-666.yaml
  #然后再编辑yaml把nodeSelector为disk: ssdl加上，即可
  apiVersion: v1
  kind: Pod
  metadata:creationTimestamp: nulllabels:run: nginx-kusc00101name: nginx-kusc00101
  spec:containers:- image: nginxname: nginx-kusc00101nodeSelector:disk: ssd
  #再运行    
  kubectl apply -f nginx-666.yaml
  

• 创建 deployment 名字为 nginx-app 容器采用 1.10.2-alpine 版本的 nginx 这个 deployment 包含 3 个副本

  kubectl create deploy  nginx-app --image=nginx:1.10.2-alpine -o yaml --dry-run=client > nginx-app.yaml
  #然后再编辑yaml，进行添加其它内容
  vi nginx-app.yaml
  #运行
  kubectl apply -f nginx-app.yaml
  #nginx 这个 deployment 包含 3 个副本
  kubectl scale deploy nginx-app --replicas=3######或者一条命令搞定
  kubectl run deployment nginx-app --image=nginx:1.10.2-alpine --replicas=3
  

脚本中的稳定输出

请求一个面向机器的输出格式，例如 -o name、-o json、-o yaml、-o go template 或 -o jsonpath。

使用配置文件对 Kubernetes 对象进行声明式管理

你可以通过在一个目录中存储多个对象配置文件、并使用 kubectl apply 来递归地创建和更新对象来创建、更新和删除 Kubernetes 对象。 这种方法会保留对现有对象已作出的修改，而不会将这些更改写回到对象配置文件中。 kubectl diff 也会给你呈现 apply 将作出的变更的预览。

Kubectl diff

Kubectl diff

APIServer dry-run很方便，因为它可以让你看到如何处理对象，但如果对象很大，很难准确识别出改变了什么。kubectl diff可以满足这方面的需要，通过显示当前“实时”对象与新“干运行”对象之间的差异。只关注对对象所做的更改，服务器如何合并这些更改，以及变异webhook如何影响输出，这非常方便。

概览

声明式对象管理需要用户对 Kubernetes 对象定义和配置有比较深刻的理解。 如果你还没有这方面的知识储备，请先阅读下面的文档：

• 使用指令式命令管理 Kubernetes 对象
• 使用配置文件对 Kubernetes 对象进行指令式管理

以下是本文档中使用的术语的定义：

• 对象配置文件/配置文件：一个定义 Kubernetes 对象的配置的文件。 本主题展示如何将配置文件传递给 kubectl apply。 配置文件通常存储于类似 Git 这种源码控制系统中。
• 现时对象配置/现时配置：由 Kubernetes 集群所观测到的对象的现时配置值。 这些配置保存在 Kubernetes 集群存储（通常是 etcd）中。
• 声明式配置写者/声明式写者：负责更新现时对象的人或者软件组件。 本主题中的声明式写者负责改变对象配置文件并执行 kubectl apply 命令 以写入变更。

如何创建对象

使用 kubectl apply 来创建指定目录中配置文件所定义的所有对象，除非对应对象已经存在：

kubectl apply -f <目录>/

此操作会在每个对象上设置 kubectl.kubernetes.io/last-applied-configuration: '{...}' 注解。注解值中包含了用来创建对象的配置文件的内容。

说明： 添加 -R 标志可以递归地处理目录。

示例

下面是一个对象配置文件示例：

simple_deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:name: nginx-deployment
spec:selector:matchLabels:app: nginxminReadySeconds: 5template:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx:1.14.2ports:- containerPort: 80

执行 kubectl diff 可以打印出将被创建的对象：

kubectl diff -f simple_deployment.yaml

说明：
diff 使用服务器端试运行（Server-side Dry-run） 功能特性；而该功能特性需要在 kube-apiserver 上启用。
由于 diff 操作会使用试运行模式执行服务器端 apply 请求，因此需要为 用户配置 PATCH、CREATE 和 UPDATE 操作权限。 参阅试运行授权 了解详情。

使用 kubectl apply 来创建对象：

kubectl apply -f https://k8s.io/examples/application/simple_deployment.yaml

使用 kubectl get 打印其现时配置：

kubectl get -f https://k8s.io/examples/application/simple_deployment.yaml -o yaml

如何更新对象

你也可以使用 kubectl apply 来更新某个目录中定义的所有对象，即使那些对象已经存在。 这一操作会隐含以下行为：

1. 在现时配置中设置配置文件中出现的字段；
2. 在现时配置中清除配置文件中已删除的字段。

kubectl diff -f <目录>/
kubectl apply -f <目录>/

说明： 使用 -R 标志递归处理目录。

示例

下面是一个配置文件示例：

simple_deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:name: nginx-deployment
spec:selector:matchLabels:app: nginxminReadySeconds: 5template:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx:1.14.2ports:- containerPort: 80

使用 kubectl apply 来创建对象：

kubectl apply -f https://k8s.io/examples/application/simple_deployment.yaml

使用 kubectl get 打印现时配置：

kubectl get -f https://k8s.io/examples/application/simple_deployment.yaml -o yaml

通过 kubeclt scale 命令直接更新现时配置中的 replicas 字段。 这一命令没有使用 kubectl apply：

kubectl scale deployment/nginx-deployment --replicas=2

使用 kubectl get 来打印现时配置：

kubectl get deployment nginx-deployment -o yaml

输出显示，replicas 字段已经被设置为 2，而 last-applied-configuration 注解中 并不包含 replicas 字段。

如何删除对象

官方建议操作方式：kubectl delete -f <文件名>

kubectl delete -f <文件名>

如何查看对象

你可以使用 kubectl get 并指定 -o yaml 选项来查看现时对象的配置：

kubectl get -f <文件名 | URL> -o yaml

服务器端试运行（Server-side Dry-run）

服务器端试运行（Server-side Dry-run）

试运行dry-run的授权

试运行和非试运行请求的鉴权是完全相同的。因此，要发起一个试运行请求，用户必须 被授权执行非试运行请求。

例如，要在 Deployment 对象上试运行 PATCH 操作，你必须具有对 Deployment 执行PATCH 操作的访问权限，如下面的 RBAC 规则所示：

rules:
- apiGroups: ["extensions", "apps"]resources: ["deployments"]verbs: ["patch"]

试运行 dry-run

FEATURE STATE: Kubernetes v1.18 [stable]

修改性质的动词（POST、PUT、PATCH 和 DELETE）可以支持 试运行（dry run） 模式的请求。试运行模式可帮助通过典型的请求阶段（准入控制链、合法性 检查、合并冲突）来评估请求，只是最终的对象不会写入存储。请求的响应主体与 非试运行模式下的响应尽可能接近。系统会保证试运行模式的请求不会被写入到存储 中，也不会产生其他副作用。

发起试运行请求

通过设置 dryRun 查询参数可以触发试运行模式。此参数是一个字符串，以枚举值 的形式工作且可接受的值只有：

• All：每个阶段被会正常运行，除了最后的存储阶段。准入控制器会被运行来检查请求 是否合法，变更性（Mutating）控制器会变更请求，PATCH 请求也会触发合并操作， 对象字段的默认值也会被设置，且基于模式定义的合法性检查也会被执行。 所生成的变更不会被写入到下层的持久性存储中，但本来会写入到数据库中的最终对象 会和正常的状态代码一起被返回给用户。如果请求会触发准入控制器而该准入控制器 带有一定的副作用，则请求会失败而不是冒险产生不希望的副作用。 所有的内置准入控制器插件都支持试运行模式。此外，准入控制 Webhook 也可在其 配置对象 中通过将 sideEffects 字段设置为 “None” 来声明自身不会产生副作用。 如果某 Webhook 确实会产生副作用，那么 sideEffects 字段应该设置为 “NoneOnDryRun”， 并且 Webhook 应该被更改以支持 AdmissionReview 中的 dryRun 字段，从而避免 在试运行时产生副作用。
• 空字符串（也即默认值）：保留默认的修改行为。

例如：

POST /api/v1/namespaces/test/pods?dryRun=All
Content-Type: application/json
Accept: application/json

响应会与非试运行模式请求的响应看起来相同，只是某些生成字段的值可能会不同。

kubectl 的用法约定

kubectl 工具能够支持三种对象管理方式：

• 指令式命令
• 指令式对象配置
• 声明式对象配置

关于每种对象管理的优缺点的讨论，可参见 Kubernetes 对象管理。

kubectl 的推荐用法约定

在可重用脚本中使用 kubectl

对于脚本中的稳定输出：

• 请求一个面向机器的输出格式，例如 -o name、-o json、-o yaml、-o go template 或 -o jsonpath。
• 完全限定版本。例如 jobs.v1.batch/myjob。这将确保 kubectl 不会使用其默认版本，该版本会随着时间的推移而更改。
• 在使用基于生成器的命令（例如 kubectl run 或者 kubectl expose）时，指定 --generator 参数以固定到特定行为。
• 不要依赖上下文、首选项或其他隐式状态。

最佳实践

kubectl run

若希望 kubectl run 满足基础设施即代码的要求：

• 使用特定版本的标签标记镜像，不要将该标签移动到新版本。例如，使用 :v1234、v1.2.3、r03062016-1-4，而不是 :latest（有关详细信息，请参阅配置的最佳实践)。
• 固定到特定的生成器版本，例如 kubectl run --generator=run-pod/v1。
• 使用基于版本控制的脚本来记录所使用的参数，或者至少使用 --record 参数以便为所创建的对象添加注解，在使用轻度参数化的镜像时，记录下所使用的命令行。
• 使用基于版本控制的脚本来运行包含大量参数的镜像。
• 对于无法通过 kubectl run 参数来表示的功能特性，使用基于源码控制的配置文件，以记录要使用的功能特性。

生成器

您可以使用带有 --generator 参数的 kubectl run 命令创建如下资源：

资源	API 组	kubectl 命令
Pod	v1	kubectl run --generator=run-pod/v1
ReplicationController (已弃用)	v1	kubectl run --generator=run/v1
Deployment (已弃用)	extensions/v1beta1	kubectl run --generator=deployment/v1beta1
Deployment (已弃用)	apps/v1beta1	kubectl run --generator=deployment/apps.v1beta1
Job (已弃用)	batch/v1	kubectl run --generator=job/v1
CronJob (已弃用)	batch/v2alpha1	kubectl run --generator=cronjob/v2alpha1
CronJob (已弃用)	batch/v1beta1	kubectl run --generator=cronjob/v1beta1

说明：

不推荐使用 run-pod/v1 以外的其他生成器.

如果您显式设置了 --generator 参数，kubectl 将使用您指定的生成器。如果使用 kubectl run 命令但是未指定生成器，kubectl 会根据您设置的其他参数自动选择要使用的生成器。下表列出了如果您自己未指定参数自动使用与之相匹配的生成器：

参数	相匹配的资源
--schedule=<schedule>	CronJob
--restart=Always	Deployment
--restart=OnFailure	Job
--restart=Never	Pod

如果不指定生成器，kubectl 将按以下顺序考虑其他参数：

1. --schedule
2. --restart

您可以使用 --dry-run 参数预览要发送到集群的对象，而无需真正提交。

kubectl apply

• 您可以使用 kubectl apply 命令创建或更新资源。有关使用 kubectl apply 更新资源的详细信息，请参阅 Kubectl 文档。

参考原文：

英文https://v1-17.docs.kubernetes.io/blog/2019/01/14/apiserver-dry-run-and-kubectl-diff/

中文https://mp.weixin.qq.com/s/hQXP2zooYosmTPVGS7kB3Q

这篇关于dry-run、Kubectl diff、kubectl apply、kubectl delete -f、kubectl get -f、kubectl run的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---