Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Rakhmankulov/Interviews

BranchesTags

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

159 Commits
.github
.github
 
 
Architect section
Architect section
 
 
LLM and ML
LLM and ML
 
 
Linux basic questions
Linux basic questions
 
 
Python
Python
 
 
images
images
 
 
webapp
webapp
 
 
.gitignore
.gitignore
 
 
README.md
README.md
 
 

Repository files navigation

Вопросы к SRE/DevOps на интервью

Полезные ссылки

https://github.com/Tinkoff/career/blob/main/interview/README.md - IT собеседование в Тинькофф
https://learnk8s.io/production-best-practices - Kubernetes best practice
https://github.com/Swfuse/devops-interview/blob/main/interview.md - IT вопросы на собесе
https://www.opennet.ru/base/net/tcpdump_explore.txt.html - tcpdump
https://habr.com/ru/company/alexhost/blog/531170/ - tcpdump

Мои вопросы к интервьюеру

  • Эта позиция, на которую вы меня собеседуете - новая, или я заменю старого сотрудника? Чем не подошел старый сотрудник?
  • В какую команду вы меня берете и на какой проект?
  • Какие задачи решать и какую функцию я буду выполнять?
  • Как у вас построен процесс повышения грейдов и пересмотра зарплат?
  • На какой срок рассчитан этот проект?
  • Какие карьерные перспективы могут меня ждать в вашей компании?

Ответы на вопросы

DevOps практики

Этапы CI/CD

CI - Непрерывная интеграция:
1. План
2. Код
3. Сборка
4. Тест
CD - Непрерывная доставка:
1. Тест
2. Релиз
3. Развертывание
4. Поддержка и мониторинг

DevOps Practics

Двенадцать факторов приложения

12 факторов приложения — это набор принципов для разработки современных веб-приложений, которые обеспечивают их масштабируемость, надежность и простоту развертывания. Вот краткое описание каждого из 12 факторов:

  1. Кодовая база: Все приложения должны иметь одну кодовую базу, которая может быть развернута в нескольких средах (разработка, тестирование, продакшн).
  2. Зависимости: Явно объявляйте и изолируйте зависимости приложения, чтобы обеспечить воспроизводимость среды.
  3. Конфигурация: Храните конфигурацию в переменных окружения, а не в коде, чтобы упростить управление настройками для разных сред.
  4. Сервисы поддержки: Внешние сервисы (например, базы данных, очереди сообщений) должны быть подключены через конфигурацию, а не жестко встроены в код.
  5. Сборка, релиз, запуск: Четко разделяйте этапы сборки, релиза и запуска приложения для обеспечения стабильности и предсказуемости.
  6. Процессы: Приложение должно быть многопроцессным, а не монолитным, чтобы обеспечить масштабируемость и устойчивость.
  7. Порты: Приложение должно экспортировать сервисы через порты, а не через сокеты или другие механизмы.
  8. Параллельность: Приложение должно быть способно масштабироваться горизонтально путем запуска нескольких экземпляров.
  9. Быстрые стартап и остановка: Приложение должно быстро запускаться и корректно завершать работу, чтобы обеспечить надежность и удобство развертывания.
  10. Разделение разработки и продакшена: Разработка и продакшен должны быть четко разделены, чтобы предотвратить нежелательные изменения в продакшене.
  11. Логи: Приложение должно выводить логи в стандартный поток вывода, чтобы обеспечить централизованное управление логами.
  12. Административные процессы: Административные задачи (например, миграции баз данных) должны выполняться в среде, идентичной продакшену, чтобы обеспечить надежность и предсказуемость.

Linux

Динамическая маршрутизация и разные протоколы динамической маршрутизации, ebgp ibgp, константы bgp. На чём сейчас принято строить bgp-пиринги. Что такое blackhole.

  • Ответ

    Основные протоколы динамической маршрутизации:

    1. RIP (Routing Information Protocol) - один из старейших протоколов, использует алгоритм расстояния-вектора.
    2. OSPF (Open Shortest Path First) - протокол маршрутизации внутри автономной системы, использует алгоритм состояния канала.
    3. EIGRP (Enhanced Interior Gateway Routing Protocol) - протокол Cisco, сочетает в себе лучшие черты RIP и OSPF.
    4. BGP (Border Gateway Protocol) - протокол междоменной маршрутизации, используется для маршрутизации между различными автономными системами.

    автономные системы (AS) - это сети, управляемые одной или несколькими организациями и имеющие уникальный идентификатор AS. BGP позволяет обмениваться маршрутной информацией между этими системами.

    Принцип работы: Интернет состоит из множества Автономных Систем (AS). BGP обменивается информацией о доступности сетей между этими системами.
    Масштабируемость: Это единственный протокол маршрутизации, способный справляться с колоссальными таблицами маршрутов глобального интернета.
    Управление политиками: В отличие от внутренних протоколов (например, OSPF), BGP позволяет операторам сетей гибко настраивать правила: какой трафик принимать, а какой отклонять или передавать дальше.

    eBGP и iBGP

    eBGP (External BGP) и iBGP (Internal BGP) являются двумя вариантами протокола BGP:

    • eBGP используется для маршрутизации между различными автономными системами (AS). Обычно eBGP требует, чтобы маршрутизаторы были непосредственно соединены.
    • iBGP используется внутри одной автономной системы. Маршрутизаторы, использующие iBGP, могут быть соединены через другие маршрутизаторы, не участвующие в BGP.

    Константы BGP

    Константы BGP включают различные атрибуты и параметры, которые используются для выбора наилучшего пути. Некоторые из ключевых атрибутов:

    • AS_PATH - список AS, через которые проходит маршрут.
    • NEXT_HOP - следующий переходный узел, к которому должен обратиться маршрутизатор для достижения целевой сети.
    • LOCAL_PREF - предпочтение маршрута внутри AS; чем выше значение, тем предпочтительнее маршрут.
    • MED (Multi-Exit Discriminator) - атрибут, используемый для влияния на выбор входящего маршрута соседним AS.

    Построение BGP-пирингов

    Современные BGP-пиринги часто строятся на основе сетевых устройств, способных обрабатывать большие объемы маршрутизационной информации и поддерживать высокую производительность. Используются как физические, так и виртуальные маршрутизаторы. Важным аспектом является настройка безопасности пиринга, включая аутентификацию и фильтрацию маршрутов.

    Blackhole

    Blackhole в сетевых терминах — это механизм, используемый для преднамеренного "поглощения" трафика, который по какой-либо причине считается нежелательным или вредоносным. Трафик, направленный в blackhole, обычно отбрасывается, что помогает защитить сеть от DDoS-атак или избавиться от трафика к недоступным сервисам.

Команды дебага Linux

  lsof -p # поиск удаленных файлов, если процесс их еще держит
  numactl --hardware, -H # список номеров нод, разделенных запятыми, или диапазонов A-B, или всех.

  perf: # узнать сколько CPU использует каждая функция в программе
    CPU:
      perf top
      perf stat ls -e
      perf 
  /usr/bin/perf top -c 100

  strace # отслеживает системные вызовы
    strace -e trace=%network -p <PID> # смотреть сетeвые вызовы
    strace -f -p <PID> # посмотреть все дочерние процессы
    strace -e open -p <PID> # посмотреть все файлы, которые открывает процесс

  unshare # запуск программ в пространстве имен, не разделенном с родительским.
  ulimit -n # фиксит Too many open files
  opensnoop # следит за открытыми файлами
  dstat # сочетает в себе возможности iostat, vmstat, netstat и ifstat.
Докер:
  docker ps 

Ресурсы по ядру:
  syscalls https://man7.org/linux/man-pages/man2/syscalls.2.html
    The system call is the fundamental interface between an application and the Linux kernel.
Сетевые: 
  nslookup # DNS запросы
  tcpdump # можно проверить проходит ли пакет между хостами. Через wireshark можно посмотреть кто виноват, клиент или сервер. 
  tcpdump -A # посмотреть пакеты, если трафик не шифрованный
  tcpdump -ni any net 10.232.232.0/31 -AvX 
    -A # Печать каждого пакета (за вычетом заголовка уровня соединения) в формате ASCII. Удобно для захвата веб-страниц.
    -v # verbose
    -X # Печать данных каждого пакета в шестнадцатеричном формате и ASCII. 
  sudo ngrep -d any # сканить сетку

Чаще всего, программа работает медленно из-за:

  • CPU time;
  • Диска (много I/O операций);
  • Ожидания медленного сервера.

Mastering the mentioned tools: (strace, tcpdump, netstat, lsof, ngrep, etc)

IPIP over TCP или нет?

  • Ответ: Нет. TCP - L4, а IPIP и GRE-туннели — это туннели сетевого уровня (L3) модели OSI, при создании которых доступны IP-адреса обеих сторон. Они представляются в системе в виде интерфейсов GreX и IPIPX, и через них можно настраивать маршрутизацию (в том числе и default route) точно также, как и через любые другие интерфейсы.
    Плюс ко всему для этих интерфейсов можно настроить уровень доступа security level — private, protected или public
    IPIP (IP over IP) один из самых простых в настройке туннелей (инкапсулирует только unicast IPv4-трафик). Его можно настроить как на UNIX/Linux-системе, так и на различных маршрутизаторах (например, Cisco).

    В Kubernetes, IPIP-туннели могут использоваться в Calico, если кластер развернут в облаке, которое не поддерживает BGP. В этом случае Calico использует IPIP для инкапсуляции трафика между подами на разных узлах, обеспечивая их связь через оверлейную сеть.

Как OOM выбирает кого убивать?

  • Ответ: По приоритету. Приоритет в файле /proc/$PID/oom_adj. Сначала сдохнут свежие процессы пользователя с низким приоритетом, в последнюю очередь рутовые. Диапазон от -1000 (OOM Killer пройдет мимо) до 1000 (Процесс будет дохнуть в числе первых). fsnotify

Что такое UEFI?

  • Ответ: UEFI: новый BIOS
    Stage boot loader: синий экран загрузки, где можно задать Single mod. Представьте себе, и за знание таких терминов спрашивают. Еще бы спрашивали какой драйвер за вывод курсора на винде отвечает...

Что делает команда kill?

  • Ответ:

    Назначение команды kill - отправить определенный сигнал процессу. По умолчанию используется сигнал SIGTERM.

    А вот все сигналы можно глянуть через kill -l, они нужны для взаимодействия между процессами

    root@pentagon:~# kill -l
 1) SIGHUP       2) SIGINT       3) SIGQUIT      4) SIGILL       5) SIGTRAP
 6) SIGABRT      7) SIGBUS       8) SIGFPE       9) SIGKILL     10) SIGUSR1
11) SIGSEGV     12) SIGUSR2     13) SIGPIPE     14) SIGALRM     15) SIGTERM
16) SIGSTKFLT   17) SIGCHLD     18) SIGCONT     19) SIGSTOP     20) SIGTSTP
21) SIGTTIN     22) SIGTTOU     23) SIGURG      24) SIGXCPU     25) SIGXFSZ
26) SIGVTALRM   27) SIGPROF     28) SIGWINCH    29) SIGIO       30) SIGPWR
31) SIGSYS      34) SIGRTMIN    35) SIGRTMIN+1  36) SIGRTMIN+2  37) SIGRTMIN+3
38) SIGRTMIN+4  39) SIGRTMIN+5  40) SIGRTMIN+6  41) SIGRTMIN+7  42) SIGRTMIN+8
43) SIGRTMIN+9  44) SIGRTMIN+10 45) SIGRTMIN+11 46) SIGRTMIN+12 47) SIGRTMIN+13
48) SIGRTMIN+14 49) SIGRTMIN+15 50) SIGRTMAX-14 51) SIGRTMAX-13 52) SIGRTMAX-12
53) SIGRTMAX-11 54) SIGRTMAX-10 55) SIGRTMAX-9  56) SIGRTMAX-8  57) SIGRTMAX-7
58) SIGRTMAX-6  59) SIGRTMAX-5  60) SIGRTMAX-4  61) SIGRTMAX-3  62) SIGRTMAX-2
63) SIGRTMAX-1  64) SIGRTMAX

Для чего нужны сигналы? Какие сигналы используются чаще всего? (5 - 10 штук)

  • Ответ:

    Это уведомление процесса о наступившем событии. Также это способ взаимодйествия между процссами. SIGTERM (15) - запрос на "мягкое" завершение процесса.
    SIGKILL (9) - принудительное завершение процесса.
    SIGINT (2) - прерывание процесса. (Например нажатие Ctrl-C)
    SIGSTOP (10) - приостановка процесса.
    SIGCONT (18) - возобновить работу процесса.
    SIGHUP (1) - перезагрузка конфигурации (например, так можно сделать релоад конфига nginx)
    Сигналы SIGKILL и SIGSTOP нельзя перехватить, блокировать или игнорировать.

Что делает сигнал SIGHUP?

  • Ответ:

    SIGHUP: По умолчанию этот сигнал завершает работу программы, но многие демоны используют его для «мягкой» перезагрузки конфигурации без остановки

Какие сигналы не могут быть проигнорированы?

  • Ответ:

    SIGSTOP - принудительная остановка процесса
    SIGKILL - немедленное завершение процесса

Процессы и треды (шаринг ресурсов)

Процесс — это независимый контейнер ресурсов, содержащий собственную память, код и дескрипторы файлов.

Поток (тред) — это единица выполнения внутри процесса. В отличие от процессов, которые изолированы друг от друга, потоки разделяют общее адресное пространство. То есть, когда один поток изменяет ресурс процесса, это изменение сразу же становится видно другим потокам этого процесса.

DNS работает через TCP или UDP?

  • Ответ:

    Как правило, считается, что DNS использует UDP port 53, но TCP port 53 также зарезервирован под использование для DNS. То есть, (маленький тупой) рекурсивный сервер должен сначала пробовать выполнять DNS-запрос с использованием UDP, но при высокой вероятности большого и усеченного ответа (размер пакета превышает 512 байт), либо при наличии открытой TCP-сессии к запрашиваемому серверу (по которому обрабатывается другой запрос или запрос другого клиента), не возбраняется использование TCP. Подробнее тут

Методы мониторинга

  • RED Method:
    • Requests
    • Errors
    • Duration
  • 4 golden signals:
    • Задержка (Latency)
    • Трафик (Traffic)
    • Ошибки (Errors)
    • Насыщенность (Saturation)

Шифрование

  • Симметричное шифрование - один и тот же ключ используется и для кодирования, и для восстановления информации:
    • Шифр Цезаря, RSA
  • Асимметричное шифрование - данные шифруются открытым ключем, а расшифровываются приватным. И никакой магии. Примеры:
    • TLS, SSH.
  • mTLS добавляет возможность двусторонней аутентификации. Это означает, что не только клиент, но и сервер должны предоставить свидетельство своей подлинности при установлении защищенного соединения. Такое усиление аутентификации снижает риск атаки «человек посередине», когда злоумышленник пытается подставиться под сервер или клиента.

Сети

Здесь будут основные вопросы по сетям, которые задают на собеседованиях.

В чем разница между TCP и UDP?

  • Ответ:

    TCP – транспортный протокол (L4 OSI) передачи данных в сетях TCP/IP, предварительно устанавливающий соединение с сетью (SYN > SYN-ACK > ACK) и гарантирующий доставку данных. Используется для передачи таких данных как электронная почта, файлы, сообщения. При определении потери пакетов будет выполнен перезапрос потерянных пакетов. При нарушении порядка доставки пакетов TCP их порядок будет восстановлен.

    UDP – транспортный протокол (L4 OSI), передающий сообщения-датаграммы без установки соединения в IP-сети. Используется в потоковой передаче данных IPTV, VoIP. При потере пакетов перезапроса потерянных пакетов не происходит.

    В нашем мире каждый протокол используется для разных типов передачи трафика.

  • Ответ покороче:

    TCP перед передачей данных устанавливает связь между устройствами. Он выполняет трехэтапное рукопожатие. И при доставке пакета проверяет, дошел ли он до адресата. Если нет - отправляет повторно.
    UDP сразу отправляет данные, хендшейк не устанавливает. Возможна частичная потеря и несоблюдение порядка данных.

Что такое QUIC?

  • Ответ:

    QUIC (Quick UDP Internet Connections) — это транспортный протокол, разработанный Google, который работает поверх UDP. Он предназначен для улучшения производительности веб-приложений и уменьшения задержек при установлении соединений. QUIC объединяет функции TCP и TLS, обеспечивая надежную передачу данных и шифрование в одном протоколе. Основные преимущества QUIC включают:

    1. Быстрое установление соединения: QUIC использует 0-RTT (Zero Round Trip Time) для повторных соединений, что позволяет сократить время ожидания.
    2. Улучшенная производительность: QUIC снижает задержки и повышает скорость передачи данных за счет оптимизации управления потоками и устранения проблем с блокировкой головы очереди.
    3. Встроенное шифрование: QUIC обеспечивает безопасность данных с помощью встроенного TLS 1.3, что делает его более безопасным по сравнению с традиционными протоколами.
    4. Поддержка мультиплексирования: QUIC позволяет грузить сразу несколько объектов веб-страницы.

Как TCP устанавливает соединение?

  • Ответ:

tcp-con-img

Установка TCP-соединения — это процесс «трехстороннего рукопожатия» (3-way handshake). Он гарантирует надежную связь: клиент и сервер синхронизируют номера пакетов и подтверждают готовность.

Этот процесс состоит из трех шагов:

  • SYN (Synchronize): Клиент отправляет серверу пакет с установленным флагом SYN и своим начальным порядковым номером.
  • SYN-ACK (Synchronize-Acknowledge): Сервер принимает запрос, отвечает пакетом с флагами SYN + ACK, подтверждая получение первым пакетом (номер клиента + 1) и отправляя свой порядковый номер.
  • ACK (Acknowledge): Клиент получает ответ, выделяет ресурсы для связи и отправляет серверу пакет с флагом ACK (номер сервера + 1). Соединение установлено, начинается передача данных.

Как происходит TLS Handshake?

  • Ответ:

tls-handshake-img

TLS-рукопожатие происходит после того, как с помощью TCP-рукопожатия было установлено TCP-соединение.

  1. Клиент отправляет ClientHello, в котором сообщает список алгоритмов шифрования, которые он поддерживает.
  2. Сервер отвечает ServerHello, выбирая версию TLS, набор шифров, отправляя свое случайное число и публичную часть сертификата, и может запросить сертификат клиента (если требуется двусторонняя аутентификация).
  3. Клиент проверяет сертификат сервера, используя доверенные центры сертификации. Если сертификат действителен, клиент генерирует сеансовый ключ, шифрует его открытым ключом сервера и отправляет обратно.
  4. Сервер расшифровывает сеансовый ключ с помощью своего приватного ключа. Теперь и клиент, и сервер имеют общий сеансовый ключ.
  5. Клиент и сервер отправляют друг другу сообщения Finished, подтверждая успешное завершение рукопожатия. После этого начинается защищенная передача данных с использованием симметричного шифрования на основе сеансового ключа.

Фишка в том что публичным ключом можно только зашифровать, а расшифровать можно только приватным. Поэтому клиент шифрует сеансовый ключ публичным ключом сервера, а сервер расшифровывает его своим приватным ключом.

Что такое SNI?

  • Ответ:

    SNI (Server Name Indication) — это расширение протокола TLS, которое позволяет клиенту указывать имя хоста, к которому он пытается подключиться, во время установления TLS-соединения. Это особенно важно для серверов, которые обслуживают несколько доменов на одном IP-адресе (виртуальный хостинг). SNI позволяет серверу выбрать правильный сертификат для конкретного домена, обеспечивая безопасное соединение для каждого клиента.

Что такое mTLS?

  • Ответ:

    mTLS (Mutual Transport Layer Security) — это расширение протокола TLS, которое обеспечивает двустороннюю аутентификацию между клиентом и сервером. В отличие от стандартного TLS, где только сервер предоставляет свой сертификат для аутентификации, в mTLS оба участника (клиент и сервер) обмениваются сертификатами. Это позволяет не только клиенту убедиться в подлинности сервера, но и серверу проверить подлинность клиента. mTLS можно использовать, например, в Kubernetes.

Что такое маска подсети и CIDR?

  • Ответ:

    IP-адрес - это 32 бита. Формула для расчета количества IP-адресов на основе префикса CIDR: $$N = 2^{(32 - P)} - 2$$

    где:

    • N — количество полезных IP-адресов, которые можно присвоить устройствам.
    • 32 — общее количество бит в адресе IPv4.
    • P — префикс CIDR (число после косой черты, например, 24 в сети /24).
    • 2 — исключение двух обязательных служебных адресов:
      • Адрес сети (первый адрес подсети).
      • Широковещательный адрес (Broadcast, последний адрес подсети).

Назовите все уровни OSI

  • Ответ: osi-model-img

Как диагностировать доступность порта и сервиса?

На сервере:

  1. А сервис вообще запущен?
  # НА ХОСТЕ
  netstat -tulnp | grep <port_number>
  # ИЛИ 
  ss -tulnp | grep <port_number>
  # ИЛИ
  systemctl status <service_name>
  1. Фаервол не режет порт?
  # НА ХОСТЕ
  iptables -n -v -L| grep <port_number>
  # ИЛИ
  ufw status | grep <port_number>
  1. В облаке проверить настройки Security Group (AWS) или NSG (Azure) или Firewall (GCP)

На клиенте:

  1. Проверить доступность
  # НА КЛИЕНТЕ
  nc -zv <host> <port_number>
  # ИЛИ
  telnet <host> <port_number>

Тут для telnet:

  • CONNECTED - порт доступен, все хорошо
  • TRYING - пакеты дропаются по пути
  • CONNECTION REFUSED - порт закрыт, но хост доступен

Для https можно использовать curl -v https://<host>:<port_number>
Тут будет видно:

  • DNS резолвинг
  • TCP соединение
  • TLS рукопожатие
  • HTTP запрос и ответ

Если запрос от клиента не доходит до сервера, можно использовать traceroute или mtr, чтобы понять где теряются пакеты.

  # НА КЛИЕНТЕ
  traceroute <host>
  # ИЛИ
  mtr <host>

Что такое DNS и какие типы записей бывают?

  • Ответ:

    DNS (Domain Name System) — распределённая база данных, переводящая доменные имена (например, google.com) в IP-адреса (142.250.185.78).

    Основные типы DNS-записей

    Тип Назначение
    A IPv4-адрес домена
    AAAA IPv6-адрес домена
    CNAME Алиас (перенаправление на другой домен), например, www.google.com → google.com
    MX Почтовые серверы
    NS DNS-серверы домена
    TXT Текстовые данные (SPF, DKIM, верификации)
    PTR Обратная запись (IP → домен)
    SOA Параметры зоны (авторитетный сервер, TTL)
    SRV Сервисные записи (порт, приоритет)
    CAA Разрешённые центры сертификации (SSL)

Какие бывают HTTP-статус-коды?

  • Ответ:

    1xx (Информационные): Запрос получен, продолжается обработка.
    2xx (Успешные): Запрос успешно обработан.
    3xx (Перенаправления): Необходимы дополнительные действия для завершения запроса.
    4xx (Ошибки клиента): Ошибка на стороне клиента (например, неверный запрос).

    Ошибка Значение Пояснение
    400 Bad Request Кривый запрос
    401 Unauthorized Неавторизован
    403 Forbidden Аворизован, но нет прав
    404 Not Found Файл или ресурс не найден
    405 Method Not Allowed Метод не поддерживается
    429 Too Many Requests Слишком много запросов (rate limit)

    5xx (Ошибки сервера): Ошибка на стороне сервера (например, сервер не может обработать запрос).

    Ошибка Значение Пояснение
    500 Internal Server Error Внутренняя ошибка сервера (что-то просто упало)
    502 Bad Gateway Прокси не достучался до бэкенда
    503 Service Unavailable Сервис перегружен
    504 Gateway Timeout Прокси не дождался ответа от бэкенда (таймаут)

Что происходит, когда вы вводите адрес в браузере?

  • Ответ:

    1. DNS-резолвинг: Браузер проверяет локальный (свой) кэш DNS, затем обращается к DNS-серверу для получения IP-адреса домена.
    • Кэш браузера
    • Кэш ОС
    • /etc/hosts
      • DNS провайдера
        • Корневые DNS-серверы
          • DNS-серверы зоны (.com, .org, .net)
            • DNS-серверы домена (например, ns1.google.com)
    1. Установка TCP-соединения: Браузер инициирует TCP-соединение с сервером по полученному IP-адресу (3-way handshake).
    2. TLS Handshake: Если используется HTTPS, происходит TLS-рукопожатие для установления защищенного соединения.
    3. HTTP-запрос: Браузер отправляет HTTP-запрос на сервер (например, GET /index.html).
    4. Обработка запроса сервером: Сервер обрабатывает запрос и формирует HTTP-ответ.
    5. HTTP-ответ: Сервер отправляет ответ обратно браузеру, включая статус-код, заголовки и тело ответа (например, HTML-код страницы).
    6. Рендеринг страницы: Браузер получает ответ, парсит HTML, CSS и JavaScript, загружает необходимые ресурсы (изображения, скрипты) и отображает страницу пользователю.

Контейнеризация

Контейнеры в Linux

Контейнеры = Linux namespaces + cgroups + chroot + capabilities (Seccomp)

  • Namespaces изолируют различные ресурсы между процессами, чтобы они не "видели" друг друга
    Механизмы контейнеризации: namespaces

    Namespaces состоят из:

    Тип Что изолирует
    PID PID процессов
    NETWORK Сетевые устройства, сетки, порты и т.п.
    USER ID Пользовательские идентификаторы (UID/GID)
    MOUNT Точки монтирования (контейнер видит только свою файловую структуру)
    UTC Изоляция имени хоста и доменного имени
    IPC Изоляция систем межпроцессного взаимодействия (например, разделяемая память)

  • Сgroups (Control Groups) ограничивают, учитывают и изолируют использование ресурсов (CPU/Memory/Disk/Network)

    Ресурс Пример использования
    CPU Ограничение использования процессорного времени
    Memory Задание лимитов на использование памяти
    Disk I/O Контроль скорости чтения/записи на диск
    Network Ограничение пропускной способности сети

    Cgroups предотвращают ситуацию, когда один контейнер потребляет все ресурсы хоста. Вот как они это делают:

  • Ограничение ресурсов - можно определить сколько CPU или памяти будет использовать конкретный процесс

  • Приоритизация – cgroups позволяют определить какой процесс в рамках одной cgroup более приоритетен для использования ресурсов

  • Отчетность - лимиты ресурсов мониторятся и сообщаются на уровне cgroup

  • Управление - можно изменить статус (frozen, stopped, restarted) всех процессов cgroup одной командой

  • Chroot — операция изменения корневого каталога диска для запущенного процесса и его дочерних процессов. Программа, запущенная в таком окружении, не может получить доступ к файлам вне нового корневого каталога. Это измененное окружение называется chroot jail.

  • Seccomp (сокращение от secure computing) — механизм ядра Linuх, позволяющий процессам определять системные вызовы, которые они будут использовать. Если злоумышленник получит возможность выполнить произвольный код, seccomp не даст ему использовать системные вызовы, которые не были заранее объявлены.

Итоговая структура контейнера:

  1. Файловая система (основана на UnionFS, включает слои образов).
  2. Процессы (изолированы с помощью namespaces).
  3. Ресурсы (управляются через cgroups).
  4. Сеть (виртуальная, изолированная через net namespace).
  5. Конфигурация (переменные окружения, монтирование томов, настройки сети).

Контейнеры не включают ядро операционной системы — они используют ядро хоста, что делает их лёгкими и быстрыми по сравнению с виртуальными машинами.

Что такое Kata Container

Это технология с открытым исходным кодом, которая создает легкие виртуальные машины, работающие и выглядящие как обычные контейнеры.

Kata Containers объединяют преимущества контейнеров и виртуальных машин (VM). Они обеспечивают более высокий уровень изоляции и безопасности для приложений, сохраняя при этом лёгкость и скорость работы контейнеров. Если обычные контейнеры используют стандартные механизмы контейнеризации Linux, у Kata Containers используются QEMU, KVM.

Контейнер на стероидах. Больше для безопасности придумано.

Что такое copy on write

Принципы работы OverlayFS:

  1. Чтение файлов:
    - OverlayFS сначала ищет файл в верхнем слое.
    - Если файл найден, он используется.
    - Если файла нет в верхнем слое, он читается из нижнего слоя.
  2. Запись файлов (Copy-on-Write):
    - OverlayFS не изменяет файлы в нижнем слое, так как он read-only.
    - При изменении файла из нижнего слоя:
    • Файл копируется в верхний слой (это называется Copy-on-Write).
    • Изменения применяются только к копии в верхнем слое.
  3. Удаление файлов:
    - OverlayFS не удаляет файлы из нижнего слоя.
    - Вместо этого в верхнем слое создаётся запись, отмечающая файл как "удалённый" (Whiteout File).
  4. Создание новых файлов:
    - Новые файлы и каталоги создаются только в верхнем слое.

Docker

50 вопросов по Docker, которые задают на собеседованиях, и ответы на них

Что такое Docker и какие инструменты Linux лежат в его основе? Для чего он используется?

  • Ответ

    Docker базируется на технологиях namespaces, cgroups, capabilities, overlayfs

    • namespaces - обеспечивает изоляцию процессов. Например, можно айдишники процессов разместить в разных контейнерах.
    • cgroup - ограничивают и управляют использованием ресурсов (CPU, память, дисковый ввод/вывод), которые контейнеры могут потреблять.
    • capabilites - штука, которая позволяет дать некоторые root привелегии процессам или исполняемым файлам. Например, изменить UID процесса на 0, или дать возможность монтировать файловые системы.
    • overlay (overlayFS, overlay2-драйвер) - файловая система, которая умеет работать "слоями". Не сохранять каждый раз новые файлы, а наслаивать один слой с конкретными изменениями конкретного файла на другой, тем самым экономя место на диске и время создания контейнера.

    А вот Docker - это уже штука, которая всеми этими технологиями рулит. Да ещё и удобным для нас образом.

Компоненты докера

1. **Docker Daemon** — тот самый Container Engine. Запускает контейнеры.
2. **Docker CLI** — утилита по управлению Docker Daemon.
3. **Dockerfile** — инструкция по тому, как собирать образ.
4. **Image** — образ, из которого раскатывается контейнер.
5. **Container** - запущенный экземпляр образа — изолированная среда выполнения.
6. **Docker registry** — хранилище образов.

docker-basic-img

На **DOCKER_HOST** работает **Docker daemon**, запускает контейнеры. Есть **Client** (Docker CLI), который передаёт команды: *собери образ*, *скачай образ*, *запусти контейнер*. **Docker daemon** ходит в **Registry** и выполняет их. **Docker CLI** может обращаться и локально (к unix-сокету), и по TCP с удалённого хоста.

**Docker Daemon** (демон) — это серверная часть, она работает на хост-машине: скачивает образы и запускает из них контейнеры, создаёт сеть между контейнерами, собирает логи. Когда мы говорим «создай образ», этим тоже занимается демон.

**Docker CLI** — клиентская часть Docker, консольная утилита для работы с демоном. Повторю, она может работать не только локально, но и по сети.

Docker Building best practises

Официалная документация

  1. Использовать multi-stage билды
  2. Создавать переиспользуемые стейджи
  3. Выбор оптимальных базовых образов
  4. Регулярная пересборка образов с обновленными зависимостями
  5. Использовать --pull в команде docker build для загрузки более новой базовой версии: 
    docker build --pull -t my-image:my-tag .
  6. Использовать параметр --no-cache для чистой сборки: 
     docker build --pull --no-cache -t my-image:my-tag .
  7. Настроить исключения файлов с помощью .dockerignore
  8. Создание эфемерных контейнеров (легко и быстро пересоздаваемых)

Docker полный путь старта контейнера

  1. Когда я выполняю docker run hello-world, Docker client отправляет запрос в Docker daemon по API.
  2. Daemon проверяет, есть ли образ локально, и если нет — скачивает его из registry.
  3. Далее Docker daemon через containerd создаёт контейнер: настраивает namespaces, cgroups, файловую систему и через OCI runtime (runc) запускает процесс контейнера.
  4. Stdout/stderr процесса передаются обратно через Daemon в Docker client (Docker CLI), который выводит результат в терминал.

Docker multi-stage builds

При многоэтапной сборке вы используете несколько операторов FROM в вашем Dockerfile. Каждая инструкция FROM использует произвольный базовый образ и начинает новый этап сборки. Вы можете выборочно копировать артефакты с одного этапа на другой, оставляя только то, что вам необходимо в конечном образе. Пример как это работает:

Dockerfile:

FROM golang:1.7.3
WORKDIR /go/src/github.com/alexellis/href-counter/
RUN go get -d -v golang.org/x/net/html  
COPY app.go .
RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o app .

FROM alpine:latest  
RUN apk --no-cache add ca-certificates
WORKDIR /root/
COPY --from=0 /go/src/github.com/alexellis/href-counter/app . # тут вся фишка
CMD ["./app"]

Теперь вам нужен только один Dockerfile. Более того, вам больше не нужен и отдельный скрипт сборки. Просто запустите сборку образа привычной командой.

docker build -t ivanovii/href-counter:latest .

В итоге, вы получаете крошечный образ. Фишка в том, что вам не нужно извлекать промежуточные артефакты на вашу локальную систему.

Как это работает? Вторая команда FROM начинает новый этап сборки с базового образа alpine:latest. Инструкция COPY --from=0 копирует артефакты с предыдущего этапа сборки на текущий этап, благодаря чему необходимые для сборки Go SDK и любые промежуточные артефакты не сохраняются в конечном образе.

Kubernetes

Компоненты Kubernetes

k8s

Компоненты контура управления Kubernetes

  • Kube-apiserver:
    • представляет API Kubernetes;
    • умеет в горизонтальное масштабирование;
    • на OpenAPI (OpenAPI - это cпецификация), на архитектуре REST.
  • etcd:
    • Распределённая и высоконадёжная БД в формате "ключ-значение", основное хранилище всех данных кластера в Kubernetes.
  • kube-scheduler:
    • отслеживает созданные поды без привязанного узла (ноды) и выбирает узел, на котором они должны работать;
    • назначает поды согласно требованиям к ресурсам, ограничениям, связанным с аппаратными/программными политиками, принадлежности (affinity) и непринадлежности (anti-affinity) узлов/подов, местонахождению данных, предельным срокам отклика.
  • kube-controller-manager (куча контроллеров в одном бинаре):
    • Node Controller: уведомляет и реагирует на сбои узла;
    • ReplicationController: старая, изначальная технология, сейчас этой балалайки в k8s нет;
    • ReplicaSets Controller: поддерживает правильное количество подов для каждого объекта ReplicaSets в системе. У него нет rolling-update, как у предшественника. Вот по этому появился Deployment, он абстракция над ReplicaSets, добавляет функционал rolling-update/rollback. Костыли. Кругом костыли;
    • Endpoints Controller: заполняет объект узлов (Endpoints), то есть связывает сервисы (Services) и поды (Pods);
    • Account & Token Controllers: создают стандартные учетные записи и токены доступа API для новых пространств имен.

Контроллер - это асинхронный скрипт, который работает над согласованием текущего состояния системы Kubernetes с желаемым состоянием. Полезно думать о кубелете как о контроллере! Он запрашивает Pods из kube-apiserver каждые 20 секунд (это настраивается), фильтруя те, чье NodeName совпадает с именем узла, на котором запущен kubelet. Получив этот список, он обнаруживает новые добавления, сравнивая их с собственным внутренним кэшем, и начинает синхронизировать состояние, если имеются какие-либо расхождения.

Компоненты worker-ноды Kubernetes

  • kubelet:
    • следит за тем, чтобы контейнеры были запущены в поде;
    • принимает набор PodSpecs, и гарантирует работоспособность и исправность определённых в них контейнеров;
    • если Pod создается, он регистрирует некоторые метрики запуска, в Prometheus для отслеживания Pod;

У пода бывает несколько статусов: Pending, Running, Succeeded, Failed and Unknown. Когда Pod запускается впервые, Kubelet вызывает команду удаленной процедуры RunPodSandbox (RPC). "Песочница" - это термин CRI для описания набора контейнеров, который в языке Kubernetes, как вы догадались, является Pod.

  • kube-proxy:
    • конфигурирует правила сети на узлах (iptables). При помощи них разрешаются сетевые подключения к вашим подам изнутри и снаружи кластера;

kube-proxy использует уровень фильтрации пакетов в операционной системы, если он доступен. В противном случае, kube-proxy сам обрабатывает передачу сетевого трафика.

Kubectl apply manifest - что происходит после этой команды (коротко)?

  • валидация манифеста на стороне kubectl (client-side) и затем на kube-apiserver (server-side);
  • kubectl идет в kube-apiserver на мастер-ноду, проходя при этом аутентификацию, авторизацию и admission control;
  • kube-apiserver десериализует манифест и записывает объект в etcd;
  • controller-manager смотрит на kube-apiserver через informers/watches и создает необходимые объекты (напр., ReplicaSet для Deployment);
  • kube-scheduler получает уведомление о новых подах без привязки к ноде, подбирает подходящую ноду и устанавливает nodeName у пода;
  • на воркер-ноде kubelet синхронизирует состояние подов через CRI (Container Runtime Interface) — containerd, cri-o или docker;
  • CRI runtime создает контейнеры, CNI прокидывает сетевой интерфейс в pod, запускаются lifecycle hooks;

Kubectl apply manifest - что происходит после этой команды (развернуто)?

Источник

1. Действия внутри kubectl (на стороне клиента)

  • Валидация и генераторы:
    • kubectl проводит валидацию на стороне клиента, не отправляя никаких запросов
    • kubectl формирует HTTP запрос, который будет отправлен на kube-apiserver
    • kubectl также выяснит, нужны ли какие-либо действия, например, запись команды (для роллоута или аудита), или же эта команда просто "--dry-run".
  • API groups and version negotiation:
    • k8s использует REST архитектуру и протокол OpenAPI. Другими словами, API у кубера не монолитное и имеет много отдельных ресурсов. Собственно, выбирается нужный. Все ресурсы можно посмотреть командой kubectl api-resources
    • у k8s версионированный API (v1, v1beta1, v1alpha1, apps/v1 и т.д.), kubectl выбирает подходящую версию для ресурса
  • Аутентификация пользователя/клиента:
    • Для аутентификации нужен kubeconfig
    • Аутентифицироваться в k8s можно по сертификату, Bearer токену, имени пользователя/паролю, через OpenID токен

2. HTTP запрос отправляется на Kube-apiserver
Kube-apiserver - это главный интерфейс, через который клиенты и элементы контролплейна рулят нашим кластером.

  • Аутентификация:
    • Kube-apiserver должен убедиться, что запрашивающий является тем, за кого себя выдает. В зависимости от опциий запуска будет проверка что HTTP-запрос закодирован ключом TLS, подписанным корневым сертификатом CA, или проверит токен, или проверит что учетные данные HTTP-запроса соответствуют его собственному локальному состоянию.
  • Авторизация:
    • Например, через RBAC роль, настроенную админом.
  • Admission control: (контроллеры допуска (последний бастион контроля перед сохранением объекта в etcd)):

    они бывают всякими, например, resource management, security, defaulting, and referential consistency examples of admission controllers resource management.

    • InitialResources устанавливает ограничения ресурсов по умолчанию для ресурсов контейнера на основе прошлого использования;
    • LimitRanger накладывает верхние границы на определенные ресурсы (не более 2 ГБ памяти, по умолчанию 512 МБ);
    • ResourceQuota подсчитывает и запрещает количество объектов (pods, rc, балансировщики нагрузки сервисов) или общее количество потребляемых ресурсов (cpu, память, диск) в пространстве имен.

3. После создания объекта, Kubernetes будет следить за существованием объекта

  • ETCD:
    Здесь, наконец, kube-apiserver десериализует HTTP-запрос (inverse process of kubectl's generators) и записывает наши объекты в БД, такие как:
    • Deployment
    • Replicaset
    • Pod

Initializers (инициализаторы): Ну на собесах фиг с ними

  • Kube-controller-manager:
    Контроллеры - это куча скриптов (участков кода) в одном бинарнике, которые асинхронно следят только за своей зоной ответственности.

    • Deployments controller cоздает ReplicaSet, присоединяет к нему label selector и дает номер ревизии.
    • ReplicaSets controller проверяет состояние нового ReplicaSet, если видит несоответствие между тем, что есть, и тем, что требуется, пытается наплодить Pods, принадлежащих ReplicaSet.

      При подъеме происходит магия SlowStartInitialBatchSize. То есть, при каждом успешном создании пода, новых подов в следующей итерации поднимается в 2 раза больше. Это сделано, чтобы не упороть KubeApiserver, если что-то пойдет не так.

  • Informers и Watch:
    Informers — это высокоуровневый паттерн в Kubernetes для отслеживания изменений объектов. Компоненты (контроллеры, scheduler) подписываются через Watch API на изменения интересующих их объектов. Механизм List-Watch работает так: при старте выкачивается полное состояние ресурсов (List), а затем поддерживается актуальный локальный кэш через поток событий об изменениях (Watch). Это позволяет компонентам реагировать на события в режиме реального времени, потреблять меньше ресурсов и снижать нагрузку на Control Plane.

  • Scheduler:

    • Слушает события (через Watch) о подах, у которых не установлен nodeName, и выполняет scheduling в соответствии с запрошенными ресурсами, constraints и policies.
    • После выбора подходящей ноды устанавливает nodeName в spec пода через binding API.

  • Kubelet:

    • Это агент, запущенный на каждой воркер ноде кластера k8s и отвечает за управление жизненным циклом подов. Подписывается через Watch на поды, у которых nodeName соответствует этой ноде.
    • Получив информацию о новом поде, он обрабатывает всю логику перевода между абстракцией "Pod" и ее строительными блоками (контейнерами).
    • Он также обрабатывает всю сопутствующую логику, связанную с:
      • монтированием томов
      • протоколированием контейнеров
      • сборкой мусора и многими другими важными вещами
      • передачей podSpec в CRI
    • Регулярно сообщает статус подов обратно в kube-apiserver

  • CRI (Docker, containerd (protocol buffers (it's like a faster JSON) and a gRPC API)):

    • Создается Sandbox (песочница) включает в себя создание pause контейнера.
    • pause контейнер служит в качестве родительского для всех остальных контейнеров в Pod, поскольку в нем размещается множество ресурсов уровня Pod, которые в конечном итоге будут использовать контейнеры рабочей нагрузки.
      Эти ресурсы представляют собой пространства имен Linux (IPC, сеть, PID).

  • CNI:

    bridge/ipvlan/macvlan/sr-iov

    тут прокидывается виртуальный линк в Pod хоста, IP цепляется за pause контейнер, чтоб не потеряться при рестартах контейнера из-за ошибок, например.

  • Inter-host networking:

    • overlay networking (Flannel, например)
      Для этого обычно используется концепция оверлейной сети, которая представляет собой способ динамической синхронизации маршрутов между несколькими узлами. Одним из популярных поставщиков оверлейных сетей является Flannel. Когда он установлен, его основной задачей является обеспечение сети IPv4 третьего уровня между несколькими узлами в кластере. Flannel не управляет тем, как контейнеры подключаются к узлу (это задача CNI remember), а скорее тем, как трафик передается между узлами. Для этого он выбирает подсеть для узла и регистрирует ее в etcd. Затем он хранит локальное представление маршрутов кластера и инкапсулирует исходящие пакеты в UDP-датаграммы, гарантируя, что они дойдут до нужного узла.

    Для получения дополнительной информации ознакомьтесь с документацией CoreOS.

  • Container startup:

    • Pull the image
    • Create the container via CRI
    • Create network via CNI (всякие правила iptables)
    • post-start lifecycle хуки
    • Рединес пробы
    • Контейнер шуршит

Как устроена сеть в Kubernetes

Можно посмотреть вот это видео

С чего бы начать? В Кубере есть такой прикол как эфемерность подов. Поды могут умирать и рождаться как им вздумается, а IP-адреса при этом могут меняться как погода в Питере.

А еще в среднестатистическом кластере Кубера существует сразу 3 разновидности сети. Весело, даже сеть на микросервисы поделили.

Three Networks

Разберемся с каждой из них:

  1. Node Network - грубо говоря, это сеть железок - самих хостов, которые мы называем worker-нодами. Внутри этой сети ноды общаются друг с другом, а также с мастерами. Обычная серверная связность (L2/L3 уровни OSI). Эта сеть ничего не знает про поды.

  2. CNI — Container Network Interface. Короче, куберовцы молодцы, съехали с темы администрирования сети и отдали ее, грубо говоря, на аутсорс, предоставив интерфейс - коннектор до плагинов.

    Самый популярный:

    • Calico - Работает на уровне L3, поддерживает NetworkPolicy, использует BGP для маршрутизации между нодами.

    Но есть и другие: (Cilium, Flannel и т.д.)

    • Flannel - нет NetworkPolicy - в прод не берем, только дома поиграться. Работает на оверлейных сетях (VXLAN - упаковывает пакет пода в пакет ноды), простая настройка.
    • Cilium - киллер фича - использует eBPF, поддерживает mTLS, все хорошо с NetworkPolicy, работает на уровне L3

Как СNI-плагин работает при старте пода:

  1. Pod Scheduling

  2. Kubelet получает из API детали запускаемого пода и обращаеся в CRI для создания пода.

  3. CRI в свою очередь:

    • Создает сетевой namespace.
    • Создает pause контейнер.
    • Вызвает CNI plugin.

  4. CNI plugin (например, Calico):

    • Создает виртуальный Ethernet интерфейс (veth pair) для пода.
    • Подключает один конец veth к поду, а другой к bridge ноды.
    • Назначает IP-адрес поду из пула CIDR ноды.
    • Прописывает маршруты.
    • Прописывает правила iptables.

  5. Services

Трафик между подами на одной ноде (intra-node)

Давай посмотрим, что происходит, когда pod1 хочет отправить пакет pod2, и оба находятся на одной ноде:

  1. Пакет выходит из pod1 через его виртуальный интерфейс eth0 и попадает в root netns узла через вещь под названием veth (вроде виртуального сетевого кабеля)
  2. Пакет приходит в cbr0 — это сетевой мост на ноде (container bridge). Это такой коммутатор в ядре ОС
  3. cbr0 говорит: "Хм, пакет для IP 10.x.x.x. У кого такой IP?" и отправляет ARP-запрос (это как узнать, кто сидит за этим IP)
  4. Виртуальный кабель пода pod2 (vethyyy) отвечает: "Это я! Это мой IP!"
  5. bridge узнаёт, через какой виртуальный кабель лежит путь до пода, и отправляет пакет туда
  6. Пакет проходит через этот кабель и попадает в netns pod2

Просто, правда? Это работает на уровне L2 (линк-уровня).

Трафик между подами на разных нодах (inter-node)

А вот тут становится сложнее. Поды должны быть доступны со всех узлов, и каждому узлу нужен способ узнать, как до них добраться.

Вот как Kubernetes это решает:

Каждому узлу назначается свой блок CIDR (через Calico) — это диапазон IP-адресов. Например:

  • Нода 1 получает 10.244.0.0/24
  • Нода 2 получает 10.244.1.0/24

Так что поды на разных нодах никогда не конфликтуют по IP-адресам.

Как трафик передаётся между нодами?

Kubernetes не диктует, как это должно работать. Можно использовать несколько подходов:

  1. L3 маршрутизация (Calico) — просто добавляются маршруты в таблицу маршрутизации. Например: "Трафик для 10.244.1.0/24 идёт через 192.168.1.10 (IP узла 2)". Обычно облачные провайдеры используют именно этот способ
  2. Оверлейные сети (вроде Flannel) — пакеты инкапсулируются. Например, пакет от пода на ноде 1 к поду на ноде 2 оборачивается в ещё один IP-пакет и только потом отправляется на узел 2, а там распаковывается и доставляется в нужный под.
  3. L2 подходы (вроде Weave) — используется ARP между узлами

Смысл такой: Kubernetes говорит "Поды должны видеть друг друга", а как это реализовать — дело CNI-плагина (Flannel, Calico, Weave и т.д.)

Services: как всё это упростить

Так, хорошо, но IP-адреса подов постоянно меняются — поды создаются и удаляются. Как приложениям обращаться друг к другу?

Для этого есть Services — это виртуальный IP (VIP), который не меняется и автоматически маршрутизирует трафик к нужным подам.

Типы Services:

  • ClusterIP (по умолчанию): Service получает виртуальный IP (VIP), доступный только внутри кластера. Это как внутренний адрес склада, который никому не нужен снаружи. kube-proxy на каждой ноде обновляет правила iptables, чтобы трафик к VIP адресам перенаправлялся на реальные IP подов.

  • NodePort: Сервис доступен на одном и том же порту на каждой ноде кластера. Например, если ты настроил NodePort на порт 30000, то можешь обратиться на 192.168.1.10:30000 или 192.168.1.11:30000, и трафик попадёт на поды сервиса. Под капотом Kubernetes всё равно создаёт ClusterIP, но дополнительно прокидывает трафик на узлах.

  • LoadBalancer: Если ты в облаке (AWS, GCP и т.д.), этот тип просит облачный провайдер создать балансировщик нагрузки и направить трафик на твой сервис. Пользователь обращается на внешний IP балансера, и всё работает волшебно.

  • ExternalName: Это просто alias для внешнего сервиса. Например, ты можешь сказать, что сервис my-db на самом деле это my-db.example.com. Kubernetes просто вернёт CNAME запись, никакого проксирования.

DNS в Kubernetes

Каждый Service и Pod получают имя во внутренней DNS системе Kubernetes. Обычно это выглядит так:

  • my-service.default.svc.cluster.local для сервиса my-service в namespace'е default. Можешь просто писать my-service, и если под в том же namespace'е, система поймёт о ком речь

DNS-сервер в кластере (обычно CoreDNS) следит за всеми Services и обновляет DNS-записи. Это сделано для того, чтобы приложения могли обращаться друг к другу по имени, а не по IP.

kube-proxy

На каждой ноде работает kube-proxy. Его задача — следить за Services и обновлять правила маршрутизации в ядре ОС (обычно через iptables). Когда ты создаёшь Service, kube-proxy добавляет правило: "Если видишь трафик на VIP этого сервиса, отправь его на IP одного из его подов" (причём выбирает под по round-robin). Это работает очень быстро, потому что всё решается в ядре ОС.

Что такое Network Policies в Kubernetes

Network Policies в Kubernetes — это объект, который определяет правила управления сетевым трафиком между подами (Pods) и сетевыми сущностями внутри кластера. Они используются для ограничения и контроля входящего (ingress) и исходящего (egress) трафика между подами на уровне сетевого взаимодействия.

Сетевые политики позволяют улучшить безопасность, изолируя поды и управляя их сетевой доступностью.

Основные задачи Network Policies

  1. Изоляция сетевого трафика:
    По умолчанию все поды могут взаимодействовать друг с другом без ограничений. Network Policies позволяют контролировать, какие поды могут обмениваться трафиком.

  2. Управление входящим трафиком (Ingress):
    Определяет, кто может отправлять сетевые запросы в под.

  3. Управление исходящим трафиком (Egress):
    Определяет, куда под может отправлять сетевые запросы.

Как работают Network Policies?

  • Network Policies работают на уровне CNI (Container Network Interface) плагинов, таких как:
    • Calico
    • Weave
    • Cilium

Важно: Чтобы Network Policies работали, CNI-плагин должен поддерживать их реализацию.

  • По умолчанию поды открыты для всех соединений, пока не применена хотя бы одна Network Policy.

  • Правила политики описываются на основе меток (Labels), которые задают:

    • Какие поды участвуют в политике.
    • Какой трафик разрешён или запрещён.

Особенности работы

  1. Если политика определена для Ingress, то весь входящий трафик блокируется, кроме явно разрешённого.
  2. Если политика определена для Egress, то весь исходящий трафик блокируется, кроме явно разрешённого.
  3. Политики не имеют обратной силы:
    • Если под не попадает в podSelector, политика на него не распространяется.
  4. Network Policies не блокируют трафик, идущий через Service type NodePort или LoadBalancer, а только межподовый трафик.

Преимущества использования Network Policies

  1. Безопасность:

    • Позволяют изолировать поды и ограничивать сетевые взаимодействия.
    • Защищают от несанкционированного доступа.

  2. Гибкость:

    • Позволяют задавать сложные правила маршрутизации трафика.

  3. Масштабируемость:

    • Использование меток (labels) упрощает управление политиками при большом количестве подов.

  4. Соответствие стандартам:

    • Network Policies помогают соответствовать требованиям безопасности, таким как PCI DSS или GDPR.

Ограничения Network Policies

  1. Только L3/L4:
    Network Policies работают на сетевом уровне (IP и порты), но не на уровне приложений (L7), например, HTTP.

  2. Зависимость от CNI-плагина:
    Network Policies не работают с плагинами, которые их не поддерживают (например, Flannel).

  3. Нет deny-правил:
    Kubernetes Network Policies определяют только разрешающие (allow) правила. Блокировка трафика происходит автоматически, если явно не разрешено.

Общие вопросы по Kubernetes

Сущности Kubernetes (StatefulSets/Daemonset/Operator)

  • StatefulSets: Штука, описывающая где будут крутиться Pods с данными. StatefulSets

  • Daemonset: Гарантирует, что все (или некоторые по .spec.template.spec.{nodeSelector или affinity}) узлы запускают копию Pod

    • Примеры:
      • node-exporter (Prometheus)
      • Datadog Agent
      • Zabbix agent
      • Telegraf
    • CNI / сетевые компоненты
      • Calico node
    • NVIDIA device plugin

  • Operator: (профессия) — группа профессий по управлению работой оборудования (установок) различного вида и назначения. Шутка. Операторы - это программные расширения Kubernetes, которые используют пользовательские ресурсы для управления приложениями и их компонентами.
    К числу задач, которые можно автоматизировать с помощью оператора, относятся:

    • развертывание приложения по требованию;
    • создание и восстановление резервных копий состояния приложения;
    • обработка обновлений кода приложения вместе с сопутствующими изменениями, такими как схемы баз данных или дополнительные параметры конфигурации;
    • публикация службы для приложений, которые не поддерживают API Kubernetes, чтобы обнаружить их;
    • имитация сбоя всего кластера или его части для проверки его устойчивости;
    • выбор лидера для распределенного приложения без внутреннего участника.

Как поды назначаются на ноды

Назначение подов на ноды происходит по одному из следующих методов:
- nodeSelector: выбор ноды по node labels. Kubernetes будет планировать размещение бода только на тех узлах, которые имеют все указанные вами метки.
- Affinity and anti-affinity: можно указать, что правило является мягким или предпочтительным, чтобы планировщик все равно запланировал под, даже если он не может найти подходящий узел, например.
- nodeName
- Pod topology spread constraints: ограничения на распространение топологии Подов

Какие бывают Пробы

  • livenessProbe: Показывает, запущен ли контейнер;
  • readinessProbe: Указывает, готов ли контейнер отвечать на запросы;
  • startupProbe: Указывает, запущено ли приложение внутри контейнера.

Нужно выбирать или livenessProbe + readinessProbe, или startupProbe. Если с пробами что-то не так, kubelet смотрит в restartPolicy, а они бывают трех видов - Always, OnFailure, and Never

Как прокидывается файл из инит контейнера

Ладно, представь ситуацию: тебе нужно что-то подготовить перед тем, как запустить основное приложение. Например, сгенерировать конфиг, скачать данные или проверить что-то. Для этого есть init-контейнеры — они запускаются ДО основного контейнера и могут создавать/подготавливать файлы.

Порядок выполнения

Вот как это работает:

  1. Init-контейнер запускается первым — выполняет свою задачу (например, создаёт файл /data/config.conf)
  2. Init-контейнер завершается — его работа закончена, он умирает
  3. Основной контейнер запускается — видит уже готовые файлы, которые создал init-контейнер
  4. Приложение работает — использует файлы из общего тома

Важно: Если init-контейнер упадёт с ошибкой, основной контейнер вообще не запустится. Kubernetes перезапустит весь под.

Какие Volumes подходят

Для общего использования между init и основным контейнером подходят emptyDir (самый частый случай) и другие:

  • emptyDir (самый частый) — пустая директория, которая существует только пока живёт под. Init создаёт там файлы, основной читает. Идеально!

    volumes:
- name: shared-data
  emptyDir: {}

  • configMap — если нужно смонтировать конфиг из ConfigMap. Init может его читать и дополнять.

  • downwardAPI — для метаинформации пода (имя, namespace, labels). Init может записать эту информацию в файл.

  • secret — если init нужно прочитать секрет и обработать его.

  • persistentVolumeClaim — если данные нужно сохранить между перезагрузками пода.

Когда и зачем использовать

Когда использовать init-контейнеры:

  1. Генерация конфигов — например, создать nginx.conf на основе переменных окружения
  2. Загрузка данных — скачать нужные файлы из S3 или другого хранилища
  3. Проверка зависимостей — убедиться, что БД доступна, прежде чем запустить приложение
  4. Миграции БД — запустить миграции перед стартом приложения
  5. Инициализация — распаковать архив, создать нужные директории, установить разрешения

Пример:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  # Init-контейнер подготавливает данные
  initContainers:
  - name: init-config
    image: busybox
    command:
    - sh
    - -c
    - |
      echo "Generated config" > /data/config.txt
      echo "Server started at $(date)" >> /data/config.txt
    volumeMounts:
    - name: shared-data
      mountPath: /data
  
  # Основной контейнер читает готовые файлы
  containers:
  - name: app
    image: nginx
    volumeMounts:
    - name: shared-data
      mountPath: /usr/share/nginx/html
  
  # Один том на всех
  volumes:
  - name: shared-data
    emptyDir: {}

В этом примере init-контейнер создаёт файлы в /data, а nginx их видит как готовые к использованию.

Как выбирается мастер в Kubernetes?

Ответ: По протоколу RAFT
Основной механизм — Lease API:
* Kubernetes API предоставляет объект типа Lease (часть Coordination API).
* Кандидаты на лидерство периодически пытаются обновить объект Lease в etcd, который служит индикатором текущего лидера.
* Узел, который успешно обновляет Lease, становится лидером.

По какому протоколу работает API Kubernetes?

Ответ: OpenAPI (REST) HTTP/HTTPS

Два слова про REST

Обычно существует 2 поля объекта: `spec` и `status`.  
В поле `spec` указывается требуемое состояние (описание характеристик, которые должны быть у объекта).  
`status` описывает текущее состояние объекта  
ой как понятно стало

garbage collector вычищает по полю ownerReferences

Восстановление etcd (disaster recovery):

- нужно выключить 2 из трех инстансов, на оставшемся можно подложить последний хороший бэкап (забэкапив текущие данные, если они покрашились) и запуститься с ключем `--force-new-cluster`  
- [ETCD Disaster recovery](https://etcd.io/docs/v3.3/op-guide/recovery/)  
> Сжатие + дефрагментация + правильный мониторинг — основа обслуживания вашего кластера etcd.

Общие вопросы с собесов

Чем отличается git merge от git rebase?

  • Ответ: merge - оставляет историю (больше коммитов, после merge - новый коммит слияния в основной ветке, другая продолжает существовать и не зависит от основной)
    rebase - переписывает историю (меньше коммитов, после rebase последний коммит перезаписывается и остаётся основным. Ветка, которая была родительской - удаляется)

Что такое CAP теорема?

  • Ответ:

    Теорема cap: эвристическое утверждение о том, что в любой реализации распределённых вычислений возможно обеспечить не более двух из трёх следующих свойств:

    • согласованность данных (англ. consistency) — во всех вычислительных узлах в один момент времени данные не противоречат друг другу;
    • доступность (англ. availability) — любой запрос к распределённой системе завершается откликом, однако без гарантии, что ответы всех узлов системы совпадают;
    • устойчивость к разделению (англ. partition tolerance) — расщепление распределённой системы на несколько изолированных секций не приводит к некорректности отклика от каждой из секций.

Вопросы от Барсукова

У вас есть ноутбук с линуксом, например убунтой, на рабочем столе запущен терминал, в нем вы запускаете curl https://example.com/расскажите, что произойдет?

Прострой отказоустойчивый сервис сокращения ссылок, например.
Отказоустойчивый, распределенный сервис DNS, например, на 5 зон

Где Prometheus хранит данные?

  • Ответ:

    Prometheus хранит данные в своей локальной Time Series Database (TSDB) на диске.

    • По умолчанию — в директории ./data (относительно рабочей папки Prometheus).
    • В production — обычно /var/lib/prometheus или /var/lib/prometheus/data (зависит от дистрибутива/установки).
    • Указывается флагом --storage.tsdb.path=/path/to/data.

    Структура внутри:

    • WAL (write-ahead log) — для недавних данных и восстановления после краша
    • Блоки (chunks_head, блоки по 2 часа → компактируются в большие) — основные данные time series
    • Индексы, метаданные.

    Данные хранятся локально на файловой системе (рекомендуется локальный диск, не NFS для надёжности).
    Для долгосрочного хранения → remote write в Thanos, Cortex, VictoriaMetrics и т.д. (локально держат только недавние данные, retention обычно 15 дней–несколько недель).

Ansible

Ansible — это инструмент для автоматизации настройки серверов: устанавливать пакеты, править конфиги, запускать команды без ручного SSH.

Проще: Ansible — это “настроить много серверов одной командой”.

Структура директорий

Обычно проект выглядит так:

ansible/
├── inventory/        # Список серверов
│   └── hosts.yml
├── playbook.yml      # Что делать (основной сценарий)
├── roles/            # Готовые роли
│   └── nginx/
│       ├── tasks/    # Что выполнять
│       │   └── main.yml
│       ├── handlers/ # Перезапуск сервисов
│       │   └── main.yml
│       ├── templates/# Jinja2 шаблоны
│       ├── files/    # Файлы для копирования
│       └── vars/     # Переменные

Коротко по файлам

  • inventory — где сервера
  • playbook — что делать
  • roles — переиспользуемая логика

Подлиннее по файлам

Inventory — файл конфигурации, где определяется информация о хосте. Хранится в папке /etc/ansible/hosts

Плейбуки - в плейбуках Ansible мы определяем, как применять политики, объявлять конфигурации, оркестрировать действия и запускать задачи на серверах — синхронно или асинхронно. Плейбук может включать один play или несколько.

Play — компонент плейбука, который состоит из группы задач, выполняемых на определённых хостах. Каждый play должен указывать хост или группу хостов. Пример:

-hosts: all # здесь мы указываем все хосты.

Задачи (task) — это отдельные действия, которые выполняются плейбуками. Например:

- name: Install Apache httpd # Определение задачи может содержать модули, 
например yum, git, service и copy.

Роли в Ansible назначаются группе хостов и помогают организовать задачи по автоматизации. Мы можем создать несколько ролей и назначить их группе задач. Допустим, роль webserver можно использовать для установки Apache и Nginx на указанной группе серверов.

Обработчики (handler) похожи на задачи, но выполняются только при вызове из события. Например, обработчик может запустить сервис httpd после того, как его установила задача. Обработчик вызывается директивой notify. Важно! Имя директивы notify и обработчика должны совпадать.

Шаблоны Файлы шаблонов (template) основаны на шаблонизаторе Python Jinja2 и имеют расширение .j2. В файл шаблона при желании можно поместить содержимое файла index.html, но эффективнее всего использовать в них переменные и факты.

Переменные В плейбуки можно включать собственные переменные. Есть пять способов определить переменную:

  1. В play, в атрибуте vars_files:
vars_files:
- "/path/to/var/file"
  1. В /vars/apache-install.yml
  2. В командной строке:
# ansible-playbook apache-install.yml -e "http-port=80"
  1. В play через vars:
vars: http_port: 80
  1. В каталоге group_vars/

Приоритеты переменных https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_variables.html#understanding-variable-precedence

Модули в Ansible

Модули в Ansible — это готовые действия, которые Ansible выполняет на серверах.

Проще: модуль = “что именно сделать” (установить пакет, скопировать файл, перезапустить сервис).

Примеры модулей

  • apt / dnf — установить пакет
  • copy — скопировать файл
  • template — развернуть шаблон
  • service / systemd — управлять сервисом
  • file — создать файл/директорию
  • shell / command — выполнить команду

Пример в playbook

- name: Install nginx
  apt:
    name: nginx
    state: present

Здесь apt — модуль.

Важно понимать

  • Модули идемпотентны (повторный запуск безопасен)
  • Работают через SSH
  • Не нужно писать скрипты
  • Возвращают structured output (ok / changed / failed)

Что НЕ является модулем

  • playbook — ❌
  • role — ❌
  • inventory — ❌

Terraform

Отличие Ansible и Terraform

Terraform - Предназначен для инфры.
Ansible - Предназначен для приложений на инфре.

То есть, Terraform используется чтобы разворачивать инфраструктуру (виртуальные машины, сети, диски, и тп.).
Ansible предназначен для работы с существующими ресурсами, чтобы устанавливать и настраивать окружение (программы, операционные системы) на этих виртуалках.

Нюансы:

  • Terraform отслеживает состояние и делает инкрементные изменения, что особенно полезно при работе с облачной инфраструктурой.

  • Ansible не управляет состоянием, и каждая задача считается независимой.

    • Нужно понимать что это инструменты. И в ряде случаев с помощью Ansible равзвернуть инфраструктуру всё таки можно.
    • Как и для Терраформа написать провайдер, который будет делать что-то свое. Вопрос лишь в применимости инструментов.

Основные возможности Terraform

  • Декларативный язык (HCL) – вы описываете, какой должна быть инфраструктура, а Terraform сам выполняет необходимые шаги.
  • Поддержка множества облаков – AWS, Google Cloud, Azure, Kubernetes и даже локальная инфраструктура.
  • Отслеживание состояния – Terraform хранит текущее состояние ресурсов и понимает, что нужно изменить.
  • Масштабируемость – можно управлять как небольшими, так и крупными кластерами.
  • Модули – позволяют переиспользовать код и упрощать управление инфраструктурой.

Базовые команды Terraform?

  1. Пишем код Определяем ресурсы в файле .tf, например:

    resource "aws_instance" "example" {
  ami           = "ami-123456"
  instance_type = "t2.micro"
}

  2. Инициализируем проект

    terraform init

  3. Просматриваем план изменений

    terraform plan

  4. Применяем конфигурацию

    terraform apply

  5. Удаляем инфраструктуру при необходимости

    terraform destroy

Важные концепции

  • Providers – плагины, которые позволяют работать с разными облачными сервисами.
  • State (состояние) – Terraform хранит текущее состояние ресурсов в файле terraform.tfstate.
  • Modules – повторно используемые блоки конфигурации.
  • Variables – позволяют параметризовать конфигурацию.
  • Outputs – используются для экспорта данных, например, IP-адресов.

Что такое ресурс в Terraform

  • Ответ:

    Это основной строительный блок кода, который описывает объект в инфраструктуре. Каждый ресурс имеет свои аргументы, свои параметры, свою конфигурацию. Ресурс имеет какой-то уникальный идентификатор (ID, ARN и тд).

    Виртуальная машина, сеть, диск, порт, балансировщик и тд.

Как реализовать принцип Don't Repeat Yourself при описании инфраструктуры с помощью IaC-инструментов (Terraform, Ansible, Helm)?

  • Ответ: В Terraform — модули, for_each, переменные + locals.
    В Ansible — роли, include_tasks, vars_files и Jinja-шаблоны.
    В Helm — _helpers.tpl, values.yaml + subcharts.

    Главное — выносить повторяющуюся логику в переиспользуемые блоки и параметризовать через переменные.

Базы данных

Типы баз данных: сравнение

Тип БД В каких форматах хранят данные Чем хороши (Плюсы) Популярность Особенности и ограничения Сценарии использования в Highload / ML
Реляционные (RDBMS) PostgreSQL, MySQL, Oracle, MS SQL. Строки (двумерные таблицы). Данные разбиты по колонкам с жестко заданной схемой типов (Schema-on-Write). Строгое соблюдение ACID; поддержка сложных декларативных SQL-запросов и JOIN; гарантированная консистентность. Мощная аналитика. Экстремально высокая. Почти каждый проект использует их как ядро. Плохо масштабируются горизонтально; деградация производительности при обилии связей «многие-ко-многим» и терабайтных объемах. Финансовые транзакции, биллинг, учетные записи пользователей, паттерн Transactional Outbox.
Документо-ориентированные MongoDB, Couchbase. Иерархические документы. Текстовые или бинарные структуры данных: JSON, BSON, XML. Schemaless (гибкая структура без жесткой схемы); высокая скорость записи; легкое горизонтальное масштабирование (sharding). Очень высокая. Стандарт для быстрой разработки и работы с полуструктурированными данными. Нет поддержки полноценных JOIN на уровне движка; избыточность (дублирование данных внутри документов); повышенный расход диска. Каталоги товаров со сложным набором характеристик, хранение пользовательских профилей и сессий, CMS-системы.
Ключ-Значение (Key-Value) Redis, Memcached, Dragonfly Ассоциативный массив. Простая пара: уникальный ключ (строка) и значение (строка, строка-бинарник, JSON, списки/хэши). Экстремально низкий Latency (субмиллисекунды); огромный throughput (сотни тысяч RPS); работа целиком в оперативной памяти. Высокая (как слой кэширования). Присутствует почти в любой highload-архитектуре. Объем данных жестко ограничен размером RAM сервера; риск потери данных при перезапуске, если не настроен сброс на диск (RDB/AOF). Кэширование ответов API, хранение сессий пользователей, распределенные блокировки (Mutex), rate-limiter'ы.
Колоночные (Wide-Column / OLAP) ClickHouse (лидер в РФ), Cassandra, ScyllaDB, Google Bigtable По колонкам (столбцам). Физически данные из одной колонки пишутся на диск в один непрерывный блок. Колоссальная скорость чтения отдельных колонок для агрегации; высокая степень сжатия данных (одинаковые типы сжимаются эффективнее). Высокая в BigData/Аналитике. Не подходят для OLTP (частых точечных обновлений/удалений одиночных строк); не поддерживают транзакции ACID. ClickHouse: Аналитика логов, продуктовые метрики, аудит-логи. Cassandra: Таймлайны, история сообщений в чатах.
Векторные (Vector DB) Qdrant, Milvus, Pinecone, плагин pgvector Многомерные числовые массивы. Векторы фиксированной длины (эмбеддинги), полученные из ML-моделей (например, [0.12, -0.43, ..., 0.89]). Эффективный поиск ближайших соседей (ANN поиск); оптимизация математических операций сравнения векторов (косинусное расстояние). Взрывной рост (благодаря LLM). Главный инфраструктурный тренд последних лет. Высокая нагрузка на CPU/GPU при перестроении индексов (HNSW); требуют огромного объема RAM; точность поиска вероятностная. RAG-системы (Retrieval-Augmented Generation), семантический поиск по картинкам/текстам, рекомендательные движки.
Временные ряды (Time-Series) VictoriaMetrics, InfluxDB, TimescaleDB Пара: Время + Метрика. Массив точек, где ключевым индексом является временная метка (Timestamp), привязанная к набору тегов. Оптимизированы под непрерывную запись метрик в хронологическом порядке; автоматическое удаление старых данных по политикам (TTL). Высокая в DevOps и IoT. Инфраструктурный стандарт для сбора телеметрии. Узкая специализация; низкая эффективность, если структура данных или метатеги постоянно меняются в реальном времени. Мониторинг ИТ-инфраструктуры (сбор метрик с серверов, etcd и Kubernetes через Prometheus), финансовые тикеры, котировки акций.

Что такое ACID?

  • Ответ:

    ACID — это набор свойств, обеспечивающих надежность транзакций в базах данных.
    Каждая буква в аббревиатуре ACID обозначает одно из свойств:

    1. Atomicity (Атомарность):

      • Транзакция выполняется полностью или не выполняется вовсе. Если одна часть транзакции не удалась, все изменения откатываются.

    2. Consistency (Согласованность):

      • После завершения транзакции база данных остается в согласованном состоянии, удовлетворяя всем правилам и ограничениям (например, уникальность ключей, внешние ключи).

    3. Isolation (Изоляция):

      • Одновременные транзакции не влияют друг на друга. Результат выполнения одной транзакции не виден другим до её завершения.

    4. Durability (Долговечность):

      • После успешного завершения транзакции изменения сохраняются в базе данных даже в случае сбоя системы.

Что такое OLTP-базы данных?

  • Ответ:

    OLTP (Online Transaction Processing) базы данных — БД, предназначенные для обработки большого количества транзакций в реальном времени. Используются там, где требуется высокая скорость операций ввода, обновления, удаления и чтения данных, таких как системы управления заказами, банковские системы, розничная торговля, системы бронирования и другие. Следуют ACID.

    Основные характеристики OLTP-баз данных:

    1. Обработка транзакций в реальном времени с большой скоростью I/O:
      * OLTP-базы обрабатывают транзакции быстро и с минимальной задержкой (например, покупка товара, перевод средств). Фигачат транзакции в миллисекундах (добавление, обновление или удаление данных).
    2. Моделирование данных:
      * OLTP использует нормализованную структуру данных, чтобы минимизировать избыточность и обеспечивать согласованность данных.
    3. Поддержка большого числа пользователей:
      * OLTP-системы часто рассчитаны на поддержку тысяч или миллионов пользователей, которые выполняют транзакции одновременно.

    Примеры баз данных, используемых для OLTP:

    1. Реляционные базы данных:
    • MySQL
    • PostgreSQL
    • Oracle Database
    • Microsoft SQL Server
    1. NoSQL базы данных (для специфичных сценариев):
    • MongoDB
    • Cassandra
    • Redis (в качестве высокопроизводительного кэша)

Рекомендованная архитектура отказоустойчивой БД

  1. Основная база данных с синхронной репликацией (Master-Slave).
  2. Географически распределённые узлы для защиты от катастроф.
  3. Автоматическое переключение (failover) на резервный сервер.
  4. Резервное копирование с регулярной проверкой восстановления.
    • Репликация - НЕ БЭКАП!
  5. Инструменты мониторинга и оповещения для быстрого реагирования. Мониторить следующие метрики:
    • активные соединения (max_connections);
    • использование ресурсов (Disk I/O, CPU, RAM);
    • задержка репликации (в идеале 0 секунд);
    • блокировки;
    • ошибки транзакций;
    • состояние бэкапов и их успешность.

Архитектура отказоустойчивого кластера PostgreSQL

  1. Primary и минимум одна синхронная реплика. Для синхронной реплики нужно включить WAL-журналы (Write-Ahead Logging - Все операции записываются последовательно в журнал транзакций перед их применением)
  2. Автоматический failover через Patroni или Pgpool-II. - Pgpool-II Позволяет распределять чтение на реплики. Patroni - самый популярный.
  3. DCS (Distributed Consensus Store): Etcd (или Consul) — распределенное хранилище состояния. Хранит информацию о том, кто сейчас Лидер (Primary), а кто Реплика. Защищает от проблемы Split-Brain (когда две нoды думают, что они главные)
  4. Балансировка и роутинг трафика: Haproxy + Keepalived (или встроенный в Kubernetes-сервисы механизм). На Haproxy вешаем VIP для прозрачного переключения клиентов - виртуальный IP, через Keepalived.
  5. Мониторинг и управление через Prometheus/Grafana.
  6. Резервные копии для защиты от потери данных. через pg_basebackup или pg_dump

Архитектура отказоустойчивого кластера PostgreSQL

Что такое Redis?

  • Ответ:

    Redis (Remote Dictionary Server) — это сверхбыстрая база данных с открытым исходным кодом, которая хранит данные в оперативной памяти и поддерживает множество типов данных. Она популярна как кэш, брокер сообщений или хранилище данных, требующих быстрого доступа.

Что такое ETL?

ETL (Extract, Transform, Load — Извлечение, Трансформация, Загрузка) — это базовый трехэтапный процесс в инженерии данных, который собирает информацию из разных источников, приводит её в порядок и сохраняет в единое централизованное хранилище (Data Warehouse или Data Lake).Это «топливная система» для любой аналитики, отчетов и ИИ-моделей. Без ETL данные останутся разбросанными по разным базам в сыром, грязном и нечитаемом виде.

Три шага процесса ETL

  1. Extract (Извлечение)
    Система подключается к множеству разрозненных источников и забирает из них новые или изменившиеся данные.
    Откуда забирает:
    Из баз данных продакшн-сайтов (PostgreSQL, MongoDB), логов серверов, CRM-систем (amoCRM, Salesforce), Google Таблиц, рекламных кабинетов или API-сервисов.

  2. Transform (Трансформация)
    Самый сложный и важный этап. Сырые данные очищаются, пересобираются и приводятся к единому стандарту, чтобы их можно было анализировать вместе.
    Очистка: Удаление дубликатов, исправление ошибок, обработка пустых значений (NULL).
    Нормализация: Приведение к одному формату. Например, даты из разных систем (06/06/2026, 2026-06-06, 06-Июн-26) превращаются в единый стандарт 2026-06-06. Валюты переводятся в одну базовую денежную единицу.
    Агрегация и обогащение: Склеивание таблиц (JOIN) и подсчет промежуточных итогов, чтобы аналитикам не приходилось делать это вручную.

  3. Load (Загрузка)
    Чистые отформатированные данные записываются в финальное распределенное хранилище.
    Куда загружает:
    В аналитические СУБД (ClickHouse, Snowflake, Greenplum) или объектные хранилища (MinIO, AWS S3). Отсюда данные забирают BI-системы (PowerBI, Tableau) для построения красивых графиков или Data Science модели для обучения.

Наглядный пример работы ETL

Представьте сеть супермаркетов.

  1. Extract: ETL-скрипт в полночь забирает данные о продажах: из базы данных кассовых аппаратов (там SQL), из мобильного приложения (там JSON файлы) и от службы доставки (там CSV файлы).

  2. Transform: Скрипт видит, что один и тот же товар в кассах называется «Вода 0.5», а в приложении — «Вода минеральная без газа, 500мл». Он сопоставляет их по штрихкоду, убирает ошибочные тестовые транзакции и считает общую выручку за день.

  3. Load: Готовая чистая таблица отправляется в ClickHouse бэкенда. Утром директор открывает ноутбук и видит точный график продаж по всей сети.

Современная альтернатива: ELT

С появлением мощных распределенных хранилищ (о которых мы говорили в прошлом шаге) классический ETL часто уступает место подходу ELT (Extract, Load, Transform).

  • Данные сначала извлекаются и сразу же загружаются в хранилище в сыром виде.
  • Трансформация (Transform) происходит уже внутри самого хранилища силами его собственных вычислительных мощностей. Это быстрее и позволяет гибко менять логику очистки данных задним числом.

Популярные инструменты для ETL/ELT

  • Оркестраторы и движки: Apache Airflow, Prefect, Dagster (управляют запуском скриптов по расписанию).
  • Трансформация кода: dbt (Data Build Tool) — стандарт для трансформации данных внутри баз с помощью SQL.
  • Low-Code платформы: Apache NiFi, Airbyte, Talend.

Свистелки

ArgoCD (continuous delivery): декларативный инструмент для непрерывной доставки в Kubernetes по модели GitOps. Имеет красивый UI, поддерживает синхронизацию с репозиториями Git и автоматическое обновление ресурсов в кластере.
Terragrunt — это тонкая обертка (wrapper) для Terraform, которая решает его главные «боли» и помогает содержать код инфраструктуры в чистоте, особенно в больших проектах. Если Terraform — это кирпичи, то Terragrunt — это умная система логистики, которая следит, чтобы кирпичи лежали ровно и не дублировались.
Istio Service Mesh: - Istio идет как Control Plane, он состоит из трёх компонентов - Pilot, Mixer и Citadel;
- Envoy как sidecar у подов (Data Plane)
> Istio перехватывает весь сетевой трафик и применяет к нему набор правил, вставляя в каждый pod умный прокси в виде sidecar-контейнера. Прокси, которые активируют все возможности, образуют собой Data Plane, и они могут динамически настраиваться с помощью Control Plane.
> На моей практике Nginx сайта перенаправлял запросы к одной из нескольких ферм Envoy, которая роутила запрос непосредственно в нужный kubernetes кластер.

ELK: (Elasticsearch, Logstash и Kibana): у нас ClickHouse, c kittenhouse - своей проксей + statsd
sr-iov: Single Root Input/Output Virtualization
Calico: сетевая штука, через CRD (Custom Resource Definition) поднимает networkpolicy, net
Consul: обеспечивает обнаружение сервисов, проверку работоспособности, балансировку нагрузки, граф сервисов, принудительное использование идентификационных данных с помощью TLS и управление конфигурацией распределенных сервисов. Вау.
Deckhouse kubernetes — это enterprise-платформа Kubernetes “под ключ” от компании Flant, ориентированная на эксплуатацию, безопасность и управляемые обновления.
Mesos: это централизованная отказоустойчивая система управления кластером. Она разработана для распределенных компьютерных сред c целью обеспечения изоляции ресурсов и удобного управления кластерами подчиненных узлов (mesos slaves). Это новый эффективный способ управления серверной инфраструктурой, но и, как любое техническое решение, не "серебряная пуля". Нормальные мальчики пользуют ванильный кубер :)
Apache Kafka статья:
- Событие или сообщение — данные, которые поступают из одного сервиса, хранятся на узлах Kafka и читаются другими сервисами. Сообщение состоит из:
- Key — опциональный ключ, нужен для распределения сообщений по кластеру.
- Value — массив байт, бизнес-данные.
- Timestamp — текущее системное время, устанавливается отправителем или кластером во время обработки.
- Headers — пользовательские атрибуты key-value, которые прикрепляют к сообщению.

RabbitMQ:
- Сообщение — это единица данных, которая передается между отправителем и получателем через брокер сообщений. Сообщение состоит из:
- Body — основное содержимое сообщения, может быть любым типом данных (текст, JSON, бинарные данные).
- Properties — метаданные сообщения, такие как заголовки, приоритет, время жизни и т.д.
- Routing Key — строка, которая используется для маршрутизации сообщения к соответствующему потребителю.
- Exchange — логический компонент, который принимает сообщения от отправителей и маршрутизирует их в очереди на основе правил маршрутизации.

Чаще всего Kafka сравнивают с RabbitMQ. Обе системы — брокеры сообщений. Главное отличие в модели доставки: Kafka добавляет сообщение в журнал, и консьюмер сам забирает информацию из топика; брокер RabbitMQ самостоятельно отправляет сообщения получателям — помещает событие в очередь и отслеживает его статус.

«Кролик» удаляет событие после доставки, «Кафка» хранит до запланированной очистки журнала. Таким образом, брокер Apache используется как источник истории изменений.

Разработчики RabbitMQ создали системы управления потоком сообщений: мониторинг получения, маршрутизация и шаблоны доставки. Подобное гибкое управление подойдет для высокоскоростного обмена сообщениями между несколькими сервисами. Минус такого подхода в снижении производительности при высокой нагрузке.

Главный вывод — для сбора и агрегации событий из большого количества источников, логов и метрик больше подойдет Apache Kafka.

Airflow — это платформа для создания, планирования и мониторинга рабочих процессов (workflow) в виде Directed Acyclic Graphs (DAGs). Она позволяет автоматизировать сложные задачи, такие как ETL-процессы, обработка данных и другие повторяющиеся операции. Airflow обеспечивает гибкость, масштабируемость и удобный интерфейс для управления задачами и их зависимостями.

  • DAG (Directed Acyclic Graph) — это структура данных, которая представляет собой ориентированный ациклический граф. В контексте Airflow, DAG используется для определения рабочих процессов, где узлы представляют задачи, а ребра указывают на зависимости между ними. DAG гарантирует, что задачи выполняются в правильном порядке и предотвращает циклические зависимости.
  • Operator — это абстрактный класс в Airflow, который представляет собой единицу работы. Он определяет, что должно быть выполнено, но не как. Существует множество встроенных операторов (например, BashOperator, PythonOperator), а также возможность создавать свои собственные операторы для выполнения специфичных задач.
  • Планировщик (Scheduler) — это компонент Airflow, который отвечает за планирование и запуск задач в соответствии с определенными DAG. Он следит за зависимостями между задачами и запускает их, когда все условия выполнены.

Менеджерские свистелки

Nexus: фреймворк - расширение классического скрама для крупных проектов с многокомандной разработкой.
ITIL методология: https://www.atlassian.com/ru/itsm/itil
ITSM методология Основная идея ITSM заключается в том, что ИТ нужно предоставлять как услугу.

Вопросы без ответа

Dependencies
lvm
jagger
open-api
gravitee
vmware - виртуализация, не интересно в эпоху контейнеров. Хотя... Есть люди, которые поднимают Kubernetes в виртуалках, наверно, надо изучить эти кейсы. Здесь может быть ваш MR :)

LeetCode - уровень easy https://leetcode.com/ - это для SRE в Rндекс и ТинькоFF. Кстати, они гоняют тупо по академическим знаниям, не спрашивая у любителей куберетиса ничего про кубернетис, отнимая тонны вашего времени на 4 этапа. Что сказать, Google Way...

штурвал
haiva
ipv6

git джит-компилятор

steal
dora

Безопасность:
dlp системы

RHEL
Пайпы

About

Моя выжимка из подготовки к собеседованиям в роли SRE/DevOps. При необходимости, добавляйте правки, буду рад

Resources

Readme
Activity

Stars

18 stars

Watchers

1 watching

Forks

7 forks
Report repository

Releases

No releases published

Packages

 
 
 

Contributors

Languages