Improve consistency of Fleet UI deployment to Kubernetes experience

[mlunadia]

As a continuation of the improvements brought by

• [Fleet] Present users with a Kubernetes manifest for deploying agent in fleet managed mode for Kubernetes #127703
  a few areas for further improvement have been identified:

1. Enabling users to select Kubernetes when Kubernetes integration hasn't been added to their chosen policy
   The current experience exposes the user to the Kubernetes manifest deployment experience only if the user has selected a policy where Kubernetes has been added as an integration.

The feedback has been that this forces new users to be familiar with how agent policies and integrations work before enabling them to deploy agent to Kubernetes and it is not clear that the Kubernetes integration is required.

This will also solve for security use cases where the Kubernetes integration is not a must.

2. Auto-select Kubernetes deployment mode when Kubernetes is detected

Requirements:
1. Kubernetes needs to be treated consistently to other types of hosts meaning that it should be a tab option next to Linux, mac, windows, etc..
2. When a user selects a policy that includes the Kubernetes integration, the Kubernetes tab should be preselected by default.

The changes between the daemonset / configmap manifest should remain as handled today.

[elasticmachine]

Pinging @elastic/fleet (Team:Fleet)

[mlunadia]

@joshdover would be great to get your thoughts on this one. The cloud-native team could support getting this through in similar fashion we worked together for #127703

[mlunadia]

@learhy @nick-alayil this is aimed at improving the onboarding from a solution agnostic perspective.

[joshdover]

I'll defer to @kpollich on this, but I don't have any opposition to a contribution. One issue to consider is that we're moving to a new onboarding flow that leads with installing the Agent first, potentially even before an integration has been selected. I don't think this will make sense for k8s deployments because the security requirements of the container need to be known before the k8s manifest is generated.

[MichaelKatsoulis]

@joshdover Is this new onboarding flow coming in 8.4? Should we proceed with updating the Kubernetes experience or wait for your change as it may change the whole layout a lot ?

[ChrsMark]

I know this issue is for managed Agent but if I'm not mistaken we have a similar flow for the standalone one, right?

We have several discussions regarding Hints in standalone Agent at elastic/elastic-agent#613 (comment) which might be related to the flow examined in this issue.

@MichaelKatsoulis @kpollich we can sync on this to make sure we head towards one single direction.

[joshdover]

Is this new onboarding flow coming in 8.4? Should we proceed with updating the Kubernetes experience or wait for your change as it may change the whole layout a lot ?

The new onboarding experience is partly in place today, but only when adding your first integration when onboarding on ESS and it still requires choosing the integration first. I believe we already exclude the Kubernetes integration from this new flow. The next stages haven't yet been scheduled (moving integration selection to after agent install), so they won't be coming until 8.5 at the earliest, but likely later.

[kpollich]

I believe we already exclude the Kubernetes integration from this new flow.

This is correct, we exclude a few packages including Kubernetes from the "multi page" onboarding flow:

https://github.com/elastic/kibana/blob/main/x-pack/plugins/fleet/public/applications/integrations/sections/epm/screens/detail/utils/get_install_route_options.ts#L18

[MichaelKatsoulis]

@kpollich, @joshdover
I am really interested in this multi-page approach. Why was Kubernetes excluded? It just needs a slightly different handling on agent install instructions (download the manifest).
Also an additional nice step in the end. after data confirmation

could be a Visualize data where the OOTB dashboards could be listed.
@mlunadia

[hop-dev]

hi @MichaelKatsoulis, due to time constraints in the 8.3 iteration we omitted any integration with custom UI elements or steps. The new multi page layout is very much an MVP at the moment.

[mlunadia]

@hop-dev @joshdover I've added a comment on the multi-page issue for exploring an infrastructure first approach for hosts.
We will for now we will move forward with this issue as it is as it makes sense to make this step consistent but it will be worth it to explore that flow which is much of an industry standard and reduces the need for new users to understand in detail what agent and integrations are and how they work.

[mlunadia]

cc: @alvarolobato these are the onboarding flow changes we discussed a few weeks back during our sync.

[alvarolobato]

@mlunadia ++ looking good, this will improve the experience quite a bit.

[mlunadia]

cc: @learhy @tinnytintin10 @nick-alayil

[dimadavid]

this is looking great!

Did we explore an option to have the install (step4 for Kubernetes) be part of the step 3 section? the logic is that it would be a bit cleaner if the environment toggles in the step 3 section would affect the UI areas in that section. Cross section UI dependencies work, but if we can avoid it, it would be better, interaction-design-wise.

Also, it feels to me that the order could be as this:
[Windows] [Mac] [Linux Tar] [RPM] [DEB] [Kubernetes]

[mlunadia]

Did we explore an option to have the install (step4 for Kubernetes) be part of the step 3 section? the logic is that it would be a bit cleaner if the environment toggles in the step 3 section would affect the UI areas in that section. Cross section UI dependencies work, but if we can avoid it, it would be better, interaction-design-wise.

@dimadavid have a look at #136014 and let us know your thoughts.

Also, it feels to be that the order could be as this:
[Windows] [Mac] [Linux Tar] [RPM] [DEB] [Kubernetes]

@MichaelKatsoulis check this comment from @dimadavid to discuss order in #136109

[dimadavid]

@dimadavid have a look at #136014 and let us know your thoughts.

Yes, the consolidated step 3 looks way better and feels more streamlined. There are some UI improvements I would make tho. I asked for Figma file if it exists.

[jen-huang]

@mlunadia @MichaelKatsoulis Saw this was marked Done on your team's board, can we close this out?

[rameshelastic]

Closing this as this issue is being tracked elsewhere. https://github.com/elastic/ingest-dev/issues/1269