Intelligent Computing LINGJUN:Personalizar componentes de código aberto

1. Obter o código-fonte

O código-fonte dos componentes de código aberto está publicado no repositório do GitHub aliyun/LJ-RuntimeKit. Cada componente fica em seu próprio subdiretório:

Convenções de branches e tags:

• A branch main sempre contém o código utilizável mais recente.

• Tags marcam versões estáveis. Cada versão de componente de código aberto acompanha a versão correspondente do Runtime.

2. Compilar e criar imagens

Compile cada componente a partir da raiz do diretório de código-fonte usando o Makefile:

make build     # Compile the binary
make docker    # Build the image

Para outros targets de compilação, consulte o Makefile no diretório de cada componente. Após a conclusão da compilação, envie as imagens para um registry do qual os nós do cluster possam fazer pull. Certifique-se de que os nomes e tags das imagens nos manifestos de implantação correspondam aos artefatos de compilação reais (para detalhes sobre arquivos de implantação e configuração de imagens, consulte 3.6 Implantação avançada e personalização).

# 1. Switch dependencies to the target Kubernetes version (for example, v1.28.0)
./hack/download-deps.sh v1.28.0

# 2. Update the vendor directory
go mod tidy && go mod vendor

# 3. Verify the build
make build

3. Implantar componentes personalizados

Implante componentes personalizados da mesma forma que os componentes pré-compilados:

1. Implantação com um clique: o repositório do Scheduler Framework fornece o script deploy/deploy-all.sh para implantar todos os componentes ou componentes individuais (--components=<name>). Ele também permite sobrescrever parâmetros como o endereço da imagem e o namespace.

2. Implantação por componente: cada componente também oferece seus próprios métodos de implantação, como make deploy, Helm charts e kustomize.

3. Compatibilidade de versões: componentes personalizados ainda se integram ao Runtime por meio da interface gRPC, e a política de compatibilidade de versões e os requisitos de versão mínima se aplicam da mesma forma. Para detalhes, consulte 5. Compatibilidade de versões e 6. Requisitos de versão mínima para recursos.

4. Personalização no nível de configuração (sem necessidade de recompilação): os manifestos de implantação do Device Plugin, do Scheduler Framework e do Exporter contêm, cada um, um arquivo configmap.yaml separado. Esse arquivo externaliza constantes de protocolo, como nomes de recursos estendidos, chaves de labels de nós e chaves de annotations, em um ConfigMap. Para alterar apenas configurações como nomes de recursos sem mexer no código, edite o ConfigMap correspondente e faça a reimplantação. Não é necessário recompilar as imagens. Observação: os três componentes compartilham o mesmo conjunto de constantes de protocolo. Se as configurações estiverem inconsistentes, os componentes usarão nomes de recursos divergentes para relatórios de recursos, agendamento e monitoramento. Os Pods podem falhar no agendamento ou os dados de monitoramento podem ficar incompletos. O exemplo a seguir altera os nomes de recursos gpu-core e gpu-memory:

     protocol.yaml: 
       resources.memory: "alibabacloud.com/gpu-memory.percentage"
       resources.core: "alibabacloud.com/gpu-core.percentage"
       resources.gpu: "alibabacloud.com/gpu"

   Essas configurações ficam nos arquivos ConfigMap de cada componente, dentro do diretório deploy da implantação com um clique do Scheduler Framework — deploy/<component>/02-configmap.yaml. Após a edição, execute kubectl apply -f para os três componentes atualizarem seus ConfigMaps e, em seguida, reinicie os DaemonSets e o Deployment correspondentes para aplicar a nova configuração:

   # 1. Update the ConfigMaps of the three components
   kubectl apply -f deploy/deviceplugin/02-configmap.yaml
   kubectl apply -f deploy/exporter/02-configmap.yaml
   kubectl apply -f deploy/scheduler/02-configmap.yaml
   
   # 2. Restart the components to apply the new configuration
   kubectl rollout restart ds/lj-runtimekit-device-plugin-ds -n kube-system
   kubectl rollout restart ds/lj-runtimekit-exporter-ds -n kube-system
   kubectl rollout restart deploy/lj-runtimekit-scheduler-framework -n kube-system

   Alternativamente, reimplante todos os componentes de uma vez com deploy-all.sh deploy para obter o mesmo resultado.

Componentes personalizados são mantidos por você. Ao atualizar para uma nova baseline, integre suas alterações personalizadas na nova versão.

4. Estrutura do código-fonte e pontos de extensão dos componentes

Controller/
├── cmd/
│   ├── controller/main.go       # Controller main program (Kubebuilder framework)
│   └── job-agent/main.go        # Job Agent (executes enable/disable on nodes)
├── internal/controller/
│   ├── node_controller.go       # Watches Node label changes and creates Jobs
│   └── job_controller.go        # Automatically cleans up successful Jobs
├── api/proto/
│   └── config_service.proto     # gRPC interface definitions
├── pkg/configpb/                # Generated Go gRPC code
└── config/manager/              # Deployment configuration

5. Limites de personalização e considerações

1. A interface gRPC é o único limite de integração. Desde que você não altere as partes que interagem com o Lingjun Runtime Kit, não precisa lidar com detalhes de proto. Sua personalização fica dentro das políticas do próprio componente, como agendamento, monitoramento, orquestração e armazenamento. Se precisar modificar ou reimplementar a interação com o Runtime, use Referência da API gRPC como base de protocolo e siga sua política de compatibilidade.

2. Consistência de nomes de recursos: ao personalizar um prefixo de nome de recurso, atualize os componentes Device Plugin, Scheduler Framework e Exporter ao mesmo tempo. Caso contrário, os relatórios de recursos e o agendamento não corresponderão. Para alterações simples que afetam apenas a configuração, edite o ConfigMap de protocolo no manifesto de implantação de cada componente para atualizar os três componentes de uma vez (consulte a seção 3). Não é necessário recompilar. Se a alteração envolver lógica de código, modifique as definições de constantes no código-fonte e recompile as imagens.

3. A compatibilidade de versões também se aplica: componentes personalizados e o Runtime continuam seguindo a política de interface "aditiva e compatível com versões anteriores", e os requisitos de versão mínima para recursos também se aplicam a implementações personalizadas (para detalhes, consulte 5. Compatibilidade de versões e 6. Requisitos de versão mínima para recursos).

4. Responsabilidade de manutenção: você é responsável por manter os componentes personalizados. Quando uma nova baseline for lançada, integre suas alterações personalizadas na nova versão. Para detalhes sobre responsabilidade por problemas e canais de suporte, consulte Guia de implantação e lançamento.