сервис deckhouse
This commit is contained in:
Левченко Людмила Алексеевна
@@ -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'}
|
||||
]
|
||||
}
|
||||
],
|
||||
|
||||
@@ -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-кластера без ручной настройки сети, хранилищ и мониторинга;
|
||||
- администрирование через веб-интерфейс без прямого доступа к серверам.
|
||||
@@ -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-кластером.
|
||||
|
||||
Он позволяет выполнять большинство операций, доступных в командной строке через **kubectl**, в визуальном режиме:
|
||||
- мониторинг состояния кластера;
|
||||
- управление узлами и модулями;
|
||||
- настройку безопасности и сети.
|
||||
|
||||
## Вход в Console
|
||||
|
||||
1. Необходимо открыть веб-браузер и перейдите по адресу, предоставленному для доступа к Console;
|
||||
1. Откройте веб-браузер и перейдите по адресу, предоставленному для доступа к Console.
|
||||
|
||||
: : : info
|
||||
URL-адрес направляется пользователю на электронную почту при предоставлении доступа.
|
||||
::: info Примечание
|
||||
URL-адрес направляется пользователю на электронную почту при предоставлении доступа.
|
||||
:::
|
||||
|
||||
2. На странице авторизации вводятся логин и пароль от учётной записи кластера;
|
||||
2. На странице ввода учетных данных выполняется аутентификация при помощи логина и пароля;
|
||||
|
||||
|
||||
|
||||
@@ -52,7 +55,7 @@ Console - это встроенный веб-интерфейс платформ
|
||||
3. Нажимается кнопка генерации - система сгенерирует необходимые команды;
|
||||
4. Далее, нужно скопировать и выполнить в терминале команды, которые сгенерированы для пользовательской учётной записи.
|
||||
|
||||
: : : info
|
||||
::: info Примечание
|
||||
Сгенерированный **kubeconfig** уже содержит все необходимые параметры для подключения к API Kubernetes.
|
||||
:::
|
||||
|
||||
|
||||
+11
-12
@@ -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/technical-parameters.md
|
||||
description: Параметры конфигурации сервиса Deckhouse
|
||||
- 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: Подключение к сервису Deckhouse
|
||||
link: /PaaS/Deckhouse/connection.md
|
||||
description: Подключение и работа с сервисом Deckhouse
|
||||
---
|
||||
|
||||
# Deckhouse
|
||||
|
||||
В данном разделе представлена документация по управлемому сервису **Deckhouse** платформы Beeline Cloud.
|
||||
# Cloud Deckhouse Kubernetes
|
||||
|
||||
В данном разделе представлена документация по управлемому сервису **Cloud Deckhouse Kubernetes** платформы Beeline Cloud.
|
||||
|
||||
@@ -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-кластера без ручной настройки сети, хранилищ и мониторинга;
|
||||
- администрирование через веб-интерфейс без прямого доступа к серверам.
|
||||
@@ -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-узлами (кворума) в случае возникновения неполадок с одним из них.
|
||||
|
||||
При использовании всего одного master-узла его отказ приводит к сбою всего кластера, так как именно master-узел управляет ключевыми компонентами, обеспечивающими работу кластера.
|
||||
|
||||
#### System-узлы
|
||||
|
||||
Системные узлы предназначены для запуска модулей Deckhouse. Рекомендуется выделить два системных узла. В этом случае модули Deckhouse будут работать на них, не пересекаясь с пользовательскими приложениями кластера.
|
||||
|
||||
#### Frontend-узлы
|
||||
|
||||
Frontend-узлы балансируют входящий трафик, на них работают Ingress-контроллеры. Рекомендуется использовать более одного frontend-узла. Frontend-узлы должны выдерживать трафик при отказе как минимум одного узла.
|
||||
|
||||
: : : info
|
||||
Если в кластере два frontend-узла, каждый из них должен справляться со всей нагрузкой на кластер в случае выхода второго из строя.
|
||||
::: info Примечение
|
||||
Чем больше узлов, тем выше надежность и пропускная способность.
|
||||
:::
|
||||
|
||||
: : : info
|
||||
Если в кластере три frontend-узла, каждый должен выдерживать увеличение нагрузки как минимум в полтора раза.
|
||||
: : :
|
||||
#### 1. Master-узлы (control plane)
|
||||
|
||||
#### Worker-узлы
|
||||
Для обеспечения отказоустойчивости кластера **рекомендуется использовать не менее трех master-узлов**.
|
||||
|
||||
Количество worker-узлов - от 1 и более. На них выполняются пользовательские приложения. В дальнейшем пользователь может самостоятельно увеличить их максимальное количество.
|
||||
| Количество узлов | Результат |
|
||||
|------------------|-----------------------------------------------------------------------------------------------|
|
||||
| 3 и более | Обеспечивают кворум, безопасное обновление и отказоустойчивость. Большего числа не требуется. |
|
||||
| 2 | Недостаточно для кворума при отказе одного узла. |
|
||||
| 1 | Отказ узла приводит к полному сбою кластера. |
|
||||
|
||||
#### 2. System-узлы
|
||||
|
||||
Предназначены для запуска модулей Deckhouse.
|
||||
|
||||
**Рекомендация:** два узла. Это изолирует системные модули от пользовательских приложений.
|
||||
|
||||
#### 3. Frontend-узлы
|
||||
|
||||
Балансируют входящий трафик, на них работают Ingress-контроллеры.
|
||||
|
||||
**Рекомендация:** более одного узла.
|
||||
|
||||
**Требования к емкости:**
|
||||
|
||||
| Количество узлов | Требование к каждому узлу |
|
||||
|------------------|---------------------------------------------------|
|
||||
| 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-адрес.
|
||||
::: info Примечание
|
||||
Для выбранного канала предоставляется **статический белый IP-адрес**.
|
||||
:::
|
||||
@@ -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;
|
||||
- ограничение доступа к отдельным ресурсам.
|
||||
- создавать и удалять учетные записи (ServiceAccount);
|
||||
- назначать роли (Role, RoleBinding) другим пользователям в пределах своего namespace;
|
||||
- ограничивать доступ к отдельным ресурсам.
|
||||
+3
-3
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user