Como parte de mi lógica de prueba de CI, tengo un script que crea un archivo de implementación de Kubernetes para cada uno de un grupo de nodos dedicados, elimina cualquier implementación anterior en ellos y luego inicia las nuevas implementaciones. (La configuración se adjunta en la parte inferior porque probablemente no sea importante). Una vez que he ejecutado las pruebas con ellos, se apagan y están listos para la siguiente ejecución de prueba. Los nodos solo ejecutan mis implementaciones, por lo que no me molesto en declarar cuánta CPU/memoria/lo que sea que necesiten, y no tengo ningún script de preparación porque los contenedores resuelven esas cosas entre sí, y solo necesito hablar. al servicio de monitoreo de estado, una vez que tenga una dirección IP.
Por lo general, están listos y funcionando en aproximadamente un minuto (mi secuencia de comandos monitorea la salida del siguiente comando hasta que nada indica "falso"), pero de vez en cuando no se inician dentro del tiempo que les doy: No quiero esperar un tiempo indeterminado si algo sale mal; necesito recopilar las direcciones para alimentarlas a los procesos posteriores, configurar mis pruebas con las implementaciones que DID completaron, pero si Kubernetes no puede mostrarme un progreso significativo o diagnóstico de por qué las cosas van lentas, no puedo hacer mucho más que abortar las implementaciones incompletas.
kubectl get pods -l pod-agent=$AGENT_NAME \
-o 'jsonpath={range .items[*]}{..status.conditions[?(@.type=="Ready")].status}:{.status.podIP}:{.status.phase}:{.metadata.name} '
Teoricé que podría ser que uno de los contenedores no se hubiera utilizado antes en ese host, y que tal vez tomó tanto tiempo copiarlo en cada host que la implementación general excedió el tiempo de espera de mi secuencia de comandos, así que agregué esto (ignore el | cat | - es una solución para un error del terminal IntelliJ)
kubectl describe pod $REPLY | cat | sed -n '/Events:/,$p; /emulator.*:/,/Ready:/p'
para darme una idea de lo que está haciendo cada módulo, cada vez que el primer comando devuelve "falso", pero obtengo lo que parecen resultados inconsistentes: aunque la sección "eventos" afirma que los contenedores se extraen y se inician, la salida estructurada de el mismo comando muestra los contenedores 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
..más de lo mismo, y luego
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"
entonces los eventos afirman que los contenedores están iniciados, pero los datos estructurados lo contradicen. Usaría los eventos como autorizados, pero están extrañamente truncados en las 26 entradas principales (!) a pesar de que el servidor no está configurado con ninguna configuración que limite la tasa de eventos.
Incluyo una descripción completa de uno de los contenedores que, según los eventos, "comenzó" al final, pero no veo ninguna pista en el resultado completo.
Una vez que ha comenzado la implementación, es decir, la primera línea muestra "verdadero", todos los contenedores se muestran abruptamente como "En ejecución".
Entonces, mi pregunta fundamental es ¿cómo puedo determinar el estado real de mi implementación, aparentemente representada por "eventos", para entender por qué y dónde se atasca en aquellas ocasiones en las que falla, dado que describe podaparentemente no es confiable y/o está incompleto?
¿Hay algo más allá de 'kubectl get pods' que pueda usar para encontrar el estado REAL del juego? (Preferiblemente no algo tan desagradable como enviar ssh al servidor y olfatear sus registros sin procesar).
Gracias.
Versión de kubectl Versión del 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", Compilador:"gc", Plataforma:"linux/amd64"} Versión del servidor: version.Info{Mayor:"1", Menor:"15", GitVersion:"v1 .15.3", GitCommit:"2d3c76f9091b6bec110a5e63777c332469e0cba2", GitTreeState:"clean", BuildDate:"2019-08-19T11:05:50Z", GoVersion:"go1.12.9", Compilador:"gc", Plataforma:"linux/amd64 "}
Mi archivo de implementación:
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.
Y la 'descripción' completa de un contenedor 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)
Respuesta1
Puedes usarkubectl esperapara pausar la ejecución de la prueba hasta que los pods estén en Readyestado.
Tenga en cuenta que si no utiliza un problema de preparación para su aplicación, el hecho de que los pods estén en Readyestado no implicará que su aplicación esté realmente lista para recibir tráfico, lo que podría hacer que sus pruebas sean inestables.