Forwarded from NN
ИИ научился думать как человек — теперь точно. Модель от польского стартапа Pathway превратили в копию живого мозга.
Модель сама формирует кластеры нейронов и укрепляет связи между ними во время рассуждений — прямо как люди. При этом она анализирует и делает выводы, а не просто повторяет выученную информацию.
Кажется, началось.
Модель сама формирует кластеры нейронов и укрепляет связи между ними во время рассуждений — прямо как люди. При этом она анализирует и делает выводы, а не просто повторяет выученную информацию.
Кажется, началось.
Запуск и управление контейнерами Docker
Изучите, как запускать контейнеры самых разных типов (серверы, базы данных, CLI-инструменты и т.д.), взаимодействовать с ними и сформировать чёткое понимание того, как Docker управляет вашими приложениями «под капотом».
Здесь: Docker 101: Run and Manage Containers
Изучите, как запускать контейнеры самых разных типов (серверы, базы данных, CLI-инструменты и т.д.), взаимодействовать с ними и сформировать чёткое понимание того, как Docker управляет вашими приложениями «под капотом».
Здесь: Docker 101: Run and Manage Containers
👍6
Pinokio AI — ставим ИИ-инструменты с GitHub в один клик:
— Установка нейронок, агентов и тулзов без ручной возни;
— Работает локально, без облака;
— Поддерживает инструменты для изображений, видео и аудио.
Заценить можно тут
— Установка нейронок, агентов и тулзов без ручной возни;
— Работает локально, без облака;
— Поддерживает инструменты для изображений, видео и аудио.
Заценить можно тут
🔥5👍3
Media is too big
VIEW IN TELEGRAM
MIT представили ИИ, который подстраивается под ваш мозг
NeuroChat считывает сигналы мозга с помощью датчика, встроенного в повязку Наруто, и тут же решает: стоит ли упростить объяснение, добавить деталей или сменить темп. Короче, меняет стиль ответов в зависимости от твоего уровня внимания и вовлечённости.
NeuroChat считывает сигналы мозга с помощью датчика, встроенного в повязку Наруто, и тут же решает: стоит ли упростить объяснение, добавить деталей или сменить темп. Короче, меняет стиль ответов в зависимости от твоего уровня внимания и вовлечённости.
👍5
Драма в двух актах:
Акт I. Британия вводит закон, по которому без скана паспорта нельзя войти ни в один онлайн-сервис.
Акт II. Спустя несколько месяцев партнёр Дискорда, проверявший документы, становится источником утечки: в сеть попадают данные ~70 000 пользователей вместе с фото их паспортов.
Discord уверяет, что виноват не он, а подрядчик, и что реальные цифры меньше, чем заявляют хакеры. Но ирония в том, что всё это случилось из-за закона, который должен был повысить безопасность.
еще одно хорошее напоминание, почему MAX нужно убрать подальше🤣 🤣
Акт I. Британия вводит закон, по которому без скана паспорта нельзя войти ни в один онлайн-сервис.
Акт II. Спустя несколько месяцев партнёр Дискорда, проверявший документы, становится источником утечки: в сеть попадают данные ~70 000 пользователей вместе с фото их паспортов.
Discord уверяет, что виноват не он, а подрядчик, и что реальные цифры меньше, чем заявляют хакеры. Но ирония в том, что всё это случилось из-за закона, который должен был повысить безопасность.
еще одно хорошее напоминание, почему MAX нужно убрать подальше
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥5
Media is too big
VIEW IN TELEGRAM
Создаём презентации за пару кликов — мощнейший сервис VoxDeck
Забудь про скучные шаблоны и долгую возню в PowerPoint. Сервис VoxDeck превращает промпт или документ в готовую презентацию за секунды:
— ИИ сам подбирает стиль, дизайн и картинки;
— Добавляет 3D-диаграммы и графику;
— Может даже сгенерировать цифрового аватара, который проведёт презентацию вместо тебя.
И самое главное — никаких лишних движений: загрузил текст → получил крутые слайды.
Бесплатно тестим тут
Забудь про скучные шаблоны и долгую возню в PowerPoint. Сервис VoxDeck превращает промпт или документ в готовую презентацию за секунды:
— ИИ сам подбирает стиль, дизайн и картинки;
— Добавляет 3D-диаграммы и графику;
— Может даже сгенерировать цифрового аватара, который проведёт презентацию вместо тебя.
И самое главное — никаких лишних движений: загрузил текст → получил крутые слайды.
Бесплатно тестим тут
👍4🔥4
VIM Master — браузерная игра, которая обучает основным действиям в Vim и командам редактирования с помощью коротких, целенаправленных уровней.
👍5
DocTR (распознавание текста в документах) — это удобная, высокопроизводительная и доступная библиотека для задач, связанных с распознаванием текста, на основе глубокого обучения.
👍6
Хотите сложных авторских статей? Не только новости и гайдики?
Накидайте реакций. Пойму, что это интересно и буду писать😱 😱
Накидайте реакций. Пойму, что это интересно и буду писать
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥10🗿3
Media is too big
VIEW IN TELEGRAM
Вышла Veo 3.1: теперь целая 1 минута видео и чистое 1080p😋
Ролики теперь не разваливаются: персонажи держат лицо и одежду, камера плывёт, сюжет тянется без дерганий. Было 8 секунд, стало 60 — плюс мультипромпты: даёшь несколько описаний, Veo склеивает их в единую сцену с переходами.
Доступ раскатывают в AI Studio, Vertex AI и Imagine with Google; уже добавили в flowith и Higgsfield. В Gemini обещают в течение месяца.
А пока ждём, можно насладиться бесплатным доступом к Veo-3 — здесь.
Ролики теперь не разваливаются: персонажи держат лицо и одежду, камера плывёт, сюжет тянется без дерганий. Было 8 секунд, стало 60 — плюс мультипромпты: даёшь несколько описаний, Veo склеивает их в единую сцену с переходами.
Доступ раскатывают в AI Studio, Vertex AI и Imagine with Google; уже добавили в flowith и Higgsfield. В Gemini обещают в течение месяца.
А пока ждём, можно насладиться бесплатным доступом к Veo-3 — здесь.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6🔥3
Ловите 100+ опенсорс клонов популярных сервисов, собранных в одном месте — Clone Wars.
Внутри есть все: от Notion и Spotify до YouTube и TikTok. Можно изучить архитектуру, используемые технологии, стащить идею для пет-проекта или просто понять, как устроены продукты мирового уровня.
Сохраняем😉
Внутри есть все: от Notion и Spotify до YouTube и TikTok. Можно изучить архитектуру, используемые технологии, стащить идею для пет-проекта или просто понять, как устроены продукты мирового уровня.
Сохраняем
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥3👍2👀1
Дорогие подписчики!
Мы берем короткую творческую паузу, чтобы тщательно продумать будущее канала. Мы хотим не просто публиковать посты, а создавать по-настоящему качественный и полезный для вас контент
Сейчас анализируем статистику, изучаем тренды и думаем над новым форматом, который позволит нам расти вместе с вами
Оставайтесь с нами-впереди много интересного! Следите за анонсами
Мы берем короткую творческую паузу, чтобы тщательно продумать будущее канала. Мы хотим не просто публиковать посты, а создавать по-настоящему качественный и полезный для вас контент
Сейчас анализируем статистику, изучаем тренды и думаем над новым форматом, который позволит нам расти вместе с вами
Оставайтесь с нами-впереди много интересного! Следите за анонсами
2🤝8
Всем привет, группа UnderCode 2.0 возвращается 06.11.
- Теперь в группе будет упор только на DevOps для новичков - 80% контента
- 10% про AI и другие 10% это новости и обзоры
- В группе будут экспертные статьи, разборы разных кейсов (практических), инцидентов
- Мини-курс для подписчиков, раз в неделю будет выходить статья по курсу с практикой, сделаем отдельный чат обсуждения практических работ, выходить начнет с 20.11,но чат появится до 9.11
- Теперь в группе будет упор только на DevOps для новичков - 80% контента
- 10% про AI и другие 10% это новости и обзоры
- В группе будут экспертные статьи, разборы разных кейсов (практических), инцидентов
- Мини-курс для подписчиков, раз в неделю будет выходить статья по курсу с практикой, сделаем отдельный чат обсуждения практических работ, выходить начнет с 20.11,но чат появится до 9.11
🔥13👍3🗿2
☸️ kubectl алиасы: как сэкономить время и не сойти с ума
Если ты работаешь с Kubernetes, ты наверняка уже понял, что команда kubectl любит длинные конструкции.
Каждый раз писать
удовольствие так себе.
Чтобы не тратить время, можно создать алиасы короткие команды, которые делают то же самое.
🧩 Простой пример
Вместо:
Можно написать алиас:
Теперь просто вводишь:
и видишь список подов.
Красота.
📦 Полезные алиасы для повседневной работы
Теперь, например, вместо:
ты пишешь:
🛠 Как добавить алиасы навсегда
Алиасы можно прописать в ~/.bashrc или ~/.zshrc:
Добавь туда все нужные строки с alias и сохрани.
Затем обнови сессию:
Теперь они будут работать всегда, даже после перезагрузки.
🔥 Бонус: готовый алиас-файл
Готовый alias-файл на GitHub
Можно просто скачать и подключить:
После этого у тебя появятся сотни полезных коротких команд вроде kgp, kdp, kga и других.
💡 Итог
Алиасы - мелочь, но экономят часы времени на вводе постоянных 3ех метровых команд :).
Если работаешь с Kubernetes каждый день - настрой один раз и забудь про длинные команды.
#DevOps #K8s #Beginer #Tips
Если ты работаешь с Kubernetes, ты наверняка уже понял, что команда kubectl любит длинные конструкции.
Каждый раз писать
kubectl get pods -n kube-system
удовольствие так себе.
Чтобы не тратить время, можно создать алиасы короткие команды, которые делают то же самое.
🧩 Простой пример
Вместо:
kubectl get pods -n kube-system
Можно написать алиас:
alias kgp="kubectl get pods"
Теперь просто вводишь:
kgp
и видишь список подов.
Красота.
📦 Полезные алиасы для повседневной работы
alias k="kubectl"
alias kgp="kubectl get pods"
alias kgs="kubectl get svc"
alias kgn="kubectl get nodes"
alias kaf="kubectl apply -f"
alias kdf="kubectl delete -f"
alias kctx="kubectl config use-context"
alias kns="kubectl config set-context --current --namespace"
Теперь, например, вместо:
kubectl apply -f deployment.yaml
ты пишешь:
kaf deployment.yaml
🛠 Как добавить алиасы навсегда
Алиасы можно прописать в ~/.bashrc или ~/.zshrc:
nano ~/.bashrc
Добавь туда все нужные строки с alias и сохрани.
Затем обнови сессию:
source ~/.bashrc
Теперь они будут работать всегда, даже после перезагрузки.
🔥 Бонус: готовый алиас-файл
Готовый alias-файл на GitHub
Можно просто скачать и подключить:
curl -s https://raw.githubusercontent.com/ahmetb/kubectl-aliases/master/.kubectl_aliases -o ~/.kubectl_aliases
source ~/.kubectl_aliases
После этого у тебя появятся сотни полезных коротких команд вроде kgp, kdp, kga и других.
💡 Итог
Алиасы - мелочь, но экономят часы времени на вводе постоянных 3ех метровых команд :).
Если работаешь с Kubernetes каждый день - настрой один раз и забудь про длинные команды.
#DevOps #K8s #Beginer #Tips
👍9🔥5
Всем привет, выхожу на связь. В связи с высокой нагрузкой запланированное не получилось. Следующая неделя должна быть последняя с высокой нагрузкой и активно начну пилить контент, прошу прощения.
Хочу делать интересные и качественные статьи, на них уходит много времени, а сейчас его попросту нет🥲
Хочу делать интересные и качественные статьи, на них уходит много времени, а сейчас его попросту нет
Please open Telegram to view this post
VIEW IN TELEGRAM
🤝12
Что на самом деле делает DevOps, а не как пишут во многих вакансиях❌
Если читать вакансии, DevOps это человек, который:
1️⃣Настраивает CI/CD
2️⃣Работает с Kubernetes
3️⃣Пишет Terraform
4️⃣Чинит серверы
5️⃣Дежурит ночью
и этот список можно продолжать практически до бесконечности. Не дохера ли всего делает 1 человек?
Звучит как суперспециалист. В реальности все проще и сложнее одновременно.
DevOps это не отдельная профессия. Это роль в команде. Хотя если быть прям на 100% честным это вообще Философия (можете почитать про это отдельно) в РФ и СНГ сложилось устоявшееся мнение DevOps-инженер, тут я придерживаюсь именно этой парадигмы. 😑
Если совсем просто:
DevOps отвечает за то, чтобы изменения в программе доходили до конечных пользователей продуктом. В наше время каждый занимается четко своим делом (в идеальном мире, да-да) разработчик разрабатывает, DevOps деплоит, тестировщик все ломает (шутка)
1️⃣Изменения это новый код.
2️⃣Момент, когда код уже работает для пользователей и генерирует полезную нагрузку, называется продакшен. Часто говорят просто прод. (Для тех кто не знал, что называют Продом)
3️⃣Про Деплой будет ниже, не бойтесь :)
Что DevOps делает на самом деле, DevOps в первую очередь следит за процессом.
1. Как изменения попадают к пользователям
Разработчик написал код.
Его нужно:
собрать
проверить
запустить на серверах
Этот процесс называется деплой.
Если деплой ручной и каждый раз разный, начинаются проблемы.
DevOps делает так, чтобы деплой был:
повторяемым
предсказуемым
без ручных действий
2. Как система работает после запуска
Когда программа уже запущена, важно понимать:
она вообще работает или нет, не тормозит ли не упала ли часть системы после внесения изменений в софт и так далее. (там все сложнее)
Для этого используют:
логи это записи о работе программы
метрики это цифры о нагрузке и состоянии
алерты это уведомления о проблемах
DevOps настраивает все это. Чтобы о проблеме узнавали быстро, а не от клиента или руководства.
3. Что будет если что то сломается
Любая система ломается.
Вопрос не если, а когда.
DevOps думает заранее:
что сломается первым
как быстро восстановить работу
кто получит уведомление
что делать по шагам
Это и есть инженерное мышление.
Чего DevOps обычно не делает
Но от него часто этого ждут.
DevOps обычно:
не пишет бизнес код
не заменяет разработчиков
не чинит все в одиночку
не обязан знать все технологии мира
Если в вакансии требуют все подряд, это не DevOps. Это признак хаоса в компании.
Почему DevOps часто крайний
DevOps находится между:
разработчиками
серверами
бизнесом
Если что то не работает:
Разработчики говорят: "Локально у нас все работало, задеплоили не дев и тест, там тоже ок, на проде чет свалилось, мы не знаем"
Бизнес спрашивает: "Почему простой и когда проблема будет устранена?"
И отвечать приходится DevOps. Не потому что мы виноваты или из-за нас что-то упало(такое тоже может быть, человеческий фактор еще никто не отменял). А потому что он видит всю картину.👀
Что важно понять новичку кто хочет погрузить в этот дивный и чудный мир:
DevOps это не набор инструментов. Это образ мышления, по другому и не скажешь. DevOps не только должен уметь думать как инженер, но еще и уметь разговаривать и доносить между командами правильно информацию, объяснять бизнесу простым языком сложные технические вещи и почему очередная "мудрая" вещь очередного "мудрого" Манагера полная хуита и не будет работать.
А так же, всегда должен уметь задавать вопросы себе, внутри команды, архитекторам и так далее при внедрение что либо нового в процесс.
как это будет работать у пользователей (если их это касается)
что будет если упадет (наша новая IMBA фича)
как мы узнаем о проблеме(хреново если с вертухи от Руководства)
как быстро восстановимся(Бекапы да, помним все про бекапы?)
Если есть это мышление, инструменты придут сами.
Что должен уметь DevOps
Разрабатывать и упрощать процессы
Делать систему стабильной
Помогать команде работать спокойно(пожалуй и очень часто для многих это самое сложное, а иногда это еще и самое важное)
Если читать вакансии, DevOps это человек, который:
1️⃣Настраивает CI/CD
2️⃣Работает с Kubernetes
3️⃣Пишет Terraform
4️⃣Чинит серверы
5️⃣Дежурит ночью
и этот список можно продолжать практически до бесконечности. Не
Звучит как суперспециалист. В реальности все проще и сложнее одновременно.
DevOps это не отдельная профессия. Это роль в команде. Хотя если быть прям на 100% честным это вообще Философия (можете почитать про это отдельно) в РФ и СНГ сложилось устоявшееся мнение DevOps-инженер, тут я придерживаюсь именно этой парадигмы. 😑
Если совсем просто:
DevOps отвечает за то, чтобы изменения в программе доходили до конечных пользователей продуктом. В наше время каждый занимается четко своим делом (в идеальном мире, да-да) разработчик разрабатывает, DevOps деплоит, тестировщик все ломает (шутка)
1️⃣Изменения это новый код.
2️⃣Момент, когда код уже работает для пользователей и генерирует полезную нагрузку, называется продакшен. Часто говорят просто прод. (Для тех кто не знал, что называют Продом)
3️⃣Про Деплой будет ниже, не бойтесь :)
Что DevOps делает на самом деле, DevOps в первую очередь следит за процессом.
1. Как изменения попадают к пользователям
Разработчик написал код.
Его нужно:
собрать
проверить
запустить на серверах
Этот процесс называется деплой.
Если деплой ручной и каждый раз разный, начинаются проблемы.
DevOps делает так, чтобы деплой был:
повторяемым
предсказуемым
без ручных действий
2. Как система работает после запуска
Когда программа уже запущена, важно понимать:
она вообще работает или нет, не тормозит ли не упала ли часть системы после внесения изменений в софт и так далее. (там все сложнее)
Для этого используют:
логи это записи о работе программы
метрики это цифры о нагрузке и состоянии
алерты это уведомления о проблемах
DevOps настраивает все это. Чтобы о проблеме узнавали быстро, а не от клиента или руководства.
3. Что будет если что то сломается
Любая система ломается.
Вопрос не если, а когда.
DevOps думает заранее:
что сломается первым
как быстро восстановить работу
кто получит уведомление
что делать по шагам
Это и есть инженерное мышление.
Чего DevOps обычно не делает
Но от него часто этого ждут.
DevOps обычно:
не пишет бизнес код
не заменяет разработчиков
не чинит все в одиночку
не обязан знать все технологии мира
Если в вакансии требуют все подряд, это не DevOps. Это признак хаоса в компании.
Почему DevOps часто крайний
DevOps находится между:
разработчиками
серверами
бизнесом
Если что то не работает:
Разработчики говорят: "Локально у нас все работало, задеплоили не дев и тест, там тоже ок, на проде чет свалилось, мы не знаем"
Бизнес спрашивает: "Почему простой и когда проблема будет устранена?"
И отвечать приходится DevOps. Не потому что мы виноваты или из-за нас что-то упало(такое тоже может быть, человеческий фактор еще никто не отменял). А потому что он видит всю картину.👀
Что важно понять новичку кто хочет погрузить в этот дивный и чудный мир:
DevOps это не набор инструментов. Это образ мышления, по другому и не скажешь. DevOps не только должен уметь думать как инженер, но еще и уметь разговаривать и доносить между командами правильно информацию, объяснять бизнесу простым языком сложные технические вещи и почему очередная "мудрая" вещь очередного "мудрого" Манагера полная хуита и не будет работать.
А так же, всегда должен уметь задавать вопросы себе, внутри команды, архитекторам и так далее при внедрение что либо нового в процесс.
как это будет работать у пользователей (если их это касается)
что будет если упадет (наша новая IMBA фича)
как мы узнаем о проблеме(хреново если с вертухи от Руководства)
как быстро восстановимся(Бекапы да, помним все про бекапы?)
Если есть это мышление, инструменты придут сами.
Что должен уметь DevOps
Разрабатывать и упрощать процессы
Делать систему стабильной
Помогать команде работать спокойно(пожалуй и очень часто для многих это самое сложное, а иногда это еще и самое важное)
Please open Telegram to view this post
VIEW IN TELEGRAM
🤝8🔥7👍3
Что должен уметь DevOps-новичок, чтобы не вылететь с испытательного 🤡
Короче, реальность такая: В вакансиях пишут 100500 стеков, а на деле тебя смотрят на живость мозга, ответственность и умение не срать под себя.
Вот что реально важно, а не то, что в требованиях.
📌 Не стек, а ожидания
Ты можешь не шарить в Kubernetes как бог, но если ты:
- понимаешь, зачем нужен деплой
- понимаешь, как работает CI/CD на базовом уровне
- можешь объяснить, что делает сервис простыми словами
- можешь разобраться в чужом коде или конфиге, прочитать документацию
- умеешь и не стесняешься задавать интересные, сложные вопросы
- это уже огромное преимущество.
Никто не ждет, что ты будешь экспертом во всём за 1 день.
Но реакция на проблему и способ мышления - это то, на что реально смотрят.
🗣 Коммуникация — это то, что цепляют в первую очередь
Звучит, как будто это про «Красиво говорить..».
Нет.
Это про то, чтобы ты мог:
- нормально объяснить, что случилось
- сказать «я не знаю, но сейчас разберусь»
- задать правильный вопрос, а не молчать
- донести до разработчика/бизнеса, свою идею, а так же отстаивать здравые идеи и не идти у всех на поводу (например объяснить почему деплой в пятницу идея говна кусок)
тебе очевидно, а они могут этого не понимать, им главное выкатить свежую фичу побыстрее..
Если ты тупишь, не изучаешь ничего и молчишь как рыба - прощай, испытательный.
✍️ Ответственность и документация
Тут всё просто:
- сломал - опиши, как починил
- накатил - запиши, как работает
- решил задачу - оставь след, чтобы другие могли повторить
Документация - не для галочки.
Она твоя страховка, когда что-то отваливается и все бегут с вопросами.
⚠️ Типичные причины увольнений
И вот за что реально сливают новичков:
🔥 игнорирование сообщений, тикетов, алертов
🔥 молчание, когда что-то сломалось
🔥 «Спорить и говорить я так всегда делал» вместо «Подумать и понять почему так делать плохо»
🔥 отказ читать логи/метрики, забить на мониторинг и надеется что сервис никогда не сдохнет..
🔥 недоразумения с командой из-за отсутствия коммуникации
Короче, если ты работаешь как скрипт - тебя выкинут.
Нужен живой инженер, который умеет думать, общаться и не боится ответственности.
🧠 Итог для тех, кто хочет остаться
DevOps это не про “настроил стек - и поехали”.
Это про:
✔️ думать как инженер
✔️ объяснять простыми словами сложное
✔️ брать ответственность
✔️ оставлять после себя след (документация)
✔️ не срать под себя, когда всё горит (стрессоустойчивость, кто не понял)
Если освоишь это - стек подтянется, проблемы станут задачами, а не ужасом.
#DevOps #UnderCode #Испытательный #IT #Начинающий
Короче, реальность такая: В вакансиях пишут 100500 стеков, а на деле тебя смотрят на живость мозга, ответственность и умение не срать под себя.
Вот что реально важно, а не то, что в требованиях.
📌 Не стек, а ожидания
Ты можешь не шарить в Kubernetes как бог, но если ты:
- понимаешь, зачем нужен деплой
- понимаешь, как работает CI/CD на базовом уровне
- можешь объяснить, что делает сервис простыми словами
- можешь разобраться в чужом коде или конфиге, прочитать документацию
- умеешь и не стесняешься задавать интересные, сложные вопросы
- это уже огромное преимущество.
Никто не ждет, что ты будешь экспертом во всём за 1 день.
Но реакция на проблему и способ мышления - это то, на что реально смотрят.
🗣 Коммуникация — это то, что цепляют в первую очередь
Звучит, как будто это про «Красиво говорить..».
Нет.
Это про то, чтобы ты мог:
- нормально объяснить, что случилось
- сказать «я не знаю, но сейчас разберусь»
- задать правильный вопрос, а не молчать
- донести до разработчика/бизнеса, свою идею, а так же отстаивать здравые идеи и не идти у всех на поводу (например объяснить почему деплой в пятницу идея говна кусок)
тебе очевидно, а они могут этого не понимать, им главное выкатить свежую фичу побыстрее..
Если ты тупишь, не изучаешь ничего и молчишь как рыба - прощай, испытательный.
✍️ Ответственность и документация
Тут всё просто:
- сломал - опиши, как починил
- накатил - запиши, как работает
- решил задачу - оставь след, чтобы другие могли повторить
Документация - не для галочки.
Она твоя страховка, когда что-то отваливается и все бегут с вопросами.
⚠️ Типичные причины увольнений
И вот за что реально сливают новичков:
🔥 игнорирование сообщений, тикетов, алертов
🔥 молчание, когда что-то сломалось
🔥 «Спорить и говорить я так всегда делал» вместо «Подумать и понять почему так делать плохо»
🔥 отказ читать логи/метрики, забить на мониторинг и надеется что сервис никогда не сдохнет..
🔥 недоразумения с командой из-за отсутствия коммуникации
Короче, если ты работаешь как скрипт - тебя выкинут.
Нужен живой инженер, который умеет думать, общаться и не боится ответственности.
🧠 Итог для тех, кто хочет остаться
DevOps это не про “настроил стек - и поехали”.
Это про:
✔️ думать как инженер
✔️ объяснять простыми словами сложное
✔️ брать ответственность
✔️ оставлять после себя след (документация)
✔️ не срать под себя, когда всё горит (стрессоустойчивость, кто не понял)
Если освоишь это - стек подтянется, проблемы станут задачами, а не ужасом.
#DevOps #UnderCode #Испытательный #IT #Начинающий
👍8🔥2💯2
Почему знание Kubernetes без Linux почти бесполезно 🤬
Ты можешь заучить все сущности k8s, понять Deploy/Service/Ingress, собрать Helm-чарты и всё равно в проде будешь ощущать себя как при попытке собрать шкаф без инструкции.
Почему?
Потому что Kubernetes это не отдельная магия, он построен на Linux. И если ты не шаришь за Linux K8s для тебя будет как дорогой автомобиль без двигателя.
Kubernetes - это обёртка над Linux 🐧
Под капотом K8s делает не какую-то особую магию.
Он просто рулит механизмами Linux, которые реально делают контейнеры возможными:
— Механизмы изоляции (namespaces) отделяют процессы друг от друга и дают каждому Pod свой процессный мир.
— Контроль ресурсов (cgroups) следит за CPU, памятью, диском чтобы один Pod не сожрал все доступные ресурсы.
— Сети, файловые системы и безопасность это всё Linux под капотом, а Kubernetes просто командует, как это использовать.
Именно поэтому в профессиональном мире часто говорят:
Kubernetes это просто Linux - но организованный и упакованный.
Без знаний Linux K8s выглядит как «чёрный ящик»
Вот что реально будет происходить, если ты игнорируешь изучение Linux:
Ты напишешь Pod манифест, он упадёт, а ты будешь тыкать kubectl logs и describe как попугай по кругу.
Но почему этот Pod упал?
Почему OOM-киллер его убил?
Почему kubelet не стартует?
Почему сеть не работает?
Ответы на эти вопросы лежат не в Kubernetes, а в том, как ядро Linux изолирует процессы и управляет ресурсами.
Где Kubernetes заканчивается, а Linux начинается
Kubernetes берет то, что есть в Linux, и организует это в кластер:
🔹 namespaces = изоляция процессов, сети и файловой системы, без которой контейнеры вообще были бы невозможны.
🔹 cgroups = реальное управление ресурсами для каждого контейнера.
🔹 OverlayFS (или иной слоистый FS) = механизм, на котором базируются контейнерные образы.
🔹 сетевые правила (iptables/nftables) = как пакеты текут внутрь и вне Pod-ов.
Без понимания этих штук Kubernetes просто магия, и ты будешь бесконечно дебажить:
“Почему у меня сеть не работает?”
“Почему контейнер съел всю память?”
“Почему kubelet упал?”
— потому что всё это Linux и его механизмы работы процессов, а не просто YAML-файлы.
Что учить в Linux, чтобы реально шарить в K8s
Не нужно становиться Linux-гуру за пару недель. Но эти темы точно должны быть в твоём базовом наборе:
Процессы и namespace
— понимать PID, как Linux изолирует процессы, откуда берется PID 1 в контейнере.
Ресурсы и cgroups
— зачем вообще limits/requests и как ядро на самом деле ограничивает CPU/память.
Сеть Linux
— как работает сеть на уровне узла, что такое network namespace и почему Pod-ы видят сеть по-другому.
Логи и система
— смотреть логи journalctl, понимать systemd unit файлы, видеть ошибки в kern.log и dmesg.
Немного честной правды
Kubernetes отлично автоматизирует многие вещи, но он не убирает Linux из уравнения.
Kubernetes просто автоматизирует то, что Linux уже умеет делать, и делает это в масштабе кластера.
Это значит:
✔️ ты можешь понимать YAML и Helm
✔️ но это не поможет, если ты не понимаешь, что происходит в узле под капотом
Понимание Linux переводит K8s из “черной магии” в предсказуемый инструмент, а не в рулетку для новичка.
Итог
Kubernetes это не отдельный мир.
Это обёртка над Linux, которая делает контейнеры управляемыми.
Если ты не шаришь за Linux —
ты будешь тыкать kubectl logs как слепой котёнок,
а проблемы будут повторяться, и ты будешь как белка в колесе 😅
Учишь Linux - Kubernetes перестаёт быть магией и становится инструментом под твоим контролем.
#DevOps #Linux #Kubernetes #UnderCode #ПроLinuxИK8s
Ты можешь заучить все сущности k8s, понять Deploy/Service/Ingress, собрать Helm-чарты и всё равно в проде будешь ощущать себя как при попытке собрать шкаф без инструкции.
Почему?
Потому что Kubernetes это не отдельная магия, он построен на Linux. И если ты не шаришь за Linux K8s для тебя будет как дорогой автомобиль без двигателя.
Kubernetes - это обёртка над Linux 🐧
Под капотом K8s делает не какую-то особую магию.
Он просто рулит механизмами Linux, которые реально делают контейнеры возможными:
— Механизмы изоляции (namespaces) отделяют процессы друг от друга и дают каждому Pod свой процессный мир.
— Контроль ресурсов (cgroups) следит за CPU, памятью, диском чтобы один Pod не сожрал все доступные ресурсы.
— Сети, файловые системы и безопасность это всё Linux под капотом, а Kubernetes просто командует, как это использовать.
Именно поэтому в профессиональном мире часто говорят:
Kubernetes это просто Linux - но организованный и упакованный.
Без знаний Linux K8s выглядит как «чёрный ящик»
Вот что реально будет происходить, если ты игнорируешь изучение Linux:
Ты напишешь Pod манифест, он упадёт, а ты будешь тыкать kubectl logs и describe как попугай по кругу.
Но почему этот Pod упал?
Почему OOM-киллер его убил?
Почему kubelet не стартует?
Почему сеть не работает?
Ответы на эти вопросы лежат не в Kubernetes, а в том, как ядро Linux изолирует процессы и управляет ресурсами.
Где Kubernetes заканчивается, а Linux начинается
Kubernetes берет то, что есть в Linux, и организует это в кластер:
🔹 namespaces = изоляция процессов, сети и файловой системы, без которой контейнеры вообще были бы невозможны.
🔹 cgroups = реальное управление ресурсами для каждого контейнера.
🔹 OverlayFS (или иной слоистый FS) = механизм, на котором базируются контейнерные образы.
🔹 сетевые правила (iptables/nftables) = как пакеты текут внутрь и вне Pod-ов.
Без понимания этих штук Kubernetes просто магия, и ты будешь бесконечно дебажить:
“Почему у меня сеть не работает?”
“Почему контейнер съел всю память?”
“Почему kubelet упал?”
— потому что всё это Linux и его механизмы работы процессов, а не просто YAML-файлы.
Что учить в Linux, чтобы реально шарить в K8s
Не нужно становиться Linux-гуру за пару недель. Но эти темы точно должны быть в твоём базовом наборе:
Процессы и namespace
— понимать PID, как Linux изолирует процессы, откуда берется PID 1 в контейнере.
Ресурсы и cgroups
— зачем вообще limits/requests и как ядро на самом деле ограничивает CPU/память.
Сеть Linux
— как работает сеть на уровне узла, что такое network namespace и почему Pod-ы видят сеть по-другому.
Логи и система
— смотреть логи journalctl, понимать systemd unit файлы, видеть ошибки в kern.log и dmesg.
Немного честной правды
Kubernetes отлично автоматизирует многие вещи, но он не убирает Linux из уравнения.
Kubernetes просто автоматизирует то, что Linux уже умеет делать, и делает это в масштабе кластера.
Это значит:
✔️ ты можешь понимать YAML и Helm
✔️ но это не поможет, если ты не понимаешь, что происходит в узле под капотом
Понимание Linux переводит K8s из “черной магии” в предсказуемый инструмент, а не в рулетку для новичка.
Итог
Kubernetes это не отдельный мир.
Это обёртка над Linux, которая делает контейнеры управляемыми.
Если ты не шаришь за Linux —
ты будешь тыкать kubectl logs как слепой котёнок,
а проблемы будут повторяться, и ты будешь как белка в колесе 😅
Учишь Linux - Kubernetes перестаёт быть магией и становится инструментом под твоим контролем.
#DevOps #Linux #Kubernetes #UnderCode #ПроLinuxИK8s
🔥5
В этом репозитории вы найдёте роадмап для изучения Kubernetes с нуля (от уровня новичка до продвинутого).
Внутри много ссылок на курсы, статьи, материалы по теме
Забираем на GitHub
Внутри много ссылок на курсы, статьи, материалы по теме
Забираем на GitHub
🔥9