You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Both this project and kubernetes-ingress-controller reconcile Gateway API like Gateway & HTTPRoute. And even more, this project has a plan to distribute plugins: #371. If people use KGO to distribute plugins, maybe the next step is to configure plugins with KGO... Otherwise, it's confusing that people need to use another controller to configure plugins.
So I have two questions:
What's the relationship or boundary between this project and KIC?
Why not implement the deployment feature inside the KIC?
The text was updated successfully, but these errors were encountered:
KIC currently is the only component that reconciles the "configuration" aspect of Kong, meaning it reconciles, Services, Ingresses but also Gateway API HTTPRoutes, GRPCRoutes, TLSRoutes etc.
You can think of these 2 projects as:
KGO can be used to deploy and manage KIC and Kong (think: an alternative to Helm)
KIC is used to configure Kong
Plugin distribution is being implemented in KGO because KIC does not have (and does not plan to have) any management capabilities: it does not spawn or tear down resources. It "only" creates Kong configuration and applies it to Kong instance(s).
Kong
locked and limited conversation to collaborators
Jul 23, 2024
Both this project and kubernetes-ingress-controller reconcile Gateway API like Gateway & HTTPRoute. And even more, this project has a plan to distribute plugins: #371. If people use KGO to distribute plugins, maybe the next step is to configure plugins with KGO... Otherwise, it's confusing that people need to use another controller to configure plugins.
So I have two questions:
The text was updated successfully, but these errors were encountered: