之前写了个脚本：传入 deployment 资源名称作为参数，脚本会正则匹配以该名称开头的 pod 列表（认为匹配到的 pod 是由该 deployment 创建的），再循环去获取 pod 的一些信息。正常使用了几个月后突然发现有些传入的 deployment 资源名称匹配不到 pod 了，于是开始查找原因

拿到报异常的 deployment 资源名称手动执行过滤，发现真的没匹配上

仔细瞅了一下发现，pod 的名称格式竟然变了，之前是 deployment 名称开头加上 -77495f666c-6cjhn 这种相当于三段式格式。现在是 deployment 名称加上 -787b88f8pmjxx 这种两段式格式，那正则肯定匹配不上了。
经过一番测试，发现 deployment 资源名称的字符个数会影响生成的 pod 名称格式，deployment 资源字符长度的不同会产生好几种 pod 格式。这里做下记录（没用的知识又增加了...）

测试下来 deployment 生成的 pod 命名格式为：deployment名称+k8s生成的随机字符拼接而成。pod 名称最多为 63 个字符，并且尾部最少包含5个k8s生成的随机字符，具体根据 deployment 名称的字符长度显示为不同格式。

格式1 - 三段式

# 第一种是常见的三段式格式：
grep -E "${deployment_name}-[a-z0-9]{9,10}-[a-z0-9]{5}"

z-fbc4889f6-g9525
z123456789z123456789z123456789z123456789z123456-fbc4889f6-gcf2l
test-shop-67d968f44b-x9tbq

# 需要注意的是如果第二段长度是9个字符，那么 deployment 资源名称的字符数为 1-47 个；第二段长度是10个字符，那么 deployment 资源名称的字符数为 1-46 个。超出字符长度 pod 名称则会转换为另一种格式。

格式2 - 两段式

# 两段式的格式相对就少见了，除非你把 deployment 资源的名称定义的特别长（超过46或47个字符）pod 的名称才会变成这种格式。
grep -E "${deployment_name}-[a-z0-9]{5,15}"

z123456789z123456789z123456789z123456789z1234567-fbc4889f6xt4g8
z123456789z123456789z123456789z123456789z123456789z123456-nhc5f

格式3 - 一段式

# 一段式的就更少见了，把 deployment 资源名称定义的如此长实属不易图片，长度大于等于58个字符的时候，生成的 pod 名称才会变成一段式
grep -E "${deployment_name:0:58}[a-z0-9]{5}"

[root@imzcy ~]# kubectl -n test apply -f test.yaml
deployment.apps/z123456789z123456789z123456789z123456789z123456789z1234567 created

[root@imzcy ~]# kubectl -n test get pods -l app=zcy-test
NAME                                                              READY   STATUS    RESTARTS   AGE
z123456789z123456789z123456789z123456789z123456789z1234567jkl8h   1/1     Running   0          3s

# 需要注意的是，如果由于 deployment 的名称过长导致生成的 pod 名称在 63 个字符内无法在尾部填充最少5个随机字符，那么会将 deployment 名称从头部开始截取 58 个字符再拼接5个随机字符。