🐛 Bugfix: Fixed an issue where the MCP service failed to start in a Kubernetes pod.

[YehongPan]

🐛 Bugfix: Fixed an issue where the MCP service failed to start in a Kubernetes pod.
fixes #3253
[Specification Details]

1. Modify the pod naming logic to convert all non-compliant characters to -.
2. Modify test cases.

[YehongPan]

[逻辑漏洞] _sanitize_k8s_name 函数在注释中提到了 Kubernetes 命名约束（最大 253 字符），但实际代码中未对长度进行截断。如果输入名称超过 253 字符，生成的 K8s 资源名称将无效，导致创建失败。建议在函数末尾添加长度截断逻辑：sanitized = sanitized[:253].rstrip('-')。

[JasonW404]

_sanitize_k8s_name(None) 会在 name.lower() 处抛出 AttributeError，因为 None 没有 lower() 方法。if not name 检查在 name.lower() 之后才执行，无法拦截 None 输入。测试用例 test_sanitize_none 预期返回 "unknown" 但实际会崩溃。建议将 None 检查移到最前面：if not name: return "unknown" 改为 if name is None or not name: return "unknown"。

[WMC001]

Observation: improved K8s name sanitization

sdk/nexent/container/k8s_client.py — extracts _sanitize_k8s_name helper for centralized name sanitization across _generate_pod_name and list_containers. The helper handles empty/None inputs (returns "unknown"), strips leading/trailing dashes, and prepends x for names that start with non-alphanumeric. Tests cover the main edge cases including consecutive special chars, leading/trailing chars, and underscores/dots/spaces.

No bugs found. Note that _sanitize_k8s_name is called before the [:8] truncation, which is the correct order — internal .strip("-") ensures the truncated slice doesn't contain leading/trailing dashes.

[xuyaqist]

_sanitize_k8s_name 函数没有对输出长度进行限制。Kubernetes DNS label 名称最长 63 个字符（RFC 1123），而 pod 名称由 mcp-{safe_name}-{tenant}-{user}-{uuid} 拼接而成。如果 service_name 很长，最终 pod 名称可能超过 253 字符限制导致 K8s API 报错。建议在函数末尾添加截断逻辑，或在 _generate_pod_name 中对各段长度做约束。

[xuyaqist]

_sanitize_k8s_name 在 sanitized 为空时返回 "unknown"，但当输入为 None 时，虽然 if not name 的 guard 能正确拦截（返回 True），但类型注解 name: str 应改为 Optional[str] 以准确反映函数实际接受的输入类型，提高代码可读性和类型检查的准确性。

[hhhhsc701]

[P2] 注释写 max 253，但这个 sanitizer 没有实际 enforce 长度，而且很多使用点是 label value/名称片段，常见上限是 63。注释会让调用方误以为长度已经安全，建议把长度作为参数并在函数内截断。

[hhhhsc701]

[P2] name 标注为 str，但测试又传 None；如果传入 truthy 的非字符串对象，name.lower() 会抛 AttributeError。边界入口应先 str(name) 或显式拒绝非字符串。

[hhhhsc701]

[P1] 返回值没有任何长度限制，长 service_name 经过清洗后仍然可以非常长，最终 pod name 会超过 Kubernetes 限制。这里应该在 sanitizer 或 _generate_pod_name 中截断并附稳定 hash。

[hhhhsc701]

[P2] tenant_part/user_part 只取前 8 位，tenantabcdef 和 tenantabcxyz 会生成同样前缀，排障和清理时容易误判。建议用前缀+短 hash，而不是纯截断。

[hhhhsc701]

[P2] list_containers 用 sanitize 后的 safe_name 再做子串匹配，service=api 会匹配到 my-api-v2 等不相关 pod。应和创建时的 component label 做精确匹配，或保存完整 sanitized service_name label。

[hhhhsc701]

[P2] 注释写 max 253，但这个 sanitizer 没有实际 enforce 长度，而且很多使用点是 label value/名称片段，常见上限是 63。注释会让调用方误以为长度已经安全，建议把长度作为参数并在函数内截断。

[hhhhsc701]

[P2] name 标注为 str，但测试又传 None；如果传入 truthy 的非字符串对象，name.lower() 会抛 AttributeError。边界入口应先 str(name) 或显式拒绝非字符串。

[hhhhsc701]

[P1] 返回值没有任何长度限制，长 service_name 经过清洗后仍然可以非常长，最终 pod name 会超过 Kubernetes 限制。这里应该在 sanitizer 或 _generate_pod_name 中截断并附稳定 hash。

[hhhhsc701]

[P2] tenant_part/user_part 只取前 8 位，tenantabcdef 和 tenantabcxyz 会生成同样前缀，排障和清理时容易误判。建议用前缀+短 hash，而不是纯截断。

[hhhhsc701]

[P2] list_containers 用 sanitize 后的 safe_name 再做子串匹配，service=api 会匹配到 my-api-v2 等不相关 pod。应和创建时的 component label 做精确匹配，或保存完整 sanitized service_name label。

[Dallas98]

事后审查补充：按已合入 diff 补充 5 条可行动 inline review comments。

[Dallas98]

事后审查补充：[P2] 注释写 max 253，但这个 sanitizer 没有实际 enforce 长度，而且很多使用点是 label value/名称片段，常见上限是 63。注释会让调用方误以为长度已经安全，建议把长度作为参数并在函数内截断。

影响：这个问题合入后会在对应部署、运行或权限场景中留下真实故障/安全风险，后续排查成本较高。
建议：沿着上述风险点补齐校验、配置来源、权限边界或回归测试，避免同类问题再次出现。

[Dallas98]

事后审查补充：[P2] name 标注为 str，但测试又传 None；如果传入 truthy 的非字符串对象，name.lower() 会抛 AttributeError。边界入口应先 str(name) 或显式拒绝非字符串。

影响：这个问题合入后会在对应部署、运行或权限场景中留下真实故障/安全风险，后续排查成本较高。
建议：沿着上述风险点补齐校验、配置来源、权限边界或回归测试，避免同类问题再次出现。

[Dallas98]

事后审查补充：[P1] 返回值没有任何长度限制，长 service_name 经过清洗后仍然可以非常长，最终 pod name 会超过 Kubernetes 限制。这里应该在 sanitizer 或 _generate_pod_name 中截断并附稳定 hash。

影响：这个问题合入后会在对应部署、运行或权限场景中留下真实故障/安全风险，后续排查成本较高。
建议：沿着上述风险点补齐校验、配置来源、权限边界或回归测试，避免同类问题再次出现。

[Dallas98]

事后审查补充：[P2] tenant_part/user_part 只取前 8 位，tenantabcdef 和 tenantabcxyz 会生成同样前缀，排障和清理时容易误判。建议用前缀+短 hash，而不是纯截断。

影响：这个问题合入后会在对应部署、运行或权限场景中留下真实故障/安全风险，后续排查成本较高。
建议：沿着上述风险点补齐校验、配置来源、权限边界或回归测试，避免同类问题再次出现。

[Dallas98]

事后审查补充：[P2] list_containers 用 sanitize 后的 safe_name 再做子串匹配，service=api 会匹配到 my-api-v2 等不相关 pod。应和创建时的 component label 做精确匹配，或保存完整 sanitized service_name label。

影响：这个问题合入后会在对应部署、运行或权限场景中留下真实故障/安全风险，后续排查成本较高。
建议：沿着上述风险点补齐校验、配置来源、权限边界或回归测试，避免同类问题再次出现。

[Dallas98]

二次事后审查补充 1/5：单条独立 review submission。

[Dallas98]

二次事后审查补充：[P2] 注释写 max 253，但这个 sanitizer 没有实际 enforce 长度，而且很多使用点是 label value/名称片段，常见上限是 63。注释会让调用方误以为长度已经安全，建议把长度作为参数并在函数内截断。

影响：该问题合入后仍可能在真实部署、运行、权限或测试场景中形成回归风险。
建议：后续按这个风险点补齐边界校验、配置来源收敛、权限约束或针对性回归测试。

[Dallas98]

二次事后审查补充 2/5：单条独立 review submission。

[Dallas98]

二次事后审查补充：[P2] name 标注为 str，但测试又传 None；如果传入 truthy 的非字符串对象，name.lower() 会抛 AttributeError。边界入口应先 str(name) 或显式拒绝非字符串。

影响：该问题合入后仍可能在真实部署、运行、权限或测试场景中形成回归风险。
建议：后续按这个风险点补齐边界校验、配置来源收敛、权限约束或针对性回归测试。

[Dallas98]

二次事后审查补充 3/5：单条独立 review submission。

[Dallas98]

二次事后审查补充：[P1] 返回值没有任何长度限制，长 service_name 经过清洗后仍然可以非常长，最终 pod name 会超过 Kubernetes 限制。这里应该在 sanitizer 或 _generate_pod_name 中截断并附稳定 hash。

影响：该问题合入后仍可能在真实部署、运行、权限或测试场景中形成回归风险。
建议：后续按这个风险点补齐边界校验、配置来源收敛、权限约束或针对性回归测试。

[Dallas98]

二次事后审查补充 4/5：单条独立 review submission。

[Dallas98]

二次事后审查补充：[P2] tenant_part/user_part 只取前 8 位，tenantabcdef 和 tenantabcxyz 会生成同样前缀，排障和清理时容易误判。建议用前缀+短 hash，而不是纯截断。

影响：该问题合入后仍可能在真实部署、运行、权限或测试场景中形成回归风险。
建议：后续按这个风险点补齐边界校验、配置来源收敛、权限约束或针对性回归测试。

[Dallas98]

二次事后审查补充 5/5：单条独立 review submission。

[Dallas98]

二次事后审查补充：[P2] list_containers 用 sanitize 后的 safe_name 再做子串匹配，service=api 会匹配到 my-api-v2 等不相关 pod。应和创建时的 component label 做精确匹配，或保存完整 sanitized service_name label。

影响：该问题合入后仍可能在真实部署、运行、权限或测试场景中形成回归风险。
建议：后续按这个风险点补齐边界校验、配置来源收敛、权限约束或针对性回归测试。