【发布时间】：2022-01-24 12:12:00
【问题描述】：
我目前正在尝试将基于 calico 的集群迁移到新的 Dataplane V2，它基本上是托管的 Cilium 产品。 对于本地测试，我正在运行安装了开源 cilium 的 k3d，并创建了一组 NetworkPolicies（k8s 原生策略，而不是 CiliumPolicies），用于锁定所需的命名空间。
我当前的问题是，当在 GKE 集群（启用 DataPlane）上移植相同的策略时，这些相同的策略不起作用。
作为一个例子，让我们看看一些应用程序和数据库之间的连接：
---
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: db-server.db-client
namespace: BAR
spec:
podSelector:
matchLabels:
policy.ory.sh/db: server
policyTypes:
- Ingress
ingress:
- ports: []
from:
- namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: FOO
podSelector:
matchLabels:
policy.ory.sh/db: client
---
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: db-client.db-server
namespace: FOO
spec:
podSelector:
matchLabels:
policy.ory.sh/db: client
policyTypes:
- Egress
egress:
- ports:
- port: 26257
protocol: TCP
to:
- namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: BAR
podSelector:
matchLabels:
policy.ory.sh/db: server
此外，使用 GCP 监控工具，我们可以看到政策对连接性的预期和实际影响：
来自应用程序的日志尝试连接到数据库并被拒绝：
{
"insertId": "FOO",
"jsonPayload": {
"count": 3,
"connection": {
"dest_port": 26257,
"src_port": 44506,
"dest_ip": "172.19.0.19",
"src_ip": "172.19.1.85",
"protocol": "tcp",
"direction": "egress"
},
"disposition": "deny",
"node_name": "FOO",
"src": {
"pod_name": "backoffice-automigrate-hwmhv",
"workload_kind": "Job",
"pod_namespace": "FOO",
"namespace": "FOO",
"workload_name": "backoffice-automigrate"
},
"dest": {
"namespace": "FOO",
"pod_namespace": "FOO",
"pod_name": "cockroachdb-0"
}
},
"resource": {
"type": "k8s_node",
"labels": {
"project_id": "FOO",
"node_name": "FOO",
"location": "FOO",
"cluster_name": "FOO"
}
},
"timestamp": "FOO",
"logName": "projects/FOO/logs/policy-action",
"receiveTimestamp": "FOO"
}
编辑：
我的本地环境是通过以下方式创建的 k3d 集群：
k3d cluster create --image ${K3SIMAGE} --registry-use k3d-localhost -p "9090:30080@server:0" \
-p "9091:30443@server:0" foobar \
--k3s-arg=--kube-apiserver-arg="enable-admission-plugins=PodSecurityPolicy,NodeRestriction,ServiceAccount@server:0" \
--k3s-arg="--disable=traefik@server:0" \
--k3s-arg="--disable-network-policy@server:0" \
--k3s-arg="--flannel-backend=none@server:0" \
--k3s-arg=feature-gates="NamespaceDefaultLabelName=true@server:0"
docker exec k3d-server-0 sh -c "mount bpffs /sys/fs/bpf -t bpf && mount --make-shared /sys/fs/bpf"
kubectl taint nodes k3d-ory-cloud-server-0 node.cilium.io/agent-not-ready=true:NoSchedule --overwrite=true
skaffold run --cache-artifacts=true -p cilium --skip-tests=true --status-check=false
docker exec k3d-server-0 sh -c "mount --make-shared /run/cilium/cgroupv2"
cilium 本身是由 skaffold 安装的，通过 helm 使用以下参数：
name: cilium
remoteChart: cilium/cilium
namespace: kube-system
version: 1.11.0
upgradeOnChange: true
wait: false
setValues:
externalIPs.enabled: true
nodePort.enabled: true
hostPort.enabled: true
hubble.relay.enabled: true
hubble.ui.enabled: true
更新： 我已经设置了第三个环境：使用旧 calico CNI（传统数据平面）的 GKE 集群并手动安装了 cilium，如图所示here。 Cilium 工作正常，甚至 Hubble 开箱即用（与 dataplane v2 不同......），我发现了一些有趣的东西。规则的行为与 GKE 管理的 cilium 相同，但在 hubble 工作时我能够看到：
由于某种原因 cilium/hubble 无法识别 db pod 并破译其标签。由于标签不起作用，依赖这些标签的策略也不起作用。
另外一个证明是来自 hubble 的跟踪日志：
这里的目标应用程序仅通过 IP 识别，而不是标签。
现在的问题是为什么会这样？
知道如何调试这个问题吗？可能有什么不同？这些策略是否需要对托管的 Cilium 进行一些调整，或者是 GKE 中的错误？ 任何帮助/反馈/建议表示赞赏！
【问题讨论】：
-
请提供有关您的第一个环境和当前环境的更多详细信息。所以一开始你在 K3d 上有本地集群，然后你转移到 GKE 并创建了启用
Dataplane V2的新集群？您是否遵循任何文档？您是否将default GCE Service Account用于 GKE 虚拟机？您是否尝试查看 [此故障排除指南](cloud.google.com/kubernetes-engine/docs/how-to/dataplane- v2)？您能否确认您的环境/设置是否没有达到任何限制form here？ -
你的 db pod 还在监听 26257 端口吗？此外，您在发布的策略中屏蔽命名空间可能只是一个问题，但是入口和出口策略是针对相同还是不同的命名空间？该策略具有不同的命名空间，但错误显示相同。
-
@PjoterS 感谢您的回复，我已将我的 k3d 设置添加到问题中。是的，这些集群是使用 dataplaneV2 从头开始创建的，我发现在 anted pod 中没有错误，并且一些策略（如 DNS）有效，而另一些则没有。
-
@GariSingh：是的，该应用正在侦听该端口。你说的蒙面是什么意思？我正在使用 AutoLabel 功能，因为策略对标签而不是命名空间名称进行操作。数据库服务器位于命名空间 BAR 中，客户端位于 FOO 中
-
@Demonsthere - 我只是假设标签与命名空间匹配。我可能读错了，但看起来政策允许 Egress to BAR 和 Ingress from FOO 但错误消息似乎表明 src 和 dest 都在 FOO 中？
标签： kubernetes google-cloud-platform google-kubernetes-engine kubernetes-networkpolicy cilium