O que é o caminho certo para liberar recursos Kubernetes para um trabalho Kubernetes que não consegue puxar a imagem?

votos
0

Contexto

Há muito tempo executar trabalhos Kubernetes baseado em contentores Docker. Os recipientes precisa de recursos (por exemplo, memória de 15 GB, 2 cpu) e usamos Autoscaler para escalar novos nós de trabalho a pedido.

Cenário

Os usuários podem selecionar a versão da imagem janela de encaixe para ser usado por um emprego, por exemplo, 1.0.0, 1.1.0, ou até mesmo uma confirmação de hash do código a imagem foi construída a partir de ambiente de teste.

Como deixamos a tag janela de encaixe para ser freetext, o usuário pode digitar um tag janela de encaixe não-existente. Por isso, o pod trabalho vem em estado ImagePullBackOff. O pod permanece neste estado e mantém os recursos bloqueados de modo que não podem ser reutilizados por qualquer outro trabalho.

Pergunta, questão

Qual é a solução certa, que pode ser aplicado em si Kubernetes, por não o pod imediatamente ou pelo menos rapidamente se um puxão falhar devido a imagem estivador um existente não: tag?

possibilidades

Olhei para backofflimit. Eu configurá-lo para 0, mas isso não falhar ou remover o trabalho. Os recursos são, naturalmente, mantido bem.

Talvez eles possam ser morto por um trabalho cron. Não sabe como fazê-lo.

Idealmente, os recursos não deve mesmo ser alocados para um trabalho com uma imagem não mais existiam janela de encaixe. Mas eu não tenho certeza se há uma possibilidade de alcançar facilmente isso.

Qualquer outro?

Publicado 24/10/2019 em 11:53
fonte usuário
Em outras línguas...                            


3 respostas

votos
0

Você pode usar failedJobsHistoryLimitpara tarefas com falhas e successfulJobsHistoryLimitpara trabalhos de sucesso

Com estes dois parâmetros, você pode manter o seu emprego história limpa

.spec.backoffLimit para especificar o número de tentativas antes de considerar um trabalho como falha.

Respondeu 24/10/2019 em 12:16
fonte usuário

votos
0

Quando A completa emprego, sem mais Pods são criados, mas as vagens não são excluídos também.

Por padrão, um trabalho será executado sem interrupções a menos que um Pod falhar (restartPolicy = Nunca) ou um recipiente saídas em erro (restartPolicy = OnFailure), altura em que os adia trabalho para a .spec.backoffLimit descrito acima. Uma vez .spec.backoffLimit foi alcançado o trabalho será marcado como falhou e nenhum Pods executando será encerrado.

Outra maneira de terminar um trabalho é através da criação de um prazo ativo. Fazer isso definindo o .spec.activeDeadlineSeconds campo do trabalho para um número de segundos. Os activeDeadlineSeconds se aplica à duração do trabalho, não importa quantas Pods são criados. Uma vez que um trabalho atinge activeDeadlineSeconds, todos os seus Pods em execução são encerrados e o status do trabalho vai se tornar Tipo: Falha com a razão: DeadlineExceeded.

Note-se que um de Jó .spec.activeDeadlineSeconds tem precedência sobre a sua .spec.backoffLimit . Portanto, um trabalho que está repetindo uma ou Pods mais falhadas não vai implantar Pods adicionais uma vez que atinge o limite de tempo especificado por activeDeadlineSeconds , mesmo se o backoffLimit ainda não é atingido.

Aqui está mais informações: empregos .

Você também pode configurá-lo concurrencyPolicy de cronjob para substituir e substituir o trabalho sendo executado com um novo emprego.

Aqui está um exemplo:

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "*/2 * * * *"
  concurrencyPolicy: Replace
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox
            args:
            - /bin/sh
            - -c
            - date; echo Hello from the Kubernetes cluster && sleep 420
          restartPolicy: Never

Definir Substituir valor para concurrencyPolicy meios bandeira se é hora de uma nova execução da tarefa ea execução da tarefa anterior ainda não terminou, o trabalho cron substitui o actualmente em execução execução da tarefa com uma nova execução da tarefa.

Independentemente de esta solução suas mentiras problemáticas em imagens erradas de modo automatizado exclusão de vagens ou empregos não resolve problema. Porque se você não mudar nada na definição de trabalhos e imagens suas vagens ainda falhará após a criação de trabalho novamente.

Aqui é exemplo de solução de problemas para Erro: ImagePullBackOff normal BackOff: ImagePullBackOff .

Respondeu 25/10/2019 em 10:27
fonte usuário

votos
0

Depois de olhar para o seu projeto, eu recomendaria para adicionar InitContainer a especificação de trabalho para verificar a existência de imagens docker com a tag dada.

Se a imagem com a tag não existe no registro, InitContainer pode relatar um erro e falha Pod do trabalho por sair com um código de saída diferente de zero.

Depois Pod que é o trabalho será reiniciado . Depois de certa quantidade de tentativas Job terá Failedestado. Ao configurar .spec.ttlSecondsAfterFinished opção, falhou trabalhos podem ser eliminados.

Se recipiente de inicialização de um Pod falhar, Kubernetes reinicia repetidamente a Pod até que o recipiente de inicialização bem-sucedida. No entanto, se o Pod tem uma restartPolicy do Nunca, Kubernetes não reiniciar o Pod.

Se a imagem existe, InitContainer saídas script com a imagem Recipiente trabalho principal de código e de saída zero vai ser puxado e começa recipiente.

Respondeu 01/11/2019 em 20:55
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more