6 Accessing and Using OpenShift

How Users Interact with an OpenShift Cluster

From a user’s perspective, “using OpenShift” means connecting to a cluster, authenticating, and working with applications and resources through tools that OpenShift provides. At a high level there are two main entry points:

• A web-based graphical user interface (the web console)
• A command-line interface (oc)

On top of this, OpenShift organizes work into logical containers called projects/namespaces and enforces limits through resource quotas and limits. This chapter focuses on how you, as a user, actually access and operate within an OpenShift cluster at a practical level, without yet going into the deep details that are covered in later chapters.

In this chapter you will:

• Learn the main ways to connect to an OpenShift cluster
• Understand what a “project” is in daily use
• Learn how resource quotas and limits affect your work
• Get a sense of common day-to-day workflows

Ways to Access an OpenShift Cluster

OpenShift is typically exposed as one or more HTTPS endpoints:

• Cluster API endpoint (used by oc and tools)
• Web console URL
• Service/application URLs (routes/ingress, discussed elsewhere)

In practice, your platform or cluster administrator will provide:

• The web console URL (for example, https://console-openshift-console.apps.example.com)
• One or more methods to log in (e.g., corporate SSO, username/password)
• Optionally, an oc login command that already includes the API URL

You usually:

1. Open the web console in your browser for a visual workflow.
2. Use oc on your workstation, in a terminal or integrated into scripts/CI.

Typical Authentication Flow

Although details of authentication and authorization are covered in their own chapter, the basic experience for an end user looks like:

• Web console
• Navigate to the console URL in a browser.
• You are redirected to an identity provider (IdP) such as:
• Corporate SSO (SAML, OAuth, OIDC)
• GitHub / GitLab / other OAuth provider
• Local user/password if configured
• After successful authentication, you land in the console main page.
• CLI (oc)
• Install oc for your platform (binaries are usually downloadable from the cluster console or vendor site).
• Run oc login with:
• The cluster API URL
• Either username/password, token, or SSO flow depending on setup.
• Once logged in, oc stores a context in a local config file (usually ~/.kube/config), so you don’t have to re-enter everything each time.

Your identity and group membership then determine what projects and resources you can see and modify.

Web Console: Graphical Access

The OpenShift web console provides a browser-based way to interact with the cluster. It is designed for both developers and administrators, with different views and levels of detail.

Main Areas of the Web Console

While the exact layout can change slightly between versions and themes, common sections include:

• Perspective selector
• Often you can switch between a “Developer” and “Administrator” perspective:
• Developer: application-centric views, visual topology, builds, pipelines.
• Administrator: cluster-wide views, nodes, operators, storage, networking.
• The available perspectives depend on your permissions.
• Project/namespace selector
• A dropdown or selector lets you choose the active project (namespace) you are working in.
• Many views and lists will show only resources in the currently selected project.
• Navigation sidebar
• Provides access to:
• Workloads (Deployments, StatefulSets, etc.)
• Builds and image streams (in OpenShift-specific workflows)
• Networking (Services, Routes)
• Storage (PVCs, etc.)
• Configurations and secrets
• Observability (logs, metrics, events)
• User settings and access tokens

Common Developer Workflows in the Console

Some typical actions that developers perform through the web console:

• Browsing and inspecting applications
• Use the topology view or workloads lists to see running applications, pods, and their status.
• Drill down into pod details, environment variables, logs, and events.
• Deploying or modifying applications
• Use form-based wizards (“Add” or “+Add” flows) to:
• Deploy an image from a container registry.
• Use Source-to-Image (S2I) to build and deploy from source.
• Import from Git repositories to create CI/CD pipelines.
• Edit settings like replica counts, environment variables, or resource limits in a guided UI.
• Viewing logs and basic troubleshooting
• View real-time pod logs directly in the browser.
• Check recent events for error messages or scheduling problems.
• Restart or redeploy workloads through the UI.
• Managing configurations
• Create and edit ConfigMaps and Secrets via forms or raw YAML.
• Attach configuration to workloads (e.g., environment variables, volumes).

The console is particularly useful for learning, for exploratory debugging, and for users who prefer a visual interface over raw YAML or CLI commands.

Administrator-Oriented Views

Even if you’re not a cluster admin, it helps to know that the console’s admin perspective exposes:

• Cluster-level status and health
• Node lists and details
• Operator management
• Storage backends and networking settings

Your role determines whether you can see or change these settings. From an “access and use” standpoint, be aware that some menu items may be visible but disabled, or completely hidden, depending on your authorization.

CLI Access with `oc`

The oc tool is the primary command-line interface for OpenShift. It extends the standard Kubernetes kubectl with OpenShift-specific functionality (for example, working with projects, routes, and certain OpenShift APIs).

Installing and Configuring `oc`

In a typical setup:

1. Download oc:
• The web console often has a “Command Line Tools” link with platform-specific binaries.
2. Place oc on your system PATH.
3. Verify installation with:
• oc version
4. Authenticate:
• oc login https://api.example.com:6443
• Provide credentials or token as instructed.

The oc configuration (including cluster URL, user, and active project) is stored locally, allowing you to manage multiple clusters and contexts.

Basic Usage Patterns

Even before diving into specific resource commands, there are a few patterns that you will use everywhere:

• Resource listing and inspection
• oc get to list resources
• oc describe for detailed inspection
• oc logs for container logs
• Editing and applying configuration
• oc apply -f to apply declarative configurations (YAML/JSON)
• oc create -f to create from a file
• oc delete to remove resources
• oc edit to open a resource in your editor

As an adaptation for OpenShift-specific conventions, you’ll also see commands such as:

• oc new-project to create a project
• oc new-app to create an application from source or an image
• oc status for a human-friendly summary of what’s in a project

Later chapters will cover specific resource types and deployment models in more depth. Here, the key is to understand that oc is your scripted and automation-friendly way to do anything you can do in the console, and often more.

Working with Multiple Contexts

oc can manage multiple clusters and users through “contexts” in your configuration file. Common operations include:

• Listing contexts to see what’s available:
• oc config get-contexts
• Switching the active context:
• oc config use-context <name>
• Verifying which cluster and user you’re currently using:
• oc whoami
• oc whoami --show-server

This is especially important if you work in different environments (e.g., development, staging, production) or with multiple OpenShift clusters.

Projects and Namespaces in Daily Use

OpenShift organizes workloads and resources into objects called projects, which map to Kubernetes namespaces but add some OpenShift-specific metadata and workflows. From a user’s perspective, the “project” is the main scope you operate in day to day.

What a Project Represents for a User

A project is typically used to group:

• One or more applications or services that belong together
• A team, environment, or tenant boundary (e.g., team-a-dev, app1-prod)
• Policies such as:
• Who can access these resources
• What quotas and limits apply
• What default behaviors are in effect

In most real environments, projects are created to reflect both organizational structure and environment lifecycle (development, test, production, etc.).

Project Lifecycle from a User Perspective

Depending on your permissions and organizational policies:

• You may be able to create projects yourself using:
• Web console: “Create Project” or similar option.
• CLI: oc new-project <name> or oc create ns <name> plus project metadata.
• Or projects may be provisioned for you by a platform team using automation or self-service portals.

Once a project exists, you typically:

• Select it in the web console as your active project.
• Use oc project <name> to switch your CLI context to that project.

In both interfaces, your view of resources (pods, services, deployments, etc.) is scoped to the selected project by default.

Access Control Around Projects

Authorization is covered separately, but from a usage perspective:

• Your ability to:
• List a project
• Read resources in it
• Create or modify resources
• Delete the project
• Is governed by role assignments and policies.

Practically, this means:

• You may see some projects as “read-only” (you can inspect but not change).
• You may not see certain projects at all if you have no access.
• Changes to your membership in groups or roles can instantly change which projects are available to you.

If something you expect is not visible, checking your active project (and your access rights) is often the first step.

Resource Quotas and Limits: How They Affect Your Work

OpenShift uses resource quotas and limits to ensure fair use of shared cluster capacity and to prevent misbehaving workloads from consuming excessive resources. As a user, you don’t typically define cluster-wide policies, but you must operate within them.

Resource Quotas at Project Level

A resource quota is a set of hard caps applied to a project. Examples include limits on:

• Number of pods
• Total CPU and memory requested by all pods
• Number of persistent volume claims
• Number of services, routes, or other objects

For instance, a project could have:

• Max 50 pods
• Max total memory requests of 32 GiB

From your perspective:

• If you try to create or scale workloads beyond these quotas, the operation fails.
• Error messages will usually indicate which quota was exceeded.
• You might need to:
• Reduce resource requests/limits for existing workloads.
• Delete unused resources.
• Request a quota adjustment from administrators.

You can view quota definitions in your project via both console and CLI (e.g., oc get quota).

Limits and LimitRanges

Limit ranges define defaults and per-container or per-pod boundaries for compute resources such as CPU and memory. They interact with Kubernetes resource requests and limits (covered in more detail elsewhere), but at a high level:

• For each container, you often set:
• A request: what the container is guaranteed.
• A limit: the maximum it can use.

A limit range can define, for example:

• Default request/limit values if you don’t specify them.
• Maximum allowed CPU or memory per container.
• Minimum required resources to prevent tiny, underprovisioned pods.

As a user, you will notice:

• If you do not specify requests/limits, the platform may automatically apply defaults.
• If you specify values outside the allowed range (too large or too small), your pod will be rejected.
• Changing resource requirements for a pod can require updating the associated workload definition (e.g., Deployment) and restarting the pods.

Understanding your project’s limit ranges helps you choose sensible resource values for your applications the first time, avoiding deployment errors.

Day-to-Day Workflow Examples

Putting these pieces together, a typical developer or user workflow on OpenShift might look like:

1. Log in
• Open the web console and authenticate via SSO.
• Or open a terminal and run oc login.
2. Select a project
• In the console, choose the appropriate project from the dropdown.
• In the CLI, run oc project my-team-dev.
3. Inspect existing resources
• Check what’s already running:
• Console: use the topology or workloads view.
• CLI: oc get pods, oc get deployments, etc.
4. Deploy or update an application
• Use a console wizard (e.g., “Deploy image from registry”).
• Or apply configuration via CLI:
• oc apply -f deployment.yaml
5. Monitor and debug
• View logs in the console or with oc logs.
• Watch status with oc get pods -w.
• Check events for errors about quota or limits.
6. Adjust resources within quotas
• If a deployment fails due to quotas:
• Reduce replica count or CPU/memory requests.
• Remove unused resources.
• Coordinate with admins if more capacity is needed.
7. Repeat for different environments
• Switch projects (e.g., from my-app-dev to my-app-stage) and repeat the same pattern.

Over time, you may automate many of these steps via CI/CD pipelines and GitOps tools, but the underlying access methods and constraints remain the same.

Practical Tips for New Users

• Always verify which project you are currently in, especially before creating or deleting resources.
• Learn how to:
• Find your cluster’s oc download page.
• Use oc login and oc whoami confidently.
• When deployments fail unexpectedly, check:
• Quota usage (oc get quota)
• Limit ranges (oc get limitrange)
• Events (oc get events or the console’s events view)
• For exploratory work, the web console is often more approachable.
  For repeatable or automated tasks, prefer oc and declarative YAML files.
• Keep your local oc version reasonably in sync with the cluster version to avoid subtle incompatibilities.

These foundations—web console, oc CLI, projects, quotas, and limits—form the basic toolkit you will use in all later chapters as you build, deploy, secure, and operate applications on OpenShift.