Kubernetes对象深入学习之五：TypeMeta无效之谜-Toy模板网

这篇具有很好参考价值的文章主要介绍了Kubernetes对象深入学习之五：TypeMeta无效之谜。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

欢迎访问我的GitHub

这里分类和汇总了欣宸的全部原创(含配套源码)：https://github.com/zq2599/blog_demos

本篇概览

本文是《Kubernetes对象深入学习之五》系列的第五篇，从前文的分析也能看出，代表对象类型的schema.ObjectKind，于对象而言是至关重要的，那是它的类型和身份，既然如此，与之有关的问题也不能放过，因此本篇就来看一个对象类型相关的问题，本文由以下内容组成：

复现问题：我的代码中获取的对象类型为空
问题原因
为什么会有这个问题？
这个问题有解吗？

复现问题

问题很容易复现，回顾《Kubernetes对象深入学习之四：对象属性编码实战》的代码，controller.go有下面这么一段代码，作用是在controller监听到对象变化时，将对象的ObjectMeta内容在控制台打印出来，现在咱们在黄色箭头前面添加两端代码
新增的代码是下面这些，先用现成的方法做一次提取，得到Kind和APIVersion，再尝试直接转换成objectruntime.Object类型获取GVK

// 第一次尝试：通过公共方法转为Type接口
objType, err := meta.TypeAccessor(obj)
if err != nil {
	klog.Errorf("TypeAccessor [%s], failed with %v", key, err)
	return err
}

fmt.Printf("** 通过公共方法获取Kind, kind [%s], version [%s]\n", objType.GetKind(), objType.GetAPIVersion())

// 第二次尝试：亲自尝试强转
runtimeObj, _ := obj.(objectruntime.Object)
fmt.Printf("** 强转获取Kind: %v\n", runtimeObj.GetObjectKind().GroupVersionKind())

修改后整体效果如下，黄框中是本次新增内容
程序启动后，打印日志如下，可见不论是哪种方式，kind和version的值都是空

I0827 01:15:58.890491 2945049 controller.go:144] Starting Pod controller
** 通过公共方法获取Kind, kind [], version []
** 强转获取Kind: /, Kind=
** 通过公共方法获取Kind, kind [], version []
** 强转获取Kind: /, Kind=
** 通过公共方法获取Kind, kind [], version []
** 强转获取Kind: /, Kind=

好了，现在问题已复现：TypeMeta内容为空，接下来去寻找问题原因

问题原因

咱们按照顺序捋一下代码，在main.go中调用了CreateAndStartController来创建controller，此时指定了类型是&v1.Pod{}
在CreateAndStartController方法内会调用NewListWatchFromClient来创建ListWatcher，指定了resource就是刚才传入的pods
继续展开，就看到了关键代码NewFilteredListWatchFromClient方法，这里指出了list操作的具体实现，该方法其余代码略去不看了：文章来源地址https://www.toymoban.com/news/detail-677992.html

func NewFilteredListWatchFromClient(c Getter, resource string, namespace string, optionsModifier func(options *metav1.ListOptions)) *ListWatch {
	listFunc := func(options metav1.ListOptions) (runtime.Object, error) {
		optionsModifier(&options)
		return c.Get().
			Namespace(namespace).
			Resource(resource).
			VersionedParams(&options, metav1.ParameterCodec).
			Do(context.TODO()).
			Get()
	}
	
	// 剩余的代码省略不看
	...
}

注意，重点来了，先展开上面的Do方法，这里面发起了远程请求，获取资源列表，并且指定transformResponse方法用来处理收到的响应

func (r *Request) Do(ctx context.Context) Result {
	var result Result
	err := r.request(ctx, func(req *http.Request, resp *http.Response) {
		result = r.transformResponse(resp, req)
	})
	if err != nil {
		return Result{err: err}
	}
	return result
}

这个transformResponse方法的代码太多，我们只关注重点，就是这个decoder对象，记住这个decoder
看完了Do方法，再来看Get方法，关键代码是黄色箭头指出的部分：使用decoder对响应的body进行处理
再来看这个Decode方法的内容（apimachinery@v0.22.8/pkg/runtime/helper.go），很明显，这里故意调用了SetGroupVersionKind方法，入参是个新的GroupVersionKind对象，如此一来，所有类型有关的信息就被清除了

// Decode does not do conversion. It removes the gvk during deserialization.
func (d WithoutVersionDecoder) Decode(data []byte, defaults *schema.GroupVersionKind, into Object) (Object, *schema.GroupVersionKind, error) {
	obj, gvk, err := d.Decoder.Decode(data, defaults, into)
	if obj != nil {
		kind := obj.GetObjectKind()
		// clearing the gvk is just a convention of a codec
		kind.SetGroupVersionKind(schema.GroupVersionKind{})
	}
	return obj, gvk, err
}

至此，真相大白，kubernetes官方在处理api-server的响应内容时，刻意将TypeMeta清理掉了

为什么会有这个问题？

对于这么做的原因，首先是个人猜测，回到main.go，如下图，作为使用方，既然已经明确了要监听的资源是pod，那么得到的结果自然就只能是v1.Pod了，所以无需再从结果中获取类型，
至于根本原因，由于欣宸英语水平太差，未能从一群老外的讨论中得到明确答案，下面是和这个问题相关的pr和issue，可见抱有相同疑惑的人着实不少，并且这个问题已经持续多年，并且一直没有解决：
https://github.com/kubernetes/kubernetes/pull/59264#issuecomment-362579495
https://github.com/kubernetes/client-go/issues/541
https://github.com/kubernetes/client-go/issues/861
https://github.com/kubernetes/kubernetes/issues/80609

这个问题可以解决吗？

老外有个建议，就是用DoRaw方法得到api-server响应的原始body，然后自己做反序列化，我这里试了下
日志打印出原始body内容如下，太长了只截取部分

raw : {"kind":"PodList","apiVersion":"v1","metadata":{"resourceVersion":"12435998"},"items":[{"metadata":{"name":"nginx-deployment-78f6b696d9-cr47w","generateName":"nginx-deployment-78f6b696d9-","namespace":"client-go-tutorials","uid":"645628af-0d20-4548-b15d-0faf9e03b733","resourceVersion":"12227486","creationTimestamp":"2023-08-13T11:15:59Z","labels":{"app":"nginx-app","business-service-type":"web","language":"c","pod-template-hash":"78f6b696d9","service-update-time":"20230813120623","type":"front-end"},"annotations":{"cni.projectcalico.org/containerID":"e94b7b0ebe60d1cada361f7a672b2c6df71f2d89c4b5c1ae4056f82dec6a78db","cni.projectcalico.org/podIP":"100.91.64.45/32","cni.projectcalico.org/podIPs":"100.91.64.45/32"},"ownerReferences":[{"apiVersion":"apps/v1","kind":"ReplicaSet","name":"nginx-deployment-78f6b696d9","uid":"642c39e7-814a-491f-9b4f-295f34e959a3","controller":true,"blockOwnerDeletion":true}],"managedFields":[{"manager":"kube-controller-manager","operation":"Update","apiVersion":"v1","time":"2023-08-13T11:15:59Z","fieldsType":"FieldsV1","fieldsV1":{"f:metadata":{"f:generateName":{},"f:labels":{".":{},"f:app":{},"f:business-service-type":{},"f:language":{},"f:pod-template-hash":{},"f:type":{}},"f:ownerReferences":{".":{},"k:{\"uid\":\"642c39e7-814a-491f-9b4f-295f34e959a3\"}":{}}},"f:spec":{"f:containers":{"k:{\"name\":\"nginx-container\"}":{".":{},"f:image":{},"f:imagePullPolicy":{},"f:name":{},"f:resources":{".":{},"f:limits":{".":{},"f:cpu":{},"f:memory":{}},"f:requests":{".":{},"f:cpu":{},"f:memory":{}}},"f:terminationMessagePath":{},"f:terminationMessagePolicy":{}}},"f:dnsPolicy":{},"f:enableServiceLinks":{},"f:restartPolicy":{},"f:schedulerName":{},"f:securityContext":{},"f:terminationGracePeriodSeconds":{}}}},
...
..
.

拿到这样的json内容后，去工具网站转为go的数据结构代码，这样就能在代码中完成反序列化，例如：https://zxjson.com/json2go/，如下图，转为go的数据接口
如此一来，跌跌撞撞的拿到了完整的json对象，当然了，这并不是个好的办法
至此ypeMeta无效之谜已经解开，如果您有更好的解法或者更多官方消息，欢迎留言，感谢您的帮助