I have created a cluserIP service (I'm in Google Kubernetes GKE), and I need to know the DNS to use it in another pod, here is the result of the command : kubectl describe service book-service -n library
Result :
Name: book-service
Namespace: library
Labels: app=book-app
Annotations: cloud.google.com/neg: {"ingress":true}
Selector: app=book-app
Type: ClusterIP
IP Family Policy: SingleStack
IP Families: IPv4
IP: 10.116.9.139
IPs: 10.116.9.139
Port: http 7002/TCP
TargetPort: 7002/TCP
Endpoints: 10.112.4.32:7002
Session Affinity: None
Events: <none>
So my service adress (to be used in other pods) will be :
book-service.library.svc.cluster.local
or
book-service.library.svc.cluster.local:7002
Also I didn't saw why there are 2 IP adresses : 10.116.9.139 and endpoint 10.112.4.32 ?
CodePudding user response:
Try running
kubectl run busybox --image=busybox --restart=Never -n library -it --rm -- /bin/sh
/ # wget --spider --timeout=5 book-service.library.svc.cluster.local
Connecting to book-service.library.svc.cluster.local (10.112.4.32:target-port)
wget: download timed out
/ # wget --spider --timeout=5 book-service.library.svc.cluster.local:{port}
Connecting to book-service.library.svc.cluster.local:{port}(10.112.4.32:port)
remote file exists
/ # exit
In your case, port and target-port are same. so you would get same remote file exists
for both cases.
Had they been different, answer would be similar to mine
So, use book-service.library.svc.cluster.local:{port}
Virtual IP or IP you have shown are assigned by Kubernetes control plane. They allow Kubernetes to abstract away the details of where the service is running and provide a consistent way for other pods to access it.
CodePudding user response:
If the Service name is book-service
and the namespace name is library
, then you can just combine these together to make a DNS name; book-service.library
. This is probably under some other top-level domain (usually but not necessarily svc.cluster.local
) but this will be included in the DNS configuration that's injected into the Pods. Also see DNS for Services and Pods in the Kubernetes documentation.
If the Service is listening on port 7002 then you need to include that in a URL or other connection settings, but that port number is not part of the DNS name per se. (If it's an HTTP service, I've found it convenient to configure Services to use the standard HTTP port 80, regardless of what the underlying Pod is using.)
You don't directly need any of the kubectl inspect service
output.
The Service itself has an IP address (it is essentially a dumb load balancer) and that address is in the IP:
field; it will also be the address that book-service.library.svc.cluster.local
resolves to. The Service matches some number of Pods, which also have IP addresses, and the Pods' IP addresses are the Endpoints:
. You usually don't care about the endpoint addresses, except that Endpoints: <none>
often means the Service's selector doesn't match the intended pod labels.
CodePudding user response:
Kubernetes creates DNS records for Services and Pods. You can contact Services with consistent DNS names instead of IP addresses.
Kubernetes publishes information about Pods and Services which is used to program DNS. Kubelet configures Pods' DNS so that running containers can lookup Services by name rather than IP.
Services defined in the cluster are assigned DNS names. By default, a client Pod's DNS search list includes the Pod's own namespace and the cluster's default domain.
Namespaces of Services