how the communication between self managed worker nodes in the wavelenght and control plans happens ?

When you create an EKS cluster, Amazon EKS creates a highly-available endpoint for the managed Kubernetes API server and provisions two ENIs in different AZs to facilitate communication with your worker nodes.

For self-managed nodes to communicate with the EKS control plane, there are several networking modes available:

1. Public endpoint only: Nodes need either a public IP route through an internet gateway or a private IP route through a NAT gateway to connect to the control plane.

2. Public and private endpoints: Kubernetes API requests from the cluster's VPC communicate with the control plane through managed elastic network interfaces.

3. Private endpoint only: Communication happens exclusively through the managed ENIs in your VPC.

In your case, with both public and private endpoints enabled, your self-managed nodes in Wavelength zones should be able to communicate with the control plane through either the public endpoint or the managed ENIs.

The issue you're experiencing with nodes not registering could be due to several factors:

1. Security group configuration: Ensure that your cluster's security group allows inbound traffic from nodes on port 443 and that nodes can communicate outbound to the control plane on port 443.

2. Network connectivity: Since your worker nodes are in Wavelength zones (Casablanca) and your ENIs are in different AZs (Paris), you need to ensure proper routing between these locations.

3. Bootstrap process: Your userdata script shows that the bootstrap process starts but doesn't complete. This suggests the node can't successfully connect to the control plane.

For the bootstrap.sh script, the --apiserver-endpoint parameter should be the EKS cluster endpoint (not the ENI endpoint). However, the nodes need to be able to route to this endpoint, which could be an issue if there's no proper connectivity between your Wavelength zone and the region where your control plane is located.

You may need to:

1. Check if there are any network ACLs or security groups blocking the communication
2. Ensure proper routing exists between your Wavelength zone and the parent region
3. Verify that the IAM role attached to your instances has the necessary permissions
4. Check the logs on your instances for more detailed error messages about why the bootstrap process is failing

Remember that when using Wavelength zones, which are edge locations, you need to ensure proper network connectivity back to the parent region where your EKS control plane resides.
Sources
How EKS Control Plane is communicate with worker node | AWS re:Post
EKS Control Plane - Amazon EKS
FAQs on Cluster networking architecture in Amazon EKS | AWS re:Post
Maintain nodes yourself with self-managed nodes - Amazon EKS
Network security - Amazon EKS

I’m actually running into something very similar and had the same question when setting up my cluster. In my case too, kubectl get nodes shows nothing, which makes it feel like the worker nodes aren’t properly registering with the control plane. Your observation about the bootstrap script not completing is interesting I’m seeing behavior along those lines as well, where it starts but doesn’t fully finish, which makes me think something is blocking communication with the API server.

I’ve also been trying to figure out whether the communication should go through the public endpoint or via the private networking (ENIs), especially when both endpoints are enabled. The routing and connectivity part is still a bit unclear to me, particularly with nodes in a different region/AZ setup like yours. I also have the same question about whether additional routes or endpoint configurations are needed, or if the API server endpoint being passed in the bootstrap is the root of the issue. Would be great if someone could clarify the exact networking flow here.