Install Ambassador Ingress Controller on Kubernetes

7 min readOct 9, 2022

Kubernetes has afforded many enterprises the robustness, the resilience, the efficiency, reliability, scale and all of those sweet words that were literally difficult to achieve in the past. What is worth mentioning is that it has significantly reduced operational expenses while bringing more to the table. With this, everyone is happy. The developers enjoy the simplicity and speed it provides while the finance department has no reason to lament because they are spared from spending on extra servers quite often.

As you know, applications on your Kubernetes cluster can be accessed by outside clients in three avenues. You can configure your services to be exposed through NodePorts, LoadBalancers or by employing an Ingress Controller in your Cluster. In this guide, we are going to setup one of the many Ingress Controllers available. We are going to install Ambassador API Gateway & Ingress Controller then use it to access services deployed in your cluster. It is going to be a wonderful errand. Make sure your juices are ready for sipping along the way.

To begin, we shall acquaint ourselves with this tool then go ahead and leverage it powerful features. From its GitHub Page, Ambassador API Gateway is an open-source Kubernetes-native API Gateway + Layer 7 load balancer + Kubernetes Ingress built on Envoy Proxy. The Ambassador Edge Stack is a complete superset of the OSS Ambassador API Gateway that offers additional functionality. Ambassador is designed to easily expose, secure, and manage traffic to your Kubernetes microservices of any type. Ambassador was built around the ideas of self-service (enabling GitOps-style management) and comprehensiveness (so it works with your situations and technology solutions).

Briefly, the Ambassador API Gateway enables its users to:

Manage ingress traffic with load balancing, protocol support(gRPC and HTTP/2, TCP, and web sockets), and Kubernetes integration
Manage changes to routing with an easy to use declarative policy engine and self-service configuration, via Kubernetes CRDs or annotations
Secure microservices with authentication, rate limiting, TLS, automatic HTTPS, and custom request fiters
Ensure high availability with sticky sessions, rate limiting, and circuit breaking
Leverage observability with integrations with Grafana, Prometheus, and Datadog, and comprehensive metrics support
Set up shared development environments with Service Preview
Onboard developers with a Developer Portal
Enable progressive delivery with canary releases
Connect service meshes including Consul, Linkerd, and Istio
Knative serverless integration

Pre-requisites

For us to be able to install Ambassador API Gateway & Ingress Controller, we are assuming you already have a running Kubernetes cluster. In case you do not have one already running, you can use our previous guides below to bootstrap one as quickly as you can.

Also ensure that you can run kubectl command on your user account.

Step 1: Get Ambassador Installation files

Once we download Ambassador manifest files, there are two ways that we can install Ambassador Ingress. One way is installing and exposing it via a NodePort and the other way is installing and exposing it via a LoadBalancer. As you can guess, if you are within an infrastructure that has a LoadBalancer such as in AWS, GCP and others, the best approach is utilizing the LoadBalancer Type. On the other hand, if you have a cluster without any Load Balancer, then using a NodePort to expose your Ingress Controller is still fine. Download the files as follows

wget https://www.getambassador.io/yaml/aes-crds.yaml

wget https://www.getambassador.io/yaml/aes.yaml

Now edit the “aes.yaml” file by changing LoadBalancer to NodePort in case you have no LoadBalancer resource. Look for the ambassador service beginning at around line 206. In the spec section, you have the liberty to choose NodePort or leave is as LoadBalancer. For this example, we are going to use NodePort.

$ vim aes.yaml

apiVersion: v1

kind: Service

metadata:

  name: ambassador

  namespace: ambassador

  labels:

    product: aes

    app.kubernetes.io/component: ambassador-service

spec:

  #type: LoadBalancer

  type: NodePort

  ports:

  - name: http

    port: 80

    targetPort: http

  - name: https

    port: 443

    targetPort: https

  selector:

    service: ambassador

Edit the file accordingly, save it then exit

Step 2: Deploy Ambassador on Kubernetes

Once the edits are done to your satisfaction, what remains is to simply apply the manifests into out Kubernetes Setup. Simply execute the commands below

$ kubectl apply -f aes-crds.yaml



##Then



$ kubectl apply -f aes.yaml

Confirm that the pods were deployed Successfully

$ kubectl get pods -n ambassador

NAME                                READY   STATUS    RESTARTS   AGE  

ambassador-6696d6997-vvh8v          1/1     Running   0          5h56m

ambassador-redis-584cd89b45-6zrmh   1/1     Running   0          5h56m

Check the CRDs. Note that the list below has been truncated

$ kubectl get crd -n ambassador                                                                           

NAME                                                  CREATED AT

authservices.getambassador.io                         2021-02-01T09:28:17Z

bgpconfigurations.crd.projectcalico.org               2021-01-27T11:40:19Z

bgppeers.crd.projectcalico.org                        2021-01-27T11:40:18Z

blockaffinities.crd.projectcalico.org                 2021-01-27T11:40:18Z

clusterinformations.crd.projectcalico.org             2021-01-27T11:40:20Z

consulresolvers.getambassador.io                      2021-02-01T09:28:17Z

devportals.getambassador.io                           2021-02-01T09:28:18Z

felixconfigurations.crd.projectcalico.org             2021-01-27T11:40:17Z

filterpolicies.getambassador.io                       2021-02-01T09:28:28Z

filters.getambassador.io                              2021-02-01T09:28:30Z

globalnetworkpolicies.crd.projectcalico.org           2021-01-27T11:40:20Z

globalnetworksets.crd.projectcalico.org               2021-01-27T11:40:21Z

hostendpoints.crd.projectcalico.org                   2021-01-27T11:40:20Z

hosts.getambassador.io                                2021-02-01T09:28:19Z

ipamblocks.crd.projectcalico.org                      2021-01-27T11:40:17Z

As well as the Services

$ kubectl get svc -n ambassador

NAME               TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)                      AGE

ambassador         NodePort    10.233.31.133           80:31794/TCP,443:32190/TCP   5h58m

ambassador-admin   ClusterIP   10.233.24.117           8877/TCP                     5h58m

ambassador-redis   ClusterIP   10.233.8.55             6379/TCP                     5h58m

If you are using NodePort, you will notice two ports assigned to ambassador service. One is for pure http and another is for https.

You can access Ambassador Dashboard by pointing your browser to

https://anynodeip-or-FQDN:NodePort

The ingress resource will now make it possible to expose multiple services using a singular external endpoint, a load balancer, or both at once. Taking this approach, teams can enact host, prefix, and other rules to route traffic to defined services however they prefer.

Step 3: Install Sample application and expose via Ingresss Controller

In this step, we are going to deploy httpbin and nginx applications then use our installed Ambassador Ingress controller to access them.

Fetch httpbin as follows

wget https://github.com/istio/istio/raw/master/samples/httpbin/httpbin.yaml

httpbin service is a NodePort by default. But since we now have an Ingress Controller, let us edit this file and remove the NodePort. Look for the Service kind then check under spec. Comment “type: NodePort” as shown below

$ vim httpbin.yaml

---

apiVersion: v1

kind: Service

metadata:

  name: httpbin

  labels:

    app: httpbin

    service: httpbin

spec:

  #type: NodePort    ##Comment this line

  ports:

  - name: http

    port: 8000

    targetPort: 80

  selector:

    app: httpbin

Then install using kubectl

kubectl apply -f httpbin.yaml

In case you would wish it to be deployed in a different namespace, simply edit the file before applying it.

Create a custom Nginx deployment and service as follows:
We shall have three pods here. You can reduce them depending on your needs.

$ vim nginx.yaml

apiVersion: apps/v1

kind: Deployment

metadata:

  name: nginx-deployment

  labels:

    app: nginx

spec:

  replicas: 3     ##Three pods to be deployed

  selector:

    matchLabels:

      app: nginx

  template:

    metadata:

      labels:

        app: nginx

    spec:

      containers:

      - name: nginx

        image: nginx:1.15.4

        ports:

        - containerPort: 80

---

apiVersion: v1

kind: Service

metadata:

  name: nginx

  labels:

    app: nginx

    service: nginx

spec:

  ports:

  - name: http

    port: 8511

    targetPort: 80

  selector:

    app: nginx

Then install it in your cluster

kubectl apply -f nginx.yaml

Confirm that both deployments are running

$ kubectl get deploy -n default



NAME               READY   UP-TO-DATE   AVAILABLE   AGE

httpbin            1/1     1            1           168m

nginx-deployment   3/3     3            3           4h16m

As well as both services

NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE

httpbin      ClusterIP   10.233.23.90            8000/TCP   176m

kubernetes   ClusterIP   10.233.0.1              443/TCP    5d22h

nginx        ClusterIP   10.233.25.235           8511/TCP   4h25m

Step 4: Create Ambassador Mappings for both Applications

Until now, we have a working ingress controller and two sample deployments (nginx and httpbin) that we shall use to test how it works. Create the following Ambassador Ingress Mapping resource that will target httpbin and nginx. If you read the manifests we fetched earlier, you will notice that it creates a service called “httpbin” and “nginx” respectively. Moreover, they will be listening at ports 8000 and 8511 respectively. Armed with this information, let us create an Ingress thus:

$ vim httpbin-nginx-mapping.yaml

##For httpbin

---

apiVersion: getambassador.io/v2

kind:  Mapping

metadata:

  name:  httpbin-backend

spec:

  prefix: "/"

  timeout_ms: 4000

  service: httpbin:8000  ##Service name and its port



##For Nginx

---

apiVersion: getambassador.io/v2

kind:  Mapping

metadata:

  name:  nginx-backend

spec:

  prefix: "/nginx/"

  timeout_ms: 4000

  service: nginx:8511    ##Service name and its port

Once done, save the file then apply it in your cluster.

kubectl apply -f httpbin-nginx-mapping.yaml

What is happening here is that, any traffic that will come from “https://hostip:nodeport/” root url (/), will be routed to the httpbin service automatically. Similarly, any traffic hitting the https://hostip:nodeport/nginx/ url will be routed to your nginx pod. Note that hostip is any of your Kubernetes nodes IPs and NodePort is the port created when Ambassador was installed. If you are using a LoadBalancer, you will access your services using https://LoadBalancerIP/ for httpbin and https://LoadBalancerIP/nginx/ for nginx.

What else are we left to do than to test if we can reach our serivice?

Ensure that your NodePort has been allowed in the firewall of any node of your choice then open your browser and point it to ant of your urls. You can also use a FQDN resolving to any of your Kubernetes nodes if you are using NodePort

You should see something eye popping as shown below:

For Nginx: