Job with Pod-to-Pod Communication

    Pods within a Job might need to communicate among themselves. The user workload running in each pod could query the Kubernetes API server to learn the IPs of the other Pods, but it’s much simpler to rely on Kubernetes’ built-in DNS resolution.

    Jobs in Indexed completion mode automatically set the pods’ hostname to be in the format of . You can use this format to deterministically build pod hostnames and enable pod communication without needing to create a client connection to the Kubernetes control plane to obtain pod hostnames/IPs via API requests.

    This configuration is useful for use cases where pod networking is required but you don’t want to depend on a network connection with the Kubernetes API server.

    You should already be familiar with the basic use of .

    Your Kubernetes server must be at or later than version v1.21. To check the version, enter kubectl version.

    Note: If you are using MiniKube or a similar tool, you may need to take to ensure you have DNS.

    Starting a Job with Pod-to-Pod Communication

    To enable pod-to-pod communication using pod hostnames in a Job, you must do the following:

    Below is a working example of a Job with pod-to-pod communication via pod hostnames enabled. The Job is completed only after all pods successfully ping each other using hostnames.

    Note: In the Bash script executed on each pod in the example below, the pod hostnames can be prefixed by the namespace as well if the pod needs to be reached from outside the namespace.

    After applying the example above, reach each other over the network using: . You should see output similar to the following:

    Note: Keep in mind that the <pod-hostname>.<headless-service-name> name format used in this example would not work with DNS policy set to or Default. You can learn more about pod DNS policies here.