Keep 'orchestrator.cluster.name' if 'kubeconfig' is not returned in GKE metadata

[tetianakravchenko]

Signed-off-by: Tetiana Kravchenko [email protected]

What does this PR do?

Keep the orchestrator.cluster.name in add_cloud_metadata processor if kubeconfig is not returned in GKE metadata.

Why is it important?

For some GKE configurations, kubeconfig is not returned in GKE metadata. In this case we were dropping all orchestrator object from the metadata and orchestrator.cluster.name were not populated.

Checklist

• My code follows the style guidelines of this project
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have made corresponding change to the default configuration files
• I have added tests that prove my fix is effective or that my feature works
• I have added an entry in CHANGELOG.next.asciidoc or CHANGELOG-developer.next.asciidoc.

Author's Checklist

• [ ]

How to test this PR locally

Related issues

Use cases

Screenshots

Logs

[mergify]

This pull request does not have a backport label.
If this is a bug or security fix, could you label this PR @tetianakravchenko? 🙏.
For such, you'll need to label your PR with:

• The upcoming major version of the Elastic Stack
• The upcoming minor version of the Elastic Stack (if you're not pushing a breaking change)

To fixup this pull request, you need to add the backport labels for the needed
branches, such as:

• backport-v8./d.0 is the label to automatically backport to the 8./d branch. /d is the digit

[elasticmachine]

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

• Start Time: 2022-10-20T16:40:29.291+0000

• Duration: 81 min 12 sec

Test stats 🧪

Test	Results
Failed	0
Passed	23669
Skipped	1950
Total	25619

💚 Flaky test report

Tests succeeded.

🤖 GitHub comments

Expand to view the GitHub comments

To re-run your PR in the CI, just comment with:

• /test : Re-trigger the build.

• /package : Generate the packages and run the E2E tests.

• /beats-tester : Run the installation tests with beats-tester.

• run elasticsearch-ci/docs : Re-trigger the docs validation. (use unformatted text in the comment!)

[MichaelKatsoulis]

@tetianakravchenko is this (missing kubeconfig in metadata but present cluster name) something that you noticed that happens? And under which circumstances ?

[tetianakravchenko]

@tetianakravchenko is this (missing kubeconfig in metadata but present cluster name) something that you noticed that happens? And under which circumstances ?

@MichaelKatsoulis
After some playing around with the GKE configuration I think it is mainly related to the Security > Shielded GKE nodes setting. The main difference: for clusters that do provide kubeconfig - CREATE_BOOTSTRAP_KUBECONFIG is set to false (CREATE_BOOTSTRAP_KUBECONFIG is a part of kube-env of custom metadata), for clusters that does not contain kubeconfig: CREATE_BOOTSTRAP_KUBECONFIG: "true" and KUBELET_ARGS contains --bootstrap-kubeconfig=/var/lib/kubelet/bootstrap-kubeconfig, that is needed for the bootstrap initialization process https://kubernetes.io/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/#bootstrap-initialization

[tetianakravchenko]

/package