diff --git a/src/PaaS/Deckhouse/FAQ.md b/src/PaaS/Deckhouse/FAQ.md new file mode 100644 index 0000000..8cf5fd4 --- /dev/null +++ b/src/PaaS/Deckhouse/FAQ.md @@ -0,0 +1,177 @@ +# FAQ Deckhouse + +## О разделе + +В данном разделе приведены ответы на часто задаваемые вопросы по работе с сервисом Cloud Deckhouse Kubernetes. + +## Создание учетной записи пользователя + +### Через web-интерфейс Console: + +1. Необходимо войти в Console с учётной записью, имеющей права администратора (SuperAdmin); +2. В левом боковом меню требуется выбрать раздел **«Доступ»**; +3. В раскрывающемся подменю нужно выбрать **«Локальная аутентификация»**; + ![Локальная аутентификация](images/local-authentication.png) +4. Следует выбрать пункт **«Пользователи»** и в правом верхнем углу нажать кнопку **«Создать»**; + ![Создание](images/create.png) +5. Необходимо заполнить форму создания пользователя и нажать **«Создать»**; + ![Заполнение формы](images/form-filling.png) +6. Требуется назначить пользователю права доступа (роли): + - В левом боковом меню выбрать раздел **«Права доступа»**; + - В правом верхнем углу нажать кнопку **«Создать»**; + ![Права доступа](images/access-permissions.png) + - Заполнить форму: указать название правила, уровень доступа, добавить созданного пользователя. Нажать **«Создать»**. + +: : : info +Новому пользователю можно назначить уже существующее правило. Для этого необходимо выбрать из списка нужное правило, в открывшемся окне нажать кнопку **«Добавить»** и указать пользователя, сервис-аккаунт или группу, для которых будет применяться это правило. +: : : + +![Выданные права](images/granted-permissions.png) + +### Рекомендации к паролям + +**Длина пароля (рекомендуемая):** + +- для учётной записи пользователя - не менее 12 знаков; +- для учётных записей администраторов, технических и служебных учётных записей - не менее 16 знаков. + +**Сложность пароля:** рекомендуется использовать уникальный пароль, содержащий символы как минимум трёх из четырёх указанных ниже групп (при отсутствии технических ограничений): + +- буквы латинского алфавита в верхнем регистре (A-Z); +- буквы латинского алфавита в нижнем регистре (a-z); +- цифры (0-9); +- специальные символы и знаки пунктуации (например, !@#$%^&*(),.?). + +**Периодичность смены:** рекомендуемая периодичность смены пароля - не реже одного раза в год. + +### Создание пользователя с помощью kubectl + +**1. Создание ServiceAccount**. + +Требуется создать файл **service-account.yaml**: + +``` +apiVersion: v1 +kind: ServiceAccount +metadata: + name: my-user-sa + namespace: my-project +``` + +Необходимо выполнить команду: + +``` +kubectl apply -f service-account.yaml +``` + +Пример вывода: + +``` +serviceaccount/my-user-sa created +``` + +**2. Создание роли (или использование существующей)**. + +Нужно создать файл **role.yaml** (пример роли с правами на чтение подов): + +``` +apiVersion: rbac.authorization.k8s.io/v1 +kind: Role +metadata: + name: pod-reader + namespace: my-project +rules: +- apiGroups: [""] + resources: ["pods"] + verbs: ["get", "list", "watch"] +``` + +Выполняется команда: + +``` +kubectl apply -f role.yaml +``` + +**3. Связывание ServiceAccount с ролью (RoleBinding)**. + +Требуется создать файл **role-binding.yaml**: + +``` +apiVersion: rbac.authorization.k8s.io/v1 +kind: RoleBinding +metadata: + name: read-pods-binding + namespace: my-project +subjects: +- kind: ServiceAccount + name: my-user-sa + namespace: my-project +roleRef: + kind: Role + name: pod-reader + apiGroup: rbac.authorization.k8s.io +``` + +Необходимо выполнить команду: + +``` +kubectl apply -f role-binding.yaml +``` + +Пример вывода: + +``` +rolebinding.rbac.authorization.k8s.io/read-pods-binding created +``` + +## Создание worker-групп + +### Через веб-интерфейс Console: + +1. Необходимо войти в Console с учётной записью, имеющей права администратора (SuperAdmin); +2. В левом боковом меню требуется выбрать раздел **«Узлы»**; +3. В раскрывающемся подменю нужно выбрать **«Группы узлов» (Node Groups)**; + ![Группы узлов](images/node-groups.png) +4. Следует нажать кнопку **«Создать»** и выбрать тип **CloudEphemeral**; +5. В открывшейся форме необходимо заполнить параметры группы узлов. Класс машин указывается **worker**; + ![Параметры группы узлов](images/node-group-parameters.png) +6. При необходимости настраиваются дополнительные параметры: + - параметры автомасштабирования; + - обновление узлов; + - шаблон узла; + - системные параметры узлов. +7. Требуется нажать **«Создать»**. Система автоматически создает указанное количество виртуальных машин с заданными параметрами и присоединяет их к кластеру. + +### Создание worker-групп через kubectl: + +В Deckhouse группы узлов описываются декларативно через специальный ресурс **NodeGroup**. +**Файл node-group-worker.yaml:** + +``` +apiVersion: deckhouse.io/v1 +kind: NodeGroup +metadata: + name: worker-high-cpu +spec: + cloudInstances: + classReference: + kind: VCDInstanceClass + name: worker + maxPerZone: 5 + maxSurgePerZone: 0 + maxUnavailablePerZone: 0 + minPerZone: 1 + nodeType: CloudEphemeral +``` + +Необходимо выполнить команду: + +``` +kubectl apply -f node-group-worker.yaml +``` + +Пример вывода: + +``` +nodegroup.deckhouse.io/worker-high-cpu created +``` \ No newline at end of file diff --git a/src/PaaS/Deckhouse/connection.md b/src/PaaS/Deckhouse/connection.md new file mode 100644 index 0000000..2c95707 --- /dev/null +++ b/src/PaaS/Deckhouse/connection.md @@ -0,0 +1,235 @@ +# Подключение к сервису Deckhouse + +## О разделе + +В данном разделе описаны способы подключения к кластеру Cloud Deckhouse Kubernetes. Рассматривается работа с кластером через веб-интерфейс **Console**, а также управление через командную строку с использованием утилиты **kubectl** после генерации **kubeconfig**. Приведены примеры основных команд для начала работы. + +## Предварительные требования + +После предоставления доступа к сервису Cloud Deckhouse Kubernetes пользователь получает возможность управлять кластером через веб-интерфейс Console.  + +Console - это встроенный веб-интерфейс платформы Deckhouse, предназначенный для упрощения взаимодействия с Kubernetes-кластером . Он позволяет выполнять большинство операций, доступных в командной строке через **kubectl**, в визуальном режиме: мониторинг состояния кластера, управление узлами и модулями, настройку безопасности и сети . + +## Вход в Console + +1. Необходимо открыть веб-браузер и перейдите по адресу, предоставленному для доступа к Console; + +: : : info +   URL-адрес направляется пользователю на электронную почту при предоставлении доступа. +: : : + +2. На странице авторизации вводятся логин и пароль от учётной записи кластера; + +![Авторизация](images/authorization.png) + +3. После успешной аутентификации откроется главная страница веб-интерфейса Console. + +![Главная страница](images/home-page.png) + +## Основные разделы Console + +В левой боковой панели веб-интерфейса Console расположены основные разделы для управления кластером: + +| Раздел | Назначение | +| ------------------ | -------------------------------------------------------------------------------------- | +| **Deckhouse** | Управление платформой Deckhouse: обзор, обновления, модули, глобальные настройки | +| **Проекты** | Управление проектами, шаблонами проектов и namespace (пространствами имён) | +| **Узлы** | Управление узлами кластера: группы узлов, конфигурации, классы машин, статические узлы | +| **Конфигурация** | Настройка Deschedulers и Priority Classes | +| **Доступ** | Управление аутентификацией, сессиями пользователей, правами доступа (RBAC) | +| **Сеть** | Настройка Egress-шлюзов, балансировки и управление сертификатами | +| **Хранилище** | Управление Persistent Volume, классами хранилищ и снимками томов | +| **Безопасность** | Настройка политик безопасности и операционных политик | +| **Мониторинг** | Просмотр данных, дашбордов, активных алертов, настройка уведомлений и экспорт метрик | +| **Журналирование** | Управление отправкой и сбором логов | + +## Генерация kubeconfig через Console + +Помимо управления через веб-интерфейс, Console позволяет сгенерировать файл **kubeconfig** для доступа к кластеру через **kubectl**. + +1. На главной странице Console находится раздел «Инструменты» (Tools); +2. Необходимо выбрать пункт «Генератор kubeconfig» (Generate kubeconfig); +3. Нажимается кнопка генерации - система сгенерирует необходимые команды; +4. Далее, нужно скопировать и выполнить в терминале команды, которые сгенерированы для пользовательской учётной записи. + +: : : info +Сгенерированный **kubeconfig** уже содержит все необходимые параметры для подключения к API Kubernetes. +: : : + +## Примеры простейших команд kubectl + +После настройки **kubeconfig** управление кластером осуществляется через командную строку с помощью утилиты **kubectl**. Ниже приведены основные команды для начала работы. + +### Проверка подключения к кластеру + +``` +kubectl cluster-info +``` + +**Пример вывода:** + +``` +Kubernetes control plane is running at https://127.0.0.1:6445 + +To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'. +``` + +### Просмотр узлов кластера + +``` +kubectl get nodes +``` + +**Пример вывода:** + +``` +NAME STATUS ROLES AGE VERSION +cloud-frontend-0 Ready frontend 12d v1.32.10 +cloud-frontend-1 Ready frontend 12d v1.32.10 +cloud-master-0 Ready control-plane,master 12d v1.32.10 +cloud-master-1 Ready control-plane,master 12d v1.32.10 +cloud-master-2 Ready control-plane,master 12d v1.32.10 +cloud-system-0 Ready system 12d v1.32.10 +cloud-system-1 Ready system 12d v1.32.10 +cloud-worker-a374349e-zznfp-nkqr2 Ready worker 12d v1.32.10 +cloud-worker-a374349e-zznfp-rdpdz Ready worker 12d v1.32.10 +``` + +### Просмотр пространств имен + +``` +kubectl get namespaces +``` + +**Пример вывода:** + +``` +NAME STATUS AGE +d8-admission-policy-engine Active 12d +d8-cert-manager Active 12d +d8-chrony Active 12d +d8-cloud-instance-manager Active 12d +d8-cloud-provider-vcd Active 12d +d8-cni-cilium Active 12d +d8-console Active 12d +d8-dashboard Active 12d +d8-descheduler Active 12d +d8-ingress-nginx Active 12d +d8-local-path-provisioner Active 12d +d8-log-shipper Active 12d +d8-metallb Active 12d +d8-monitoring Active 12d +d8-multitenancy-manager Active 12d +d8-observability Active 12d +d8-operator-prometheus Active 12d +d8-pod-reloader Active 12d +d8-service-accounts Active 12d +d8-snapshot-controller Active 12d +d8-system Active 12d +d8-upmeter Active 12d +d8-user-authn Active 12d +default Active 12d +kube-node-lease Active 12d +kube-public Active 12d +kube-system Active 12d +``` + +### Просмотр подов в конкретном namespace + +``` +kubectl get pods -n d8-console +``` + +**Пример вывода:** + +``` +NAME READY STATUS RESTARTS AGE +backend-546c7496f8-2nzx2 1/1 Running 0 3d7h +backend-546c7496f8-nxqf4 1/1 Running 0 3d7h +console-dex-authenticator-6b7d456445-7cg9p 2/2 Running 0 12d +console-dex-authenticator-6b7d456445-ljjr8 2/2 Running 0 12d +frontend-79cb59c94d-cf457 1/1 Running 0 3d7h +frontend-79cb59c94d-rvlzk 1/1 Running 0 3d7h +observability-gw-59c4fb6548-2lcqr 1/1 Running 0 3d7h +observability-gw-59c4fb6548-9n6nb 1/1 Running 0 3d7h +``` + +### Просмотр логов пода + +``` +kubectl logs frontend-79cb59c94d-cf457 -n d8-console +``` + +### Просмотр сервисов + +``` +kubectl get services -n d8-console +``` + +**Пример вывода:** + +``` +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +backend ClusterIP 10.222.4.60 8999/TCP 12d +console-dex-authenticator ClusterIP 10.222.224.82 443/TCP 12d +frontend ClusterIP 10.222.226.106 80/TCP 12d +observability-gw ClusterIP None 3000/TCP,8443/TCP 12d +``` + +### Быстрое получение информации о ресурсах + +``` +kubectl get all -n d8-console +``` + +**Пример вывода:** + +``` +NAME READY STATUS RESTARTS AGE +pod/backend-546c7496f8-2nzx2 1/1 Running 0 3d7h +pod/backend-546c7496f8-nxqf4 1/1 Running 0 3d7h +pod/console-dex-authenticator-6b7d456445-7cg9p 2/2 Running 0 12d +pod/console-dex-authenticator-6b7d456445-ljjr8 2/2 Running 0 12d +pod/frontend-79cb59c94d-cf457 1/1 Running 0 3d7h +pod/frontend-79cb59c94d-rvlzk 1/1 Running 0 3d7h +pod/observability-gw-59c4fb6548-2lcqr 1/1 Running 0 3d7h +pod/observability-gw-59c4fb6548-9n6nb 1/1 Running 0 3d7h + +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +service/backend ClusterIP 10.222.4.60 8999/TCP 12d +service/console-dex-authenticator ClusterIP 10.222.224.82 443/TCP 12d +service/frontend ClusterIP 10.222.226.106 80/TCP 12d +service/observability-gw ClusterIP None 3000/TCP,8443/TCP 12d + +NAME READY UP-TO-DATE AVAILABLE AGE +deployment.apps/backend 2/2 2 2 12d +deployment.apps/console-dex-authenticator 2/2 2 2 12d +deployment.apps/frontend 2/2 2 2 12d +deployment.apps/observability-gw 2/2 2 2 12d + +NAME DESIRED CURRENT READY AGE +replicaset.apps/backend-546c7496f8 2 2 2 3d7h +replicaset.apps/backend-69d8c6bd68 0 0 0 12d +replicaset.apps/console-dex-authenticator-6b7d456445 2 2 2 12d +replicaset.apps/console-dex-authenticator-74c97bf4d6 0 0 0 12d +replicaset.apps/frontend-6b7ffb7bbd 0 0 0 9d +replicaset.apps/frontend-79cb59c94d 2 2 2 3d7h +replicaset.apps/frontend-79ccdfc56b 0 0 0 12d +replicaset.apps/observability-gw-574cdfdd87 0 0 0 12d +replicaset.apps/observability-gw-59c4fb6548 2 2 2 3d7h + + +``` +### Получение справки + +Для получение справки по любой команде используется флаг **--help**: + +``` +kubectl get pods --help +kubectl describe pod --help +``` +### Просмотр подробной информации о конкретном ресурсе + +``` +kubectl describe pod <имя-пода> -n +``` \ No newline at end of file diff --git a/src/PaaS/Deckhouse/images/access-permissions.png b/src/PaaS/Deckhouse/images/access-permissions.png new file mode 100644 index 0000000..bdb0201 Binary files /dev/null and b/src/PaaS/Deckhouse/images/access-permissions.png differ diff --git a/src/PaaS/Deckhouse/images/authorization.png b/src/PaaS/Deckhouse/images/authorization.png new file mode 100644 index 0000000..c36fd67 Binary files /dev/null and b/src/PaaS/Deckhouse/images/authorization.png differ diff --git a/src/PaaS/Deckhouse/images/create.png b/src/PaaS/Deckhouse/images/create.png new file mode 100644 index 0000000..59ea3c0 Binary files /dev/null and b/src/PaaS/Deckhouse/images/create.png differ diff --git a/src/PaaS/Deckhouse/images/form-filling.png b/src/PaaS/Deckhouse/images/form-filling.png new file mode 100644 index 0000000..f20330c Binary files /dev/null and b/src/PaaS/Deckhouse/images/form-filling.png differ diff --git a/src/PaaS/Deckhouse/images/granted-permissions.png b/src/PaaS/Deckhouse/images/granted-permissions.png new file mode 100644 index 0000000..d8b2d15 Binary files /dev/null and b/src/PaaS/Deckhouse/images/granted-permissions.png differ diff --git a/src/PaaS/Deckhouse/images/home-page.png b/src/PaaS/Deckhouse/images/home-page.png new file mode 100644 index 0000000..597a451 Binary files /dev/null and b/src/PaaS/Deckhouse/images/home-page.png differ diff --git a/src/PaaS/Deckhouse/images/local-authentication.png b/src/PaaS/Deckhouse/images/local-authentication.png new file mode 100644 index 0000000..ab67669 Binary files /dev/null and b/src/PaaS/Deckhouse/images/local-authentication.png differ diff --git a/src/PaaS/Deckhouse/images/node-group-parameters.png b/src/PaaS/Deckhouse/images/node-group-parameters.png new file mode 100644 index 0000000..cbc9da8 Binary files /dev/null and b/src/PaaS/Deckhouse/images/node-group-parameters.png differ diff --git a/src/PaaS/Deckhouse/images/node-groups.png b/src/PaaS/Deckhouse/images/node-groups.png new file mode 100644 index 0000000..92581f7 Binary files /dev/null and b/src/PaaS/Deckhouse/images/node-groups.png differ diff --git a/src/PaaS/Deckhouse/specifications.md b/src/PaaS/Deckhouse/specifications.md new file mode 100644 index 0000000..25c2d5f --- /dev/null +++ b/src/PaaS/Deckhouse/specifications.md @@ -0,0 +1,87 @@ +# Техническое описание сервиса + +## О сервисе + +Cloud Deckhouse Kubernetes - это управляемый облачный сервис платформы оркестрации контейнеров Kubernetes. Он позволяет развернуть и использовать отказоустойчивый кластер контейнеризации без необходимости самостоятельно настраивать серверы, сеть, балансировщики и механизмы отказоустойчивости. + +Kubernetes - это платформа для оркестрации контейнеров, которая автоматизирует развертывание, масштабирование и управление приложениями. + +В Cloud Deckhouse Kubernetes все основные операции по управлению кластером выполняются автоматически. + +Сервис самостоятельно: + +- управляет ролями узлов кластера (master, frontend, system и worker); +- отслеживает состояние компонентов платформы; +- автоматически восстанавливает вышедшие из строя узлы и приложения (поды). + +Для обеспечения стабильной работы сервиса используется несколько компонентов: + +- **Deckhouse** - платформа управления, автоматизирующая установку, обновление и конфигурацию кластера; +- **etcd** - распределенное хранилище состояния кластера; +- **Балансировщики нагрузки** - обеспечивают единую точку входа в приложения. + +Подключение к приложениям, работающим в кластере, выполняется через единую точку доступа. Пользователю не требуется подключаться к отдельным узлам. + +Для управления кластером и развертывания приложений доступен веб-интерфейс Console, а для мониторинга - Grafana. + +## Конфигурация кластера + +Кластер предоставляется в отказоустойчивой архитектуре, которая обеспечивает: + +- высокую доступность плоскости управления (control plane); +- автоматическое восстановление при отказе узлов. + +### Типы узлов кластера + +Кластер состоит из следующих типов виртуальных серверов: + +| Тип узла | Количество узлов | Назначение | +| ------------------------------- | ---------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| **Master-узлы (control plane)** | 3 узла | Обязательные узлы. На них работают управляющие компоненты кластера: API server, etcd, controller manager, scheduler. | +| **System-узлы** | 2 узла | Служебные узлы. На них размещаются внутренние компоненты платформы Deckhouse, системы мониторинга (Prometheus, Grafana), логирования и другие вспомогательные сервисы, обеспечивающие работу кластера. | +| **Frontend-узлы** | 2 узла | Узлы, предназначенные для обработки входящего трафика. На них работают Ingress-контроллеры и балансировщики нагрузки, которые принимают запросы из внешней сети и распределяют их между приложениями, запущенными на worker-узлах. | +| **Worker-узлы** | от 1 и более | Узлы, на которых непосредственно выполняются пользовательские приложения в контейнерах. Именно здесь размещаются поды с сервисами и прикладными компонентами. | | + +: : : info +По умолчанию кластер работает в высокодоступном режиме. Выход из строя одного или двух master-узлов не приводит к потере управления кластером. +: : : + +: : : info +Для тестовых сред возможна одноузловая конфигурация control plane, но в этом случае отказ master-узла сделает кластер неуправляемым. +: : : + +## Доступ к кластеру + +Прямой доступ к серверам кластера (по SSH) не предоставляется. . + +Управление приложениями и ресурсами кластера возможно через: +- командную строку (**kubectl**); +- веб-интерфейс console; +- API Kubernetes. + +## Возможности сервиса + +Cloud Deckhouse Kubernetes предоставляет возможности, позволяющие использовать Kubernetes без самостоятельного администрирования инфраструктуры. + +Сервис обеспечивает: + +- автоматическое управление кластером (установка, обновление, настройка); +- высокую доступность control plane; +- единую точку входа в приложения; +- автоматическое восстановление при отказах; +- веб-доступ к управлению кластером и мониторингу; +- совместимость со стандартными инструментами (**kubectl**); +- автоматическое масштабирование приложений; +- блочные и сетевые хранилища для данных приложений (Persistent Volume). + +## Сценарии использования + +Сервис подходит для систем, где требуется надёжная оркестрация контейнеров и упрощённое управление инфраструктурой. + +Примеры использования: + +- размещение production-приложений в контейнерах с высокими требованиями к доступности; +- микросервисная архитектура с единой точкой управления кластером; +- работа stateful-приложений (базы данных, очереди) с сохранением состояния; +- быстрое развёртывание Kubernetes-кластера без ручной настройки сети, хранилищ и мониторинга; +- администрирование через веб-интерфейс без прямого доступа к серверам. \ No newline at end of file diff --git a/src/PaaS/Deckhouse/technical-parameters.md b/src/PaaS/Deckhouse/technical-parameters.md new file mode 100644 index 0000000..59c74b4 --- /dev/null +++ b/src/PaaS/Deckhouse/technical-parameters.md @@ -0,0 +1,96 @@ +# Описание технических параметров + +## О разделе + +Данный раздел содержит технические параметры кластера Kubernetes и порядок их первичной конфигурации. + +Настройка указанных параметров выполняется администратором облачного провайдера на этапе развёртывания сервиса. Пользователь не имеет прямого доступа к их самостоятельной установке (за исключением конфигурации worker-узлов). + +Перед созданием кластера клиент предоставляет перечень требуемых параметров менеджеру. Администратор облачного провайдера выполняет конфигурацию в соответствии с согласованными требованиями. + +## Выбор типа и размера дискового хранилища + +Производительность приложений в Kubernetes напрямую зависит от скорости, с которой они могут читать и записывать данные на диск. При заказе кластера необходимо выбрать тип дискового хранилища, который определит максимальную скорость работы (IOPS) и время отклика. + +**IOPS (Input/Output Operations Per Second)** - количество операций чтения или записи, которые диск может выполнить за секунду. Чем выше этот показатель, тем быстрее работают базы данных и другие приложения, интенсивно работающие с диском. + +## Доступные типы хранилищ: + +| Название | Лимит IOPS | +| ---------- | ------------------ | +| Fast SAS | до 2 IOPS на 1 ГБ | +| SSD | до 5 IOPS на 1 ГБ | +| Fast SSD | до 10 IOPS на 1 ГБ | +| Ultra NVMe | до 25 IOPS на 1 ГБ + +: : : warning +После выбора типа диска необходимо указать объем дискового хранилища, который будет выделен под данные приложений (Persistent Volumes). Минимальный объем - 50 ГБ. +: : : + +## Конфигурация вычислительных ресурсов + +В данном разделе определяются вычислительные мощности кластера: процессорные ресурсы, оперативная память и количество узлов, из которых будет состоять кластер Kubernetes. + +### Количество узлов в кластере + +Количество узлов определяет отказоустойчивость кластера и возможность распределять нагрузку между worker-узлами. Чем больше узлов, тем выше надёжность и пропускная способность. + +#### Master-узлы (control plane) + +Для обеспечения отказоустойчивости кластера рекомендуется использовать не менее трёх master-узлов. Такое количество обеспечивает безотказную работу кластера и позволяет безопасно обновлять master-узлы. В большем числе нет необходимости, а двух узлов недостаточно для обеспечения согласия между master-узлами (кворума) в случае возникновения неполадок с одним из них. + +При использовании всего одного master-узла его отказ приводит к сбою всего кластера, так как именно master-узел управляет ключевыми компонентами, обеспечивающими работу кластера. + +#### System-узлы + +Системные узлы предназначены для запуска модулей Deckhouse. Рекомендуется выделить два системных узла. В этом случае модули Deckhouse будут работать на них, не пересекаясь с пользовательскими приложениями кластера. + +#### Frontend-узлы + +Frontend-узлы балансируют входящий трафик, на них работают Ingress-контроллеры. Рекомендуется использовать более одного frontend-узла. Frontend-узлы должны выдерживать трафик при отказе как минимум одного узла. + +: : : info +Если в кластере два frontend-узла, каждый из них должен справляться со всей нагрузкой на кластер в случае выхода второго из строя. +: : : + +: : : info +Если в кластере три frontend-узла, каждый должен выдерживать увеличение нагрузки как минимум в полтора раза. +: : : + +#### Worker-узлы + +Количество worker-узлов - от 1 и более. На них выполняются пользовательские приложения. В дальнейшем пользователь может самостоятельно увеличить их максимальное количество. + +## Процессор (CPU) + +Процессор - это вычислительная мощность, выделяемая каждому узлу кластера. Количество vCPU определяет, насколько быстро приложения смогут: + +- обрабатывать запросы; +- выполнять сложные вычисления; +- обслуживать одновременные подключения. + +Доступный диапазон: от 2 до 24 vCPU на один узел. + +## Оперативная память (RAM) + +Оперативная память - один из ключевых ресурсов для производительности приложений. Данные, помещающиеся в RAM, обрабатываются максимально быстро, без обращения к диску. + +Доступный диапазон: от 4 до 768 ГБ RAM на один узел. + +## Доступ в интернет + +При заказе сервиса можно выбрать пропускную способность канала связи, через который будет осуществляться доступ к кластеру Kubernetes из сети интернет. + +Доступные варианты скорости: + +- 50 Мбит/с; +- 100 Мбит/с; +- 200 Мбит/с; +- 300 Мбит/с; +- 400 Мбит/с; +- 500 Мбит/с; +- 1000 Мбит/с (1 Гбит/с). + +: : : info +Для выбранного канала предоставляется статический белый IP-адрес. +: : : \ No newline at end of file diff --git a/src/PaaS/Deckhouse/user-permissions.md b/src/PaaS/Deckhouse/user-permissions.md new file mode 100644 index 0000000..c8ca3e8 --- /dev/null +++ b/src/PaaS/Deckhouse/user-permissions.md @@ -0,0 +1,81 @@ +# Права и возможности пользователей + +## О разделе + +Данный раздел описывает права, которые предоставляются пользователю Deckhouse при создании сервиса Cloud Deckhouse Kubernetes, а также перечень административных операций, доступных ему для самостоятельного выполнения. + +При развертывании сервиса создается учетная запись, которая имеет уровень доступа **SuperAdmin**. Данный уровень предоставляет расширенные права на управление кластером Kubernetes, позволяя получить полный контроль над своими приложениями и ресурсами в пределах выделенного кластера или пространства имен (namespace). + +**Ограничения доступа SuperAdmin:** + +- инфраструктурный уровень (гипервизоры, физические серверы, сетевое оборудование); +- управление компонентами платформы Deckhouse на уровне всего кластера; +- master-узлы, system-узлы и frontend-узлы; +- изменение конфигурации платформы Deckhouse и её глобальных модулей. + +## Доступные действия + +### Управление пространствами имен (Namespaces) + +SuperAdmin может создавать, изменять и удалять пространства имен. + +- создание нового namespace; +- удаление namespace (при этом все ресурсы внутри него также удаляются); +- просмотр списка всех namespace; +- установка меток (labels) и аннотаций для namespace. + +### Управление рабочими нагрузками + +SuperAdmin имеет полный контроль над подами, развёртываниями и другими ресурсами приложений. + +- создание, обновление и удаление Deployment, StatefulSet, DaemonSet; +- создание, обновление и удаление Pod; +- просмотр логов подов (`kubectl logs`); +- подключение к выполняющемуся контейнеру (`kubectl exec`); +- масштабирование развёртываний (увеличение или уменьшение количества реплик); +- обновление версий образов контейнеров; +- удаление подов (в том числе принудительное); +- просмотр событий (events) в namespace. + +### Управление сетевым доступом (Services & Ingress) + +SuperAdmin может настраивать способы доступа к приложениям как внутри кластера, так и из внешней сети. + +- создание, изменение и удаление Service (типы: ClusterIP, NodePort, LoadBalancer); +- создание, изменение и удаление Ingress-правил для маршрутизации входящего трафика; +- настройка портов и селекторов для сервисов; +- просмотр списка сервисов и их конечных точек (endpoints). + +### Управление хранилищем (Storage) + +SuperAdmin может создавать и использовать тома для хранения данных приложений. + +- создание Persistent Volume Claim (PVC); +- удаление PVC (освобождение дискового пространства); +- просмотр списка PVC и их статусов; +- использование PVC в подах (монтирование томов). + +### Управление конфигурацией (ConfigMaps & Secrets) + +SuperAdmin может создавать и изменять конфигурационные данные и секреты для приложений. + +- создание, изменение и удаление ConfigMap; +- создание, изменение и удаление Secrets (например, для хранения паролей, токенов, ключей); +- монтирование ConfigMap и Secrets в поды в виде переменных окружения или файлов. + +### Мониторинг и наблюдаемость + +SuperAdmin имеет доступ к метрикам и логам своих приложений. + +- просмотр метрик приложений в Grafana; +- просмотр логов через `kubectl logs` или через интерфейс сбора логов (Loki); +- просмотр дашбордов с информацией о потреблении ресурсов (CPU, RAM, Storage) своими приложениями; +- просмотр событий Kubernetes (events) для диагностики проблем. + +### Управление доступом (RBAC) + +SuperAdmin может управлять правами других пользователей в рамках своего пространства имен. + +- создание и удаление учётных записей (ServiceAccount); +- назначение ролей (Role, RoleBinding) другим пользователям в пределах своего namespace; +- ограничение доступа к отдельным ресурсам. \ No newline at end of file