Als Teil meiner CI-Testlogik habe ich ein Skript, das für jeden einer Reihe dedizierter Knoten eine Kubernetes-Bereitstellungsdatei erstellt, alle vorherigen Bereitstellungen auf ihnen löscht und dann die neuen Bereitstellungen startet. (Konfiguration unten angehängt, da sie wahrscheinlich nicht wichtig ist.) Nachdem ich die Tests mit ihnen ausgeführt habe, werden sie heruntergefahren und sind bereit für den nächsten Testlauf. Die Knoten führen nur meine Bereitstellungen aus, daher muss ich nicht angeben, wie viel CPU/Speicher/was auch immer sie benötigen, und ich habe keine Bereitschaftsskripte, da die Container das untereinander klären und ich nur mit dem Statusüberwachungsdienst kommunizieren muss, sobald dieser eine IP-Adresse hat.
Normalerweise sind sie innerhalb von etwa einer Minute bereit und funktionieren – mein Skript überwacht die Ausgabe des folgenden Befehls, bis nichts „false“ meldet –, aber hin und wieder starten sie nicht innerhalb der von mir gewährten Zeit: Ich möchte nicht auf unbestimmte Zeit warten, wenn etwas schiefgeht – ich muss die Adressen sammeln, um sie den nachgelagerten Prozessen zuzuführen, um meine Tests mit den Bereitstellungen einzurichten, die tatsächlich abgeschlossen wurden – aber wenn Kubernetes mir keinen sinnvollen Fortschritt oder keine Diagnose anzeigen kann, warum die Dinge langsam sind, kann ich nicht viel mehr tun, als die unvollständigen Bereitstellungen abzubrechen.
kubectl get pods -l pod-agent=$AGENT_NAME \
-o 'jsonpath={range .items[*]}{..status.conditions[?(@.type=="Ready")].status}:{.status.podIP}:{.status.phase}:{.metadata.name} '
Ich vermutete, dass einer der Container vielleicht noch nie auf diesem Host verwendet wurde und dass das Kopieren auf alle Hosts so lange gedauert hat, dass die gesamte Bereitstellung das Timeout meines Skripts überschritten hat. Daher habe ich Folgendes hinzugefügt (ignorieren Sie das | cat | – dies ist ein Workaround für einen Fehler im IntelliJ-Terminal).
kubectl describe pod $REPLY | cat | sed -n '/Events:/,$p; /emulator.*:/,/Ready:/p'
um mir einen Eindruck davon zu geben, was jeder Pod macht, gibt der erste Befehl jedes Mal „false“ zurück, aber ich erhalte scheinbar inkonsistente Ergebnisse: Obwohl im Abschnitt „Ereignisse“ angegeben wird, dass die Container abgerufen und gestartet werden, zeigt die strukturierte Ausgabe desselben Befehls die Container als „ContainerCreating“ an:
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
..mehr vom Gleichen, und dann
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"
Die Ereignisse behaupten also, dass die Container gestartet wurden, aber die strukturierten Daten widersprechen dem. Ich würde die Ereignisse als maßgeblich verwenden, aber sie sind bei den 26 führenden(!) Einträgen ziemlich seltsam abgeschnitten, obwohl der Server nicht mit einer Ereignisratenbegrenzungskonfiguration eingerichtet ist.
Ich füge am Ende eine vollständige Beschreibung eines der Container ein, von dem das Ereignis behauptet, er sei „gestartet“, aber ich sehe in der vollständigen Ausgabe keine Hinweise.
Sobald die Bereitstellung gestartet wurde, d. h. die erste Zeile „true“ anzeigt, wird für alle Container plötzlich „Running“ angezeigt.
Meine grundsätzliche Frage lautet also: Wie kann ich den tatsächlichen Status meiner Bereitstellung ermitteln – offenbar dargestellt durch „Ereignisse“ –, um zu verstehen, warum und wo sie bei Fehlern hängen bleibt, da sie describe podoffenbar unzuverlässig und/oder unvollständig ist?
Gibt es außer „kubectl get pods“ noch etwas anderes, mit dem ich den WIRKLICHEN Stand der Dinge herausfinden kann? (Vorzugsweise nichts so Schrottiges wie eine SSH-Verbindung zum Server und das Ausspionieren seiner Rohprotokolle.)
Danke.
kubectl-Version Client-Version: 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", Plattform:"linux/amd64"} Server-Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.3", GitCommit:"2d3c76f9091b6bec110a5e63777c332469e0cba2", GitTreeState:"clean", BuildDate:"2019-08-19T11:05:50Z", GoVersion:"go1.12.9", Compiler:"gc", Plattform:"linux/amd64"}
Meine Bereitstellungsdatei:
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.
Und die vollständige Beschreibung eines Containers, der durch Ereignisse als „gestartet“ deklariert wurde:
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)
Antwort1
Sie könnenkubectl warteum Ihre Testausführung anzuhalten, bis die Pods im ReadyStatus sind.
Bedenken Sie: Wenn Sie für Ihre App keine Bereitschaftsprüfung verwenden, Readybedeutet der Status der Pods nicht, dass Ihre App tatsächlich bereit ist, Datenverkehr aufzunehmen. Das könnte zu fehlerhaften Tests führen.