Как использовать клиент Python Kubernetes таким образом, чтобы он был устойчив к сбоям GKE Kubernetes Master?

Question

Иногда мы используем скрипты Python для ускорения и мониторинга модулей Kubernetes, работающих на Google Kubernetes Engine, используя Официальную клиентскую библиотеку Python для kubernetes .Мы также включаем автоматическое масштабирование в некоторых из наших пулов узлов.

В соответствии с этим , «Master VM автоматически масштабируется, обновляется, резервируется и защищается».Пост также, кажется, указывает на то, что некоторое автоматическое масштабирование плоскости управления / главной виртуальной машины происходит, когда число узлов увеличивается с 0-5 до 6+ и, возможно, в другое время, когда добавляется больше узлов.

Кажется, чтоплоскость управления может упасть в такие моменты, когда было задействовано много узлов.Когда и где это происходит, наши скрипты Python, которые отслеживают модули через плоскость управления, часто терпят крах, по-видимому, не находя конечную точку KubeApi / Control Plane, вызывающую некоторые из следующих исключений:

ApiException, urllib3.exceptions.NewConnectionError, urllib3.exceptions.MaxRetryError.

Каков наилучший способ справиться с этой ситуацией?Существуют ли какие-либо свойства событий автоматического масштабирования, которые могут быть полезны?

Чтобы пояснить, что мы делаем с клиентом Python, мы находимся в цикле, читающем состояние интересующего модуля через read_namespaced_pod каждые несколько минут и перехват исключений, аналогичных приведенному в примере (кроме того, мы попытались также перехватить исключения для базовых вызовов urllib ).Мы также добавили повторные попытки с экспоненциальным откатом, но вещи не могут восстановиться и потерпеть неудачу после указанного максимального числа повторных попыток, даже если это число велико (например, продолжайте повторную попытку в течение> 5 минут).

Одна вещь, которую мы не пробовали, это воссоздание объекта kubernetes.client.CoreV1Api при каждой повторной попытке.Будет ли это иметь большое значение?

Answer 1

Когда размер пула узлов изменяется в зависимости от размера, это может инициировать изменение размера мастера.Вот размеры пулов узлов, сопоставленные с основными размерами .В случае, когда размер пула узлов требует большего мастера, автоматическое масштабирование мастера инициируется на GCP.Во время этого процесса мастер будет недоступен в течение примерно 1-5 минут.Обратите внимание, что эти события недоступны в Ведение журнала Stackdriver .

В этот момент все вызовы API к мастеру не будут выполнены, включая вызовы из клиента Python API и kubectl.Однако через 1-5 минут мастер должен быть доступен, и вызовы от клиента и kubectl должны работать.Я смог проверить это путем масштабирования моего кластера с 3 до 20 узлов, и в течение 1-5 минут мастер не был доступен.Я получил следующие ошибки от клиента Python API:

Max retries exceeded with url: /api/v1/pods?watch=False (Caused by NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection object at>: Failed to establish a new connection: [Errno 111] Connection refused',)) 

С kubectl у меня было:

“Unable to connect to the server: dial tcp” 

Через 1-5 минут мастер был доступен, и вызовы были успешными.Не было необходимости воссоздавать объект kubernetes.client.CoreV1Api , поскольку это всего лишь конечная точка API.

Согласно вашему описанию, ваш мастер не был доступен через 5 минут, что сигнализирует о потенциальной проблеме с вашим мастером или настройкой скрипта Python.Чтобы устранить эту проблему дальше во время работы скрипта Python, вы можете проверить доступность master, выполнив любую команду kubectl.