fix(logging): correctly detect GKE resource

[freelerobot]

Fixes: #4079

Changes:

• Refactored resource autodetection logic to new file resource.go
• Fixes previous incorrect detection where GKE logs were labeled as GCE. Labels still missing container_name because there's no unhacky way to get this info.
• End to end GKE environment tests are now available for this here

Decisions:

• namespace_name: Finally, the default namespace to be used for namespaced API operations is placed in a file at /var/run/secrets/kubernetes.io/serviceaccount/namespace in each container.
  https://kubernetes.io/docs/tasks/access-application-cluster/access-cluster/#accessing-the-api-from-a-pod
• podname_name: HOSTNAME envvar
• container_name: CONTAINER_NAME optional user provided envvar

[daniel-sanche]

Labels still missing container_name because there's no unhacky way to get this info.

One (imperfect) option would be to try to detect CONTAINER_NAME (or something similar) and instruct users to populate it using the downward API

This could be useful as a second option for pod_name and namespace_name too, in case there are edge cases where the current heuristics don't work

[daniel-sanche]

I don't think we can guarantee this file will always be accessible. It looks like you're already doing error checking so it should be fine, just wanted to double check

[freelerobot]

correct, it will just be "" if readfile fails. We can rely on this to exist majority of the time though.

its a part of kubernetes downward api contract:
https://kubernetes.io/docs/tasks/access-application-cluster/access-cluster/#accessing-the-api-from-a-pod
Finally, the default namespace to be used for namespaced API operations is placed in a file at /var/run/secrets/kubernetes.io/serviceaccount/namespace in each container.

[daniel-sanche]

Ok cool, yeah I just wanted to make sure all the necessary error-checking was done since I'm not super familiar with go. But it looks like it should be!

[daniel-sanche]

There are a lot of repeated magic strings in this file. Maybe turn these into constants?

[freelerobot]

Agree magic numbers are not great. I actually wrote one iteration with constants (camel case). But, since resource.labels have to be in snake case, I liked the explicit nature of having the snake-case keys inline with the variable setting.

Also go is statically typed, I like the idea of the compiler not having to know all the constants that the switch case might not end up accessing.

[daniel-sanche]

I was also thinking of things like K_SERVICE, which are used in multiple places. For Python I put these at the top, but I think it's fine as-is too

[freelerobot]

Labels still missing container_name because there's no unhacky way to get this info.

One (imperfect) option would be to try to detect CONTAINER_NAME (or something similar) and instruct users to populate it using the downward API

This could be useful as a second option for pod_name and namespace_name too, in case there are edge cases where the current heuristics don't work

Adopted! @daniel-sanche, mind taking another look and stamping? Thank you.

[gcf-merge-on-green]

Merge-on-green attempted to merge your PR for 6 hours, but it was not mergeable because either one of your required status checks failed, one of your required reviews was not approved, or there is a do not merge label. Learn more about your required status checks here: https://help.github.com/en/github/administering-a-repository/enabling-required-status-checks. You can remove and reapply the label to re-run the bot.