Como parte da minha lógica de teste de CI, tenho um script que cria um arquivo de implantação do Kubernetes para cada um de vários nós dedicados, exclui todas as implantações anteriores neles e, em seguida, inicia as novas implantações. (Configuração anexada na parte inferior porque provavelmente não é importante.) Depois de executar os testes com eles, eles serão desligados, prontos para a próxima execução de teste. Os nós apenas executam minhas implantações, então não estou me preocupando em declarar quanta CPU/memória/o que eles precisam, e não tenho nenhum script de prontidão porque os contêineres resolvem essas coisas entre si, e eu só preciso conversar ao serviço de monitoramento de status, uma vez que tenha um endereço IP.
Geralmente eles estão prontos e funcionando em cerca de um minuto - meu script monitora a saída do comando a seguir até que nada informe 'falso' - mas de vez em quando eles não iniciam dentro do tempo que estou permitindo: eu não ' não quero esperar um tempo indeterminado se algo der errado - preciso coletar os endereços para alimentá-los aos processos downstream, para configurar meus testes com as implantações que foram concluídas - mas se o kubernetes não puder me mostrar um progresso significativo ou diagnóstico de por que as coisas estão lentas, não posso fazer muito mais do que abortar as implantações incompletas.
kubectl get pods -l pod-agent=$AGENT_NAME \
-o 'jsonpath={range .items[*]}{..status.conditions[?(@.type=="Ready")].status}:{.status.podIP}:{.status.phase}:{.metadata.name} '
Eu teorizei que poderia ser que um dos contêineres não tivesse sido usado naquele host antes e que talvez tenha demorado tanto para copiá-lo para cada host que a implantação geral excedeu o tempo limite do meu script, então adicionei isso (ignore o | cat | - é uma solução alternativa para um bug do terminal IntelliJ)
kubectl describe pod $REPLY | cat | sed -n '/Events:/,$p; /emulator.*:/,/Ready:/p'
para me dar uma ideia do que cada pod está fazendo, cada vez que o primeiro comando retorna 'falso', mas recebo resultados aparentemente inconsistentes: embora a seção 'eventos' afirme que os contêineres são extraídos e iniciados, a saída estruturada de o mesmo comando mostra os contêineres como 'ContainerCreating':
1 False::Pending:kubulator-mysh-automation11-dlan-666b96d788-6gfl7
emulator-5554:
Container ID:
Image: dockerio.dlan/auto/android-avd-10a29v8-emu29_0_11_kuber-snapshot-skin_name-540x1060-hw_lcd_density-240
Image ID:
Port: <none>
Host Port: <none>
State: Waiting
Reason: ContainerCreating
Ready: False
emulator-5556:
Container ID:
Image: dockerio.dlan/auto/android-avd-10a29v8-emu29_0_11_kuber-snapshot-skin_name-540x1060-hw_lcd_density-240
Image ID:
Port: <none>
Host Port: <none>
State: Waiting
Reason: ContainerCreating
Ready: False
..mais do mesmo, e então
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 23s default-scheduler Successfully assigned auto/kubulator-mysh-automation11-dlan-666b96d788-6gfl7 to automation11.dlan
Normal Pulling 16s kubelet, automation11.dlan Pulling image "dockerio.dlan/auto/ticket-machine"
Normal Pulled 16s kubelet, automation11.dlan Successfully pulled image "dockerio.dlan/auto/ticket-machine"
Normal Created 16s kubelet, automation11.dlan Created container ticket-machine
Normal Started 16s kubelet, automation11.dlan Started container ticket-machine
Normal Pulling 16s kubelet, automation11.dlan Pulling image "dockerio.dlan/qa/cgi-bin-remote"
Normal Created 15s kubelet, automation11.dlan Created container cgi-adb-remote
Normal Pulled 15s kubelet, automation11.dlan Successfully pulled image "dockerio.dlan/qa/cgi-bin-remote"
Normal Started 15s kubelet, automation11.dlan Started container cgi-adb-remote
Normal Pulling 15s kubelet, automation11.dlan Pulling image "dockerio.dlan/auto/android-avd-10a29v8-emu29_0_11_kuber-snapshot-skin_name-540x1060-hw_lcd_density-240"
Normal Pulled 15s kubelet, automation11.dlan Successfully pulled image "dockerio.dlan/auto/android-avd-10a29v8-emu29_0_11_kuber-snapshot-skin_name-540x1060-hw_lcd_density-240"
Normal Created 15s kubelet, automation11.dlan Created container emulator-5554
Normal Started 15s kubelet, automation11.dlan Started container emulator-5554
Normal Pulled 15s kubelet, automation11.dlan Successfully pulled image "dockerio.dlan/auto/android-avd-10a29v8-emu29_0_11_kuber-snapshot-skin_name-540x1060-hw_lcd_density-240"
Normal Pulling 15s kubelet, automation11.dlan Pulling image "dockerio.dlan/auto/android-avd-10a29v8-emu29_0_11_kuber-snapshot-skin_name-540x1060-hw_lcd_density-240"
Normal Created 14s kubelet, automation11.dlan Created container emulator-5556
Normal Started 14s kubelet, automation11.dlan Started container emulator-5556
Normal Pulling 14s kubelet, automation11.dlan Pulling image "dockerio.dlan/auto/android-avd-10a29v8-emu29_0_11_kuber-snapshot-skin_name-540x1060-hw_lcd_density-240"
então os eventos afirmam que os contêineres foram iniciados, mas os dados estruturados contradizem isso. Eu usaria os eventos como oficiais, mas eles são estranhamente truncados nas 26 entradas principais (!), Apesar de o servidor não estar configurado com nenhuma configuração de limitação de taxa de eventos.
Incluí uma descrição completa de um dos contêineres cujos eventos afirmam ter 'iniciado' no final, mas não vejo nenhuma pista na saída completa.
Assim que a implantação for iniciada - ou seja, a primeira linha mostra 'true', todos os contêineres aparecem abruptamente como 'Running'.
Portanto, minha questão fundamental é como posso determinar o estado real da minha implantação - aparentemente representado por 'eventos' - para entender por que e onde ela fica presa nas ocasiões em que falha, visto que describe podé aparentemente não confiável e/ou incompleta?
Existe algo além de 'kubectl get pods' que posso usar para encontrar a situação REAL? (De preferência, não algo complicado como ssh-ing para o servidor e farejar seus logs brutos.)
Obrigado.
versão kubectl Versão do cliente: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.3", GitCommit:"b3cbbae08ec52a7fc73d334838e18d17e8512749", GitTreeState:"clean", BuildDate:"2019-11-13T11: 23:11Z", GoVersion:"go1.12.12", Compiler:"gc", Platform:"linux/amd64"} Versão do servidor: version.Info{Major:"1", Minor:"15", GitVersion:"v1 .15.3", GitCommit:"2d3c76f9091b6bec110a5e63777c332469e0cba2", GitTreeState:"clean", BuildDate:"2019-08-19T11:05:50Z", GoVersion:"go1.12.9", Compilador:"gc", Plataforma:"linux/amd64 "}
Meu arquivo de implantação:
apiVersion: v1
kind: Service
metadata:
name: kubulator-mysh-automation11-dlan
labels:
run: kubulator-mysh-automation11-dlan
pod-agent: mysh
spec:
type: ClusterIP
clusterIP: None
ports:
- name: http
protocol: TCP
port: 8088
targetPort: 8088
- name: adb-remote
protocol: TCP
port: 8080
targetPort: 8080
- name: adb
protocol: TCP
port: 9100
targetPort: 9100
selector:
run: kubulator-mysh-automation11-dlan
kubernetes.io/hostname: automation11.dlan
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: kubulator-mysh-automation11-dlan
labels:
pod-agent: mysh
spec:
selector:
matchLabels:
run: kubulator-mysh-automation11-dlan
pod-agent: mysh
replicas: 1
template:
metadata:
labels:
run: kubulator-mysh-automation11-dlan
pod-agent: mysh
spec:
nodeSelector:
kubernetes.io/hostname: automation11.dlan
volumes:
- name: dev-kvm
hostPath:
path: /dev/kvm
type: CharDevice
- name: logs
emptyDir: {}
containers:
- name: ticket-machine
image: dockerio.dlan/auto/ticket-machine
args: ['--', '--count', '20'] # --adb /local/adb-....
imagePullPolicy: Always
volumeMounts:
- mountPath: /logs
name: logs
ports:
- containerPort: 8088
env:
- name: ANDROID_ADB_SERVER_PORT
value: "9100"
- name: ANDROID_ADB_SERVER
value: host
- name: cgi-adb-remote
image: dockerio.dlan/qa/cgi-bin-remote
args: ['/root/git/CgiAdbRemote/CgiAdbRemote.pl', '-foreground', '-port=8080', "-adb=/root/adb-8aug-usbbus-maxemu-v39"]
imagePullPolicy: Always
ports:
- containerPort: 8080
env:
- name: ADB_SERVER_SOCKET
value: "tcp:localhost:9100"
- name: ANDROID_ADB_SERVER
value: host
- name: emulator-5554
image: dockerio.dlan/auto/android-avd-10a29v8-emu29_0_11_kuber-snapshot-skin_name-540x1060-hw_lcd_density-240
imagePullPolicy: Always
securityContext:
privileged: true
volumeMounts:
- mountPath: /logs
name: logs
- mountPath: /dev/kvm
name: dev-kvm
env:
- name: ANDROID_ADB_VERSION
value: v39
- name: ANDROID_ADB_SERVER_PORT
value: '9100'
- name: EMULATOR_PORT
value: '5554'
- name: EMULATOR_MAX_SECS
value: '2400'
- name: ANDROID_ADB_SERVER
value: host
- name: EMU_WINDOW
value: '2'
- name: emulator-5556
image: dockerio.dlan/auto/android-avd-10a29v8-emu29_0_11_kuber-snapshot-skin_name-540x1060-hw_lcd_density-240
... etc - several more of these emulator containers.
E a 'descrição' completa de um contêiner declarado como 'iniciado' por eventos:
emulator-5554:
Container ID:
Image: dockerio.dlan/auto/android-avd-10a29v8-emu29_0_11_kuber-snapshot-skin_name-540x1060-hw_lcd_density-240
Image ID:
Port: <none>
Host Port: <none>
State: Waiting
Reason: ContainerCreating
Ready: False
Restart Count: 0
Environment:
ANDROID_ADB_VERSION: v39
ANDROID_ADB_SERVER_PORT: 9100
EMULATOR_PORT: 5554
EMULATOR_MAX_SECS: 2400
ANDROID_ADB_SERVER: host
EMU_WINDOW: 2
Mounts:
/dev/kvm from dev-kvm (rw)
/logs from logs (rw)
/var/run/secrets/kubernetes.io/serviceaccount from default-token-2jrv5 (ro)
Responder1
Você pode usarkubectl esperepara pausar a execução do teste até que os pods estejam no Readystatus.
Lembre-se de que, se você não usar um teste de prontidão para seu aplicativo, o Readystatus dos pods não implicará que seu aplicativo esteja realmente pronto para receber tráfego, o que pode tornar seus testes instáveis.