Feature: Kubernetes: Plumbing View - cockpit-project/cockpit GitHub Wiki

Provide internal 'plumbing' view of Kubernetes cluster.

Notes

  • Goal: Show the moving parts that implement a Kubernetes Service
  • Kubernetes services are the externally available entities. Most of the rest is implementation details. We want to convey that implementation this view.
  • Scope: An entry level dashboard is a separate feature
  • Answers questions like:
    • "Why is my service not working?"
    • "What does my service consist of?"
  • Trello: https://trello.com/c/qGiKArif/126-kubernetes-internal-view

Stories

Phillip J. Fry leads a small IT at a moderately sized firm. His company has a modest data center.

Phillip is running the 'Poppler.io' application. 'Poppler.io' is an application that runs on top of a Kubernetes cluster. This morning the application stopped "working". Phillip uses the internal view to see that one of the database pods has failed.

Hermes Conrad is the VP of engineering at a large corporation.

Hermes is exploring Kubernetes as a way to orchestrate containers. He has just setup a Kubernetes master, and add further machines. Hermes has no deep knowledge of Kubernetes, but Docker was seemed easy to discover hands-on, and wants to do the same here. Hermes uses the nested view to see how services are built up from moving parts, how they are scaled etc.

Workflows

Phillip:

  • Clicks on a failed service on the Cockpit Kubernetes Dashboard
  • Is taken to the internal view of the service, and able to see its moving parts.
  • Sees one of the pods has failed
  • Clicks on the pod for details.
  • Notes which host this pod is running on.
  • Is able to diagnose a missing application container image that wasn't pushed to the right repo.

Hermes:

  • Clicks on a failed service on the Cockpit Kubernetes Dashboard
  • Can explore replication controllers, and the pod template information
  • Can see how the pods consist of containers

Implementation Notes and Technical Limitations

  • Watch for changes in kubernetes and update them on the fly.
  • Although kubernetes has no concept of 'nesting', such a concept is critical to solve the user's stories.
    • The user asks questions like: "Which pods belong to this service?" "Which part of my service has failed?"
    • Even though such a concept is is not directly present in kubernetes, we want to answer those questions.
    • Some objects may be duplicated in this view. It'll be discoverable from the design that they are the same object.
  • Later: Display openshift related entities, object inheritance.
  • Out of scope: complete detailed views of the entities, their history, resources, etc.
  • Failures should stand out.
  • To show nested relations two types of queries are needed across the Kubernetes relationships:
    • Typical selector -> label query.
    • Reverse label <- selector query, which tells us which selectors would match a given label.
  • Research incomplete

Wireframes

Feedback

Please give feedback on the above! This is the place where those not working on the feature can provide insight, questions, limitations, notes etc.

  • ... (sign name)
  • ... (sign name)