Gateways play a pivotal role in application connectivity. In the Kubernetes cloud-native world, Gateway API is gaining traction as a powerful standard for defining gateways and exposing your applications and services in a security-focused and scalable way. Kuadrant, a Red Hat-sponsored project, brings together Gateway API and Policies to help you scale, load-balance, and secure your gateways in single or multi-cluster environments.
What are we announcing?
Earlier this year, we wrote about how you can use Kuadrant to add rate limiting and AuthN/Z to your services. Since then we have evolved those policies and developed some new policies with a focus on solving large-scale multi-cluster application connectivity problems. We have been busy working on our first upstream release, with lots of documentation updates, new guides, and reference material, and we are pleased to announce it is now ready.
In this post, we have included more details on what the project is, who it is for, how it works and what's coming in the future. However, if you'd prefer to jump in and try it out yourself, give our quickstart a go.
Who is Kuadrant for?
At its core, Kuadrant provides a set of Kubernetes APIs for managing your application connectivity problems, such as AuthN/Z, rate limiting, DNS, unhealthy endpoint mitigation and TLS. So first and foremost, Kuadrant is for platform engineers who are looking to define infrastructure and protect it, but it can also be leveraged by application developers who want to define how their own applications should be accessed and rate-limited.
These APIs are intended to give the platform engineer a cloud-native, declarative way to manage important areas such as global load balancing and TLS and gateway definition and placement. They also enable platform engineers and application developers to configure, protect, and help secure their application endpoints. This concept is important for a zero trust architecture.
For example, the platform engineer can manage DNS for all application hosts centrally via a DNSPolicy. They can also enforce security for all applications in a set of gateways via a TLSPolicy, providing a safe set of coarse-grained behavior. Application developers can use the AuthPolicy and RateLimitPolicy APIs to configure the fine-grained aspects of their applications.
If (or when) the platform engineer needs to scale their platform beyond a single cluster, Kuadrant can scale alongside the platform. It has a concept of a multi-cluster gateway, which implements the Gateway API spec. A multi-cluster gateway allows the platform engineer to define a gateway centrally and have multiple instances of it deployed to multiple clusters. An additional benefit of this is being able to manage DNS weighting, geo-based routing, load balancing, and endpoint health checks across different gateway instances. This advanced feature is intended for applications deployed to multiple locations for reasons such as resiliency or compliance.
How does Kuadrant work?
In a single Kubernetes cluster, the Kuadrant components Authorino and Limitador and the associated operators reconcile any AuthPolicies and RateLimitPolicies from application namespaces. AuthPolicy and RateLimitPolicy are Kubernetes CRDs introduced by Kuadrant. Those components interact with the Gateway API provider to enforce those policies. Policies can target specific HTTPRoutes, or an entire set of listeners in a gateway. At this time, Kuadrant supports Istio as the Gateway API provider.
The multi-cluster Kubernetes environment extends on the single-cluster environment by leveraging OCM (open cluster management) for its placement and status aggregation capabilities and installing an additional component, the Multicluster Gateway Controller. This controller runs in a hub cluster, while the other Kuadrant components run in spoke clusters. The controller understands the Gateway API specification for gateway resources, specifically a multi-cluster gateway. A multi-cluster gateway is declared once in the hub cluster and gets instantiated in spoke clusters alongside applications. Policies defined in the hub cluster, like DNS and TLS, can target a multi-cluster Gateway. The controller has sufficient context about spoke clusters to manage DNS records and distribute TLS certificates to the right clusters.
Kuadrant currently supports Google Cloud DNS and Route 53 for DNS management. TLS capabilities use the cert-manager project, which supports many certificate issuers, like Lets Encrypt and ZeroSSL.
What's next for Kuadrant?
The Kuadrant project is transitioning from early development to sharing for collaboration. There are lots of opportunities to get involved and influence where the project goes from here. That being said, some things are high on our list of priorities, such as:
- Additional DNS provider support for CoreDNS and Azure DNS
- Integration with external-dns
- Envoy Gateway support
- Extending the policy set to work seamlessly in both single- and multi-cluster environments (e.g., rate limiting across clusters or single-cluster DNSPolicies)
- Allowing overrides and defaults as part of the policy definitions as per Gateway API inherited policy attachment concepts
- We have been experimenting with East-West multi-cluster architectures using Skupper and Submariner.
- We also have an early-stage multi-cluster observability architecture using Prometheus metrics federation and a set of Grafana dashboards.
We are also working closely with Red Hat product management on opportunities to include Kuadrant as part of a future product offering.
If you are interested in trying out the Kuadrant project, check out our Getting Started guide. You can get in touch with the developers on Kubernetes Slack if you have any questions, problems, or suggestions. If you really like the project and would like to get involved, check out our Community page for details. We also have a YouTube channel for demos, and a weekly community call where we discuss priorities, proposals, and implementation.
저자 소개
David Martin has been working in the area of managed services since 2009. Ranging from a mobile backend platform based on Node.js and Linux containers, to API and Integration products running on customer OpenShift clusters. His role has revolved around core engineering, with a hint of on-call operations, SRE methodology and observability. More recently he has been involved in the area of multicluster Kubernetes and API management.
Software Engineer working at RedHat since 2011. Craig is one of the architects for Kuadrant.
Since 2017, unwaveringly committed to crafting innovative solutions for API management, Application Connectivity and Security with Red Hat. A proud member of the core team responsible for bringing Authorino and Kuadrant to life.
채널별 검색
오토메이션
기술, 팀, 인프라를 위한 IT 자동화 최신 동향
인공지능
고객이 어디서나 AI 워크로드를 실행할 수 있도록 지원하는 플랫폼 업데이트
오픈 하이브리드 클라우드
하이브리드 클라우드로 더욱 유연한 미래를 구축하는 방법을 알아보세요
보안
환경과 기술 전반에 걸쳐 리스크를 감소하는 방법에 대한 최신 정보
엣지 컴퓨팅
엣지에서의 운영을 단순화하는 플랫폼 업데이트
인프라
세계적으로 인정받은 기업용 Linux 플랫폼에 대한 최신 정보
애플리케이션
복잡한 애플리케이션에 대한 솔루션 더 보기
오리지널 쇼
엔터프라이즈 기술 분야의 제작자와 리더가 전하는 흥미로운 스토리
제품
- Red Hat Enterprise Linux
- Red Hat OpenShift Enterprise
- Red Hat Ansible Automation Platform
- 클라우드 서비스
- 모든 제품 보기
툴
체험, 구매 & 영업
커뮤니케이션
Red Hat 소개
Red Hat은 Linux, 클라우드, 컨테이너, 쿠버네티스 등을 포함한 글로벌 엔터프라이즈 오픈소스 솔루션 공급업체입니다. Red Hat은 코어 데이터센터에서 네트워크 엣지에 이르기까지 다양한 플랫폼과 환경에서 기업의 업무 편의성을 높여 주는 강화된 기능의 솔루션을 제공합니다.