前言
上文【从入门到放弃-Kubernetes】Kubernetes入门-应用部署中，我们学习了如何通过命令行部署应用，本文我们学习如果通过yaml配置文件进行应用部署，并进行应用的扩缩容。
Kubernetes 对象
Kubernetes 对象 是持久化的实体。Kubernetes 使用这些实体去表示整个集群的状态。
描述了如下信息：
- 哪些容器化应用在运行（以及在哪个 Node 上）
- 可以被应用使用的资源
- 关于应用运行时表现的策略，比如重启策略、升级策略，以及容错策略
一但对象被创建，k8s集群就会开始持续工作以保证对象符合期望状态。
对象规约（Spec）与状态（Status）
每个 Kubernetes 对象包含两个嵌套的对象字段，它们负责管理对象的配置：对象 spec 和 对象 status 。 spec 是必需的，它描述了对象的 期望状态（Desired State） —— 希望对象所具有的特征。 status 描述了对象的 实际状态（Actual State） ，它是由 Kubernetes 系统提供和更新的。在任何时刻，Kubernetes 控制面一直努力地管理着对象的实际状态以与期望状态相匹配。
描述 Kubernetes 对象
一般使用yaml来描述一个k8s对象，yaml是专门用来写配置的语言。
基本语法规则如下：
- 大小写敏感
- 使用缩进表示层级关系
- 缩进不允许使用tab，只允许空格
- 缩进的空格数不重要，只要相同层级的元素左对齐即可
- '#'表示注释
使用yaml描述k8s对象，需要以下必需字段：
- apiVersion - 创建该对象所使用的 Kubernetes API 的版本
- kind - 想要创建的对象的类型
- metadata - 帮助识别对象唯一性的数据，包括一个 name 字符串、UID 和可选的 namespace
- spec - 描述了对象的 期望状态（Desired State），k8s集群会持续保证对象符合描述的状态。
管理 Kubernetes 对象
管理k8s对象有三种方式
命令式命令（Imperative commands）
就是我们上文中使用的方式，在命令行直接操作。
如：
kubectl create deployment nginx --image nginx与对象配置相比的优点：
- 命令简单，易学且易于记忆。
- 命令仅需一步即可对集群进行更改。
与对象配置相比的缺点：
- 命令不与变更审查流程集成。
- 命令不提供与更改关联的审核跟踪。
- 除了实时内容外，命令不提供记录源。
- 命令不提供用于创建新对象的模板。
命令式对象配置（Imperative object configuration）
需要操作指令和配置文件配合使用。
如：
kubectl create -f nginx.yaml与命令式命令相比的优点：
- 对象配置可以存储在源控制系统中，比如 Git。
- 对象配置可以与流程集成，例如在推送和审计之前检查更新。
- 对象配置提供了用于创建新对象的模板。
与命令式命令相比的缺点：
- 对象配置需要对对象架构有基本的了解。
- 对象配置需要额外的步骤来编写 YAML 文件。
与声明式对象配置相比的优点：
- 命令式对象配置行为更加简单易懂。
- 从 Kubernetes 1.5 版本开始，命令式对象配置更加成熟。
与声明式对象配置相比的缺点：
- 命令式对象配置更适合文件，而非目录。
- 对活动对象的更新必须反映在配置文件中，否则会在下一次替换时丢失。
声明式对象配置（Declarative object configuration）
使用声明式对象配置，不需要在命令中显示的指定操作，这样可以将配置文件放在目录中，对目录中的文件进行不同的操作。
比如：
kubectl apply -f configs/与命令式对象配置相比的优点：
- 对活动对象所做的更改即使未合并到配置文件中，也会被保留下来。
- 声明性对象配置更好地支持对目录进行操作并自动检测每个文件的操作类型（创建，修补，删除）。
与命令式对象配置相比的缺点：
- 声明式对象配置难于调试并且出现异常时结果难以理解。
- 使用 diff 产生的部分更新会创建复杂的合并和补丁操作。
实践操作
创建Deployment
创建node-deployment.yaml文件
apiVersion: apps/v1
kind: Deployment
metadata:
name: node-deployment
labels:
app: node
spec:
replicas: 3
selector:
matchLabels:
app: node
template:
metadata:
labels:
app: node
spec:
containers:
- name: node
image: registry.cn-hangzhou.aliyuncs.com/larswang/hello-node:1.0
ports:
- containerPort: 80创建
kubectl apply -f node-deployment.yaml查看deployments
kubectl get deployments
查看pods
kubectl get pods --show-labels
缩放Deployment
扩容到十个副本
kubectl scale deployment.v1.apps/node-deployment --replicas=10扩展完成查看deployments和pods情况
kubectl get deployments
kubectl get pods --show-labels
缩容到三个副本
kubectl scale deployment.v1.apps/node-deployment --replicas=3此时可以看到 其中7个pod处于Terminating状态。一段时间后，再次查看，只剩下了3个正在running的pod。
自动恢复
先查看pods列表
kubectl get pods --show-labels选中其中一个pod并删除
kubectl delete pod node-deployment-57df45c5bf-d8xst等删除成功后，再次查看pods列表
kubectl get pods --show-labels
会发现被删除的pod已经不存在了，但是Deployment又创建了一个新的pod。
这就是k8s会始终尽量保证集群的运行状态和配置描述的状态保持一致的特性。
获取Deployment描述信息
kubectl describe deployment node-deployment
可以看到Deployment的当前描述，及pod历史变化情况。
NewReplicaSet：
- 当第一次创建 Deployment 时，它创建了一个 ReplicaSet （node-deployment-57df45c5bf） 并创建了3个副本。
Events：
- 先扩容到了10个pods
- 缩容到了3个pods
- 缩容到了1个pods
- 扩容到了3个pods
查看Deployment状态
kubectl get deployment node-deployment -o yaml以yaml格式展示Deployment的配置情况及当前状态
总结
本文我们介绍了什么是k8s对象，以及使用yaml配置，创建了一个Deployment。
通过scale对Deployment进行缩放，并演示了手动删除一个pod后，k8s根据描述保持运行态与描述一致的特性。
在操作完一遍之后，回过头再看概念，会有种茅塞顿开的感觉。
文中的配置文件可以在AloofJr中找到。
更多文章
见我的博客：https://nc2era.com
written by AloofJr，转载请注明出处
