OpenShift for Beginners!

Learn OpenShift Basics & Fundamentals(2024 Guide):

(OpenShift for Beginners Guide) & Get your OpenShift Fundamentals Strong!

Learn OpenShift from Beginners point of view.

Are you one of these?

• I am new to OpenShift or know only basics about Containers and I want to learn OpenShift Fundamentals.
• I know OpenShift but only basic about OpenShift and I want to Learn OpenShift Fundamentals clearly.
• I am working as an OpenShift Admin want to learn OpenShift Basics thoroughly. You may also read OpenShift Advanced Concepts if you want to jump to learn Advanced Concepts.

Learning Topics:

1. What is OpenShift?
2. What is OpenShift Architecture?
3. What is Red Hat OpenShift CoreOS?
4. Read OpenShift Learning Roadmap
5. OpenShift Components
6. Key differences between OpenShift and Kubernetes
7. What is OpenShift API Server
8. What is CR, MCP, MC, Storage Class, PV and PVC
9. What is Podman, CRI-o
10. What is Namespace and projects.
11. What are the key tasks expected from an OpenShift Administrator
12. Top 100 OpenShift commands list you can try.
13. OpenShift Hands on Labs with CRC
14. Read about OpenShift Interview Questions and Preparation
15. Read about OpenShift Networking
16. Know the potential OpenShift Customers who are using OpenShift and Hiring.
17. Read about OpenShift Health Check Notes
18. Read about UPI and IPI Differences

Getting started: OpenShift v4 for Beginner Learners

It is very important to know OpenShift Bascis clearly. We know getting started with OpenShift is hard and we made it easy for you to Learn for Free!

You may download all the available OpenShift Free PDF files

OpenShift is a powerful container management platform that has gained significant popularity in the world of containerization and microservices.

If you’re just getting started with containers and OpenShift, you’re in the right place. In this article, we’ll provide a beginner-friendly introduction to OpenShift v4 and explain its core concepts.

What is OpenShift?

You may read brief about What is OpenShift?

OpenShift is an enterprise Kubernetes platform that simplifies the deployment, scaling, and management of containerized applications.

It is developed and maintained by Red Hat, a prominent name in the world of open-source software.

OpenShift is designed to streamline the development and operation of container-based applications, making it easier for teams to adopt modern software development practices.

Containers and Kubernetes

https://kubernetes.io/

Before diving into OpenShift, it’s crucial to understand the basic concepts of containers and Kubernetes.

Containers are lightweight, standalone executable packages that include everything needed to run a piece of software, including the code, runtime, system tools, libraries, and settings.

Containers offer a consistent environment, making it easier to develop, test, and deploy applications across various environments.

Kubernetes, on the other hand, is an open-source container orchestration platform.

It automates the deployment, scaling, and management of containerized applications. Kubernetes uses a declarative approach, where you specify the desired state of your applications, and it takes care of maintaining that state.

OpenShift and Kubernetes Relationship:

Read about OpenShift Kubernetes Differences.

OpenShift builds upon Kubernetes, adding extra features and simplifications.

Think of OpenShift as a Kubernetes distribution tailored for enterprise use.

OpenShift includes a streamlined developer experience, security enhancements, and integrated tools for continuous integration and continuous delivery (CI/CD).

It also includes a web-based dashboard for easier management.

Key Features of OpenShift v4

Get your OpenShift Free Course from YouTube (*Free signup required).

1. Developer-Friendly: OpenShift offers a developer-friendly experience with tools like Source-to-Image (S2I) and the OpenShift Web Console. S2I simplifies the process of building container images from source code, making it easier for developers to package their applications in containers.

2. Self-Service Platform: OpenShift enables self-service for developers, allowing them to deploy applications independently without needing deep knowledge of the underlying infrastructure.

This empowers developers to be more productive and iterate faster.

3. Security: Security is a top priority in OpenShift. It provides features like role-based access control (RBAC), container runtime security, and image scanning to ensure that your applications are running in a secure environment.

4. Scaling and High Availability: OpenShift makes it simple to scale applications up or down based on demand, ensuring high availability and efficient resource usage.

5. Operator Framework: OpenShift introduces the Operator Framework, which allows you to automate the management of applications and services. Operators extend the Kubernetes API to manage complex, stateful applications.

6. Container Registry: OpenShift includes a built-in container registry where you can store and manage your container images, making it easier to manage the container lifecycle.

7. CI/CD Integration: OpenShift integrates with popular CI/CD tools like Jenkins, enabling you to automate the delivery pipeline from source code to production.

Read about OpenShift Case Study

Understand the basics of OpenShift:

To get started with OpenShift, consider the following steps:

1. Learn Kubernetes Basics: Before diving into OpenShift, ensure you have a solid understanding of Kubernetes, as OpenShift builds on top of it.

2. Install OpenShift: You can set up OpenShift on your local machine using Minishift for development and testing. For production use, you can install OpenShift on a cloud provider or on-premises infrastructure.

3. Explore the OpenShift Web Console: The web console is a user-friendly interface for managing your OpenShift cluster. Take some time to navigate through it and familiarize yourself with its features.

4. Try Deploying Applications: Use OpenShift to deploy simple applications, gradually increasing the complexity as you become more comfortable with the platform.

5. Learn about Operators: Operators are a powerful concept in OpenShift. Understanding how they work can help you automate application management.

OpenShift can be a game-changer for organizations looking to embrace containerization and microservices.

For beginners, it may seem a bit overwhelming at first, but with patience and practice, you can harness its capabilities to streamline your development and deployment processes.

As you progress in your containerization journey, you’ll find OpenShift to be a valuable tool in your toolbox, enabling you to build and manage modern, cloud-native applications efficiently.

OpenShift Architecture:

Very simple explanation of the OpenShift v4 architecture:

1. Nodes: OpenShift clusters consist of nodes, which are individual servers or virtual machines that run containerized applications. Nodes can be grouped into availability zones for increased resilience.

2. Master Node: The master node is the control plane of the OpenShift cluster. It manages and oversees the cluster’s operations, including scheduling applications, scaling, and maintaining the desired state. The master node runs several components, such as the API server, controller manager, and scheduler.

3. API Server: The API server is a key component that exposes the OpenShift API, allowing users and other components to communicate with the cluster. It receives commands from users and processes them, initiating actions within the cluster.

4. Controller Manager: This component watches for changes in the cluster’s desired state (specified by users) and takes actions to move the current state towards the desired state. It manages various controllers responsible for tasks like scaling, replication, and endpoints.

5. Scheduler: The scheduler is responsible for assigning workloads to specific nodes based on resource availability, constraints, and policies. It ensures that applications are deployed and distributed efficiently across the cluster.

6. etcd: OpenShift uses etcd as its distributed key-value store to store configuration data and the cluster’s state. It provides a reliable and consistent way to manage and store data across the cluster.

7. Worker Nodes: Worker nodes are where the actual containerized applications run. Each worker node hosts multiple pods, which are the smallest deployable units in OpenShift. Pods contain one or more containers that share the same network namespace and storage.

8. Kubelet: The Kubelet is an agent that runs on each worker node and communicates with the master node. It is responsible for starting, stopping, and maintaining containers on the node, as well as reporting the node’s status back to the master.

9. Container Runtime: OpenShift supports various container runtimes, such as Docker or containerd, which are responsible for running containers and managing their lifecycle.

10. Operators: OpenShift introduces the concept of operators, which are a method of packaging, deploying, and managing a Kubernetes application. They automate tasks related to application lifecycle management, making it easier to deploy and manage complex applications.

In summary, OpenShift v4 architecture includes master nodes for control, worker nodes for running applications, and a set of components working together to automate the deployment and management of containerized applications in a Kubernetes environment.

Read about OpenShift Health Check activities

What is Red Hat CoreOS?

Red Hat OpenShift CoreOS is an operating system designed specifically for running containerized applications within the Red Hat OpenShift Container Platform.

It is a minimalistic, lightweight operating system that focuses on providing a secure and efficient environment for container orchestration.

Reference: Red Hat CoreOS

Key points about CoreOS:

1. Containerized Applications: OpenShift CoreOS is tailored for hosting applications packaged in containers.

Containers encapsulate an application and its dependencies, ensuring consistency across different environments.

2. Red Hat OpenShift Container Platform: OpenShift CoreOS is part of the broader Red Hat OpenShift Container Platform, a Kubernetes-based container orchestration platform.

It simplifies the deployment, scaling, and management of containerized applications.

3. Minimalistic Design: OpenShift CoreOS follows a minimalistic design philosophy, providing only the essential components needed for running containers.

This streamlined approach enhances security, reliability, and performance.

4. Automatic Updates: One notable feature of OpenShift CoreOS is its ability to automatically update itself without manual intervention.

This ensures that the operating system remains secure and up-to-date with the latest patches and improvements.

5. Integrated with OpenShift: OpenShift CoreOS seamlessly integrates with the larger OpenShift ecosystem, facilitating a unified and consistent experience for deploying and managing containerized workloads.

Overall, Red Hat OpenShift CoreOS is a specialized operating system optimized for container orchestration, particularly within the context of the Red Hat OpenShift Container Platform.

It aims to provide a secure, lightweight, and self-updating foundation for running containerized applications at scale.

Read about OpenShift Troubleshooting Notes.

Fundamental OpenShift components:

1. Nodes: These are the individual machines (physical or virtual) that form the underlying infrastructure of an OpenShift cluster.

Each node runs an operating system and hosts containers. Nodes are managed by the OpenShift control plane.

2. Control Plane: The control plane is the brains of the OpenShift cluster. It manages and monitors all activities within the cluster.

Key components of the control plane include:

   – API Server: Acts as the front end for the control plane. It validates and processes requests, enforcing policies and coordinating actions.
   – Controller Manager: Maintains the desired state of the cluster by controlling various controllers (e.g., replication controllers, endpoint controllers).
   – Scheduler: Assigns work to nodes based on resource availability and other constraints.

3. Etcd: A distributed key-value store that stores the configuration data of the entire cluster. It serves as the cluster’s source of truth, ensuring consistency and reliability.

4. Operators: Operators are a method of packaging, deploying, and managing OpenShift applications. They automate common operational tasks, making it easier to manage complex, stateful applications.

5. Kubernetes: OpenShift builds on Kubernetes, which is an open-source container orchestration platform. Kubernetes provides the basic framework for deploying, scaling, and managing containerized applications.

6. Builds and Image Streams: OpenShift includes features for building and deploying container images. Builds define how to transform source code into a runnable image, while Image Streams allow for versioning and organizing container images.

7. Projects and Namespaces: Projects (formerly known as projects in OpenShift v3.x) are a way to organize and control access to resources within an OpenShift cluster. They provide a namespace for multiple users to collaborate while maintaining isolation.

8. Routes: Routes expose services to the external network, making applications accessible from outside the cluster. They provide a way to access applications without exposing the internal details of the cluster.

These are just some of the key components that make up an OpenShift cluster. The platform is designed to streamline the deployment and management of containerized applications, providing a scalable and flexible infrastructure for modern, cloud-native development.

Key differences between OpenShift and Kubernetes:

You differences between OpenShift and Kubernetes

1. Chef’s Knife (Kubernetes)
   – Flexibility Kubernetes provides a powerful and flexible foundation for container orchestration. It’s like a sharp chef’s knife that can handle a variety of tasks in different culinary scenarios.
   – Community-Driven Just like a popular knife brand, Kubernetes is widely adopted and has a large community. It’s a go-to choice for those who want flexibility and customization in their container management.

2. Full-Service Kitchen (OpenShift)
   – End-to-End Solution OpenShift extends Kubernetes by adding more features and components. It’s like a full-service kitchen with chefs, assistants, and a well-organized workflow. OpenShift comes with additional tools and services that make it easier to manage the entire containerization process.
   – Integrated Tools OpenShift provides built-in tools for continuous integration, monitoring, and security. It’s like having kitchen assistants specialized in different tasks, ensuring a smoother and more comprehensive experience.

3. Recipe Book (Operators)
   – Automation OpenShift introduces the concept of Operators, which are like recipes in a book. Operators automate routine tasks and manage the lifecycle of applications. It’s as if the kitchen itself follows the recipes without constant chef intervention.

   – Simplified Operations With Operators, OpenShift simplifies complex operational tasks, making it easier for developers and administrators to handle applications throughout their lifecycle.

4. Security and Compliance (OpenShift)
   – Built-In Security Measures OpenShift puts an extra layer of focus on security, like having a kitchen with advanced safety features. It includes built-in security measures and compliance tools, making it a preferred choice for organizations with stringent security requirements.

What is OpenShift API Server:

The OpenShift API Server is a fundamental component of the OpenShift Container Platform, and it plays a crucial role in the interaction between different parts of the platform.

Here’s a simple explanation:

1. API Server Functionality
   – Endpoint for Communication The OpenShift API Server acts as the communication hub for various components within the OpenShift cluster.

It provides a central endpoint for users, administrators, and internal components to interact with the OpenShift system.

   – Requests and Responses When users or internal components want to perform actions within the OpenShift cluster, they send requests to the API Server.

These requests can include operations like deploying applications, scaling services, or updating configurations. The API Server processes these requests and sends back appropriate responses.

2. Interaction with Control Plane
   – Control Plane Component The API Server is a key component of the OpenShift Control Plane.

The Control Plane is responsible for managing and controlling the state of the cluster, ensuring that the actual state matches the desired state.

   – Enforcing Policies The API Server enforces policies and permissions, ensuring that only authorized entities can make changes to the cluster.

It validates requests, checks permissions, and ensures that the cluster adheres to specified configurations and security measures.

3. RESTful API
   – RESTful Interface The API Server exposes a RESTful API, which means it follows the principles of Representational State Transfer (REST).

This design makes it accessible and interoperable, allowing users and external tools to interact with the OpenShift cluster using standard HTTP methods.

   – Resource Endpoints In OpenShift, various resources, such as pods, services, and deployments, are represented as endpoints in the API.

Users interact with these endpoints to manage and monitor the state of their applications and the overall cluster.

What is CRI-o?

CRI-O (Container Runtime Interface – Open Container Initiative) is a lightweight container runtime specifically designed for Kubernetes.

In the context of OpenShift, which is built on top of Kubernetes, CRI-O serves as the container runtime responsible for running containers within the OpenShift cluster.

Here’s a simple explanation:

1. Container Runtime Interface (CRI)
   – Standardized Interface CRI is a standardized interface between Kubernetes and container runtimes.

It allows Kubernetes to be container runtime-agnostic, enabling the use of different runtimes while maintaining compatibility.

2. Lightweight Container Runtime (CRI-O)
   – Focused on Kubernetes CRI-O is a container runtime implementation that focuses solely on providing the functionalities required by Kubernetes.

It is lightweight and designed to do the minimum necessary work to run containers efficiently within a Kubernetes environment.

   – Container Lifecycle Management CRI-O handles tasks related to the container lifecycle, such as pulling container images, creating and running containers, and managing container storage.

It doesn’t include additional features not directly needed by Kubernetes.

3. Integration with OpenShift
   – OpenShift Container Platform In OpenShift, CRI-O is often used as the container runtime to execute and manage containers.

It integrates seamlessly with the broader OpenShift ecosystem, including features like orchestration, networking, and security.

   – Optimized for Kubernetes Workloads CRI-O is optimized for running Kubernetes workloads, providing a focused and efficient runtime for containerized applications orchestrated by Kubernetes and, consequently, OpenShift.

In summary, CRI-O in OpenShift is the container runtime responsible for executing and managing containers within the context of a Kubernetes-based environment.

It adheres to the CRI standard, providing a minimal and Kubernetes-focused runtime that aligns with the design principles of simplicity and efficiency.

In essence, the OpenShift API Server is the gateway through which users and components interact with the OpenShift platform.

It serves as a centralized and secure interface, processing requests, enforcing policies, and facilitating communication between different parts of the OpenShift cluster.

About Projects and Namespace in the context of OpenShift v4:

1. Projects in OpenShift
   – Think of a Project in OpenShift like a big, labeled box on your computer where you keep all the stuff related to a specific task or goal.

   – It’s like having a project folder on your desktop, but way cooler.

OpenShift Projects help you organize and manage different applications, resources, and teams neatly in their designated boxes, making sure everything stays in order.

2. Namespace in OpenShift v4
   – Imagine a Namespace as a magical barrier that separates and protects different parts of your computer world.

It’s like having invisible walls around specific areas to keep things organized and prevent any accidental mix-ups.

   – In OpenShift v4, a Namespace is a way to create isolated spaces within a Project.

Each Namespace is like a mini-world where different applications or components can live independently.

It’s like having separate rooms for different activities, making sure everyone plays well without interference.

So, in simple terms, Projects are like labeled containers holding everything related to a particular goal, and Namespaces are like invisible dividers within those containers, ensuring each part has its own space to thrive.

OpenShift Terms:

OpenShift is a container orchestration platform that extends the capabilities of Kubernetes. In OpenShift v4, several concepts and resources are used to manage containerized applications. Here’s a brief explanation of the terms you mentioned:

CR (Custom Resource): In OpenShift, Custom Resources are extensions of the Kubernetes API. They allow you to define and use custom objects in your cluster. Custom Resources are often used to manage and deploy applications in a more customized way.

MCP (Machine Config Pool): This is a feature in OpenShift that manages machine configurations in a cluster. It allows you to define configurations for machines in a pool, which can then be used to provision and configure nodes in your OpenShift cluster.

MC (Machine Config): Machine Configs are configurations that define the desired state of a machine in an OpenShift cluster. They include information about the operating system, kernel settings, container runtime configuration, and more.

PV (Persistent Volume): In Kubernetes and OpenShift, a Persistent Volume is a piece of storage that has been provisioned by an administrator. It is a resource in the cluster, and it can be mounted into a Pod as a volume.

PVC (Persistent Volume Claim): A Persistent Volume Claim is a request for storage by a user. It is used by a Pod to request a specific amount of storage. When a Pod needs access to storage, it makes a request via a PVC, and the system provisions a PV to fulfill that claim.

Storage Class: Storage Classes are used to define different classes of storage in a cluster, specifying the type of provisioner, parameters, and reclaim policies. It allows users to request dynamic storage allocation without having to manually provision storage.

Pod: In Kubernetes and OpenShift, a Pod is the smallest deployable unit. It represents a single instance of a running process in a cluster and can contain one or more containers.

Replica: In the context of OpenShift and Kubernetes, a Replica refers to the number of identical Pods that should be running. Replication Controllers or Replica Sets manage the desired number of replicas and ensure that the specified number of Pods is always running.

YAML: YAML (YAML Ain’t Markup Language) is a human-readable data serialization format. In the context of OpenShift and Kubernetes, YAML files are commonly used to define the configuration of resources like Pods, Services, Deployments, and more.

OpenShift RBAC:

OpenShift v4 uses Role-Based Access Control (RBAC) to manage and control access to resources within the platform. RBAC allows administrators to define roles with specific permissions and assign those roles to users or groups. Here’s a simple explanation of how OpenShift v4 RBAC works:

Roles and RoleBindings:

Roles: These are sets of permissions defining what actions users or groups are allowed to perform on specific resources within OpenShift, such as creating pods or modifying services.

RoleBindings: These associate users or groups with specific roles, specifying which users or groups have which permissions.
ClusterRoles and ClusterRoleBindings:

Similar to Roles and RoleBindings, but operate at the cluster level instead of the project (namespace) level. ClusterRoles define permissions across the entire OpenShift cluster, and ClusterRoleBindings associate these roles with users or groups.
Subjects:

In RBAC, a “subject” is an entity (user or group) to which you grant access. Subjects can be users, groups, or service accounts.

Resources:

Resources are the OpenShift objects that RBAC controls access to, such as pods, services, routes, etc.

In OpenShift, services and routes are important concepts that help manage and expose applications within the platform. Let me explain each term:

Read about OpenShift Best Practices.

OpenShift Service:

In Kubernetes, which is the underlying orchestration platform for OpenShift, a service is an abstraction that defines a logical set of pods and a policy by which to access them.

The service provides a stable IP address and DNS name by which external components can access the pods, abstracting away the details of the individual pods’ IP addresses.

In OpenShift, a service can be created at the project (namespace) level, and it allows different parts of your application to communicate with each other.

For example, if you have a frontend and a backend, a service can be created for the backend, and the frontend can communicate with the backend through this service.

Here’s a basic example of a service definition in OpenShift:

yaml
Copy code
apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: my-app
  ports:
    – protocol: TCP
      port: 80
      targetPort: 8080
In this example, the service named “my-service” selects pods labeled with app: my-app and exposes them on port 80 within the cluster.

Read about Frequently Asked OpenShift v4 Questions

What is OpenShift Routes:

A route in OpenShift is an object that exposes a service at a host name, like www.example.com, so that external users can access your application.

It acts as a bridge between the OpenShift cluster and external clients, providing a way to access services from outside the cluster.

A route can be configured with various options, including edge termination (SSL termination at the router), re-encryption (SSL pass-through), and passthrough (TCP traffic). It allows you to expose your services securely over the internet.

Here’s a basic example of a route definition in OpenShift:

yaml
Copy code
apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: my-route
spec:
  to:
    kind: Service
    name: my-service
  tls:
    termination: edge
In this example, the route named “my-route” directs traffic to the service named “my-service” and terminates SSL at the router (edge termination).

In summary, services provide internal network abstraction within the OpenShift cluster, while routes enable external access to those services from the internet.

What are the key tasks expected from OpenShift Administrator:

As an OpenShift v4 administrator, you would be responsible for managing and maintaining the OpenShift Container Platform, ensuring its availability, performance, and security. Here are some day-to-day tasks you might expect:

Cluster Installation and Configuration:
Deploying new OpenShift clusters.
Configuring cluster settings based on organizational requirements.

User and Access Management:
Creating and managing user accounts.
Assigning roles and permissions to users and groups.
Implementing authentication and authorization policies.

Cluster Monitoring and Logging:
Monitoring cluster health and performance.
Analyzing logs to identify and troubleshoot issues.
Setting up alerts for critical events.

Resource Management:
Allocating and managing computing resources for applications.
Scaling applications to meet changing demand.
Implementing resource quotas and limits.

Application Deployment and Lifecycle Management:
Deploying applications onto the OpenShift platform.
Managing application updates and rollbacks.
Troubleshooting application-related issues.

Networking Configuration:

Configuring and managing network policies.
Implementing and managing service discovery.
Configuring load balancing and routing.

Security and Compliance:
Implementing security measures for the OpenShift platform.
Ensuring compliance with security policies and best practices.
Regularly updating and patching the OpenShift platform.

Backup and Disaster Recovery:
Implementing backup strategies for OpenShift resources.
Planning and testing disaster recovery procedures.

Integration with External Systems:
Integrating OpenShift with external systems and services.
Managing integrations with identity providers, storage systems, and CI/CD pipelines.

Documentation and Training:
Keeping documentation up to date.
Providing training and support to other team members and end-users.

Upgrades and Patching:
Planning and executing platform upgrades.
Applying patches and updates to the OpenShift environment.

Troubleshooting and Support:
Identifying and resolving issues in the OpenShift platform.
Providing support to development teams and end-users.

Performance Optimization:
Analyzing and optimizing the performance of the OpenShift environment.
Implementing improvements based on performance metrics.

Collaboration:
Collaborating with development teams, architects, and other stakeholders.
Participating in meetings and discussions related to platform architecture and improvements.

Stay Informed:
Keeping up to date with the latest OpenShift releases, updates, and best practices.
Participating in the OpenShift community and forums.
These tasks may vary based on the specific requirements and size of your organization, but they provide a general overview of the responsibilities of an OpenShift v4 administrator.

Yay! 🎉 You made it to the end of the article!