KRR工具默认跳过kube-system命名空间的行为解析

KRR作为一款Kubernetes资源推荐工具，其默认行为在实际使用中存在一个值得注意的特性：它会自动跳过kube-system命名空间，尽管其帮助文档中声称默认会扫描所有命名空间。这一设计决策背后有着合理的考量。

行为表现与预期差异

当用户执行基础命令时：

krr simple

工具不会显示kube-system命名空间中的资源。然而，当明确指定该命名空间时：

krr simple --namespace kube-system

工具则会正常扫描并显示该命名空间内的资源。这种差异源于代码中一个特定的过滤逻辑：

# 注意：默认情况下我们会过滤掉kube-system命名空间
if settings.namespaces == "*" and object.namespace == "kube-system":
    continue

设计决策的深层考量

项目维护者选择保持这一默认行为主要基于以下技术考虑：

1. 托管环境兼容性：大多数托管Kubernetes服务（如EKS、AKS、GKE等）会在kube-system命名空间中运行系统级组件，这些组件通常不受用户直接控制。

2. 资源推荐相关性：系统组件的资源需求通常由云服务商预先配置，用户调整这些配置可能影响集群稳定性。

3. 用户体验优化：避免向终端用户展示他们通常不需要关注的系统组件资源建议，减少信息噪音。

最佳实践建议

对于不同使用场景，建议采用以下方式：

1. 常规使用：保持默认行为，专注于业务工作负载的资源优化。

2. 系统组件调优：当确实需要分析系统组件资源时，通过显式指定命名空间参数来获取相关信息。

3. 全集群扫描：如需包含系统命名空间，可以通过指定所有命名空间的方式实现：

   krr simple --namespace "*" --namespace "kube-system"
   

版本兼容性说明

这一行为特性在当前稳定版本中持续存在，用户在编写自动化脚本或文档时应当注意这一细节差异，避免产生预期外的扫描结果遗漏。对于需要严格审计所有命名空间的场景，建议在CI/CD流程中明确指定需要扫描的命名空间列表。