-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GKE ingress network policy #139
Comments
在使用 GKE (Google Kubernetes Engine) 配置内部负载均衡器时,如果启用了网络策略,如 Calico,可能需要特别注意确保健康检查流量能够正常通过。网络策略可以控制 Pod 之间的通信,如果不正确配置,可能会阻止来自 GKE 控制平面的健康检查流量,导致服务状态显示为 unhealthy。 解决方案
示例网络策略以下是一个 Calico 网络策略的示例,它允许来自特定 IP 地址范围的入站流量,这些 IP 地址范围应该包括 GKE 控制平面的 IP 地址: apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
name: allow-health-checks
spec:
ingress:
- action: Allow
protocol: TCP
source:
nets:
- "<GKE控制平面IP范围>"
destination:
ports:
- 10256 # 假设的健康检查端口
selector: "role == 'your-app'" 在这个策略中,您需要替换 结论正确配置网络策略是确保 GKE 内部负载均衡器能够正常进行健康检查的关键。如果遇到问题,建议详细检查现有的网络策略设置,并根据需要进行调整。如果问题仍然存在,可能需要进一步检查日志和监控数据,或者联系 Google Cloud 支持获取帮助。 Sources 您遇到的问题很有可能是由于 Network Policy 的规则过于严格而导致的。当您应用了 Network Policy 后,Kubernetes 会根据这些规则来控制进出 Pod 的流量,如果规则太严格可能会阻止了正常的流量。 要解决这个问题,您需要在 Network Policy 中添加合适的规则,以允许以下流量:
具体来说,您可以尝试添加以下规则: apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-ingress-and-healthcheck
namespace: your-namespace
spec:
podSelector:
matchLabels:
app: your-app-label
policyTypes:
- Ingress
ingress:
- from:
- namespaceSelector:
matchLabels:
component: ingress
ports:
- port: your-service-port
- from:
- ipBlock:
cidr: 0.0.0.0/0
except:
- 10.0.0.0/8
- 172.16.0.0/12
- 192.168.0.0/16
ports:
- port: your-service-port 上面的规则做了以下工作:
您需要根据您的实际情况调整 如果上述规则无法解决您的问题,您可能需要进一步检查您的网络插件配置,或者查看 Ingress 控制器日志以获取更多信息。 我认为下面这个允许load balanced ip也可能有道理 In this case, the issue is likely due to the fact that the health check probes sent by the ingress controller are blocked by the network policy. To allow the health checks to succeed, you need to create a network policy that permits traffic from the ingress controller to your backend service. However, since you're using an internal load balancer, you need to allow traffic from the load balancer's IP address range instead of the ingress controller's pod IP. Here's a possible solution: Create a network policy to allow health checks
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-health-checks
namespace: <your-namespace>
spec:
podSelector:
matchLabels:
app: <your-backend-service-app-label>
ingress:
- from:
- ipBlock:
cidr: <load-balancer-ip-range>/32
- ports:
- 8080 # or the port your backend service is listening on
policyTypes:
- Ingress Replace Apply the network policy Run Verify the health check After applying the network policy, verify that the backend service health check is successful again. You can check the health check status using By allowing traffic from the internal load balancer's IP address range to your backend service, you should be able to resolve the health check issues caused by the network policy. |
在使用 Network Policy 时,您需要确保网络策略允许所需的流量通过以维持健康的后端服务状态。在您的情况下,由于在没有网络策略时服务是正常的,但在应用网络策略后服务变得不健康,可能是由于网络策略阻止了必要的流量导致的。 根据您的描述,您的网络策略可能阻止了健康检查或其他必要的流量到达您的后端服务。您可以通过以下方式来解决这个问题:
具体的网络策略规则取决于您的环境和应用程序的配置。以下是一些示例规则,您可以根据您的需求进行调整: apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-egress
spec:
podSelector:
matchLabels:
app: your-app # 调整为您的应用程序标签
policyTypes:
- Egress
egress:
- to:
- podSelector:
matchLabels:
role: backend # 调整为您的后端服务标签 这个示例允许来自标签为 如果您已经有特定的网络策略配置,请分享您的网络策略规则,以便更好地帮助您诊断问题并提出解决方案。 |
按照下面这个说法,我是不是需要在我的创建ingress 时候 指定一个标签 这样的话我才能在我的网络规则上做标签的选择 在 Kubernetes 中,Network Policies 是用来控制不同 Pods 之间的网络连接的规则。如果你在启用 Network Policies 后发现服务健康检查变为 unhealthy,这通常是因为 Network Policies 阻止了必要的网络流量。 对于你的内部 GKE Ingress、Service 和 Deployment 的配置,以下是一些可能需要的 Network Policy 规则,以确保流量可以正常流动:
一个基本的 Network Policy 示例可能如下所示: apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-ingress-to-service
spec:
podSelector:
matchLabels:
# 选择你的 Deployment 的标签
app: your-app
ingress:
- from:
- podSelector:
matchLabels:
app: your-ingress
ports:
- protocol: TCP
port: 80 # 或者你的服务监听的端口 在这个例子中, 请注意,Network Policies 可以非常具体,因此你需要根据你的具体配置和需求来调整规则。如果你不确定需要哪些规则,可以尝试以下步骤:
请记得,在实施任何 Network Policies 之前,最好在一个测试环境中进行测试,以避免在生产环境中引入问题。如果你不熟悉 Network Policies 的配置,可能需要进一步研究或咨询 Kubernetes 网络方面的专家。 |
对于在GKE的namespace中调试Network Policy规则的流量是否符合预期,您可以采取以下措施:
Kubernetes审计日志记录了Kubernetes API服务器收到的所有请求。您可以在审计日志中查看Network Policy是否生效,以及哪些Pod或服务被拒绝访问。
kube-bench是一个通过运行端到端测试来检查Kubernetes部署中Network Policy实施情况的工具。您可以运行以下命令: kubectl run temp-pod --rm -i -t --image=aquasec/kube-bench:latest --restart=Never -- master --audit-env
利用kube-state-metrics导出NetworkPolicy生效的监控指标,并在Prometheus中配置抓取相关指标,从而监控NetworkPolicy运行状态。
通过上述多种方式,您可以全面地查看Network Policy规则生效情况、影响范围、连通性测试等,从而调试您的NetworkPolicy是否按预期工作,哪些流量被阻挡或放行等细节信息。 |
要解决您提出的问题,即如何在默认拒绝所有入站和出站流量的情况下,逐步放开一些规则,并确认其他命名空间或流量是否可以到达您的命名空间,以及如何获取规则命中的详细信息,您可以采取以下步骤进行调试和确认: 1. 确认网络策略的存在和状态首先,确保您已经正确创建并应用了网络策略。您可以使用以下命令列出当前命名空间中的所有网络策略: kubectl get networkpolicies --namespace=<您的命名空间> 2. 使用日志和监控工具GKE 并没有直接提供查看网络策略命中详情的内置工具,但您可以通过配置日志和监控来间接获取这些信息。您可以使用如 Stackdriver 这样的日志管理工具来收集和分析您的集群日志。通过配置适当的日志记录级别,您可以获取到关于网络流量和网络策略决策的详细信息。 3. 使用第三方工具还有一些第三方工具和项目,如 Cilium 或 Calico,它们提供了更高级的网络策略调试和可视化功能。这些工具可以帮助您更容易地理解网络策略的行为,并且通常提供了更详细的日志和监控功能。 4. 测试网络连通性您可以使用 kubectl exec <源Pod名称> --namespace=<源命名空间> -- curl <目标Pod的IP地址> 如果请求成功,说明流量被允许;如果失败,可能是被网络策略拒绝。 5. 审查网络策略的定义仔细检查您的网络策略定义,确保规则按预期工作。网络策略是基于白名单的,所以只有明确允许的流量才能通过。确保您的放行规则正确无误,并且顺序适当。 6. 使用
|
是的,当您使用 Network Policy 时,可能需要开放一些特定的规则来允许健康检查流量通过。对于 GKE Ingress 的健康检查,您需要开放以下规则:
允许 Ingress 控制器与后端服务通信:
此规则允许 Ingress 控制器与您的服务通信。请将
your-namespace
替换为您的命名空间,将your-app
替换为您的应用的标签选择器,将your-service-port
替换为您服务的端口号。允许后端服务与 GKE 健康检查通信:
此规则允许来自 GKE 健康检查器的流量访问您的服务。GKE 健康检查使用
130.211.0.0/22
和35.191.0.0/16
这两个 CIDR 范围。请将your-namespace
和your-service-port
替换为对应的值。通过应用这两个 NetworkPolicy 规则,您应该能够解决 GKE Ingress 的健康检查问题。请注意,如果您还有其他需求,可能需要进一步调整这些规则。
这里的
namespaceSelector
用于选择 Ingress 控制器所在的命名空间。在 GKE 上,Ingress 控制器通常是部署在kube-system
或gke-system
等系统命名空间中的。具体来说:
project: ingress-controller
是一个标签选择器,用于匹配 Ingress 控制器所在命名空间的标签。kube-system
命名空间通常会有一个标签kubernetes.io/metadata.name=kube-system
。gke-system
命名空间通常会有一个标签name=gke-system
。所以,如果您的 Ingress 控制器位于
kube-system
命名空间,您可以将上面的规则修改为:那么按照上面的这个说法,我应该去检查我对应的控制器位于
kube-system
命名空间一些详细信息 因为我必须允许namespace 的流入 我觉得这个是一个核心问题如果位于
gke-system
命名空间,则修改为:这个规则的目的是允许 Ingress 控制器与您的应用服务进行通信,而不是授权您自己的工程。因为 Ingress 控制器作为中介,需要与后端服务通信来转发流量。
如果不确定 Ingress 控制器所在的命名空间及其标签,可以运行以下命令查看:
然后根据输出结果调整
namespaceSelector
部分即可。在使用 Kubernetes Network Policy 时,如果您的后端服务的健康检查状态变为 unhealthy,可能是由于网络策略过于严格,阻止了健康检查的流量。您需要为健康检查流量开放特殊的规则。
对于 GKE 的内部 Ingress,健康检查流量来自于 GKE 的一些特殊 IP 范围。因此,您需要在 Network Policy 中允许这些 IP 范围的入站流量。具体的规则如下:
在上面的规则中:
130.211.0.0/22
和35.191.0.0/16
是 GKE 的健康检查 IP 范围,您需要允许这些范围的入站流量。your-service-port
是您服务的端口号。app: your-app-label
是您要应用此策略的 Pod 的标签选择器。请注意,如果您使用的是 GKE Ingress,则不需要额外的规则,因为 GKE Ingress 控制器已经对健康检查流量进行了处理。但如果您使用的是自定义 Ingress 控制器或负载均衡器,则需要添加类似的规则。
同时,确保您已经正确配置了 Network Policy 的命名空间选择器,以确保策略应用于正确的命名空间。
The text was updated successfully, but these errors were encountered: