У меня есть два KONG экземпляра в кластере k8s с соответствующей базой данных
- Экземпляр песочницы Kong назван
kong-ingress-controller, и его конфигурация следующая:
- А также у меня есть производственный экземпляр Kong , который называется
kong-ingress-controller-production, и его конфигурация такова:
Даже в этой схеме конфигурации я могу развернуть оба kongs (песочница и производственные экземпляры) в одном и том же порту, я имею в виду 8001, потому что каждый kong расположен на отдельной машине pod.
В экземпляре песочницы kong я создал следующие ресурсы kong:
basic-auth и acl KongPlugins
2 KongConsumer ресурсов с соответствующими KongCredentials
А также я настроил параметр - --ingress-class=kong в песочнице kong, и у меня есть ресурс Ingress, указывающий на него
В среде песочницы kong все ранее упомянутые ресурсы создаются и хранятся в его базе данных kong.
Не так в производственной среде Гонконга. Посмотрим ...
Я также создаю в производственной среде kong следующее:
basic-auth и acl KongPlugins
1 KongConsumer ресурс с соответствующими KongCredential
А также я настроил параметр - --ingress-class=kong-production в производстве в Конге, и у меня есть ресурс Ingress, указывающий на него
Что происходит?
Мои две песочницы и производственные экземпляры работают и работают, но
База данных среды песочницы kong берет на себя создание и хранение KongConsumers и KongCredentials.
Эти ресурсы не сохраняются в производственной базе данных kong, учетные данные, потребители, плагины basic-auth и ACL хранятся в базе данных песочницы ...
В производственной базе данных kong хранится только KongPlugins.
Ситуация выглядит так, как будто в какой-то момент были пересечены различные соединения kong, или, по крайней мере, среда песочницы kong прослушивает и передает запрос в рабочую среду kong.
Проверка или доказательство того, что я говорю, заключается в том, что даже среда контроллера производства Kong игнорирует создание Kongconsumer и его KongCredential. Вот записи по этому утверждению
I0509 14:23:21.759720 6 kong.go:113] syncing global plugins
I0509 14:29:57.353944 6 store.go:371] ingress rule without annotations
I0509 14:29:57.353963 6 store.go:373] ignoring add event for plugin swaggerapi-production-basic-auth based on annotation kubernetes.io/ingress.class with value
I0509 14:29:57.395732 6 store.go:371] ingress rule without annotations
I0509 14:29:57.395756 6 store.go:373] ignoring add event for plugin swaggerapi-production-acl based on annotation kubernetes.io/ingress.class with value
I0509 14:29:57.438604 6 store.go:439] ignoring add event for consumer zcrm365dev-consumer based on annotation kubernetes.io/ingress.class with value
I0509 14:29:57.487996 6 store.go:505] ignoring add event for credential zcrm365dev-credential based on annotation kubernetes.io/ingress.class with value
I0509 14:29:57.529698 6 store.go:505] ignoring add event for credential zcrm365-prod-acl-credential based on annotation kubernetes.io/ingress.class with value
Это странно, потому что я указываю в каждом развертывании Kong параметр --ingress-class, и у каждого есть определенное значение следующим образом:
- Конг производственная среда ->
- --ingress-class=kong-production
- среда песочницы в Конге ->
- --ingress-class=kong
А также в каждом Ingress ресурсе, который указывает на каждый конкретный класс конга, используя аннотацию kubernetes.io/ingress.class следующим образом:
Вход, указывающий на песочницу в Конге ---> kubernetes.io/ingress.class: "kong"
Вход, указывающий на производство в Конге ---> kubernetes.io/ingress.class: "kong-production"
Кто-то знает, что здесь происходит?
Как мне перенаправить или хотя бы выполнить отладку этого поведения?
Я проверял журналы и операцию переадресации портов, чтобы подтвердить доступность обоих экземпляров kong, а также того, что ни один из них не побеждает другой, как мы можем видеть на этом рисунке:
