获取我的 k8s 微服务应用程序的非命名空间依赖项

如何解决获取我的 k8s 微服务应用程序的非命名空间依赖项

如果我在命名空间中有一个微服务应用程序，我可以使用 k8s api 轻松获取该命名空间内的所有命名空间资源。但是，我无法查看微服务应用程序正在使用哪些非命名空间资源。如果我想查看我的非命名空间资源，我只能一次查看它们，而无法指明哪些是微服务应用程序中的依赖项。

如何找到与我的应用程序相关的依赖项？我希望能够获得对应用的命名空间资源正在使用的 PersistentVolumes、StorageClasses、ClusterRoles 等内容的引用。

解决方法

您的代码在命名空间内的 pod 容器中运行，使用 serviceaccount 集运行，该集合使用 pod.spec.serviceAccountName。 如果未设置，它将使用默认服务帐户运行。

您需要创建一个 clusterRole 以授予对集群范围资源特定动词的访问权限，然后在 pod 命名空间中通过 roleBinding 将此 clusterRole 分配给 serviceaccount > 以之前创建的 clusterRole 为目标。

然后你的 pod，使用 kubernetes 客户端，并使用“in-cluster config”auth 方法，将能够查询 apiserver 以获取/list/watch/delete/patch...所说的集群范围的资源.

,

这绝对是一项非常重要的任务，因为 dependency 可以通过多种方式发挥作用：每当一个对象“使用”另一个对象时，我们就可以识别依赖项。问题是这种“使用”关系可以采用多种形式：例如，Pod 可以在其定义中引用 Volume（这将是一种直接依赖），但也可以使用 { {1}} 然后将通过使用 PersistentVolumeClaim 实例化 PV -- 这些关系仅在 运行 时为 Kubernetes 所知，当应用 YAML 定义时.

换句话说：

• 要追踪依赖关系，您必须检查正在使用的资源的 YAML 描述，了解每个资源的语义：每个资源中没有单个 StorageClass 值，但需要遵循，例如 {{1 depends: 的 }}、spec.storageClass 的 PVC 等。
• 在某些情况下，这甚至还不够：例如，对于匹配 spec.volumes: 和 Pod，这甚至还不够，因为必须匹配每一侧的端口。
• 所有这些都需要通过从正在运行的 K8s 集群中提取 YAML 来完成，因为资源之间的某些关系在实例化之前是未知的。

您可以查看 Daniele Polencic 的 How do you visualise dependencies in your Kubernetes YAML files? 文章，其中介绍了一些可用于可视化依赖关系的工具：

没有任何静态工具可以分析 YAML 文件。但是您可以使用 Weave Scope、KubeView 或使用 Istio 跟踪流量来可视化集群中的依赖项。