# 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`
]]>