API Endpoints¶
Below, we demonstrate calling endpoints on the application in either of two ways:
- Internally from within the Kubernetes cluster
-
Through the "front door", via the ingress gateway
The environment variable
LB_IP
captures the public IP address of the load balancer fronting the ingress gateway. We can access the service endpoints through that IP address.
Deploy the sleep
client¶
We make use of Istio's sleep sample application to facilitate the task of making calls to workloads from inside the cluster.
The sleep
deployment is a blank client Pod that can be used to send direct calls to specific microservices from within the Kubernetes cluster.
Deploy sleep
to your cluster:
Wait for the sleep pod to be ready (2/2 containers).
Test individual service endpoints¶
We assume that you have the excellent jq utility already installed.
Call the "Vets" controller endpoint¶
Customers service endpoints¶
Here are a couple of customers-service
endpoints to test:
Give the owner George Franklin a new pet, Sir Hiss (a snake):
This can also be performed directly from the UI.
The Visits service¶
Test one of the visits-service
endpoints:
PetClinic Frontend¶
Call petclinic-frontend
endpoint that calls both the customers and visits services:
Summary¶
Now that we have some familiarity with some of the API endpoints that make up this application, let's turn our attention to configuring a small aspect of resilience: timeouts.