aibangjuxin
commented
1 month ago 在使用 GKE (Google Kubernetes Engine) 配置内部负载均衡器时，如果启用了网络策略，如 Calico，可能需要特别注意确保健康检查流量能够正常通过。网络策略可以控制 Pod 之间的通信，如果不正确配置，可能会阻止来自 GKE 控制平面的健康检查流量，导致服务状态显示为 unhealthy。
解决方案
-
允许来自 GKE 控制平面的流量： GKE 的健康检查通常来自于 GKE 控制平面。因此，您需要确保网络策略允许来自控制平面（通常是 Google Cloud 的内部 IP 地址）的入站流量到达您的 Pod。这可以通过在 Calico 网络策略中明确允许这些 IP 地址来实现。
-
配置适当的标签和选择器： 确保您的网络策略正确地使用标签选择器来识别和允许健康检查流量。例如，您可能需要为执行健康检查的 GKE 系统 Pod 设置特定的标签，并在网络策略中引用这些标签。
-
检查和调整现有的网络策略： 如果已经有网络策略在运行，需要仔细检查这些策略是否无意中阻止了健康检查流量。可能需要调整或添加新的策略规则来特别允许这些流量。
示例网络策略
以下是一个 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控制平面IP范围> 为实际的 IP 地址范围，并确保 selector 正确匹配您的应用 Pod 的标签。此外，端口 10256 应替换为您的应用实际使用的健康检查端口。
结论
正确配置网络策略是确保 GKE 内部负载均衡器能够正常进行健康检查的关键。如果遇到问题，建议详细检查现有的网络策略设置，并根据需要进行调整。如果问题仍然存在，可能需要进一步检查日志和监控数据，或者联系 Google Cloud 支持获取帮助。
Sources [1] Configuring Ingress for internal Application Load Balancers | Google Kubernetes Engine (GKE) | Google Cloud https://cloud.google.com/kubernetes-engine/docs/how-to/internal-load-balance-ingress [2] Control communication between Pods and Services using network ... https://cloud.google.com/kubernetes-engine/docs/how-to/network-policy [3] Get started with Calico network policy https://docs.tigera.io/calico/latest/network-policy/get-started/calico-policy/calico-network-policy [4] GKE Dataplane V2 | Google Kubernetes Engine (GKE) https://cloud.google.com/kubernetes-engine/docs/concepts/dataplane-v2 [5] Support Project Network Policy (PNP) for Project level ... - GitHub https://github.com/rancher/rancher/issues/14085 [6] Allow only in-cluster ingress for calico network policy - Stack Overflow https://stackoverflow.com/questions/71433996/allow-only-in-cluster-ingress-for-calico-network-policy [7] Calico on Kubernetes 从入门到精通 https://www.kubernetes.org.cn/4960.html [8] 容器网络calico 基本原理和模拟- 不认命？就拼命！ https://zhdya.gitee.io/zhdya/2019/04/22/%E5%AE%B9%E5%99%A8%E7%BD%91%E7%BB%9C%20calico%20%E5%9F%BA%E6%9C%AC%E5%8E%9F%E7%90%86%E5%92%8C%E6%A8%A1%E6%8B%9F/ [9] gke pods not able to ping the gce's when using calico #2813 - GitHub https://github.com/projectcalico/calico/issues/2813 [10] Network policy | Calico Documentation - Tigera https://docs.tigera.io/calico-enterprise/latest/reference/resources/networkpolicy [11] K8S Calico网络插件- RidingWind - 博客园 https://www.cnblogs.com/RidingWind/p/16301622.html [12] Kubernetes policy, advanced tutorial - Calico Documentation - Tigera https://docs.tigera.io/calico/latest/network-policy/get-started/kubernetes-policy/kubernetes-policy-advanced [13] Calico网络策略详解 - 偷得浮生 https://zhangzhuo.ltd/articles/2022/08/24/1661307737007.html [14] DevOps/kubernetes/calico介绍-原理与使用.md at master - GitHub https://github.com/yangpeng14/DevOps/blob/master/kubernetes/calico%E4%BB%8B%E7%BB%8D-%E5%8E%9F%E7%90%86%E4%B8%8E%E4%BD%BF%E7%94%A8.md [15] calico rr - 滴滴滴- 博客园 https://www.cnblogs.com/gaoyuechen/p/16889157.html [16] calico多网口配置原创 - CSDN博客 https://blog.csdn.net/vah101/article/details/110234028
您遇到的问题很有可能是由于 Network Policy 的规则过于严格而导致的。当您应用了 Network Policy 后,Kubernetes 会根据这些规则来控制进出 Pod 的流量,如果规则太严格可能会阻止了正常的流量。
要解决这个问题,您需要在 Network Policy 中添加合适的规则,以允许以下流量:
- 允许 GKE Ingress 控制器与您的 Service 通信。
- 允许健康检查的流量到达您的 Pod。
具体来说,您可以尝试添加以下规则:
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 命名空间的流量访问您的 Service 端口。
- 允许来自外部的健康检查流量访问您的 Service 端口,但排除了内部 IP 范围。
您需要根据您的实际情况调整 your-namespace、your-app-label、your-service-port 等参数。
如果上述规则无法解决您的问题,您可能需要进一步检查您的网络插件配置,或者查看 Ingress 控制器日志以获取更多信息。
我认为下面这个允许load balanced ip也可能有道理 You've followed the guide to set up an internal GKE ingress, and you're experiencing issues with the backend service health check when using network policies.
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
- Identify the internal load balancer's IP address range. You can do this by running
kubectl describe ingress <ingress-name> -n <ingress-namespace> | grep "LoadBalancer Ingress"and looking for theipRangesfield. - Create a network policy that allows traffic from the internal load balancer's IP address range to your backend service. You can use the following YAML as a starting point:
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: - IngressReplace
<load-balancer-ip-range>with the IP address range of the internal load balancer, and<your-backend-service-app-label>with the label of your backend service.
Apply the network policy
Run kubectl apply -f <network-policy-yaml> to create the network policy.
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 kubectl describe ingress <ingress-name> -n <ingress-namespace>.
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 时,可能需要开放一些特定的规则来允许健康检查流量通过。对于 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 的命名空间选择器,以确保策略应用于正确的命名空间。