Kong for Kubernetes is a Kubernetes Ingress Controller based on the Kong Gateway open source project. Kong for K8s is fully Kubernetes-native and provides enhanced API management capabilities. From an architectural perspective, Kong for K8s consists of two parts: A Kubernetes controller, which manages the state of Kong for K8S ingress configuration, and the Kong Gateway, which processes and manages incoming API requests.
When protecting your online services, the weakest link is represented by the endpoints – that is, by the end-user devices running web or mobile applications or by external systems leveraging open APIs. As a matter of fact, there is a growing number of targeted attacks leveraging sophisticated techniques such as malicious web injections, mobile overlay and API abuse attacks to perform identity hijacking, account takeover, transaction tampering and payment frauds.
In his most recent blog post, Marco Palladino, our CTO and co-founder, went over the difference between API gateways and service mesh. I highly recommend reading his blog post to see how API management and service mesh are complementary patterns for different use cases, but to summarize in his words, “an API gateway and service mesh will be used simultaneously.” We maintain two open source projects that work flawlessly together to cover all the use cases you may encounter.
A modern API gateway like Kong enables organizations to achieve some use cases much more easily than traditional gateways. The reason is older, traditional gateways try to provide as many features as possible into a heavyweight monolith, while modern solutions use a best-in-breed approach. These traditional solutions not only try to be a gateway, but they also try to be a business intelligence system, a central logging hub, a monitoring tool and so much more.
Let’s admit it – web services (SOAP) are here to stay for a few more years, and maybe for a long time in some places where there is no business incentive to rebuild them. However, with a decline in new SOAP web services and most applications moving to cloud native architectures, a common query is “how can we support legacy services while moving to microservices?”
We are happy to announce the release of Kuma 0.4! This is a major release focused on significantly better observability capabilities that also includes many new features and improvements across the board. This release also marks the 10th release of Kuma since September 2019!
For many years, API Management (APIM) — and the adoption of API gateways — was the primary technology used to implement modern API use cases both inside and outside the data center.
Infrastructure as Code (IaC) is a powerful process – replacing manual, error prone and expensive operations with automated, consistent and quick provisioning of resources. In many cases, IaC is dependent on existing infrastructure, typically including a configuration management system. Chef, Puppet and SaltStack are all commonly referenced players in this market, each requiring resources to be in place and having their own difficulties in setup and maintenance.
A common requirement for APIs is to rewrite the published URL to a different URL for the upstream service’s endpoint. For example, due to legacy reasons, your upstream endpoint may have a base URI like /api/oilers/. However, you want your publicly accessible API endpoint to now be named /titans/api.
After a full year of development since our last major open source release, we are proud to announce the next chapter of our flagship open-source API gateway — Kong Gateway 2.0 is generally available! With this release, Kong will become more operationally agnostic for large-scale deployments across on-premises and multi-cloud environments, thanks to the new Hybrid Mode. In addition, plugin development also becomes more language agnostic, thanks to the new Golang PDK support.
