To build these microservices, navigate to the
start directory and run the following command.
Next, run the
docker build commands to build container images for your application:
docker build -t system:1.0-SNAPSHOT system/.
docker build -t inventory:1.0-SNAPSHOT inventory/.
-t flag in the
docker build command allows the Docker image to be labeled (tagged) in the
name[:tag] format. The tag for an image describes the specific image version. If the optional
[:tag] tag is not specified, the
latest tag is created by default.
When the builds succeed, run the following command to deploy the necessary Kubernetes resources to serve the applications.
kubectl apply -f kubernetes.yaml
Use the following command to view the status of the pods. There will be two
system pods and one
inventory pod, later you’ll observe their behavior as the
system pods become unhealthy.
NAME READY STATUS RESTARTS AGE
system-deployment-694c7b74f7-hcf4q 1/1 Running 0 59s
system-deployment-694c7b74f7-lrlf7 1/1 Running 0 59s
inventory-deployment-cf8f564c6-nctcr 1/1 Running 0 59s
Wait until the pods are ready. After the pods are ready, you will make requests to your services.
The default host name for Docker Desktop is
The default host name for minikube is 192.168.99.100. Otherwise it can be found using the
minikube ip command.
http://[hostname]:31000/system/properties and observe a response containing JVM system properties. Replace
[hostname] with the IP address or host name of your Kubernetes cluster. The readiness probe ensures the READY state won’t be
1/1 until the container is available to accept requests. Without a readiness probe, you may notice an unsuccessful response from the server. This scenario can occur when the container has started, but the application server hasn’t fully initialized. With the readiness probe, you can be certain the pod will only accept traffic when the microservice has fully started.
Similarly, navigate to
http://[hostname]:32000/inventory/systems/system-service and observe that the request is successful.