I am trying to port a monolithic app to k8s pods. In theory, pods are considered ephemeral and it is suggested to use service concept to provide a static IP. But in my test so far, I have not seen the POD IP being changed. So now the question when will k8s assign a new IP to my POD?
I have created POD (without using any controller) with fixed hostname and they are bounded to a single node. So the node and the hostname will never change and the POD will never be deleted? So in this unique case, when can the POD IP change. I looked at the documentation and this is not clear to me.
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
phaseof Succeeded or Failed for more than some duration (determined byterminated-pod-gc-thresholdin 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.
The IP won't change as long as the pod is running, but there are no promises that your pod will stay running. The closest there is to a stable network name is with a StatefulSet. That will create a consistent pod name, which means a consistent DNS name in kubedns/coredns. There is no generic way in Kubernetes to get long-term static IP on a pod (or on a service for that matter), though it's technically up to your CNI networking plugin so maybe some of those have special cases?
If you launch multiple replicas of the pod in a deployment, the pod IP address will change. If you change the base container and relaunch the pod, the new pod will probably have a different IP address.
You claim "the pod will never be deleted" but this is a very strong, and unusual, claim in Kubernetes. The typical way to update an application or the base OS container underneath it is to build a new Docker image and redeploy it, which will result in deleting the pod and its IP address changing.
You should in any case create a Kubernetes service referencing the pod. The service will provide a DNS name within the cluster, which will be stable and under your control. From other applications running in the cluster you can reference servicename.namespacename.svc.cluster.local as a host name.