What's the relationship between this project and KIC?

[spacewander]

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?

[pmalek]

Hi @spacewander 👋

KGO allows users to deploy and manage Kong (DataPlane) and KIC (ControlPlane) instances or use the Gateway to deploy and manage those 2.

KIC reconciles all the Gateway API (and Ingress) resources in a non managed way (https://docs.konghq.com/kubernetes-ingress-controller/latest/gateway-api/#gatewayclass--gateway) which basically requires users to manage Kong instances themselves.

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).