Привет, Хабр! Я Максим, инженер по тестированию в Selectel. Недавно мы провели технический воркшоп по работе с Kubernetes на выделенных серверах. Под катом — подробный текстовый разбор. Рассмотрим создание кластера через панель управления, деплой приложения, настройку внешнего доступа и подключение облачной базы данных с тестовым запросом прямо из пода.

Используйте навигацию, если не хотите читать текст полностью

• Почему именно выделенные серверы для рабочих нод

• Как облако и «железо» работают вместе

• Создаем кластер за 10 минут

• Практический воркшоп: развертываем первое приложение

• Интеграция с облачными базами данных: соединяем лучшее из двух миров

• Управление и эксплуатация кластера на выделенных серверах

• Продвинутые сценарии и будущие возможности

• Оптимизация затрат и специальные предложения

• Заключение

Несколько слов о компании

Selectel — провайдер IT-инфраструктуры. Мы искали способ объединить мощь и надежность наших машин. Одним из таких решений стал Managed Kubernetes на выделенных серверах. В его основе — гибридная модель. Управляющий слой кластера, так называемый Control Plane или мастер-нода, работает в нашей отказоустойчивой облачной платформе. Рабочие ноды (воркер‑ноды), на которых исполняются приложения, — это физические выделенные серверы.

Такой гибридный подход дает несколько ключевых преимуществ, которые мы подробно раскроем дальше:

• непревзойденная производительность,

• высокий уровень безопасности за счет физической изоляции,

• глубокая интеграция в экосистему облачных сервисов.

Почему именно выделенные серверы для рабочих нод

Решение размещать рабочие нагрузки Kubernetes на выделенных серверах — не техническая особенность, а стратегический выбор. Давайте разберемся, какие задачи решает такой подход.

Производительность и предсказуемость

В стандартной облачной среде виртуальные машины работают на одном физическом хосте с другими клиентами. Такая совмещенность может приводить к ситуации, известной как «шумные соседи» (noisy neighbors) — на производительность начинает влиять высокая нагрузка чужих задач.

Выделенные серверы полностью исключают этот фактор. Все ресурсы — процессорные ядра, оперативная память, дисковый ввод-вывод — принадлежат только одному хозяину. Эксклюзивное владение гарантирует стабильную и предсказуемую производительность, что критически важно для приложений с постоянной высокой нагрузкой:высоконагруженных веб-сервисов, систем обработки данных в реальном времени или CI/CD‑раннеров. Одним словом — везде, где задержки недопустимы.

Безопасность и изоляция

Физическая изоляция ресурсов на выделенном сервере создает основу для безопасности. Отсутствие соседей по гипервизору значительно снижает вектор потенциальных атак и упрощает прохождение аудитов соответствия строгим отраслевым стандартам — например, в финансовом секторе или здравоохранении. Для компаний, которым требуется максимальный контроль над инфраструктурой, а также высокая степень безопасности, выделенные серверы — очевидный выбор.

Полный контроль над окружением

Выделенный сервер дает возможность управлять конфигурацией на более низком уровне, чем виртуальная машина. Хотя в рамках управляемого сервиса часть настроек абстрагирована, сама природа «железа» открывает двери для специфических оптимизаций, недоступных в облаке.

Как облако и «железо» работают вместе

Чтобы понять, как облачный Control Plane управляет физическими серверами, нужно взглянуть на архитектуру решения. Она элегантно объединяет два мира — гибкость облака и мощь «железа» — в единую, слаженно работающую систему.

В основе интеграции — глобальный роутер (L3VPN). Этот компонент создает единую приватную сеть, которая охватывает и облачную платформу, и выделенные серверы. Благодаря такой связности, для облачных сервисов выделенный сервер становится таким же «родным» участником сети, как и любая виртуальная машина — частью большой экосистемы облака.

Давайте разберем компоненты, показанные на схеме.

Control Plane находится в облачной платформе Selectel. Он включает в себя все стандартные компоненты Kubernetes.

• API Server — точка входа для всех команд.

• etcd — распределенное хранилище состояния кластера.

• controller-manager — управляет контроллерами.

• scheduler — распределяет поды по нодам.

Важнейший аспект — именно провайдер отвечает за доступность, обслуживание и масштабирование Control Plane.

Воркер-ноды — выделенные серверы. На них работает kubelet, который получает инструкции от Control Plane. Именно здесь запускаются контейнеры и поды пользователей.

Главное преимущество такой архитектуры — бесшовная интеграция. Приложения, работающие на выделенных серверах, могут нативно и безопасно взаимодействовать с другими облачными сервисами, например:

• управляемыми базами данных,

• реестрами контейнеров (Container Registry),

• облачными балансировщиками нагрузки,

• объектным хранилищем.

Все коммуникации проходят внутри приватной сети, без выхода в интернет, что повышает и скорость, и безопасность. Набор отдельных услуг трансформируется в целостную и мощную платформу.

Создаем кластер за 10 минут

Перейдем от теории к практике. Создание кластера Kubernetes на выделенных серверах в панели управления Selectel занимает около 10 минут и состоит всего из трех шагов. Сам процесс подготовки серверов может занять до часа, но настройка со стороны пользователя действительно быстрая.

Для начала зайдите в панель управления, выберите Облачные серверы, а затем пункт меню Kubernetes и нажмите кнопку Создать кластер.

Шаг 1. Настройка кластера

На первом шаге задаем основные параметры нового кластера. Придумываем понятное название кластера — например, demo-cluster. Указываем версию Kubernetes — рекомендуется выбирать последнюю стабильную, предлагаемую по умолчанию.

Тип кластера — здесь нужно сделать правильный выбор.

Отказоустойчивый — создается три мастер-ноды в разных зонах доступности облачной платформы. Если одна из зон выйдет из строя, Control Plane продолжит работать. Это стандарт при развертывании на проде.

Региональный (базовый) — создается одна мастер-нода. Такой вариант подходит для разработки и тестирования, но не обеспечивает высокой доступности управляющего слоя.

Далее выбираем регион и пул — географическое расположение кластера. Наконец, определяемся с досягаемостью. Если включить опцию Приватный Kube API, то API-сервер кластера будет доступен только из приватной сети Selectel, что значительно повышает безопасность.

Шаг 2. Конфигурация рабочих нод

Это самый интересный шаг, где мы выбираем «железо» для наших приложений.

1. Вверху формы переключитесь на вкладку Выделенный сервер.

2. Пул — выберите пул, в котором будут размещены серверы.

3. Конфигурация ноды — одна из списка готовых конфигураций выделенных серверов с указанием процессора, памяти, дисков и их количества, доступного для заказа. Тарификация: от дня до года — чем больше срок, тем больше скидка.

4. Количество нод — сколько серверов вы хотите добавить в группу. Для нашего воркшопа мы возьмем два — это позволит нам наглядно продемонстрировать работу DaemonSet, который следит за тем, чтобы на каждой из нод был запущен экземпляр пода.

5. Метки и Taints — настройки для более гибкого управления размещением подов.

6. Сеть — подключить ноды можно к уже существующей приватной подсети или создать новую, указав нужный диапазон адресов.

Шаг 3. Обслуживание и логирование

На последнем шаге задаем время обслуживания и настройки для аудит-логов.

• Время обслуживания — подходящий момент, когда система сможет проводить плановые работы — например, обновление кластера.

• Аудит-логи — сбор подробных логов о всех действиях, происходящих в API-сервере кластера.

После нажатия кнопки Создать кластер начнется процесс подготовки. Когда статус кластера и нод-группы изменится на Active, появится возможность kubeconfig-файл из контекстного меню — файл содержит все необходимое для подключения к новому кластеру с помощью утилиты kubectl.

Теперь, когда у нас есть работающий кластер, давайте что-нибудь на нем развернем!

Практический воркшоп: развертываем первое приложение

Для демонстрации работы с кластером мы выполним несколько классических задач, которые можно встретить во всех книгах по Kubernetes:

• развернем простое приложение с помощью DaemonSet;

• опубликуем его вовне через Ingress;

• убедимся, что все работает как надо.

Приложение и Docker-образ

Мы подготовили простое приложение на Go. Его задача — при обращении по корневому URL отдавать имя пода и имя ноды, на которой этот под запущен. Это поможет наглядно увидеть работу балансировщика нагрузки. Вот его код:

package main

import (
	"fmt"
	"log"
	"net/http"
	"os"
)

func main() {
	http.HandleFunc("/", helloHandler)
	fmt.Println("Server is running on port 8080")
	http.ListenAndServe(":8080", nil)
}

func helloHandler(w http.ResponseWriter, r *http.Request) {
	nodeName := os.Getenv("__NODE_NAME")
	fmt.Fprintf(w, "Hello from pod: %s, node: %s", getHostname(), nodeName)
}

func getHostname() string {
	nodeName, err := os.Hostname()
	if err!= nil {
		log.Fatal("can not get hostname")
	}
	return nodeName
}

Чтобы запустить это приложение в Kubernetes, его нужно упаковать в контейнер. Мы используем многостадийный Dockerfile, чтобы итоговый образ был минималистичным и безопасным:

FROM golang:1.21.5-bookworm AS builder

WORKDIR /build

COPY go.mod.
COPY main.go.

RUN CGO_ENABLED=0 GOOS=linux go build -o /main main.go

FROM alpine:3.18

ENV PORT=8080
EXPOSE $PORT

COPY --from=builder /main /bin/main

CMD ["/bin/main"]

Сборка и загрузка образа в Container Registry

Сначала соберем образ и загрузим его в заранее созданный нами реестр в сервисе Container Registry, который тесно интегрирован с нашей платформой:

docker build --platform="linux/amd64" -t cr.selcloud.ru/workshop/workshop
docker push cr.selcloud.ru/workshop/workshop

Интеграция реестра с кластером

Чтобы наш кластер Kubernetes мог скачивать приватные образы из реестра, их нужно интегрировать. В панели управления заходим на страницу нашего кластера.

В настройках находим кнопку Настроить интеграцию с Container Registry, выбираем нужный реестр из списка и нажимаем Интегрировать.

В кластере автоматически создадутся необходимые секреты и добавятся во все пространства имен.

Развертывание приложения с помощью DaemonSet

Теперь все готово к развертыванию. Мы будем использовать манифест, который описывает два объекта: DaemonSet и Service.

Выбор DaemonSet здесь не случаен. В отличие от Deployment, который просто создает заданное число реплик, DaemonSet гарантирует, что на каждой ноде кластера (или на нодах, соответствующих селектору) будет запущен ровно один экземпляр пода. Для нашей задачи идеально — приложение размещается на каждом из двух выделенных серверов.

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: go-api
  labels:
    app: go-api
spec:
  selector:
    matchLabels:
      app: go-api
  template:
    metadata:
      labels:
        app: go-api
    spec:
      containers:
        - name: go-api
          image: cr.selcloud.ru/workshop/workshop
          imagePullPolicy: Always
          ports:
            - containerPort: 8080
              name: http-web
          env:
            - name: __NODE_NAME
              valueFrom:
                fieldRef:
                  fieldPath: spec.nodeName
      nodeSelector:
        kubernetes.io/os: linux
---
apiVersion: v1
kind: Service
metadata:
  name: go-api
  labels:
    app: go-api
spec:
  ports:
    - name: http-service-port
      port: 80
      targetPort: http-web
      protocol: TCP
  selector:
    app: go-api

Обратите внимание на секцию env: мы используем valueFrom.fieldRef для того, чтобы передать имя ноды в переменную окружения __NODE_NAME внутри контейнера. Приложение затем читает эту переменную и отдает в ответе.

Применим манифест к нашему кластеру:

kubectl --kubeconfig=kubeconfig.yaml apply -f 1-deploy.yaml

Проверим, что поды создались и работают:

kubectl --kubeconfig=kubeconfig.yaml get po
# NAME           READY   STATUS    RESTARTS   AGE
# go-api-abcde   1/1     Running   0          30s
# go-api-fghij   1/1     Running   0          30s
kubectl logs <pod-name>

Мы должны увидеть два пода в статусе Running. Чтобы убедиться, что образ был скачан именно из нашего приватного реестра, можно выполнить команду describe:

kubectl --kubeconfig=kubeconfig.yaml describe pod <pod-name>

В выводе в секции Events должна быть строка Successfully pulled image «cr.selcloud.ru/workshop/workshop».

Публикация сервиса с помощью Ingress

Наше приложение работает, но доступно только внутри кластера. Чтобы открыть к нему путь из внешнего мира, воспользуемся Ingress-контроллером — например, популярным ingress-nginx. Он будет принимать внешний трафик и маршрутизировать его на наш сервис.

Сначала добавим репозиторий Helm и установим контроллер, следуя инструкции из документации Selectel: 

KUBECONFIG=kubeconfig.yaml helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
KUBECONFIG=kubeconfig.yaml helm install ingress-nginx ingress-nginx/ingress-nginx --generate-name

После установки контроллера в кластере будет автоматически создан облачный балансировщик нагрузки, который получит публичный IP-адрес и будет направлять трафик на поды Ingress-контроллера.

Теперь создадим сам объект Ingress, который определит правила маршрутизации: 

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: minimal-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: "nginx"
  rules:
    - http:
        paths:
          - path: /path
            pathType: Prefix
            backend:
              service:
                name: go-api
                port:
                  number: 80

Этот манифест говорит: «Весь трафик, приходящий на публичный IP‑балансировщика по пути /path, перенаправлять к сервису go-api на порт 80». Аннотация rewrite-target: / убирает /path из запроса перед отправкой в сервис.

Применим манифест:

kubectl --kubeconfig=kubeconfig.yaml apply -f 2-ingress.yaml

Теперь нужно дождаться, пока облачный балансировщик получит внешний IP-адрес. Это можно отследить командой: 

kubectl --kubeconfig=kubeconfig.yaml get svc -w

Ищем сервис  …-ingress-nginx-controller… и ждем появления IP в колонке EXTERNAL-IP. Как только IP-адрес появится, можно делать запрос (<IP> нужно заменить на получившийся адрес):

curl http://<IP>:80/path

В ответ мы должны получить:

Hello from pod: go-api-abcde, node: <имя-первой-ноды>

Если выполнить команду несколько раз, ответ будет приходить то с одного пода, то с другого, демонстрируя работу балансировки нагрузки между нашими выделенными серверами.

Итак. Мы успешно развернули приложение в гибридном кластере и опубликовали его в интернете, интегрировав несколько сервисов Selectel.

Интеграция с облачными базами данных: соединяем лучшее из двух миров

Одно из главных преимуществ гибридной архитектуры — возможность легко соединять высокопроизводительные вычисления на «железе» с надежными управляемыми сервисами в облаке. Сейчас мы продемонстрируем это, подключив к нашему кластеру облачную базу данных PostgreSQL.

Такой подход позволяет снять с себя заботы об администрировании, резервном копировании и отказоустойчивости СУБД, доверив их провайдеру — и в то же время запускать основное приложение на полностью выделенных ресурсах.

Создание и настройка базы данных

Перейдем в панели управления в раздел Базы данных и создадим новый кластер СУБД.

СУБД — выберем PostgreSQL последней версии. Регион — укажем тот же регион, где находится наш Kubernetes-кластер.

Сеть — это ключевой шаг. В настройках выберем ту же приватную сеть, к которой подключены наши выделенные серверы — это обеспечит прямую и безопасную связность.

Остальные параметры для демонстрации оставим по умолчанию и нажмем Создать кластер. После создания кластера БД, что займет 5-10 минут, нужно выполнить еще два действия.

На вкладке Пользователи создать нового пользователя — например, workshop — и обязательно сохранить сгенерированный пароль.

На вкладке Базы данных создать новый экземпляр БД — например, work — и назначить созданного пользователя его владельцем.

На вкладке Подключение мы найдем внутренний IP‑адрес нашего кластера баз данных. Запомним его.

Подключение из пода Kubernetes

Теперь вернемся в наш кластер Kubernetes. Чтобы проверить связность, создадим простой под, который с помощью клиента psql подключится к базе и выполнит запрос SELECT version(): 

psql -h 10.20.0.64 -p 5432 -U workshop -d work -c SELECT version()

Важное замечание по безопасности

В демонстрационном манифесте ниже пароль передается через переменную окружения в открытом виде. Так никогда не нельзя делать в продакшене! Правильный и безопасный способ — использовать Kubernetes Secrets. Мы покажем оба варианта.

Пример для демонстрации — небезопасный:

apiVersion: v1
kind: Pod
metadata:
  name: psql
spec:
  containers:
    - name: psql
      image: postgres
      imagePullPolicy: IfNotPresent
      env:
        - name: PGPASSWORD
          value: "<пароль>"
      command:
        [
          "psql",
          "-h",
          "10.20.0.64",
          "-p",
          "5432",
          "-U",
          "workshop",
          "-d",
          "work",
          "-c",
          "SELECT version()",
        ]

  restartPolicy: Never

Сделаем то же самое, но безопасно. Сначала создадим секрет Kubernetes, который будет хранить пароль. Затем файл db-secret.yaml: 

apiVersion: v1
kind: Secret
metadata:
  name: db-credentials
type: Opaque
stringData:
  password: "<пароль>" # Вставьте сюда ваш пароль

Применим его: 

kubectl apply -f db-secret.yaml

Теперь модифицируем манифест пода, чтобы он брал пароль из секрета, а не из открытого текста: 

apiVersion: v1
kind: Pod
metadata:
  name: psql
spec:
  containers:
    - name: psql
      image: postgres
      imagePullPolicy: IfNotPresent
      env:
        - name: PGPASSWORD
          valueFrom:
            secretKeyRef:
              name: db-credentials
              key: password
      command:
        [
          "psql",
          "-h",
          "10.20.0.64",
          "-p",
          "5432",
          "-U",
          "workshop",
          "-d",
          "work",
          "-c",
          "SELECT version()",
        ]
       
  restartPolicy: Never

Такой подход — стандарт для работы с чувствительными данными в Kubernetes.

Проверка подключения

Применим наш (безопасный) манифест и посмотрим логи пода:

kubectl --kubeconfig=kubeconfig.yaml apply -f 3-db-pod.yaml
# Дожидаемся, пока под выполнится (статус Completed)
kubectl --kubeconfig=kubeconfig.yaml logs psql

В выводе мы должны увидеть версию нашего PostgreSQL, что подтверждает успешное подключение:

PostgreSQL 16.2 (Ubuntu 16.2-1.pgdg22.04+1) on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0, 64-bit
(1 row)

Этот пример наглядно показал мощь гибридной модели: мы разместили каждое приложение на той инфраструктуре, которая подходит для него лучше всего, а затем легко соединили их благодаря единой приватной сети.

Управление и эксплуатация кластера на выделенных серверах

Создание кластера — только начало. Для успешной работы в продакшене важно понимать, как управлять кластером, масштабировать его, обеспечивать отказоустойчивость и безопасность.

Модель PaaS и масштабирование

Сервис работает по модели Platform as a Service (PaaS). Это значит, что Selectel берет на себя всю ответственность за доступность, обновление и обслуживание мастер-нод. Если нагрузка на Control Plane возрастает, наши инженеры самостоятельно его масштабируют без увеличения стоимости для клиента.

Масштабирование рабочих нод (воркеров) на выделенных серверах пока происходит вручную. Если потребуется больше ресурсов, можете добавить в кластер новую группу нод с серверами требуемой конфигурации. Автомасштабирование для выделенных серверов — функциональность, которую мы рассматриваем на будущее.

Отказоустойчивость и обновления

Отказоустойчивость приложений обеспечивается встроенными механизмами самого Kubernetes — такими, как репликация, health checks. Для повышения надежности самого кластера рекомендуется выбирать тип с тремя мастер-нодами. Кроме того, в настройках можно включить опцию автоматического восстановления рабочих нод: если сервер станет недоступен, система сама попытается развернуть на замену новый.

Обновление минорных версий Kubernetes запускается пользователем из панели управления, а сам процесс происходит автоматически. Важно помнить, что во время обновления рабочие ноды будут поочередно перезагружаться, поэтому приложения должны проектироваться так, чтобы выдерживать перезапуск подов.

Хранилища (Storage) на выделенных серверах

Работа с персистентными данными на выделенных серверах имеет свои особенности. В отличие от облака, где можно в один клик создать сетевой диск, здесь мы имеем дело с локальными дисками сервера. Рассмотрим основные варианты.

К таблице добавлю несколько разъяснений.

hostPath — прямой монтаж директории с хостовой машины в под. Просто, но рискованно, так как под получает доступ к файловой системе ноды, что может быть небезопасно. Использовать можно, но с осторожностью — в основном для служебных задач.

Local Persistent Volumes (LPV) — это Kubernetes-нативный способ работы с локальными дисками. Он позволяет объявить локальный диск как PersistentVolume. Главное преимущество — планировщик Kubernetes становится «осведомлен» о местонахождении данных и будет всегда запускать под, запрашивающий этот том, именно на той ноде, где находится сам диск.

В облачном хранилище благодаря гибридной архитектуре поды на выделенных серверах могут без проблем использовать персистентные тома́ из облачной платформы Selectel. Это лучший выбор для данных, требующих высокой доступности, так как сетевой диск не привязан к конкретному физическому серверу.

Безопасность в гибридной среде

Безопасность — процесс многоуровневый. Рассмотрим два ключевых аспекта в Kubernetes: сетевые политики и управление доступом.

По умолчанию в Kubernetes все поды могут свободно общаться друг с другом внутри кластера. Это удобно для старта, но небезопасно для продакшена.

NetworkPolicy — своего рода файрвол на уровне подов. Лучшая практика — начать с политики «запрещено все по умолчанию» (default deny), а затем точечно разрешать необходимые коммуникации.

Пример. Ниже — политика, которая разрешает входящий трафик на наши go-api‑поды только от подов с меткой role: frontend:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: go-api-ingress-policy
spec:
  podSelector:
    matchLabels:
      app: go-api
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              role: frontend
      ports:
        - protocol: TCP
          port: 8080

Такой подход реализует принцип Zero Trust и значительно повышает безопасность приложения.

RBAC — это механизм, который определяет, кто и какие действия может выполнять в кластере. Основополагающий принцип здесь — наименьших привилегий (Principle of Least Privilege). Не давайте пользователям или сервисным аккаунтам больше прав, чем им абсолютно необходимо для выполнения их задач.

Основные объекты RBAC

• Role / ClusterRole — описывают набор разрешений (что можно делать: get, list, create; с какими ресурсами: pods, secrets). Role действует в рамках одного namespace, ClusterRole — во всем кластере.

• RoleBinding / ClusterRoleBinding — связывают Role или ClusterRole с субъектом — пользователем, группой или ServiceAccount.

Никогда не используйте учетную запись cluster-admin для повседневной работы и не раздавайте права с использованием wildcard (*), так как это дает доступ ко всем ресурсам, включая те, что появятся в будущем.

Продвинутые сценарии и будущие возможности

Платформа постоянно развивается. Давайте рассмотрим пару продвинутых тем и заглянем в будущее.

Проброс внешних ресурсов

На вебинаре был задан вопрос про безопасное подключение к внешнему ClickHouse. Подход здесь многогранный.

Для HTTP-интерфейса можно использовать Ingress с TLS-сертификатом для шифрования трафика (HTTPS).

Для нативного клиента необходимо настроить SSL-соединение на стороне самого ClickHouse и клиента. Также можно использовать специализированные Kubernetes-операторы, которые автоматизируют настройку.

K8s vs. K3s: что выбрать

Иногда в обсуждениях всплывает K3s, и важно понимать его отличия от «большого» Kubernetes (K8s).

K3s — официальная, но легковесная дистрибуция Kubernetes от Rancher/SUSE. Она упакована в один бинарный файл размером менее 100 MB и оптимизирована для работы в средах с ограниченными ресурсами — таких как IoT, Edge-устройства или локальные машины для разработки.

Ключевое техническое отличие — в хранилище состояния. Стандартный K8s использует etcd — распределенную, отказоустойчивую базу данных ключ-значение, созданную для построения высокодоступных систем. K3s по умолчанию заменяет etcd на встроенную базу данных SQLite.

Учитывая эти особенности, последствия этого выбора можно описать кратко.

SQLite делает K3s невероятно простым в установке и очень нетребовательным к ресурсам. Это его главный плюс.

Приходится идти на компромисс с отказоустойчивостью. Кластер K3s с SQLite по умолчанию не имеет высокой доступности управляющего слоя (Control Plane). Если единственная мастер-нода выйдет из строя, кластер перестанет управляться. «Большой» K8s с кластером из нескольких etcd-нод — это промышленный стандарт для построения отказоустойчивых производственных систем.

Выводы

K3s — превосходный легковесный инструмент для разработки, тестирования и некритичных Edge-сценариев.

K8s — это мощное решение для крупномасштабных, критически важных производственных нагрузок, где требуется максимальная надежность.

Сервис Managed Kubernetes построен на базе полноценного K8s, чтобы обеспечить именно этот уровень надежности.

Оптимизация затрат и специальные предложения

Управление затратами — важная часть эксплуатации любой инфраструктуры. Наш сервис на выделенных серверах предлагает несколько возможностей для оптимизации.

Доступны различные периоды оплаты — от одного дня до года. Выбирая более длительный срок аренды, вы получаете значительную скидку. Например, при оплате за год скидка может составлять 15%.

Бесплатная миграция — мы можем начислить до 1 000 000 бонусов на ваш счет. Для участия в акции нужно зарегистрироваться и написать тикет в поддержку. Наши специалисты помогут составить план переезда.

Мы предоставляем гранты на тестирование Managed Kubernetes и других облачных сервисов. Это отличная возможность попробовать наши продукты. Все, что требуется для получения гранта — обратиться в поддержку через тикет-систему.

Заключение

Мы прошли большой путь: от понимания гибридной архитектуры до развертывания реального приложения и его интеграции с базой данных.

Managed Kubernetes на выделенных серверах объединяет производительность и безопасность физически изолированных ресурсов для любых рабочих нагрузок и одновременно удобство и надежность управляемого Control Plane в облаке.

Глубокая интеграция в экосистему через единую приватную сеть позволяет бесшовно использовать весь спектр облачных сервисов, строя по-настоящему гибкие и эффективные архитектуры.

Выбор надежного провайдера IT-инфраструктуры — это выбор партнера, который обладает опытом, развитой экосистемой продуктов и готов помочь на каждом этапе.

Призываем вас попробовать сервис в деле. Разверните свой первый кластер, протестируйте свои приложения и задавайте вопросы нашей поддержке. Уверены, вы оцените мощь и гибкость этого решения.

Запись митапа