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.

Install Kubernetes Cluster on Debian 10 with Kubespray

Install Kubernetes Cluster on Ubuntu 20.04 using K3s

Easily Setup Kubernetes Cluster on AWS with EKS

Deploy Highly Available Kubernetes Cluster on CentOS 7 using Kubespray

Install Minikube Kubernetes on CentOS with KVM

How To run Minikube on KVM

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   <none>        80:31794/TCP,443:32190/TCP   5h58m
ambassador-admin   ClusterIP   10.233.24.117   <none>        8877/TCP                     5h58m
ambassador-redis   ClusterIP   10.233.8.55     <none>        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

Ambassador

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    <none>        8000/TCP   176m
kubernetes   ClusterIP   10.233.0.1      <none>        443/TCP    5d22h
nginx        ClusterIP   10.233.25.235   <none>        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:

Ambassador

For httpbin:

Ambassador

Conclusion

Installing Ambassador is as simple and as exciting as it has been discussed. There are lots of features that Ambassador ships with and we encourage you to check out its Official Documentation so that you can fully utilize its power.

Otherwise, we continue to appreciate your enormous support and we hope that your year will flourish, your endeavour bear good fruits and your investments pay off handsomely.

Other guides you might enjoy:

Install Kubernetes Cluster on CentOS 7 with kubeadm

Install Istio Service Mesh in EKS Kubernetes Cluster

Authenticate Kubernetes Dashboard Users With Active Directory

Your support is our everlasting motivation,
that cup of coffee is what keeps us going!


As we continue to grow, we would wish to reach and impact more people who visit and take advantage of the guides we have on our blog. This is a big task for us and we are so far extremely grateful for the kind people who have shown amazing support for our work over the time we have been online.

Thank You for your support as we work to give you the best of guides and articles. Click below to buy us a coffee.

LEAVE A REPLY

Please enter your comment!
Please enter your name here