Inforcing Ingress возвращает 503 во время технического обслуживания

Question

У нас есть некоторые из наших API-сервисов, работающих на Google Kubernetes Engine, и время от времени нам нужно проводить некоторые ремонтные работы, поэтому мы хотим, чтобы сервис API возвращал 503 вместе с некоторым настраиваемым сообщением о времени простоя.

Это не будет надежным способом заставить службу API возвращать 503 из развертываний Kubernetes, на которые ссылается служба, так как может потребоваться отключить / перезапустить модули API.

Одна идея, которая у меня возникла, заключалась в том, чтобы иметь конкретное развертывание / модуль, который мы настроили бы для использования службы, и чтобы эта служба просто возвращала 503 с некоторой информацией об обслуживании Службы. Однако этот подход не будет работать, если мы проведем обновление кластера, поскольку может быть некоторое время, когда развертывание / модуль также будет недоступен.

Так есть ли способ сделать это, не полагаясь на развертывание / модуль? Имеется в виду конфигурация, которая выходит за рамки конкретного кластера Kubernetes?

Answer 1

Вы можете использовать вход и 2 развертывания (API и 503) и всякий раз, когда вы хотите переключиться, вы просто редактируете вход.

kubectl edit ingress ${INGRESS_NAME}

В GKE вы можете достичь нулевого времени простоя, если используете региональный кластер (3 мастера), как минимум 2 пула узлов и сходство узлов с узлами в разных пулах узлов так что всякий раз, когда вы обновляете только пул узлов, используя флаг - node-pool , в пуле других узлов запускается модуль.

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

Answer 2

Если вы установите эту конфигурацию на уровне Kubernetes, она никогда не будет удерживаться во время обновления кластера. Вы должны положиться на внешнее решение, например, разместить простую функцию в облачных функциях. Вы также можете достичь этого с помощью AWS Cloud Formation, например.

Переключение между приложением работоспособности и сообщением о техническом обслуживании, которое вы можете сделать в DNS, но я бы не стал полагаться на него, поскольку это может занять некоторое время в зависимости от конфигурации TTL. Я бы предпочел сделать это на вашем решении LoadBalancer.