Forem: Viktor Gamov

Installing Kong's API Gateway with Docker

Viktor Gamov — Fri, 10 Sep 2021 19:57:32 +0000

Kong Gateway is an API layer for managing APIs and microservices. The easiest way to get started running Kong Gateway is to use Docker.

In this video, I'll explain how to run Kong Gateway using Docker and Docker Compose.

Using Kubernetes Ingress Controller as an API Gateway

Viktor Gamov — Tue, 23 Mar 2021 14:18:22 +0000

In this first section, I’ll provide a quick overview of the business case and the tools you can use to create a Kubernetes ingress API gateway. If you’re already familiar, you could skip ahead to the tutorial section.

Digital transformation has led to a high velocity of data moving through APIs to applications and devices. Companies with legacy infrastructures are experiencing inconsistencies, failures and increased costs. And most importantly, dissatisfied customers.

All this has led to significant restructuring and modernization, especially within IT. A primary strategy is to embrace Kubernetes and decouple monolithic systems. On top of that, IT leadership is tasking DevOps teams to find systems, like an API gateway or Kubernetes ingress controller, to support API traffic growth while minimizing costs.

API gateways are crucial components of microservice architectures. The API gateway acts as a single entry point into a distributed system, providing a unified interface for clients who don’t need to care (or know) that the system aggregates their API call response from multiple microservices.

Some everyday use cases for API gateways include:

• Routing inbound requests to the appropriate microservice
• Presenting a unified interface to a distributed architecture by aggregating responses from multiple backend services
• Transforming microservice responses into the format required by the caller
• Implementing non-functional/policy concerns such as authentication, logging, monitoring and observability, rate-limiting, IP filtering, and attack mitigation
• Facilitating deployment strategies such as blue/green or canary releases

API gateways can simplify the development and maintenance of a microservice architecture. As a result, freeing up development teams to focus on the business logic of individual components.

Like Papa John’s, many companies select a Kubernetes API gateway at the beginning or partway through their transition to multi-cloud. Doing so makes it necessary to choose a solution that can function with on-prem services and the cloud.

Kubernetes

Kubernetes is becoming the hosting platform of choice for distributed architectures. It offers auto-scaling, fault tolerance and zero-downtime deployments out of the box.

By providing a widely accepted, standard approach with a carefully designed API, Kubernetes has spawned a thriving ecosystem of products and tools that make it much easier to deploy and maintain complex systems.

Kubernetes Ingress Controller

As a native Kubernetes application, Kong is installed and managed precisely as any other Kubernetes resource. It integrates well with other CNCF projects and automatically updates itself with zero downtime in response to cluster events like pod deployments. There’s also a great plugin ecosystem and native gRPC support.

This article will walk through how easy it is to set up the open source Kong Ingress Controller as a Kubernetes API gateway on a cluster.

Use Case: Routing API Calls to Backend Services

To keep this article to a manageable size, I will only cover a single, straightforward use case.

I will create a Kubernetes cluster, deploy two dummy microservices, “foo” and “bar,” install and configure Kong to route inbound calls to /foo to the foo microservice and send calls to /bar to the bar microservice.

The information in this post barely scratches the surface of what you can do with Kong, but it’s a good starting point.

Prerequisites

There are a few things you’ll need to work through in this article.

I’m going to create a “real” Kubernetes cluster on DigitalOcean because it’s quick and easy, and I like to keep things as close to real-world scenarios as possible. If you want to work locally, you can use minikube or KinD. You will need to fake a load-balancer, though, either using the minikube tunnel or setting up a port forward to the API gateway.

For DigitalOcean, you will need:

• A DigitalOcean account
• A DigitalOcean API token with read and write scopes
• The doctl command-line tool

To build and push docker images representing our microservices, you will need:

• Docker
• An account on Docker Hub

Note: Optional because you can deploy the images I’ve already created.

You will also need kubectl to access the Kubernetes cluster.

Setting Up doctl

After installing doctl, you’ll need to authenticate using the DigitalOcean API token:

2
3
4
$ doctl auth init
...
Enter your access token:  <-- paste your API token, when prompted
Validating token... OK

Create Kubernetes Cluster

Now that you have authenticated doctl, you can create your Kubernetes cluster with this command:

$ doctl kubernetes cluster create mycluster --size s-1vcpu-2gb --count 1

Note: The command spins up a Kubernetes cluster on DigitalOcean. Doing so will incur charges (approximately $0.01/hour, at the time of writing) as long as it is running. Please remember to destroy any resources you create when you finish with them.

The command creates a cluster with a single worker node of the smallest viable size in the New York data center. It’s the smallest and simplest cluster (and also the cheapest to run). You can explore other options by running doctl kubernetes --help.

The command will take several minutes to complete, and you should see an output like this:


2
3
4
5
6
7
8
$ doctl kubernetes cluster create mycluster --size s-1vcpu-2gb --count 1
Notice: Cluster is provisioning, waiting for cluster to be running
....................................................
Notice: Cluster created, fetching credentials
Notice: Adding cluster credentials to kubeconfig file found in "/Users/david/.kube/config"
Notice: Setting current-context to do-nyc1-mycluster
ID                                      Name         Region    Version        Auto Upgrade    Status     Node Pools
4cf2159a-01c1-423c-907d-51f19c3f9a01    mycluster    nyc1      1.20.2-do.0    false           running    mycluster-default-pool

As you can see, the command automatically adds cluster credentials and a context to the ~/.kube/config file, so you should be able to access your cluster using kubectl:


2
3
4
5
6
$ kubectl get namespace
NAME              STATUS   AGE
default           Active   24m
kube-node-lease   Active   24m
kube-public       Active   24m
kube-system       Active   24m

Create Dummy Microservices

To represent backend microservices, I’m going to use a trivial Python Flask application that returns a JSON string:

foo.py


2
3
4
5
6
7
8
9
from flask import Flask
app = Flask(__name__)

@app.route('/foo')
def hello():
    return '{"msg":"Hello from the foo microservice"}'

if __name__ == "__main__":
    app.run(debug=True, host='0.0.0.0')

This Dockerfile builds a docker image you can deploy:

Dockerfile

FROM python:3-alpine

WORKDIR /app

RUN echo "Flask==1.1.1" > requirements.txt
RUN pip install -r requirements.txt
COPY foo.py .

EXPOSE 5000

CMD ["python", "foo.py"]

The files for our “foo” and “bar” services are almost identical, so I’m only going to show the “foo” files here.

This gist contains files and a script to build foo and bar microservices docker images and push them to Docker Hub as:

• digitalronin/foo-microservice:0.1
• digitalronin/bar-microservice:0.1

Note: You don’t have to build and push these images. You can just use the ones I’ve already created.

Deploy Dummy Microservices

You’ll need a manifest that defines a Deployment and a Service for each microservice, both for “foo” and “bar.” The manifest for “foo” (again, I’m only showing the “foo” example here, since the “bar” file is nearly identical) would look like this:

foo.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: foo-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: foo
  template:
    metadata:
      labels:
        app: foo
    spec:
      containers:
      - name: api
        image: digitalronin/foo-microservice:0.1
        ports:
        - containerPort: 5000
---
apiVersion: v1
kind: Service
metadata:
  name: foo-service
  labels:
    app: foo-service
spec:
  ports:
  - port: 5000
    name: http
    targetPort: 5000
  selector:
    app: foo

This gist has manifests for both microservices, which you can download and deploy to your cluster like this:

$ kubectl apply -f foo.yaml
$ kubectl apply -f bar.yaml

Access the Services

You can check that the microservices are running correctly using a port forward:

$ kubectl port-forward service/foo-service 5000:5000

Then, in a different terminal:


2
$ curl http://localhost:5000/foo
{"msg":"Hello from the foo microservice"}

Ditto for bar, also using port 5000.

Install Kong for Kubernetes

Now that you have our two microservices running in our Kubernetes cluster, let’s install Kong.

There are several options for this, which you will find in the documentation. I’m going to apply the manifest directly, like this:

$ kubectl create -f https://bit.ly/k4k8s

The last few lines of output should look like this:

...
service/kong-proxy created
service/kong-validation-webhook created
deployment.apps/ingress-kong created

Note: You may receive several API deprecation warnings at this point, which you can ignore. Kong’s choice of API versions allows Kong Ingress Controller to support the broadest range of Kubernetes versions possible.

Installing Kong will create a DigitalOcean load balancer. It’s the internet-facing endpoint to which you will make API calls to access our microservices.

Note: DigitalOcean load balancers incur charges, so please remember to delete your load balancer along with your cluster when you are finished.

Creating the load balancer will take a minute or two. You can monitor its progress like this:

$ kubectl -n kong get service kong-proxy
NAME                      TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)                      AGE
kong-proxy                LoadBalancer   10.245.14.22    <pending>     80:32073/TCP,443:30537/TCP   71s

Once the system creates the load balancer, the EXTERNAL-IP value will change from <pending> to a real IP address:

$ kubectl -n kong get service kong-proxy
NAME                      TYPE           CLUSTER-IP      EXTERNAL-IP     PORT(S)                      AGE
kong-proxy                LoadBalancer   10.245.14.22    167.172.7.192   80:32073/TCP,443:30537/TCP   3m45s

For convenience, let’s export that IP number as an environment variable:

$ export PROXY_IP=167.172.7.192 # <--- use your own EXTERNAL-IP number here

Now you can check that Kong is working:

$ curl $PROXY_IP
{"message":"no Route matched with those values"}

Note: It’s the correct response because you haven’t yet told Kong what to do with any API calls it receives.

Configure Kong Gateway

You can use Ingress resources like this to configure Kong to route API calls to the microservices:

foo-ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: foo
  namespace: default

spec:
  ingressClassName: kong
  rules:
  - http:
      paths:
      - path: /foo
        pathType: Prefix
        backend:
          service:
            name: foo-service
            port:
              number: 5000

This gist defines ingresses for both microservices. Download and apply them:

$ kubectl apply -f foo-ingress.yaml
$ kubectl apply -f bar-ingress.yaml

Now, Kong will route calls to /foo to the foo microservice and /bar to bar.

You can check this using curl:

$ curl $PROXY_IP/foo
{"msg":"Hello from the foo microservice"}

$ curl $PROXY_IP/bar
{"msg":"Hello from the bar microservice"}

What Else Can You Do?

In this article, I have:

• Deployed a Kubernetes cluster on DigitalOcean
• Created Docker images for two dummy microservices, “foo” and “bar”
• Deployed the microservices to the Kubernetes cluster
• Installed the Kong Ingress Controller
• Configured Kong to route API calls to the appropriate backend microservice

I’ve demonstrated one simple use of Kong, but it’s only a starting point. With Kong for Kubernetes, here are several examples of other things you can do:

Authentication

By adding an authentication plugin to Kong, you can require your API callers to provide a valid JSON Web Token (JWT) and check each call against an Access Control List (ACL) to ensure callers are entitled to perform the relevant operations.

Certificate management

You can enable integration with cert-manager to provision and auto-renew SSL certificates for your API endpoints so that all your API traffic is encrypted as it travels over the public internet.

gRPC support

Kong natively supports gRPC, so it’s easy to add gRPC support to your API.

You can do a lot more with Kong, and I’d encourage you to look at the documentation and start to explore some of the other features.

The API gateway is a crucial part of a microservices architecture, and the Kong Ingress Controller is well suited for this role in a Kubernetes cluster. You can manage it in the same way as any other Kubernetes resource.

Cleanup

Don’t forget to destroy your Kubernetes cluster when you are finished with it so that you don’t incur unnecessary charges:

1
2
3
4
5
6
$ kubectl delete -f https://bit.ly/k4k8s  # <-- this will destroy the load-balancer

$ doctl kubernetes cluster delete mycluster
Warning: Are you sure you want to delete this Kubernetes cluster? (y/N) ? y
Notice: Cluster deleted, removing credentials
...

Note: If you delete the cluster first, the load balancer will be left behind. You can delete any leftover resources via the DigitalOcean web interface.

Thanks for walking through this tutorial with us. It was originally published on our blog: https://bit.ly/316W3zw

🎥 Using Protobuf with Kafka Streams

Viktor Gamov — Fri, 19 Jun 2020 16:04:06 +0000

In case you missed (you should subscribe https://gamov.dev/youtube so you won't miss it in future) #LiveStreams episode this week I posted the recording with updated timecodes.

In this video, you will get an idea of how to use #protobuf with Kafka Streams(+ tests with TopologyTestDriver).

Also, I'm showing a new kafka-protobuf-console-consumer command-line tool that ships with Confluent Platform 5.5.

5 Kubernetes Tools You Probably Don’t Use (But You Should)

Viktor Gamov — Mon, 30 Mar 2020 05:06:08 +0000

Table of Contents

Put your prompt to work
Cluster context and namespaces switching on your fingertips
Monitoring cluster health and Kubernetes Resources Right From Your Terminal
Web UI to remote Kubernetes without installation!
Checking what the Helm is happening
Conclusion

TL;DR
In this post, I’m going to talk about few tools that I found very useful during my Kubernetes development and presentations. |

Earlier this year, I recorded a three-episode series, «Streaming on Kubernetes: It doesn’t have to be the hard way.»There I showed some demos of the Confluent Operator on Kubernetes. Many people reached out after and asked - «What kind of terminal do you use,» «What kind of plugins do you use» and so far and so on. And today, I’m going to be talking about five Kubernetes tools that I use in my demos (of during preparations to it) that you’re probably don’t use but defiantly should.

So, let’s get to it - it’s going to be fun!

Put your prompt to work

Name: kube-ps1
Github: https://github.com/jonmosco/kube-ps1

OK, I do demos.Many demos.OK, not like a lot of demos but still, a large number of demos.And things that I’m usually demoing very technical.So technical some things I demo don’t even have GUI.The only thing that I have to interact with those things is the command line interface, aka terminal.

As the theatre starts with a coat, a proper terminal starts with a prompt.Because during those technical demos, there are many things going in on the screen.

So, having an excellent terminal prompt that will allow the audience and yours truly always to know where we are?That’s why I appreciate kube-ps1 that displays information about the current Kubernetes cluster context as part of a terminal prompt.Also, it adds two a helper commands kubeon and kubeoff that allow for turning this prompt on and off on demand.

| | It does work great in bash and zsh. |

Figure 1. Current Kubernetes cluster in your command line

Cluster context and namespaces switching on your fingertips

Name: kubectx and kubens
Github: https://github.com/ahmetb/kubectx

Next, I do create and use many Kubernetes clusters on a daily basis.Some days I may create a few Kubernetes clustersSaying this, I need to switch between those quite often.It may need to type a few commands if you don’t know what full name of a cluster (and I can be a quire long)See yourself!

kubectx

kubectl config get-contexts (1)
kubectl config current-context (2)
kubectl config use-context <NAME OF CONTEXT> (3)

| 1 | Get list of all Kubernetes clusters configured in your system |
| 2 | Get a current cluster context |
| 3 | Set desired cluster context |

Not so useful, right?Yet, there is a better way!

Enter kubectx.

kubectx allows switching between Kubernetes clusters few quickly.It also integrates with command pager utility, and allows you to have some text menu where you can choose a specific cluster!

As a bonus, there is another tool that comes from the same author called kubens that I allow to switch namespaces withing the same cluster context.Same with namespace switching - not rocket science, but you need to remember or google those commands all the time.

Monitoring cluster health and Kubernetes Resources Right From Your Terminal

Name: k9s
Github: https://github.com/derailed/k9s

OK, good, now you learned to switch between Kubernetes clusters and namespaces in those clusters.The next tool can be a bit useful because it provides a GUI (terminal UI) tool that allows you to interact with your Kubernetes cluster.

You can see:

Standard Kubernetes resources and well as custom resources and KafkaCluster or PhysicalStatefulCluster
You can drill down to pods and see logs from the individual containers.
You watch health and vitals of your Kubernetes cluster and your applications.

Also, this tool has many customization hooks!

Web UI to remote Kubernetes without installation!

Name: octant
Github: https://github.com/vmware-tanzu/octant

Have you ever used Kubernetes Dashboard?Yes, you have because it’s a standard monitoring dashboard for Kubernetes.But there is one slight problem - it requires installation on your cluster.If you don’t have enough rights, or your operations folks don’t want to have extra crap installed in your Kubernetes cluster, this may be a challenge to get you GUI.

Enter Octant. It’s a web-based Kubernetes resource visualizer.

And it doesn’t require installation on your Kubernetes cluster.Octant runs locally on your machine and talks to Kubernetes via standard API calls.

Figure 2. Killer feature is a resource dependency graph

Figure 3. Apart from understanding standard Kubernetes resource, octant shows some custom resources

Another very cool feature of octant is «Port Forwarding».It works like this:

Navigate to the resource, e.g. controlcenter StatefulSet
Scroll to the container that want to forward ports from.
And you can click «Start Port Forward».
Octant UI will display localhost and port to the pod.

Figure 4. Octant port-forwarding Control Center on localhost

Figure 5. You can get a list of all port forwards

Checking what the Helm is happening

Name: Helm Cabin
Github: https://github.com/Nick-Triller/helm-cabin

Our last small nifty tool for today is Helm Cabin - your dashboard for helm releases.image::helm-cabin.jpg[]

You will be able to see all your helm releases deployed to given Kubernetes cluster.Once you click on one of the release names, we drill down to some helm release info - NOTES from chart, templates and values, and «effective» chart.

Figure 6. Chart details

In my opinion, this is pretty useful tool for housekeeping and audit purposes.

Conclusion

If you have found this video useful or entertaining, hit that like button and consider subscribing to this channel.Stay tuned for the next one.And as always, have a nice day!

Tips And Tricks That I use in my demos and presentation with Docker

Viktor Gamov — Wed, 28 Nov 2018 18:00:00 +0000

Table of Contents

Delete every Docker containers
Open shell in running container
- Extra carriculum matterial: How to do the same in case of Docker Compose?

Figure 1. A very small tip for you!

TL;DR

The sole purpose of this post is to help me to return here time to time if I forget some of the commands.If this would be useful for anyone - praise me on twitter - http://twitter.com/gamussa.

Let’s start with a small but important thing - how to erase everything Docker and start clean.

Delete every Docker containers

|NOTE:| Don’t do this if you’re on the plane. Downloading new images using the airline’s wifi will be the pain. Proceed with caution. You have been warned. |

How many time you have found yourself running out of space in your laptop, and you don’t know who’s eating all the space.Usual suspects here are maven or gradle directory jar’s directory and Docker images directory.

❯ du -sh ~/.m2
2.4G /Users/viktor/.m2 (1)

❯ du -sh ~/.gradle
2.8G /Users/viktor/.gradle (2)

❯ du -sh ~/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/Docker.raw
8.1G /Users/viktor/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/Docker.raw

| 1 | Should I nuke it? |
| 2 | I definitely use Gradle more |

Must be run first because images are attached to containers

docker rm -f $(docker ps -a -q)

Delete every Docker image

docker rmi -f $(docker images -q)

Open shell in running container

If I have a container that already running I can use docker exec command to connect to it!

First, get the name of the existing container using docker ps

With docker exec -it <container name> /bin/bash to get a bash shell in the container

Essentially, use docker exec -it <container name> <command> to execute whatever command you specify in the container.

Extra curriculum material: How to do the same in case of Docker Compose?

docker-compose run <container_name_in_yml_file> <command>.

E.g. to get a shell into your Kafka container, you might run docker-compose run kafka1 /bin/bash

To run a series of commands, you must wrap them in a single command using a shell

docker-compose run <name in yml> sh -c '<command 1> && <command 2> && <command 3>'

The docker run command accepts command-line options to specify volume mounts, environment variables, the working directory, and more.