Kubernetes：网络策略-全部拒绝和全部允许

我对所有名称空间中的所有pod都有一个默认的拒绝所有策略。如果在某个名称空间中有allow all添加到一个pod中该怎么办。什么优先？在组合多个策略时是否存在任何和/或逻辑

---

谢谢

从我的发现来看还不完全清楚，但暗示了允许先于拒绝：

POD通过具有选择它们的网络策略而变得孤立。一旦名称空间中有任何NetworkPolicy选择了特定的pod，该pod将拒绝任何NetworkPolicy不允许的任何连接。（命名空间中未被任何NetworkPolicy选择的其他POD将继续接受所有流量。）

---

基本上，对任何pod应用NetworkPolicy都包括一个隐式的“拒绝任何其他内容”策略。通过创建一个“默认拒绝”策略，您可以隔离所有POD，因为没有该策略，它们不会成为任何策略的目标（无策略=无隔离）

由于我们无法在网络策略中指定优先级，因此解决问题的最佳方法是将两个策略合并为一个策略，以避免冲突规则。

网络策略白名单连接，因此存在一个隐式或，如果一个连接被至少一个网络策略允许，那么它将被允许

更详细的解释（礼貌）：

每个网络策略都有一个podSelector字段，用于选择一组（零个或多个）pod。当一个pod被网络策略选择时，网络策略被称为应用于该pod

每个网络策略还指定允许（入口和出口）连接的列表。创建网络策略时，允许其应用的所有POD建立或接受其中列出的连接。换句话说，网络策略本质上是一个允许连接的白名单——如果应用于pod的至少一个网络策略允许连接到pod或从pod连接到pod，则允许连接

然而，这个故事有一个重要的转折点：根据到目前为止所描述的一切，人们会认为，如果没有对pod应用网络策略，那么就不允许与pod建立连接。事实上，情况正好相反：如果没有网络策略应用于pod，那么所有与pod之间的网络连接都是允许的（除非连接中应用于其他对等方的网络策略禁止连接）

这种行为与“隔离”的概念有关：如果至少有一个网络策略应用于POD，则POD是“隔离”的；如果没有适用的政策，它们是“非孤立的”。网络策略不会在非隔离的POD上强制实施。尽管有点违反直觉，但这种行为的存在是为了让集群更容易启动和运行——不了解网络策略的用户可以运行他们的应用程序，而无需创建一个应用程序