组件名称没有长度限制，导致组件可能无法启动

[poneding]

遇到组件启动失败的情况，但是启动日志本身没有暴露启动失败信息。

查看rbd-worker日志发现，实际的情况是k8s中容器名称字符长度要求不能超过63，否则，k8s资源验证不通过，组件就无法启动。 分三种情况：

1. 组件名称本身没有长度限制，如果超过63位，那么组件容器名称（直接使用了组件名称）不符合要求；
2. 组件名称过长，插件容器名称又额外添加了前缀：“default-tcpmesh-”，“probe-mesh-”导致容器名称长度超出，不符合要求；

[yangkaa]

目前我想大概有以下两处需要处理：

1. 限制应用和组件名称不超过 32 位
2. 快速复制，每次复制时，会在组件后面加上后缀 -copy，复制多次时可能也无法启动

[poneding]

代码中有三个地方会导致这个问题：

是不是写一个截断函数比较好？

[yangkaa]

写一个截断函数确实能保证组件一定可以启动，但是前端应该还是需要进行相应限制，因为在组件的资源监控页面，获取组件的内存、CPU等使用量时，使用的值为 as.GetK8sWorkloadName ，这样可能会有这种情况发生：

组件的 GetK8sWorkloadName 值为 appname-component-name， 那么其对应的查询语句为 sum(container_memory_rss{name=~".*appname-component-name.*"}/1024/1024) by (pod, namespace)。

如果此时加上前缀 default-tcpmesh- ，值为 default-tcpmesh-appname-component-name, 被截断后变为 default-tcpmesh-appname-compon， 此时可能无法获取到组件对应的指标

[poneding]

写一个截断函数确实能保证组件一定可以启动，但是前端应该还是需要进行相应限制，因为在组件的资源监控页面，获取组件的内存、CPU等使用量时，使用的值为 as.GetK8sWorkloadName ，这样可能会有这种情况发生：

组件的 GetK8sWorkloadName 值为 appname-component-name， 那么其对应的查询语句为 sum(container_memory_rss{name=~".*appname-component-name.*"}/1024/1024) by (pod, namespace)。

如果此时加上前缀 default-tcpmesh- ，值为 default-tcpmesh-appname-component-name, 被截断后变为 default-tcpmesh-appname-compon， 此时可能无法获取到组件对应的指标

嗯 是会有这样的问题。 那可以给组件名称限制长度，并且copy的时候如果超长了就截断，并一个短随机id去替换后面几位（比如截到56，再追加7位随机id）