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:
In this article, we will see how we can deploy Microgateway as a Kubernetes sidecar connected to API Gateway using Helm charts.
Helm is a package manager for Kubernetes. It helps you manage Kubernetes applications — Helm Charts help you define, install, and upgrade even the most complex Kubernetes application. For more details refer Helm | Docs
Audience
This document is intended for users who want to deploy Microgateway as a Kubernetes sidecar connected to API Gateway using helm charts.
Prerequisites
- Basic Knowledge of Docker, Kubernetes, Helm
- The native service Docker images are pushed to a Docker registry to make them available for the Kubernetes environment
- Create API in API Gateway
- Understanding of Microgateway
- Docker and Kubernetes environment setup
- Helm installation
Use Case
In this article, we will see how we can deploy the Microgateway as Kubernetes sidecar using Helm charts.
We will be using PostalCode native service docker Image which is a simple Java-based application that will return the postalCode when queried with the specific latitude and longitude.
Deploying a Microgateway Kubernetes Sidecar connected to API Gateway using Helm Charts
Before you start with the deployment ensure you have done the following:
- Ensure you have a running Kubernetes environment with Helm installed
- There is an API Gateway instance running in a dedicated Kubernetes service.
- There is a native service Docker image in the Docker registry
Below are the steps about how we can achieve Microgateway Kubernetes sidecar deployment using helm charts
1. Create a Microgateway Docker image
Navigate to the Microgateway installation directory
<InstallationDir>\Microgateway
Create the configuration file pull-postalcode-service.yml that holds the configuration for pulling the definition of the PostalCode API from API Gateway.
Below is the snippet of the configuration file used for pulling the PostalCode API
Where,
<<APIGatewayISHost>> is the Host IP of the Integration Server where the API Gateway is hosted.
<<APIGatewayISPort>> is the Port of the Integration Server where the API Gateway is hosted.
Run the below docker command to create a docker file:
./microgateway.bat createDockerFile -c pull-postalcode-service.yml --docker_file DockerFilePostalCode -dod
Add the below environment variables to your docker file:
ENV mcgw_api_gateway_url http://<<host>>:<<port>/rest/apigateway
ENV mcgw_api_gateway_user <<API Gateway Username>>
ENV mcgw_api_gateway_password <<API Gateway Password>>
Where,
<< host>> is the IP of the system where the API gateway server is hosted.
<< port>> is the Integration server port where the API gateway is installed.
Run the below command to create a docker image
docker build -t mg-postalcodeimg -f DockerFilePostalCode .
2. Push the image to the docker repository
Tag the image created in Step 1 and push it to the Docker registry.
docker tag mg-postalcodeimg <<dockerRepo>>/mg-postalcodeimg
docker push <<dockerRepo>>/mg-postalcodeimg
3. Create a new namespace in Kubernetes
The below command creates a 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 Helm Chart
Run the below command to create a helm chart structure
helm create mg-helmchart
This will create the below folder structure
6. Replace deployment template data
Edit deployment.yaml file present under mg-helmchart/templates folder and replace with the below content.
apiVersion: apps/v1
kind: Deployment
metadata:
name: {{ .Release.Name }}
labels:
app: {{ .Release.Name }}
category: microgateway
spec:
replicas: {{ .Values.replicaCount }}
selector:
matchLabels:
app: {{ .Release.Name }}
template:
metadata:
labels:
app: {{ .Release.Name }}
annotations:
prometheus.io/scrape: "{{ .Values.metrics.prometheus }}"
spec:
containers:
- name: {{ .Release.Name }}
image: "{{ .Values.image.repository }}"
env:
- name: "mcgw_api_gateway_url"
valueFrom:
secretKeyRef:
key: mcgw_api_gateway_url
name: {{ .Release.Name }}-auth
- name: "mcgw_api_gateway_user"
valueFrom:
secretKeyRef:
key: mcgw_api_gateway_user
name: {{ .Release.Name }}-auth
- name: "mcgw_api_gateway_password"
valueFrom:
secretKeyRef:
key: mcgw_api_gateway_password
name: {{ .Release.Name }}-auth
livenessProbe:
exec:
command:
- /bin/sh
- -c
- /opt/softwareag/Microgateway/files/k8s-lifenesscheck.sh
initialDelaySeconds: 10
periodSeconds: 10
timeoutSeconds: 5
failureThreshold: 3
readinessProbe:
exec:
command:
- /bin/sh
- -c
- /opt/softwareag/Microgateway/files/k8s-readinesscheck.sh
initialDelaySeconds: 10
periodSeconds: 10
timeoutSeconds: 5
failureThreshold: 3
- name: "{{ .Values.sidecarimage.name }}"
image: "{{ .Values.sidecarimage.repository }}:{{ .Values.sidecarimage.tag }}"
7. Replace and adapt the values data
Replace the content of values.yaml file present under mg-helmchart folder with the below content for having the values substituted in the deployment file created in Step 6
# This is a YAML-formatted file.
# Declare variables to be passed into your templates.
replicaCount: 1
mcgw_api_gateway_url: http://<<SystemIP>>:32580/rest/apigateway
mcgw_api_gateway_user: Administrator
mcgw_api_gateway_password: manage
# The Microgateway Docker image
image:
repository: <<dockerRepo>>/mg-postalcodeimg
tag: latest
containerPort: 9090
pullPolicy: IfNotPresent
# The sidecar Docker image of the native service (if used, uncomment and adapt values)
sidecarimage:
repository: <<dockerRepo>>/apiserver
tag: latest
name: sidecar-node
pullPolicy: IfNotPresent
metrics:
prometheus: true
ingress:
enabled: false
paths: []
hosts: []
tls: []
resources: {}
# We usually recommend not to specify default resources and to leave this as a conscious # choice for the user.
nodeSelector: {}
tolerations: []
affinity: {}
8. Add the Environment Variables definition in secrets.yaml
Notice the tag secretKeyRef under env of deployment.yaml file, which is the place holder for environment variables.
In order to have environment variables substituted, create secrets.yaml under templates folder of mg-helmchart . Add the below content.
apiVersion: v1
kind: Secret
metadata:
name: {{ .Release.Name }}-auth
data:
mcgw_api_gateway_url: {{ .Values.mcgw_api_gateway_url | b64enc }}
mcgw_api_gateway_user: {{ .Values.mcgw_api_gateway_user | b64enc }}
mcgw_api_gateway_password: {{ .Values.mcgw_api_gateway_password | b64enc }}
Notice the values are coming from the {{ .Values. <<VariableName>> | b64enc }} which in turn getting from values.yaml file created in Step 7
9. Deploy the Helm Chart
Run the below command to create the deployment by making use of helm chart and configurations created in the earlier steps
helm install mg-test ./mg-helmchart
If the deployment is successful you should see 2 out of 2 containers running under mg-test deployment
10. Expose Microgateway sidecar deployment as a Kubernetes service.
Run the below command to expose the deployment created in Step 9:
kubectl expose deployment mg-test --type=NodePort --port=9090
Note Here we can also expose the deployment with type LoadBalancer and access using localhost
11. Check Microgateway service and Invoke the API using the exposed IP and port
Once the deployment is exposed as a service, we can check the Microgateway server status with the below.
Here am using system IP and Node Port as I have exposed the deployment as type “NodePort”
GET http://<<SystemIP>>:32171/rest/microgateway/status
We can also invoke the API with the below endpoint.
GET http://<<SystemIP>>:32171/gateway/PostalCode/1.0/postalCodes?latitude=333&longitude=444444
Note here since the native services are not exposed by the Kubernetes configuration the Microgateway can’t be bypassed. Consumer requests are routed by the Microgateway to the native services.
From API Gateway, we can check the details of Microgateway under Microgateways tab.
#API-Management#Microgateway#webMethods