📌 В чём отличие Deployment от Delivery ?

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

Термины "Deployment" и "Delivery" часто используются в контексте процессов разработки ПО, особенно в рамках DevOps и непрерывных практик (CI/CD - Continuous Integration/Continuous Deployment или Continuous Delivery). Они имеют разные значения и цели в процессе доставки программного обеспечения.

🤔 Continuous Delivery (Непрерывная доставка)

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

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

🤔 Continuous Deployment (Непрерывное развертывание)

➕ Является расширением практики Continuous Delivery. В контексте Continuous Deployment каждое изменение, которое проходит все стадии автоматизированной сборки и тестирования, немедленно разворачивается в продуктивной среде. Таким образом, не требуется ручного одобрения для выпуска изменений.

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

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

1️⃣Автоматизация vs. ручное управление: В Continuous Delivery финальное решение о развертывании может быть сделано вручную. В Continuous Deployment каждое изменение автоматически разворачивается без вмешательства человека.

2️⃣ Частота развертывания: В Continuous Deployment изменения разворачиваются чаще и постоянно, в то время как в Continuous Delivery изменения готовы к развертыванию, но могут быть запущены в производство в более контролируемом порядке.

3️⃣ Уровень риска: Continuous Deployment требует более строгих мер контроля качества и автоматизации из-за более высокого риска, связанного с непрерывным развертыванием изменений.

Continuous Delivery гарантирует, что каждое изменение готово к развертыванию и может быть выпущено в любой момент, но не обязательно автоматически разворачивается. Автоматически развертывает каждое изменение, минимизируя задержки между разработкой и доступностью функций для пользователей. Обе практики направлены на ускорение и оптимизацию процессов разработки и выпуска программного обеспечения.

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

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

📌 Как должен выглядеть идеальный pipeline CI/CD, что в нём должно быть что за чем идти ?

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

Идеальный CI/CD (Continuous Integration/Continuous Deployment) пайплайн организует процесс разработки таким образом, чтобы максимизировать автоматизацию и минимизировать ручные задачи, увеличивая скорость разработки и обеспечивая высокое качество конечного продукта. Хорошо организованный пайплайн обеспечивает бесперебойное и быстрое внесение изменений в код, их тестирование, сборку и развертывание в производственную среду.

🤔 Этапы:

1️⃣Инициация изменений (Version Control System Integration)

➕ Разработчики клонируют репозиторий и вносят изменения.
➕ Изменения отправляются в репозиторий (например, через git push).

2️⃣ Непрерывная интеграция (Continuous Integration)

➕ Автоматический запуск пайплайна: Каждый push или pull request в репозиторий автоматически инициирует CI пайплайн.
➕ Сборка проекта: Компиляция кода, если это необходимо для данного языка программирования.
➕ Запуск модульных тестов (Unit Tests): Тестирование компонентов программы для проверки их корректности.
➕ Статический анализ кода: Проверка кода на соответствие стандартам кодирования и поиск потенциальных ошибок.

3️⃣Артефакты

➕ Сборка артефактов: Создание готовых для развертывания пакетов (например, Docker-образов).

4️⃣ Непрерывное тестирование (Continuous Testing)

➕ Интеграционное тестирование: Проверка, как различные части проекта работают вместе.
➕ Тестирование безопасности (Security Testing): Проверка на уязвимости.
➕ Тестирование производительности (Performance Testing): Проверка скорости и стабильности системы под нагрузкой.

5️⃣ Непрерывная доставка (Continuous Delivery)

➕ Автоматическое развертывание в тестовую среду: Автоматическое развертывание артефактов в тестовую среду для дополнительного тестирования.
➕ Ручное одобрение: Опционально, требование ручного одобрения перед продвижением артефактов в продакшн.

6️⃣ Непрерывное развертывание (Continuous Deployment)

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

7️⃣ Мониторинг и обратная связь

➕ Мониторинг: Непрерывный мониторинг производительности и стабильности приложения в производственной среде.
➕ Логирование: Сбор и анализ логов для выявления потенциальных проблем.
➕ Обратная связь: Системы уведомлений для информирования команды о состоянии пайплайна и производственной среды.

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

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

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

📌 В чем разница между подом и контейнером ?

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

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

🤔 Контейнер

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

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

🤔 Под

➕ Это наименьшая и простейшая единица, которую можно создать или управлять. Он представляет собой группу одного или нескольких контейнеров с общими ресурсами, которые запускаются на одном узле (физическом или виртуальном сервере). Каждый под имеет свои IP-адреса, объемы данных (если таковые есть), и контейнеры в поде могут обмениваться состоянием и общаться друг с другом через localhost.

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

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

➕ Сфера применения: Контейнер — это механизм, который напрямую связан с запуском отдельного приложения или процесса. Под же представляет собой уровень абстракции в Kubernetes, который включает один или несколько контейнеров, которые должны работать вместе.
➕ Управление: Контейнеры управляются внутри подов. Kubernetes не управляет контейнерами напрямую; вместо этого он управляет подами, которые в свою очередь содержат контейнеры.
➕ Совместное использование ресурсов: Все контейнеры внутри пода могут совместно использовать ресурсы, такие как сетевые подключения и дисковое пространство, что облегчает взаимодействие компонентов приложения.

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

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

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

📌 Что такое CI/CD ?

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

CI/CD — это сокращение от "Continuous Integration" (Непрерывная интеграция) и "Continuous Delivery" или "Continuous Deployment" (Непрерывная доставка или непрерывное развертывание), которые представляют собой ключевые концепции в современных методиках разработки ПО. Они помогают автоматизировать процессы разработки, тестирования и развертывания приложений, улучшая скорость, качество и эффективность процессов.

🤔 Непрерывная интеграция (Continuous Integration, CI)

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

🤔 Непрерывная доставка (Continuous Delivery, CD)

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

🤔 Непрерывное развертывание (Continuous Deployment)

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

🤔 Преимущества:

1️⃣ Быстрое обнаружение и устранение ошибок: Благодаря частой интеграции и тестированию, ошибки обнаруживаются и исправляются на ранних этапах, что снижает стоимость их устранения.
2️⃣ Улучшенное качество продукта: Постоянные тестирование и обратная связь способствуют повышению качества продукта.
3️⃣ Сокращение времени на выход продукта на рынок: Автоматизация позволяет быстрее доставлять продукт пользователям.
4️⃣ Улучшение процессов разработки: Разработчики могут сосредоточиться на улучшении продукта, а не на рутинных задачах.

CI/CD являются фундаментальными практиками в рамках DevOps, направленными на создание более эффективных и надежных процессов разработки программного обеспечения. Эти методологии способствуют более быстрому внедрению инноваций и повышению конкурентоспособности компаний на рынке.

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

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

📌 В чём разница между контейнеризацией и виртуализацией ?

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

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

🤔 Виртуализация

➕ Позволяет запускать несколько операционных систем как виртуальных машин (ВМ) на одном физическом сервере. Каждая ВМ имеет свою собственную полностью изолированную операционную систему, и каждая из них эмулирует аппаратное обеспечение хоста. Это достигается с помощью гипервизора, который стоит между аппаратным обеспечением и операционными системами. Гипервизор управляет аппаратными ресурсами и распределяет их между разными виртуальными машинами.

🤔Примеры гипервизоров:

➕ VMware ESXi
➕ Microsoft Hyper-V
➕ Oracle VirtualBox

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

➕ В отличие от виртуализации, позволяет запускать несколько приложений и их зависимостей в изолированных процессах, называемых контейнерами, на одной операционной системе. Контейнеры разделяют ядро операционной системы хоста, но могут быть ограничены в использовании CPU, памяти и I/O. Контейнеры быстрее и легче, чем виртуальные машины, поскольку они не требуют отдельной операционной системы для каждого из них.

🤔 Примеры технологий:

➕ Docker
➕ Kubernetes (используется для оркестрации контейнеров)
➕ LXC

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

1️⃣Уровень изоляции: Виртуализация предоставляет более полную изоляцию, так как каждая виртуальная машина имеет свою собственную операционную систему, в то время как контейнеры разделяют операционную систему хоста.

2️⃣Ресурсы: Виртуальные машины требуют больше ресурсов, так как каждая ВМ нуждается в собственных копиях операционной системы и её ресурсах, в то время как контейнеры более легковесные и быстрее загружаются.

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

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

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

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

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

📌 Что такое 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 практики.

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

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