сервис deckhouse

This commit is contained in:
Левченко Людмила Алексеевна
2026-05-07 17:40:34 +03:00
parent b6b3a2b45e
commit 697c368f5c
8 changed files with 248 additions and 201 deletions
+5 -6
View File
@@ -293,17 +293,16 @@ export default defineConfig({
{text: 'Веб-интерфейс Grafana', link: '/PaaS/PostgreSQL/grafana.md'}, {text: 'Веб-интерфейс Grafana', link: '/PaaS/PostgreSQL/grafana.md'},
], ],
}, },
{text: 'Параметры конфигурации IPSEC', link: '/PaaS/IPSEC.md'}, {text: 'IPSEC', link: '/PaaS/IPSEC.md'},
{ {
text: 'Deckhouse', text: 'Deckhouse', link: 'PaaS/Deckhouse/index.md',
link: 'PaaS/Deckhouse/index.md',
collapsed: true, collapsed: true,
items: [ items: [
{text: 'Подключение к сервису', link: '/PaaS/Deckhouse/connection.md'}, {text: 'Обзор сервиса', link: '/PaaS/Deckhouse/about.md'},
{text: 'Техническое описание сервиса', link: '/PaaS/Deckhouse/specifications.md'}, {text: 'Права и возможности пользователей', link: '/PaaS/Deckhouse/user-permissions.md'},
{text: 'Описание технических параметров', link: '/PaaS/Deckhouse/technical-parameters.md'}, {text: 'Описание технических параметров', link: '/PaaS/Deckhouse/technical-parameters.md'},
{text: рава и возможности пользователей', link: '/PaaS/Deckhouse/user-permissions.md'} {text: одключение к сервису', link: '/PaaS/Deckhouse/connection.md'}
] ]
} }
], ],
+107
View File
@@ -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-кластера без ручной настройки сети, хранилищ и мониторинга;
- администрирование через веб-интерфейс без прямого доступа к серверам.
+16 -13
View File
@@ -1,24 +1,27 @@
# Подключение к сервису Deckhouse # Подключение к сервису 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 1. Откройте веб-браузер и перейдите по адресу, предоставленному для доступа к Console.
   URL-адрес направляется пользователю на электронную почту при предоставлении доступа.
: : :
2. На странице авторизации вводятся логин и пароль от учётной записи кластера; ::: info Примечание
URL-адрес направляется пользователю на электронную почту при предоставлении доступа.
:::
2. На странице ввода учетных данных выполняется аутентификация при помощи логина и пароля;
![Авторизация](images/authorization.png) ![Авторизация](images/authorization.png)
@@ -52,9 +55,9 @@ Console - это встроенный веб-интерфейс платформ
3. Нажимается кнопка генерации - система сгенерирует необходимые команды; 3. Нажимается кнопка генерации - система сгенерирует необходимые команды;
4. Далее, нужно скопировать и выполнить в терминале команды, которые сгенерированы для пользовательской учётной записи. 4. Далее, нужно скопировать и выполнить в терминале команды, которые сгенерированы для пользовательской учётной записи.
: : : info ::: info Примечание
Сгенерированный **kubeconfig** уже содержит все необходимые параметры для подключения к API Kubernetes. Сгенерированный **kubeconfig** уже содержит все необходимые параметры для подключения к API Kubernetes.
: : : :::
## Примеры простейших команд kubectl ## Примеры простейших команд kubectl
+11 -12
View File
@@ -1,20 +1,19 @@
--- ---
section_links: section_links:
- title: Подключение к сервису Deckhouse - title: Обзор сервиса
link: /PaaS/Deckhouse/connection.md link: /PaaS/Deckhouse/about.md
description: Подключение и работа с сервисом Deckhouse description: Обзор сервиса
- title: Техническое описание сервиса - title: Права и возможности пользователей
link: /PaaS/Deckhouse/specifications.md link: /PaaS/Deckhouse/user-permissions.md
description: Технические характеристики и возможности сервиса description: Управление доступом и роли пользователей
- title: Описание технических параметров - title: Описание технических параметров
link: /PaaS/Deckhouse/technical-parameters.md link: /PaaS/Deckhouse/technical-parameters.md
description: Параметры конфигурации сервиса Deckhouse description: Параметры конфигурации сервиса Deckhouse
- title: Права и возможности пользователей - title: Подключение к сервису Deckhouse
link: /PaaS/Deckhouse/user-permissions.md link: /PaaS/Deckhouse/connection.md
description: Управление доступом и роли пользователей description: Подключение и работа с сервисом Deckhouse
--- ---
# Deckhouse # Cloud Deckhouse Kubernetes
В данном разделе представлена документация по управлемому сервису **Deckhouse** платформы Beeline Cloud.
В данном разделе представлена документация по управлемому сервису **Cloud Deckhouse Kubernetes** платформы Beeline Cloud.
-87
View File
@@ -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-кластера без ручной настройки сети, хранилищ и мониторинга;
- администрирование через веб-интерфейс без прямого доступа к серверам.
+63 -39
View File
@@ -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 ГБ | | Fast SAS | до 2 IOPS на 1 ГБ |
| SSD | до 5 IOPS на 1 ГБ | | SSD | до 5 IOPS на 1 ГБ |
| Fast SSD | до 10 IOPS на 1 ГБ | | Fast SSD | до 10 IOPS на 1 ГБ |
| Ultra NVMe | до 25 IOPS на 1 ГБ | Ultra NVMe | до 25 IOPS на 1 ГБ |
: : : warning ::: warning Важно
После выбора типа диска необходимо указать объем дискового хранилища, который будет выделен под данные приложений (Persistent Volumes). Минимальный объем - 50 ГБ. После выбора типа диска необходимо указать объем дискового хранилища, который будет выделен под данные приложений (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 #### 3. Frontend-узлы
Если в кластере три frontend-узла, каждый должен выдерживать увеличение нагрузки как минимум в полтора раза.
: : :
#### Worker-узлы Балансируют входящий трафик, на них работают Ingress-контроллеры.
Количество worker-узлов - от 1 и более. На них выполняются пользовательские приложения. В дальнейшем пользователь может самостоятельно увеличить их максимальное количество. **Рекомендация:** более одного узла.
**Требования к емкости:**
| Количество узлов | Требование к каждому узлу |
|------------------|---------------------------------------------------|
| 2 | Должен выдержать 100% нагрузки при отказе второго |
| 3 | Должен выдержать увеличение нагрузки в 1.5 раза |
#### 4. Worker-узлы
На них выполняются пользовательские приложения.
- **Рекомендация:** от 1 узла.
- **Управление:** пользователь может увеличивать максимальное количество узлов самостоятельно.
## Процессор (CPU) ## Процессор (CPU)
Процессор - это вычислительная мощность, выделяемая каждому узлу кластера. Количество vCPU определяет, насколько быстро приложения смогут: **Процессор** - это вычислительная мощность, выделяемая каждому узлу кластера. Количество vCPU определяет, насколько быстро приложения смогут:
- обрабатывать запросы; - обрабатывать запросы;
- выполнять сложные вычисления; - выполнять сложные вычисления;
- обслуживать одновременные подключения. - обслуживать одновременные подключения.
Доступный диапазон: от 2 до 24 vCPU на один узел. **Диапазон**: от 2 до 24 vCPU на один узел.
## Оперативная память (RAM) ## Оперативная память (RAM)
Оперативная память - один из ключевых ресурсов для производительности приложений. Данные, помещающиеся в RAM, обрабатываются максимально быстро, без обращения к диску. **Оперативная память** - влияет на производительность приложений. Данные в RAM обрабатываются без обращения к диску.
Доступный диапазон: от 4 до 768 ГБ RAM на один узел. **Диапазон**: от 4 до 768 ГБ RAM на один узел.
## Доступ в интернет ## Доступ в интернет
При заказе сервиса можно выбрать пропускную способность канала связи, через который будет осуществляться доступ к кластеру Kubernetes из сети интернет. При заказе сервиса выберите пропускную способность канала для доступа к кластеру из интернета.
Доступные варианты скорости: **Доступные скорости**:
- 50 Мбит/с; - 50 Мбит/с;
- 100 Мбит/с; - 100 Мбит/с;
@@ -91,6 +115,6 @@ Frontend-узлы балансируют входящий трафик, на н
- 500 Мбит/с; - 500 Мбит/с;
- 1000 Мбит/с (1 Гбит/с). - 1000 Мбит/с (1 Гбит/с).
: : : info ::: info Примечание
Для выбранного канала предоставляется статический белый IP-адрес. Для выбранного канала предоставляется **статический белый IP-адрес**.
: : : :::
+43 -41
View File
@@ -1,12 +1,12 @@
# Права и возможности пользователей # Права и возможности пользователей
## О разделе При развертывании сервиса Cloud Deckhouse Kubernetes создается учетная запись с уровнем доступа **SuperAdmin**. Этот уровень предоставляет расширенные права на управление кластером Kubernetes.
Данный раздел описывает права, которые предоставляются пользователю Deckhouse при создании сервиса Cloud Deckhouse Kubernetes, а также перечень административных операций, доступных ему для самостоятельного выполнения. **SuperAdmin** получает полный контроль над своими приложениями и ресурсами в пределах выделенного кластера или пространства имен (namespace).
При развертывании сервиса создается учетная запись, которая имеет уровень доступа **SuperAdmin**. Данный уровень предоставляет расширенные права на управление кластером Kubernetes, позволяя получить полный контроль над своими приложениями и ресурсами в пределах выделенного кластера или пространства имен (namespace). ## Ограничения доступа SuperAdmin
**Ограничения доступа SuperAdmin:** SuperAdmin **не имеет доступа** к следующим компонентам:
- инфраструктурный уровень (гипервизоры, физические серверы, сетевое оборудование); - инфраструктурный уровень (гипервизоры, физические серверы, сетевое оборудование);
- управление компонентами платформы Deckhouse на уровне всего кластера; - управление компонентами платформы Deckhouse на уровне всего кластера;
@@ -17,65 +17,67 @@
### Управление пространствами имен (Namespaces) ### Управление пространствами имен (Namespaces)
SuperAdmin может создавать, изменять и удалять пространства имен. SuperAdmin может управлять пространствами имен:
- создание нового namespace; - создавать новые namespace;
- удаление namespace (при этом все ресурсы внутри него также удаляются); - удалять namespace (все ресурсы внутри удаляются);
- просмотр списка всех namespace; - просматривать список всех namespace;
- установка меток (labels) и аннотаций для namespace. - устанавливать метки (labels) и аннотации для namespace.
### Управление рабочими нагрузками ### Управление рабочими нагрузками
SuperAdmin имеет полный контроль над подами, развёртываниями и другими ресурсами приложений. SuperAdmin имеет полный контроль над подами, развёртываниями и другими ресурсами приложений:
- создание, обновление и удаление Deployment, StatefulSet, DaemonSet; - создавать, обновлять и удалять Deployment, StatefulSet, DaemonSet;
- создание, обновление и удаление Pod; - создавать, обновлять и удалять Pod;
- просмотр логов подов (`kubectl logs`); - просматривать логи подов (`kubectl logs`);
- подключение к выполняющемуся контейнеру (`kubectl exec`); - подключаться к выполняющемуся контейнеру (`kubectl exec`);
- масштабирование развёртываний (увеличение или уменьшение количества реплик); - масштабировать развертывания (увеличивать или уменьшать количество реплик);
- обновление версий образов контейнеров; - обновлять версии образов контейнеров;
- удаление подов (в том числе принудительное); - удалять поды (в том числе принудительно);
- просмотр событий (events) в namespace. - просматривать события (events) в namespace.
### Управление сетевым доступом (Services & Ingress) ### Управление сетевым доступом (Services & Ingress)
SuperAdmin может настраивать способы доступа к приложениям как внутри кластера, так и из внешней сети. SuperAdmin может настраивать способы доступа к приложениям как внутри кластера, так и из внешней сети:
- создание, изменение и удаление Service (типы: ClusterIP, NodePort, LoadBalancer); SuperAdmin может настраивать способы доступа к приложениям внутри кластера и из внешней сети:
- создание, изменение и удаление Ingress-правил для маршрутизации входящего трафика;
- настройка портов и селекторов для сервисов; - создавать, изменять и удалять Service (типы: ClusterIP, NodePort, LoadBalancer);
- просмотр списка сервисов и их конечных точек (endpoints). - создавать, изменять и удалять Ingress-правила для маршрутизации входящего трафика;
- настраивать порты и селекторы для сервисов;
- просматривать список сервисов и их конечных точек (endpoints).
### Управление хранилищем (Storage) ### Управление хранилищем (Storage)
SuperAdmin может создавать и использовать тома для хранения данных приложений. SuperAdmin может создавать и использовать тома для хранения данных приложений:
- создание Persistent Volume Claim (PVC); - создавать Persistent Volume Claim (PVC);
- удаление PVC (освобождение дискового пространства); - удалять PVC (освобождать дисковое пространство);
- просмотр списка PVC и их статусов; - просматривать список PVC и их статусов;
- использование PVC в подах (монтирование томов). - использовать PVC в подах (монтировать тома).
### Управление конфигурацией (ConfigMaps & Secrets) ### Управление конфигурацией (ConfigMaps & Secrets)
SuperAdmin может создавать и изменять конфигурационные данные и секреты для приложений. SuperAdmin может создавать и изменять конфигурационные данные и секреты для приложений:
- создание, изменение и удаление ConfigMap; - создавать, изменять и удалять ConfigMap;
- создание, изменение и удаление Secrets (например, для хранения паролей, токенов, ключей); - создавать, изменять и удалять Secrets (например, для хранения токенов, паролей или ключей);
- монтирование ConfigMap и Secrets в поды в виде переменных окружения или файлов. - монтировать ConfigMap и Secrets в поды в виде переменных окружения или файлов.
### Мониторинг и наблюдаемость ### Мониторинг и наблюдаемость
SuperAdmin имеет доступ к метрикам и логам своих приложений. SuperAdmin имеет доступ к метрикам и логам своих приложений:
- просмотр метрик приложений в Grafana; - просматривать метрики приложений в Grafana;
- просмотр логов через `kubectl logs` или через интерфейс сбора логов (Loki); - просматривать логи через `kubectl logs` или интерфейс сбора логов (Loki);
- просмотр дашбордов с информацией о потреблении ресурсов (CPU, RAM, Storage) своими приложениями; - просматривать дашборды с информацией о потреблении ресурсов (CPU, RAM, Storage) своими приложениями;
- просмотр событий Kubernetes (events) для диагностики проблем. - просматривать события Kubernetes (events) для диагностики проблем.
### Управление доступом (RBAC) ### Управление доступом (RBAC)
SuperAdmin может управлять правами других пользователей в рамках своего пространства имен. SuperAdmin может управлять правами других пользователей в рамках своего пространства имен:
- создание и удаление учётных записей (ServiceAccount); - создавать и удалять учетные записи (ServiceAccount);
- назначение ролей (Role, RoleBinding) другим пользователям в пределах своего namespace; - назначать роли (Role, RoleBinding) другим пользователям в пределах своего namespace;
- ограничение доступа к отдельным ресурсам. - ограничивать доступ к отдельным ресурсам.
+3 -3
View File
@@ -3,10 +3,10 @@ section_links:
- title: Cloud PostgreSQL - title: Cloud PostgreSQL
link: /PaaS/PostgreSQL/PostgreSQL-index.md link: /PaaS/PostgreSQL/PostgreSQL-index.md
description: Обзор сервиса PostgreSQL description: Обзор сервиса PostgreSQL
- title: Deckhouse
link: /PaaS/Deckhouse/index.md
description: Обзор сервиса Deckhouse Kubernetes
- title: IPSEC - title: IPSEC
link: /PaaS/IPSEC.md link: /PaaS/IPSEC.md
description: Параметры конфигурации IPSEC description: Параметры конфигурации IPSEC
--- ---
# Начало работы в Cloud PostgreSQL