I generate certificates using LetsEncrypt for each domain that points their CNAME/A-Record to my IP/Domain. Secrets are then generated from them specified in the "tls" section of my ingress config.
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: great-site
namespace: production
annotations:
kubernetes.io/ingress.allow-http: 'true'
kubernetes.io/ingress.global-static-ip-name: 'great-site-production'
spec:
tls:
- secretName: domain.one-2019-09-10
- secretName: domain.two-2019-09-10
- secretName: domain.three-2019-09-10
- secretName: domain.four-2019-09-10
- secretName: domain.five-2019-09-10
- secretName: domain.six-2019-09-11
- secretName: domain.seven-2019-10-19
- secretName: domain.eight-2019-10-19
- secretName: domain.nine-2019-10-20
- secretName: domain.ten-2019-10-21
- secretName: domain.eleven-2019-10-22
- secretName: domain.twelve-2019-10-23
- secretName: domain.thirteen-2019-10-24
- secretName: domain.fourteen-2019-10-26
- secretName: domain.fifteen-2019-10-27
rules:
- host: domain.one
http:
paths:
- backend:
serviceName: great-site-service
servicePort: 8081
- host: domain.two
http:
paths:
- backend:
serviceName: great-site-service
servicePort: 8081
- host: domain.three
http:
paths:
- backend:
serviceName: great-site-service
servicePort: 8081
- host: domain.four
http:
paths:
- backend:
serviceName: great-site-service
servicePort: 8081
- host: domain.five
http:
paths:
- backend:
serviceName: great-site-service
servicePort: 8081
- host: domain.six
http:
paths:
- backend:
serviceName: great-site-service
servicePort: 8081
- host: domain.seven
http:
paths:
- backend:
serviceName: great-site-service
servicePort: 8081
- host: domain.eight
http:
paths:
- backend:
serviceName: great-site-service
servicePort: 8081
- host: domain.nine
http:
paths:
- backend:
serviceName: great-site-service
servicePort: 8081
- host: domain.ten
http:
paths:
- backend:
serviceName: great-site-service
servicePort: 8081
- host: domain.eleven
http:
paths:
- backend:
serviceName: great-site-service
servicePort: 8081
- host: domain.twelve
http:
paths:
- backend:
serviceName: great-site-service
servicePort: 8081
- host: domain.thirteen
http:
paths:
- backend:
serviceName: great-site-service
servicePort: 8081
- host: domain.fourteen
http:
paths:
- backend:
serviceName: great-site-service
servicePort: 8081
- host: domain.fifteen
http:
paths:
- backend:
serviceName: great-site-service
servicePort: 808115 is the maximum number of certificates one can attach to a load balancer so adding any more secrets to this doesn't work. I want to know what to do in order to scale from here and register more domains. Or if there's a better approach I could take for the whole thing.
You can use either Wildcard or SAN certificates.
With a Wildcard certificate, you can secure a theoretical unlimited number of domains.
While with a SAN certificate it's up to the CA to define a limit on the number of domains that can be secured with the certificate. For LetsEncrypt as stated:
If you have a lot of subdomains, you may want to combine them into a single certificate, up to a limit of 100 Names per Certificate.
Further information can be found on LetsEncrypt FAQs (while the first Q was answered implicitly in the previous quote):
Can I get a certificate for multiple domain names (SAN certificates or UCC certificates)?
Yes, the same certificate can contain several different names using the Subject Alternative Name (SAN) mechanism.
Does Let’s Encrypt issue wildcard certificates?
Yes. Wildcard issuance must be done via ACMEv2 using the DNS-01 challenge. See this post for more technical information.
You can find here some background on these along with certificate management considerations that might help you contemplate this issue from a more design-oriented standpoint.
For support of Wildcard and SAN certificates with GCP LB please confirm official documentation. While for SAN certificates, as it's featured in the linked documentation
SAN certificates are supported for HTTPS load balancing
it could be assumed that both Google-managed and self-managed certificates are being referred.
For Wildcard certificates:
Google-managed SSL certificates do not support using wildcards.
Anyways, the use case from the original poster relates to self-managed certificates, but as pointed by a community peer, it might be nice to have this last piece of information here.