Do Kubernetes service IPs change?

Question

I'm very new to kubernetes/docker, so apologies if this is a silly question.

I have a pod that is accessing a few services. In my container I'm running a python script and need to access the service. Currently I'm doing this using the services' IP addresses.

Is the service IP address stable or is it better to use environment variables? If so, some tips on doing that would be great.

The opening paragraph of the Services Documentation gives a motivation for services which implies stable IP addresses, but I never see it explicitly stated:

While each Pod gets its own IP address, even those IP addresses cannot be relied upon to be stable over time. This leads to a problem: if some set of Pods (let’s call them backends) provides functionality to other Pods (let’s call them frontends) inside the Kubernetes cluster, how do those frontends find out and keep track of which backends are in that set?

Enter Services.

My pod spec for reference:

kind: Pod
apiVersion: v1
metadata:
  name: fetchdataiso 
  labels:
    name: fetchdataiso
spec:
  containers:
    - name: fetchdataiso 
      image: 192.111.1.11:5000/ncllc/fetch_data
      command: ["python"]
      args: ["feed/fetch_data.py", "-hf", "10.222.222.51", "-pf", "8880", "-hi", "10.223.222.173", "-pi","9101"]

Answer 1

The short answer is "Yes, the service IP can change"

$ kubectl apply -f test.svc.yml
service "test" created

$ kubectl get svc
NAME         CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
kubernetes   10.12.0.1       <none>        443/TCP   10d
test         10.12.172.156   <none>        80/TCP    6s

$ kubectl delete svc test
service "test" deleted

$ kubectl apply -f test.svc.yml
service "test" created

$ kubectl get svc
NAME         CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
kubernetes   10.12.0.1       <none>        443/TCP   10d
test         10.12.254.241   <none>        80/TCP    3s

The long answer is that if you use it right, you will have no problem with it. What is even more important in scope of your question is that ENV variables are way worse then DNS/IP coupling. You should refer to your service by service or service.namespace or even full path like something along the lines of test.default.svc.cluster.local. This will get resolved to service ClusterIP, and in opposite to your ENVs it can get re-resolved to a new IP (which will probably never happen unless you explicitly delete and recreate service) while ENV of a running process will not be changed