Kubectl
Kubernetes 对象管理
管理技术
Kubernetes 对象只能使用一项技术进行管理。使用多项技术对同一对象进行管理会产生未定义的行为
| Management technique | Operates on | Recommended environment | Supported writers | Learning curve |
|---|---|---|---|---|
| Imperative commands | Live objects | Development projects | 1+ | Lowest |
| Imperative object configuration | Individual files | Production projects | Moderate | |
| Declarative object configuration | Directories of files | Production projects | 1+ | Highest |
命令式命令
当使用命令式命令时，用户直接对集群中活动的对象进行操作。用户将操作作为参数提供给 kubectl。
Trade-offs
相对于对象配置的优点：
- 较简单
- 只需一步就可以在集群上做改变
相对于对象配置的缺点：
- 命令不与更改回顾过程集成
- 命令不提供与变化相关的审计跟踪
- 除非是活动的，否则命令不提供记录源
- 不提供创建新对象的模版
命令式对象配置
示例
命令式对象配置中，kubectl 命令指定操作（create，replace 等），可选的参数以及至少一个文件名。这个指定的文件必须以 YAML 或 JSON 的形式包含对象的完整定义。
创建在配置文件中定义的对象：
kubectl create -f nginx.yaml
删除在两个配置文件中定义的对象：
kubectl delete -f nginx.yaml -f redis.yaml
更新配置文件中定义的对象：
kubectl replace -f nginx.yaml
Trade-offs
相对于命令式命令的优点：
- 对象配置可以存储在版本控制系统中
- 对象配置能集成流程，如 push 之前可以查看变化以及审计跟踪
- 提供创建对象的新模版
相对于对象配置的缺点：
- 对象配置需要理解基本的对象模式
- 对象配置需要额外创建 YAML 文件
相对于声明式对象配置的优点：
- 较简单
- 更成熟
相对于声明式对象配置的缺点：
- 命令式对象配置适用于文件，而不是目录
- 活动对象的更新必须反映在配置文件中，否则将在下一个替换后丢失
声明式对象配置
当使用声明式对象配置时，用户在存储在本地的配置文件中进行操作，不定义在文件中的操作。每个对象的创建、删除和更新操作被 kubectl 自动检测。这使得在目录中能够工作，因为不同的对象可能需要不同的操作。
示例
处理所有在 configs 目录中的对象配置文件，创建或修补活动对象。可以先使用 diff来查看将会造成的不同，然后再应用：
kubectl diff -f configs/
kubectl apply -f configs/
递归处理目录：
kubectl diff -R -f configs/
kubectl apply -R -f configs/
Trade-offs
相对于命令式对象配置的优点：
- 对于活动对象直接的改变是被保留的，尽管这些改变没有合并回配置文件
- 声明式对象配置对于目录上的操作以及为每个对象自动检测操作类型（创建，修补和删除）有更好的支持
相对于命令式对象配置的缺点：
- 声明式对象配置更难调试和理解预期之外的结果
- 使用 diff 的部分的更新创建更加符合的合并以及修补操作
命令式命令管理 Kubernetes 对象
创建对象
run：创建一个新的 Deployment 对象，以便在一个或多个 Pod 中运行容器expose：创建一个新的 Service 对象，以便在 Pod 之间对流量进行负载均衡autoscale：创建一个新的 Autoscaler 对象，以便自动水平扩展一个控制器，例如一个 Deployment
kubectl 也支持根据对象类型创建对象：create <object type> [subtype] <instance name>
subtype 包含 ClusterIP，LoadBalancer 和 NodePort
kubectl create service nodeport <my service name>
更新对象
scale：通过更新控制器的副本数量水平扩展一个控制器来增加或移除 Podsannotate：增加或移除一个对象的注解label：增加或移除一个对象的标签
kubectl 也支持由对象的某个方面驱动的更新命令：
set <field>：设置一个对象的某个方面
kubectl 支持这些额外的方式来直接更新活动对象：edit：在编辑器中打开活动对象的配置，直接编辑其原始的配置patch：通过一个 patch 字符串直接修改活动对象的特定字段
删除对象
delete <type>/<name>
kubectl delete deployment/nginx
查看对象
get：打印有关对象的基本信息describe：打印有关对象的汇总详细信息logs：为仍在 Pod 中运行的容器打印 stdout 和 stderr
在创建之前使用 set 命令修改对象
存在一些对象字段，没有在创建命令中可以使用的参数。在一些情况下，可以混合使用 set和 create来在对象创建之前为字段指定值。这个通过将 create 命令的输出以管道输送给 set 命令，然后再输送给 create 命令来实现。例如：
kubectl create service clusterip my-svc --clusterip="None" -o yaml --dry-run | kubectl set selector --local -f - 'environment=qa' -o yaml | kubectl create -f -
kubectl create service -o yaml --dry-run命令为该 Service 创建配置，但是将其以 YAML 打印到 stdout 而不是发送给 Kubernetes API 服务器。kubectl set selector --local -f - -o yaml命令从 stdin 读取配置，并以 YAML 打印更新配置到 stdout。kubectl create -f -命令通过 stdin 提供的配置创建对象。
2 中的 - 即1 中的stdout（输出的 YAML），3 中的- 即2 中的 stdout（输出的YAML）
在创建之前使用 --edit 修改对象
可以使用 kubectl create --edit在对象创建之前进行任意修改。例如：
kubectl create service clusterip my-svc --clusterip='None' -o yaml --dry-run > /tmp/srv.yaml
kubectl create --edit -f /tmp/srv.yaml
kubectl create service命令为该 Service 创建配置并将其保存到/tmp/srv.yaml。kubectl create --edit命令在对象创建之前打开配置以编辑。
使用配置文件命令式管理 Kubernetes 对象
创建对象
kubectl create -f <filename | url>
更新对象
使用
replace命令更新对象会删除配置文件中 spec 未指定的的所有部分。例如，LoadBalancer 类型的 Service，其 externalIPs 字段独立于配置文件管理。单独管理的字段必须复制到配置文件中来防止replace删除它们。
kubectl replace -f <filename | url>
删除对象
kubectl delete -f <filename | url>
查看对象
kubectl get -f <filename | url> -o yaml
-o yaml参数指定打印完整的对象配置。
限制
create，replace，delete命令在每个对象在其配置文件中被完整定义和记录的时候能很好地工作。当一个活动对象被更新的时候，并且更新没有合并到其配置文件中时，更新会在下一个 replace执行的时候丢失。
如果需要对同一个对象支持多个用户，可以使用 kubectl apply来管理对象。
从 URL 创建和编辑对象而不保存配置文件
kubectl create -f <url> --edit
从命令式命令迁移到命令式对象配置
- 导出活动对象到要给本地对象配置文件：
kubectl get <kind>/<name> -o yaml --export > <kind>_<name>.yaml - 从对象配置文件中手动移除 status 字段：
- 使用
replace：
kubectl replace -f <kind>_<name>.yaml
定义控制器选择器和 PodTemplate 标签
强烈反对在控制器上更新选择器
推荐的方法是定义一个单一的、不可变的 PodTemplate 标签供控制器选择器使用。
selector:
matchLabels:
controller-selector: "extensions/v1beta1/deployment/nginx"
template:
metadata:
labels:
controller-selector: "extensions/v1beta1/deployment/nginx"
使用配置文件声明式管理 Kubernetes 对象
此方法保留对活动对象的更改，并不将更改合并到对象配置文件中。
创建对象
使用 kubectl apply创建除了已经存在的对象，创建的这些对象由指定目录中的配置文件定义。
kubectl apply -f <directory>/
这会在每个对象上设置一个注解：kubectl.kubernetes.io/last-applied=configuration: '{...}'。这个注解包含了用于创建对象的配置文件的内容。
添加 -R 参数来递归处理目录
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.7.9
ports:
- containerPort: 80
运行 kubectl diff来打印要创建的对象：
kubectl diff -f https://k8s.io/examples/application/simple_deployment.yaml
使用 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 scale更新 replicas字段：
kubectl scale deployment/nginx-deployment --replicas=2
kubectl get -f https://k8s.io/examples/application/simple_deployment.yaml -o yaml
输出结果中 replicas字段已经被设置为2，但是 last-applied-configuration注解没有包含 replicas字段。
更改配置文件，将 nginx:1.7.9更改为 nginx:1.11.9，删除 minReadySeconds字段。执行 kubectl apply命令，之后打印配置文件信息，可以看到：
replicas字段仍然保留由kubectl scale设置的2。因为这是被配置文件忽略的。image字段已经由nginx:1.7.9更新为nginx:1.11.9。last-applied-configuration注解已使用新镜像更新。minReadySeconds字段已经被清除。last-applied-configuration注解不在包含minReadySeconds字段。
混合使用
kubectl apply和命令式对象配置命令create和replace是不支持的。因为create和replace不保留kubectl.kubernetes.io/last-applied-configuration，这是kubectl apply用于计算更新的。
删除对象
有两种删除由 kubectl apply管理的对象。
推荐的：kubectl delete -f
使用命令式命令手动删除对象是推荐的，因为这更明确要删除什么，并且不太可能导致用户无意删除某些东西。
kubectl delete -f <filename>
查看对象
kubectl get -f <filename | url> -o yaml
计算差异和合并更改
当 kubectl apply更新对象的活动配置的时候，它向 API 服务器发送了一个 patch 请求。Patch 定义更新的范围为活动对象配置的特定字段。kubectl apply命令使用配置文件、活动配置以及存储在活动配置中的 last-applied-configuration注解计算 patch 请求。
合并 patch 计算
kubectl apply命令将配置文件的内容写入 kubectl.kubernetes.io/last-applied-configuration注解中。这个用于标识已经从配置文件中移除以及需要从活动配置中清除的字段。以下是计算哪些字段应该被删除设置的步骤：
- 计算要删除的字段。这些字段出现在
last-applied-configuration并且不在配置文件中。 - 计算要被添加或设置的属性。这些字段出现在配置文件中，但是对应的值和活动配置不匹配。
合并不同类型字段
- primitive：string，integer 或 bool。例如：方式：直接替换。
- map（object）：映射或包含子字段的复杂类型。例如：labels，annotations，spec。方式：合并元素或子字段。
- list：primitive 类型或 map 类型的列表。例如：containers，ports 和 args。方式：改变。
当kubectl apply更新 map 或 list 字段时，通常不会替换整个字段。相反，更新单独的子元素。例如，当合并一个 Deployment 上的 spec 时，整个 spec 不会被替换。replicas 会被计算和合并。
改变管理方法
从命令式命令管理迁移到声明式对象配置管理
- 导出活动对象到一个配置文件：
kubectl get <kind>/<name> -o yaml --export > <kind>_<name>.yaml - 从配置文件手动删除
status字段：
这一步是可选的，因为
kubectl apply不会更新 status 字段，尽管它存在在配置文件中
- 在对象中设置
kubectl.kubernetes.io/last-applied-configuration注解：
kubectl replace --save-config -f <kind>_<name>.yaml - 将流程更改为仅使用
kubectl apply管理对象
从命令式对象配置管理更改到声明式对象配置管理
- 在对象中设置
kubectl.kubernetes.io/last-applied-configuration注解：
kubectl replace --save-config -f <kind>_<name>.yaml - 将流程更改为仅使用
kubectl apply管理对象
定义控制器选择器和 PodTemplate 标签
推荐的方法是定义一个单一的、不变的 PodTemplate 标签，这个标签仅用于控制选择器而没有其他的语义。例如：
selector:
matchLabels:
controller-selector: "extensions/v1beta1/deployment/nginx"
template:
metadata:
labels:
controller-selector: "extensions/v1beta1/deployment/nginx"
