Похоже, что наш мастер был автоматически обновлен сегодня утром без предварительного предупреждения с более ранней версии 1.14.x до 1.14.7-gke.14, но ранее мы отключили автоматическое обновление, поэтому это совершенно странно, особенно если учесть, что 1.14.7-gke.14 нарушает идентификацию рабочей нагрузки. на которые полагаются многие из нас в мире GKE.
Более того, я вижу новую версию в списке 1.14.8-gke.2, которая на момент написания этого вопроса даже не упоминалась в примечаниях к выпуску GKE . Наш кластер был создан еще до того, как каналы выпуска стали единым целым, поэтому AFAIK нас не зачислили ни в один из них.
Интересно, кто-то нажал на спусковой крючок преждевременно (опять же, поскольку это не в первый раз).
Поскольку не было возможности вернуться к стабильной версии, в которой идентификация рабочей нагрузки работала нормально, мы продолжили и обновили до 1.14.8-gke.2 в надежде, что это решит проблему. Это была явная игра, которая не окупилась вообще, потому что привела к колоссальному кластерному феку, когда некоторые сервисы вообще не работали из-за всевозможных проблем с контейнерами и сетями. В частности:
Прометей-к-SD контейнера kube-dns выдаёт следующую ошибку: http://169.254.169.254/computeMetadata/v1/project/project-id: dial tcp 169.254.169.254:80: getsockopt: connection refused
Сбои в тестах готовности и живучестииз-за какой-то внутренней проблемы с сетью для некоторых наших сервисов
Теперь перейдем к основному вопросу. Что бы вы предложили, ребята? Воссоздать кластер и вернуться к v1.13.x, а также зарегистрироваться в стабильном выпуске канала? Какие еще варианты у нас есть? Хотелось бы получить представление о том, что здесь происходит, черт возьми.
РЕДАКТИРОВАТЬ: в настоящее время мы размещаемся в europe-west1-d, это зональный кластер, который включает 1 стандартный пул с 3 автоматически масштабируемыми узлами и1 вытесняемый пул для динамических рабочих нагрузок.
EDIT2: только что заметил в примечаниях к выпуску от 30 октября, что 1.14.6-gke.2 будет свернут, я должен был пропустить это раньше. В любом случае все еще остается вопрос, почему существует недокументированная версия и почему она не работает +, если кто-нибудь знает, когда идентичность рабочей нагрузки снова будет работать в обычном канале? Это вынуждает нас перейти на 1.13.x
EDIT3: оказывается, kube-dns использует версию образа 1.15.4 на кластере 1.14.x, это почти похоже на сломанный выпуск, когда я понижаю егоработает ненадолго, пока контроллер кластера не решил отменить изменение, поэтому мы собираемся воссоздать кластер
EDIT4: через несколько часов выясняется, что изображение cos_containerd было основной причиной, переключаяИзображение помогло решить все проблемы, похоже, мы продолжим мониторинг