This document summarizes common questions and answers about using cloud-native gateways.
Product Inquiries
What Is a Cloud Native Gateway?
Cloud Native Gateway is a high-performance, highly available gateway product launched by Tencent Cloud based on the open-source microservices gateway (Kong). As the traffic entry point for cloud-based microservices architectures, it integrates features such as request distribution, API management, traffic monitoring, and access control, and provides:
Traffic Gateway: It provides unified access and intelligent scheduling for north-south traffic.
Microservices Gateway: It provides east-west traffic management and inter-service communication.
Security Gateway: It provides end-to-end security protection and authentication/authorization.
What Is the Difference Between a Cloud Native Gateway and an AI Gateway?
Cloud Native Gateway addresses scenarios involving traditional microservices and cloud-native traffic management, solving problems related to the access, routing, rate limiting, circuit breaking, and security protection of north-south and east-west traffic.
AI Gateway targets large model and intelligent scenarios, focusing on solving core challenges enterprises face when accessing, scheduling, and managing multiple AI models, including protocol complexity, governance difficulties, uncontrollable costs, and high barriers to legacy system transformation.
Both belong to the cloud-native intelligent gateway product family and can be independently selected based on business needs.
Is the Managed Service Provided by Cloud Native Gateway a Dedicated Instance?
Cloud Native Gateway provides each user with physically isolated, resource-dedicated instances to ensure performance and security.
Purchase and Billing
How to Purchase a Cloud Native Gateway
Log in to the Cloud Native Gateway console and create and purchase instances on the relevant pages. Cloud Native Gateway supports purchasing based on node specifications and quantity, and also supports adjusting node specifications and quantity after purchase. What Are the Current Purchase Restrictions for Cloud Native Gateway?
Currently, Cloud Native Gateway supports new purchases via allowlist only for microservices scenarios. Other scenarios do not support new access.
What Node Specifications Does Cloud Native Gateway Offer?
Cloud Native Gateway offers various node specifications, such as 2-core 4GB, 4-core 8GB, 8-core 16GB, and 16-core 32GB. You can select the appropriate resource size based on your business needs. The gateway also supports modifying node specifications and quantities after purchase.
Usage
What Is the Purpose of the VPC Selected When a Cloud Native Gateway Instance Is Created?
The VPC selected when a Cloud Native Gateway instance is created is primarily used for communication with other customer resources. The gateway uses one IP address from the subnet of this VPC as its private network entry point. Additionally, when the gateway accesses backend services, it uses a corresponding number of IP addresses from the subnet based on the context of the original text, for communication with other resources within the VPC. Therefore, ensure that the selected subnet has sufficient available IP addresses.
What Service Sources Does Cloud Native Gateway Support?
Cloud Native Gateway associates backend services through service sources. Supported service sources include:
K8s services (using TKE or EKS).
Registry services (using TSF or self-built Nacos/Consul/Polaris)
Container services (TKE, EKS).
Serverless Cloud Functions (SCF).
Services on Tencent Cloud Virtual Machines (CVM).
Domain names, fixed IP addresses, or IP address lists that do not rely on any service discovery mechanism.
Private Domain Name System (PrivateDNS).
What Protocols Does Cloud Native Gateway Support?
Cloud Native Gateway supports protocol conversion for TCP, UDP, HTTP/HTTPS, WebSocket, as well as conversions from HTTP/HTTPS to gRPC and from HTTP/HTTPS to Dubbo.
What Management Methods Does Cloud Native Gateway Support?
Cloud Native Gateway supports multiple access methods, including the Tencent Cloud console, Ingress, TencentCloud API, the native console (Konga), and Terraform. You can choose the method based on your usage habits.
How Does Cloud Native Gateway Ensure High Availability?
Access points (CLB), gateway nodes, and gateway configurations all support deployment across multiple AZs, and critical paths achieve cross-AZ disaster recovery. The platform also provides open-source enhanced traffic protection capabilities such as rate limiting, canary release, circuit breaking, and traffic mirroring. It supports zero-downtime service deployment and allows chaos engineering drills by simulating faults.
How Does Cloud Native Gateway Perform Security Protection?
Cloud Native Gateway supports the following security capabilities:
It integrates with Tencent Cloud Web Application Firewall (WAF) and supports protection at the instance, service, and route levels.
Integrate with Tencent Cloud DDoS Protection (Anti-DDoS IP or Anti-DDoS Package).
Use the Tencent Cloud Certificate Management Platform (SSL) to manage certificates.
It supports common API authentication and authorization methods (such as username/password, key-based authentication, JWT, OAuth2) and custom authorization.
Cloud Native API Gateway supports the IP address blocklist/allowlist for access control.
What Monitoring and Logging Capabilities Does Cloud Native Gateway Support?
It allows you to view monitoring metrics such as number of requests, latency, CPU, memory, bandwidth, and number of connections in the console and configure custom alarms. It also supports integration with Prometheus. You can view gateway request logs and error logs in the console. Logs can be delivered to Tencent Cloud Log Service (CLS) for analysis or to CKafka.
Performance and Specifications
What Is the Recommended Operating Watermark for Cloud Native Gateway?
Recommended threshold: CPU utilization 30%, memory utilization 30%.
Alert threshold: CPU utilization 60%, memory utilization 60%.
It is recommended to maintain resource utilization between 30% and 60% during normal operations. This range helps achieve high resource efficiency while allowing the system to handle sudden traffic spikes. When utilization is below the alert threshold, the gateway is fully covered by the SLA. If the threshold is exceeded, the gateway enters a high-load state, which may affect request success rates and latency. We recommend configuring alarms for this scenario.
What Are the Capacity Metrics for Different Node Specifications (Single-Node Alert Watermark)?
|
Maximum Number of Connections | 48000 | 96000 | 192000 | 384000 |
HTTP New Connections Per Second | 4000 | 8000 | 16000 | 32000 |
HTTPS New Connections Per Second | 1200 | 2400 | 4800 | 9600 |
What Are the Methods for Increasing Gateway Capacity?
You can increase gateway capacity by scaling up node specifications or scaling out the number of nodes. When node specifications remain unchanged, gateway capacity scales approximately linearly with the number of nodes.
AS
What Types of AS Does Cloud Native Gateway Support?
Auto Scaling (AS) supports two types of scaling policies: metric-based rules and scheduled rules (available in the Professional Edition only).
Metric-based rules: These rules are suitable for scenarios with sudden traffic spikes or typical periodic traffic. They define the scaling trigger conditions and the change in the number of nodes using metrics (such as CPU utilization, memory utilization, and QPS) and thresholds.
Scheduled rules: These rules are suitable for scenarios where resource utilization follows a periodic pattern. The system automatically adjusts the number of instance nodes when the configured periodic time point is reached.
Why Is the AS Policy Not Effective After Creation?
An Auto Scaling (AS) policy must be bound to a cluster group to take effect. You can bind it to one or multiple cluster groups at a time. To complete the binding, go to the AS policy list page and click Bind Group on the right side of the target policy.
How Do Metric-Based Scaling and Scheduled Scaling Take Effect When Configured Simultaneously?
When both policies are configured, the gateway adjusts the number of nodes by combining the content of both policies. Scheduled scaling does not directly adjust the number of nodes. Instead, it performs scaling decisions and adjustments by modifying the metric-based scaling range for the number of nodes. The final number of nodes is then adjusted accordingly based on this modified range.
Migration
How to Migrate from a Self-Built Kong Gateway to Cloud Native Gateway
You can use the official Kong decK tool to migrate configurations. The main steps are as follows:
1. Use deck dump to export the configurations (services, routes, plugins) from your self-managed Kong gateway.
2. Use deck diff to view the configuration differences. After confirming they are correct, use deck sync to import the configurations to the cloud-native gateway Kong.
3. Check whether the configurations have been imported successfully in the Cloud Native Gateway console.
How to Migrate from Spring Cloud Gateway (SCG) to Cloud Native Gateway
The main migration steps are as follows:
1. Identify the service source: If the current service source is a K8s service, a registry service (TSF/Nacos/Consul/Polaris), or a domain name/fixed IP/IP list, you can migrate it directly. For other types of registries, you must first register the services with Nacos/Consul/Polaris.
2. Migrating configurations: The services/routes in SCG correspond to the services/routes in the cloud-native gateway. Predicates are implemented through route matching conditions or canary rules. Filters are implemented using plugins such as tse-proxy-rewrite, rate limiting capabilities, and custom plugins.
3. Configure monitoring alarms.
4. Traffic migration: Gradually switch traffic using a canary approach. First, validate with a small-scale deployment of non-core services. Then, expand to core services. Finally, switch the DNS resolution to complete the full migration.
What Are the Advantages of Cloud Native Gateway over Self-Built Gateways?
|
Setup and Ops cost | Fully managed resources with no Ops required, supporting specification/node quantity/billing mode changes, edition upgrades, and AS. | Requires self-procurement of resources for setup, with high labor costs. |
High availability | Access points, nodes, and configurations all support cross-AZ disaster recovery, providing comprehensive traffic protection. | Requires self-exploration and development of a high-availability system. |
Ease of use | Supports multiple methods including the console, Ingress, TencentCloud API, and Konga. | Requires self-setup and Ops. |
Security | Integrates with WAF, DDoS protection, and SSL Certificates, and supports authentication, authorization, allowlist, and blocklist. | Requires self-integration with relevant cloud products. |
Observability | View monitoring metrics and set alarms in the console, with support for Prometheus and CLS. | Only basic monitoring is provided, requiring self-setup. |
Cloud product integration | Deeply integrated with TSF, TKE, SCF, CVM, WAF, CLS, SSL, and more | Not supported |