Basic Concept
Virtual Kubernetes Services (VKS ) is an elastic GPU container cluster service that provides virtualized Kubernetes clusters. Before getting started with VKS, users may need to familiarize themselves with several core concepts. This document introduces the fundamental terminology used in VKS to help users operate the service more effectively.
Cluster
A Kubernetes cluster consists of a set of physical or virtual machines, referred to as nodes. Clusters include two types of nodes: Master Nodes and Worker Nodes. Master Nodes handle cluster-wide management and scheduling, while Worker Nodes run the actual application containers.
Administrator Account
The account used during an enterprise’s initial registration is automatically designated as the administrator account. Each enterprise can have only one Administrator Account. This account holds the highest level of administrative privileges and can perform, but is not limited to, the following operations:
- Assign cluster access permissions to other accounts within the enterprise.
- Manage member roles and permission configurations.
- View and update the enterprise’s basic information.
- Manage enterprise-related resources and service settings.
Parallelism Limit
For an enterprise, the parallelism limit represents the maximum number of GPUs that the enterprise is allowed to provision. For an individual Virtual Kubernetes cluster, it represents the maximum number of a specific type of GPU that a user can utilize within that cluster.
Node
A node is an individual machine (either a physical server or a virtual machine) within a Kubernetes cluster. Each node runs the essential services required to operate Pods and to communicate with the control plane. Key components running on a node include the kubelet,kube-proxy, and a container runtime engine (such as Docker).
Container
A container is a technology that packages an application together with all its runtime dependencies. It is the fundamental execution unit for running applications. A node can run multiple containers, typically grouped within a single Pod.
Pod
A Pod is the smallest deployable unit in a Kubernetes cluster and can contain one or more tightly coupled containers. A Pod represents a running process on the cluster; all containers within the Pod share the same network namespace, IP address, and volumes.
- The following command can be used to check the status of Pods within a specific namespace.
kubectl.exe get pod -n [deepseek]
- The following command can be used to access the corresponding Pod.
kubectl exec -it [prepare-deploy-74f545496-9bl62] -n [deepseek] -- bash
ReplicaSet
A ReplicaSet ensures that a specified number of Pod replicas are running at all times. If any Pod fails, the ReplicaSet automatically creates a new one to replace it. ReplicaSets are primarily used to maintain high availability and reliability of applications.
Workload
| Type | Description |
|---|---|
| Deployment | A Deployment is one of the most important resource types in Kubernetes and is particularly suitable for managing application services that do not require persistent storage. It enables operators to deploy, maintain, and upgrade applications more efficiently. |
| StatefulSet | A StatefulSet provides a reliable mechanism for managing applications that require state persistence, ensuring that such applications can run stably and consistently within a Kubernetes cluster. |
| DaemonSet | A DaemonSet ensures that a Pod runs on every node (or on a specified subset of nodes). Unlike a Deployment, it deploys Pods across all eligible nodes. It is commonly used for cluster-wide log collection, monitoring, and similar system-level workloads. |
| Job | A Kubernetes Job allows users to run one-time tasks, with the option to launch multiple Pods in parallel to accelerate processing. |
| CustomResourceDefinitions (CRD) | CRDs allow users to extend Kubernetes by adding third-party workload resource types. With a CRD, you can define your own custom resources. |
Service
A Service is an abstraction that defines a logical group of Pods along with the policy used to access them. A Service provides a stable IP address and DNS name, enabling other services to discover and access these Pods reliably. Common Service types include ClusterIP (accessible only within the cluster), NodePort (exposes a port on each node for external access), and LoadBalancer (provisions a cloud provider load balancer).
Namespace
A Namespace provides a mechanism for logically partitioning resources within the same physical cluster. It helps organize objects and isolate them across different projects or teams. By default, Kubernetes includes three namespaces:default,kube-system（used by system components）and kube-public (used for publicly readable information).
The following command demonstrates how to create a Namespace using VKS clusters.
kubectl create namespace [deepseek]
ConfigMap
A ConfigMap is used to store configuration data that can be injected into containers as environment variables, command-line arguments, or configuration files.
Secret
A Secret is specifically designed for storing sensitive information, such as passwords or OAuth tokens, and is encrypted by default. The following command shows how to create a Secret using VKS clusters.
kubectl apply -f [deepseek-secret.yaml]
Volume
A Volume is a form of persistent storage that allows data to persist across Pod restarts without being lost. Kubernetes supports multiple Volume types, including local storage, network-based storage (such as NFS and iSCSI), and cloud storage (such as AWS EBS and GCE PD).
Ingress
An Ingress is an API object used to manage HTTP(S) routing rules for accessing Services inside a cluster. It is typically used to provide features such as domain-based routing and SSL termination.
Service Export
In a VKS cluster, when a Service cannot be exposed directly via the NodePort type, services that require external access can be exposed using ServiceExporter. A ServiceExporter is a component within the VKS that binds to the Service requiring external access and provides an externally reachable endpoint for users.
- The following command shows how to create a ServiceExport resource.
kubectl apply -f [ray-svcExporter-chat.yaml] - After the resource is successfully created, the command below can be used to view the ServiceExporter information.
kubectl describe serviceExporter [ray-svc-chat-exporter] -n [deepseek]
When using the commands above, replace the parameters enclosed in "[ ]" with the actual resource values.