The Ambassador Ingress Controller is an open-source software package used to create and manage secure connections between cloud-based applications, services, and users. It is quickly gaining popularity as a powerful tool for creating and managing secure connections between applications and services in the cloud.
For many organizations, managing secure connections between applications and services is becoming increasingly important as the cloud becomes more complex and dynamic. Leveraging the Ambassador Ingress Controller is one of the best ways to ensure that all components of the cloud ecosystem have secure access to each other.
This tutorial will demonstrate how to install and configure the Ambassador Ingress Controller on a Kubernetes cluster. Installing the Ambassador Ingress Controller is an easy process and involves installing the Helm Chart and setting up an ingress-controller deployment. The following steps will guide you through the installation process.
First, download the Helm Chart for the Ambassador Ingress Controller. Next, generate the authsecret.yaml file which is required for authentication and authorization. Upload the authsecret.yaml to your Kubernetes cluster.
Next, create a service account by running kubectl create sa ambassador. This service account is used to authenticate your clusters against the remote services such as Kubernetes Dashboard. On each node where Ambassador will run, create an RBAC role that grants access to the necessary APIs and resources.
Next, install the Ambassador Ingress Controller and create a deployment. To create the deployment, simply run the script in the Helm Chart directory and configure the deployment with the necessary settings. Finally, configure the Ambassador Ingress Controller in your Kubernetes cluster by editing the daemonset.yml and ingress-controller.yml files.
After completing these steps, the Ambassador Ingress Controller will be installed and ready to go. With the Ambassador Ingress Controller, users can easily configure secure and reliable connections between cloud-based applications, services, and users. By configuring the Ambassador Ingress Controller, organizations will be able to significantly improve the security of their cloud environments.
We hope this tutorial has helped you successfully install the Ambassador Ingress Controller on your Kubernetes cluster. With the help of the Ambassador Ingress Controller, organizations will be able to manage secure connections between applications and services accurately and easily.
Install Ambassador Ingress Controller on Kubernetes. 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.yamlNow 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: ambassadorEdit 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.yamlConfirm 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 5h56mCheck 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:17ZAs 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
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.yamlhttpbin 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: httpbinThen install using kubectl
kubectl apply -f httpbin.yamlIn 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: nginxThen install it in your cluster
kubectl apply -f nginx.yamlConfirm 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 4h16mAs 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 4h25mStep 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 portOnce done, save the file then apply it in your cluster.
kubectl apply -f httpbin-nginx-mapping.yamlWhat 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:
For httpbin:
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:
