The rate limit that you're reaching here (for duplicate certificates) is not one that Let's Encrypt typically grants an increase for; in fact, I'm not sure whether software tools have even been created to allow that on the certificate authority side.
The people operating the certificate authority would probably prefer for you to pursue a different issuance strategy whereby the names in the certificates are not exact duplicates. Also, if the devices to which these certificates are issued are directly controlled by the customers, that may not be appropriate because the customers could use the certificates to impersonate one another's sites. If the devices are controlled by you rather than by the customers, you might be able to re-use the same certificate on multiple servers or devices.
There is a rate limit increase form that you can fill out to describe your situation
but, again, I think the most likely response would be that the certificates per registered domain limit can be increased when you are hosting many separate customers or entities' sites under a single registered domain, while the duplicate certificate rate limit (for certificates issued during the same week that cover exactly the same set of names) cannot be increased.
@schoen the consumers are not end users. It's our developers.
We are making a clone of our production with selected services in a new K8S namespace.
This feature is now more widely used. If we request certificate to a specific domain (rather than a wildcard), would that solve our issue?
What do you mean by different issuance strategy? What other issuance strategies can be suited to our use case?
If the instances are all under your control, you could copy a single wildcard certificate between them. A single certificate can be used by multiple devices or services, as long as they're accessed under names that are matched by that certificate.
If that doesn't seem practical or doesn't appeal to you, then:
It would probably be an improvement from the Let's Encrypt rate limit point of view. First, a different rate limit would apply compared to the one that you're currently reaching. The other rate limit that would apply is much more lenient than the one you're being limited by, permitting a much greater volume of certificate issuance. Second, if you do eventually need to request a rate limit increase anyway, it would be easier for Let's Encrypt to approve that request within its existing policy and technical framework if the certificates are getting issued for individual subdomains used for distinct customers' services.
K8S is Kubernates. Namespaces are used for partitioning of resources.
No one here has access to LetsEncrypt's infrastructure. You need to share detailed info about your errors.
The proper solution for your situation is to recycle/share your certificates. Your scaling/deployment strategy for Certificates exhibits a common anti-pattern. Common fixes include, but are not limited to:
Store certificates in the cloud; read on startup/cron
Store certificates on a shared volume; read on startup/cron
Have one node responsible for Certificates, and other nodes pull/copy the certs on startup/cron
Have one node responsible for Certificates, and push to nodes on new procurement