# HG changeset patch # User enis # Date 1753398100 0 # Node ID 7c660a6be0685bbd9f5df61f8f0f95307cdfba17 # Parent fcfb703748b1618f4e1097f3441b046ed5023071 planemo upload for repository https://github.com/afgane/gcp_batch_netcat commit ece227052d14d755b0d0b07a827152b2e98fb94b-dirty diff -r fcfb703748b1 -r 7c660a6be068 gcp_batch_netcat.xml --- a/gcp_batch_netcat.xml Thu Jul 24 22:32:12 2025 +0000 +++ b/gcp_batch_netcat.xml Thu Jul 24 23:01:40 2025 +0000 @@ -17,9 +17,9 @@ + - @@ -39,8 +39,7 @@ To find the correct IP address, run: ``` -kubectl get svc | grep nfs -kubectl get svc -o wide +kubectl get svc -n nfs-provisioner ``` Look for the "EXTERNAL-IP" column for LoadBalancer type services. @@ -49,17 +48,5 @@ For NFS connectivity from GCP Batch jobs, your NFS server must be exposed via a LoadBalancer service with an external IP. Internal ClusterIP services are not accessible from external Batch workers. -**Troubleshooting Network Issues** - -The tool helps identify the root cause of connectivity issues: -- **Connection timeouts**: Usually indicates firewall rules blocking traffic or NFS service not accessible externally -- **DNS resolution failures**: May indicate DNS configuration issues -- **Wrong IP address**: Ensure you're using the LoadBalancer external IP, not the ClusterIP - -**Best Practices** - -1. Ensure your NFS service is exposed as type LoadBalancer with an external IP -2. Verify GCP firewall rules allow traffic from Batch subnet to NFS LoadBalancer IP on port 2049 -3. Test the connection manually: `telnet 2049` ]]>