likes
comments
collection
share

Kubernetes对象深入学习之五：TypeMeta无效之谜

作者站长头像
站长
· 阅读数 17

欢迎访问我的GitHub

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

本篇概览

  • 本文是《Kubernetes对象深入学习之五》系列的第五篇，从前文的分析也能看出，代表对象类型的schema.ObjectKind，于对象而言是至关重要的，那是它的类型和身份，既然如此，与之有关的问题也不能放过，因此本篇就来看一个对象类型相关的问题，本文由以下内容组成：
  1. 复现问题：我的代码中获取的对象类型为空
  2. 问题原因
  3. 为什么会有这个问题？
  4. 这个问题有解吗？

复现问题

  • 问题很容易复现，回顾《Kubernetes对象深入学习之四：对象属性编码实战》的代码，controller.go有下面这么一段代码，作用是在controller监听到对象变化时，将对象的ObjectMeta内容在控制台打印出来，现在咱们在黄色箭头前面添加两端代码 Kubernetes对象深入学习之五：TypeMeta无效之谜
  • 新增的代码是下面这些，先用现成的方法做一次提取，得到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())
  • 修改后整体效果如下，黄框中是本次新增内容 Kubernetes对象深入学习之五：TypeMeta无效之谜
  • 程序启动后，打印日志如下，可见不论是哪种方式，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{} Kubernetes对象深入学习之五：TypeMeta无效之谜

  • 在CreateAndStartController方法内会调用NewListWatchFromClient来创建ListWatcher，指定了resource就是刚才传入的pods Kubernetes对象深入学习之五：TypeMeta无效之谜

  • 继续展开，就看到了关键代码NewFilteredListWatchFromClient方法，这里指出了list操作的具体实现，该方法其余代码略去不看了：

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 Kubernetes对象深入学习之五：TypeMeta无效之谜
  • 看完了Do方法，再来看Get方法，关键代码是黄色箭头指出的部分：使用decoder对响应的body进行处理 Kubernetes对象深入学习之五：TypeMeta无效之谜
  • 再来看这个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了，所以无需再从结果中获取类型， Kubernetes对象深入学习之五：TypeMeta无效之谜
  • 至于根本原因，由于欣宸英语水平太差，未能从一群老外的讨论中得到明确答案，下面是和这个问题相关的pr和issue，可见抱有相同疑惑的人着实不少，并且这个问题已经持续多年，并且一直没有解决：
  • github.com/kubernetes/…
  • github.com/kubernetes/…
  • github.com/kubernetes/…
  • github.com/kubernetes/…

这个问题可以解决吗？

  • 老外有个建议，就是用DoRaw方法得到api-server响应的原始body，然后自己做反序列化，我这里试了下 Kubernetes对象深入学习之五：TypeMeta无效之谜
  • 日志打印出原始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的数据结构代码，这样就能在代码中完成反序列化，例如：zxjson.com/json2go/， 如下图，转为go的数据接口 Kubernetes对象深入学习之五：TypeMeta无效之谜
  • 如此一来，跌跌撞撞的拿到了完整的json对象，当然了，这并不是个好的办法
  • 至此ypeMeta无效之谜已经解开，如果您有更好的解法或者更多官方消息，欢迎留言，感谢您的帮助

欢迎关注头条号：程序员欣宸

  • 学习路上，你不孤单，欣宸原创一路相伴...