split large configuration file

[adou0510]

we have more than 10000+ site ,the nginx.conf so big about 500M

[wangyysde]

/cc @wangyysde

[longwuyuan]

/kind feature
/remove-kind bug

[AmazingTurtle]

maybe relates to #7232

[rikatz]

This seems a good approach, but will need some effort to implement.

If someone wants to tackle on this one after we merge the support for v1 API in ingress nginx I would be glad to review it :)

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[rikatz]

/remove-lifecycle stale
Still want to look into this

[tao12345666333]

I have done some thinking, but in this project, if we split the configuration file, what will be the benefit?

[tao12345666333]

In the context of this project, the user is modifying and maintaining Ingress resources, not directly on the configuration file. I haven't thought of the benefits it can bring. cc @rikatz

[agile6v]

Hi @tao12345666333 if I understand it correctly splitting configuration file can reduce the memory consumption. Because the current strategy is to render the whole configuration file, so if there are many ingress resources, the configuration will be very large and frequent changes can cause excessive consumption. Thanks.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[rikatz]

/lifecycle frozen

[rikatz]

/assign

[iamNoah1]

/triage accepted
/priority backlog

[wangyysde]

@rikatz Are you preparing a PR for this? I try to do it if you are not work for it.

[rikatz]

@wangyysde if you can work on it, I will be happy to review :) right now I'm not working on it

[wangyysde]

@rikatz ok ,then I will try to work on it.

[wangyysde]

/assign

[pmint93]

Sharding is a better approach, it also address the issue with reload becoming costly. The term "sharding" I means, there are multiple instances of Ingress Controller, each manage a subset of Ingress resources and so it have smaller configuration files, faster reload, and perhaps reduce overall memory consumption ...

But the challenge is: how to dynamically route requests to relevant instances, perhaps we need another level of dynamic routing.

[gewuang]

I'm experiencing the same problem, please ask if this issue is being looked at and if there will be any subsequent updates