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
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
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
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
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:
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.