Improve ALB -> K8s linking

[dylanratcliffe]

Because pods change so frequently, it's very likely that the ALB target group to pod mapping will be out of date in revlink since they rely on the IP address. It would be better if we could link them more directly in a way that wouldn't be as affected by the changing IPs of the pods.

The best way to do this is probably the tags on the target group:

tag	value
elbv2.k8s.aws/cluster	dogfood
ingress.k8s.aws/resource	default/api-lb-gateway:8080
ingress.k8s.aws/stack	default/api-lb

Maybe linking from K8s in this direction would be best? Search for target groups by tag maybe?

[dylanratcliffe]

It is possible to get the cluster name from the userdata assuming the pod has access to the IMDSv2 endpoint. We could use this to get the data: https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/feature/ec2/imds and then parse out the name, though it's not very robust. This would however allow the k8s source to determine the name of the cluster it is running in which would match the tags above

[dylanratcliffe]

Looking further I'm almost certain that you could enable automatic cluster naming for EKS by:

• Using the IMDS API to get the instance ID, region etc.
• Using the fact that EKS instances have IAM permission to get instance and cluster details to get the details of the cluster based on the tags of the instance

However this only solves half the problem. In order to solve the other half we need to be able to work what k8s resource the targetgroup refers to, which in this case is encoded in the tags. If we were to start capturing tags we could solve this.

The other option of course is simply to keep revlink up to date. If we had a mechanism for listening for updates from k8s, we could keep revlink up to date and we'd be able to link based on the IP reliably

[dylanratcliffe]

I think the solution here is to create links once overmindtech/k8s-source#133 has been implemented, and tags are a first class citizen so we can create a link from the tagged target group to the service