If you have a load-balanced service that is on the public Internet, it will need to present a certificate for the service using the name it has on the Internet, e.g suppose you run webserv1, webserv2 and webserv3 and together they offer a load-balanced service presented as www.example.com, the user’s web browser expects a certificate for www.example.com, and isn’t interested in certificates for webserv2 in this case, it has no idea they exist. Let’s Encrypt is very pleased to offer certificates for this purpose, but you will need to pass an authentication challenge for www.example.com, and the easiest ways to do that are made a bit trickier by having several servers.
One option is “DNS authentication”. The certbot / letsencrypt Python client don’t do this, but the Let’s Encrypt CA itself does support it and you can find shell scripts online that show how it’s done. It requires creating a TXT record with contents specified on the fly. If you’re comfortable setting up scripts that configure DNS records automatically, this may be a good option for you. Another option is the “webroot” mode, for this you need to ensure that files your ACME client (certbot or the letsencrypt Python client or any other you’ve chosen) will appear in the desired place on your web site under .well-known/acme-challenge/, to anybody from the public Internet. You might be able to grant a special case in your load balancer, saying these requests always go to say, webserv1, while other requests are load balanced. Or you could use a distributed filesystem to ensure the files appear on all the servers at once. Then you need to ensure the certificates get installed / configured everywhere. People using the same load balancer as you might have written their own approaches. I know one exists for the F5 Big IP for example that includes auto-renewal.
NB Names that aren’t on the public Internet are not eligible for certificates from a public CA (since 2015). So you can’t ever receive a certificate for the local name “webserv1” or “webserv1.local” and you can only receive a certificate for “webserv1.example.com” if you can prove control over that public name. For Let’s Encrypt that would mean either making webserv1.example.com route to your systems from the Internet at least enough to complete LE authentication, or using a DNS challenge. Some other (commercial) public CAs will be happy to issue based on proof you control example.com, for example a bunch of paperwork from your DNS registrar saying yes you own this domain, but Let’s Encrypt is fully automated so it has nobody to examine paperwork or answer telephone calls.