fix: solve timeout when api server hostname is given

[axgkl]

docs say # api_server_hostname: k8s.example.com # optional: DNS for the k8s API LoadBalancer. After the script has run, create a DNS record with the address of the API LoadBalancer.

And indeed, the user can't do this BEFORE running the script, not knowing the IP of the API LB created.

But since we set that hostname into the kubeconfig, when we do save_kubeconfig(master_count) and in the next command do kubectl cluster-info, this can't work - since at that time the DNS is not configured to point to that api loadbalancer.

My suggested fix is to set the IP of the LB into the kubeconfig. Then all will work and the user can, at his pace, configure his DNS to point to the api lb for that hostname - and only then adapt the kubeconfig, if wanted. SSL will work since we configure tls-sans for that hostname anyway. But kubeconfig, we can't do this for the user, having no control over if and when he configures his DNS.

`

[axgkl]

Suggested Feature regarding that api loadbalancer:

Would you accept a PR for the feature below, did not dare to put it in here - but it would help me a lot.

Thing is: I don't want the API loadbalancer, keep deleting it anyway and point my kubectl to one of the masters.

So this would allow to have it set to the first master via the "api_server_hostname" key:

diff --git a/src/kubernetes/installer.cr b/src/kubernetes/installer.cr
index 8f33273..27c6735 100644
--- a/src/kubernetes/installer.cr
+++ b/src/kubernetes/installer.cr
@@ -358,6 +358,10 @@ class Kubernetes::Installer
   end

   private def api_server_ip_address(master_count : Int)
-    master_count > 1 ? load_balancer.not_nil!.public_ip_address.not_nil! : first_master.host_ip_address.not_nil!
+    if settings.api_server_hostname == "first_master"
+      first_master.host_ip_address.not_nil!
+    else
+      master_count > 1 ? load_balancer.not_nil!.public_ip_address.not_nil! : first_master.host_ip_address.not_nil!
+    end
   end
 end

Add Note: Last week, one day, all day, the LB status never(!) went healthy, allthough 6443 ports where all listening, hetzner had problems. This feature here allows installs nevertheless, while with the current version there is no way, in such a situation, to get the installer running through. Not sure naturally how often this happens.

[vitobotta]

Thanks for the PR! I agree this is a better approach overall, since it's unlikely that people are going to interact with the API via hostname directly anyway.