[EKS] [PrivateLink Support]: Support Kubernetes API server endpoint as AWS PrivateLink Endpoint

### Community Note

* Please vote on this issue by adding a 👍 [reaction](https://blog.github.com/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/) to the original issue to help the community and maintainers prioritize this request
* Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
* If you are interested in working on this issue or have submitted a pull request, please leave a comment

**Tell us about your request**
What do you want us to build?

Support for AWS PrivateLink Endpoints for Elastic Kubernetes Service.

**Which service(s) is this request for?**
**Elastic Kubernetes Service**. ECR and ECS are already supported as PrivateLink Endpoints.

**Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?**
What outcome are you trying to achieve, ultimately, and why is it hard/impossible to do right now? What is the impact of not having this problem solved? The more details you can provide, the better we'll be able to understand and solve the problem.

We have EKS clusters running in various VPCs for production, pre-production, etc. One of the VPCs is solely devoted to continuous integration/deployment, but of course it needs access to certain resources in our other VPCs in order to do its various jobs. One of those jobs is to run Terraform, which in turn creates Kubernetes resources, so it needs to access the Kubernetes API of our pre-production and production environments, which of course are in separate VPCs and are set up as private EKS endpoints. If we had PrivateLink Endpoint support for EKS, we could create a PrivateLink Endpoint of our pre-prod/prod EKS API Servers into our CI/CD VPC for access by our CI/CD jobs.

**Are you currently working around this issue?**
How are you currently solving this problem?

Right now, we use a VPC Peering connection to allow access to resources across VPCs. Additionally we attempt to use Security Groups (and soon Security Groups for Pods) to be able to better lock down which resources in the CI/CD VPC can access which resources in the pre-prod/prod VPCs, but it is definitely cumbersome. There are some resources that should never be accessed by our CI/CD VPC, so there is no point in exposing them via the VPC Peering Gateway.

Alternatively, we have thought about creating a load balancer that was registered as a PrivateLink Service and have that point at the IPs behind the EKS Kubernetes API endpoint. Of course that would require a background process that continually queries the EKS enpdoint DNS to get the list of IPs and shove them into a Target Group, but theoretically it sounds possible.

**Additional context**
Anything else we should know?

PrivateLink Endpoints also make the intention of access more explicit. As I come to look at the set up in a month or two, I might question why we have a whole VPC Peering connection set up as it feels overly permissive. Then I might go on to turn something off not realizing that I broke these other services owned by another team because they relied on some esoteric Security Group setting and the VPC Peering connection. If we used PrivateLink Endpoints, then I know that job a/b/c only need access to the Kubernetes API, and job d/e/f only need access to some other resource. This would be something we inherently get by having explicit endpoints across VPCs for specific resources.

Hopefully this all makes sense, it felt a little "wordy".

**Attachments**
If you think you might have additional information that you'd like to include via an attachment, please do - we'll take a look. (Remember to remove any personally-identifiable information.)

Start by reviewing the repository's existing ECR and ECS PrivateLink support, then compare it with the EKS Kubernetes API endpoint and the Terraform workflow described in the issue. Done means enabling an AWS PrivateLink endpoint for an EKS API server across VPCs while preserving the intended access restrictions.

Written by the indexing model from the issue text.