refer to: https://medium.com/@nikhil.nagarajappa/deploying-kong-db-less-and-konga-via-raedy-to-use-yaml-files-38dce989674d

Contents

What is kong?

Kong is a popular open-source API gateway and microservices management layer. It acts as an intermediary between clients and backend services by providing a unified entry point for all API traffic. Kong is designed to handle API traffic at scale and provides features such as load balancing, authentication, rate limiting, request/response transformations, and more.

Kong is built on top of the Nginx web server and can be deployed as a standalone service or as a containerized application. It supports a wide range of protocols and formats, including HTTP, HTTPS, TCP, WebSockets, and GraphQL.

Kong is often used in microservices architectures to manage the complexity of multiple services communicating with each other. It provides a central location for managing and monitoring API traffic and allows for easy scaling and maintenance of microservices-based applications.

What is Konga?

Konga is a web-based user interface for managing Kong API Gateway. It provides a graphical interface for configuring and managing APIs, plugins, routes, and consumers within Kong.

Konga simplifies the process of managing Kong by providing a user-friendly interface for creating, updating, and deleting API endpoints and their associated configuration elements. It also allows you to manage authentication and authorization policies, rate limiting, caching, and other features of the Kong API Gateway.

Konga provides a range of features including an API designer, plugin management, and user management. It also includes a dashboard for monitoring API traffic and metrics.

Konga is designed to work seamlessly with Kong, but it can also be used as a standalone tool for managing APIs. It is an open-source project that is maintained by the same team behind Kong.

What is Kong DBless mode?

Kong DB-less mode is a feature introduced in Kong version 2.0 that allows Kong to be run without the need for a database. Instead of storing configuration data in a database, the configuration is stored in declarative YAML files, which can be version-controlled and audited using standard source control tools.

In DB-less mode, Kong uses a set of YAML files to configure the API Gateway’s behavior, including routes, plugins, and other settings. These files can be stored in a version control system such as Git or managed through a CI/CD pipeline.

The primary benefit of DB-less mode is that it simplifies the deployment and management of Kong instances. It eliminates the need for a separate database instance, which can be a source of complexity and maintenance overhead. It also allows for easier scaling and versioning of Kong instances.

DB-less mode is particularly useful in cloud-native environments, where infrastructure is often managed through automation tools and containers. With DB-less mode, Kong can be integrated into these environments more seamlessly, allowing for more agile and efficient development and deployment of APIs.

Deploy Kong:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: kong
  namespace: kong
spec:
  replicas: 1
  selector:
    matchLabels:
      app: kong
  template:
    metadata:
      labels:
        app: kong
    spec:
      containers:
      - name: kong
        image: kong:2.7
        env:
        - name: KONG_DATABASE
          value: "off"
        - name: KONG_DECLARATIVE_CONFIG
          value: "/kong/kong.yml"
        - name: KONG_PROXY_ACCESS_LOG
          value: "/dev/stdout"
        - name: KONG_ADMIN_ACCESS_LOG
          value: "/dev/stdout"
        - name: KONG_PROXY_ERROR_LOG
          value: "/dev/stderr"
        - name: KONG_ADMIN_ERROR_LOG
          value: "/dev/stderr"
        - name: KONG_ADMIN_LISTEN
          value: "0.0.0.0:8001, 0.0.0.0:8444 ssl"
        ports:
        - name: proxy
          containerPort: 8000
        - name: proxy-ssl
          containerPort: 8443
        - name: admin
          containerPort: 8001
        - name: admin-ssl
          containerPort: 8444
        volumeMounts:
        - name: kong-config
          mountPath: /kong
      volumes:
      - name: kong-config
        configMap:
          name: kong-config

This is a Kubernetes deployment specification file written in YAML format. It describes the deployment of an instance of the Kong API gateway, a popular open-source API gateway solution.

Let’s break down the various parts of the file:

– `apiVersion` and `kind`: These two fields specify the Kubernetes API version and the kind of Kubernetes resource being defined, respectively. In this case, the `apps/v1` API version is being used, and the resource kind is a `Deployment`.

– `metadata`: This field specifies metadata about the Kubernetes resource being defined, such as the name and namespace of the deployment. In this case, the deployment is named `kong` and is deployed to the `kong` namespace.

– `spec`: This field specifies the desired state of the deployment, such as the number of replicas and the pod template to be used.

– `replicas`: This field specifies the number of replicas of the pod to be created. In this case, only one replica is specified.

– `selector`: This field specifies how the deployment selects which pods to manage. In this case, the selector matches pods with the `app=kong` label.

– `template`: This field specifies the pod template that will be used to create the replicas.

– `metadata`: This field specifies metadata about the pod template, such as the labels to be applied to the pod. In this case, the pod will have the `app=kong` label.

– `spec`: This field specifies the pod template specification, such as the container(s) to be run in the pod.

– `containers`: This field specifies the container(s) to be run in the pod. In this case, only one container is specified, which is named `kong`.

– `image`: This field specifies the Docker image to be used for the container. In this case, the `kong:2.7` image is being used.

– `env`: This field specifies the environment variables to be set in the container. In this case, several environment variables are being set for the Kong container, including the `KONG_DATABASE` variable set to `”off”`, which disables the use of a database for Kong.

– `ports`: This field specifies the ports to be exposed by the container. In this case, four ports are being exposed: `8000`, `8443`, `8001`, and `8444`.

– `volumeMounts`: This field specifies the volumes to be mounted by the container. In this case, only one volume is being mounted, which is named `kong-config` and is mounted to the `/kong` directory in the container.

– `volumes`: This field specifies the volumes to be used by the pod. In this case, only one volume is being used, which is a `configMap` named `kong-config`. This configMap likely contains the Kong configuration to be used by the container.

Deploy Kong services:

apiVersion: v1
kind: Service
metadata:
 name: kong-admin
 namespace: kong
spec:
 selector:
 app: kong
 ports:
 - name: admin
 protocol: TCP
 port: 8001
 targetPort: 8001
 - name: admin-ssl
 protocol: TCP
 port: 8444
 targetPort: 8444
 type: ClusterIP
 - -
apiVersion: v1
kind: Service
metadata:
 name: kong-proxy
 namespace: kong
spec:
 selector:
 app: kong
 ports:
 - name: proxy
 protocol: TCP
 port: 80
 targetPort: 8000
 - name: proxy-ssl
 protocol: TCP
 port: 443
 targetPort: 8443
 type: LoadBalancer

The first Service, kong-admin, exposes the Kong Admin API within the Kubernetes cluster using a ClusterIP type service. It selects the Kong container based on the app: kong label and exposes two ports: port 8001 for HTTP traffic and port 8444 for HTTPS traffic.

The second Service, kong-proxy, exposes the Kong Proxy API within the Kubernetes cluster using a LoadBalancer type service. It selects the Kong container based on the app: kong label and exposes two ports: port 80 for HTTP traffic and port 443 for HTTPS traffic. This Service is intended to be used by external clients to access the APIs managed by Kong.

Deploy test applications:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: httpbin
  namespace: kong
spec:
  replicas: 1
  selector:
    matchLabels:
      app: httpbin
  template:
    metadata:
      labels:
        app: httpbin
    spec:
      containers:
      - name: httpbin
        image: kennethreitz/httpbin
        ports:
        - containerPort: 80

---

apiVersion: v1
kind: Service
metadata:
  name: httpbin
  namespace: kong
spec:
  selector:
    app: httpbin
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: ClusterIP

Deploy another test application:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-world
  namespace: kong
spec:
  replicas: 1
  selector:
    matchLabels:
      app: hello-world
  template:
    metadata:
      labels:
        app: hello-world
    spec:
      containers:
      - name: hello-world
        image: nginxdemos/hello:plain-text
        ports:
        - containerPort: 80

---

apiVersion: v1
kind: Service
metadata:
  name: hello-world-service
  namespace: kong
spec:
  selector:
    app: hello-world
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: ClusterIP

Deploy and Configure Kong Configmap to route to the above test services(Also called Upstream services):

apiVersion: v1
kind: ConfigMap
metadata:
  name: kong-config
  namespace: kong
data:
  kong.yml: |
    _format_version: "1.1"

    services:
    - name: httpbin-service
      url: http://httpbin.kong.svc.cluster.local:80
      routes:
      - name: httpbin-route
        paths:
        - "/httpbin"
    - name: web-service
      url: http://hello-world-service.kong.svc.cluster.local:80
      routes:
      - name: hello-world-route
        paths:
        - "/hello-world"

This YAML defines a ConfigMap named kong-config in the kong namespace, with a single key-value pair in the data section. The value is a multi-line string that contains the configuration for two services and their associated routes within Kong.

The new data format uses YAML block scalar notation (|) to preserve newlines in the multi-line string.

Routing is defined using the routes key within each service definition. Each service has one or more routes associated with it, which define the HTTP paths and methods that should be routed to that service.

For example, in the following snippet of YAML:

services:
- name: httpbin-service
  url: http://httpbin.kong.svc.cluster.local:80
  routes:
  - name: httpbin-route
    paths:
    - "/httpbin"

The httpbin-service has one route named httpbin-route that is associated with it. The paths key within the route definition specifies the HTTP path that should be routed to the httpbin-service service, which in this case is /httpbin.

Similarly, the following snippet of YAML:

- name: web-service
  url: http://hello-world-service.kong.svc.cluster.local:80
  routes:
  - name: hello-world-route
    paths:
    - "/hello-world"

Defines the web-service with a single route named hello-world-route that handles HTTP requests with the path /hello-world.

In summary, routing is accomplished by defining the HTTP paths and methods that should be routed to each service using the routes key within each service definition.

Configuring Firewall Rules:

Open port 80 and 443 for internet in the VPC using firewall rules in GKE.

Testing:

Get the external IP for Kong-proxy service via Kubectl get svc -n kong command.

Use the external IP to hit routes defined in configmap:

To hit httpbin test service:

http://EXTERNAL-IP-ADDRESS/httpbin

Expected output:

2. To hit hello-world test service:

http://EXTERNAL-IP-ADDRESS /hello-world

Expected output:

Server address: x.x.x.x:80
Server name: hello-world-xxxxxxxx
Date: 02/May/2023:06:38:31 +0000
URI: /
Request ID: 3db7bc3xxxxxxxxxx

Deploy Konga:

git clone https://github.com/pantsel/konga.git
cd konga
docker build -t konga .
docker tag konga gcr.io/[PROJECT_ID]/konga:v1
gcloud auth configure-docker
docker push gcr.io/[PROJECT_ID]/konga:v1

Expanation of above 6 commands:

Here’s what each command does:

git clone https://github.com/pantsel/konga.git: This command clones the Konga repository from GitHub to your local machine.
cd konga: This command changes the current working directory to the Konga repository that was just cloned.
docker build -t konga .: This command builds a Docker image for Konga using the Dockerfile in the current directory. The -t flag sets the name of the image to konga.
docker tag konga gcr.io/[PROJECT_ID]/konga:v1: This command tags the konga image with a new name gcr.io/[PROJECT_ID]/konga:v1, where [PROJECT_ID] is your Google Cloud project ID. This is necessary for pushing the image to the Google Cloud Container Registry.
gcloud auth configure-docker: This command configures Docker to use your Google Cloud credentials for pushing images to the Container Registry.
docker push gcr.io/[PROJECT_ID]/konga:v1: This command pushes the gcr.io/[PROJECT_ID]/konga:v1 image to the Google Cloud Container Registry. The image can now be used to deploy Konga within a Kubernetes cluster or other container orchestration environment.

Overall, these commands provide a way to build and deploy the Konga web-based GUI using Docker and the Google Cloud Container Registry.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: konga
  namespace: kong
spec:
  replicas: 1
  selector:
    matchLabels:
      app: konga
  template:
    metadata:
      labels:
        app: konga
    spec:
      containers:
      - name: konga
        image: gcr.io/[PROJECT_ID]/konga:v1
        ports:
        - containerPort: 1337
        env:
        - name: KONGA_BACKEND_URL
          value: "http://kong-admin:8001"
---
apiVersion: v1
kind: Service
metadata:
  name: konga
  namespace: kong
spec:
  selector:
    app: konga
  ports:
    - protocol: TCP
      port: 80
      targetPort: 1337
  type: LoadBalancer

The first part of the YAML code defines a Deployment for the Konga application, which specifies that there should be one replica of the konga container. The container runs the gcr.io/hopeful-runner-380002/konga:v1 image and listens on port 1337. The environment variable KONGA_BACKEND_URL is set to the URL of the Kong Admin API at http://kong-admin:8001.

The second part of the YAML code defines a Service for the Konga application, which exposes the Konga container within the Kubernetes cluster using a LoadBalancer type service. The Service selects the Konga container based on the app: konga label and maps port 80 to port 1337 of the container.

Overall, this YAML code defines a Kubernetes Deployment and Service for the Konga application, which provides a web-based GUI for managing the Kong API Gateway.

Testing:

Get the external IP for “Konga” service via Kubectl get svc -n kong command.

Hit http://EXTERNAL-IP/

Expected output:

You can create a new account, sign in and configure the connection.

Configuring the connection:

Click on “Add New Connection” and enter the value as shown above in new connection dialog box. For instance, in KONG ADMIN URL, enter http://kong-admin:8001.

Summary:

In this topic, we covered several YAML code examples for Kubernetes objects used in conjunction with the Kong API Gateway. These objects include Kubernetes Services and Deployments, as well as a ConfigMap used to store configuration data for Kong.

The Kubernetes Services are used to expose the Kong API Gateway and associated services within a Kubernetes cluster. The Services can be configured as either a ClusterIP or LoadBalancer type, depending on whether they are intended to be accessed only within the cluster or from external clients.

The Kubernetes Deployments are used to define the containerized applications that run on the Kong API Gateway, such as the Kong Admin API, the Kong Proxy API, and the Konga web-based GUI for managing the gateway.

Finally, the ConfigMap is used to store configuration data for Kong, which can be consumed by other Kubernetes objects to configure the gateway and associated services.

Overall, the use of Kubernetes objects provides a scalable and manageable way to deploy and manage the Kong API Gateway within a Kubernetes environment, making it a popular choice for building microservices architectures and managing API traffic.