пользуем клиент Python kubernetes (4.0.0) в сочетании с движком Google kubernetes (master + nodepools run k8s 1.8.4) для периодического планирования рабочих нагрузок на kubernetes. Упрощенная версия скрипта, который мы используем для создания модуля, прикрепления к журналам и отчета о состоянии модуля, выглядит следующим образом:

config.load_kube_config(persist_config=False)
v1 = client.CoreV1Api()
v1.create_namespaced_pod(body=pod_specs_dict, namespace=args.namespace)
logging_response = v1.read_namespaced_pod_log(
    name=pod_name,
    namespace=args.namespace,
    follow=True,
    _preload_content=False
)
for line in logging_response:
    line = line.rstrip()
    logging.info(line)
status_response = v1.read_namespaced_pod_status(pod_name, namespace=args.namespace)
print("Pod ended in status: {}".format(status_response.status.phase))

Все работает довольно хорошо, однако у нас возникают некоторые проблемы с аутентификацией. Аутентификация происходит по умолчаниюgcp auth-провайдера, для которого я получил начальный токен доступа, запустивkubectl container cluster get-credentials вручную по планировщику. На некоторых случайных таймфреймах некоторые вызовы API приводят к ответу 401 от сервера API. Я предполагаю, что это происходит всякий раз, когда токен доступа истекает, и сценарий пытается получить новый токен доступа. Однако бывает так, что в планировщике одновременно выполняется несколько сценариев, в результате чего новый ключ API получается несколько раз, из которых только один остается действительным. Я опробовал несколько способов решить проблему (используйтеpersist_config=True, повторите попытку 401 после перезагрузки конфигурации, ...) без какого-либо успеха. Так как я не полностью осознаю, как работает аутентификация gcp и конфиг клиента python kubernetes (и документации для обоих довольно мало), я немного оставлен в неведении.

Должны ли мы использовать другой метод аутентификации вместоgcp Auth-провайдер? Это ошибка в клиенте Python kubernetes? Должны ли мы использовать несколько файлов конфигурации?