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