在我们的集群中,我们在单独的节点池中运行两个版本的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和service 1&2都在同一个节点池中,并且pod 1&2都包含标签version=v1-1
。示例:
我希望这些吊舱能够互相交谈:
Pod1
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
虽然这些吊舱应该被网络政策阻止
Pod1
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
答案 0 :(得分:0)
以上网络策略networkpolicy-v1-1将仅允许从pod1(版本:v1-1)到pod1(版本:v1-1)的入口流量,它将不允许任何其他入口流量,但允许所有外向流量,是故意的?如果要实现pod1> service1> service2> pod2,则以下网络策略可以提供帮助。下面将确保pod2仅接收来自POD1的流量
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: networkpolicy-v2-2
namespace: default
spec:
podSelector:
matchLabels:
version: v2-2
policyTypes:
- Ingress
- Egress
ingress:
- from:
- podSelector:
matchLabels:
version: v1-1
egress:
- {}