使用示例

为了平常使用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: null
  labels:
    run: nginx
  name: nginx
spec:
  containers:
  - image: nginx
    name: nginx
    resources: {
      
      }
  dnsPolicy: ClusterFirst
  restartPolicy: Always
status: {
      
      }
----------------------------------------------
root@master:/shl4yaml# cat deployment-pod.yaml 
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: deployment
  name: deployment
spec:
  containers:
  - args:
    - nginx-app
    image: nginx
    name: deployment
    resources: {
      
      }
  dnsPolicy: ClusterFirst
  restartPolicy: 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: null
  labels:
    run: nginx-kusc00101
  name: nginx-kusc00101
spec:
  containers:
  - image: nginx
    name: nginx-kusc00101
  nodeSelector:
    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 将作出的变更的预览。

扫描二维码关注公众号，回复： 12415457 查看本文章

Kubectl diff

Kubectl diff

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

概览

声明式对象管理需要用户对 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: nginx
  minReadySeconds: 5
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - 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 来更新某个目录中定义的所有对象，即使那些对象已经存在。这一操作会隐含以下行为：

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

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

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

示例

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

simple_deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  minReadySeconds: 5
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - 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）

试运行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 将按以下顺序考虑其他参数：

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

理解并举例标题中的命令

使用示例

脚本中的稳定输出

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

Kubectl diff

概览

如何创建对象

示例

如何更新对象

示例

如何删除对象

如何查看对象

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

试运行dry-run的授权

试运行 dry-run

发起试运行请求

kubectl 的用法约定

在可重用脚本中使用 `kubectl`

最佳实践

`kubectl run`

生成器

`kubectl apply`

猜你喜欢

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

理解并举例标题中的命令

使用示例

脚本中的稳定输出

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

Kubectl diff

概览

如何创建对象

示例

如何更新对象

示例

如何删除对象

如何查看对象

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

试运行dry-run的授权

试运行 dry-run

发起试运行请求

kubectl 的用法约定

在可重用脚本中使用 kubectl

最佳实践

kubectl run

生成器

kubectl apply

猜你喜欢

在可重用脚本中使用 `kubectl`

`kubectl run`

`kubectl apply`