Обновление Kubernetes без простоя? - PullRequest
0 голосов
/ 22 января 2019

Согласно https://kubernetes.io/docs/tutorials/stateful-application/basic-stateful-set/#scaling-a-statefulset, Я хотел бы спросить, как добиться непрерывного обновления с нулевым временем простоя? Я думаю, вот минимальные требования:

(1) .spec.updateStrategy установлен в RollingUpdate

(2) .spec.podManagementPolicy установлен в OrderedReady

(3) .spec.replicas установлен на 2

Это правильно? И я предполагаю, что когда обновление происходит в обратном порядке, весь трафик к StatefulSet обслуживается модулями с меньшим порядковым номером?

Ответы [ 2 ]

0 голосов
/ 23 января 2019

Я согласен с @Prafull Ladha, главной ролью readinessProbe здесь, чтобы гарантировать, что новые модули, созданные во время RollingUpdate, готовы принимать запросы перед завершением работы старых модулей.Однако вы также можете управлять процессом непрерывного обновления, указав соответствующие необязательные параметры, как описано в официальной документации Kubernetes .

0 голосов
/ 22 января 2019

Да, чтобы иметь нулевое время простоя для statefulsets обновления, вы должны иметь все упомянутые пункты:

  1. .spec.updateStrategy установлено на RollingUpdate
  2. .spec.podManagementPolicy установлен на OrderedReady, что по умолчанию OrderedReady
  3. .spec.replicas установлен на минимум 2.

Еще одна вещь, которую вам нужно убедиться, что ваш набор состояний не имеет времени простоя, является правильным readiness набор датчиков. Зонд readiness сообщает менеджеру контроллера kubernetes, что этот модуль готов к обработке запроса, и вы можете начать отправлять ему запросы.

Причина, по которой это очень важно при обновлении с нулевым временем простоя, состоит в том, что у вас есть две реплики statefulset, и вы начали непрерывное обновление без установленной проверки готовности. Kubernetes удалит модуль в обратном порядке и переведет его в рабочее состояние, пометит его как готовый и завершит работу другого модуля. Теперь предположим, что ваш контейнерный процесс не был запущен в то время, когда не будет ни одного модуля для обслуживания запросов, потому что один модуль еще не полностью готов, и kubernetes отключил другой модуль для процесса обновления и, следовательно, потери данных.

readinessProbe:
  httpGet:
    path: /
    port: 80
  initialDelaySeconds: 5
  periodSeconds: 5
  successThreshold: 1

РЕДАКТИРОВАТЬ: следующий фрагмент json, который я использую для обновления обновления состояний в моем случае:

 "spec": {
         "containers": [
           {
             "name": "md",
             "image": "",
             "imagePullPolicy": "IfNotPresent",
             "command": [
               "/bin/sh",
               "-c"
             ],
             "args": [
               "chmod -R 777 /logs/; /on_start.sh"
             ],
             "readinessProbe": {
                "exec": {
                   "command": [
                      "cat",
                      "/tmp/ready.txt"
                   ]
                 },
                 "failureThreshold": 10,
                 "initialDelaySeconds": 5,
                 "periodSeconds": 5,
                 "successThreshold": 1,
                 "timeoutSeconds": 1
             },
             "securityContext": {
               "privileged": true
             }
      }

Так вы можете настроить датчик готовности в ваших контейнерах с установленным состоянием. Я устанавливаю датчик готовности как linux command, если у вас http-проба, он будет другим.

...