作者：周虚（应金挺）
SREWorks的开源吸引了大量用户来尝试部署和使用我们的产品，其中不乏一些初次接触Kubernetes的朋友。随着SREWorks云原生运维平台使用的持续深入，部分用户对于其中的原理和概念还存在一些困惑。因此，我们特推出《Kubernetes资源编排系列》，从底层的Pod YAML开始，逐步递进地讲解相关内容，希望能够解答大家对于Kubernetes的一些疑问，让用户对于云原生相关技术有更深入的了解。
一、 Pod整体结构
Pod YAML的整体结构，可以初步分为Resource（资源）、Object（元数据）、Spec（规范）、Status（状态）。本文将会围绕这四部分一一展开。
• Resource：定义资源类型与版本，作为从Rest API中获取资源必带的属性。
• Object：资源的元数据属性，明确资源的基本标识。
• Spec/Status：
｡ Spec：定义资源的期望状态，包括用户提供的配置、系统扩展的默认值，以及周边系统初始化或者更改值（scheduler、hpa等）。
｡ Status：定义资源的当前状态，从而基于Spec定义的申明式配置，使pod不断朝期望状态靠近。
二、 Resource（资源）-Rest API
k8s资源按照Scope可以分为Namespace资源、Cluster资源，Namespace在k8s可以认为是软租户的效果，实现资源层面的隔离，Pod资源就是属于Namespace资源，而Namespace不光体现在YAML参数中，也表现在k8s Rest API中。
Rest API的整体结构，以Pod举例：
apiVersion: v1 kind: Pod metadata: name: test-pod namespace: default
|
基于上述YAML，可以明确出namespace为default，name为test-pod的Pod资源对象，也就是明确出Pod为Namespace资源，该Pod资源对象对应的apiVersion为v1，后续k8s自内联相关的Group为/API，自然而然，我们就将该对象的数据分离出来了：
• group：API
• apiVersion：v1
• kind：Pod
• name：test-pod
• namespace：default
基于上述的数据展示，apiserver自然而然会相应的注册出下列Rest API。
• /api/{apiVersion}/{kind}：该kind下的所有资源列表。
• /api/{apiVersion}/namespace/{namespace}/{kind}/：该kind下当前namespace的所有资源列表。
• /api/{apiVersion}/namespace/{namespace}/{kind}/{name}：该kind下当前namespace且名为name的资源。
• /api/{apiVersion}/namespace/{namespace}/{kind}/{name}/{subresource}：该kind下当前namespace且名为name的资源下子资源操作。
后续基于扩展，我们就需要明确出method，这样一个真正完整的Rest API就诞生了。
