Skip to content

Latest commit

 

History

History
67 lines (48 loc) · 3.04 KB

README.adoc

File metadata and controls

67 lines (48 loc) · 3.04 KB
Raw

Ambassador

To try out this example, you need access to a Kubernetes cluster, e.g., by choosing one of the options from the INSTALL.

In this example, we create a simple ambassador that abstracts away a logging backend. The main random-generator service logs each incoming request by sending the generated data to a URL specified via the environment variable LOG_URL. We use this LOG_URL to connect to an ambassador listening on localhost at port 9009. The ambassador is responsible for forwarding the log data to a suitable log service.

For simplicity, we use a basic ambassador that logs the data to standard output. This ambassador utilizes a simple Node.js HTTP server within the container image k8spatterns/random-generator-log-ambassador. You can find this image in the image directory (Dockerfile and Node.js code), or directly on Docker Hub.

Let’s create a bare Pod with k8spatterns/random-generator as the main container and k8spatterns/random-generator-log-ambassador as the ambassador:

kubectl create -f https://k8spatterns.io/Ambassador/pod.yml

To enable external access to the random generator, we use a nodePort service:

kubectl create -f https://k8spatterns.io/Ambassador/service.yml

This service leverages nodePort to expose its port on every cluster node. For simple testing, this approach works well. Alternatively, you can use a full ingress or load-balancer exposed route as described in the Service Discovery pattern.

Assuming you are using Minikube, we can access and expose the service using the following command:

minikube service random-generator --url > /tmp/random-url.txt &

This command starts a tunnel in the background and writes down the access URL for the two exposed ports. We store these URLs in a text file to access the service with the following command:

curl $(cat /tmp/random-url.txt)

Now we can verify if our ambassador has been contacted with the appropriate data:

kubectl logs -f random-generator -c ambassador

You can also run this command in the background and re-run the curl program to see how the sidecar container is called for each request.

The logs will display an output like this:

==========================================
Starting up random-generator ambassador
Listening at http://localhost:9009
==========================================
Message received for processing:
>>> ID: d822e648-0f41-4c4f-ae3a-1ced14d2b4a2 -- Duration: 35318 -- Random: 355610385
Message received for processing:
>>> ID: d822e648-0f41-4c4f-ae3a-1ced14d2b4a2 -- Duration: 10080 -- Random: 294941020
Message received for processing:
>>> ID: d822e648-0f41-4c4f-ae3a-1ced14d2b4a2 -- Duration: 21987 -- Random: 1345536975