【发布时间】:2020-11-21 09:39:54
【问题描述】:
在我们的集群中,我们在不同的节点池中运行两个版本的 API。现在我们每个版本的微服务流量从 pod1 > service1 > service2 > pod2 路由。我想使用网络策略来证明我们的 API 可以防止一个版本的 API 中的 pod 与另一个版本进行通信。
以下是我为 1.1 版编写的网络策略示例。但是,这似乎阻碍了 1.1 节点池中的所有流量。
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: networkpolicy-v1-1
namespace: default
spec:
podSelector:
matchLabels:
version: v1-1
policyTypes:
- Ingress
- Egress
ingress:
- from:
- podSelector:
matchLabels:
version: v1-1
egress:
- {}
这是describe pod <podname> 的输出,显示了标签的匹配。
Name: adduser-v1-1-696467d46-zkvq9
Namespace: default
Labels: app=adduser-v1-1
pod-template-hash=696467d46
version=v1-1
为了确认,我在上面的 pod 中运行的代码中添加了以下语句。我能够在没有网络策略的情况下看到日志记录语句。当策略处于活动状态时,请求会超时,并且找不到日志记录语句。
@api.route('/customer/add', methods=['POST'])
def create_customer():
logger.info("inside create customer")
我们的服务很好:
apiVersion: v1
kind: Service
metadata:
name: adduser-v1-1
spec:
ports:
- port: 80
targetPort: 8081
protocol: TCP
name: http
selector:
app: adduser-v1-1
type: LoadBalancer
编辑
澄清一下:在我上面的示例中,pod1 > service1 > service2 > pod2 所有 pod 和服务 1 和 2 都在同一个节点池中,并且 pod 1 和 2 都包含标签 version=v1-1。示例:
我希望这些 pod 能够相互交谈:
吊舱1
Labels: app=adduser-v1-1
pod-template-hash=687b4f6b8d
version=v1-1
Pod2
Labels: app=authuser-v1-1
pod-template-hash=5449f9bd6d
version=v1-1
虽然这些 pod 应该被网络策略阻止
吊舱1
Labels: app=adduser-v1-1
pod-template-hash=687b4f6b8d
version=v1-1
吊舱 2
Labels: app=authuser-v2-0
pod-template-hash=bd87f9d55
version=v2-0
【问题讨论】:
-
在您的网络策略中,您只允许来自您的 pod 的流量进入,这将阻止所有其他流量,而不是您可以编写一个默认的拒绝进入策略 @NealR
-
您是使用默认的 GKE CNI 还是更改了它?我将尝试在我的实验室测试中重现。
-
@KoopaKiller 我们使用默认值
-
我已经在我的实验室帐户中进行了测试,如果 pod1-->service1 并且阻止从 pod1 到 pod2 的流量,但如果我使用服务名称 pod1-->service2 进行测试,您的策略也可以正常工作允许...您是否考虑过在单独的名称空间中运行 app1 和 app2?
标签: kubernetes google-kubernetes-engine kubernetes-networkpolicy