sobre nosotros
Para más casos y conocimientos sobre la nube nativa, puede prestar atención a la cuenta pública del mismo nombre [Tencent Cloud Native]~
Bienestar:
① Responda al [Manual] en el fondo de la cuenta oficial, puede obtener el "Manual de hoja de ruta nativa de Tencent Cloud" y las "Prácticas recomendadas nativas de Tencent Cloud" ~
②La cuenta oficial responderá a [series] en segundo plano, y puede obtener "15 series de más de 100 colecciones de productos secos originales nativas en la nube súper prácticas", incluida la reducción de costos y la mejora de la eficiencia de Kubernetes, las prácticas de optimización del rendimiento de K8, las mejores prácticas y otros serie.
③Si responde al [Informe técnico] en el fondo de la cuenta oficial, puede obtener el "Informe técnico de Tencent Cloud Container Security" y "La fuente de la reducción de costos: Informe técnico de gestión de costos nativos en la nube v1.0"
④ Responda a [Introducción a la velocidad de la luz] en el fondo de la cuenta oficial, puede obtener un tutorial de esencia de 50,000 palabras de los expertos de Tencent Cloud, Prometheus y Grafana de la velocidad de la luz.
autor
Xu Bei, experto en tecnología de contenedores en la nube de Tencent, líder de contenedores de computación heterogénea en la nube de Tencent, muchos años de diseño de arquitectura de primera línea de computación en la nube y experiencia en I + D, Kubernetes profundo a largo plazo, en el campo de la ubicación conjunta sin conexión y la contenedorización de GPU, Kubernetes KEP Autor de QoS de memoria, colaborador activo de Kubernetes.
Actualmente hay un problema
Con una gran cantidad de núcleos y memoria de alta velocidad, las GPU son buenas para la computación paralela y son ideales para entrenar y ejecutar modelos de aprendizaje automático. A medida que la tecnología de IA se ha vuelto más y más madura en los últimos años, hay más y más escenarios de aterrizaje y la demanda de GPU muestra una tendencia arrolladora. En la plataforma de programación de gestión de recursos, Kubernetes se ha convertido en el estándar de facto. Por lo tanto, muchos clientes eligen usar GPU para ejecutar tareas informáticas de IA en Kubernetes.
Kubernetes proporciona un mecanismo de complemento de dispositivo que permite que los nodos descubran e informen los recursos del dispositivo para que los usen los pods. Los recursos de GPU también se proporcionan de esta manera. Tomando GPU nvidia como ejemplo, el usuario implementa el complemento de dispositivo nvidia en el nodo de Kubernetes, el complemento escanea la tarjeta GPU del nodo y nvidia.com/gpu: 8registra los recursos GPU en el nodo de una forma similar a través del mecanismo de recursos extendidos. El usuario especifica el nombre del recurso al crear un Pod. Después de que el programador lo programe, el Pod se vincula al nodo y, finalmente, el dispositivo GPU requerido se monta en el contenedor a través de una serie de herramientas proporcionadas por nvidia docker.
El complemento de dispositivo de Kubernetes proporciona una manera conveniente de integrar dispositivos de terceros. Sin embargo, cuando se aplica a escenarios de GPU, todavía existen las siguientes deficiencias:
-
Los recursos de GPU de clúster carecen de una perspectiva global . No existe una forma intuitiva de obtener información de la GPU a nivel de clúster, como la relación vinculante entre el pod/contenedor y la tarjeta GPU, la cantidad de tarjetas GPU usadas, etc.
-
Los backends multi-GPU no son bien compatibles . Varias tecnologías de GPU (nvidia docker, qGPU, vCUDA, gpu share, GPU pooling) necesitan implementar componentes de forma independiente y no se pueden programar ni administrar de manera uniforme
Problema 1: falta de perspectiva global de los recursos de GPU
La asignación y programación de recursos de GPU de Kubernetes existentes se logra a través de recursos extendidos, que se basan en la suma o resta de la cantidad de tarjetas en el nodo. Si los usuarios desean conocer la asignación de tarjetas GPU en el clúster, deben atravesar los nodos para obtener y calcular la información. Y debido a que este recurso es escalar, no es posible obtener la relación vinculante entre el Pod/contenedor y la tarjeta. Estos problemas no son tan prominentes en el modo de tarjeta completa, pero son especialmente serios en el modo de uso compartido detallado.
Dado que las tarjetas GPU son relativamente caras y algunas cargas de IA no pueden consumir la potencia informática de una sola GPU, surgió la tecnología GPU Sharing. En Kubernetes, compartiremos algunas cargas de trabajo de IA en la misma tarjeta GPU para ahorrar costos al aumentar la densidad de implementación comercial y mejorar la utilización de la GPU. Tomando TKE qGPU como ejemplo, en el modo GPU Sharing, los recursos de expansión cambian de la cantidad de tarjetas GPU al porcentaje de qGPU Core y MB de memoria qGPU. En otras palabras, los usuarios pueden solicitar un dispositivo virtual qGPU más pequeño que una tarjeta a través de la tecnología de virtualización de contenedores qGPU. Estos dispositivos están virtualizados en una sola tarjeta física y los recursos también están fuertemente aislados. Además de qGPU, tecnologías como vCUDA y gpu share admiten múltiples pods/contenedores que comparten la misma tarjeta GPU. Según la arquitectura de Kubernetes existente, es imposible conocer la distribución de los recursos de segmento (que defino como la combinación de núcleo de GPU y memoria) contenidos en la tarjeta de GPU. La distribución de recursos del clúster es una caja negra tanto para los administradores como para los usuarios. Los administradores no pueden conocer la asignación de recursos de segmento de GPU en todo el clúster y los usuarios no saben si los recursos están disponibles para los servicios recién implementados.
Problema 2: no se puede admitir backend multi-GPU
Además del método de asignación y montaje de toda la tarjeta, los usuarios adoptan cada vez más tecnologías de uso compartido de GPU como TKE qGPU, vCUDA, uso compartido de GPU y agrupación de GPU. Cada solución tiene su propio conjunto independiente de implementaciones de integración de Kubernetes. Por ejemplo, en TKE qGPU, tenemos un tke-qgpu-scheduler de desarrollo propio para la programación de asignación de memoria de video y potencia informática de grano fino de GPU, y el tke-qgpu-manager de soporte se usa para la inicialización de nodos, el registro y la generación de informes de recursos de qGPU. y virtualización de contenedores qGPU. vCUDA y gpu share también son arquitecturas similares, que también se componen de programador + complemento de dispositivo. Estos programas son independientes entre sí, no existe un estándar unificado y no se pueden compartir. Esto dificulta que los usuarios utilicen varias tecnologías de back-end de GPU simultáneamente en un solo clúster. Por ejemplo, algunas empresas en el grupo de usuarios están razonando en línea, no están satisfechas con toda la tarjeta y desean solicitar recursos de segmento TKE qGPU. Otra parte del negocio es la formación, que requiere la asignación de una única tarjeta. Algunos servicios de simulación y depuración de modelos desean solicitar recursos de manera dinámica desde el grupo de GPU remoto por costo y flexibilidad. Es difícil que las soluciones existentes cumplan con los requisitos anteriores al mismo tiempo, lo que dificulta aún más la creación de una plataforma de infraestructura de IA unificada basada en Kubernetes.
Los problemas anteriores son los problemas reales que encuentra TKE cuando ayuda a los clientes a crear plataformas informáticas de IA basadas en Kubernetes. Con la mejora continua del negocio de IA, los clientes ya no están satisfechos con "poder usar los recursos de GPU de Kubernetes". La atención al costo de GPU, el control general de los recursos de GPU y el uso preciso de diferentes backends de GPU se han convertido en requisitos previos para que los clientes hagan un buen uso de la potencia informática de GPU. Dado que el sistema existente no se puede satisfacer, debemos encontrar otra forma y repensar la posición de la GPU en Kubernetes.
Una nueva solución de GPU de Kubernetes
Inspiración de PV / PVC
En Kubernetes, los recursos generalmente se diseñan y definen en torno a Pods. En gran medida, hay dos tipos de recursos disponibles para un clúster: recursos básicos y recursos externos. Los recursos básicos se refieren a los recursos indispensables para mantener el funcionamiento normal del Pod, incluidos la CPU, la memoria, el almacenamiento temporal, la tarjeta de red, etc. Estos se escanean en busca de nodos a través del kubelet y se informan al clúster. La otra parte son los recursos externos, que se refieren principalmente al almacenamiento externo y otros dispositivos, como discos de datos, GPU, FPGA, etc. Estos dispositivos pueden ser montajes de dispositivos locales o montajes de dispositivos remotos. La existencia de dichos recursos puede hacer que el Pod funcione mejor. Por ejemplo, el disco de datos aumenta la capacidad de almacenamiento del Pod y la GPU/FPGA acelera la potencia informática del Pod. Desde esta perspectiva, el almacenamiento es similar a la GPU.
Kubernetes abstrae un conjunto de recursos de almacenamiento, como PV/PVC/StorageClass, y proporciona un conjunto de API y métodos de interacción para estandarizar y separar la administración y el uso del suministro de almacenamiento.
- PV : PV es un recurso de almacenamiento real en el clúster, que el administrador puede crear manualmente o crear dinámicamente a través de StorageClass. PV es similar a la CPU, la memoria, la tarjeta de red y otros recursos en el nodo. PV puede tener varios backends, como el servicio de almacenamiento en la nube pública descrito anteriormente, el almacenamiento compartido autoconstruido o el almacenamiento local.
- PVC : PVC es la reclamación de un usuario de recursos de almacenamiento fotovoltaico. Es similar a un Pod en un clúster. Pod aplica para CPU, memoria, red y otros recursos en el nodo, y PVC aplica para recursos de almacenamiento, es decir, PV.
- StorageClass : StorageClass proporciona a los administradores una forma de describir una "clase" de almacenamiento. Por ejemplo, el método creado por el backend PV, el método de montaje, etc.
El usuario crea el almacenamiento real en el backend especificado a través del PV, y el usuario solicita el recurso de almacenamiento de PV creado a través del PVC, o especifica StorageClass para crear dinámicamente el PV desde el backend.
En referencia a la forma en que se diseña el almacenamiento de Kubernetes, creemos que las GPU también pueden definir e implementar abstracciones similares.
GPU elástico CRD
Definimos tres nuevos CRD de Kubernetes que representan diferentes abstracciones para los recursos de GPU:
- ElasticGPU : ElasticGPU es un recurso de GPU realmente utilizable en el clúster, que puede ser una tarjeta física de GPU local, un recurso de segmento de GPU (una combinación de potencia informática de GPU y memoria de video) y un dispositivo de GPU remoto.
- ElasticGPUClaim : ElasticGPUClaim es una aplicación de usuario para los recursos de ElasticGPU. Puede solicitar la cantidad de tarjetas completas, solicitar la cantidad de núcleos de GPU/memoria de video o solicitar potencia informática TFLOPS.
- EGPUClass : EGPUClass proporciona una forma de producir y montar ElasticGPU, que puede usar virtualización qGPU, vCUDA o tecnología de agrupación remota de GPU.
type ElasticGPU struct {
metav1.TypeMeta `json:",inline"`
metav1.ObjectMeta `json:"metadata,omitempty" protobuf:"bytes,1,opt,name=metadata"`
Spec ElasticGPUSpec `json:"spec,omitempty" protobuf:"bytes,2,opt,name=spec"`
Status ElasticGPUStatus `json:"status,omitempty" protobuf:"bytes,3,opt,name=status"`
}
type ElasticGPUSpec struct {
Capacity v1.ResourceList `json:"capacity,omitempty" protobuf:"bytes,1,rep,name=capacity,casttype=ResourceList,castkey=ResourceName"`
ElasticGPUSource `json:",inline" protobuf:"bytes,2,opt,name=elasticGPUSource"`
ClaimRef v1.ObjectReference `json:"claimRef,omitempty" protobuf:"bytes,3,opt,name=claimRef"`
NodeAffinity GPUNodeAffinity `json:"nodeAffinity,omitempty" protobuf:"bytes,4,opt,name=nodeAffinity"`
NodeName string `json:"nodeName,omitempty" protobuf:"bytes,5,opt,name=nodeName"`
}
type ElasticGPUSource struct {
QGPU *QGPUElasticGPUSource `json:"qGPU,omitempty" protobuf:"bytes,1,opt,name=qGPU"`
PhysicalGPU *PhysicalGPUElasticGPUSource `json:"physicalGPU,omitempty" protobuf:"bytes,2,opt,name=physicalGPU"`
GPUShare *GPUShareElasticGPUSource `json:"gpuShare,omitempty" protobuf:"bytes,3,opt,name=gpuShare"`
}
type ElasticGPUClaim struct {
metav1.TypeMeta `json:",inline"`
metav1.ObjectMeta `json:"metadata,omitempty" protobuf:"bytes,1,opt,name=metadata"`
Spec ElasticGPUClaimSpec `json:"spec,omitempty" protobuf:"bytes,2,opt,name=spec"`
Status ElasticGPUClaimStatus `json:"status,omitempty" protobuf:"bytes,3,opt,name=status"`
}
type ElasticGPUClass struct {
metav1.TypeMeta `json:",inline"`
metav1.ObjectMeta `json:"metadata,omitempty" protobuf:"bytes,1,opt,name=metadata"`
Provisioner string `json:"provisioner" protobuf:"bytes,2,opt,name=provisioner"`
Parameters map[string]string `json:"parameters,omitempty" protobuf:"bytes,3,rep,name=parameters"`
}
A continuación, se toma TKE qGPU como ejemplo para describir todo el proceso de programación y asignación de recursos combinado con la solución de GPU elástica.
aplicación de recursos qGPU
El usuario crea una ElasticGPUClass en el clúster y especifica qGPU como backend de GPU.
apiVersion: elasticgpu.io/v1alpha
kind: ElasticGPUClass
metadata:
name: qgpu-class
provisioner: elasticgpu.io/qgpu
reclaimPolicy: Retain
eGPUBindingMode: Immediate
Cree ElasticGPUClaim para describir la solicitud de recursos de qGPU, lo que significa solicitar tke.cloud.tencent.com/qgpu-coreel 10 % de la potencia informática de GPU y significa tke.cloud.tencent.com/qgpu-memorysolicitar 4 GB de memoria de video.
apiVersion: elasticgpu.io/v1alpha
kind: ElasticGPUClaim
metadata:
name: qgpu-egpuc
spec:
storageClassName: qgpu-class
resources:
requests:
tke.cloud.tencent.com/qgpu-core: 10
tke.cloud.tencent.com/qgpu-memory: 4GB
El usuario especifica ElasticGPUClaim para completar la aplicación de recursos qGPU al crear un Pod.
apiVersion: v1
kind: Pod
metadata:
name: qgpu-pod
annotations:
elasticgpu.io/egpuc-<container-name>: qgpu-egpuc
spec:
containers:
- name: test
programación de recursos qGPU
Teniendo en cuenta el diseño de out-tree, el descubrimiento de recursos de qGPU, los informes y la programación aún se basan en el complemento del dispositivo original y el mecanismo de recursos extendidos.
Usamos elastic-gpu-admission-hook para identificar anotaciones cuando se crea Pod elasticgpu.io/egpuc-<container-name>y configurar correctamente los recursos de la aplicación en los contenedores.
apiVersion: v1
kind: Pod
metadata:
name: qgpu-pod
annotations:
elasticgpu.io/egpuc-test: qgpu-egpuc
spec:
containers:
- name: test
resources:
requests:
tke.cloud.tencent.com/qgpu-core: 10
tke.cloud.tencent.com/qgpu-memory: 4GB
limits:
tke.cloud.tencent.com/qgpu-core: 10
tke.cloud.tencent.com/qgpu-memory: 4GB
El planificador de extensión qgpu-scheduler se utiliza para la programación de recursos de qGPU y devuelve nodos que cumplen los requisitos. Después de vincular el Pod al nodo, qgpu-provisioner actualizará ElasticGPUla información, como el nodo y el índice de la tarjeta GPU en el CRD, para realizar la vinculación del dispositivo qGPU.
creación de recursos qGPU
qgpu-manager observará ElastciGPUlos cambios de CRD y, una vez que el nodo se haya enlazado correctamente, realizará la operación de creación de un dispositivo qGPU. qgpu-manager creará un dispositivo qGPU en la capa inferior de acuerdo con la potencia informática de la aplicación y la información de la memoria de video contenida en el CRD y el índice de la tarjeta GPU que se enviará.
Montaje de dispositivo qGPU
qgpu-manager es un complemento de dispositivo, y kubelet llamará al complemento a través de la interfaz estándar al asignar un dispositivo. En interfaces Allocatey PreStartContainer, montaremos la qGPU necesaria, los dispositivos nvidia y estableceremos las variables de entorno. Finalmente, confiamos en qgpu-container-runtime para vincular dispositivos qGPU a contenedores.
próximo paso
Con la implementación a gran escala de los servicios de IA, cada vez más usuarios utilizan GPU para la informática de IA en Kubernetes. Es difícil que los mecanismos de complemento de dispositivos y recursos extendidos existentes satisfagan el control fino y la asignación de recursos de GPU de los clientes, y es imperativo un nuevo marco técnico. Elastic GPU abstrae un recurso de GPU nativo en un clúster de Kubernetes. Se centra en tres CRD personalizados. Con la premisa de estandarizar y definir la interacción con otras tecnologías de GPU, también proporciona una perspectiva de recursos de GPU global a nivel de clúster, lo que permite a los usuarios observar y administrar los recursos de la GPU.
El primer paso de Elastic GPU se centrará en la definición de CRD y la estandarización del proceso de interacción, y primero se adaptará a TKE qGPU. En esta etapa, esperamos referirnos al concepto de diseño de PV/PVC/CSI, proporcionar la abstracción de recursos de GPU de forma nativa de Kubernetes, estandarizar los procesos de asignación de recursos, programación, montaje, etc., y proporcionar interfaces flexibles para integración con otras tecnologías de GPU. Al admitir TKE qGPU primero en producción, continuaremos puliendo el marco y lanzando la primera versión alfa. A continuación, presionaremos a la comunidad para que implemente soporte integrado para las principales tecnologías de GPU, incluidos nvidia docker, gpu share y vCUDA, los escenarios aplicables del marco de escalado horizontal. A través de un marco estándar, interfaces y procesos unificados, reduzca los costos de gestión de clientes. Mejore la flexibilidad, aumente la utilización y reduzca los costos de las tarjetas de los clientes a través de tecnologías como GPU compartida y GPU remota. Esperamos confiar en el marco de trabajo de GPU elástico para finalmente brindar a los clientes la capacidad de usar recursos de GPU listos para usar en Kubernetes.
TKE qGPU: https://cloud.tencent.com/document/product/457/61448
[Tencent Cloud Native] Nuevos productos de Yunshuo, nuevas técnicas de Yunyan, nuevas actividades de Yunyou e información sobre la apreciación de la nube, escanee el código para seguir la cuenta pública del mismo nombre y obtenga más productos secos a tiempo. !
