我的场景如下图：
几天后试图找到一种基于规则阻止 pod 之间连接的方法后，我找到了Network Policy。但它在 Google Cloud Platform 或本地 Kubernetes 上都不适合我！
我的场景很简单，我需要一种方法来根据规则（例如命名空间、工作负载标签等）阻止 pod 之间的连接。乍一看，我认为这对我有用，但我不知道为什么它在 Google Cloud 上不起作用，即使我使用“网络策略”选项从头开始创建集群。
【问题讨论】：
标签： kubernetes istio kubernetes-networkpolicy
网络政策将允许您完全按照图片上的描述进行操作。您可以根据标签或命名空间允许或阻止。
如果你不解释你到底做了什么，什么没用，就很难为你提供帮助。使用您创建的实际网络策略 YAML 更新您的问题，理想情况下还可以从带有 pod 的命名空间发送 kubectl get pod --show-labels。
“本地 kubernetes”是什么意思也不清楚，但它很大程度上取决于您使用的网络 CNI，因为它必须支持网络策略。例如 Calico 或 Cilium 支持它。 Minikube 在它的默认设置中没有，所以你应该遵循本指南：https://medium.com/@atsvetkov906090/enable-network-policy-on-minikube-f7e250f09a14
【讨论】：
你可以使用 Istio Sidecar 来解决这个问题：https://istio.io/latest/docs/reference/config/networking/sidecar/
另一个 Istio 解决方案是 AuthorizationPolicy 的使用：https://istio.io/latest/docs/reference/config/security/authorization-policy/
【讨论】：
只是为了更新，因为我参与了这篇文章的问题。 问题在于注入了 istio 的 pod。在这种情况下，命名空间中的所有 pod，因为它启用了 istio-injection=enabled。 当由 matchselector、egress 或 ingress 进行选择时，NetworkPolicy 规则未生效，并且所涉及的 pod 在创建 NetworkPolicy 之前已经在运行。通过杀死 pod 然后启动它，标签匹配的 pod 可以正常访问。我不知道是否有办法说刷新 pod 内的 sidecar 而无需重新启动它。 创建 NetworkPolicy 后启动的 Pod 并没有给出这个帖子的问题。
【讨论】：