As the coderanger mentions, you should not rely on the pod itself as Pods are ephemeral and replaceable. As the Pod is the smallest deployable object in Kubernetes and is considered to be easily replaceable, we should avoid direct interaction with a pod itself; instead, we should interact with the controller which will take care of the Pod. David Maze mentions that you should use the service for managing the pod/pods. What did my predecessors mean is that after you do any changes to the Pod, it might result in a deletion of the pod, after failure it would stop working and if you would interact with your Pod with controllers it would result in recreating.
So to be more clear - your question is "if I will not use the best practices and the advised way of interacting with my cluster what will happen". The answer is - many things can go wrong, and one of them is errors and a lot of unnecessary troubleshooting for you. So what do we advise to you is complying with the set of rules provided by the Kubernetes community and documentation:
As stated here:
In general, Pods do not disappear until someone destroys them. This
might be a human or a controller. The only exception to this rule is
that Pods with a phase of Succeeded or Failed for more than some
duration (determined by terminated-pod-gc-threshold in the master)
will expire and be automatically destroyed.
You should almost always use a controller even in your singleton scenario; controllers provide a lot of advantages like self-healing or replication etc. As coderanger mentioned, StatefullSets can also provide support to stateful pods. More about the durability of Pods here.
Going further we use different types of controllers, so you can avoid direct interaction with a pod:
- Job for Pods that are expected to terminate
- ReplicationController, ReplicaSet, or Deployment for Pods that are not expected to terminate
- DaemonSet Pods that need to run one per machine, because they provide a machine-specific system service
The reason for that is because controllers are resilient and they will survive machine failures which Pods will not. Pods are not durable entities and should not be treated like that. They will not survive scheduling errors, node failures (lack of resource evictions), etc.
Going directly to the essence of the question, you can't assign a static IP to the Pod because of the nature of Kubernetes. Hardcoding the hostname is not a good idea, the closest you can get to your solution is creating StatefullSet as advised by the @coderanger, which will more or less give your Pod a static hostname.
