DEV Community

Mariela Dimitrova for Software AG Tech Community

Posted on • Originally published at tech.forums.softwareag.com on

Microgateway Stand-alone Kubernetes Sidecar Deployment

Introduction

A Microgateway Kubernetes sidecar deployment can be established by creating a pod containing two containers; one container runs the native service, and the other container runs the Microgateway protecting the native service.

The native services are accessed by consumers through the Microgateway endpoint.

To access the native service from the Microgateway container, Microgateway has to use localhost as URL together with the port exposed by the native service as both the containers are treated as being within the same host.

There are two types of sidecar deployment models:

  • A stand-alone Kubernetes sidecar deployment
  • A Kubernetes sidecar connected to API Gateway

In this article we will see how we can realize Microgateway as a stand-alone Kubernetes sidecar deployment model.

Audience

This document is intended for users who wants to deploy Microgateway as a stand-alone deployment to protect the native services deployed in the Kubernetes environment.

Pre-Requisites

  • Basic Knowledge on Docker, Kubernetes
  • The native service Docker images are pushed to a Docker registry to make them available for the Kubernetes environment
  • Create API in API Gateway
  • Export of APIs and related assets from the API Gateway
  • Understanding on Microgateway
  • Docker and Kubernetes environment setup

UseCase

In this article we will be creating the standalone microgateway deployment with the below assets

  1. PostalCode Native Service Docker Image – Simple Java application which will return the postalCode when queried with the specific latitude and longitude.

  2. PostalCodeAPI.zip – Export of the API created in the API gateway, which will invoke the native service.

Deploying Microgateway as Standalone Kubernetes SideCar

Below are the steps about how we can deploy a stand-alone Kubernetes sidecar. Stand-alone means that the Microgateways are not connected to an API Gateway. The API definitions are provided through API Gateway export archives.

1. Create a Microgateway Docker image

Navigate to the Microgateway installation directory <InstallationDir>\Microgateway

Create an export of API from API Gateway and name the file PostalCodeAPI.zip

Run the below docker command to create docker file

.\microgateway.bat createDockerFile --docker_dir . -p 9090 -a PostalCodeAPI.zip

Run the below command to create a docker image

docker build -f Microgateway_DockerFile -t sag:mcgwimg107 .

2. Push the image to the docker repository

Tag the image created in the Step 1 and push it to docker registry.

docker tag sag:mcgwimg107 <<dockerRepo>>:mcgwimg107

docker push <<dockerRepo>>:mcgwimg107

3. Create new namespace in Kubernetes

Below command creates new namespace in Kubernetes.

kubectl create namespace postalcode

4. Set Kubernetes context

Below command sets the Kubernetes context to the namespace created in step 3.

kubectl config set-context --current --namespace= postalcode

5. Create a template for Kubernetes sidecar deployment

Microgateway offers a function to generate a Kubernetes YAML file, which can be used for a convenient deployment.

We can specify the sidecar parameters together with the Microgateway image parameters to have the two containers created within one pod.

The below command creates the Kubernetes YAML file.

./microgateway.bat createKubernetesFile --docker_image <<dockerRepo>>:mcgwimg107 --pod_name postalcode-sidecar --sidecar_docker_image <<dockerRepo>>/apiserver:latest --sidecar_pod_name postalcode-service --output postalcode-sidecar-deployment.yml

Here,

<<dockerRepo>>:mcgwimg107 is the microgateway image created in Step 1

<<dockerRepo>>/apiserver:latest is the native service image

6. Create and check the Kubernetes deployment

Create the Kubernetes deployment with the below command

kubectl create –f postalcode-sidecar-deployment.yml

If the deployment is successful we should see 2 out of 2 containers running

GetPods

7. Expose Microgateway sidecar deployment as a Kubernetes service.

Run the below command to expose the deployment created in Step 4.

kubectl expose deployment postalcode-sidecar --type=LoadBalancer --port=9090

8. Verify the Microgateway Kubernetes service definition including the exposed IP and port

Run the below command to see if the Kubernetes service as created along with the port details.

kubectl get svc

getSvc

9. Check Microgateway service and Invoke the API

Once the deployment is exposed as service, we can check the Microgateway server status with the below

GET http://localhost:9090/rest/microgateway/status

Microgateway Status

We can also invoke the API with the below endpoint.

GET http://localhost:9090/gateway/PostalCodeAPI/1.0/postalCodes?latitude=333&longitude=444444

PostalcodeAPI

Note here since the native services are not exposed by the Kubernetes configuration the Microgateway can’t be by-passed. Consumer requests are routed by the Microgateway to the native services.

For more information, please refer documentation Kubernetes Sidecar Deployment (softwareag.com)

Read full topic

Top comments (0)