Как имитировать отключение зоны доступности в службе Azure Kubernetes?

#azure #kubernetes #azure-aks #availability-zone

#azure #kubernetes #azure-aks #зона доступности

Вопрос:

Ниже приведены мои запросы:

  1. Как имитировать отключение зоны доступности в службе Azure Kubernetes, чтобы убедиться, что переключение входящего трафика выполнено в другую зону?
  2. Есть ли какой-либо способ выяснить, какая зона или какой узел в настоящее время получает входящие запросы в службе Azure Kubernetes?

Ответ №1:

Неясно, что вы подразумеваете под проверкой переключения входящего трафика. Переключение трафика не происходит, трафик будет поступать в модули, которые в настоящее время доступны для ответа на запрос. Вы несете ответственность за распределение реплик по разным зонам доступности в вашем кластере. если, например, у вас есть модуль развертывания с двумя репликами, одна в зоне 1, а другая в зоне 2, трафик будет поступать на обе реплики, если зона 1 отключается, балансировщик нагрузки будет отправлять трафик только в модуль в зоне 2, пока модуль в зоне 1 не вернется.

  1. Один из простых способов проверить это — остановить или перезапустить виртуальные машины в одной зоне доступности и проверить, не происходит ли простоя.
  2. Как я уже сказал, это не одна зона за раз, вам необходимо развернуть реплики во всей зоне доступности, если вы хотите, чтобы отказоустойчивость зоны выполнялась, и это не выполняется автоматически с помощью AKS. Один из способов сделать это — настроить podAntiAffinity в вашем модуле Pod, чтобы убедиться, что реплики не развернуты на том же узле и в той же зоне доступности. В AKS узлы имеют метку topology.kubernetes.io/zone , содержащую номер зоны, вы можете использовать эту метку в правиле podAntiAffinity. Следующая команда предоставит вам список узлов с разными зонами :
 kubectl get nodes -o custom-columns=NAME:'{.metadata.name}',REGION:'{.metadata.labels.topology.kubernetes.io/region}',ZONE:'{metadata.labels.topology.kubernetes.io/zone}'

NAME                                REGION   ZONE
aks-nodepool1-34917322-vmss000000   eastus   eastus-1
aks-nodepool1-34917322-vmss000001   eastus   eastus-2
aks-nodepool1-34917322-vmss000002   eastus   eastus-3
 

Комментарии:

1. Спасибо! Я также поступил так же, как вы предложили. Я испытал простои на 5-10 минут, а затем ответственность взяла на себя другая виртуальная машина.