Соединение внешнего модуля с внутренним модулем
Создайте службу для своего развертывания и укажите в приложении свое имя службы. Ключом к подключению внешнего интерфейса к бэкенду является внутренняя служба. Служба создает постоянный IP-адрес и запись имени DNS, чтобы всегда можно было получить доступ к внутреннему микросервису. Служба использует селекторы для поиска модулей, которым она маршрутизирует трафик c.
Сначала настройте службу MySQL как службу ClusterIP. Он будет закрытым, видимым только для других сервисов. Это можно сделать, удалив строку с параметром type.
apiVersion: v1
kind: Service
metadata:
name: app-api-mysql-svc
spec:
selector:
app: app-api-mysql
ports:
- protocol: TCP
port: 80
targetPort: [the port exposed by the mysql pod]
Теперь, когда у вас есть бэкэнд, вы можете создать веб-интерфейс, который подключается к бэкэнду. Интерфейс подключается к рабочим модулям бэкэнда, используя DNS-имя, присвоенное бэкэнд-службе. DNS-именем является « app-api- mysql -sv c», которое является значением поля name в предыдущем файле конфигурации службы.
apiVersion: v1
kind: Service
metadata:
name: frontend
spec:
selector:
app: app-api-mysql
ports:
- protocol: "TCP"
port: 80
targetPort: 80
type: LoadBalancer
Как и в бэкэнде, у внешнего интерфейса тоже есть сервис. Конфигурация для Сервиса имеет type: LoadBalancer, что означает, что Сервис использует балансировщик нагрузки по умолчанию вашего облачного провайдера.
Вы также можете proxy все ваши внутренние вызовы через ваш интерфейсный сервер
Если вы маршрутизируете (или хотите маршрутизировать) все ваши микросервисные / серверные вызовы через серверную часть внешнего интерфейса, и если вы развертываете как внешний интерфейс, так и внутренний интерфейс в одном и том же кластере k8s в одном и том же пространстве имен, затем вы можете использовать надстройку KubeDNS (если она еще не доступна в вашем кластере k8s, вы можете проверить с администратором k8s), чтобы разрешить имя бэкэнд-сервиса в его IP. С вашего внешнего сервера ваш бэкэнд-сервис всегда будет разрешаться по его имени.
Поскольку у вас есть kubeDNS в вашем кластере k8s, а и внешние, и внутренние сервисы находятся в одном и том же кластере k8s и В том же пространстве имен мы можем использовать встроенный механизм обнаружения сервисов k8s. Бэкэнд-сервис и фронтенд-сервис будут обнаруживаться друг у друга по имени. Это означает, что вы можете просто использовать DNS-имя «backend», чтобы получить доступ к своей серверной службе из вашего внешнего интерфейса pods . Так что, просто перенаправьте весь запрос бэкэнда через ваш интерфейс nginx в бэкэнд-сервис верхнего уровня. В веб-интерфейсе nginx pods IP-адрес серверной службы будет разрешаться для доменного имени "backend". Это избавит вас от головной боли CORS тоже. Эта установка является переносимой, то есть не имеет значения, развертываете ли вы в dev, stage или prod, имя «backend» всегда будет соответствовать соответствующему backend.
Более подробную информацию вы можете найти здесь: backend-frontend , frontend-backend-pod-connection .
Для подключения постоянного тома к модулю
MySQL требуется PersistentVolume для хранения данных. Их PersistentVolumeClaims будут созданы на этапе развертывания.
Во многих кластерных средах установлен класс StorageClass по умолчанию. Когда StorageClass не указан в PersistentVolumeClaim, вместо него используется кластерный StorageClass по умолчанию.
Когда создается PersistentVolumeClaim , PersistentVolume динамически предоставляется на основе StorageClass конфигурация.
Здесь вы можете найти подробное руководство по настройке модуля MySQL с постоянным объемом: pv- mysql -wordpress .