- Вопрос или проблема
- Ответ или решение
- Настройка приложений и инфраструктуры в Kubernetes
- 1. Архитектура приложения
- 2. Создание пространства имен
- 3. Моделирование приложений в Kubernetes
- 3.1. Создание Deployment для вашего UI приложения
- 3.2. API службы
- 4. Настройка баз данных
- 5. Сетевые настройки
- 6. Использование Helm и ArgoCD
- Заключение
Вопрос или проблема
В данный момент я пытаюсь разобраться в лучшем способе настройки комбинации услуг и приложений на Kubernetes. Идеально использовать Ansible, но это не цель вопроса. Вопрос больше касается того, как лучше разделить проблему.
Архитектура приложения такова, что существует разделение пользовательского интерфейса от кода доступа к базе данных и от основных услуг. Например:
-
У меня есть одно приложение Symfony, предоставляющее пользовательский интерфейс, которое доступно для внешнего мира. Оно вызывает несколько других проектов Symfony с помощью API-запросов; эти API-сервисы имеют подключение к общим экземплярам MySQL в фоновом режиме. Каждое приложение — это отдельный проект на GitHub.
-
В разработке я запускаю все приложения вместе с контейнерами для базы данных и почтовой системы и использую разные порты на машине для доступа к каждому из API-сервисов.
-
Каждое из приложений в некоторой степени автономно, так как им нужен процесс php-fpm и загрузка их зависимостей Composer и не много другого.
-
Я хочу иметь возможность масштабировать приложение, но не уверен, как его разделить. Создаю ли я контейнер со всеми службами, а затем имею несколько экземпляров за балансировщиком нагрузки, или у меня есть балансировщик нагрузки для каждого приложения, а каждый контейнер — это одно приложение, которое я могу масштабировать индивидуально.
-
Я действительно хочу, чтобы API-приложения были невидимы для внешнего мира и видели их только в внутренней сети.
-
В каждом случае как я могу сделать базы данных (2 из них) доступными только для внутренней сети.
-
У меня есть кластер RPI, настроенный как эксперимент с k3S, helm, ArgoCD, но я не могу разобраться в лучшей архитектуре для продвижения эксперимента вперед.
В данный момент работает следующим образом.
- Процесс веб-приложения работает на Apache/nginx и php-fpm (приложение UI), доступное для внешнего мира
- API-процессы работают как виртуальные хосты на Apache на портах 8000, 8001, слушают только внутреннюю сеть
- Docker-compose.yml с контейнерами, которые создают базу данных MYSQL и почтовый сервер (в данный момент — почтовый ловец), порты 3306 и 25 открыты для доступа приложений Symfony.
Мысли?
Ответ или решение
Настройка приложений и инфраструктуры в Kubernetes
Создание инфраструктуры приложений на основе Kubernetes может оказаться задачей с множеством переменных. Основываясь на предоставленной информации о вашей архитектуре с использованием Symfony, API и баз данных, я постараюсь представить наиболее эффективный способ организации вашего кластера.
1. Архитектура приложения
Так как у вас имеется разделение между пользовательским интерфейсом, серверной логикой API и базами данных, необходимо создать четкую структуру для приложений и их ресурсов в Kubernetes.
- Содержимое приложения:
- 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 в своих проектах.