🤔 Зачем нужен OOM

OOM (Out Of Memory) — это механизм, срабатывающий, когда системе не хватает памяти для работы, что приводит к завершению процессов с высокой нагрузкой. Он защищает систему от полного исчерпания памяти, освобождая ресурсы, чтобы другие процессы могли продолжать работать. OOM-killer используется для выбора и завершения наименее критичных процессов, предотвращая полное зависание системы.

Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний

🤔 В чем разница Deployment и DaemonSet?

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

🚩Deployment

Это контроллер, который обеспечивает декларативное обновление подов и ReplicaSets (другой тип контроллера, который управляет одновременным запуском нескольких экземпляров одного и того же пода). Deployment поддерживает непрерывное развертывание, откат к предыдущим версиям, а также масштабирование подов.

🟠Масштабирование
Вы можете увеличивать или уменьшать количество подов в зависимости от нужд.
🟠Обновления
Поддерживает стратегии развертывания, такие как Rolling Update (постепенное обновление), которое помогает минимизировать простои при обновлении приложения.
🟠Самовосстановление
Автоматически перезапускает поды, которые перестали работать, находятся в ошибочном состоянии или не отвечают.

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

🚩DaemonSet

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

🟠Гарантия запуска
Убедитесь, что каждый узел кластера запускает копию определённого пода.
🟠Автоматическое размещение
Когда добавляются новые узлы, на них автоматически размещаются необходимые поды.
🟠Службы уровня узла
Идеально подходит для запуска системных служб, таких как коллекторы логов, системы мониторинга и другие.

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd-elasticsearch
spec:
  selector:
    matchLabels:
      name: fluentd-elasticsearch
  template:
    metadata:
      labels:
        name: fluentd-elasticsearch
    spec:
      containers:
      - name: fluentd-elasticsearch
        image: fluent/fluentd:v1.0
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        - name: varlibdockercontainers
          mountPath: /var/lib/docker/containers
          readOnly: true

Ставь 👍 и забирай 📚 Базу знаний

🤔 Какие типы заголовков есть?

Заголовки в HTTP делятся на:
- General — общие (Date, Connection);
- Request — только для клиента (Accept, User-Agent, Authorization);
- Response — только для ответа (Server, Set-Cookie);
- Entity — описывают тело (Content-Type, Content-Length).

Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний

🤔 Что произойдет если под не пройдет readiness пробу?

Если под (Pod) в Kubernetes не пройдет readiness-пробу (readiness probe), он будет считаться не готовым для обработки запросов.

🚩Что делает readiness-проба?

Readiness-проба используется для определения того, готов ли контейнер в поде обрабатывать входящие запросы. Если проба не проходит, Kubernetes исключает этот под из списка доступных для обслуживания запросов (например, через Service).

🚩Основные последствия

🟠Под не будет получать трафик через Service
Kubernetes автоматически исключает под из группы Endpoints для соответствующего сервиса. Другие компоненты системы, обращающиеся к сервису, не будут направлять запросы в этот под.

🟠Под продолжает работать
Под не будет удален или перезапущен. Kubernetes продолжит проверять его состояние readiness-пробой до тех пор, пока он не станет готовым.

🟠Нет влияния на liveness-пробу
Если readiness-проба не проходит, это не влияет на liveness-пробу. Под будет работать, пока не нарушена его "жизнеспособность".

🟠Аварийное поведение приложения может быть скрыто
Если под зависнет или будет не в состоянии обработать запросы, но при этом не нарушит liveness-пробу, он останется запущенным, но не будет получать трафик.

🚩Как это выглядит на практике?

Пример readiness-пробы

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: my-container
    image: nginx
    readinessProbe:
      httpGet:
        path: /
        port: 80
      initialDelaySeconds: 5
      periodSeconds: 10

🚩Сценарий

🟠На старте
После создания пода Kubernetes ждет initialDelaySeconds (5 секунд) перед выполнением первой проверки. Если / не отвечает на HTTP-запрос, под считается не готовым.

🟠Если проба продолжает проваливаться
Kubernetes исключает под из группы доступных эндпоинтов. Под остается запущенным, и проба выполняется каждые periodSeconds (10 секунд), пока под не станет готовым.

🚩Что произойдет с трафиком?

Если под — единственный в сервисе: Запросы к сервису вернут ошибку (например, 503 Service Unavailable), так как ни один под не готов.
Если подов несколько: Трафик перенаправляется на другие поды, готовые обрабатывать запросы.

🚩Как это помогает?

🟠Обеспечивает стабильность приложения
Под начинает обрабатывать трафик только после полной инициализации.

🟠Улучшает отказоустойчивость
В случае проблем с подом система перенаправляет запросы на другие экземпляры.

🟠Поддерживает обновления без простоя
Во время обновления подов через Deployment новые поды добавляются в пул доступных только после успешного прохождения readiness-проб.

Ставь 👍 и забирай 📚 Базу знаний

🤔 Нужно ли базу данных помещать в Kubernetes, если нужно, то почему?

Базы данных можно запускать в Kubernetes для повышения удобства управления, масштабирования и использования облачных возможностей. Однако для критически важных данных лучше использовать managed database services, чтобы снизить административные риски.

Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний

🤔 Что такое лямбда выражение в Phyton?

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

Синтаксис

lambda аргументы: выражение

🚩Примеры

Простая лямбда-функция

add = lambda x, y: x + y
print(add(3, 5))  # Выведет: 8

Эквивалентно обычной функции

def add(x, y):
    return x + y

Лямбда внутри map()

nums = [1, 2, 3, 4]
squares = list(map(lambda x: x ** 2, nums))
print(squares)  # [1, 4, 9, 16]

Лямбда внутри sorted()

words = ["apple", "banana", "kiwi"]
sorted_words = sorted(words, key=lambda w: len(w))
print(sorted_words)  # ['kiwi', 'apple', 'banana']

Ставь 👍 и забирай 📚 Базу знаний

🤔 Чем методы REST отличаются?

Методы REST различаются по назначению и идемпотентности:
- GET — для чтения данных, безопасен и идемпотентен;
- POST — для создания ресурса, не идемпотентен;
- PUT — для полного обновления ресурса, идемпотентен;
- PATCH — для частичного обновления;
- DELETE — для удаления, идемпотентен;
- OPTIONS, HEAD — вспомогательные методы для получения метаинформации.

Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний

🤔 Какие есть лучшие практики в использовании инструкции add и copy?

ADD и COPY — это инструкции Dockerfile, которые копируют файлы в контейнер. Их использование влияет на размер образа, безопасность и производительность сборки.

🚩Лучшие практики по использованию `COPY` и `ADD`

🟠Используйте `COPY` вместо `ADD`, если не нужно распаковывать архивы
Плохо (избыточное использование ADD)

ADD app.tar.gz /app/

Хорошо (явное распаковывание в RUN)

COPY app.tar.gz /tmp/
RUN tar -xzf /tmp/app.tar.gz -C /app && rm /tmp/app.tar.gz

🟠Минимизируйте число `COPY` и `ADD`, чтобы уменьшить размер образа
Плохо (копируем всё без исключений)

COPY . /app

Хорошо (копируем только нужные файлы)

COPY src/ /app/src/
COPY requirements.txt /app/

Добавьте .dockerignore

.git
node_modules
__pycache__
*.log

🟠Копируйте только изменяемые файлы, чтобы ускорить кэширование
Плохо (изменение кода приводит к пересборке зависимостей)**

COPY . /app
RUN pip install -r /app/requirements.txt

Хорошо (сначала зависимости, потом код)

COPY requirements.txt /app/
RUN pip install -r /app/requirements.txt

COPY src/ /app/src/

🟠Не используйте `ADD` для загрузки файлов из интернета
Плохо (ADD загружает файл, но не кэшируется)

ADD https://example.com/file.tar.gz /tmp/

🟠Хорошо (используем RUN curl + COPY)

RUN curl -L -o /tmp/file.tar.gz https://example.com/file.tar.gz
COPY file.tar.gz /app/

Ставь 👍 и забирай 📚 Базу знаний

🤔 Какой командой загрузить модуль ядра?

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

Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний

🤔 Как сделать так чтобы клиенты отдавали метрики в Prometheus?

В Prometheus данные собираются по pull-модели – сервер сам запрашивает метрики у клиентов. Чтобы клиенты отдавали метрики, нужно:

1. Настроить приложение на экспонирование метрик в формате Prometheus.
2. Добавить Prometheus job для сбора этих метрик.
3. Опционально – использовать Pushgateway, если pull-модель не подходит.

🚩Экспонирование метрик в формате Prometheus

Если приложение написано на Go, Python, Java или Node.js. Prometheus предлагает официальные клиентские библиотеки:
Go: [prometheus/client_golang](https://github.com/prometheus/client_golang)
Python: [prometheus_client](https://github.com/prometheus/client_python)
Java: [simpleclient](https://github.com/prometheus/client_java)
Node.js: [prom-client](https://github.com/siimon/prom-client)
Пример для Python

1⃣Установим библиотеку

pip install prometheus_client

2⃣Добавим в код экспонирование метрик

from prometheus_client import start_http_server, Counter
import time

# Создаем счетчик запросов
REQUEST_COUNT = Counter('app_requests_total', 'Total requests')

def process_request():
    REQUEST_COUNT.inc()  # Увеличиваем счетчик
    time.sleep(1)  # Имитация обработки запроса

if __name__ == '__main__':
    start_http_server(8000)  # Открываем метрики на 8000 порту
    while True:
        process_request()

🚩Пример для Node.js

1⃣Установим библиотеку:

npm install prom-client express

2⃣Код сервера:

const express = require('express');
const client = require('prom-client');

const app = express();
const collectDefaultMetrics = client.collectDefaultMetrics;
collectDefaultMetrics();

const requestCounter = new client.Counter({
  name: 'http_requests_total',
  help: 'Total HTTP requests',
});

app.get('/', (req, res) => {
  requestCounter.inc();
  res.send('Hello, World!');
});

app.get('/metrics', (req, res) => {
  res.set('Content-Type', client.register.contentType);
  res.end(client.register.metrics());
});

app.listen(3000, () => {
  console.log('Server running on port 3000');
});

🚩Настроить Prometheus для сбора метрик

Добавляем job в prometheus.yml

scrape_configs:
  - job_name: 'my_app'
    static_configs:
      - targets: ['app_host:8000']

🚩Push-модель через Pushgateway (если нужно)

Если клиент не может сам отдавать метрики (например, это краткоживущий job), можно использовать Pushgateway.

Запускаем Pushgateway:

docker run -d -p 9091:9091 prom/pushgateway

Отправляем метрики через curl

echo "job_execution_time 5.3" | curl --data-binary @- https://localhost:9091/metrics/job/my_batch_job

Настраиваем Prometheus на сбор данных из Pushgateway

scrape_configs:
  - job_name: 'pushgateway'
    static_configs:
      - targets: ['localhost:9091']

Ставь 👍 и забирай 📚 Базу знаний

🤔 Где Elasticsearch хранит логи?

Elasticsearch хранит данные в индексах (индекс — это аналог таблицы в реляционной БД), на диске в формате, совместимом с Lucene. По умолчанию данные находятся в директории /var/lib/elasticsearch.

Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний

🤔 Что такое data source в графане?

Это источник данных, с которым Grafana может взаимодействовать для построения графиков, панелей мониторинга (dashboards) и выполнения запросов. Data Source определяет, как Grafana подключается к внешним системам мониторинга, базам данных или API для получения метрик, логов или другой информации.

🚩Основные аспекты

🟠Типы Data Source
Grafana поддерживает множество типов источников данных, включая:
Системы мониторинга:
Prometheus
Zabbix
InfluxDB
Graphite
Лог-агрегаторы:
Loki
Elasticsearch
Splunk
Облачные сервисы:
AWS CloudWatch
Google Cloud Monitoring
Azure Monitor
Реляционные базы данных:
MySQL
PostgreSQL
API или внешние плагины:
JSON API
OpenTelemetry

🟠Функции Data Source
Подключение: Определяет параметры для соединения с внешним хранилищем данных, такие как URL, токены аутентификации, логин/пароль. Выполнение запросов: Обеспечивает интерфейс для написания запросов к данным через встроенный редактор запросов Grafana. Форматирование данных: Конвертирует данные из формата, предоставляемого источником, в формат, понятный Grafana.

🟠Добавление Data Source
Добавление источника данных выполняется через веб-интерфейс Grafana:
Зайдите в Settings → Data Sources.
Нажмите кнопку Add data source.
Выберите нужный тип источника (например, Prometheus).
Настройте параметры подключения (например, URL, токен, порт).
Нажмите Save & Test, чтобы проверить соединение.

🟠Примеры запросов
Для Prometheus:

rate(http_requests_total[5m])

Для MySQL

SELECT time, value FROM metrics WHERE time > NOW() - INTERVAL 1 HOUR;

🚩Особенности Data Source

🟠Кастомизация
Вы можете устанавливать плагины для подключения к нестандартным источникам данных. Grafana Marketplace предлагает плагины для расширения функциональности.

🟠Мульти-сорсинг
Один дашборд может использовать несколько источников данных, что позволяет объединять данные из разных систем.

🟠Глобальные переменные
Источники данных могут использовать глобальные параметры, такие как время ($__timeFilter), для унификации запросов.

🟠Безопасность
Поддержка различных методов аутентификации: токены, ключи API, OAuth.

Ставь 👍 и забирай 📚 Базу знаний

🤔 Из чего состоит ELK стек?

ELK включает в себя три компонента: Elasticsearch (хранение и поиск данных), Logstash (сбор и преобразование логов) и Kibana (визуализация данных). Вместе они обеспечивают централизованный сбор, хранение и анализ логов.

Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний