In this article, you will explore some of the key features of Emissary by walking through an example workflow and exploring the Edge Policy Console.
You must have Emissary installed in your Kubernetes cluster.
Like any other Kubernetes object, Custom Resource Definitions (CRDs) are used to
declaratively define Emissary’s desired state. The workflow you are going to
build uses a sample deployment and the Mapping
CRD, which is the core resource
that you will use with Emissary to manage your edge. It enables you to route
requests by host and URL path from the edge of your cluster to Kubernetes services.
quote.yaml
so that
you can deploy these resources to your cluster. This basic configuration creates
the quote
deployment and a service to expose that deployment on port 80.---
apiVersion: apps/v1
kind: Deployment
metadata:
name: quote
spec:
replicas: 1
selector:
matchLabels:
app: quote
strategy:
type: RollingUpdate
template:
metadata:
labels:
app: quote
spec:
containers:
- name: backend
image: docker.io/datawire/quote:$quoteVersion$
ports:
- name: http
containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
name: quote
spec:
ports:
- name: http
port: 80
targetPort: 8080
selector:
app: quote
Apply the configuration to the cluster with the command kubectl apply -f quote.yaml
.
Copy the configuration below and save it to a file called quote-backend.yaml
so that you can create a Mapping
on your cluster. This Mapping
tells Emissary to route all traffic inbound to the /backend/
path to the quote
service.
---
apiVersion: getambassador.io/v2
kind: Mapping
metadata:
name: quote-backend
spec:
prefix: /backend/
service: quote
Apply the configuration to the cluster with the command
kubectl apply -f quote-backend.yaml
Store the Emissary LoadBalancer
address to a local environment variable.
You will use this variable to test accessing your pod.
export EMISSARY_LB_ENDPOINT=$(kubectl get svc ambassador -o "go-template={{range .status.loadBalancer.ingress}}{{or .ip .hostname}}{{end}}")
$ curl -Lk "http://$EMISSARY_LB_ENDPOINT/backend/"
{
"server": "idle-cranberry-8tbb6iks",
"quote": "Non-locality is the driver of truth. By summoning, we vibrate.",
"time": "2019-12-11T20:10:16.525471212Z"
}
Success, you have created your first Emissary Mapping
, routing a
request from your cluster’s edge to a service!
Emissary provides live diagnostics viewable with a web browser. While this would normally not be exposed to the public network, the Docker demo publishes the diagnostics service at the following URL:
http://localhost:8080/ambassador/v0/diag/
You’ll have to authenticate to view this page: use the username admin
,
password admin
(obviously this would be a poor choice in the real world!).
We’ll talk more about authentication shortly.
To access the Diagnostics page with authentication, use curl http://localhost:8080/ambassador/v0/diag/ -u admin:admin
Some of the most important information - your Emissary version, how recently Emissary’s configuration was updated, and how recently Envoy last reported status to Emissary - is right at the top. The diagnostics overview can show you what it sees in your configuration map, and which Envoy objects were created based on your configuration.
Further explore some of the concepts you learned about in this article:
Mapping
resource: routes traffic from
the edge of your cluster to a Kubernetes serviceHost
resource: sets the hostname by which
Emissary will be accessed and secured with TLS certificatesEmissary has a comprehensive range of features to support the requirements of any edge microservice.
Learn more about how developers use Emissary to manage edge policies.
Learn more about how site reliability engineers and operators run Emissary in production environments.
To learn how Emissary works, use cases, best practices, and more, check out the Quick Start page or read the Emissary Story.
For a custom configuration, you can install Emissary manually.
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.