GKE Dataplane v2 NetworkPolicies 不工作
GKE Dataplane v2 NetworkPolicies not working
我目前正在尝试将基于 calico 的集群移动到新的 Dataplane V2,它基本上是一个托管的 Cilium 产品。
对于本地测试,我是 运行 k3d,安装了开源的 cilium,并创建了一组 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 管理的纤毛相同,但通过 hubble 工作我能够看到:
出于某种原因 cilium/hubble 无法识别数据库 pod 并破译其标签。由于标签不起作用,依赖于这些标签的策略也不起作用。
另一个证据是哈勃的跟踪日志:
此处目标应用仅通过 IP 识别,而非标签。
现在的问题是为什么会这样?
知道如何调试这个问题吗?可能有什么不同?这些政策是否需要对托管 Cilium 进行一些调整,或者是 GKE 中的错误?
任何 help/feedback/suggestion 赞赏!
更新:我解开了谜团,一直都是ArgoCD。 Cilium 正在为命名空间中的每个对象创建一个 Endpoint 和 Identity,而 Argo 在部署应用程序后删除它们。
对于遇到此问题的任何人,解决方案是将此排除项添加到 ArgoCD:
resource.exclusions: |
- apiGroups:
- cilium.io
kinds:
- CiliumIdentity
- CiliumEndpoint
clusters:
- "*"
我目前正在尝试将基于 calico 的集群移动到新的 Dataplane V2,它基本上是一个托管的 Cilium 产品。 对于本地测试,我是 运行 k3d,安装了开源的 cilium,并创建了一组 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 管理的纤毛相同,但通过 hubble 工作我能够看到:
出于某种原因 cilium/hubble 无法识别数据库 pod 并破译其标签。由于标签不起作用,依赖于这些标签的策略也不起作用。
另一个证据是哈勃的跟踪日志:
此处目标应用仅通过 IP 识别,而非标签。
现在的问题是为什么会这样?
知道如何调试这个问题吗?可能有什么不同?这些政策是否需要对托管 Cilium 进行一些调整,或者是 GKE 中的错误? 任何 help/feedback/suggestion 赞赏!
更新:我解开了谜团,一直都是ArgoCD。 Cilium 正在为命名空间中的每个对象创建一个 Endpoint 和 Identity,而 Argo 在部署应用程序后删除它们。
对于遇到此问题的任何人,解决方案是将此排除项添加到 ArgoCD:
resource.exclusions: |
- apiGroups:
- cilium.io
kinds:
- CiliumIdentity
- CiliumEndpoint
clusters:
- "*"