Docs

Volcengine Kubernetes Engine

User guide

Guide to common console operations

When using VKE, you may encounter various issues, such as creating different types of clusters, remotely connecting to clusters, as well as configuring networking or storage, observability, or cluster diagnosis and inspections. This topic mainly describes the common features and operations of VKE. This helps you use VKE clusters in a more secure, reliable, flexible, and efficient manner.

Usage notes

For usage notes and constraints of VKE, see Usage notes and Limits.

For information you need to understand before creating a VKE cluster, see Guide for beginners.

Authorization

Feature	Application scenario	Operation guide
IAM permissions	It controls what VKE resources each account, user group, or role can access and what operations they can perform. This is applicable to scenarios such as assigning console permissions based on personnel responsibilities and isolating operations across different teams, improving account security and permission management efficiency.	Granting IAM permissions
RBAC permissions	Manage resources and operations within the Kubernetes cluster based on users or identities. This is applicable to scenarios that require fine‑grained cluster permission assignment to O&M, development, and test roles, preventing misoperations and enhancing cluster permission management flexibility.	Granting RBAC permissions
IRSA permissions	It allows Pods to securely access cloud resources by using bound service account identities without explicitly storing long‑term keys in applications. This is applicable to workloads that need to access cloud services, such as TOS and FileNAS, reducing key leakage risks and simplifying permission operations.	Using IRSA in clusters

Cluster

Feature	Application scenario	Operation guide
Create clusters	A cluster is a collection of computing, storage, and network resources in VKE. It also functions as the environment for running containerized applications. This is applicable to scenarios where you need to quickly create a business-running foundation based on Kubernetes, and you can select an appropriate creation method based on the infrastructure source (new/existing), computing power type (general-purpose/heterogeneous), and network solution (single-stack/dual-stack).	Creating managed clusters Registering existing clusters Creating a managed heterogeneous computing cluster Creating IPv4/IPv6 dual-stack clusters
Connect to clusters	After a cluster is created, you need to connect the local development environment or CI/CD system to the cluster API Server to deploy, query, and modify Kubernetes resources such as Pods, Deployments, and Services within the cluster.	Connecting to clusters using kubectl Connecting to clusters using custom domain names
Cluster O&M	Cluster O&M is an O&M and management feature that ensures cluster stability, reduces management costs, and achieves fault self-healing. This helps you reduce manual inspection workloads and promptly discover and handle risks in clusters, covering common O&M requirements such as daily control plane maintenance, automatic upgrades of Kubernetes patches and add-ons, and proactive system risk notifications.	Automatic O&M O&M events
Upgrading clusters	When the current Kubernetes version of a cluster is about to reach the end of maintenance, or when you need to use new version capabilities and security patches, you can upgrade the cluster version. Before the upgrade, we recommend completing the upgrade check first to identify compatibility risks in advance.	Upgrading clusters Cluster upgrade checks
Deleting clusters	When a cluster is no longer needed for test environments, temporary environments, or decommissioned businesses, you can delete the cluster and release related resources. Before deletion, confirm that business data, workloads, and dependent resources have been backed up or migrated.	Deleting clusters

Node and node pool

Feature	Application scenario	Operation guide
Creating node pools	When you need to supplement computing resources for a cluster, you can create different node pools based on business types, instance specifications, billing methods, and O&M requirements to uniformly manage nodes of the same type.	Creating managed node pools Creating normal node pools Create spot instance node pools
Scaling out/in node pools	In the face of business traffic fluctuations, periodic tasks, or activity peaks, you can manually adjust the number of nodes or configure scheduled scale-out to ensure resource supply while reasonably controlling costs.	Manually scaling node pools Elastic scheduled scale-out (general-purpose) Elastic scheduled scale-out (Time-period type)
Configure node pool parameters	Uniformly configure Kubelet and Containerd parameters for node pools if workloads have specific requirements for container runtimes, resource management, and node performance. Evaluate the impact on existing nodes and workloads before parameter changes.	Configuring Kubelet parameters for node pools Configuring containerd for node pools
Node management	It enables you to manage, view, maintain, and handle the status of nodes and is an important entry for routine cluster resource management. This is applicable to scenarios such as adding new nodes, identifying abnormal nodes, and checking node status, which can help you maintain cluster node resources more efficiently.	Adding nodes Managing nodes of managed clusters Managing nodes of registered clusters
Node O&M	Manage running policies such as node resource reservation, scheduling density, labels, and taints to ensure nodes stably host workloads. This is applicable to scenarios where you need to optimize node resource allocation, control workload scheduling scope, or improve node running stability, which can enhance cluster resource governance capabilities.	Node resource reservation policies Calculating schedulable Pod density for nodes System labels and taints
Node image	When the default image cannot meet the requirements of the operating system, runtime environment, or software dependencies, you can create a custom image to quickly create nodes with consistent runtime environments.	Creating a custom image based on Docker Creating a custom image based on ECS

Network

Feature	Sub-features	Application scenario	Operation guide
Cluster network	-	It manages network connectivity between the control plane and nodes, secure access, and addresses. You can extend subnets, set security groups, restrict API Server access sources, or adjust access rates based on the cluster size and security requirements.	Expanding cluster subnets Configuring security groups Cluster access rules Access control of API server API Server subnet management Overview of API server rate limiting Access the API server through IPv6
Pod networking	-	When Pods need independent public access, fixed IP addresses, dedicated ENIs, or bandwidth control, you can configure the corresponding pod networking capabilities. You can also use NetworkPolicy to control the access scope between Pods.	Binding dedicated EIP to pods Elastic network interface dedicated to a pod with Trunk ENI Configuring Static IPs for pods Configuring QoS bandwidth limits for pods Configuring IPv6 public bandwidth for pods Using a NetworkPolicy for network access control
Service	ClusterIP	When you only need to access an application within a cluster, you can provide a stable access address for the service via ClusterIP. This prevents service-to-service call relationships from being affected by Pod IP changes.	ClusterIP
		NodePort	Expose services externally via node IP addresses and fixed ports. This is applicable to scenarios such as test verification, integration with existing external traffic entries, or when CLB is not required, which can quickly establish access paths from outside the cluster.	NodePort
		LoadBalancer	LoadBalancer type services expose business externally through CLB and support traffic distribution and high-availability access. This is applicable to scenarios such as web services and API services that require stable public or private network entries, which can reduce access complexity and improve service availability.	Creating CLB services via the console Creating CLB services via kubectl Configuring CLB LoadBalancer Services by using annotations Configuring the IP mode of the CLB service Configuring an NLB Service using annotations
Ingress	APIG Ingress	Performs centralized routing, authentication, and traffic management in clusters via APIG. This is applicable to scenarios where API services are exposed externally and require fine-grained gateway policy management. It improves API management capabilities and release efficiency.	Creating APIG Ingresses in the console Creating APIG Ingresses by using kubectl Configuring APIG Ingresses by using annotations
		ALB Ingress	Implement Layer‑7 traffic forwarding and domain‑based routing based on the ALB service. It is suitable for HTTP/HTTPS services for which traffic needs to be distributed by domain and path. This enables more flexible ingress traffic management and an improved application access experience.	Creating an ALB Ingress through the console Creating an ALB Ingress through kubectl Configuring ALB Ingress using annotation
		CLB Ingress	Expose services within the cluster externally by using the CLB service. This is applicable to scenarios where you already have a CLB system and need to quickly configure Ingress forwarding rules for your business, which can help you access business entries at a low cost.	Creating CLB Ingresses through the console Creating CLB Ingresses through kubectl Configuring CLB Ingress through annotations
Gateway API	-	Manages cluster traffic entries and routing rules in a more standardized and extensible way based on the Gateway API routing standard. This is applicable to scenarios where you need to uniformly manage complex traffic policies and gradually evolve to a new generation of traffic governance systems, which can improve the standardization and scalability of network governance.	Using Gateway API via APIG
DNS	-	Configure and optimize the in-cluster domain query path and DNS access performance. This is applicable to scenarios where services have a large number of DNS resolution requests, and you want to reduce DNS latencies and upstream workloads, which can improve service access stability and optimize cluster network performance.	Using NodeLocal DNSCache as a DNS caching proxy

Storage

A wide range of storage resources in the cloud is available for VKE to meet various storage requirements.

Feature	Application scenario	Operation guide
FSX client	The FSX client is used to access and manage a variety of cloud storage resources within container environments. It also provides authentication, configuration, and version management capabilities. It is applicable to scenarios that require a unified storage access method or where different nodes require custom client configurations.	FSXSet resource introduction FSX client migration Upgrading FSX clients FSX authentication methods Using IRSA to implement authentication for storage mounting Using FSXSet to implement differentiated configurations for clients
DMC	DMC provides unified access and data management capabilities for multiple storage services. This is applicable to scenarios where data processing, analysis, or AI training tasks need to directly access existing data assets within DMC, reducing data copying and migration.	Accessing static DMC PVs by using the FSX client
EBS	EBS provides highly reliable block storage for workloads and supports dynamic creation, capacity expansion, and snapshot backup. This is applicable to databases, middleware, and other stateful applications that have high requirements for persistence and read/write performance.	Using static EBS PVs Using cloud disk dynamic PVs Dynamically expanding EBS data volumes Expanding by using statically provisioned EBS data volumes Cloud disk snapshots
Torch Object Storage (TOS)	TOS provides large-capacity, scalable object storage, which can be mounted to containers through the FSX client. This is suitable for scenarios such as log archiving, media processing, and training data reading that require storage of massive amounts of unstructured data.	Accessing static TOS PVs by using the FSX client Encrypting TOS PersistentVolumes
FileNAS	FileNAS provides standard shared file storage, supporting concurrent access to the same data by multiple Pods. This is applicable to businesses that rely on file system semantics, such as content management, shared configurations, and model file sharing.	Accessing FileNAS static PV through the FSX client Using static FileNAS PVs via NFS Using dynamic FileNAS PVs via NFS
EFS	EFS provides scalable shared file storage without the need to manually plan and adjust underlying storage capacity. This is applicable to scenarios where data volume grows quickly, multiple Pods need to share files, and you want to reduce capacity O&M costs.	Accessing static EFS PV through the FSX client Using static EFS PVs via NFS Using dynamic EFS PVs via NFS
vePFS	vePFS provides high‑throughput, low‑latency, and large-scale parallel access capabilities. This is applicable to AI training, high-performance computing, and massive file processing scenarios with high requirements for storage performance.	Accessing static vePFS PV through the FSX client Using static vePFS PVs Using dynamic vePFS PVs Using vePFS PVs via NFS
CloudFS	CloudFS provides unified file storage and access capabilities for big data workloads. This is applicable to scenarios where offline computing, batch processing, and big data analysis require access to large-scale datasets.	Using static CloudFS PVs
Local volumes	Local storage volumes use node local disks to provide high-performance data read/write capabilities for workloads. This is applicable to businesses that are sensitive to latency and throughput and can accept data binding to nodes.	Using dynamic PersistentVolumes created from LVM-managed local storage Using dynamic PersistentVolumes created from dedicated local storage Using LVM-managed local volumes as ephemeral volumes

Autoscaling

Feature	Application scenario	Operation guide
Cluster Autoscaler	It can automatically or quickly supplement underlying computing power based on cluster resource requirements. This is applicable to scenarios where business loads significantly fluctuate and resource requirements are difficult to accurately estimate in advance, which can reduce manual scale-out operations and improve resource supply efficiency.	Node autoscaling (Cluster Autoscaler) Instant node elasticity (Karpenter)
Workload autoscaling	Automatically adjust the number of replicas based on metrics, scheduled policies, intelligent predictions, or event changes. This is applicable to scenarios where business request volume fluctuates periodically, traffic spikes exist, or asynchronous task volumes change, which can improve application elasticity while controlling costs.	HPA CronHPA Intelligent Horizontal Pod Autoscaler (IHPA) Event-driven autoscaling (KEDA)

Heterogeneous computing

Feature	Application scenario	Operation guide
NVIDIA GPU scheduling	Allocate GPU resources to container workloads on demand. This is applicable to scenarios such as AI training, model inference, and graphics rendering that require GPU computing power, which can improve heterogeneous resource utilization and ensure smooth task execution.	Configuring NVIDIA GPU scheduling Implementing NVIDIA GPU scheduling based on DRA
mGPU scheduling	You can split and share a single GPU for more fine‑grained computing power allocation. This is applicable to inference, small‑scale training, or multi‑tenant GPU sharing, improving GPU utilization and reducing computing power waste.	Configuring mGPU scheduling Allocating mGPU computing power Implementing multi-card sharing based on mGPUs Implementing online-offline hybrid deployment based on mGPUs
RDMA for high-performance computing	It provides low-latency and high-throughput network communications for container workloads. This is applicable to large‑model training, distributed computing, and HPC clusters, and can significantly improve the collaborative computing efficiency across multiple nodes.	Using RDMA resources (RoCE) in clusters Using RDMA resources (InfiniBand) in clusters

Scheduling

Feature	Application scenario	Operation guide
Job scheduling	Arrange task execution order and admission methods based on job characteristics and resource constraints. This is applicable to scenarios where multiple tasks such as batch processing, AI training, and quota control compete for resources, which can improve resource allocation efficiency and reduce task contention.	Gang scheduling Job admission and scheduling based on Kueue Capacity scheduling
ResourcePolicy scheduling	It preferentially ensures core business stability when resources are insufficient or when resources are in mixed use. This is applicable to scenarios where critical and non-critical tasks run together, ensuring core business runs stably with priority.	ResourcePolicy scheduling
Load-aware scheduling	It can optimize workload distribution based on real‑time node load. This is applicable to scenarios with uneven cluster resource utilization or obvious hotspot nodes, improving resource balance and overall operational stability.	Load-aware scheduling
Topology-aware scheduling	Make more precise scheduling decisions by combining hardware topology information such as NUMA and RDMA. This is applicable to scenarios such as high-performance computing, low-latency businesses, or those with high hardware affinity requirements, which can improve task execution performance.	NUMA-aware scheduling RDMA topology-aware scheduling

Observability

Feature	Application scenario	Operation guide
Log management	Collect and view container and control plane add-on logs in a centralized manner. This is applicable to scenarios such as application troubleshooting, running status tracking, and audit trails, which can help you quickly locate exceptions and improve O&M efficiency.	Collecting container logs Collecting control plane add-on logs
Event management	View and handle running events generated by resources in the cluster, and event persistence is supported. This is applicable to scenarios such as resource troubleshooting and tracking of object status change causes, which can improve fault discovery and issue backtracking efficiency.	Querying and handling events Configuring and viewing persistent events
Basic observability	View the basic running status of clusters based on multiple dimensions, including the container, control plane, network, and storage. This is applicable to scenarios such as routine inspection, capacity observation, and exception localization. This helps you quickly identify issue trends and enhances visual O&M capabilities.	VKE observability Control plane observability DNS service observability CNI network observability Image acceleration observability AI resource observability Image repository observability CSI storage observability Container storage observability Check and self-healing observability
Full-stack observability	Connect information about resources, topologies, and network connections to form a more complete issue analysis view. This is applicable to scenarios such as complex troubleshooting, cross-add-on localization, and global trace analysis, which can shorten the troubleshooting path and improve diagnostic efficiency.	Enabling full-stack observability Resource retrieval Cluster topologies Capturing network packets
Application performance observability	It analyzes application‑level requests, performance metrics, and running status. This helps you quickly identify performance bottlenecks and optimize application quality for a better service experience, higher API performance, and greater business stability.	Application performance observability

Diagnosis and inspection

Feature	Application scenario	Operation guide
Diagnosis	Perform issue localization and root cause analysis for objects such as node pools, nodes, and pods. This is applicable to quick troubleshooting scenarios when resources are abnormal, instances are unavailable, or businesses do not run as expected, which can help you shorten fault localization time.	Node pool diagnosis Node diagnosis Pod diagnosis
Check and self-healing	It allows automatic checks of node health status and repair when conditions are met. This is applicable to scenarios where you want to reduce manual intervention and promptly resolve common node exceptions, which can improve cluster autonomy and business continuity.	Node check and self-healing Custom node check items
Risk inspection	Regularly discover potential risks at the cluster configuration, baseline, and application levels. This is applicable to scenarios such as pre-release self-checks, routine health checks, or security governance, which can help you expose risks in advance and reduce the probability of failures.	Cluster inspection Baseline inspection Application inspection

Last updated: 2026.07.15 17:33:42