Microservices simplified with Kubernetes + Consul +Ambassador + Spring + Python + Go + Terraform

Get started with your microservices infrastructure with just one command using the Microservices Rightstart Kit (MRK).

Microservices can solve a lot of problems faced with the monolith approach like:

  1. Scalability
  2. Performance
  3. Productivity
  4. Polyglot solutions

But, this brings in a whole new set of problems to address with the microservices way. The most common things to be taken care of are:

  1. Service discovery — How does a service identify another service to communicate? How will this be managed independent of service/business logic?
  2. Secure service to service communication — In the cloud, services may run on different machines, hence those inter-service communications should be highly secure.
  3. Service Management/Orchestration — What happens when a service/container stopped responding? How can a sudden peak in incoming traffic be handled?
  4. Infrastructure management — With many different services to be managed, handling this as a single entity is a challenge.

Solution:

  1. Kubernetes — Orchestration
  2. Consul — Service discovery + Service Mesh
  3. Ambassador — API Gateway

This entire setup is managed using

  1. Helm Charts — Service level management on k8s
  2. Terraform — Manage complete Infrastructure

There are a lot of other options in the market for all the above use-cases. And these are the ones that integrate well with each other.

Consul connect uses Envoy as proxy and Ambassador is built on the Envoy proxy

Once you have all the above pieces in place, all you need is your application services.

Here’s the Github repo link to MRK — https://github.com/codaglobal/microservices-rightstart-kit/

Architecture:

Application development Strategy:

The whole cycle of DevOps is becoming easier with native integrations of infrastructure with application code. For example, Spring Cloud provides integration with Kubernetes, consul, vault,…
But, this becomes trouble in the future when the infrastructure demands a migration to different tools. For example, If you want to migrate from Kubernetes to Hashicorp Nomad, or move from vault to any other secret store, it brings in a burden to change the application code.

Hence, the best way for application development is to be away from any infrastructure related implementations.

Let the application/service do just what it needs to do.

In this MRK, there are three services created with different languages to demonstrate various possible scenarios as follows:

  1. Access service as API from the internet.
  2. Service to service inter-communication.
  3. Both (Access service from the internet as well as from another service internally).

Let’s dive deeper on the MRK infrastructure part:

Terraform:
This is used to provision and manage the infrastructure as code. We use the terraform helm provider to deploy the helm charts.

Kubernetes:
This is used for container management and orchestration of our application services. Basically this serves as a system for automating deployment, scaling, and management of containerized applications.

Helm Charts:
Helm is used as a package manager for Kubernetes resources. Charts are created with Kubernetes resource definitions that are version managed using helm.

Consul:
Consul Connect is used to introduce secure TLS communication between services with the help of sidecar proxies. Also, consul has a DNS service with which it provides the service discovery feature.

Ambassador:
It is used as an ingress controller to route external traffic to the corresponding services with load balancing.

North — South traffic is handled by Ambassador whereas East — West traffic is managed by Consul

What Resources will MRK create?

With just one command, terraform apply you have your microservices setup ready to use on the Google Cloud Platform.

  1. Creates a Google Kubernetes Engine (GKE).
  2. Installs helm v2 with tiller.
  3. Installs Consul helm chart.
  4. Installs Ambassador helm chart.
  5. Installs all the apps(services) helm charts.

Things to configure before executing:

terraform/provider.tf

provider "google" {    credentials = file("./creds/serviceaccount.json")    project     = "microservices-264808"    region      = "us-central1-a"}

In provider.tf modify the location to your credentials that grant access to your GCP, and change the project name and region as needed.

Docker Images of Services:

Helm charts of each service use the docker image of the corresponding application. Hence, you need to create a docker image and supply it to the helm chart via container registry like GCR/ECR.

Steps to create a docker image of services and push to GCR.

Python:

export PROJECT_ID="$(gcloud config get-value project -q)"docker build -t python-service-mrk .docker tag python-service-mrk:latest "gcr.io/${PROJECT_ID}/python-service-mrk:v1"docker push "gcr.io/${PROJECT_ID}/python-service-mrk:v1"

Go:

export PROJECT_ID="$(gcloud config get-value project -q)"docker build -t go-service-mrk .docker tag go-service-mrk:latest "gcr.io/${PROJECT_ID}/go-service-mrk:v1"docker push "gcr.io/${PROJECT_ID}/go-service-mrk:v1"

Spring:

mvn packagedocker build -t spring-service-mrk .docker tag spring-service-mrk:latest "gcr.io/${PROJECT_ID}/spring-service-mrk:v1"docker push "gcr.io/${PROJECT_ID}/spring-service-mrk:v1"

Each service contains a Dockerfile that has the instructions to create a docker image.

Modify the values of the docker image name in values.yaml of the respective application helm chart.

How to Deploy MRK:

  1. Here’s the Github link — https://github.com/codaglobal/microservices-rightstart-kit/
  2. Go to -> terraform folder and run terraform init . This will install terraform dependencies.
  3. Then, run terraform plan -out plan-1 . This will create a plan of what resources will be created and output it to a file plan-1.
  4. Now, terraform apply plan-1 will create all the resources.

Output:

Here’s what to expect after you run terraform apply

  1. Connect to the Google Kubernetes cluster to configure kubectl command-line access by running the command provided in the Google cloud console.
  2. Run the command kubectl get svc -n ambassador . You’ll get a list of output as below.

3. Copy the External-IP of the Ambassador load balancer. This will be used to access the services running inside k8s.

4. Check out the pods created using kubectl get pods -n mrk-app for the application.

5. Check out the consul and ambassador related pods the same way.

The MRK kit has five GET API endpoints to demonstrate all possible combinations of service communication.

  1. /api/spring-service
Output of /api/spring-service endpoint

2. /api/spring-service/interservice/go

Output of /api/spring-service/interservice/go endpoint

3. /api/spring-service/interservice/python

Output of /api/spring-service/interservice/python endpoint

4. /api/python-service

Output of /api/python-service endpoint

5. /api/python-service/inter

Output of /api/python-service/inter endpoint

Go service is not publically accessible as there is no ambassador mapping configured.

The entire motive of this Microservices Rightstart Kit(MRK) is to provide an easy start to any microservices application having in mind to migrate the application to a different platform with no application code changes.

Note:

  1. If you come across an issue as stated below,
    Error: rpc error: code = Unknown desc = Could not get apiVersions from Kubernetes: unable to retrieve the complete list of server APIs: metrics.k8s.io/v1beta1: the server is currently unable to handle the request
    Then this is probably because of a bug with helm provider version 0.10.

Run terraform plan -out plan-1 and terrform apply plan-1 again. And this time it works fine.


Thank You

Clap

Leave A Comment