Kubernetes активно использует стандарты с открытым исходным кодом для обеспечения совместимости и расширяемости. Основные из них включают OCI, CRI, CNI, CSI, SMI и CPI. Эти стандарты определяют интерфейсы и протоколы, которые позволяют Kubernetes взаимодействовать с различными компонентами и инструментами.
Проект Linux Foundation, который определяет стандарты для контейнеров. Основные спецификации OCI:
Kubernetes использует OCI-совместимые образы и среды выполнения, такие как runc, для обеспечения универсальной совместимости контейнеров.
Это интерфейс, который позволяет Kubernetes взаимодействовать с различными средами выполнения контейнеров. CRI определяет набор API, через которые kubelet может запускать и управлять контейнерами.
Это стандарт для настройки сетевых интерфейсов контейнеров и управления их жизненным циклом. CNI обеспечивает гибкость и расширяемость сетевых решений в Kubernetes.
Это стандарт, который позволяет Kubernetes взаимодействовать с различными системами хранения данных. CSI определяет API для создания, удаления, монтирования и управления томами.
Стандартный интерфейс для управления сервисными сетями (service mesh) в Kubernetes. SMI предоставляет набор абстракций для таких функций, как маршрутизация, телеметрия и управление трафиком.
Интерфейс, который позволяет Kubernetes взаимодействовать с различными облачными провайдерами. CPI управляет ресурсами облака, такими как виртуальные машины, сети и хранилища, в контексте Kubernetes-кластера.
Ставь 👍 и забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
👍8
Anonymous Quiz
6%
head
76%
tail
15%
less
3%
grep
👍2
- 100 Continue: Сервер получил начальную часть запроса и клиент может продолжать отправку запроса.
- 101 Switching Protocols: Сервер переключается на другой протокол, указанный в заголовке Upgrade.
- 200 OK: Запрос выполнен успешно. Наиболее распространенный код для успешных запросов.
- 201 Created: Запрос успешно выполнен и приведен к созданию ресурса. Используется, например, при отправке данных на сервер для создания новой записи.
- 202 Accepted: Запрос принят для обработки, но обработка еще не завершена.
- 204 No Content: Запрос выполнен успешно, но тело ответа пусто.
- 301 Moved Permanently: Ресурс был перемещен на новый постоянный URL. Клиент должен использовать новый URL для будущих запросов.
- 302 Found: Ресурс временно доступен по другому URL. Клиент должен использовать оригинальный URL для будущих запросов.
- 304 Not Modified: Ресурс не был изменен с момента последнего запроса. Клиент может использовать кэшированную версию.
- 400 Bad Request: Сервер не может обработать запрос из-за ошибки клиента (например, неверный синтаксис запроса).
- 401 Unauthorized: Запрос требует аутентификации. Клиент должен предоставить учетные данные для доступа к ресурсу.
- 403 Forbidden: Сервер понял запрос, но отказывается его выполнять. Клиент не имеет необходимых прав для доступа к ресурсу.
- 404 Not Found: Ресурс не найден. Сервер не может найти запрошенный ресурс.
- 405 Method Not Allowed: Метод, указанный в запросе, не поддерживается для данного ресурса.
- 409 Conflict: Запрос не может быть выполнен из-за конфликта с текущим состоянием ресурса.
- 429 Too Many Requests: Клиент отправил слишком много запросов за короткий период. Используется для ограничения скорости запросов.
- 500 Internal Server Error: Общая ошибка сервера. Сервер столкнулся с неожиданной ситуацией, которая помешала выполнению запроса.
- 501 Not Implemented: Сервер не поддерживает функциональность, необходимую для выполнения запроса.
- 502 Bad Gateway: Сервер, выступающий в роли шлюза или прокси, получил недопустимый ответ от вышестоящего сервера.
- 503 Service Unavailable: Сервер временно недоступен, обычно из-за перегрузки или технического обслуживания.
- 504 Gateway Timeout: Сервер, выступающий в роли шлюза или прокси, не получил своевременный ответ от вышестоящего сервера.
1: 200 OK
GET /index.html HTTP/1.1
Host: www.example.com
```http
HTTP/1.1 200 OK
Content-Type: text/html
<html>
<head><title>Example</title></head>
<body>Example page</body>
</html>
http
2: 404 Not Found
GET /nonexistent.html HTTP/1.1
Host: www.example.com
http
HTTP/1.1 404 Not Found
Content-Type: text/html
<html>
<head><title>404 Not Found</title></head>
<body>Page not found</body>
</html>
`Ставь 👍 и забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6❤1
Anonymous Quiz
5%
Контейнеризация приложений
24%
Управление конфигурацией
51%
Обнаружение сервисов и конфигурация
20%
Автоматизация тестирования
Docker — это платформа для разработки, развертывания и запуска приложений в контейнерах. Контейнеры обеспечивают изоляцию приложения и его зависимостей, позволяя запускать их в любой среде, будь то разработка, тестирование или производство. Docker упрощает процесс создания, тестирования и развертывания приложений, предоставляя все необходимые инструменты для работы с контейнерами.
Основные компоненты Docker
Docker daemon (dockerd) — это основной процесс Docker, который управляет контейнерами, образами, сетями и хранилищами. Docker daemon отвечает за выполнение команд, отправляемых через Docker CLI или API, и контролирует все операции, связанные с контейнерами.
Основные функции Docker daemon
- Создание, запуск, остановка, перезапуск и удаление контейнеров.
- Мониторинг состояния контейнеров и их взаимодействия с хостовой системой.
- Загрузка, создание, тегирование и удаление Docker-образов.
- Кэширование слоев образов для оптимизации повторного использования.
- Создание и управление виртуальными сетями для контейнеров.
- Поддержка различных сетевых драйверов (bridge, host, overlay и т.д.).
- Создание и управление томами (volumes) для постоянного хранения данных контейнеров.
Docker daemon работает в фоновом режиме и взаимодействует с Docker CLI и API для выполнения команд. Когда пользователь вводит команду через Docker CLI (например,
docker run), CLI отправляет эту команду Docker daemon через API. Docker daemon обрабатывает команду, выполняет необходимые действия и возвращает результат через CLI.docker run hello-world в терминале.hello-world. Если образ отсутствует, он загружает его из Docker Hub.hello-world.Результат: Пользователь видит вывод в терминале, подтверждающий успешный запуск контейнера.
$ docker run hello-world
Hello from Docker!
This message shows that your installation appears to be working correctly.
Ставь 👍 и забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
👍15
Anonymous Quiz
94%
Единица управления контейнерами в Kubernetes
1%
Система для мониторинга
4%
Инструмент для управления конфигурацией
1%
Платформа для автоматизации CI/CD
В современных операционных системах процессы и потоки (threads) являются основными единицами выполнения. Хотя они имеют много общего, есть несколько ключевых различий, которые определяют их использование и поведение.
Процесс — это экземпляр программы, который выполняется в операционной системе. Процессы имеют свои собственные ресурсы и память.
fork в Unix-подобных системах) занимает больше времени и ресурсов по сравнению с созданием потоков.Поток (thread) — это более легковесная единица выполнения, которая существует внутри процесса. Потоки одного и того же процесса разделяют его ресурсы и память, что позволяет им эффективно взаимодействовать.
pthread_create в POSIX-системах) быстрее и требует меньше ресурсов по сравнению с созданием нового процесса.Память и ресурсы:
Создание и управление:
Использование:
Пример создания процесса (на C с использованием fork):
#include <stdio.h>
#include <unistd.h>
int main() {
pid_t pid = fork();
if (pid == 0) {
printf("Это дочерний процесс\n");
} else if (pid > 0) {
printf("Это родительский процесс\n");
} else {
perror("fork");
return 1;
}
return 0;
}
Пример создания потока (на C с использованием pthreads):
#include <stdio.h>
#include <pthread.h>
void* thread_function(void* arg) {
printf("Это поток\n");
return NULL;
}
int main() {
pthread_t thread;
pthread_create(&thread, NULL, thread_function, NULL);
pthread_join(thread, NULL);
printf("Главный поток\n");
return 0;
}
Ставь 👍 и забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
👍13
Anonymous Quiz
2%
Управление конфигурацией
97%
Визуализация метрик и логов
1%
Автоматизация развертывания
1%
Контейнеризация приложений
👍1
Systemd стала основной системой инициализации для Unix-подобных ОС, управляя процессами и службами при загрузке и вытеснив традиционные системы, такие как System V init.
init: Выполняет задачи инициализации последовательно, что может замедлять процесс загрузки.
systemd: Поддерживает параллельную загрузку сервисов, что значительно ускоряет процесс загрузки системы.
init: Ограниченные возможности управления зависимостями между сервисами.
systemd: Предоставляет сложное управление зависимостями, автоматически определяя порядок запуска и останова сервисов.
init: Ограниченные возможности мониторинга и автоматического перезапуска упавших сервисов.
systemd: Встроенные функции для мониторинга состояния сервисов и автоматического их перезапуска в случае сбоя.
init: Различные дистрибутивы могут использовать разные форматы и скрипты инициализации.
systemd: Стандартизированный формат конфигурационных файлов (unit-файлов), что упрощает администрирование и переносимость.
init: Использует отдельные инструменты для журналирования, такие как syslog.
systemd: Встроенная система журналирования (journald), которая объединяет логи всех сервисов и предоставляет мощные возможности для их анализа.
init: Ограниченные возможности управления состоянием системы, такими как спящий режим, гибернация и выключение.
systemd: Встроенные команды для управления состоянием системы, такие как
systemctl suspend, systemctl hibernate и systemctl poweroff.Запуск и остановка сервисов:
systemctl start httpd.service
Остановка сервиса:
systemctl stop httpd.service
Проверка статуса сервиса:
systemctl status httpd.service
Включение автозапуска:
systemctl enable httpd.service
Отключение автозапуска:
systemctl disable httpd.service
Пример unit-файла для сервиса Nginx:
[Unit]
Description=A high performance web server and a reverse proxy server
After=network.target
[Service]
ExecStart=/usr/sbin/nginx
ExecReload=/usr/sbin/nginx -s reload
ExecStop=/usr/sbin/nginx -s quit
PIDFile=/run/nginx.pid
Restart=always
[Install]
WantedBy=multi-user.target
Ставь 👍 и забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
👍24
Anonymous Quiz
4%
Система для управления логами
14%
Инструмент для автоматизации CI/CD
77%
Пакетный менеджер для Kubernetes
5%
Система мониторинга
Ошибки в синтаксисе или логике Dockerfile могут приводить к созданию некорректного образа. Если указаны неверные пути или отсутствуют необходимые файлы, образ может не работать. Если директория
app/ отсутствует, команда COPY завершится с ошибкой.COPY app/ /usr/src/app
CMD ["python", "/usr/src/app/app.py"]
Если необходимые библиотеки или пакеты не установлены, приложение не сможет запуститься. Если
app.py требует внешних библиотек, их нужно установить с помощью RUN pip install.FROM python:3.8
COPY app.py /
CMD ["python", "/app.py"]
Если не указана правильная рабочая директория, команды могут выполняться в неверном контексте. Если не указать
WORKDIR /app, Node.js не сможет найти index.js.FROM node:14
COPY . /app
WORKDIR /app
CMD ["node", "index.js"]
Отсутствие или неправильная настройка переменных окружения может приводить к сбоям. Если контейнер слушает на порту, который не открыт, он не будет доступен извне. Если
default.conf имеет ошибки конфигурации, Nginx не запустится.FROM nginx
COPY default.conf /etc/nginx/conf.d/
Если файлы или директории имеют неправильные права доступа, приложение может не запуститься. Некоторые приложения требуют выполнения от имени определенного пользователя. Если
nobody не имеет права выполнения скрипта, контейнер не запустится.FROM ubuntu
COPY script.sh /
RUN chmod +x /script.sh
USER nobody
CMD ["/script.sh"]
Недостаток памяти или процессорного времени может привести к сбою при запуске контейнера. Если приложение требует больше памяти, оно не запустится.
docker run -m 256m myapp
Неправильная настройка сетевых интерфейсов или зависимость от внешних сервисов может привести к сбоям. Если приложение требует доступа к сети, оно не запустится без сетевого интерфейса.
docker run --network=none myapp
Используйте команды
docker logs и docker inspect для диагностики проблем.docker logs <container_id>
docker inspect <container_id>
Ставь 👍 и забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
👍10
Anonymous Quiz
18%
Управление конфигурацией
3%
Контейнеризация приложений
76%
Управление инфраструктурой как кодом
2%
Мониторинг приложений
👍2
В Docker образ состоит из нескольких слоев, каждый из которых представляет собой изменения, внесенные в файловую систему контейнера. Эти слои создаются при выполнении команд в Dockerfile. Слои позволяют эффективно использовать кэширование и делиться образами. Основные команды, которые создают слои, включают:
FROM — это первая команда в Dockerfile, которая указывает базовый образ для последующих инструкций. Каждый FROM создает новый базовый слой.
FROM ubuntu:20.04
RUN — эта команда выполняет команды в новом слое поверх текущего образа и создает новый образ. Часто используется для установки пакетов и выполнения скриптов.
RUN apt-get update && apt-get install -y python3
COPY — эта команда копирует файлы и директории из контекста сборки (локальной файловой системы) в файловую систему контейнера. Она создает новый слой с добавленными или измененными файлами.
COPY . /app
ADD — аналогична команде COPY, но с дополнительными возможностями. Она может извлекать архивы и загружать файлы из URL. Эта команда также создает новый слой.
ADD myfile.tar.gz /app
- CMD: Определяет команду по умолчанию для выполнения при запуске контейнера.
- ENTRYPOINT: Устанавливает исполняемую команду для контейнера.
- ENV: Устанавливает переменные окружения.
- EXPOSE: Указывает на порты, которые контейнер будет слушать.
- WORKDIR: Устанавливает рабочую директорию для последующих команд.
ENV PATH=/app/bin:$PATH
EXPOSE 8080
WORKDIR /app
Docker использует кэширование для ускорения сборки образов. Если инструкция и контекст для команды не изменились, Docker использует закэшированный слой вместо создания нового.
# Если requirements.txt не изменился, этот слой будет закэширован
COPY requirements.txt /app/
RUN pip install -r /app/requirements.txt
# Остальные файлы копируются
COPY . /app
Ставь 👍 и забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
👍14
Anonymous Quiz
0%
Методика тестирования
96%
Архитектурный стиль, разделяющий приложение на независимые сервисы
3%
Инструмент для контейнеризации
1%
Система мониторинга
🔥3
Запуск контейнеров от имени пользователя root (рута) в Docker является обычной практикой, но это может привести к серьезным проблемам безопасности. Вот основные причины, почему это считается плохой практикой:
Эксплуатация уязвимостей: Если злоумышленник получает доступ к контейнеру, запущенному от имени root, он может легко использовать уязвимости контейнера для атаки на хост-систему.
Злоумышленники: Контейнеры могут содержать уязвимые или злонамеренные коды, которые при запуске с привилегиями root могут получить доступ к чувствительной информации или вызвать сбои.
Гостевая изоляция: Контейнеры должны быть изолированы от хост-системы. Запуск контейнера от имени root нарушает эту изоляцию, так как root внутри контейнера — это также root на хосте.
Повышенные привилегии: Контейнеры, запущенные от имени root, могут иметь доступ к системным ресурсам, что увеличивает риск нарушения безопасности.
Принцип наименьших привилегий: Этот принцип гласит, что процесс должен иметь только те привилегии, которые необходимы для выполнения его задач. Запуск контейнера от имени root нарушает этот принцип, предоставляя ему избыточные права.
Если в контейнере, запущенном от имени root, найдена уязвимость, злоумышленник может использовать ее для выполнения команд с привилегиями root на хосте, что может привести к серьезным нарушениям безопасности.
Контейнер, запущенный от имени root, может получить доступ к критически важным файлам хостовой системы, изменять их или удалять, что может привести к нарушению работы всей системы.
Использование непривилегированных пользователей:
В Dockerfile можно создать пользователя с ограниченными привилегиями и переключиться на него.
FROM ubuntu:20.04
RUN useradd -m myuser
USER myuser
CMD ["myapp"]
Использование флага --user:
При запуске контейнера можно использовать флаг
--user, чтобы указать непривилегированного пользователя.docker run --user 1000:1000 myapp
Использование механизмов безопасности Docker:
Использование профилей seccomp для ограничения системных вызовов.
Использование AppArmor или SELinux для ограничения доступа контейнеров к системным ресурсам.
Ставь 👍 и забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
👍12❤3
Anonymous Quiz
35%
Процесс автоматизации тестирования кода
59%
Процесс автоматического развертывания кода в продуктивную среду
3%
Методика управления конфигурацией
3%
Подход к разработке микросервисов
StatefulSet в Kubernetes — это объект, который управляет развертыванием и масштабированием наборов подов, и обеспечивает их уникальные идентификаторы и постоянное хранение данных. .
Каждый под в StatefulSet имеет стабильный уникальный идентификатор, который сохраняется при перезапусках.
Поды запускаются и завершаются в определенном порядке, что важно для приложений.
Каждый под имеет постоянное DNS-имя, что упрощает связь между компонентами приложения.
StatefulSet использует PersistentVolume (PV) для хранения данных, что обеспечивает сохранение данных при перезапусках или пересоздании подов.
Запуск базы данных
Один из наиболее распространенных случаев использования StatefulSet — это развертывание и управление кластерами баз данных, такими как Cassandra, MySQL или PostgreSQL.
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: mysql
spec:
serviceName: "mysql"
replicas: 3
selector:
matchLabels:
app: mysql
template:
metadata:
labels:
app: mysql
spec:
containers:
- name: mysql
image: mysql:5.7
ports:
- containerPort: 3306
volumeMounts:
- name: mysql-persistent-storage
mountPath: /var/lib/mysql
volumeClaimTemplates:
- metadata:
name: mysql-persistent-storage
spec:
accessModes: [ "ReadWriteOnce" ]
resources:
requests:
storage: 1Gi
Объяснение полей конфигурации
Успешное развертывание и управление кластерами MySQL и Cassandra, обеспечивая высокую доступность и отказоустойчивость.
Развертывание приложений, требующих сохранения состояния, таких как Zookeeper и Kafka.
Управление порядковым обновлением подов для обеспечения правильной последовательности операций и минимизации времени простоя.
Настройка мониторинга состояния подов и автоматическое масштабирование StatefulSet для адаптации к изменяющимся нагрузкам.
Ставь 👍 и забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5
Anonymous Quiz
2%
Контейнеризация приложений
2%
Автоматизация тестирования
94%
Мониторинг и оповещение
2%
Управление конфигурацией
Это объект, который управляет развертыванием и масштабированием наборов подов с гарантией их уникальных идентификаторов и стабильных сетевых идентификаторов. Основной параметр, который определяет поведение StatefulSet, это `serviceName`.
Это имя службы (Service), связанной с StatefulSet, которая управляет доступом к подам. Эта служба используется для обеспечения стабильных сетевых идентификаторов для подов.
replicas:
Определяет количество реплик подов, которые должен поддерживать StatefulSet.
replicas: 3
selector:
Указывает метки, которые должны быть на подах, управляемых StatefulSet.
selector:
matchLabels:
app: myapp
template:
Шаблон пода, который используется для создания новых реплик.
template:
metadata:
labels:
app: myapp
spec:
containers:
- name: myapp-container
image: myapp:latest
ports:
- containerPort: 80
volumeClaimTemplates:
Шаблоны PersistentVolumeClaim для создания постоянных хранилищ для каждого пода.
volumeClaimTemplates:
- metadata:
name: myapp-storage
spec:
accessModes: [ "ReadWriteOnce" ]
resources:
requests:
storage: 1Gi
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: myapp-statefulset
spec:
serviceName: "myapp-service"
replicas: 3
selector:
matchLabels:
app: myapp
template:
metadata:
labels:
app: myapp
spec:
containers:
- name: myapp-container
image: myapp:latest
ports:
- containerPort: 80
volumeMounts:
- name: myapp-storage
mountPath: /data
volumeClaimTemplates:
- metadata:
name: myapp-storage
spec:
accessModes: [ "ReadWriteOnce" ]
resources:
requests:
storage: 1Gi
apiVersion: Версия API Kubernetes для объекта StatefulSet.
kind: Тип объекта, в данном случае StatefulSet.
metadata: Метаинформация о StatefulSet, включая имя.
spec: Спецификация StatefulSet.
serviceName: Имя службы, связанной с StatefulSet, обеспечивающей стабильные сетевые идентификаторы.
replicas: Количество реплик подов.
selector: Метки для выбора подов.
template: Шаблон пода, включающий метаданные и спецификацию контейнеров.
volumeClaimTemplates: Шаблоны для создания PersistentVolumeClaim.
Ставь 👍 и забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
👍11❤1
Anonymous Quiz
7%
Система управления версиями
6%
Платформа для оркестрации контейнеров
85%
Инструмент для автоматизации CI/CD
3%
Система мониторинга
❤9