Suppose I have a service containing two pods. One of the pods is an HTTP server, and the other pod needs to hit a REST endpoint on this pod. Is there a hostname that the second pod can use to address the first pod?
Ironically, you answered your own question: a Service
is a stable name and IP that abstracts over the individual coming-and-going of the Pod
s to which it will route traffic, as described very well in the fine manual.
If the-http-pod
needs to reach the-rest-pod
, then create a Service
that matches the labels on the PodSpec
that created the-rest-pod
, and from that point forward the-http-pod
can always use ${serviceName}.${serviceNamespace}.svc.cluster.local
to each any Pod that has matching labels
You can expose your pod kubectl expose deployment --type=name of pod , then you can use the kubectl describe It will show you port number . Then you access you pod at http://localhost:portnumber in last command ....**.....Hope it will help .
I'm assuming when you say "service" you aren't referring to the Kubernetes lexicon of a Service
object, otherwise your two Pods in the Service
would be identical, so let's start by teasing out what a "Service" means in Kubernetes land.
You will have to create an additional Kubernetes object called a Service
to get your hostname for your HTTP server's Pod
. When you create a Service
you will define a .spec.selector
that points to a set of labels on the HTTP service's Pod. For the sake of example, let's say the label is app: nginx
. The name of that Service
object will become the internal DNS record that can be queried by the second Pod
.
A simplified example:
apiVersion: v1
kind: Pod
metadata:
name: http-service
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
---
kind: Service
apiVersion: v1
metadata:
name: my-http-service
spec:
selector:
app: nginx
ports:
- protocol: TCP
port: 80
targetPort: 80
Now your second Pod
can make requests to the HTTP service by the Service
name, my-http-service
.
It's also worth mentioning that Kubernetes best practice dictates that these Pod
s be managed by controllers such as Deployments or ReplicaSets for all sorts of reasons, including high availability of your applications.
Note that a service is a different concept in Docker then in K8s. The easiest way of getting what you want would be creating the two pods; say pod-1
and pod-2
, with a yaml file similar to this one:
apiVersion: v1
kind: Pod
metadata:
name: NAME
labels:
app: LABEL
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
Say NAME and LABEL are nginx
and nginx-1
, so you have now two pods called nginx
and nginx-1
, with labels app: nginx
and app: nginx-1
. Actually, as only one of them is going to be exposed, the other label is irrelevant.
Now you expose the pod either with a yaml file or from command line.
Yaml file:
apiVersion: v1
kind: Service
metadata:
name: server
spec:
ports:
- port: 80
targetPort: 80
protocol: TCP
name: http
selector:
app: nginx
Command line:
kubectl expose pod nginx --port 80 --name server
If you now access the second pod (nginx-1) and curl
the service directly, you would end up hitting the pod behind it (nginx):
nerus:~/workspace $ kubectl exec -it nginx-1 bash
root@nginx-1:/# curl -I server
HTTP/1.1 200 OK