Пятница, друзья мои. А это значит, можно под чашечку душистого чая почитать историю о том, как наиболее дурацким способом починить кластер кубера в Яндекс Облаке.
#k8s #yandexcloud #friday #debug
дисклеймер - возможны фейспалмы
Пишет мне разработчик: "Саш, у нас что-то в облаке кластер для нагрузочного тестирования не поднимается, посмотри, пожалуйста. Поды висят Pending".
Опустим ситуацию с тем, как ретроград Александр убил время на то, чтобы понять, как через клиент
Поды в статусе
А теперь следите за моей логикой. Я не настраивал Yandex Container Registry, я с ним не работал, Managed k8s я тоже не разворачивал (набрали дилетантов). Я захожу на ноду и вижу, что до сервера registry таймаут. Я интуитивно полагаю, что в managed кластере интеграция с их же registry должна работать нативно, поэтому тут же накатываю тикет в поддержку (впервые в жизни писал в поддержку за советом по куберу, всю жизнь раньше работал по принципу сам отдебажу или умру, как под штангой 100кг в зале). Отвечают быстро, у нас же премиум.
Итог банальный: чтобы работал Container Registry, нужен доступ во внешний интернет. А у нас там на узлах нет внешних интерфейсов, маршрута тоже нет. Пишу разработчику: "а раньше-то развёртывание работало?", в ответ: "да, раньше всё было ок".
Задумался. Курю документацию: можно либо дать узлам публичный IP, либо настроить NAT - либо шлюзом для VPC, либо отдельным инстансом. Понимаю, что не очень понимаю, как сделать правильно и быстро (к тому же походу дела terraform на самом деле и не применялся, но это другой разговор). Публичный IP на каждый узел - точно плохая идея, а с NAT надо разбираться.
Ну ладно, наша задача проста - быстренько поднять это дело, чтобы тестировщики смогли продолжить нагружать стенд. Если у меня есть доступ во внешний интернет и до машин кластера, то я могу скачать образы и импортировать их, всё просто!
(продолжение ниже)
#k8s #yandexcloud #friday #debug
В качестве очень краткой предыстории - проект потихоньку переезжает в Яндекс Облако. У меня коммерческого опыта в нём нет, только через Terraform поднимал там виртуалки и S3 хранилище в качестве учебного проекта на "пощупать". Всегда на работе до этого был собственный периметр, о чём честно сказал на собеседовании, помычав что-то отдалённо внятное про terraform plan, terraform apply (без какой-то осмысленной практики мало вещей запоминается). Тем не менее этого было достаточно. Я тешу себя мыслью, что блистал на вопросах про k8s и linux, поэтому в то, что я разберусь в облаке, быстро поверили.
Пишет мне разработчик: "Саш, у нас что-то в облаке кластер для нагрузочного тестирования не поднимается, посмотри, пожалуйста. Поды висят Pending".
Опустим ситуацию с тем, как ретроград Александр убил время на то, чтобы понять, как через клиент
yc вытянуть себе iam-токен для kubectl. Оказывается, всё это необязательно, базовый дебаг можно делать прямо в консоли облака, в веб-интерфейсе кластер, как на ладони. Прикольно.Поды в статусе
ImagePullBackOff. Классика. Смотрим события (для анонимизации имена репозиториев искажены):Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Pulling 18m (x19 over 103m) kubelet Pulling image "cr.yandex/randomuid/image:1.337-stable-stress"
Normal BackOff 3m34s (x382 over 103m) kubelet Back-off pulling image "cr.yandex/randomuid/image:1.337-stable-stress"
А теперь следите за моей логикой. Я не настраивал Yandex Container Registry, я с ним не работал, Managed k8s я тоже не разворачивал (набрали дилетантов). Я захожу на ноду и вижу, что до сервера registry таймаут. Я интуитивно полагаю, что в managed кластере интеграция с их же registry должна работать нативно, поэтому тут же накатываю тикет в поддержку (впервые в жизни писал в поддержку за советом по куберу, всю жизнь раньше работал по принципу сам отдебажу или умру, как под штангой 100кг в зале). Отвечают быстро, у нас же премиум.
Итог банальный: чтобы работал Container Registry, нужен доступ во внешний интернет. А у нас там на узлах нет внешних интерфейсов, маршрута тоже нет. Пишу разработчику: "а раньше-то развёртывание работало?", в ответ: "да, раньше всё было ок".
Задумался. Курю документацию: можно либо дать узлам публичный IP, либо настроить NAT - либо шлюзом для VPC, либо отдельным инстансом. Понимаю, что не очень понимаю, как сделать правильно и быстро (к тому же походу дела terraform на самом деле и не применялся, но это другой разговор). Публичный IP на каждый узел - точно плохая идея, а с NAT надо разбираться.
Ну ладно, наша задача проста - быстренько поднять это дело, чтобы тестировщики смогли продолжить нагружать стенд. Если у меня есть доступ во внешний интернет и до машин кластера, то я могу скачать образы и импортировать их, всё просто!
(продолжение ниже)
По мере изучения ремесла DevOps многим специалистам, пришедшим в профессию из эксплуатации и системного администрирования, по инерции свойственно сильнее углубляться в Ops, нежели в Dev (и я не исключение).
Чем больше ты узнаёшь, тем обширнее становится твоё столкновение с незнанием (парадокс познания, который описал Сократ своим «я знаю, что ничего не знаю»). Чем ближе подходишь к непосредственным продуктам, тем яснее понимаешь, что всё начинается с разработки (затем идёт продажа, а дальше всё остальное прекрасное - эксплуатация, тестирование, аналитика).
Не претендую на истину, и вообще, вряд ли я всё понимаю верно, опыта всё-таки пока не много.
Но вот что я понял для себя за последний год — зря я когда-то на 2-3 курсе универа полностью открестился от разработки в пользу эксплуатации. Потому что разработка это весело и важно. С другой стороны, всё бы тогда сложилось по-другому, поэтому имеем, что имеем.
Заново пытаюсь учить себя разработке, благо придумал себе пару практических задач. Сейчас устремил своё внимание на Go. Уверен, это хорошая технология для человека, знакомого с C, и поглядывающего на cloud-native подходы к разработке.
Поэтому здесь иногда будут заметки на тему изучения технологий программирования. И вот первая из них:
Читаю A Tour of Go и в сноске нашёл крутую статью. Как язык Go улучшает подход к синтаксису определения сущностей, который читается по-человечески, слева-направо! В отличие от языка C, для чтения деклараций в котором вам стоит использовать правило чтения по-спирали! Часто слышал, что Go создавался с оглядкой на C, и такие детали лучше позволяют понять мотивацию его создателей.
#go #c #programming #friday
Очень круто натыкаться на такие статьи, дающие понять логику технологии, а не только метод её применения. Особенно когда одна из таких статей старше тебя на 8 лет.
Чем больше ты узнаёшь, тем обширнее становится твоё столкновение с незнанием (парадокс познания, который описал Сократ своим «я знаю, что ничего не знаю»). Чем ближе подходишь к непосредственным продуктам, тем яснее понимаешь, что всё начинается с разработки (затем идёт продажа, а дальше всё остальное прекрасное - эксплуатация, тестирование, аналитика).
Но вот что я понял для себя за последний год — зря я когда-то на 2-3 курсе универа полностью открестился от разработки в пользу эксплуатации. Потому что разработка это весело и важно. С другой стороны, всё бы тогда сложилось по-другому, поэтому имеем, что имеем.
Заново пытаюсь учить себя разработке, благо придумал себе пару практических задач. Сейчас устремил своё внимание на Go. Уверен, это хорошая технология для человека, знакомого с C, и поглядывающего на cloud-native подходы к разработке.
Поэтому здесь иногда будут заметки на тему изучения технологий программирования. И вот первая из них:
Читаю A Tour of Go и в сноске нашёл крутую статью. Как язык Go улучшает подход к синтаксису определения сущностей, который читается по-человечески, слева-направо! В отличие от языка C, для чтения деклараций в котором вам стоит использовать правило чтения по-спирали! Часто слышал, что Go создавался с оглядкой на C, и такие детали лучше позволяют понять мотивацию его создателей.
#go #c #programming #friday
Очень круто натыкаться на такие статьи, дающие понять логику технологии, а не только метод её применения. Особенно когда одна из таких статей старше тебя на 8 лет.