diff --git a/src/.vitepress/config.mts b/src/.vitepress/config.mts index 8841cf2..89c76de 100644 --- a/src/.vitepress/config.mts +++ b/src/.vitepress/config.mts @@ -293,17 +293,16 @@ export default defineConfig({ {text: 'Веб-интерфейс Grafana', link: '/PaaS/PostgreSQL/grafana.md'}, ], }, - {text: 'Параметры конфигурации IPSEC', link: '/PaaS/IPSEC.md'}, + {text: 'IPSEC', link: '/PaaS/IPSEC.md'}, { - text: 'Deckhouse', - link: 'PaaS/Deckhouse/index.md', + text: 'Deckhouse', link: 'PaaS/Deckhouse/index.md', collapsed: true, items: [ - {text: 'Подключение к сервису', link: '/PaaS/Deckhouse/connection.md'}, - {text: 'Техническое описание сервиса', link: '/PaaS/Deckhouse/specifications.md'}, + {text: 'Обзор сервиса', link: '/PaaS/Deckhouse/about.md'}, + {text: 'Права и возможности пользователей', link: '/PaaS/Deckhouse/user-permissions.md'}, {text: 'Описание технических параметров', link: '/PaaS/Deckhouse/technical-parameters.md'}, - {text: 'Права и возможности пользователей', link: '/PaaS/Deckhouse/user-permissions.md'} + {text: 'Подключение к сервису', link: '/PaaS/Deckhouse/connection.md'} ] } ], diff --git a/src/PaaS/Deckhouse/about.md b/src/PaaS/Deckhouse/about.md new file mode 100644 index 0000000..f83f134 --- /dev/null +++ b/src/PaaS/Deckhouse/about.md @@ -0,0 +1,107 @@ +# Cloud Deckhouse Kubernetes + +## Назначение сервиса + +**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-узлов не приводит к потере управления кластером. +::: + +::: warning Важно +Для тестовых сред возможна **одноузловая конфигурация 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/connection.md b/src/PaaS/Deckhouse/connection.md index 2c95707..0ea1af8 100644 --- a/src/PaaS/Deckhouse/connection.md +++ b/src/PaaS/Deckhouse/connection.md @@ -1,24 +1,27 @@ # Подключение к сервису Deckhouse -## О разделе - -В данном разделе описаны способы подключения к кластеру Cloud Deckhouse Kubernetes. Рассматривается работа с кластером через веб-интерфейс **Console**, а также управление через командную строку с использованием утилиты **kubectl** после генерации **kubeconfig**. Приведены примеры основных команд для начала работы. +В данном разделе описаны способы подключения к кластеру **Cloud Deckhouse Kubernetes**. Рассматривается работа с кластером через веб-интерфейс **Console**, а также управление через командную строку с использованием утилиты **kubectl** после генерации **kubeconfig**. ## Предварительные требования -После предоставления доступа к сервису Cloud Deckhouse Kubernetes пользователь получает возможность управлять кластером через веб-интерфейс Console.  +После предоставления доступа к **сервису Cloud Deckhouse Kubernetes** пользователь получает возможность управлять кластером через веб-интерфейс **Console**. -Console - это встроенный веб-интерфейс платформы Deckhouse, предназначенный для упрощения взаимодействия с Kubernetes-кластером . Он позволяет выполнять большинство операций, доступных в командной строке через **kubectl**, в визуальном режиме: мониторинг состояния кластера, управление узлами и модулями, настройку безопасности и сети . +**Console** - это встроенный веб-интерфейс платформы Deckhouse, предназначенный для упрощения взаимодействия с Kubernetes-кластером. -## Вход в Console +Он позволяет выполнять большинство операций, доступных в командной строке через **kubectl**, в визуальном режиме: +- мониторинг состояния кластера; +- управление узлами и модулями; +- настройку безопасности и сети. -1. Необходимо открыть веб-браузер и перейдите по адресу, предоставленному для доступа к Console; +## Вход в Console -: : : info -   URL-адрес направляется пользователю на электронную почту при предоставлении доступа. -: : : +1. Откройте веб-браузер и перейдите по адресу, предоставленному для доступа к Console. -2. На странице авторизации вводятся логин и пароль от учётной записи кластера; +::: info Примечание +URL-адрес направляется пользователю на электронную почту при предоставлении доступа. +::: + +2. На странице ввода учетных данных выполняется аутентификация при помощи логина и пароля; ![Авторизация](images/authorization.png) @@ -52,9 +55,9 @@ Console - это встроенный веб-интерфейс платформ 3. Нажимается кнопка генерации - система сгенерирует необходимые команды; 4. Далее, нужно скопировать и выполнить в терминале команды, которые сгенерированы для пользовательской учётной записи. -: : : info +::: info Примечание Сгенерированный **kubeconfig** уже содержит все необходимые параметры для подключения к API Kubernetes. -: : : +::: ## Примеры простейших команд kubectl diff --git a/src/PaaS/Deckhouse/index.md b/src/PaaS/Deckhouse/index.md index 0689646..7a1f9e9 100644 --- a/src/PaaS/Deckhouse/index.md +++ b/src/PaaS/Deckhouse/index.md @@ -1,20 +1,19 @@ --- section_links: - - title: Подключение к сервису Deckhouse - link: /PaaS/Deckhouse/connection.md - description: Подключение и работа с сервисом Deckhouse - - title: Техническое описание сервиса - link: /PaaS/Deckhouse/specifications.md - description: Технические характеристики и возможности сервиса + - title: Обзор сервиса + link: /PaaS/Deckhouse/about.md + description: Обзор сервиса + - title: Права и возможности пользователей + link: /PaaS/Deckhouse/user-permissions.md + description: Управление доступом и роли пользователей - title: Описание технических параметров link: /PaaS/Deckhouse/technical-parameters.md description: Параметры конфигурации сервиса Deckhouse - - title: Права и возможности пользователей - link: /PaaS/Deckhouse/user-permissions.md - description: Управление доступом и роли пользователей + - title: Подключение к сервису Deckhouse + link: /PaaS/Deckhouse/connection.md + description: Подключение и работа с сервисом Deckhouse --- -# Deckhouse - -В данном разделе представлена документация по управлемому сервису **Deckhouse** платформы Beeline Cloud. +# Cloud Deckhouse Kubernetes +В данном разделе представлена документация по управлемому сервису **Cloud Deckhouse Kubernetes** платформы Beeline Cloud. diff --git a/src/PaaS/Deckhouse/specifications.md b/src/PaaS/Deckhouse/specifications.md deleted file mode 100644 index 25c2d5f..0000000 --- a/src/PaaS/Deckhouse/specifications.md +++ /dev/null @@ -1,87 +0,0 @@ -# Техническое описание сервиса - -## О сервисе - -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 index 59c74b4..ca8aea6 100644 --- a/src/PaaS/Deckhouse/technical-parameters.md +++ b/src/PaaS/Deckhouse/technical-parameters.md @@ -1,87 +1,111 @@ # Описание технических параметров -## О разделе +Данный раздел содержит технические параметры **кластера Kubernetes** и порядок их первичной конфигурации. -Данный раздел содержит технические параметры кластера Kubernetes и порядок их первичной конфигурации. +Настройка параметров выполняется администратором облачного провайдера на этапе развертывания сервиса. Пользователь не может изменять их самостоятельно (исключение — конфигурация worker-узлов). -Настройка указанных параметров выполняется администратором облачного провайдера на этапе развёртывания сервиса. Пользователь не имеет прямого доступа к их самостоятельной установке (за исключением конфигурации worker-узлов). +**Процедура согласования параметров:** -Перед созданием кластера клиент предоставляет перечень требуемых параметров менеджеру. Администратор облачного провайдера выполняет конфигурацию в соответствии с согласованными требованиями. +1. Клиент передает менеджеру список требуемых параметров. +2. Администратор выполняет настройку по согласованным требованиям. -## Выбор типа и размера дискового хранилища +## Дисковое хранилище -Производительность приложений в Kubernetes напрямую зависит от скорости, с которой они могут читать и записывать данные на диск. При заказе кластера необходимо выбрать тип дискового хранилища, который определит максимальную скорость работы (IOPS) и время отклика. +Производительность приложений в Kubernetes зависит от скорости чтения и записи данных на диск. Тип хранилища определяет: -**IOPS (Input/Output Operations Per Second)** - количество операций чтения или записи, которые диск может выполнить за секунду. Чем выше этот показатель, тем быстрее работают базы данных и другие приложения, интенсивно работающие с диском. +- **IOPS** (Input/Output Operations Per Second) — количество операций ввода-вывода в секунду; +- **время отклика** (латентность). + +::: info Примечание +Чем выше IOPS, тем быстрее работают базы данных и другие диско-интенсивные приложения. +::: ## Доступные типы хранилищ: -| Название | Лимит IOPS | +| Тип | Лимит IOPS | | ---------- | ------------------ | | Fast SAS | до 2 IOPS на 1 ГБ | | SSD | до 5 IOPS на 1 ГБ | | Fast SSD | до 10 IOPS на 1 ГБ | -| Ultra NVMe | до 25 IOPS на 1 ГБ +| Ultra NVMe | до 25 IOPS на 1 ГБ | -: : : warning -После выбора типа диска необходимо указать объем дискового хранилища, который будет выделен под данные приложений (Persistent Volumes). Минимальный объем - 50 ГБ. -: : : +::: warning Важно +После выбора типа диска необходимо указать объем дискового хранилища, который будет выделен под данные приложений (Persistent Volumes). **Минимальный объем - 50 ГБ.** +::: ## Конфигурация вычислительных ресурсов -В данном разделе определяются вычислительные мощности кластера: процессорные ресурсы, оперативная память и количество узлов, из которых будет состоять кластер Kubernetes. +Вычислительные мощности кластера включают: -### Количество узлов в кластере +- процессорные ресурсы (vCPU); +- оперативную память (RAM); +- количество узлов. -Количество узлов определяет отказоустойчивость кластера и возможность распределять нагрузку между worker-узлами. Чем больше узлов, тем выше надёжность и пропускная способность. +### Узлы в кластере -#### Master-узлы (control plane) +Количество узлов определяет отказоустойчивость кластера и возможность распределять нагрузку между worker-узлами. -Для обеспечения отказоустойчивости кластера рекомендуется использовать не менее трёх master-узлов. Такое количество обеспечивает безотказную работу кластера и позволяет безопасно обновлять master-узлы. В большем числе нет необходимости, а двух узлов недостаточно для обеспечения согласия между master-узлами (кворума) в случае возникновения неполадок с одним из них. +::: info Примечение +Чем больше узлов, тем выше надежность и пропускная способность. +::: -При использовании всего одного master-узла его отказ приводит к сбою всего кластера, так как именно master-узел управляет ключевыми компонентами, обеспечивающими работу кластера. +#### 1. Master-узлы (control plane) -#### System-узлы +Для обеспечения отказоустойчивости кластера **рекомендуется использовать не менее трех master-узлов**. -Системные узлы предназначены для запуска модулей Deckhouse. Рекомендуется выделить два системных узла. В этом случае модули Deckhouse будут работать на них, не пересекаясь с пользовательскими приложениями кластера. +| Количество узлов | Результат | +|------------------|-----------------------------------------------------------------------------------------------| +| 3 и более | Обеспечивают кворум, безопасное обновление и отказоустойчивость. Большего числа не требуется. | +| 2 | Недостаточно для кворума при отказе одного узла. | +| 1 | Отказ узла приводит к полному сбою кластера. | -#### Frontend-узлы +#### 2. System-узлы -Frontend-узлы балансируют входящий трафик, на них работают Ingress-контроллеры. Рекомендуется использовать более одного frontend-узла. Frontend-узлы должны выдерживать трафик при отказе как минимум одного узла. +Предназначены для запуска модулей Deckhouse. -: : : info -Если в кластере два frontend-узла, каждый из них должен справляться со всей нагрузкой на кластер в случае выхода второго из строя. -: : : +**Рекомендация:** два узла. Это изолирует системные модули от пользовательских приложений. -: : : info -Если в кластере три frontend-узла, каждый должен выдерживать увеличение нагрузки как минимум в полтора раза. -: : : +#### 3. Frontend-узлы -#### Worker-узлы +Балансируют входящий трафик, на них работают Ingress-контроллеры. -Количество worker-узлов - от 1 и более. На них выполняются пользовательские приложения. В дальнейшем пользователь может самостоятельно увеличить их максимальное количество. +**Рекомендация:** более одного узла. + +**Требования к емкости:** + +| Количество узлов | Требование к каждому узлу | +|------------------|---------------------------------------------------| +| 2 | Должен выдержать 100% нагрузки при отказе второго | +| 3 | Должен выдержать увеличение нагрузки в 1.5 раза | + +#### 4. Worker-узлы + +На них выполняются пользовательские приложения. + +- **Рекомендация:** от 1 узла. +- **Управление:** пользователь может увеличивать максимальное количество узлов самостоятельно. ## Процессор (CPU) -Процессор - это вычислительная мощность, выделяемая каждому узлу кластера. Количество vCPU определяет, насколько быстро приложения смогут: +**Процессор** - это вычислительная мощность, выделяемая каждому узлу кластера. Количество vCPU определяет, насколько быстро приложения смогут: - обрабатывать запросы; - выполнять сложные вычисления; - обслуживать одновременные подключения. -Доступный диапазон: от 2 до 24 vCPU на один узел. +**Диапазон**: от 2 до 24 vCPU на один узел. ## Оперативная память (RAM) -Оперативная память - один из ключевых ресурсов для производительности приложений. Данные, помещающиеся в RAM, обрабатываются максимально быстро, без обращения к диску. +**Оперативная память** - влияет на производительность приложений. Данные в RAM обрабатываются без обращения к диску. -Доступный диапазон: от 4 до 768 ГБ RAM на один узел. +**Диапазон**: от 4 до 768 ГБ RAM на один узел. ## Доступ в интернет -При заказе сервиса можно выбрать пропускную способность канала связи, через который будет осуществляться доступ к кластеру Kubernetes из сети интернет. +При заказе сервиса выберите пропускную способность канала для доступа к кластеру из интернета. -Доступные варианты скорости: +**Доступные скорости**: - 50 Мбит/с; - 100 Мбит/с; @@ -91,6 +115,6 @@ Frontend-узлы балансируют входящий трафик, на н - 500 Мбит/с; - 1000 Мбит/с (1 Гбит/с). -: : : info -Для выбранного канала предоставляется статический белый IP-адрес. -: : : \ No newline at end of file +::: info Примечание +Для выбранного канала предоставляется **статический белый IP-адрес**. +::: \ No newline at end of file diff --git a/src/PaaS/Deckhouse/user-permissions.md b/src/PaaS/Deckhouse/user-permissions.md index c8ca3e8..2be5492 100644 --- a/src/PaaS/Deckhouse/user-permissions.md +++ b/src/PaaS/Deckhouse/user-permissions.md @@ -1,12 +1,12 @@ # Права и возможности пользователей -## О разделе +При развертывании сервиса Cloud Deckhouse Kubernetes создается учетная запись с уровнем доступа **SuperAdmin**. Этот уровень предоставляет расширенные права на управление кластером Kubernetes. -Данный раздел описывает права, которые предоставляются пользователю Deckhouse при создании сервиса Cloud Deckhouse Kubernetes, а также перечень административных операций, доступных ему для самостоятельного выполнения. +**SuperAdmin** получает полный контроль над своими приложениями и ресурсами в пределах выделенного кластера или пространства имен (namespace). -При развертывании сервиса создается учетная запись, которая имеет уровень доступа **SuperAdmin**. Данный уровень предоставляет расширенные права на управление кластером Kubernetes, позволяя получить полный контроль над своими приложениями и ресурсами в пределах выделенного кластера или пространства имен (namespace). +## Ограничения доступа SuperAdmin -**Ограничения доступа SuperAdmin:** +SuperAdmin **не имеет доступа** к следующим компонентам: - инфраструктурный уровень (гипервизоры, физические серверы, сетевое оборудование); - управление компонентами платформы Deckhouse на уровне всего кластера; @@ -17,65 +17,67 @@ ### Управление пространствами имен (Namespaces) -SuperAdmin может создавать, изменять и удалять пространства имен. +SuperAdmin может управлять пространствами имен: -- создание нового namespace; -- удаление namespace (при этом все ресурсы внутри него также удаляются); -- просмотр списка всех namespace; -- установка меток (labels) и аннотаций для namespace. +- создавать новые namespace; +- удалять namespace (все ресурсы внутри удаляются); +- просматривать список всех namespace; +- устанавливать метки (labels) и аннотации для namespace. ### Управление рабочими нагрузками -SuperAdmin имеет полный контроль над подами, развёртываниями и другими ресурсами приложений. +SuperAdmin имеет полный контроль над подами, развёртываниями и другими ресурсами приложений: -- создание, обновление и удаление Deployment, StatefulSet, DaemonSet; -- создание, обновление и удаление Pod; -- просмотр логов подов (`kubectl logs`); -- подключение к выполняющемуся контейнеру (`kubectl exec`); -- масштабирование развёртываний (увеличение или уменьшение количества реплик); -- обновление версий образов контейнеров; -- удаление подов (в том числе принудительное); -- просмотр событий (events) в namespace. +- создавать, обновлять и удалять Deployment, StatefulSet, DaemonSet; +- создавать, обновлять и удалять Pod; +- просматривать логи подов (`kubectl logs`); +- подключаться к выполняющемуся контейнеру (`kubectl exec`); +- масштабировать развертывания (увеличивать или уменьшать количество реплик); +- обновлять версии образов контейнеров; +- удалять поды (в том числе принудительно); +- просматривать события (events) в namespace. ### Управление сетевым доступом (Services & Ingress) -SuperAdmin может настраивать способы доступа к приложениям как внутри кластера, так и из внешней сети. +SuperAdmin может настраивать способы доступа к приложениям как внутри кластера, так и из внешней сети: -- создание, изменение и удаление Service (типы: ClusterIP, NodePort, LoadBalancer); -- создание, изменение и удаление Ingress-правил для маршрутизации входящего трафика; -- настройка портов и селекторов для сервисов; -- просмотр списка сервисов и их конечных точек (endpoints). +SuperAdmin может настраивать способы доступа к приложениям внутри кластера и из внешней сети: + +- создавать, изменять и удалять Service (типы: ClusterIP, NodePort, LoadBalancer); +- создавать, изменять и удалять Ingress-правила для маршрутизации входящего трафика; +- настраивать порты и селекторы для сервисов; +- просматривать список сервисов и их конечных точек (endpoints). ### Управление хранилищем (Storage) -SuperAdmin может создавать и использовать тома для хранения данных приложений. +SuperAdmin может создавать и использовать тома для хранения данных приложений: -- создание Persistent Volume Claim (PVC); -- удаление PVC (освобождение дискового пространства); -- просмотр списка PVC и их статусов; -- использование PVC в подах (монтирование томов). +- создавать Persistent Volume Claim (PVC); +- удалять PVC (освобождать дисковое пространство); +- просматривать список PVC и их статусов; +- использовать PVC в подах (монтировать тома). ### Управление конфигурацией (ConfigMaps & Secrets) -SuperAdmin может создавать и изменять конфигурационные данные и секреты для приложений. +SuperAdmin может создавать и изменять конфигурационные данные и секреты для приложений: -- создание, изменение и удаление ConfigMap; -- создание, изменение и удаление Secrets (например, для хранения паролей, токенов, ключей); -- монтирование ConfigMap и Secrets в поды в виде переменных окружения или файлов. +- создавать, изменять и удалять ConfigMap; +- создавать, изменять и удалять Secrets (например, для хранения токенов, паролей или ключей); +- монтировать ConfigMap и Secrets в поды в виде переменных окружения или файлов. ### Мониторинг и наблюдаемость -SuperAdmin имеет доступ к метрикам и логам своих приложений. +SuperAdmin имеет доступ к метрикам и логам своих приложений: -- просмотр метрик приложений в Grafana; -- просмотр логов через `kubectl logs` или через интерфейс сбора логов (Loki); -- просмотр дашбордов с информацией о потреблении ресурсов (CPU, RAM, Storage) своими приложениями; -- просмотр событий Kubernetes (events) для диагностики проблем. +- просматривать метрики приложений в Grafana; +- просматривать логи через `kubectl logs` или интерфейс сбора логов (Loki); +- просматривать дашборды с информацией о потреблении ресурсов (CPU, RAM, Storage) своими приложениями; +- просматривать события Kubernetes (events) для диагностики проблем. ### Управление доступом (RBAC) -SuperAdmin может управлять правами других пользователей в рамках своего пространства имен. +SuperAdmin может управлять правами других пользователей в рамках своего пространства имен: -- создание и удаление учётных записей (ServiceAccount); -- назначение ролей (Role, RoleBinding) другим пользователям в пределах своего namespace; -- ограничение доступа к отдельным ресурсам. \ No newline at end of file +- создавать и удалять учетные записи (ServiceAccount); +- назначать роли (Role, RoleBinding) другим пользователям в пределах своего namespace; +- ограничивать доступ к отдельным ресурсам. \ No newline at end of file diff --git a/src/PaaS/index.md b/src/PaaS/index.md index 933c9aa..c6e4185 100644 --- a/src/PaaS/index.md +++ b/src/PaaS/index.md @@ -3,10 +3,10 @@ section_links: - title: Cloud PostgreSQL link: /PaaS/PostgreSQL/PostgreSQL-index.md description: Обзор сервиса PostgreSQL + - title: Deckhouse + link: /PaaS/Deckhouse/index.md + description: Обзор сервиса Deckhouse Kubernetes - title: IPSEC link: /PaaS/IPSEC.md description: Параметры конфигурации IPSEC - --- - -# Начало работы в Cloud PostgreSQL