The best approach to expose a new application hosted on Google Kubernetes Engine (GKE) with autoscaling enabled to the public using HTTPS on a public IP address is to use a Kubernetes Ingress. Therefore, the suggested answer is A. Create a Kubernetes Service of type NodePort for your application, and a Kubernetes Ingress to expose this Service via a Cloud Load Balancer.

Reasoning: This approach offers several advantages:

Cloud Load Balancer Integration: Kubernetes Ingress, especially when used with GKE, automatically provisions and manages a Google Cloud Load Balancer. This load balancer provides the public IP address, handles SSL termination (HTTPS), and distributes traffic across the backend pods of your application.
Simplified Configuration: Ingress simplifies the process of exposing services. You define rules based on hostnames or paths to route traffic to different services within your cluster.
Automatic Updates: As your application scales (due to autoscaling), the Ingress controller automatically updates the load balancer configuration to include the new pods.
HTTPS Support: Ingress can be configured to use TLS certificates for HTTPS, ensuring secure communication. The Cloud Load Balancer handles the SSL termination, offloading that task from your application pods.
NodePort Requirement: While Ingress manages the external access, the backend service needs to be reachable by the Ingress controller. A NodePort service makes the application accessible on each node's IP address at a specific port, allowing the Ingress controller to route traffic appropriately.

Reasons for not choosing the other options:

B. Create a Kubernetes Service of type ClusterIP for your application. Configure the public DNS name of your application using the IP of this Service. ClusterIP services are only accessible within the cluster and are not meant for external access. You cannot directly expose a ClusterIP service to the public internet. DNS resolution alone does not provide load balancing.
C. Create a Kubernetes Service of type NodePort to expose the application on port 443 of each node of the Kubernetes cluster. Configure the public DNS name of your application with the IP of every node of the cluster to achieve load-balancing. While NodePort does expose the service externally, relying on DNS for load balancing is not ideal. DNS-based load balancing has limitations, such as caching and uneven distribution. Also, managing DNS records for each node can become complex and error-prone. It also does not automatically handle SSL termination.
D. Create a HAProxy pod in the cluster to load-balance the traffic to all the pods of the application. Forward the public traffic to HAProxy with an iptable rule. Configure the DNS name of your application using the public IP of the node HAProxy is running on. While this approach can work, it requires manual configuration and maintenance of HAProxy and iptables rules. It doesn't integrate as seamlessly with GKE's autoscaling and load balancing capabilities as Ingress does. Managing HAProxy manually adds operational overhead.

In summary, using a Kubernetes Ingress with a NodePort service provides the most robust, scalable, and manageable solution for exposing your application publicly on GKE with HTTPS.

Kubernetes Ingress, https://kubernetes.io/docs/concepts/services-networking/ingress/
Google Cloud Load Balancer, https://cloud.google.com/load-balancing
Kubernetes Service Types, https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types