Комментарии 24
Простите это собеседование для разработчика или DevOps`а?
Напишу сюда универсальный ответ на все подобные вопросы.
В ТРИЗ есть тезис о том, что при решении задачи нужно уметь подняться на один уровень выше и опуститься на один уровень ниже.
Аналогично и в разработке - при написании, например, веб сервиса, нужно уметь опуститься ниже (как работает ЯП под капотом, как оптимизировать циклы, как устроена работа с памятью (в первом приближении) и т.п.), и подняться выше (как взаимодействуют сервисы, как работают реплики сервиса и как избежать конфликтов, как происходит выкатка, и как сделать ее отказоустойчивой). Это все должен знать опытный разработчик, чтобы делать оптимальный дизайн приложения, хотя может напрямую аллоцировать память или писать blue-green деплой ему/ей не придется.
Например, понимание canary деплоймента важно при работе с базой данных - у вас в один момент могут быть развернуты реплики двух разных версий, соответственно модель БД должна уметь работать и со старой версией приложения, и с новой одновременно.
Другой пример - знание, что у вас развернут Istio (и что в нем есть retry и circuit breaker) позволит не велосипедить эти паттерны в приложении.
Обобщая, разработчику может и не будет нужно работать с кубом, особенно если в команде есть девопс-инженеры. Но знать примитивы и подходы очень полезно каждому, кто работает в такой среде, чтобы писать хорошие с точки зрения дизайна и отказоустойчивости приложения. Как и в случае с безопасностью, хороший "cloud-native" дизайн нельзя "прикрутить" потом - это нужно делать с самого начала разработки приложения (если речь не про PoC/MVP, где законно накостылить как получится). А для этого нужно иметь понимание обо всем окружении, с которым и в котором работает приложение, пусть и не быть в этом экспертом.
Ну тут не на один уровень, тут конкретно так вглубь. Конечно бессмысленно спорить, где проходит красная линия между ответственностью DevOps и даже каким-нибудь Senior Technical/Team Lead, каждый определит её в разном месте и будет отстаивать свой вариант. Но на мой взгляд вопросы типа:
Назовите главные компоненты архитектуры Kubernetes
Какая роль у контроллера DaemonSet?
это уже явный перебор для разработчика.
Вы вновь упускаете из виду, что статья не про то, "что должен знать разработчик", а про то, что могут спросить.
Меня спрашивали о таком, хоть и на senior позиции. Когда идешь на собеседование, хочется иметь набор знаний достаточной глубины, чтобы быть спокойным и не плавать, когда собеседующий решит углубиться в детали.
Стоит ли потратить 10 минут на чтение статьи, чтобы знать это, или стоит потратить их на ютуб - каждый решает для себя сам.
Да, нынче модно, молодежно знать devops разработчикам, ибо нет охоты devops инженера содержать...
Очень печальная тенденция (
Иронично, учитывая, что методология DevOps изначально предполагала перекрестное частичное погружение разработчиков в админство, а админов в разработку. То есть как раз понимание разработчиком, что там творится в среде, где его творению запускаться, а админом, что они в своей среде запускают.
А не отдельного инженера, который будет метаться между ними. Так что эта печальная тенденция, если она и есть — просто стремление к тому, что изначально закладывалось в термин.
Идеалогия:
зачем нам аналитик, разработчик, тестиррвщик, dba, админ, если нам нужен просто один ИТишник, который все это умеет.
А в качестае логичности поддтверждения: -разработчику проще понять заказчика без посредника (роль аналитика),
-разработчик сам может писать не только юнит тесты, но авто тесты, он же лучше понимает что он написал, зачем посредник (роль автотестера)
-разработчик сам должен контролировать выход фичи в прод, ведь он не тупо кодер, он должен понимать как его код будет работать в продовой инфраструктуре, и в конце концов, пока код не на проде, то и профита нет (роль девопса)
-разработчик должен знать не только селект, апдейт, инсерт и джойн, он должен представлять как оптимизировать, масштабировать бд, чтобы бд не стала узким горлышком, ведь там лежат его данные, которые он туда шлет, а значит лучше понимает нагрузку и прочее, зачем тут прослойка (роль dba)
Поддерживаю предыдущих ораторов.
Если вам нужен Куб (а как по мне лично - то и докер) - возьмите человека и не делайте мозг программистам. (Программист - это профессиональный водитель. Он посмотрит, что есть масло и бензин, но регулирование клапанов - это не к нему.)
Если человек дорого - ваш код в новомодных штутчках не нуждается.
Я, возможно, в своём лесу отстал от всех, но читаю "истории про васю-программиста" и вася в них виртуалки поднимает, балансировщики, интеграция, бла-бла-бла. А про код, который вася пишет - не слова. И толи код - само собой, толи - Вася вовсе не программист.
Если вам нужен Куб (а как по мне лично - то и докер) - возьмите человека и не делайте мозг программистам
В статье же написано "разработчик", а не "программист". Если кратко: программист это про программирование, разработчик же знает процесс разработки, в который входит и программирование, как один из инструментов. А еще, например, траблшутинг, умение понять задачи, аналитика и пр.
Во-вторых, не все работают на галерах, где гребцу дают "весло" (фреймворк) и куда грести (тикет с описанием функции). Встречал таких, кто 15 лет опыта имея за плечами, знают только как писать код, затрудняясь рассказать про работу с БД или про сетевые протоколы. Многие же приходят в продуктовые команды и на более интересные проекты, где нет "проторенной дорожки", и много RnD, и разработчик и код пишет, и контейнеры делает, и может в куб зайти и посмотреть, что там сломалось с его приложением.
В-третьих, это вроде как не про "что надо спрашивать на собеседовании", а "что надо отвечать". Спрашивают разное, в том числе часто спрашивают про кубер и контейнеры, пусть разработчику с ними вплотную не приходится потом работать. Меня много раз спрашивали на собесах.
Ну и в-четвертых, если вы придете в стартап на этапе, когда там меньше 10 человек, вы как раз будете тем Васей, который умеет все понемножку, и задеплоить в кубер может быть нужно в том числе.
По-моему дело в том, что многие разработчики оказались "скрытыми" девопсерами. Я знаю много девелоперов на позициях сеньор или техлид, которых просто прет от всей это контейнерно-деплойной темы, а от кода не прет вот вообще никак. В итоге ни там ни там на полную катушку не работают.
А потом смотришь на код неВась и удивляешься, почему неВася забыл про обратную совместимость, не учел что система распределенная и счетчики в памяти не будут работать корректно и т.д.
Знать != делать. Одно дело понимать как все приложение целиком работает и в каком из компонентов может быть проблема, к кому идти с этой проблемой. Другое настраивать с нуля с соблюдением best practice.
Да и работа программиста не текст набирать, а решения принимать.
Для этого есть Team Lead, Tech Lead, код-ревью, интеграционные тесты. Да и в конце концов запустить 2 контейнера одного приложения через docker compose тоже никто не мешает.
Но почему-то надо сразу из в крайности в крайность бросаться: либо у нас чувак, который не умеет свой основной фреймворк деплоить или он должен куб знать на уровне неплохого девопса.
У нас же каждый второй прнимает, что под капотом у nginx и изучает обновления ядра...
Сейчас почти все программисты - это формочки и json
Напомнило про разработчиков 1С, наверное кого-то задену но большинство разработчиков 1С могут развернуть кластер и написать программу, другое дело часто ли лезут разворачивать кластер для 1С. Статья интересная, по кубу, но лично мое это наверное больше для девопсов или админов.
Небольшие поправочки:
Мастер узел необязательно содержит etcd ноду. Все зависит от топологии кластера.
kubelet и kube-proxy компоненты не только рабочих узлов, они в том числе запускаются на master нодах.
Все так, правда kubelet не обязательно запускается на мастерах, контрол плейн вполне себе (и часто так делают) запускается в виде обычных процессов через systemd и подобные.
Более того, есть топологии, где компоненты контрол плейна запускаются на воркерах другого кластера Kubernetes, например так устроен Gardener.
Предисловие. А еще я как-то упустил что топик для разработчиков(думаю для разработки избыточно) и ответ писал для DevOps'ов =) ну, пусть уже будет.
Гайд в целом неплох, но ученика может запутать на мой взгляд:
основной вывод про виртуализацию многие упускают - ресурсы выртуализированных сред отделены друг от друга и неразделяемы. контейнеры к примеру могут использовать один и тот же адрес оперативной памяти, виртуальные машины - нет.
на мой взгляд акценты по значимости немного другие: масштабируемость, потом управляемость(сюда же входит и автоматизированный запуск), SasS
вообще это скорее к общему порядку относится, но в частности для начала неплохо было бы стросить что такое вообще докер, libvirt, kvm, cgroups. а можно ли контейнер запустить без демона docker?
kubelet работает не только на worker нодах, но и на master. кстати с него бы и начал - отправная точка для работы k8s, потом уже контроллеры.
лучше бы спросить чем конкретно отличается statefulset от deployment - фактически только порядком процесса запуска и именованием пода.
опять же, как и во всех ответах - не акцентировано внимание на результаты - в частности pvc создан для того чтобы защитить pv от удаления пока есть хотя бы один запрос на использование. неплохо было бы уточнить что вопрос про хранилище именно данных.
вообще неплохо было бы для начала спросить что вообще такое service. ClusterIP сам по себе не дает возможность публикации, к нему еще нужны какая-то прокся. LoadBalancer так же можно использовать как и ClusterIP, различие в том что при обращении к сервису он отдает либо один ip, либо список ip из которого выбирается уже балансировщиком целевой под. ни первый способ, ни второй сам по себе не позволит опубликовать сервис.
вводит в заблуждение - kubectl к примеру не упаковывает контейнеры.
тут уже у всех свои предпочтения, но я бы рекомендовал(так же и сисадмином помогало двигаться по OSI) начинать от начала к концу - точка входа, ингресс, сервис, под, состояние пода, логи пода, ресурсы от которых зависит приложение.
Вот список вопросов(как видите они довольно схожи, только я еще прошу знание linux - т.к. k8s можно обучить за месяц, а опыт работы с linux набирается годами и он критичен потому что k8s это прежде всего инструмент который помогает управлять основой - linux) которые я задаю на позицию ученика(к сожалению сейчас нет времени на запись и пояснение ответов. PS редактор текста в комментарии кажется очень неудобным):
Общие:
Что делает системный администратор?
Что делает devops?
Что такое GNU
Что такое линуксLinux:
чем отличается Unix и Linux
как происходит загрузка ОС что такое grub
что такое initd стадии initd
чем отличается пространство ядра и пространство пользователя?
демон systemd, команды systemctl, как создать сервис, как посмотреть журнал сервиса, что такое journalctl, как провести дебаг сервиса
компоненты процесса что такое PID, PPID, UID, GID и как их получить
команды top, htop что такое load average %Cpu(s): 7.3 us, 5.5 sy, 0.0 ni, 87.3 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st приоритет процесса, каким бывает, как установить, как узнать, oomkiller
файловая система как устроена файловая система, что такое inode, стандартные дирректории linux: /bin /boot /dev /etc /home /lib /opt /proc /root /tmp /usr /var, что такое df и ncdu
ACL как назначить права ,как сменить владельца, что такое cgroups
что такое rpm и yum, как посмотреть список установленных пакетов, как найти доступные пакеты в репозиториях, как установить репозиторий
GNU-Utils какими пользовались за последний год sed, awk, xargs, ls, find(и чем отличается от ls), grep, rm, move, tail, head, env, tee, curl, wget, tree
TCP/IP, уровни модели osi, что такое ip адрес, что такое маска сети, чем отличается TCP от UDP, netfilter и его компоненты, iptables и conntrack, что такое порт и сколько их может быть, команды ping, traceroute, tcpdump, netstat, nmap, telnet, netcat, что такое DNS? что такое nslookup
Docker
Что такое Dockerfile
что такое docker build
Расскажите о CMD и ENTRYPOINT в Dockerfile, чем отличаются
для чего используется multi-stage в Dockerfile
Что такое контейнер Docker
Назовите наиболее важные команды Docker
Что такое пространства имен в Docker
Как определить состояние контейнера Docker
Опишите функции и случаи применения Docker
Какие сети доступны по умолчанию в Docker
Приведите необходимые шаги для развертывания докеризированного приложения, сохраненного в репозитории Git
Если вы остановите контейнер — потеряете данные?
Как выполняется мониторинг Docker в производственных окружениях
Расскажите о ключевом различии между виртуализацией и контейнеризацией
Где хранятся тома DockerKubernetes
Что такое Kubernetes?
Расскажите об основных компонентах kubernetes
Чем полезна оркестровка контейнеров?
Как связаны Kubernetes и Docker?
Что такое node в Kubernetes?
Что такое pod в Kubernetes?
Что такое Kubernetes deployment?
Опишите набор действий необходимых для запуска deployment?
Объясните разницу между pod и deployment
Что такое service?
что такое namespace
что такое controller-manager
какие типы controller-manager вы знаете?(endpoints controller, service accounts controller, namespace controller, node controller, token controller, and replication controller)
для чего etcd в kubernetes?
что такое clusterIP?
что такое NodePort?
что такое kubelet?
что такое kube-proxy?
Если kubelet запущен на мастере (что необязательно), то этот мастер одновременно является воркером.
StatefulSet даёт важную гарантийную, что в любой момент времени у вас реплика my-pod-3 запущена на одном, и только на одном воркере. Если воркер сломается (например, kubelet станет недоступным), а там был под стейтфулсета, этот под ни за что не будет перезапущен на другом хосте, пока не будет восстановлена связь со сломанным хостом и контроллер не убедится, что на нём реплика больше не работает.
Список вопросов, пожалуй, утащу себе, спасибо!
Честно говоря считаю что такие базовые вещи, которые описаны в статье, о k8s, docker и абстракциях которые в них прячутся нужно знать не только DevOps-ам или разработчикам, но и проектным и продуктовым менеджерам.
Знать что такое k8s разработчику конечно нужно, но в общих чертах и понятия в какой среде исполняется его код, но странно задавать такие вопросы разработчику на собеседовании.
Если подразумевается, что в проекте разработчики сами «крутят» кубернетес, то тогда им нужно еще и про helm знать, или про kustomize и пайпланы уметь писать, или girops освоить, а так же уметь мониторинг настроить в k8s, сборку логов, наблюдаемость и тд. и тп. Но тогда им некогда будет код писать.
17 вопросов по Kubernetes, которые может услышать разработчик на собеседовании