测试环境
- host集群(aliyun ACK, 2 nodes, kubesphere v3.0.0)
- 一个member集群(aliyun ACK, 11 nodes, kubesphere v3.0.0)
升级目的
目前生产环境host以及member集群ks版本均为v3.0.0，为了接入边缘节点，故需将ks升级至v3.1.1。
问题描述
host集群从3.0.0升级至3.1.1之后，进入host集群管理页面，查看kubesphere版本为v3.1.1-dirty，如下图所示:
本以为dirty字段是因为member还未从v3.0.0升级至v3.1.1所致，接下来按照相同步骤升级member集群，升完级之后发现，host集群与member集群下所展示的ks版本均为v3.1.1-dirty，网上查询资料没有相关描述，有人知道v3.1.1-dirty代表的含义吗？
host升级之后点击具体应用查看状态时，无法查看服务资源和工作负载资源，这个需要怎样修复？
3.1 目前通过阅读ks代码以及ks web的请求url分析得出，拉取具体应用的服务资源请求URL为: http://{ip}/api/clusters/{cluster}/v1/namespaces/{namespace}/services?labelSelector=app.kubesphere.io/instance=xxx，拉取具体工作负载资源的请求URL为: http://{ip}/apis/clusters/{cluster}/apps/v1/namespaces/{namespace}/deployments?labelSelector=app.kubesphere.io/instance=xxx
3.2 通过使用kubectl get deployments.apps -n {namespace}以及kubectl get service -n {namespace}发现该应用对应的服务资源以及工作负载存在。
3.3 通过使用kubectl edit deployments.apps {deployment_name} -n {namespace}，kubectl edit service {service_name} -n {namespace}查看配置文件内容，发现metadata.labels内容中缺少请求URL query参数的app.kubesphere.io/instance标签。
{
"metadata": {
"name": "xxx",
"namespace": "xxx",
"selfLink": "/api/v1/namespaces/{namespace}/services/xxx",
"uid": "xxx",
"resourceVersion": "253502458",
"creationTimestamp": "2021-09-23T07:36:15Z",
"labels": {
"app.kubernetes.io/instance": "xxxx",
"app.kubernetes.io/managed-by": "Helm",
"app.kubernetes.io/name": "xxxx",
"app.kubernetes.io/version": "0.0.5",
"helm.sh/chart": "xxx-0.0.5_001"
}
}
}
3.4 通过3.3命令手动添加app.kubesphere.io/instance标签，即可在ks查看具体应用对应的服务资源以及工作负载
目前该解决方案在测试环境下进行，想了解这个问题是升级ks操作不当导致还是ksv3.1.1程序bug导致。同时发现v3.1.1的ks查看具体一个应用信息时，会拉取ingresses(GET请求)、services(GET请求)、deployments(GET请求)、statefulsets(GET请求)、daemonsets(GET)以及persistentvolumeclaims(GET)资源，如果在生产环境手动增加app.kubesphere.io/instance标签风险较大。
