Inaccessible interface after clean installation

[rascasoft]

Describe the bug After installing Krateo with the Helm chart (on a freshly installed Kubernetes with Kind), by following the documentation, the frontend interface shows an error related to the authentication method.

To Reproduce Steps to reproduce the behavior:

1. Install Krateo using the Helm chart.
2. Expose the frontend so that it can be accessible, as in:

   $ kubectl -n krateo-system expose service krateo-frontend-x-krateo-system-x-vcluster-k8s --type=LoadBalancer --name=krateo-frontend-x-krateo-system-x-vcluster-k8s-lb

3. Try to access the interface and you will get "Ops! Something didn't work / Unable to retrieve authentication methods" (see attachment).

Expected behavior A login interface.

Screenshots

Desktop (please complete the following information):

• OS: Linux Mint Virginia
• Browser Firefox
• Version 125.0.1

[braghettos]

Krateo services are exposed as NodePort type by default. If using Kind, these ports must be exposed in the following way: https://github.com/krateoplatformops/krateo/blob/main/scripts/kind-vcluster.sh#L20-L47

[rascasoft]

That is clear, but those ports are correctly exposed by my cluster, the lb addition is a commodity that I use (it's metallb):

$ kubectl -n krateo-system get services
NAME                                                TYPE           CLUSTER-IP      EXTERNAL-IP    PORT(S)                         AGE
authn-service-x-krateo-system-x-vcluster-k8s        NodePort       10.96.42.251    <none>         8082:30082/TCP                  30h
krateo-bff-x-krateo-system-x-vcluster-k8s           NodePort       10.96.82.150    <none>         8081:30081/TCP                  30h
krateo-frontend-x-krateo-system-x-vcluster-k8s      NodePort       10.96.183.128   <none>         8080:30080/TCP                  30h
krateo-frontend-x-krateo-system-x-vcluster-k8s-lb   LoadBalancer   10.96.192.96    172.18.0.100   8080:32750/TCP                  30h
krateo-gateway-x-krateo-system-x-vcluster-k8s       NodePort       10.96.157.79    <none>         8443:30443/TCP                  30h
kube-dns-x-kube-system-x-vcluster-k8s               ClusterIP      10.96.255.182   <none>         53/UDP,53/TCP,9153/TCP          30h
vcluster-k8s                                        NodePort       10.96.95.122    <none>         443:32633/TCP,10250:30739/TCP   30h
vcluster-k8s-etcd                                   ClusterIP      10.96.164.3     <none>         2379/TCP,2380/TCP               30h
vcluster-k8s-etcd-headless                          ClusterIP      None            <none>         2379/TCP,2380/TCP               30h
vcluster-k8s-node-krateotest-control-plane          ClusterIP      10.96.11.134    <none>         10250/TCP                       30h

Pointing to the nodeport doesn't change the result. Given that my cluster is on 172.18.0.2:

 kubectl get nodes -o wide
NAME                       STATUS   ROLES           AGE   VERSION   INTERNAL-IP   EXTERNAL-IP   OS-IMAGE                         KERNEL-VERSION     CONTAINER-RUNTIME
krateotest-control-plane   Ready    control-plane   30h   v1.29.2   172.18.0.2    <none>        Debian GNU/Linux 12 (bookworm)   6.5.0-27-generic   containerd://1.7.1

I can reach the 172.18.0.2:30080 interface, with the same results as the load balancer exposed IP:

Am I missing something here?

Many thanks!

[rascasoft]

To give additional context, what seems to break things is a call to 127.0.0.1:30082, and seems I am using the external cluster IP with the NodePort this is unreachable:

Hope this helps.

[braghettos]

Please try with updated info: https://docs.krateo.io/how-to-guides/installing-krateo/#basic-installation, kind section

[rascasoft]

I can confirm that by using the kind configuration with the fixed node ports the login page is now showing up (given that missing link pointing to http://172.18.0.2:30080/assets/logo_big-11b390ab.svg):

Problem is that I don't feel like imposing a kind configuration based on two nodes and on fixed NodePorts should be considered a solution. Since we're talking about services that are communicating one to another, we should not have fixed links to node ports.

I think that the interface should work using the NodePort, a LoadBalancer or by even using kubectl -n krateo-system port-forward krateo-frontend-5dcbcdb7f-687sm-x-krateo-system-x-vcluster-k8s 8080:8080 to directly map the port on localhost. Today this does not work:

And this was tested with the latest Helm chart as well. I don't think this issue should be closed.