Shulou(Shulou.com)06/02 Report--

This article mainly explains "what are the two challenges facing the API gateway when adopting Kubernetes". The content in the article is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "what are the two challenges facing the API gateway when adopting Kubernetes?"

KUBERNETES and edge computing to extend edge management and support multiple requirements

Building applications using the micro-service pattern and deploying these services to Kubernetes has become a practical way to run cloud-native applications today. In the microservice architecture, a single application is decomposed into multiple microservices. Each microservice is owned by a small team that has the authority and responsibility to make the right decisions for specific microservices.

This responsibility usually starts at the edge of the system where the user request arrives, all the way to the business logic of the service, and then to the associated messaging and data storage architecture.

Edge and Kubernetes entrances

End users need to access microservices. The boundary between the internal microservice and the end user is called the edge. In order for end users to access internal applications, traffic needs to cross the edge. In Kubernetes, traffic traverses the edge using software called ingress.

When integrating API gateways with micro-service-based applications running on Kubernetes, you must consider two main challenges:

How to extend the management of over 100 services and related API; and

How gateways support a wide range of microservice architectures, protocols, and configurations that typically span the entire edge stack.

API Gateway: the point of contact for microservices

How the API gateway manages, protects, and presents the core of API. It is deployed as a software component (or a series of components) on a virtual machine or in Kubernetes and acts as a single entry point to the system. The main responsibility of API gateway is to enable users to access multiple API, micro-services and back-end systems reliably and securely.

Microservices and Kubernetes provide implementation flexibility. For example, a team could choose to expose container-based microservices as a set of HTTP-based REST API at the edge of the system (the boundary between internal services and end users). Another team may choose Protobufs and gRPC. Teams with real-time streaming requirements can expose their micro-services through WebSocket API. Any API gateway deployed in Kubernetes must support all of these protocols.

Each team is not only free to make these choices, but also responsible for the consequences. This usually translates into "you build, run". Although not every organization fully agrees with this way of working, every microservices team needs to be able to understand, diagnose, and configure all aspects of processing each service and each user's request to the application. The diversity of runtime requirements related to applications and API means that each team will use all the layers in the edge stack, such as dynamic request processing, WAF, and any caching implementation.

The development paradigm of microservices (independent, authorized and responsible teams) presents a series of new challenges for microservices teams using API gateways, Kubernetes portals and edges.

In this article, we identified two important edge challenges: managing independent microservices and accessing a comprehensive edge stack.

Challenge 1: extend Edge Management

As the number of microservices deployed increases, so do the challenges at the management edge

In the micro-service architecture, engineers will manage more services and applications. Each team needs to be able to manage their services independently to decouple the release from the plans of other teams. The traditional method of exposing applications at the edge is usually done through centralized operations or platform teams. However, when an organization has hundreds of microservices, an operations team cannot scale to handle the necessary changes.

Typical changes that need to be modified at the edge:

A new version of the service being deployed.

Modify endpoints, routing instructions, or associated back-end services.

Changes to authentication and authorization services.

Modify non-functional requirements, such as rate limits, timeouts, retry modes, and outages.

User testing of new features, for example, enabling functionality for a small number of Beta test users.

The adoption of a micro-service-based architecture will result in a significant increase in the number of releases. This increase will only exacerbate the challenges of edge management and increase the pressure on centralized operating methods.

Challenge 2: support a wide range of marginal requirements

Microservices introduce a lot of new problems at the edge

The micro-service architecture enables architectural flexibility. Application developers use this flexibility to choose the programming language and architecture that best suits the specific requirements of the service. Regardless of the architecture, the edge needs to support a wide range of features that need to be exposed to users. This extends the traditional role of API gateways, and some of the challenges related to edge consolidation tool requirements include:

Ability to route various protocols skillfully. Common protocols include HTTP / 1.1 Magi HTTP / 2 Magi WebSocket gRPC Magi gRPC ML Web and TCP.

Provides a complete set of edge functions required for any particular service, ranging from traffic management to observability to authentication.

Expose these features in the self-service model for application developers.

Encouraging the diversity of microservice team implementations allows engineers to choose "suitable tools for work". However, the integration of the underlying platform provides many benefits. Instead of allowing developers to build custom implementations to provide additional protocol support or security handling, let them have pre-approved "self-help" options at the edge so that they can choose the most appropriate options. making it easier to manage and extend. Function combination.

Thank you for your reading. the above is the content of "what are the two challenges facing the API gateway when adopting Kubernetes". After the study of this article, I believe you have a deeper understanding of what are the two challenges faced by the API gateway when adopting Kubernetes, and the specific usage needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.