Назад | Перейти на главную страницу

Как я могу определить текущее / подготовительное состояние развертывания Kubernetes, прежде чем оно будет «готово»?

В рамках моей логики тестирования CI у меня есть сценарий, который создает файл развертывания Kubernetes для каждого из группы выделенных узлов, удаляет все предыдущие развертывания на них, а затем запускает новые развертывания. (Конфигурация добавлена внизу, потому что это, вероятно, не важно.) После того, как я запустил тесты с ними, они отключаются для следующего тестового запуска. Узлы запускают только мои развертывания, поэтому я не беспокоюсь об объявлении, сколько ЦП / памяти / всего, что им нужно, и у меня нет никаких сценариев готовности, потому что контейнеры работают между собой, и мне нужно только поговорить в службу мониторинга состояния, если у нее есть IP-адрес.

Обычно они готовы и работают в течение минуты или около того - мой сценарий отслеживает вывод следующей команды до тех пор, пока ничего не сообщит «ложь», - но время от времени они не запускаются в течение времени, которое я позволяю: Я не Я не хочу ждать неопределенное время, если что-то пойдет не так - мне нужно собрать адреса, чтобы передать их нижестоящим процессам, чтобы настроить мои тесты с развертываниями, которые DID завершены - но если кубернеты не могут показать мне значимый прогресс или Чтобы понять, почему все идет медленно, я ничего не могу сделать, кроме как прервать незавершенное развертывание.

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 ведущих (!) Записях, несмотря на то, что сервер не настроен с какой-либо конфигурацией, ограничивающей скорость событий.

Я включаю полное описание одного из контейнеров, в котором, по утверждениям событий, «началось» в конце, но я не вижу никаких подсказок в полных выводах.

Как только развертывание началось, то есть первая строка показывает «истина», все контейнеры внезапно отображаются как «выполняется».

Итак, мой основной вопрос заключается в том, как я могу определить фактическое состояние моего развертывания - очевидно, представленное «событиями» - чтобы понять, почему и где он застревает в тех случаях, когда он терпит неудачу, учитывая, что describe pod очевидно ненадежный и / или неполный?

Есть ли что-то помимо "kubectl get pods", которое я могу использовать для определения НАСТОЯЩЕГО состояния игры? (Желательно не использовать что-то пошлое, например ssh-соединение с сервером и прослушивание его необработанных журналов.)

Спасибо.

kubectl version Версия клиента: version.Info {Major: «1», Minor: «16», GitVersion: «v1.16.3», GitCommit: «b3cbbae08ec52a7fc73d334838e18d17e8512749», GitTreeState: «clean», BuildDate11: «2019-11-13» 23: 11Z ", GoVersion:" go1.12.12 ", Compiler:" gc ", Platform:" 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 ", Компилятор:" gcux "/ 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)

Ты можешь использовать kubectl подождите чтобы приостановить выполнение теста, пока модули не будут в Ready положение дел.

Имейте в виду, что если вы не используете тест готовности для своего приложения, модули находятся в Ready status не будет означать, что ваше приложение действительно готово к приему трафика, что может сделать ваши тесты нестабильными.