I have a bunch of servers that spread across the global. I want to provide services like pinging a user's ip from different servers to report latency from different parts of the world.
Should I use Kubernetes to manage these servers?
By managing I mean things like make sure there is one pod in each region that is live to provide the ping service, gracefully update pods in all regions, etc.
From the docs it seems Kubernetes assumes that nodes should live close to each other, and the cluster should live inside the same network.
If Kubernetes isn't suitable for such tasks, what options do I have? Should I manage them manually?
I would not recommmend Kubernetes for this use case (as I understand it). There are a couple of reasons:
You are correct that Kubernetes generally assumes that clusters are not geographically dispersed.
The Kubernetes load balancing mechanisms for incoming traffic are relatively simple, and would not be able to do the sort of geo-load balancing you're describing. Thus, you'd still need some sort of external GSLB-type solution anyway.
As for what options you have, there are a variety of potential approaches. One approach (and by far not the only approach) would be to use EC2 instances in multiple AWS regions. If you use Auto-Scaling Groups you could ensure that at least one EC2 instance is always up. You may be able to get some GSLB-type functionality through Route53 and ELBs, but whether this is sufficient for your use case is unclear without more information.