Red Hat Certified OpenShift Administrator exam (EX280) Overview and Preparation.
Sections:
- Red Hat OpenShift Platform Architecture
- Red Hat OpenShift Editions
- Red Hat OpenShift Installation
- Red Hat Openshift Networking
- Red Hat Certified OpenShift Administrator exam
The following diagram shows the high-level stack that comprises a Red Hat OpenShift Container Platform (RHOCP) deployment.
The RHOCP architecture begins with the Red Hat CoreOS or Red Hat Enterprise Linux operating systems. By using machines that run one of these operating systems, RHOCP provides the necessary cluster features to deliver the container platform. Additional automated operations continue to build on Kubernetes to deliver an enterprise-class container environment.
Cluster services, such as metrics, a container image registry, and event logging deliver additional features for the environment. Container images are the collection of defined containers that are available within the cluster for deployment. Application services, such as service mesh and other middleware, are also available within the cluster. Additionally, the cluster contains developer services to aid the ongoing application development and platform administration.
The full stack of an RHOCP cluster delivers not only a container runtime environment, but also the additional required tools in enterprise-class deployments to perform the full set of tasks that a modern business application platform requires.
- Description: This is the foundational layer of the stack, providing the underlying operating system on which the OpenShift Container Platform runs. It includes:
- RHEL: A robust and secure Linux distribution tailored for enterprise use.
- RHEL CoreOS: A lightweight, container-optimized version of RHEL specifically designed to run containerized applications efficiently.
- Role: Provides the necessary infrastructure and environment for deploying and managing containers and orchestrating them with Kubernetes.
- Description: This layer represents the core Kubernetes functionality enhanced for enterprise use. Kubernetes is an open-source platform designed to automate deploying, scaling, and operating application containers.
- Role: Provides container orchestration capabilities, including scheduling, scaling, and managing containerized applications. It ensures high availability, fault tolerance, and efficient resource utilization within the cluster.
- Description: This layer includes tools and features for automating the deployment, management, monitoring, and scaling of applications within the OpenShift environment.
- Role: Facilitates the operational tasks associated with managing a containerized environment. It ensures smooth and efficient management of the infrastructure, reducing manual intervention and increasing reliability and performance.
- Components:
- Metrics: Collects and stores metrics data from the cluster to monitor performance and resource utilization.
- Chargeback: Provides mechanisms for tracking resource usage and cost allocation for billing purposes.
- Registry: A container image registry to store and manage container images used for deployments within the cluster.
- Logging: Captures and stores logs from applications and system components for troubleshooting and analysis.
- Role: Provides essential services that enhance the functionality and manageability of the cluster, ensuring it meets enterprise requirements.
- Components:
- Middleware: Provides essential software components like application servers, messaging systems, and databases that support application development and deployment.
- Service Mesh: Facilitates the management, security, and observability of microservices within the cluster.
- Serverless and Functions: Supports serverless computing and functions as a service (FaaS) for building scalable and event-driven applications.
- ISV (Independent Software Vendor): Integration with third-party applications and services.
- Role: Enhances the capabilities of the platform by offering additional services that support the development, deployment, and management of applications.
- Components:
- Dev Tools: Includes integrated development environments (IDEs), command-line tools, and other utilities to support developers.
- Automated Builds: Automates the process of building container images from application source code.
- CI/CD: Continuous Integration and Continuous Deployment tools to automate the testing and deployment of applications.
- IDE: Integrated Development Environment for easier coding and debugging.
- Role: Provides tools and services that streamline the development process, improving developer productivity and facilitating continuous delivery and integration practices.
Openshift, as a container Platform, includes many critical components for monitoring, automation and scaling. Take a look at the refernce image below for more details
After choosing RedHat Openshift as the container orchastrator for your Business Application, the next step is chosing the edition you will implement. Here is a list of alternatives as of Openshift 4.14
- Deploys a cluster on a local computer for testing and exploration.
- Suitable for initial exploration of OpenShift.
- Not intended for production environments.
- Provides 30 days of free access to a shared OpenShift cluster.
- Allows testing and exploration of OpenShift features.
- Not intended for production use.
- Quick access to OpenShift clusters on Amazon Web Services, Microsoft Azure, IBM Cloud, and Google Cloud.
- Managed by Red Hat and cloud providers, integrating with cloud infrastructure.
- Ideal for businesses seeking reliable and managed cluster deployments.
- Deployable on physical or virtual infrastructure, on-premise or in a public cloud.
- Offers greater control and flexibility but requires more management responsibility.
- Suitable for organizations that prefer to manage their own infrastructure and cluster services.
- Includes the latest Kubernetes platform with enhanced security and enterprise stability.
- Runs on Red Hat Enterprise Linux CoreOS and includes Red Hat OpenShift Virtualization.
- Provides an administrator console for operational support.
- Builds on the OpenShift Kubernetes Engine with additional manageability, security, and development features.
- Includes a developer console, log management, cost management, and metering information.
- Adds Red Hat OpenShift Serverless (Knative), Service Mesh (Istio), Pipelines (Tekton), and GitOps (Argo CD).
- The most feature-rich edition, including all features of the Container Platform.
- Adds Red Hat Advanced Cluster Management, Advanced Cluster Security, and Red Hat Quay private registry.
- Designed for comprehensive development and administrative needs for containerized application management.
- Available through the Red Hat Hybrid Cloud Console.
- Helps administrators identify and remediate cluster issues using data from the Insights Operator.
- Provides recommendations and their impacts on the cluster for proactive management.
Kubernetes implements software-defined networking (SDN) to manage the network infrastructure of the cluster and user applications. The SDN is a virtual network that encompasses all cluster nodes. The virtual network enables communication between any container or pod inside the cluster. Cluster node processes that Kubernetes pods manage can access the SDN. However, the SDN is not accessible from outside the cluster, nor to regular processes on cluster nodes. With the software-defined networking model, you can manage network services through the abstraction of several networking layers.
With the SDN, you can manage the network traffic and network resources programmatically, so that the organization teams can decide how to expose their applications. The SDN implementation creates a model that is compatible with traditional networking practices. It makes pods akin to virtual machines in terms of port allocation, IP address leasing, and reservation.
With the SDN design, you do not need to change how application components communicate with each other, which helps to containerize legacy applications. If your application is composed of many services that communicate over the TCP/UDP stack, then this approach still works, because containers in a pod use the same network stack.
Container Network Interface (CNI) plug-ins provide a common interface between the network provider and the container runtime. CNI defines the specifications for plug-ins that configure network interfaces inside containers. Plug-ins that are written to the specification enable different network providers to control the RHOCP cluster network.
Red Hat provides the following CNI plug-ins for an RHOCP cluster:
- OVN-Kubernetes: The default plug-in for first-time installations of RHOCP, starting with RHOCP 4.10.
- OpenShift SDN: An earlier plug-in from RHOCP 3.x; it is incompatible with some later features of RHOCP 4.x.
- Kuryr: A plug-in for integration and performance on OpenStack deployments.
Certified CNI plug-ins from other vendors are also compatible with an RHOCP cluster.
The SDN uses CNI plug-ins to create Linux namespaces to partition the usage of resources and processes on physical and virtual hosts. With this implementation, containers inside pods can share network resources, such as devices, IP stacks, firewall rules, and routing tables. The SDN allocates a unique routable IP to each pod, so that you can access the pod from any other service in the same network.
In OpenShift 4.14, OVN-Kubernetes is the default network provider.
OVN-Kubernetes uses Open Virtual Network (OVN) to manage the cluster network. A cluster that uses the OVN-Kubernetes plug-in also runs Open vSwitch (OVS) on each node. OVN configures OVS on each node to implement the declared network configuration.
For this guideline, I will explain local RedHat Openshift installation using CRC (CodeReadyContainers). For Managed services (e.g ROSA) please refer to my previous blog entry: Building your first ROSA🌹 with Red Hat and AWS
CodeReady Containers:
- Brings a minimal Openshift 4 cluster to your laptop/Desktop for developing and testing.
- The CLI makes it easy to install and interact with the VM. It also allows for easy configuration.
- Since CRC is ephemeral, it's intended only for learning purposes. Refrain from running it in production ;)
- vCPU -> At least 4vCPUs
- Memory -> At least 9GBi of free memory
- Storage -> At least 35GB of free storage
- RedHat Openshift Console Account -> https://console.redhat.com/openshift
- CRC pull secret -> Also called: Red Hat Openshift Local Secret. You can download this from item 4. Refer to below image for further details
Note: I will show the setps for a Windows OS. Please refer to official documentation for Linux/MAC OS
- Download latest CRC release https://cloud.redhat.com/openshift/install/crc/installer-provisioned
- (optional) add the path to environment variables
- Go to the CRC folder and run:
crc setup - When requested, paste the CRC pull secret code mentioned in the requirements section.
- Once completed the setup, execute the
crc start - Wait until installation is commpleted. Credentials information will be displayed.
- In case you need to collect login information, use
crc console --show-credentials - If you need to access UI, use
crc console - OCP cluster is ready to use!!
CRC Setup
CRC start completed and cluster ready to use
The Red Hat Certified OpenShift Administrator exam (EX280) 🛠️ tests your ability to set up, configure, and manage applications on the Red Hat OpenShift Container Platform 🚀, a cloud-based system for running applications in containers 📦.
Passing this exam makes you a certified Red Hat OpenShift Administrator 🏅 and helps you on your way to becoming a Red Hat Certified Architect (RHCA) 🌟.
The exam is designed for:
- System and Software Architects 🖥️ needing to understand OpenShift features and functionality.
- System Administrators 👩💻 setting up initial OpenShift clusters.
- Cluster Operators 🔧 handling ongoing maintenance of OpenShift clusters.
- Site Reliability Engineers 🛡️ troubleshooting and maintaining OpenShift clusters.
- System Administrators 💼 wanting to showcase their OpenShift skills.
- Red Hat Certified Engineers 🎓 aiming to become RHCA.
- System Administrators or Developers 👨💻 working in DevOps environments with OpenShift.
I created this blog to talk about certain topics I found difficult to practice due to limited online resources. For General Exam details and a broad range of core concepts I recommend the following:
- RedHat
-
Red Hat OpenShift Administration I: Containers & Kubernetes (DO180) course Link here
-
Red Hat OpenShift Administration II: Operating a Production Kubernetes Cluster (DO280) course Link here
Official documentation offered by Red Hat. Includes both Theory and detailed Hands-on exercises. Totally recommended.
- Youtube
-
Openshift Administration series - Tech Tejendra
-
Openshift series - Devops
Hands on Youtube series to follow along with CRC. Also recommended and In my opinion, together cover 50-60% Exam topics
- Blog
Detailed Enok Doc with Openshift EX280 topics and examples. Great for last minute review and learn some services you won't find in Youtube series.
Containers are designed to be immutable and ephemeral. A running container must be redeployed when changes are needed or when a new container image is available. However, you can change a running container without redeployment.
Updating a running container is best reserved for troubleshooting problematic containers. Red Hat does not generally recommend editing a running container to fix errors in a deployment. Changes to a running container are not captured in source control, but help to identify the needed corrections to the source code for the container functions. Capture these container updates in version control after you identify the necessary changes. Then, build a new container image and redeploy the application.
Custom alterations to a running container are incompatible with elegant architecture, reliability, and resilience for the environment.
Administrators use various tools to interact with, inspect, and alter running containers. Administrators can use commands such as oc get to gather initial details for a specified resource type. Other commands are available for detailed inspection of a resource, or to update a resource in real time.
NOTE: When interacting with the cluster containers, take suitable precautions with actively running components, services, and applications.
Use these tools to validate the functions and environment for a running container:
The oc CLI provides the following commands:
oc describe: Display the details of a resource.oc edit: Edit a resource configuration by using the system editor.oc patch: Update a specific attribute or field for a resource.oc replace: Deploy a new instance of the resource.oc cp: Copy files and directories to and from containers.oc exec: Execute a command within a specified container.oc explain: Display documentation for a specified resource.oc port-forward: Configure a port forwarder for a specified container.oc logs: Retrieve the logs for a specified container.
Besides supporting the previous oc commands, the oc CLI adds the following commands for inspecting and troubleshooting running containers:
oc status: Display the status of the containers in the selected namespace.oc rsync: Synchronize files and directories to and from containers.oc rsh: Start a remote shell within a specified container.
Find the following Practice Exams to review core concepts and challenge yourself while preparing for the exam:
- Set up the htpasswd file.
- Verify the file contents.
- Set up the rest of the users and their passwords.
- Verify the file contents.
- Check if there's an existing HTPasswd Secret file.
- Delete the
htpass-secretfile. - Create the secret from the htpasswd file.
- Download the HTPasswd Custom Resource.
- Open the file.
- Under
identityProviders, replacemy_htpasswd_providerwithusers.htpassword. - Save and exit the file by pressing
Escapefollowed by:wq. - Apply the changes.
- Log in as the
rootuser. - Verify you're logged in as
root. - Log in as the
alphauser. - Verify you're logged in as
alpha. - Log in as the
betauser. - Verify you're logged in as
beta. - Log in as the
gammauser. - Verify you're logged in as
gamma. - Log in as the
deltauser. - Verify you're logged in as
delta. - Log in as
kubeadmin. - Create the
NewProjectproject. - Give
alphaadmin permissions to theNewProjectproject. - Give
betaandgammaedit permissions to theNewProjectproject. - Give
deltabasic user permissions to theNewProjectproject. - Give the
rootuser cluster admin permissions. - Log in as
root. - Remove the
kubeadminuser from the cluster.
- Create a project called
snacks. - Create a group called
group1. - Add
alpha,beta, andgammato thegroup1group. - Grant admin access to the
group1group for the projectsnacks. - Create a custom
getpodsrole. - Assign the
getpodsrole todelta, allowing the user to get pod information from thesnacksproject. - Verify it worked.
- Download the quota and resource limit templates, modify them to limit cpu and memory for
snacksproject.
- Create a network policy to only allow ingress traffic from an specific namespace, pod label and port. Refer to below YAML file for reference
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
spec:
podSelector:
matchLabels:
deployment: hello
ingress:
- from:
- namespaceSelector:
matchLabels:
network: different-namespace
podSelector:
matchLabels:
deployment: sample-app
ports:
- port: 8080
protocol: TCP
-
Create a network policy that allows traffic to the hello pod via the exposed route
-
Create cluster logs to upload for support
Thank you for taking the time to read this summary and tips on the Red Hat EX280 exam! 📚 As with any hands-on exam, the key is consistent practice and exploring different ways to solve problems or deliver solutions. In my experience, that's the best way to truly understand and master a concept. Keep rocking and happy learning! 🚀💡
