k8s api仅接受及响应json格式的数据，同时，为了便于使用，它也允许用户提供yaml格式的post对象，但apiserver需要事先自行将其转换为json格式后方能提交。每个资源通常仅接受并返回单一类型的数据，而一种类型可以被多个反映特定用例的资源所接受或返回。
1、资源配置清单
资源的创建要通过用户提供的资源配置清单来进行，其格式类似于kubectl get命令获取到的yaml或json形式的输出结果。不过status字段对用户来说为只读字段，它由k8s集群自动维护
对几乎所有的资源来说，apiVersion、lind、metadata字段的功能基本都是相同的，但spec则用于资源的期望状态，而资源之所以存在类型上的不同，也在一它们的嵌套属性存在显著差别，它由用户定义和维护。而status字段则用于记录活动对象的当前状态。它要与用户在spec中定义的期望状态相同或正处于转换为与其相同的过程中。
2、metadata嵌套字段
metadata用于描述对象的属性信息，其内嵌多个字段用于定义资源的元数据，这些字段可分为必要字段和可选字段。对于用户未明确定义的嵌套字段，则需要由一系列的finalizer组件自动予以填充。而用户需要对资源创建的目标资源对象进行强制校验，或者在修改时需要用到initializer组件完成。
3、sepc和status字段
spec用来描述所期望的对象应该具有的状态，而用status字段来记录对象在系统上的当前状态，因此status字段仅对活动对象才有意义，用户不能手动定义。
4、资源对象管理方式
apiserver遵循声明式编程范式而设计，侧重于构建程序逻辑而无须用户描述其实现流程，用户只需设定期望状态，系统自行确定需要执行的操作以确保达到用户期望状态。k8s的自愈、自治等功能都依赖于其声明式机制。
另一种范式称为陈述式编程，侧重于通过创建一种告诉计算机如何执行操作的算法来更改程序状态的语句来完成，它与硬件的工作方式密切相关。它直接通过命令（run、expose、delete、get等）及其选项完成对象的管理操作。
kubectl的命令由此可以分为三类：陈述式命令、陈述式对象配置和声明式对象配置。
声明式对象配置并不直接指名要进行的对象管理操作，而是提供配置清单文件给k8s系统，并委托系统跟踪活动对象的状态变动。资源对象的创建、删除及修改操作全部通过唯一的命令apply来完成，并且每次操作时，提供给命令的配置信息都将保存于对象的注解信息中，并通过对比检查活动对象的当前信息、注解中的配置信息及资源清单中的配置信息三方进行变更合并，从而实现仅修改变动字段的高级补丁机制。
陈述式对象配置相较于声明式对象配置来说，其缺点在于同一目录下的配置文件必须同时进行同一种操作，例如，要么都创建，要么都更新等。而且其他用户的更新也必须反映在配置文件中，不然其更新在下一次的更新中将会被覆盖。因此，声明式对象配置是优先推荐使用的管理机制。