Volcengine Kubernetes Engine
Volcengine Kubernetes Engine
Volcengine Kubernetes Engine
Document
Volcengine Kubernetes Engine
What's New
History feature release notes
Kubernetes version release notes
Containerd runtime release notes
Add-on release notes
Monitoring add-ons
Scheduling add-ons
DNS add-ons
Security add-ons
GPU add-ons
Sandbox add-on
Security announcements
Product Announcement
Historical announcements
Overview
Getting started
User guide
Clusters
Creating clusters
Connecting to clusters
Upgrading clusters
Node pool
Creating node pools
Scaling out/in node pools
Nodes
Authorization management
Image
Namespaces
Networking
Cluster network
Container Network
Service
LoadBalancer
CLB
Ingress
APIG Ingress
ALB Ingress
Customize ALB Ingress forwarding rules
Certificate and security
CLB Ingress
Nginx Ingress
Gateway API
Workloads
Creating workloads
Configure workloads
Pods
Configuration management
Image acceleration
Storage
FSX client
EBS Volumes
TOS Volumes
NAS volumes
FSX access methods
NFS access methods
EFS volumes
vePFS volumes
FSX access methods
vePFS Client access methods
NFS access methods
CloudFS volumes
Local volumes
Autoscale
Node autoscaler
Workload autoscaler
Horizontal Pod Autoscaler (HPA)
Cron Horizontal Pod Autoscaler (CronHPA)
Intelligent Horizontal Pod Autoscaler (IHPA)
Horizontal Pod Autoscaler based on event-driven (KEDA)
Add-on management
Network add-ons
Storage add-ons
Monitoring add-ons
Scheduling add-ons
DNS add-ons
GPU add-ons
Core add-ons
Sandbox add-on
Upgrading add-ons
Heterogeneous computing
NVIDIA GPU
mGPU scheduling
RDMA high-performance computing
Scheduling management
Topology-aware scheduling
QoS-aware scheduling
Observability
Log management
Basic observation
Setup & Configuration
Cluster observation
Storage observation
Other observation
Using metrics
Full stack observation
Alert management
Diagnosis and inspection
Node check and self-healing
Application center
Backup center
Stability
Large-scale cluster management
Best practices
Authorization
Clusters
Nodes and node pools
Networking
Storage
Scheduling
Observability
Solution
Security and compliance
API reference
Cluster management
NodePool management
Node management
Virtual nodes management
Add-on management
Tag management
Access policy management
Instance images management
Cloud native observability
Inspection and diagnosis
Task management
Volcengine Container Instance
Appendix
SDK reference
Development guide
Terraform
FAQs
General FAQs
Cluster FAQ
cluster management
cluster network
cluster upgrade
Node and Node pool FAQs
Authorization FAQs
Workload FAQs
Service and Ingress FAQs
Storage FAQs
Heterogeneous computing FAQs
Observability FAQs
Quota FAQs
Add-on FAQs
Cloud-native AI
ServingKit
LLM applications
ComfyUI application
Deploying the Al inference application through Helm
Deepseek practices
Qwen practices
Kimi practice
Seed practices
Best practices
DeepSeek model deployment
GLM model deployment
MiniMax model deployment
Qwen model deployment
Kimi model deployment
Volcengine Container Instance
What's new
Historical feature release notes
Product Announcement
Overview
Billing
User guide
Integrating with VCI
Virtual node
VKE cluster uses virtual nodes
Self-managed/third-party cluster uses virtual node
Creating an instance
General purpose instance
GPU-accelerated computing instance
VCI Agent Sandbox
Startup acceleration
E2B-based management
Upgrade guide
Networking
Monitoring
Scheduling
Container configuration
VCI Image Cache
Best practices
Security and compliance
FAQs
- Documentation
Volcengine Kubernetes EngineVolcengine Kubernetes EngineBest practicesNetworkingBest practices for observability of custom Nginx Ingress controllers
Copy page
Download PDFNetworking
Best practices for observability of custom Nginx Ingress controllers
Copy pageDownload PDFBest practices for observability of custom Nginx Ingress controllers
The stability of Ingresses, which function as resource objects at the access layer in clusters, affects service quality. This topic describes best practices for monitoring custom Nginx Ingress controllers in clusters.
Background information
VKE allows you to deploy multiple independent Nginx Ingress controllers within a cluster. Each controller operates independently.
- System default ingress-nginx: Deploy the ingress-nginx add-on in the cluster add-on center and follow the on-screen prompts to complete installation. For details, see Installing ingress-nginx.
- Custom ingress-nginx: Use templates to deploy custom ingress-nginx applications in the Application center of VKE. For details, see Deploying multiple Nginx Ingress controllers.
Log collection
By default, the logs of custom Nginx Ingress controllers are not collected or persistently stored. You need to configure and enable log collection to achieve persistent collection, storage, and query of the logs for custom Nginx Ingress controllers.
Prerequisites
- The TLS service of Volcano Engine has been activated.
- A log project and log topic have been created in TLS. For detailed operations, see Log projects and Log topics.
- A custom Nginx Ingress controller has been deployed in the cluster. For details, see Deploying multiple Nginx Ingress controllers.
Configuring log collection
- Log in to the VKE console.
- In the left navigation bar, click Cluster.
- On the Cluster page, click the name of the target cluster.
- In the left navigation bar of the cluster management page, click Log management.
- Click the Log collection rule tab and click Create collection rule. On the page that appears, configure log collection for the custom Nginx Ingress controller.
- Configure the log storage location, including IAM project, Project, and Topic. After you complete the configuration, click Next step: Collection rule.
- Configure the log collection rule.
- ParametersDescriptionsParametersDescriptionsRule nameSpecify the name of the collection rule. The name must be unique in the same cluster.Collection typeSpecify the log collection type. For this example, select K8s container standard output.Collection informationConfigure log collection information. For this example, select Standard output - stdout and Standard error - stderr.K8s collection rulesSelect Enable, and specify the containers that require log collection based on parameters, such as Namespace and Workload name.
- Namespace: Configure the namespace where the custom ingress-nginx is located.
- Workload type: Select Enable, and select Stateless load.
- Workload name: Specify a custom workload name for ingress-nginx.
- Keep the default values for other parameters. After you complete the configuration, click Next step: Check the index configuration.
tip
For more configuration methods and parameter descriptions of container log collection rules, see Collecting container standard output.
- Configure log index checking. In this example, keep the default configurations.
- Click Create collection configuration to complete the configuration.
Viewing logs
- In the left navigation bar of the cluster management page, click Log management.
- Click the Container log tab. Select the target log project and log topic to view the logs of the custom Nginx Ingress controller.
Monitoring and alerting
You can enable the cloud-native observability feature in the cluster to achieve monitoring and alerting for the custom Nginx Ingress controller.
Prerequisites
- VMP has been activated.
- A VMP workspace has been created. For details, see Creating workspaces.
- A custom Nginx Ingress controller has been deployed in the cluster. For details, see Deploying multiple Nginx Ingress controllers.
Configuring metric collection
- Enable cloud-native observability in the cluster. For details, see Enabling cloud-native observability.
- Enable Ingress service observability. For details, see Ingress service observability.
- (Optional) Configure service discovery.
tip
- If your custom Nginx Ingress controller is deployed in the kube-system namespace, you can directly view the metrics and dashboard of the instance without the need to configure service discovery.
- If your custom Nginx Ingress controller is deployed in other namespaces, you need to configure service discovery to view the metrics and dashboard of the instance.
- In the left navigation bar of the cluster management page, click Services and Ingresses > Service. On the page that appears, select the target namespace from the Namespace drop-down list.
- In the service list, select the service named *-ingress-nginx-controller-metrics. * indicates the name that you define. In this example, the service name is nginx-ingress-nginx-controller-metrics.
- In the Actions column, click ... > Update to configure the following annotations for the service to enable service discovery.
- prometheus.io/scrape: "true" # Set the value to true to enable collection.prometheus.io/port: "10254" # The port number where the metrics are exposed.prometheus.io/path: "/metrics" # The URI path where metrics are exposed. It is typically /metrics.
- Click Confirm.
Viewing monitoring data
- In the left navigation bar of the cluster management page, click Monitoring > Dashboard.
- In the left dashboard list, click Network services monitoring > Ingres-nginx monitoring to view the monitoring dashboard.
- From the Namespace drop-down list, select the namespace where the Ingress is located.
- From the IngressClass drop-down list, select the type of Ingress. Supported types include the system default ingress-nginx and custom Nginx Ingress Controller.
- From the Pod drop-down list, specify a pod.
tip
Configuring alerts
VMP allows you to configure resource alerting policies. You can configure alerts in the console by using Ingress service observability. When monitoring data reaches the threshold and triggers an alert, the system sends detailed information, such as the alert resources, fault type, current value, and alert duration, to alert contacts.
VMP supports various alert notification methods, such as email, Feishu, DingTalk, and phone. For detailed configuration methods, see the following topics:
Last updated: 2026.07.23 11:53:56
All rights reserved © Beijing Volcano Engine Technology Co., Ltd2024
