在面向对象编程的思想里面，万物皆对象，k8s世界中，一个pod也好，一个ds控制器也好，他们都是对象，对象就要有对象的描述文件，k8s中是使用yml描述一个对象的，那么从yml开始分析一下相关的内容

一份简单的yml清单分析

apiVersion: v1
kind: Pod
metadata:
  name: nginx-demo
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80

配置文件解析

• apiVersion - 创建该对象所使用的 Kubernetes API 的版本
• kind - 想要创建的对象的类别
• metadata - 帮助唯一标识对象的一些数据，包括一个 name 字符串、UID 和可选的 namespace
• spec - 你所期望的该对象的状态，对每个 Kubernetes 对象而言，其 spec 之精确格式都是不同的，包含了特定于该对象的嵌套字段。 我们能在 Kubernetes API 参考 找到我们想要在 Kubernetes 上创建的任何对象的规约格式。其中spec字段必须提供
  https://kubernetes.io/zh-cn/docs/reference/kubernetes-api/

该配置文件清晰的表述出来如下内容

• 哪些容器化应用正在运行（以及在哪些节点上运行）
• 可以被应用使用的资源（端口、镜像等）
  由此可见，一份清单中最重要的就是 spec（规约）

对象规约（Spec）与状态（Status）

几乎每个 Kubernetes 对象包含两个嵌套的对象字段，它们负责管理对象的配置： 对象 spec（规约） 和 对象 status（状态）。 对于具有 spec 的对象，你必须在创建对象时设置其内容，描述你希望对象所具有的特征： 期望状态（Desired State）。

status 描述了对象的当前状态（Current State），它是由 Kubernetes 系统和组件设置并更新的。 在任何时刻，Kubernetes 控制平面都一直都在积极地管理着对象的实际状态，以使之达成期望状态。也就是说，如果你的容器此时出现问题，控制平面可能会不断的调整该容器（比如重启、调度到其他节点等），直到达成期望状态为止。

例如，Kubernetes 中的 Deployment 对象能够表示运行在集群中的应用。 当创建 Deployment 时，可能会去设置 Deployment 的 spec，以指定该应用要有 3 个副本运行。 Kubernetes 系统读取 Deployment 的 spec， 并启动我们所期望的应用的 3 个实例 —— 更新状态以与规约相匹配。 如果这些实例中有的失败了（一种状态变更），Kubernetes 系统会通过执行修正操作来响应 spec 和状态间的不一致 —— 意味着它会启动一个新的实例来替换。

对yml的一些理解

我记得业界有一个二八原则，20%的代码为主代码，80%的代码为辅助代码，我个人认为在k8s的配置文件中，也适用该原则，少数的几个配置项，就足够运行起来一个简单的容器，（虽然他可能不是那么的健壮），有可能没有健康检查机制等相关操作，也有可能没有HPA相关高可用的解决方案，但是，这是一切的起点，用来学习还是很不错的，言归正传，推荐一个阿里云官方的pod解析。大佬写的比我全面很多

Kubernetes 资源编排系列之一: Pod YAML 篇