📌 Что такое Prometheus ?

💬 Спрашивают в 33% собеседований

Prometheus — это открытая система мониторинга и оповещения, которая широко используется для сбора метрик с различных целевых объектов, таких как серверы, виртуализированные контейнеры и приложения, в режиме реального времени. Она была создана в компании SoundCloud в 2012 году и с тех пор стала частью Cloud Native Computing Foundation, что подчеркивает её популярность и признание в индустрии.

🤔 Основные характеристики:

1️⃣ Модель данных:

➕ Prometheus хранит данные в форме временных рядов.
➕ Каждый временной ряд идентифицируется уникальным именем или идентификатором и может иметь набор ключ-значение, который называется метками (labels).

2️⃣ Язык запросов:

➕Prometheus имеет собственный язык запросов, PromQL (Prometheus Query Language), который позволяет пользователям выбирать и агрегировать данные по времени.

3️⃣Непрерывная сборка данных:

➕ Prometheus регулярно собирает метрики с целевых объектов, используя pull-модель, то есть сам запрашивает данные у целевых объектов по HTTP.

4️⃣ Цели мониторинга:

➕ Цели (targets) конфигурируются для мониторинга через статическую конфигурацию или с помощью сервис-дисковери.

5️⃣ Алерты:

➕ Prometheus поддерживает возможности оповещения. Он может высылать уведомления о проблемах, которые необходимо устранить, по различным каналам связи, например, через Email, Slack и другие сервисы.

6️⃣ Хранение:

➕ По умолчанию Prometheus хранит данные локально на диске в высокоэффективном формате временных рядов. Также поддерживается интеграция с внешними системами хранения.

7️⃣Высокая доступность:

➕ Для обеспечения высокой доступности можно запустить несколько экземпляров Prometheus, которые будут собирать данные параллельно.

🤔 Пример:

➕ Prometheus может использоваться для мониторинга производительности приложений, анализа системных метрик, таких как использование ЦП и памяти, а также для мониторинга инфраструктуры в целом. Например, в кластере Kubernetes Prometheus может собирать метрики со всех узлов, подов и контейнеров, предоставляя централизованный взгляд на здоровье всей системы.

➕ Prometheus предоставляет мощный инструментарий для мониторинга и оповещения в современных облачных и контейнерных средах. Он позволяет не только отслеживать состояние системы в реальном времени, но и реагировать на возникающие проблемы оперативно, что делает его незаменимым инструментом в арсенале DevOps-инженера.

🔥 ТОП ВОПРОСОВ С СОБЕСОВ

🔒 База собесов | 🔒 База тестовых

📌 Вопрос по kubernetes чем контейнер отличается от пола?

💬 Спрашивают в 13% собеседований

🤔 Чем контейнер отличается от пода в Kubernetes

🤔 Контейнер

Контейнер — это изолированная среда выполнения, которая упаковывает приложение и его зависимости, обеспечивая его консистентное выполнение независимо от окружения. Контейнеры обычно создаются с использованием технологий, таких как Docker, и включают:
- Приложение.
- Библиотеки и зависимости.
- Средства управления.

Пример Dockerfile для создания контейнера:

FROM python:3.8-slim
COPY . /app
WORKDIR /app
RUN pip install -r requirements.txt
CMD ["python", "app.py"]

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

🤔 Под

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

- Сетевое пространство: Все контейнеры в поде имеют общий IP-адрес и порты.

- Файловую систему: Общие тома для хранения данных между контейнерами.

- Сетевые ресурсы: Контейнеры в поде могут общаться друг с другом через localhost.

Основные характеристики пода:

- Один или несколько контейнеров: Обычно в поде размещается один контейнер, но можно разместить несколько контейнеров, которые должны работать вместе.

- Жизненный цикл: Поды создаются, управляются и удаляются Kubernetes. Они могут быть перезапущены в случае отказа.

- Общее пространство: Контейнеры в поде совместно используют сетевое пространство и могут взаимодействовать друг с другом через localhost.

Пример манифеста пода (YAML):

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mycontainer
    image: myimage:latest
    ports:
    - containerPort: 80

🤔 Основные различия

1️⃣ Уровень абстракции:
- Контейнер — это отдельная изолированная среда выполнения приложения.
- Под — это абстракция Kubernetes, объединяющая один или несколько контейнеров.

2️⃣ Совместное использование ресурсов:
- Контейнеры не делятся сетевым пространством и томами по умолчанию.
- Контейнеры в поде делят сетевое пространство и могут обмениваться данными через общие тома.

3️⃣ Управление и оркестрация:
- Контейнеры управляются такими инструментами, как Docker.
- Поды управляются Kubernetes, который заботится об их создании, масштабировании, перезапуске и удалении.

4️⃣ Жизненный цикл:
- Контейнеры могут существовать независимо от Kubernetes.
- Поды управляются и контролируются Kubernetes, и они могут быть перезапущены или перемещены на другие узлы.

🤔 Краткое резюме

- Контейнер — изолированная среда выполнения для приложения и его зависимостей.

- Под — базовая единица развертывания в Kubernetes, содержащая один или несколько контейнеров с общими ресурсами (сеть, тома).

- Контейнеры в поде делят сетевые и файловые ресурсы и управляются Kubernetes для обеспечения высокой доступности и масштабируемости.

🔥 ТОП ВОПРОСОВ С СОБЕСОВ

🔒 База собесов | 🔒 База тестовых

📌 Как используешь секреты?

💬 Спрашивают в 13% собеседований

Использование секретов в Kubernetes (Kubernetes Secrets) — это важная практика для безопасного управления конфиденциальными данными, такими как пароли, токены доступа, ключи API и другие чувствительные данные. Вот как можно использовать секреты в Kubernetes:

🤔 Создание секретов

Секреты в Kubernetes могут быть созданы различными способами, включая использование командной строки kubectl, файлов YAML или напрямую через API.

1️⃣ Создание секретов с помощью командной строки kubectl

Команда kubectl create secret позволяет создать секреты из текстовых значений или файлов.

Пример создания секрета с именем mysecret из текстового значения:

kubectl create secret generic mysecret --from-literal=username=myuser --from-literal=password=mypassword

Пример создания секрета из файла:

kubectl create secret generic mysecret --from-file=path/to/secret/file

2️⃣ Создание секретов с помощью YAML-файла

Секреты можно описать в YAML-файле и применить с помощью команды kubectl apply.

Пример секрета, описанного в YAML:

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  username: bXl1c2Vy   # base64-encoded value of "myuser"
  password: bXlwYXNzd29yZA==   # base64-encoded value of "mypassword"

Чтобы создать секрет из этого файла, необходимо применить его

kubectl apply -f secret.yaml

🤔 Использование секретов в подах

Секреты могут быть использованы в подах несколькими способами:

1️⃣ Использование секретов как переменные окружения

Пример манифеста пода с использованием секретов как переменных окружения:

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mycontainer
    image: myimage:latest
    env:
    - name: USERNAME
      valueFrom:
        secretKeyRef:
          name: mysecret
          key: username
    - name: PASSWORD
      valueFrom:
        secretKeyRef:
          name: mysecret
          key: password

2️⃣ Использование секретов как тома

Пример манифеста пода с использованием секретов как тома:

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mycontainer
    image: myimage:latest
    volumeMounts:
    - name: secret-volume
      mountPath: /etc/secret
      readOnly: true
  volumes:
  - name: secret-volume
    secret:
      secretName: mysecret

В этом примере секреты будут смонтированы в поде в виде файлов в каталоге /etc/secret.

🤔 Обновление секретов

Секреты можно обновить с помощью команды kubectl apply или kubectl create secret с флагом --dry-run=client -o yaml для генерации YAML, который затем можно изменить и применить.

🤔 Безопасность секретов

1️⃣ Ограничение доступа: Используйте роли и политики RBAC для ограничения доступа к секретам.

2️⃣ Шифрование на уровне кластера: Включите шифрование секретов на уровне etcd.

3️⃣ Минимизация использования: Используйте секреты только там, где это необходимо, и избегайте их хранения в виде простого текста.

🤔 Краткое резюме

- Создание: Секреты можно создавать с помощью kubectl или YAML-файлов.

- Использование: Секреты можно использовать как переменные окружения или тома в подах.

- Обновление и безопасность: Обновляйте секреты безопасно и ограничивайте доступ к ним с помощью RBAC и шифрования.

🔥 ТОП ВОПРОСОВ С СОБЕСОВ

🔒 База собесов | 🔒 База тестовых

📌 Что за компонент kubelet?

💬 Спрашивают в 13% собеседований

🤔 Что такое kubelet

kubelet — это важный компонент в архитектуре Kubernetes, который отвечает за выполнение подов на каждом узле (Node) кластера. Он управляет жизненным циклом контейнеров и гарантирует, что они работают в соответствии с определенными спецификациями.

🤔 Основные функции kubelet

1️⃣ Управление подами: kubelet получает инструкции от API-сервера и создает или удаляет контейнеры на узле, чтобы соответствовать этим инструкциям.

2️⃣ Мониторинг состояния подов: kubelet постоянно проверяет состояние подов и контейнеров, чтобы убедиться, что они работают правильно.

3️⃣ Обеспечение соответствия спецификации: kubelet сравнивает текущее состояние подов с заданной спецификацией и при необходимости предпринимает действия для восстановления соответствия.

4️⃣ Сбор метрик и логов: kubelet собирает метрики и логи с контейнеров и отправляет их в систему мониторинга.

5️⃣ Работа с контейнерными рантаймами: kubelet взаимодействует с контейнерными рантаймами (например, Docker, containerd, CRI-O) для запуска и управления контейнерами.

🤔 Как работает kubelet

1️⃣ Регистрация узла

При запуске kubelet регистрирует узел в API-сервере Kubernetes, предоставляя информацию о ресурсах узла, таких как количество процессоров, объем памяти и состояние дисков.

2️⃣ Получение инструкций от API-сервера

kubelet регулярно обращается к API-серверу, чтобы получить обновления о желаемом состоянии подов, которые должны быть запущены на узле. Эти инструкции включают информацию о том, какие поды создавать, какие удалять и какие обновлять.

3️⃣ Создание и управление подами

На основе полученных инструкций kubelet взаимодействует с контейнерным рантаймом для создания, удаления и управления контейнерами. Он также монтирует тома, устанавливает сети и выполняет другие необходимые действия для настройки подов.

4️⃣ Проверка состояния подов и контейнеров

kubelet периодически проверяет состояние подов и контейнеров, используя механизмы, такие как liveness и readiness пробы. Если какой-либо контейнер или под не работает должным образом, kubelet пытается перезапустить его или уведомляет API-сервер о проблеме.

5️⃣ Сбор и отправка метрик и логов

kubelet собирает метрики и логи контейнеров и отправляет их в систему мониторинга и логирования (например, Prometheus, ELK Stack), чтобы администраторы могли отслеживать состояние приложений и инфраструктуры.

🤔 Пример конфигурации kubelet

Конфигурация kubelet обычно задается через параметры командной строки или с использованием файла конфигурации. Пример простого файла конфигурации kubelet:

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
address: 0.0.0.0
port: 10250
authentication:
  anonymous:
    enabled: false
  webhook:
    enabled: true
  x509:
    clientCAFile: "/etc/kubernetes/pki/ca.crt"
authorization:
  mode: Webhook
clusterDNS:
  - 10.96.0.10
clusterDomain: cluster.local
failSwapOn: false
cgroupDriver: cgroupfs
runtimeRequestTimeout: "15m"

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

- address: IP-адрес, на котором kubelet слушает запросы.

- port: Порт для связи с kubelet.

- authentication: Настройки аутентификации.

- authorization: Настройки авторизации.

- clusterDNS: Адреса DNS-серверов кластера.

- clusterDomain: Доменное имя кластера.

- failSwapOn: Остановка kubelet, если включен swap.

- cgroupDriver: Драйвер cgroup для контейнеров.

- runtimeRequestTimeout: Тайм-аут запросов к контейнерному рантайму.

🤔 Краткое резюме

kubelet — это агент на каждом узле кластера Kubernetes, отвечающий за запуск и управление подами, мониторинг их состояния, взаимодействие с контейнерными рантаймами и сбор метрик. Он играет ключевую роль в обеспечении работоспособности и согласованности состояния приложений в кластере Kubernetes.

🔥 ТОП ВОПРОСОВ С СОБЕСОВ

🔒 База собесов | 🔒 База тестовых

📌 Расскажи про разницу PVC и full stack?

💬 Спрашивают в 13% собеседований

🤔 Разница между PVC (Persistent Volume Claim) и Full Stack

Понимание этих двух терминов поможет нам различить их предназначение и использование в контексте Kubernetes и программного обеспечения.

🤔 PVC (Persistent Volume Claim)

PVC (Persistent Volume Claim) — это объект в Kubernetes, который позволяет пользователям запрашивать выделение постоянного хранилища для подов. PVC абстрагирует детали физического хранилища, позволяя разработчикам и администраторам фокусироваться на объеме и типе хранилища, необходимого для приложения, без необходимости управлять деталями самого хранилища.

🤔 Основные аспекты PVC

1️⃣ Запрос хранилища: PVC определяет запрос на объем хранилища и его характеристики, такие как размер и класс хранилища (Storage Class).

2️⃣ Абстракция хранилища: PVC абстрагирует конкретные детали физического хранилища, предоставляя единый интерфейс для запросов хранилища.

3️⃣ Динамическое и статическое связывание: PVC может использовать как динамическое связывание (где Kubernetes автоматически создает PV на основе PVC), так и статическое связывание (где администраторы заранее создают PV).

4️⃣ Совместимость с подами: PVC могут быть подключены к подам, обеспечивая постоянное хранилище для приложений.

Пример PVC в YAML:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  storageClassName: standard

🤔 Full Stack

Full Stack — это термин, используемый для описания разработчиков или инженеров, которые обладают навыками и знаниями для работы со всеми уровнями разработки программного обеспечения, от фронтенда до бэкенда, включая базы данных, серверы и даже DevOps практики.

🤔 Основные аспекты Full Stack разработки

1️⃣ Фронтенд: Создание пользовательских интерфейсов с использованием HTML, CSS, JavaScript и фреймворков, таких как React, Angular или Vue.js.

2️⃣ Бэкенд: Разработка серверной логики и API с использованием языков программирования, таких как Python, Node.js, Ruby, Java или PHP.

3️⃣ Базы данных: Работа с реляционными (например, MySQL, PostgreSQL) и нереляционными (например, MongoDB, Redis) базами данных.

4️⃣ DevOps: Управление развертыванием, настройкой серверов, CI/CD пайплайнами, мониторингом и масштабированием приложений.

5️⃣ Сетевые технологии: Понимание протоколов, таких как HTTP/HTTPS, REST, WebSockets, и работа с серверными технологиями, такими как Nginx или Apache.

🤔 Пример стека технологий Full Stack разработчика

- Фронтенд: React, Redux, Webpack, Sass

- Бэкенд: Node.js, Express, Python, Django

- Базы данных: PostgreSQL, MongoDB

- DevOps: Docker, Kubernetes, Jenkins, Terraform

- Сетевые технологии: Nginx, REST API

🤔 Краткое резюме

- PVC (Persistent Volume Claim): Объект в Kubernetes, запрашивающий выделение постоянного хранилища для подов. Он абстрагирует детали физического хранилища и обеспечивает постоянное хранилище для приложений.

- Full Stack: Термин, описывающий разработчиков, обладающих навыками работы со всеми уровнями разработки программного обеспечения, от фронтенда до бэкенда, включая базы данных и DevOps практики.

🔥 ТОП ВОПРОСОВ С СОБЕСОВ

🔒 База собесов | 🔒 База тестовых

📌 Этапы загрузки в linux и загрузчики?

💬 Спрашивают в 13% собеседований

🤔 Этапы загрузки в Linux и загрузчики

Загрузка Linux включает несколько ключевых этапов, начиная от включения питания до полной готовности операционной системы. Важно понимать эти этапы для диагностики и устранения неполадок на ранних стадиях загрузки. Основные этапы загрузки включают:

1️⃣ BIOS/UEFI

2️⃣ MBR/GPT и загрузчик (Bootloader)

3️⃣ Загрузочный менеджер (Boot Manager)

4️⃣ Инициализация ядра (Kernel Initialization)

5️⃣ init system (Система инициализации)

🤔 1. BIOS/UEFI

BIOS (Basic Input/Output System) или UEFI (Unified Extensible Firmware Interface) — это первый этап загрузки системы. Они выполняют следующие функции:

- POST (Power-On Self Test): Проверка аппаратного обеспечения на наличие ошибок.

- Поиск загрузочного устройства: Определение устройства, с которого будет загружена операционная система (жесткий диск, SSD, CD/DVD, USB и т.д.).

🤔 2. MBR/GPT и загрузчик

После того как BIOS/UEFI определяет загрузочное устройство, управление передается на первый сектор диска — MBR (Master Boot Record) или GPT (GUID Partition Table), в зависимости от типа разметки диска.

🤔 MBR:
- Первый сектор диска (512 байт) содержит загрузочную запись и таблицу разделов.

- Содержит код начальной загрузки, который загружает основной загрузчик (например, GRUB).

🤔 GPT:
- Используется на более современных системах, поддерживает большее количество разделов и большие объемы дисков.

- Содержит защитный MBR и несколько копий таблицы разделов для повышения надежности.

🤔 3. Загрузочный менеджер (Boot Manager)

GRUB (GRand Unified Bootloader) — самый распространенный загрузочный менеджер в Linux, хотя существуют и другие, такие как LILO и Syslinux.

Функции GRUB:

- Отображение меню загрузки, где пользователь может выбрать операционную систему или ядро для загрузки.

- Загрузка выбранного ядра в память и передача ему управления.

Пример конфигурационного файла GRUB (/boot/grub/grub.cfg):

menuentry 'Ubuntu' {
    set root='(hd0,1)'
    linux /vmlinuz root=/dev/sda1 ro quiet splash
    initrd /initrd.img
}

🤔 4. Инициализация ядра (Kernel Initialization)

Когда ядро загружено в память, оно выполняет следующие действия:

- Аппаратная инициализация: Настройка аппаратных компонентов системы.

- Монтаж корневой файловой системы: Ядро монтирует корневую файловую систему в режиме только для чтения.

- Запуск initramfs: Временная файловая система, содержащая необходимые драйверы и утилиты для монтирования основной корневой файловой системы.

🤔 5. init system (Система инициализации)

Система инициализации — это первый процесс, который запускается ядром после завершения его инициализации. Самые распространенные системы инициализации:

- systemd: Современная система инициализации, используемая в большинстве современных дистрибутивов Linux.

- SysVinit: Старая система инициализации, до сих пор используемая в некоторых дистрибутивах.

- Upstart: Разработана Canonical для Ubuntu, используется в некоторых старых версиях.

Функции системы инициализации:
- Запуск фоновых служб (демонов).
- Настройка среды пользователя.
- Управление процессами и службами в системе.

Пример systemd unit файла (/etc/systemd/system/example.service):

[Unit]
Description=Example Service

[Service]
ExecStart=/usr/bin/example

[Install]
WantedBy=multi-user.target

🤔 Краткое резюме

1️⃣ BIOS/UEFI: Инициализация аппаратного обеспечения и поиск загрузочного устройства.

2️⃣ MBR/GPT и загрузчик: Загрузка и передача управления загрузочному менеджеру.

3️⃣ Загрузочный менеджер (GRUB): Выбор и загрузка ядра операционной системы.

4️⃣ Инициализация ядра: Аппаратная настройка и монтирование корневой файловой системы.

5️⃣ init system: Запуск служб и управление процессами в системе.

Знание этих этапов помогает эффективно диагностировать и устранять проблемы, возникающие на различных стадиях загрузки операционной системы Linux.

🔥 ТОП ВОПРОСОВ С СОБЕСОВ

🔒 База собесов | 🔒 База тестовых

📌 Опишите идеальный конвейер?

💬 Спрашивают в 13% собеседований

🤔 Идеальный конвейер (CI/CD Pipeline) в DevOps

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

1️⃣ Управление исходным кодом

🤔 Инструменты:
- Git (с репозиториями на GitHub, GitLab, Bitbucket)

🤔 Особенности:
- Branching Strategy: Использование стратегий ветвления (например, Git Flow, GitHub Flow) для управления разработкой функций, исправлений и релизов.

- Code Reviews: Обязательные проверки кода (code review) перед слиянием веток.

2️⃣ Автоматическая сборка (Build)

🤔 Инструменты:
- Jenkins, GitLab CI/CD, GitHub Actions, Travis CI, CircleCI

🤔 Особенности:
- Сборка на каждом коммите: Автоматическая сборка проекта при каждом коммите или pull request.

- Управление зависимостями: Установка и управление зависимостями проекта (например, с использованием Maven, Gradle, npm, pip).

3️⃣ Статический анализ кода

🤔 Инструменты:
- SonarQube, ESLint, Pylint, Checkstyle

🤔 Особенности:
- Линтинг и форматирование: Автоматический анализ кода на соответствие стилю и выявление потенциальных ошибок.

- Quality Gates: Определение порогов качества, которые код должен пройти перед слиянием.

4️⃣ Автоматическое тестирование

🤔 Инструменты:
- JUnit, Selenium, PyTest, JUnit, Mocha

🤔 Особенности:
- Unit Tests: Автоматическое выполнение модульных тестов для проверки отдельных компонентов.

- Integration Tests: Проверка взаимодействия различных частей системы.

- End-to-End Tests: Тестирование приложения как целого, имитируя реального пользователя.

5️⃣ Сборка артефактов

🤔 Инструменты:
- Docker, Jenkins Artifactory, Nexus Repository

🤔 Особенности:
- Создание артефактов: Создание исполняемых файлов, Docker-образов и других артефактов после успешного прохождения тестов.

- Артефакт-репозиторий: Хранение артефактов в централизованном репозитории.

6️⃣ Развертывание (Deployment)

🤔 Инструменты:
- Kubernetes, Helm, Ansible, Terraform

🤔 Особенности:
- Инфраструктура как код (IaC): Определение инфраструктуры в виде кода для автоматизации развертывания.

- Автоматическое развертывание: Автоматизация развертывания на различных средах (development, staging, production).

- Canary Releases и Blue-Green Deployment: Подходы для минимизации рисков при развертывании новых версий.

7️⃣ Мониторинг и алертинг

🤔 Инструменты:
- Prometheus, Grafana, ELK Stack (Elasticsearch, Logstash, Kibana), Splunk

🤔 Особенности:
- Мониторинг метрик: Сбор и анализ метрик производительности и состояния системы.

- Алертинг: Настройка алертов для уведомления команды о проблемах в реальном времени.

8️⃣ Обратная связь и улучшение

🤔 Инструменты:
- Slack, JIRA, Confluence

🤔 Особенности:
- Обратная связь: Быстрая обратная связь от системы мониторинга и тестирования.

- Интеграция с таск-трекерами: Автоматическое создание задач и уведомлений при обнаружении проблем.

- Отчеты и аналитика: Регулярные отчеты о состоянии системы и качестве кода для улучшения процессов.

🤔 Пример идеального конвейера в GitLab CI/CD

stages:
  - build
  - test
  - lint
  - package
  - deploy
  - monitor

variables:
  DOCKER_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA

build:
  stage: build
  script:
    - ./build.sh

test:
  stage: test
  script:
    - ./run-tests.sh

lint:
  stage: lint
  script:
    - ./lint.sh

package:
  stage: package
  script:
    - docker build -t $DOCKER_IMAGE .
    - docker push $DOCKER_IMAGE

deploy:
  stage: deploy
  script:
    - ./deploy.sh

monitor:
  stage: monitor
  script:
    - ./monitor.sh

🤔 Краткое резюме

Идеальный конвейер включает в себя автоматизацию всех этапов разработки, от управления исходным кодом до мониторинга развернутых приложений. Основные этапы включают сборку, тестирование, статический анализ, упаковку, развертывание и мониторинг, обеспечивая высокое качество и стабильность выпускаемого ПО.

🔥 ТОП ВОПРОСОВ С СОБЕСОВ

🔒 База собесов | 🔒 База тестовых

📌 Какие команды знаешь?

💬 Спрашивают в 13% собеседований

🤔 Git

- git init: Инициализация нового репозитория.
- git clone <url>: Клонирование репозитория.
- git add <file>: Добавление файла к коммиту.
- git commit -m "сообщение": Создание коммита.
- git push: Отправка изменений.
- git pull: Получение изменений.
- git branch: Список веток.
- git checkout <branch>: Переключение ветки.

🤔 Docker

- docker build -t <image_name> .: Создание образа.
- docker run -d -p 80:80 <image_name>: Запуск контейнера.
- docker ps: Список контейнеров.
- docker stop <container_id>: Остановка контейнера.
- docker rm <container_id>: Удаление контейнера.
- docker images: Список образов.
- docker rmi <image_id>: Удаление образа.

🤔 Kubernetes (kubectl)

- kubectl get pods: Список подов.
- kubectl get services: Список сервисов.
- kubectl describe pod <pod_name>: Информация о поде.
- kubectl logs <pod_name>: Логи пода.
- kubectl apply -f <file.yaml>: Применение конфигурации.
- kubectl delete pod <pod_name>: Удаление пода.
- kubectl exec -it <pod_name> -- /bin/bash: Подключение к поду.

🤔 Ansible

- ansible-playbook <playbook.yml>: Запуск плейбука.
- ansible <host> -m ping: Проверка хостов.
- ansible <host> -m command -a 'uptime': Выполнение команды.
- ansible-galaxy install <role>: Установка роли.

🤔 Terraform

- terraform init: Инициализация.
- terraform plan: Планирование изменений.
- terraform apply: Применение изменений.
- terraform destroy: Удаление ресурсов.

🤔 Linux (bash)

- ls: Список файлов.
- cd <directory>: Перемещение в каталог.
- pwd: Текущий каталог.
- cp <source> <destination>: Копирование файлов.
- mv <source> <destination>: Перемещение файлов.
- rm <file>: Удаление файла.
- mkdir <directory>: Создание каталога.
- grep <pattern> <file>: Поиск шаблона.
- find <directory> -name <pattern>: Поиск файлов.
- chmod <permissions> <file>: Изменение прав.
- chown <user>:<group> <file>: Изменение владельца.
- top: Мониторинг процессов.
- ps aux: Список процессов.

🤔 CI/CD (GitLab, Jenkins, GitHub Actions)

🤔 GitLab CI/CD:
- .gitlab-ci.yml: Конфигурация пайплайна.
- gitlab-runner register: Регистрация Runner.
- gitlab-runner list: Список Runner.

🤔 Jenkins:
- jenkins-cli.jar: Утилита CLI.
- jenkins-jobs create <job_name>: Создание задачи.
- jenkins-jobs build <job_name>: Запуск задачи.
- jenkins-jobs list: Список задач.

🤔 GitHub Actions:
- workflow_dispatch: Ручной запуск.
- .github/workflows/<workflow>.yml: Конфигурация workflow.

🤔 Пример CI/CD пайплайна в GitLab CI/CD

stages:
  - build
  - test
  - deploy

build:
  stage: build
  script:
    - echo "Building..."
    - ./build.sh

test:
  stage: test
  script:
    - echo "Testing..."
    - ./test.sh

deploy:
  stage: deploy
  script:
    - echo "Deploying..."
    - ./deploy.sh

🤔 Краткое резюме

Эти команды охватывают управление версиями, контейнеризацию, оркестрацию, автоматизацию развертывания и администрирование систем. Знание этих команд помогает эффективно управлять процессами разработки и эксплуатации ПО.

🔥 ТОП ВОПРОСОВ С СОБЕСОВ

🔒 База собесов | 🔒 База тестовых

📌 Как посчитать размер node в кубах?

💬 Спрашивают в 13% собеседований

Для определения размера узла (node) в кластере Kubernetes необходимо собрать информацию о различных ресурсах, таких как количество процессоров (CPU), объем оперативной памяти (RAM) и объем дискового пространства, доступные на узле. Эти данные можно получить с помощью команды kubectl.

🤔 Шаги для определения размера узла

1️⃣ Получение списка узлов

Для начала необходимо получить список узлов в кластере:

kubectl get nodes

2️⃣ Получение информации о ресурсе узла

Для каждого узла из списка можно получить подробную информацию о ресурсах с помощью команды kubectl describe node <node-name>:

kubectl describe node <node-name>

Эта команда предоставит информацию о доступных и используемых ресурсах, таких как CPU, память и дисковое пространство.

3️⃣ Получение информации о ресурсах узлов в формате JSON/YAML

Чтобы получить информацию о ресурсах узлов в удобном для обработки формате (JSON или YAML), можно использовать команду kubectl get node <node-name> -o json или kubectl get node <node-name> -o yaml:

kubectl get node <node-name> -o json

🤔 Пример вывода команды

{
    "kind": "Node",
    "apiVersion": "v1",
    "metadata": {
        "name": "node1"
    },
    "status": {
        "capacity": {
            "cpu": "4",
            "memory": "16384000Ki",
            "ephemeral-storage": "100Gi"
        },
        "allocatable": {
            "cpu": "4",
            "memory": "16334000Ki",
            "ephemeral-storage": "98Gi"
        }
    }
}

🤔 Расчет размера узла

- CPU: Количество процессоров.
- Memory: Объем оперативной памяти (в Ki, где 1 Ki = 1024 байт).

- Ephemeral Storage: Объем временного дискового пространства.

🤔 Пример расчета

Допустим, узел имеет следующие ресурсы:

- CPU: 4
- Memory: 16334000Ki (примерно 15.58 GiB)
- Ephemeral Storage: 98Gi

🤔 Конвертация памяти

Память в Kubernetes часто указывается в КиБ (Kibibytes). Для конвертации в гигабайты (GiB) используется следующая формула:

\[ \text{Memory (GiB)} = \frac{\text{Memory (KiB)}}{1024 \times 1024} \]

Пример:

\[ \text{Memory (GiB)} = \frac{16334000}{1024 \times 1024} \approx 15.58 \]

🤔 Объединение всех данных

В результате, размер узла можно представить как:

- CPU: 4
- Memory: 15.58 GiB
- Ephemeral Storage: 98 GiB

🤔 Пример команд для автоматизации

Если необходимо собрать и обработать данные для всех узлов в кластере, можно использовать скрипт. Например, на bash с использованием jq для обработки JSON:

#!/bin/bash

nodes=$(kubectl get nodes -o json | jq -r '.items[].metadata.name')

for node in $nodes; do
  echo "Node: $node"
  kubectl get node $node -o json | jq '.status.capacity, .status.allocatable'
  echo ""
done

🤔 Краткое резюме

Для определения размера узла (node) в Kubernetes, используйте команды kubectl get nodes, kubectl describe node <node-name> и kubectl get node <node-name> -o json для получения информации о CPU, памяти и дисковом пространстве. Переведите данные о памяти из Ki в GiB для удобства и объедините все данные для полного представления ресурсов узла.

🔥 ТОП ВОПРОСОВ С СОБЕСОВ

🔒 База собесов | 🔒 База тестовых

📌 Как осуществляли деплой на kubernetes?

💬 Спрашивают в 13% собеседований

🤔 Осуществление деплоя на Kubernetes

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

🤔 Шаги для деплоя на Kubernetes

1️⃣ Подготовка Docker-образа

Первый шаг — подготовить Docker-образ приложения. Пример Dockerfile:

# Используем официальный образ Python
FROM python:3.8-slim

# Устанавливаем рабочую директорию
WORKDIR /app

# Копируем все файлы в контейнер
COPY . /app

# Устанавливаем зависимости
RUN pip install --no-cache-dir -r requirements.txt

# Определяем команду запуска
CMD ["python", "app.py"]

Создание и загрузка Docker-образа в Docker Hub:

docker build -t username/myapp:latest .
docker push username/myapp:latest

2️⃣ Создание конфигурационных файлов Kubernetes

Для развертывания приложения на Kubernetes, необходимо создать манифесты для деплоя (Deployment), сервиса (Service) и других необходимых ресурсов.

🤔 Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: username/myapp:latest
        ports:
        - containerPort: 80

🤔 Service

apiVersion: v1
kind: Service
metadata:
  name: myapp-service
spec:
  type: LoadBalancer
  selector:
    app: myapp
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80

3️⃣ Применение конфигураций

Применение манифестов для создания ресурсов в кластере Kubernetes:

kubectl apply -f deployment.yaml
kubectl apply -f service.yaml

4️⃣ Проверка статуса

Проверка статуса развертывания и сервисов:

kubectl get deployments
kubectl get services
kubectl get pods

5️⃣ Настройка автоскейлинга (по желанию)

Для обеспечения высокой доступности и масштабируемости можно настроить горизонтальное авто-масштабирование:

kubectl autoscale deployment myapp-deployment --cpu-percent=50 --min=1 --max=10

6️⃣ Обновление приложения

Для обновления приложения необходимо изменить образ в деплойменте и применить изменения:

Обновление Docker-образа:

docker build -t username/myapp:v2 .
docker push username/myapp:v2

Обновление манифеста Deployment:

spec:
  template:
    spec:
      containers:
      - name: myapp
        image: username/myapp:v2

Применение изменений:

kubectl apply -f deployment.yaml

🤔 Пример полного пайплайна CI/CD с использованием GitLab CI/CD

Пример .gitlab-ci.yml для автоматизации деплоя:

stages:
  - build
  - push
  - deploy

variables:
  DOCKER_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG

build:
  stage: build
  script:
    - docker build -t $DOCKER_IMAGE .
  only:
    - main

push:
  stage: push
  script:
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    - docker push $DOCKER_IMAGE
  only:
    - main

deploy:
  stage: deploy
  script:
    - kubectl apply -f deployment.yaml
    - kubectl apply -f service.yaml
  only:
    - main

🤔 Краткое резюме

1️⃣ Создание Docker-образа: Написание Dockerfile и загрузка образа в Docker Hub.

2️⃣ Подготовка манифестов Kubernetes: Создание YAML-файлов для Deployment и Service.

3️⃣ Применение конфигураций: Использование kubectl apply для развертывания ресурсов.

4️⃣ Проверка статуса: Команды kubectl get для проверки состояния деплоя.

5️⃣ Настройка автоскейлинга: Опционально, настройка горизонтального авто-масштабирования.

6️⃣ Автоматизация: Использование CI/CD систем, таких как GitLab CI/CD, для автоматизации процесса сборки и деплоя.

🔥 ТОП ВОПРОСОВ С СОБЕСОВ

🔒 База собесов | 🔒 База тестовых