Use context: kubectl config use-context k8s-c1-H
Do the following in Namespace default. Create a single Pod named ready-if-service-ready of image nginx:1.16.1-alpine. Configure a LivenessProbe which simply executes command true. Also configure a ReadinessProbe which does check if the url http://service-am-i-ready:80 is reachable, you can use wget -T2 -O- http://service-am-i-ready:80 for this. Start the Pod and confirm it isn’t ready because of the ReadinessProbe.
Create a second Pod named am-i-ready of image nginx:1.16.1-alpine with label id: cross-server-ready. The already existing Service service-am-i-ready should now have that second Pod as endpoint.
Now the first Pod should be in ready state, confirm that.
Using Readiness Probes for Pod-to-Pod Communication in Kubernetes
In Kubernetes, readiness probes are used to determine when a Pod is ready to serve traffic. While it’s an anti-pattern for one Pod to check another Pod’s readiness directly, this guide will demonstrate how probes and Pod-to-Service communication can be configured to achieve the desired behavior.
Step 1: Create the First Pod
First, we need to create the initial Pod that will use a readiness probe to check the availability of a service. Use the following command to generate the Pod YAML configuration:
|
1 2 3 4 5 |
kubectl run ready-if-service-ready --image=nginx:1.16.1-alpine --dry-run=client -o yaml > 4_pod1.yaml |
Next, open the 4_pod1.yaml file and manually add the necessary readiness probe configuration:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
apiVersion: v1 kind: Pod metadata: labels: run: ready-if-service-ready name: ready-if-service-ready spec: containers: - image: nginx:1.16.1-alpine name: ready-if-service-ready livenessProbe: # add from here exec: command: - 'true' readinessProbe: exec: command: - sh - -c - 'wget -T2 -O- http://service-am-i-ready:80' # to here dnsPolicy: ClusterFirst restartPolicy: Always |
This setup uses a simple wget command to check the availability of the service service-am-i-ready on port 80.
Step 2: Deploy the First Pod
Now, create the Pod using the updated configuration:
|
1 2 3 4 5 |
kubectl apply -f 4_pod1.yaml |
After deployment, the Pod should be in a non-ready state since the service it depends on isn’t available yet:
|
1 2 3 4 5 6 7 |
➜ kubectl get pod ready-if-service-ready NAME READY STATUS RESTARTS AGE ready-if-service-ready 0/1 Running 0 7s |
To investigate further, you can describe the Pod and see the reason for its non-readiness:
|
1 2 3 4 5 6 7 8 |
➜ kubectl describe pod ready-if-service-ready ... Warning Unhealthy 18s kubelet, cluster1-node1 Readiness probe failed: Connecting to service-am-i-ready:80 (10.109.194.234:80) wget: download timed out |
Step 3: Create the Second Pod
Now, create the second Pod that will satisfy the readiness probe of the first Pod:
|
1 2 3 4 5 |
kubectl run am-i-ready --image=nginx:1.16.1-alpine --labels="id=cross-server-ready" |
Once the second Pod is running, the existing Service service-am-i-ready should automatically have an endpoint. You can confirm this by describing the service or checking the endpoints:
|
1 2 3 4 5 6 |
kubectl describe svc service-am-i-ready kubectl get ep # also possible |
Step 4: Verify the Readiness of the First Pod
After the second Pod is up and the service has an endpoint, the first Pod should become ready after the readiness probe checks again:
|
1 2 3 4 5 6 7 |
➜ kubectl get pod ready-if-service-ready NAME READY STATUS RESTARTS AGE ready-if-service-ready 1/1 Running 0 53s |
Now both Pods are working together, demonstrating how readiness probes can be used for Pod-to-Service communication in Kubernetes.
Although this is an unconventional approach, it showcases the flexibility of readiness probes and the Pod-to-Service communication model in Kubernetes. By carefully configuring probes, you can manage dependencies between services effectively.