k8s Service, shows the IP and port that is being exposed within the cluster. Visually it should be associated with the things that it is routing to.
OpenShift Deployment, shows when and why the deployment was triggered, visually associated with what is running in the deployment
k8s/OS Pod Template (what am I actually running), shows what image is running. if the image came from OS build process then it includes build info. Shows source info that went into the build when it is known.
k8s Pods, the actual instances of the pod template including a minimal amount of status (state, IP, etc).
Structural overview of k8s and OpenShift resources
What’s being shown:
Example of the same visualization applied to only k8s resources.
Structural overview of k8s and OpenShift resources - complex scenarios
Service (routing to frontend web port for Deployment Config A, Deployment Config B, and a random pod)
OS Deployment Configuration A
OS Deployment Configuration B
Most recent OS Deployment of Deployment Config A
Pod template (Image 123)
Pod
Pod
Pod
Older active OS Deployment of Deployment Config A
Pod template
Pod
Pod
Pod
Oldest active OS Deployment of Deployment Config A
Pod template
Pod
Pod
Pod
Most recent OS Deployment of Deployment Config B
Pod template (Image 456)
Pod
Pod
Pod
Older active OS Deployment of Deployment Config B
Pod template (Image 456)
Pod
Pod
Pod
Oldest active OS Deployment of Deployment Config B
Pod template (Image 456)
Pod
Pod
Pod
When viewing k8s resources without OS concepts, things that are routed to by the service should still all be visually connected by the service.
SIngleton pod whose label matches the service’s label selector
Pod
Pod template (Image 789)
Service (routing to admin port on Dep Config A only)
A single k8s service may route to similar but different pods. One example includes multiple deployment configurations during an A/B test.
Multiple services may route to the same set of running pods, in this case the services should be stacked.
Vertical relationships between deployments should indicate time, with the most recently deployed deployments within a deployment configuration being the most important.
Clicking on a specific resource navigates to the detailed information and status for that resource (service, image, build, source, pod, etc). In OS navigation structure this would be underneath Browse
Interaction with the overview
Possible extension points within the overview
Additional details for what is running in the pods. Ex: if we know it is a JBoss image and that it has Camel routes configured then inject a link to view the Camel routes
Area beneath the deployment may provide suggestions. Ex: I am running the Rails image but I have no database images running in my project, suggest setting up a DB service.
Entire sections could be swapped out with other visual representations. Pod template, pod details, etc
Navigating the console
Structural overview (default tab when going to a project)
Pipelines. This includes build pipelines (source -> build -> image), known environment pipelines (dev -> test -> production)
Metrics and monitoring. This includes both container level system resource monitoring and extended monitoring details such as JVM monitoring (think threads, etc) and event bus monitoring.
Events (timeline), important things happening within your project.
Logs. Viewing the logs for your running containers. Viewing logs for your already completed or running builds.
Browse. Dig down into lists of resources for any resource type. Ex: I want to look at a list of all the pods in my project
Membership. View/edit the users/teams that have access to this project and its resources.
Settings. General settings for the project.
Switch between projects, the current selected left tab is maintained when switching
Filter the current view by labels
Secondary navigation column will only appear as needed. Example shown is the secondary nav for Browse.
Additional wireframes live in the OpenShift Origin repo