В рамках моей тестовой логики CI у меня есть скрипт, который создает файл развертывания Kubernetes для каждого из набора выделенных узлов, удаляет все предыдущие развертывания на них, а затем запускает новые развертывания. (Конфигурация добавлена внизу, потому что это, вероятно, не важно.) После того, как я запустил тесты с ними, они отключаются и готовы к следующему тестовому запуску. Узлы запускают только мои развертывания, поэтому я не беспокоюсь о том, сколько ЦП/памяти/чего-либо еще им нужно, и у меня нет никаких скриптов готовности, потому что контейнеры сами решают эти вопросы между собой, и мне нужно только связаться со службой мониторинга состояния, как только у нее появится IP-адрес.
Обычно они готовы и работают примерно через минуту — мой скрипт отслеживает вывод следующей команды до тех пор, пока ничто не выдаст сообщение «false», — но время от времени они не запускаются в отведенное мной время: я не хочу ждать неопределенное время, если что-то пойдет не так — мне нужно собрать адреса, чтобы передать их нижестоящим процессам, настроить мои тесты с развертываниями, которые были завершены, — но если Kubernetes не может показать мне значимый прогресс или диагностику того, почему все идет медленно, я не могу сделать ничего, кроме как прервать незавершенные развертывания.
kubectl get pods -l pod-agent=$AGENT_NAME \
-o 'jsonpath={range .items[*]}{..status.conditions[?(@.type=="Ready")].status}:{.status.podIP}:{.status.phase}:{.metadata.name} '
Я предположил, что один из контейнеров мог ранее не использоваться на этом хосте, и, возможно, его копирование на каждый хост заняло так много времени, что общее развертывание превысило тайм-аут моего скрипта, поэтому я добавил это (игнорируйте | cat | — это обходной путь для ошибки терминала IntelliJ)
kubectl describe pod $REPLY | cat | sed -n '/Events:/,$p; /emulator.*:/,/Ready:/p'
чтобы получить представление о том, что делает каждый модуль, каждый раз первая команда возвращает «false», но я получаю то, что выглядит как противоречивые результаты: хотя в разделе «события» утверждается, что контейнеры извлечены и запущены, структурированный вывод той же команды показывает контейнеры как «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
..еще больше того же самого, а затем
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"
поэтому события утверждают, что контейнеры запущены, но структурированные данные противоречат этому. Я бы использовал события как авторитетные, но они довольно странно усечены на 26 ведущих(!) записях, несмотря на то, что сервер не был настроен с какой-либо конфигурацией ограничения частоты событий.
Я включил полное описание одного из контейнеров, который, по утверждению событий, «запустился» в конце, но не вижу никаких подсказок в полном выводе.
После начала развертывания (т. е. после того, как в первой строке отображается значение «true»), все контейнеры внезапно отображаются как «Running».
Итак, мой основной вопрос заключается в том, как я могу определить фактическое состояние моего развертывания — по-видимому, представленное «событиями», — чтобы понять, почему и где оно застревает в тех случаях, когда оно дает сбой, учитывая, что оно, describe podпо-видимому, ненадежно и/или неполно?
Есть ли что-то помимо «kubectl get pods», что я могу использовать, чтобы узнать РЕАЛЬНОЕ состояние дел? (Желательно не что-то грубое вроде подключения к серверу по ssh и прослушивания его необработанных журналов.)
Спасибо.
kubectl 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", Компилятор:"gc", Платформа:"linux/amd64"} Версия сервера: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.3", GitCommit:"2d3c76f9091b6bec110a5e63777c332469e0cba2", GitTreeState:"clean", BuildDate:"2019-08-19T11:05:50Z", GoVersion:"go1.12.9", Компилятор:"gc", Платформа:"linux/amd64"}
Мой файл развертывания:
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.
И полное «описание» контейнера, объявленного как «запущенный» событиями:
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)
решение1
Вы можете использоватьkubectl подождиприостановить выполнение теста до тех пор, пока модули не придут в Readyсостояние .
Помните, что если вы не используете проверку готовности для своего приложения, то статус модулей Readyне будет означать, что ваше приложение действительно готово к приему трафика, что может привести к сбоям в работе ваших тестов.