k3s完全兼容k8s，我解释一下是为什么：
因为k3s的底层数据结构（写入etcd/mysql/sqlite/dsqlite数据库的格式），是完全照搬k8s的数据结构。api完全兼容。 对外表现相同，底层数据相同，只是实现方式不同（举个例子： 一个爆炒大虾，一个油焖虾）。
我认为 k3s/k8s数据结构的3个用途：
- 缓存从api中解析出来的参数，为了后面的处理逻辑更方便的去引用api的参数。
- 方便响应api时，用marshal() 去生成json/protobuf序列化的数据
- 方便写入数据库(etcd/mysql/sqlite)时，序列化为有序数据块
在k3s/k8s中，deploy、pod、service、Ingress、namespace、configmap等被成为资源。
yaml文件在定义一组(多组)资源的规格/约束条件的集合。
1 资源类型：
type TypeMeta struct {
// rest api操作的资源类型：deployment/pod/servce/ingress/ns/pv/pvc
Kind string `json:"kind,omitempty" protobuf:"bytes,1,opt,name=kind"`
// APIVersion defines the versioned schema of this representation of an object.
// Servers should convert recognized schemas to the latest internal value, and
// may reject unrecognized values.
APIVersion string `json:"apiVersion,omitempty" protobuf:"bytes,2,opt,name=apiVersion"`
}
2 资源元数据：
资源元数据：与api相关、与调度器相关、与数据库相关。 什么叫相关？ 直白点说：就是被读写
type ObjectMeta struct {
// 在一个命名空间范围中，资源的名字(pod-https、pod-http、pod-web、sevice-reds、confiigmap-secrets-web)。 例如某个村里面(命名空间)不允许人重名，张三、李四
Name string `json:"name,omitempty" protobuf:"bytes,1,opt,name=name"`
// 在创建yaml文件时，可以指定资源名称、也可以不指定资源名称（不指定时则 用资源类型-随机字符拼接，例如pod-nx7jsda，service-hlayjk0a）,此变量就是k3s/k8s生成的默认资源名称
GenerateName string `json:"generateName,omitempty" protobuf:"bytes,2,opt,name=generateName"`
// 命名空间名称，例如default、filecoin、ingress-nginx。在同一个命名空间内，所有资源可互相感知存在。 在不同命名空间中，资源之间不能直接感知到其它命名空间的资源。
Namespace string `json:"namespace,omitempty" protobuf:"bytes,3,opt,name=namespace"`
// url地址，client可以通过访问此地址，来只读到资源的内容。 对应另外一个命令是读写，kubectl edit pod pod-name
// k3s/k8s在1.21 release会删除此变量（因为有读写api、(历史原因存在的)只读api显得很鸡肋），无视它即可。
SelfLink string `json:"selfLink,omitempty" protobuf:"bytes,4,opt,name=selfLink"`
// k8s server在最终成功创建了资源后，会生成一个uuid给这资源，生成后，在资源的整个生命周期中不允许被修改。 （你可以理解为是身份证编号）
UID types.UID `json:"uid,omitempty" protobuf:"bytes,5,opt,name=uid,casttype=k8s.io/kubernetes/pkg/types.UID"`
// k3s/k8s 兼容多个api版本，即http/https rest api接口存在多个版本的路由，和多个版本对应的参数逻辑解析程序段
// apiVersion: v1
// apiVersion: v2
// apps/v1beta1
ResourceVersion string `json:"resourceVersion,omitempty" protobuf:"bytes,6,opt,name=resourceVersion"`
// 流水号
Generation int64 `json:"generation,omitempty" protobuf:"varint,7,opt,name=generation"`
// 资源被创建时的时间戳
CreationTimestamp Time `json:"creationTimestamp,omitempty" protobuf:"bytes,8,opt,name=creationTimestamp"`
// 资源被删除时的时间戳，例如kubectl delete pods pod-name 命令被执行到时的时间戳
DeletionTimestamp *Time `json:"deletionTimestamp,omitempty" protobuf:"bytes,9,opt,name=deletionTimestamp"`
// 资源被删除时的宽限(给资源发让其退出的信号，等待资源关闭相关的系统资源后退出)时间（单位：秒），超过宽限时间则k3s/k8s会主动杀死资源
DeletionGracePeriodSeconds *int64 `json:"deletionGracePeriodSeconds,omitempty" protobuf:"varint,10,opt,name=deletionGracePeriodSeconds"`
// 给资源打标签： kubectl label node cka-node disktype=gpu
// 查看资源标签： kubectl get node --show-labels
// 标签用途：用于更精细的去调度资源到指定的node，是k3/k8s为运维通讯提供的(管理/调度)扩展功能
Labels map[string]string `json:"labels,omitempty" protobuf:"bytes,11,rep,name=labels"`
// 注解：
//Annotations 允许在 Kubernetes 资源上附加任意的非标识性元数据，用来记录资源的一些属性。这些元数据主要是给工具或者库来提取信息，一般不会直接开放给用户。绝大多数基于 Kubernetes 的开源项目都不依赖于 DB，完全可以利用 Kubernetes 的能力，满足对 DB 的需求。对于需要持久化的数据，除了定义 CRD，另一种通用的做法就是将数据存储在 annotation 中。
//由于 annotation 的定位是 Kubernetes 资源上附加任意的非标识性元数据，除了在 key 上有跟 label key 完全一样的限制外，在 value 上没有任何限制：可长可短，可结构化可非结构化，可包含任意字符。
Annotations map[string]string `json:"annotations,omitempty" protobuf:"bytes,12,rep,name=annotations"`
// 包含足够的信息来让你确定一个对象，举个例子：你妈妈喊你吃饭时叫你小名：小张、狗子，你就知道是在叫你，而不用叫你的全名：张三丰、赵二狗
OwnerReferences []OwnerReference `json:"ownerReferences,omitempty" patchStrategy:"merge" patchMergeKey:"uid" protobuf:"bytes,13,rep,name=ownerReferences"`
// 资源在被删除之后，会写一个记录在这里切片中
Finalizers []string `json:"finalizers,omitempty" patchStrategy:"merge" protobuf:"bytes,14,rep,name=finalizers"`
// 资源属于的集群的名称。例如：易春雷老师(资源)是第二初级中学（集群名称）的优秀班主任，
ClusterName string `json:"clusterName,omitempty" protobuf:"bytes,15,opt,name=clusterName"`
//
ManagedFields []ManagedFieldsEntry `json:"managedFields,omitempty" protobuf:"bytes,17,rep,name=managedFields"`
}
type ManagedFieldsEntry struct {
// Manager is an identifier of the workflow managing these fields.
Manager string `json:"manager,omitempty" protobuf:"bytes,1,opt,name=manager"`
// Operation is the type of operation which lead to this ManagedFieldsEntry being created.
// The only valid values for this field are 'Apply' and 'Update'.
Operation ManagedFieldsOperationType `json:"operation,omitempty" protobuf:"bytes,2,opt,name=operation,casttype=ManagedFieldsOperationType"`
// APIVersion defines the version of this resource that this field set
// applies to. The format is "group/version" just like the top-level
// APIVersion field. It is necessary to track the version of a field
// set because it cannot be automatically converted.
APIVersion string `json:"apiVersion,omitempty" protobuf:"bytes,3,opt,name=apiVersion"`
// Time is timestamp of when these fields were set. It should always be empty if Operation is 'Apply'
// +optional
Time *Time `json:"time,omitempty" protobuf:"bytes,4,opt,name=time"`
// Fields is tombstoned to show why 5 is a reserved protobuf tag.
//Fields *Fields `json:"fields,omitempty" protobuf:"bytes,5,opt,name=fields,casttype=Fields"`
// FieldsType is the discriminator for the different fields format and version.
// There is currently only one possible value: "FieldsV1"
FieldsType string `json:"fieldsType,omitempty" protobuf:"bytes,6,opt,name=fieldsType"`
// FieldsV1 holds the first JSON version format as described in the "FieldsV1" type.
// +optional
FieldsV1 *FieldsV1 `json:"fieldsV1,omitempty" protobuf:"bytes,7,opt,name=fieldsV1"`
// Subresource is the name of the subresource used to update that object, or
// empty string if the object was updated through the main resource. The
// value of this field is used to distinguish between managers, even if they
// share the same name. For example, a status update will be distinct from a
// regular update using the same manager name.
// Note that the APIVersion field is not related to the Subresource field and
// it always corresponds to the version of the main resource.
Subresource string `json:"subresource,omitempty" protobuf:"bytes,8,opt,name=subresource"`
}
先写到这里，晚点补充其它数据结构。
