Порядок контроля окончания контейнеров в одном контейнере в Кубернетес - PullRequest
Новая
       60

Порядок контроля окончания контейнеров в одном контейнере в Кубернетес

0 голосов
/ 03 сентября 2018

У меня есть два контейнера внутри одного контейнера. Один - это контейнер моего приложения, а второй - контейнер прокси CloudSQL. В основном мой контейнер приложения зависит от этого контейнера CloudSQL.

Проблема заключается в том, что при завершении работы модуля pod контейнер CloudSQL-прокси завершается первым и только через несколько секунд контейнер моего приложения завершается.

Итак, до того, как мой контейнер завершит свою работу, он продолжает отправлять запросы в контейнер CloudSQL, что приводит к ошибкам: 

could not connect to server: Connection refused Is the server running on host "127.0.0.1" and accepting TCP/IP connections on port 5432

Вот почему я подумал, что было бы неплохо указать порядок завершения, так что мой контейнер приложения будет завершен в первую очередь, а затем только в облачном.

Мне не удалось найти ничего, что могло бы сделать это в документации. Но, может быть, есть какой-то способ.

1 Ответ

0 голосов
/ 03 сентября 2018

В настоящее время это невозможно напрямую с API-интерфейсом Kubernetes. Контейнеры могут быть прекращены в любом порядке. Модуль Cloud SQL может погибнуть быстрее, чем ваше приложение, например, если он требует меньше очистки для выполнения или требует меньше запросов в полете.

С Завершение стручков :

Когда пользователь запрашивает удаление модуля, система записывает предполагаемый льготный период до принудительного уничтожения модуля, и сигнал TERM отправляется главному процессу в каждом контейнере.

Вы можете обойти это в некоторой степени, поместив Cloud SQL и основные контейнеры в разные точки входа, которые сообщают друг другу о своем состоянии выхода, используя общую файловую систему уровня pod.

Оболочка, подобная следующей, может помочь с этим: 

containers:
- command: ["/bin/bash", "-c"]
  args:
  - |
    trap "touch /lifecycle/main-terminated" EXIT
    <your entry point goes here>
  volumeMounts:
  - name: lifecycle
    mountPath: /lifecycle
- name: cloudsql_proxy
  image: gcr.io/cloudsql-docker/gce-proxy
  command: ["/bin/bash", "-c"]
  args:
  - |
    /cloud_sql_proxy <your flags> &
    PID=$!

    function stop {
        while true; do
            if [[ -f "/lifecycle/main-terminated" ]]; then
                kill $PID
            fi
            sleep 1
        done
    }
    trap stop EXIT
    # We explicitly call stop to ensure the sidecar will terminate
    # if the main container exits outside a request from Kubernetes
    # to kill the Pod.
    stop &
    wait $PID
  volumeMounts:
  - name: lifecycle
    mountPath: /lifecycle

Вам также понадобится локальное пустое место, чтобы использовать его для передачи событий жизненного цикла: 

volumes:
- name: lifecycle
  emptyDir:

Конечно, это зависит от того, какие контейнеры у вас работают, и им доступна оболочка; это верно для прокси-сервера Cloud SQL, но вам может потребоваться внести изменения в ваши сборки, чтобы убедиться, что это верно для ваших собственных контейнеров приложений.

...