Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Redesign the page where we explain services to people #5654

Open
Tracked by #6419 ...
catherineluse opened this issue Apr 15, 2022 · 0 comments
Open
Tracked by #6419 ...

Redesign the page where we explain services to people #5654

catherineluse opened this issue Apr 15, 2022 · 0 comments
Assignees
Labels
kind/design kind/enhancement requires-prototyping Label for complex designs that would require a UX designer to create full layouts and workflows research-needed Label for design issue that requires more technical research than what is in the issue description
Milestone

Comments

@catherineluse
Copy link
Contributor

catherineluse commented Apr 15, 2022

If I were new to Kubernetes, I would have no idea which of these options to choose on this page, in spite of the fact that we try to explain them in text:
Screen Shot 2022-04-15 at 12 41 33 AM

My problems with this page are:

  • It presents normal options with equal visual importance to advanced options. ExternalName and Headless are more advanced options that are geared toward people who want to implement their own service discovery or integrate with something outside of Kubernetes, so they should be visually diminished.
  • It gives the misleading impression that if you want to expose a workload, you have to pick one of the five options. In reality though, they build on each other and you might need two. NodePort builds on ClusterIP, and LoadBalancer builds on NodePort. This is why in the Ember UI, when you deployed a workload, Rancher automatically deployed two Services to expose it - both a LoadBalancer AND a ClusterIP. In the new UI, we expect people to be able to manually do that, so we should help them figure it out. In my mind, it should logically cascade from ClusterIP to NodePort to LoadBalancer. (see my notebook picture that I drew below)
  • The icons don't convey meaning.
  • The text says that LoadBalancer can expose a workload externally, but it leaves out any mention of the fact that you may need an ingress if you don't want to pay for an IP for every service, for example. It also makes it sound like a service of type LoadBalancer is required to expose a workload, but a) NodePorts can also expose workloads externally, especially for development purposes, and b) you can expose any service externally - including the ClusterIPs - if you configure an Ingress to direct traffic to it.

@kwwii I've assigned this to you so that you can be aware of it, but it is very low priority and has no milestone.

This also ties into #5441 and #4845.

A more logical progression with more meaningful icons might look something like this:
20220415_025832.jpg

In case it helps, here's how I understand the basic decision flow:

Screen Shot 2022-04-15 at 2 22 36 AM

Helpful reading:

@catherineluse catherineluse added [zube]: Design Backlog research-needed Label for design issue that requires more technical research than what is in the issue description requires-prototyping Label for complex designs that would require a UX designer to create full layouts and workflows labels Jul 11, 2022
@kwwii kwwii modified the milestones: v2.7.0, v2.7.x Jul 19, 2022
@kwwii kwwii modified the milestones: v2.7.x, vNext Feb 22, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/design kind/enhancement requires-prototyping Label for complex designs that would require a UX designer to create full layouts and workflows research-needed Label for design issue that requires more technical research than what is in the issue description
Projects
None yet
Development

No branches or pull requests

3 participants