Работа с несколькими контейнерами никогда не преуспевает

Question

Я запускаю Kubernetes в кластере GKE и должен запускать сценарий миграции DB при каждом развертывании. Для постановки это легко: у нас есть постоянный отдельный сервис MySQL со своим собственным томом. Однако для производства мы используем GCE SQL, в результате чего работа имеет два контейнера - еще один для миграции, а другой для Cloud Proxy.

Из-за этого нового контейнера работа всегда отображается как 1 активная при запуске kubectl describe jobs/migration, и у меня полная потеря. Я попробовал переупорядочить контейнеры, чтобы проверить, проверяет ли он один по умолчанию, но это не имело никакого значения, и я не вижу способа либо: a) убить контейнер, либо b) проверить статус только одного контейнера внутри Job.

Любые идеи?

Answer 1

каждый Pod может быть настроен с помощью init container, который, кажется, подходит для вашей проблемы. Поэтому вместо того, чтобы иметь Pod с двумя контейнерами, которые должны запускаться постоянно, вы можете скорее определить контейнер init, чтобы выполнить миграцию заранее. Например. например:

apiVersion: v1 
kind: Pod 
metadata: 
    name: init-container 
    annotations: 
    pod.beta.kubernetes.io/init-containers: '[ 
     { 
      "name": "migrate", 
      "image": "application:version", 
      "command": ["migrate up"], 
     } 
    ]' 
spec: 
    containers: 
    - name: application 
    image: application:version 
    ports: 
    - containerPort: 80 

Answer 2

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

TL; DR: Переместите ваши контейнеры в отдельные задания, если они независимы.

-

Kubernetes рабочих мест держать перезагрузки, пока работа успешно. Задача kubernetes будет успешной только в том случае, если каждый контейнер внутри будет успешным.

Это означает, что ваши контейнеры должны быть возвращены при повторном пуске. Как только контейнер успешно работает, он должен вернуться к успеху, даже если он снова запустится. В противном случае, скажем, контейнер1 успешно, контейнер2 терпит неудачу. Работа перезапускается. Затем контейнер1 терпит неудачу (потому что он уже прошел успешно). Следовательно, Job продолжает перезапуск.

Answer 3

Я знаю, что это слишком поздно, но лучше всего запустить одиночный прокси-сервер cloudql для всех приложений, а затем настроить доступ к БД в образе приложения, чтобы использовать эту службу в качестве имени узла базы данных.

Таким образом, вам не потребуется класть контейнер облака cloudql в каждый контейнер, который использует БД.