OpenShift web console

Logging into the OpenShift Web Console

The OpenShift web console is a browser-based interface for interacting with an OpenShift cluster. In this chapter, the focus is on how to use it in practice, not on the underlying APIs or CLI equivalents.

How you reach the console URL depends on how your cluster is deployed, but typically it has a pattern like:

• https://console-openshift-console.apps.<cluster-domain>
• or is provided by your administrator.

Common login flows:

• OAuth-based login (most common):
• Username and password against an identity provider (LDAP/AD, GitHub, etc.).
• Sometimes redirected to a corporate SSO page.
• Token-based login:
• You paste or select an already-issued token.
• Common for temporary access or automation.

From within the console you can usually:

• View your current user and permissions (e.g. by clicking your username in the top-right corner).
• Log out safely, especially when using shared machines or labs.

Console Layout and Navigation

While the exact appearance may vary slightly by OpenShift version, the console layout follows a common pattern.

Global Layout

Typical elements:

• Header (top bar):
• Current project/namespace selector.
• User menu (profile, logout, copy login command, etc.).
• Sometimes quick links to documentation or help.
• Primary navigation (left sidebar):
• Main sections such as:
• Home
• Workloads
• Networking
• Storage
• Builds
• Pipelines
• Operators
• Administration (only visible with appropriate permissions).
• The available items depend on your user role and the installed features.
• Main content area:
• Changes based on what you’ve selected in the sidebar.
• Includes tables, forms, charts, YAML editors, logs, and dashboards.

Perspectives: Developer vs Administrator

The console offers different “perspectives” optimized for different tasks:

• Developer perspective:
• Focuses on application-centric workflows.
• Highlights:
• Topology view of your applications.
• Git import and deployment flows.
• Build, route, and pipeline views.
• Simplifies many details of underlying Kubernetes/OpenShift resources.
• Administrator perspective:
• Focuses on managing the cluster and platform resources.
• Highlights:
• Nodes, operators, storage, networking, and cluster settings.
• More raw views of resources, closer to Kubernetes concepts.

You can switch perspectives using a selector, typically in the upper-left area of the sidebar. The choice affects which menus and views are available, but does not change your actual permissions (those are controlled by RBAC).

Working with Projects and Namespaces in the Console

While the concepts of projects and namespaces are covered elsewhere, here is how they appear specifically in the web console.

• A project selector is usually present in the header.
• Selecting a project scopes:
• The lists of workloads, services, and other resources.
• The data in dashboards, topology, and most views.

Typical actions (when you have privileges):

• Create a project:
• Project or Create Project button from the selector or from a “Projects” page.
• Simple form: name, display name, description.
• Switch projects:
• Use the dropdown selector.
• Recent projects are often listed at the top.
• View project details:
• Quotas, limits, annotations, and access permissions.
• Useful to understand what you are allowed to run.

Developer Perspective: Application-Centric Views

The Developer perspective is designed to simplify deploying and managing applications.

Topology View

The Topology view is the main visual overview of your application in a project:

• Shows each application component as a node (pod/controller) connected with:
• Services
• Routes
• Pipelines (if present)
• Visual cues for:
• Pod status and health (color, badges).
• Scaling (number of pods).
• Build or deployment activity.

Common interactions from the topology graph:

• Click a node to open a side panel with:
• Basic info: name, type (Deployment, DeploymentConfig, etc.).
• Status, labels, and resource links.
• Actions like Edit, Scale, View logs, Open URL.
• Right-click (or action menu) for:
• Add to application or Add resource.
• Diagnostics (view YAML, events).

Topology helps you understand how components relate and where there may be issues (e.g. a pod crash loop).

“Add” Flows (Creating Applications)

Under the Developer perspective, the Add section includes guided workflows to create workloads. Typical options:

• From Git:
• You provide a git repository URL.
• Choose a language/runtime or builder image (e.g. Node.js, Python, Java).
• Set application name and route options.
• OpenShift builds and deploys automatically (often via S2I or a Dockerfile).
• Container Image:
• Deploy directly from an existing container image in a registry.
• From Catalog:
• Choose from a catalog of pre-defined templates and Operators (databases, middleware, etc.).
• Import YAML:
• Paste or upload Kubernetes/OpenShift YAML manifests.
• Database or Operator-backed services:
• Provided via installed Operators (e.g. PostgreSQL, Kafka).

These flows hide many low-level details, creating common deployment resources on your behalf.

Monitoring and Debugging from Developer Perspective

Developer-focused tools in the console include:

• Logs:
• View pod or container logs directly from the topology node or workload page.
• Search and filter, with options to follow real-time output.
• Terminal:
• Web-based terminal into a running pod’s container (if allowed).
• Useful for quick diagnostics and inspection.
• Pod metrics and status:
• Basic CPU/memory usage for workloads.
• View events to see scheduling or failure issues.

The goal is to let you handle most application-level debugging without leaving the console.

Administrator Perspective: Resource and Cluster Management

The Administrator perspective exposes more infrastructure-level views.

Resource Browsing

Key sections typically include:

• Workloads:
• Deployments, StatefulSets, DaemonSets, Jobs, CronJobs, Pods, etc.
• Networking:
• Services, Routes, Ingress, NetworkPolicies, etc.
• Storage:
• PersistentVolumeClaims, StorageClasses, snapshots (if enabled).
• Administration / Cluster Settings:
• Nodes and machine configuration.
• Operator management.
• Cluster-wide configuration (authentication, API server, etc.).

Views usually follow a common pattern:

• A tabular list:
• Name, namespace, status, age, labels, etc.
• Filters:
• By name, label, or status.
• Actions:
• Create, Edit, Delete, Clone, View YAML, View events.

Nodes and Health

From the admin perspective, you can see:

• Node list:
• Node name, roles, status, resource utilization.
• Details for a node:
• Allocated pods, conditions, and basic performance metrics.
• Cluster health:
• Overview pages within Cluster Settings and monitoring dashboards.

While deep troubleshooting is often done via CLI or external tools, the console provides a high-level snapshot and quick access points.

Creating, Editing, and Deleting Resources

The web console supports several ways to manage resources beyond the guided “Add” flows.

Form-Based Creation and Editing

For many object types, the console offers a form-based interface:

• Guided forms for:
• Deployments, Services, Routes, PVCs, ConfigMaps, Secrets, etc.
• Tooltips and inline validation to help prevent errors.
• Suitable when you prefer not to write YAML directly.

Typical workflow:

1. Navigate to the resource type (e.g. Workloads → Deployments).
2. Click Create or Create Deployment.
3. Fill required fields; optionally adjust advanced options.
4. Save to create the resource.

YAML / JSON Editor

A built-in YAML editor lets you view and modify object manifests:

• Access via Edit YAML or View YAML.
• Features:
• Syntax highlighting.
• Basic structural validation.
• Direct mapping to Kubernetes/OpenShift API fields.
• Common uses:
• Fine-tuning spec fields not exposed in the form.
• Copying configurations for reuse.
• Quick one-off changes.

Changes made here are applied immediately when you save, so it’s recommended to:

• Make small, incremental changes.
• Use version control for critical YAML in your own repositories.

Deletion and Bulk Actions

From list pages:

• Select individual or multiple objects.
• Use the Delete action for cleanup.
• Some lists support bulk operations, but always verify the selected scope (namespace and resource count) before confirming.

Viewing Logs, Events, and Metrics

The console offers integrated observability entry points, focused only on what’s needed for everyday usage.

Pod Logs

From a pod or workload view:

• Select Logs:
• Choose container (if multiple).
• Use Follow to stream logs.
• Filter by keyword, scroll, and download if needed.

Use cases:

• Check startup errors.
• Inspect application-level errors.
• Validate that a new version is behaving as expected.

Events

Events provide context around state changes and issues:

• Accessible:
• From resource details (Events tab).
• From a dedicated Events view scoped to a project or cluster.
• Show:
• What happened, when, and which component reported it.

Useful for:

• Scheduling issues (e.g. “FailedScheduling”).
• Crash loops or image pull problems.
• Permission or configuration errors.

Basic Metrics

From workload or node pages, you typically see:

• CPU and memory usage.
• Pod counts and restart counts.
• Sometimes network or storage metrics, depending on configuration.

Use these to quickly identify:

• Overloaded pods or nodes.
• Resources that may need scaling or optimization.

Using the Console Terminal and Web Shell

There are two main “terminal-like” features in the console:

In-Pod Terminal

From a pod’s detail page:

• Terminal tab:
• Opens an interactive shell inside the container, similar to oc exec -it.
• Limited by:
• Your permissions.
• The image’s available shell (e.g. /bin/sh, /bin/bash).

Use for:

• Inspecting filesystem content.
• Running small diagnostic commands.
• Confirming environment variables and config.

Avoid using it for:

• Long-term manual configuration changes (prefer immutable images and CI/CD).

Web-Based Cluster Shell (if enabled)

Some clusters provide a Web Terminal or Command Line Tools button:

• Gives you an oc/kubectl-like shell inside the browser.
• Authenticated as your user.
• Useful when you:
• Don’t have the CLI installed.
• Need to run quick one-off commands.

User Menu and Self-Service Actions

The user menu (top-right corner) usually includes:

• User profile information:
• Username, groups, and possibly identity provider details.
• Copy login command / tokens:
• Link to download or copy CLI login instructions.
• Sometimes a link to view tokens for the CLI.
• Preferences:
• UI preferences, such as:
• Dark/light theme.
• Table page size.
• Default perspective.
• Help and documentation:
• Links to OpenShift and cluster-specific documentation.
• Sometimes product or provider-specific support links.
• Logout:
• Ends your console session and clears cookies.
• Important when using shared or public machines.

Typical Beginner Workflows in the Web Console

To connect this chapter to hands-on tasks, here are common beginner flows you will likely perform using the console:

• Explore an existing application:
1. Switch to the correct project.
2. Use Developer → Topology to view the app graph.
3. Inspect pod logs and routes for verification.
• Deploy a simple app from Git:
1. In Developer perspective, go to Add.
2. Choose From Git, provide repo URL.
3. Accept defaults for build and deployment, then watch the app appear in Topology.
• Check why a pod is failing:
1. Find the pod in Workloads (Developer or Admin).
2. Open Logs and Events.
3. If needed, open Terminal to inspect in-container state.
• Review cluster health (with admin rights):
1. Switch to Administrator perspective.
2. Check Cluster Settings and Nodes.
3. Briefly review any warnings or degraded components.

These workflows build familiarity with the console and prepare you for more advanced tasks covered in other chapters.