Как настроить приложения и инфраструктуру с использованием Kubernetes

Вопрос или проблема

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

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

  1. У меня есть одно приложение Symfony, предоставляющее пользовательский интерфейс, которое доступно для внешнего мира. Оно вызывает несколько других проектов Symfony с помощью API-запросов; эти API-сервисы имеют подключение к общим экземплярам MySQL в фоновом режиме. Каждое приложение — это отдельный проект на GitHub.

  2. В разработке я запускаю все приложения вместе с контейнерами для базы данных и почтовой системы и использую разные порты на машине для доступа к каждому из API-сервисов.

  3. Каждое из приложений в некоторой степени автономно, так как им нужен процесс php-fpm и загрузка их зависимостей Composer и не много другого.

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

  5. Я действительно хочу, чтобы API-приложения были невидимы для внешнего мира и видели их только в внутренней сети.

  6. В каждом случае как я могу сделать базы данных (2 из них) доступными только для внутренней сети.

  7. У меня есть кластер RPI, настроенный как эксперимент с k3S, helm, ArgoCD, но я не могу разобраться в лучшей архитектуре для продвижения эксперимента вперед.

В данный момент работает следующим образом.

  1. Процесс веб-приложения работает на Apache/nginx и php-fpm (приложение UI), доступное для внешнего мира
  2. API-процессы работают как виртуальные хосты на Apache на портах 8000, 8001, слушают только внутреннюю сеть
  3. Docker-compose.yml с контейнерами, которые создают базу данных MYSQL и почтовый сервер (в данный момент — почтовый ловец), порты 3306 и 25 открыты для доступа приложений Symfony.

Мысли?

Ответ или решение

Настройка приложений и инфраструктуры в Kubernetes

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

1. Архитектура приложения

Так как у вас имеется разделение между пользовательским интерфейсом, серверной логикой API и базами данных, необходимо создать четкую структуру для приложений и их ресурсов в Kubernetes.

  1. Содержимое приложения:
    • Symfony UI приложение — будет доступно внешнему миру.
    • API службы — внутренние сервисы, которые будут общаться с UI через API вызовы.
    • Базы данных — доступны только из API служб.

2. Создание пространства имен

Рекомендуется создать разные пространства имен (namespaces) для вашего UI приложения, API служб и баз данных. Это поможет вам разделить ресурсы и упростит управление. Например:

  • ui-apps
  • api-services
  • databases

3. Моделирование приложений в Kubernetes

3.1. Создание Deployment для вашего UI приложения

Настройте Deployment для вашего Symfony UI приложения с использованием nginx и php-fpm. Определите Service, который будет использоваться для балансировки нагрузки.

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

apiVersion: apps/v1
kind: Deployment
metadata:
  name: symfony-ui
  namespace: ui-apps
spec:
  replicas: 2
  selector:
    matchLabels:
      app: symfony-ui
  template:
    metadata:
      labels:
        app: symfony-ui
    spec:
      containers:
      - name: symfony-ui
        image: your-docker-image
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: symfony-ui-service
  namespace: ui-apps
spec:
  type: LoadBalancer
  ports:
  - port: 80
    targetPort: 80
  selector:
    app: symfony-ui

3.2. API службы

Каждая API служба также должна быть настроена с использованием Deployment и соответствующих Service. Однако, следует использовать ClusterIP в качестве типа сервиса, чтобы сделать их доступными только внутри кластера.

Пример:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-service
  namespace: api-services
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api-service
  template:
    metadata:
      labels:
        app: api-service
    spec:
      containers:
      - name: api-service
        image: your-api-docker-image
        ports:
        - containerPort: 8000
---
apiVersion: v1
kind: Service
metadata:
  name: api-service
  namespace: api-services
spec:
  type: ClusterIP
  ports:
  - port: 8000
    targetPort: 8000
  selector:
    app: api-service

4. Настройка баз данных

Настройте StatefulSet для каждой из ваших баз данных и используйте ClusterIP, чтобы они были доступны только внутренним службам.

Пример манифеста для MySQL:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql-db
  namespace: databases
spec:
  serviceName: mysql
  replicas: 1
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - name: mysql
        image: mysql:5.7
        env:
        - name: MYSQL_ROOT_PASSWORD
          value: your_password
        ports:
        - containerPort: 3306
---
apiVersion: v1
kind: Service
metadata:
  name: mysql
  namespace: databases
spec:
  type: ClusterIP
  ports:
  - port: 3306
    targetPort: 3306
  selector:
    app: mysql

5. Сетевые настройки

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

6. Использование Helm и ArgoCD

Для управления ресурсами в Kubernetes вы можете использовать Helm для упаковки ваших приложений в чарты и ArgoCD для управления развертыванием. Это поможет вам более эффективно управлять версиями и конфигурациями.

Заключение

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

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

Оцените материал
Добавить комментарий

Капча загружается...