Kong vs Kubernetes

Get Advice Icon

Need advice about which tool to choose?Ask the StackShare community!

Kong
Kong

212
258
+ 1
90
Kubernetes
Kubernetes

8K
6.4K
+ 1
543
Add tool

Kong vs Kubernetes: What are the differences?

Kong: Open Source Microservice & API Management Layer. Kong is a scalable, open source API Layer (also known as an API Gateway, or API Middleware). Kong controls layer 4 and 7 traffic and is extended through Plugins, which provide extra functionality and services beyond the core platform; Kubernetes: Manage a cluster of Linux containers as a single system to accelerate Dev and simplify Ops. Kubernetes is an open source orchestration system for Docker containers. It handles scheduling onto nodes in a compute cluster and actively manages workloads to ensure that their state matches the users declared intentions.

Kong can be classified as a tool in the "Microservices Tools" category, while Kubernetes is grouped under "Container Tools".

Some of the features offered by Kong are:

  • Logging: Log requests and responses to your system over TCP, UDP or to disk
  • OAuth2.0: Add easily an OAuth2.0 authentication to your APIs
  • Monitoring: Live monitoring provides key load and performance server metrics

On the other hand, Kubernetes provides the following key features:

  • Lightweight, simple and accessible
  • Built for a multi-cloud world, public, private or hybrid
  • Highly modular, designed so that all of its components are easily swappable

"Easy to maintain" is the top reason why over 28 developers like Kong, while over 134 developers mention "Leading docker container management solution" as the leading cause for choosing Kubernetes.

Kong and Kubernetes are both open source tools. It seems that Kubernetes with 55.1K GitHub stars and 19.1K forks on GitHub has more adoption than Kong with 22.4K GitHub stars and 2.75K GitHub forks.

According to the StackShare community, Kubernetes has a broader approval, being mentioned in 1046 company stacks & 1096 developers stacks; compared to Kong, which is listed in 50 company stacks and 14 developer stacks.

What is Kong?

Kong is a scalable, open source API Layer (also known as an API Gateway, or API Middleware). Kong controls layer 4 and 7 traffic and is extended through Plugins, which provide extra functionality and services beyond the core platform.

What is Kubernetes?

Kubernetes is an open source orchestration system for Docker containers. It handles scheduling onto nodes in a compute cluster and actively manages workloads to ensure that their state matches the users declared intentions.
Get Advice Icon

Need advice about which tool to choose?Ask the StackShare community!

Why do developers choose Kong?
Why do developers choose Kubernetes?

Sign up to add, upvote and see more prosMake informed product decisions

    Be the first to leave a con
    Jobs that mention Kong and Kubernetes as a desired skillset
    What companies use Kong?
    What companies use Kubernetes?

    Sign up to get full access to all the companiesMake informed product decisions

    What tools integrate with Kong?
    What tools integrate with Kubernetes?

    Sign up to get full access to all the tool integrationsMake informed product decisions

    What are some alternatives to Kong and Kubernetes?
    Istio
    Istio is an open platform for providing a uniform way to integrate microservices, manage traffic flow across microservices, enforce policies and aggregate telemetry data. Istio's control plane provides an abstraction layer over the underlying cluster management platform, such as Kubernetes, Mesos, etc.
    Jersey
    It is open source, production quality, framework for developing RESTful Web Services in Java that provides support for JAX-RS APIs and serves as a JAX-RS (JSR 311 & JSR 339) Reference Implementation. It provides it’s own API that extend the JAX-RS toolkit with additional features and utilities to further simplify RESTful service and client development.
    linkerd
    linkerd is an out-of-process network stack for microservices. It functions as a transparent RPC proxy, handling everything needed to make inter-service RPC safe and sane--including load-balancing, service discovery, instrumentation, and routing.
    Express Gateway
    A cloud-native microservices gateway completely configurable and extensible through JavaScript/Node.js built for ALL platforms and languages. Enterprise features are FREE thanks to the power of 3K+ ExpressJS battle hardened modules.
    Azure Service Fabric
    Azure Service Fabric is a distributed systems platform that makes it easy to package, deploy, and manage scalable and reliable microservices. Service Fabric addresses the significant challenges in developing and managing cloud apps.
    See all alternatives
    Decisions about Kong and Kubernetes
    Yshay Yaacobi
    Yshay Yaacobi
    Software Engineer · | 27 upvotes · 343.9K views
    atSolutoSoluto
    Docker Swarm
    Docker Swarm
    .NET
    .NET
    F#
    F#
    C#
    C#
    JavaScript
    JavaScript
    TypeScript
    TypeScript
    Go
    Go
    Visual Studio Code
    Visual Studio Code
    Kubernetes
    Kubernetes

    Our first experience with .NET core was when we developed our OSS feature management platform - Tweek (https://github.com/soluto/tweek). We wanted to create a solution that is able to run anywhere (super important for OSS), has excellent performance characteristics and can fit in a multi-container architecture. We decided to implement our rule engine processor in F# , our main service was implemented in C# and other components were built using JavaScript / TypeScript and Go.

    Visual Studio Code worked really well for us as well, it worked well with all our polyglot services and the .Net core integration had great cross-platform developer experience (to be fair, F# was a bit trickier) - actually, each of our team members used a different OS (Ubuntu, macos, windows). Our production deployment ran for a time on Docker Swarm until we've decided to adopt Kubernetes with almost seamless migration process.

    After our positive experience of running .Net core workloads in containers and developing Tweek's .Net services on non-windows machines, C# had gained back some of its popularity (originally lost to Node.js), and other teams have been using it for developing microservices, k8s sidecars (like https://github.com/Soluto/airbag), cli tools, serverless functions and other projects...

    See more
    Kong
    Kong

    I use Kong because it reliably proxies traffic quickly with an assortment of pluggable features. The engineers behind the product are of the highest quality. The Company has cultivated the largest active open source community of any API gateway. They generally squash bugs in hours or days not weeks/months. Company engineers help community members through social avenues as well as supporting large enterprise. They heavily value their product and individuals as opposed to just solely growing enterprise license fees.

    See more
    Al Tsang
    Al Tsang
    CEO at LunchBadger · | 4 upvotes · 41.2K views
    atLunchBadgerLunchBadger
    Tyk Cloud
    Tyk Cloud
    Kong
    Kong
    ExpressJS
    ExpressJS
    Express Gateway
    Express Gateway
    #Gateway
    #OAuth2
    #JWT
    #APIs
    Problem/Challenge

    We needed a lightweight and completely customizable #microservices #gateway to be able to generate #JWT and introspect #OAuth2 tokens as well. The #gateway was going to front all #APIs for our single page web app as well as externalized #APIs for our partners.

    Contenders

    We looked at Tyk Cloud and Kong. Kong's plugins are all Lua based and its core is NGINX and OpenResty. Although it's open source, it's not the greatest platform to be able to customize. On top of that enterprise features are paid and expensive. Tyk is Go and the nomenclature used within Tyk like "sessions" was bizarre, and again enterprise features were paid.

    Decision

    We ultimately decided to roll our own using ExpressJS into Express Gateway because the use case for using ExpressJS as an #API #gateway was tried and true, in fact - all the enterprise features that the other two charge for #OAuth2 introspection etc were freely available within ExpressJS middleware.

    Outcome

    We opened source Express Gateway with a core set of plugins and the community started writing their own and could quickly do so by rolling lots of ExpressJS middleware into Express Gateway

    See more
    Sebastian Gębski
    Sebastian Gębski
    CTO at Shedul/Fresha · | 6 upvotes · 57.2K views
    atFresha EngineeringFresha Engineering
    Docker
    Docker
    Docker Compose
    Docker Compose
    Kubernetes
    Kubernetes
    Terraform
    Terraform
    Ansible
    Ansible
    Amazon EC2
    Amazon EC2
    Amazon EKS
    Amazon EKS
    Amazon S3
    Amazon S3
    Amazon RDS
    Amazon RDS

    Heroku was a decent choice to start a business, but at some point our platform was too big, too complex & too heterogenic, so Heroku started to be a constraint, not a benefit. First, we've started containerizing our apps with Docker to eliminate "works in my machine" syndrome & uniformize the environment setup. The first orchestration was composed with Docker Compose , but at some point it made sense to move it to Kubernetes. Fortunately, we've made a very good technical decision when starting our work with containers - all the container configuration & provisions HAD (since the beginning) to be done in code (Infrastructure as Code) - we've used Terraform & Ansible for that (correspondingly). This general trend of containerisation was accompanied by another, parallel & equally big project: migrating environments from Heroku to AWS: using Amazon EC2 , Amazon EKS, Amazon S3 & Amazon RDS.

    See more
    Emanuel Evans
    Emanuel Evans
    Senior Architect at Rainforest QA · | 12 upvotes · 155.2K views
    atRainforest QARainforest QA
    Heroku
    Heroku
    Kubernetes
    Kubernetes
    Google Kubernetes Engine
    Google Kubernetes Engine
    Google Cloud SQL for PostgreSQL
    Google Cloud SQL for PostgreSQL
    PostgreSQL
    PostgreSQL
    Google Cloud Memorystore
    Google Cloud Memorystore
    Redis
    Redis
    CircleCI
    CircleCI
    Google Cloud Build
    Google Cloud Build
    Helm
    Helm
    Terraform
    Terraform

    We recently moved our main applications from Heroku to Kubernetes . The 3 main driving factors behind the switch were scalability (database size limits), security (the inability to set up PostgreSQL instances in private networks), and costs (GCP is cheaper for raw computing resources).

    We prefer using managed services, so we are using Google Kubernetes Engine with Google Cloud SQL for PostgreSQL for our PostgreSQL databases and Google Cloud Memorystore for Redis . For our CI/CD pipeline, we are using CircleCI and Google Cloud Build to deploy applications managed with Helm . The new infrastructure is managed with Terraform .

    Read the blog post to go more in depth.

    See more
    Docker
    Docker
    Docker Compose
    Docker Compose
    Jenkins
    Jenkins
    Kubernetes
    Kubernetes
    Amazon EC2
    Amazon EC2
    Heroku
    Heroku
    FeathersJS
    FeathersJS
    Node.js
    Node.js
    ExpressJS
    ExpressJS