The Architectural “Guess”: How Quotas are Sized

Administrators do not set quotas arbitrarily; they calculate them based on several design factors:

• Infrastructure Awareness: Quotas are capped based on the total CPU cores and RAM available on physical worker nodes. Clusters are typically sized to be larger than the maximum requests of the largest project.

• Stack-Specific Baselines: Calculations often use industry baselines for different application types. For example, Java-based applications typically require at least 512Mi memory requests and 1Gi-2Gi limits due to JVM overhead, whereas Node.js or Go microservices are calculated with much lighter footprints (e.g., 100m-250m CPU and 128Mi-512Mi RAM).

• Deployment Strategy Overhead: Architects must account for “upgrade overhead”. A Rolling strategy requires the quota to accommodate at least double the resources of a single pod during transition, as old and new pods run simultaneously.

• Capacity Buffers: Designs usually include a 25% capacity buffer over average daily peak loads to allow for high-transaction days and growth without requiring immediate administrative changes.

How This Affects Your Deployment

When developers deploy onto a cluster with active quotas, the namespace acts as a “defined box of resources”.

• Strict Specification Requirement: If a compute quota is active, the Kubernetes control plane will reject any pod that does not explicitly specify resource requests or limits.

• The Admission Contract: Your pod specification is your contract with the scheduler. If a pod creation request pushes the total namespace usage beyond the hard limit, the API server will block the operation with a 403 Forbidden error.

• Performance Constraints: If your code exceeds the architecture’s memory limit, the kernel will trigger an Out-Of-Memory (OOM) kill; if it exceeds the CPU limit, the process will be throttled, leading to increased latency.

Visibility for Developers

You do not have to guess your remaining budget. You can inspect the current usage and hard limits calculated for your project by running oc describe quota or by viewing the AppliedClusterResourceQuota, which projects cluster-wide departmental budgets directly into your specific namespace.

Analogy: Imagine the namespace quota is a pre-paid utility allowance for a shared apartment. The landlord (admin) calculates the allowance based on the building’s total electrical capacity and the typical needs of a tenant (the software architecture). If you try to plug in a high-powered appliance that exceeds your room’s calculated limit, the circuit breaker trips (403 Forbidden) to prevent the whole building from losing power.NotebookLM can be inaccurate; please double check its responses.

1. Spring Boot Application Setup

To enable health probes, follow these steps to configure your application:

• Dependency Management: Add the spring-boot-starter-actuator dependency to your project. This provides the necessary infrastructure to track availability states and expose them via web endpoints.

• Enable Probes: Spring Boot possesses “cloud-native” intelligence; it automatically activates liveness and readiness health indicators when it detects it is running in a Kubernetes environment. For local testing outside of Kubernetes, you can manually enable them in your application.properties file:

• Default Endpoints: Once enabled, Actuator provides two dedicated health groups:

    ◦ Liveness: /actuator/health/liveness (returns 200 OK when the internal state is stable).

    ◦ Readiness: /actuator/health/readiness (returns 200 OK when the application is ready to handle traffic).

2. Kubernetes YAML Configuration

In your Kubernetes deployment manifest, you should define three types of probes within the container specification to ensure high availability and self-healing.

Example Configuration

spec:
  containers:
  - name: basic-springboot-app
    image: your-image:latest
    ports:
    - containerPort: 8080
    
    # Startup Probe: Protects the app during the intensive JVM boot phase
    startupProbe:
      httpGet:
        path: /actuator/health/liveness
        port: 8080
      failureThreshold: 30
      periodSeconds: 10 # Gives the app 300 seconds to start
      
    # Liveness Probe: Detects if the app is deadlocked or unrecoverable
    livenessProbe:
      httpGet:
        path: /actuator/health/liveness
        port: 8080
      initialDelaySeconds: 0 # Handled by startupProbe
      periodSeconds: 10
      
    # Readiness Probe: Determines if the app should receive network traffic
    readinessProbe:
      httpGet:
        path: /actuator/health/readiness
        port: 8080
      initialDelaySeconds: 0
      periodSeconds: 10

3. Key Concepts and Best Practices

• The Three-Probe Strategy: Always use all three probes for JVM workloads. The Startup Probe is crucial because it suppresses liveness and readiness checks until the application has finished initializing. This prevents the “restart loop” where Kubernetes kills a slow-starting container before it can become healthy.

• Liveness Independence: The liveness probe should never depend on external systems like databases or web APIs. If an external database fails and your liveness probe fails as a result, Kubernetes will restart all your application instances, potentially causing a cascading failure across the platform.

• Readiness Judgment: Readiness probes may include external checks if the application cannot function without them. If the readiness probe fails, Kubernetes simply stops routing traffic to that pod instead of restarting it.

• Resource Timing: Be cautious with aggressive timeouts. A default timeoutSeconds of 1 second can be too short if the JVM experiences garbage collection pauses or CPU throttling, leading to false-positive failures. Increasing this to 3–5 seconds is often recommended for stability.

——————————————————————————–

Analogy for Understanding Probes: Think of a Liveness Probe as a doctor checking for a heartbeat; if it stops, the system tries to “resuscitate” the app by restarting it. The Readiness Probe is like a “Back in 5 Minutes” sign on a shop door; the shop is still there (it doesn’t need to be rebuilt), but it isn’t ready to serve customers yet. Finally, the Startup Probe is like a “Grand Opening Coming Soon” sign, telling the landlord (Kubernetes) not to evict the tenant just because they haven’t started selling products while they are still setting up the shelves.

At its core, an IDP abstracts the complex underlying infrastructure — including cloud services, container orchestration, and networking — so developers can focus on writing code rather than managing operations. It provides core functionalities such as building, testing, deploying, and monitoring applications, often through automation and standardized workflows.

Why do businesses need an IDP?

Organizations engaged in software development typically involve multiple teams working on diverse projects. These projects benefit from standardized workflows, which help reduce duplicated efforts, streamline collaboration, and minimize configuration errors. Implementing an IDP facilitates scaling of development efforts, supporting rapid growth, and increasing the frequency of releases — some organizations achieving deployment cycles as short as minutes.

Using automated CI/CD pipelines, developers can rapidly move from code commits to production deployments, significantly reducing lead times.

An IDP also enhances security and compliance through policy enforcement tools, such as policy-as-code solutions (e.g., Open Policy Agent), ensuring adherence to security best practices automatically. This not only reduces risks but also simplifies audits and regulatory compliance.

Loosely Coupled Architecture

A key principle of effective IDPs is that they must be loosely coupled. This design allows individual components and tools — such as build systems, deployment tools, or policy frameworks — to be added, upgraded, or replaced independently. For example, an organization may start with Terraform for infrastructure provisioning, then later incorporate Pulumi or CloudFormation, without overhauling the entire platform.

This modularity provides several benefits:

• Flexibility & Scalability: Teams can adopt new tools or technologies as needed, ensuring the platform evolves with industry best practices.
• Rapid Iterations: Developers or platform engineers can fix bugs, add features, or optimize workflows swiftly, similar to how functions or objects are modulated in code.
• Resilience: If one tool or component fails, it limits the potential impact on the entire system, preventing major outages.
• Heterogeneous Tooling: Different teams often have unique requirements, and modularity allows each to use the most suitable tools, whether for container orchestration (e.g., Kubernetes), monitoring (e.g., Prometheus), or security policies.

Building and Deploying Infrastructure and Applications

Integrating GitOps practices enhances the automation and security of the platform. Infrastructure provisioning can be managed with tools like Terraform, CloudFormation, or Pulumi, where infrastructure code stored in Git repositories is automatically applied, ensuring version control and auditability.

Application objects, such as containers or microservices, are built and deployed through CI/CD pipelines using tools like Jenkins, GitLab CI, or Argo CD. These pipelines can automatically:

• Build container images.
• Run tests and security scans.
• Deploy updates to staging or production environments.

The API-driven nature of these tools allows seamless integration, enabling rapid, automated build and deployment cycles. Security policies and compliance controls are enforced within the pipelines, ensuring that only compliant code reaches production, reducing risk and manual oversight.

An effective IDP combines loosely coupled components, enabling organizations to adapt quickly, scale efficiently, and maintain high availability. Its design supports rapid development cycles, policy enforcement, and infrastructure automation, all critical for competitive, modern software delivery.

AI-powered code generators, such as OpenAI Codex and GitHub Copilot, can assist developers by suggesting snippets, automating routine tasks, and providing boilerplate code. For many standard programming tasks, these tools significantly speed up development processes and reduce manual effort. AI models trained on vast amounts of code can identify potential bugs and vulnerabilities faster than manual reviews. They can predict problematic code patterns and recommend fixes. AI tools can analyze existing codebases and suggest improvements for performance, readability, and maintainability. Machine learning models can adapt to specific codebases over time, becoming more effective in understanding project-specific nuances, coding styles, and architectural patterns.

However, there are limitations and challenges in AI programming.  AI models operate based on patterns learned from training data. They lack deep understanding of business logic, domain-specific intricacies, and architectural decisions. With this lack of understanding, the code base developed is not sophisticated and can create security risks in your application. AI suggestions can be incorrect or suboptimal, especially in complex scenarios requiring nuanced judgment. Reliance on AI can introduce bugs or security vulnerabilities if not thoroughly reviewed. AI is not creative. AI excels at pattern recognition but struggles with innovative design or creative problem-solving. Both design and creative problem solving are essential in sophisticated programs. The effectiveness of AI tools depends critically on the quality and diversity of training data. Poor or biased data can lead to ineffective or flawed suggestions. Most data it uses to train is old data and incorrect data.

AI has demonstrated significant effectiveness in augmenting programming tasks for sophisticated programs, especially in automation, bug detection, and optimization. However, it is not a silver bullet; limitations such as lack of contextual understanding and the potential for inaccuracies mean that AI should be viewed as a powerful assistant rather than a replacement for experienced developers.

The future of AI in programming lies in hybrid approaches, leveraging AI to handle routine and pattern-based tasks while human experts focus on strategic, architectural, and innovative aspects of software development.

CI/CD pipelines form the backbone of modern software deployment practices. They automate testing, integration, and delivery processes, enabling teams to deliver high-quality updates rapidly. Efficient, reliable CI/CD systems are essential for supporting practices like agile development, microservices architecture, and DevOps culture. 

However, many organizations rely on self-made, legacy CI/CD tools that have accumulated over the years. These tools often lack scalability, are riddled with bugs, and are incompatible with current cloud-native technologies. Such outdated systems impose significant constraints on the development lifecycle.

In the beginning, these CI/CD solutions targeted specific needs. However, as time goes by, legacy CI/CD solutions tend to become bloated over time. They are laden with obsolete features, deprecated interfaces, and convoluted workflows. This bloat leads to several issues:

– Slow Build and Deployment Times: Excessive features and inefficient processes prolong deployment cycles, delaying time-to-market.

– Higher Failure Rates: Complex, fragile pipelines are more prone to errors, requiring extensive troubleshooting.

– Increased Maintenance Burden: Technical debt accumulates, demanding ongoing effort to keep the pipeline operational.

These inefficiencies drain resources and distract from core development activities, making modernization at the application level a lost cause if the pipeline itself is a bottleneck.

Continuing to operate legacy CI/CD tools incurs mounting technical debt, requiring frequent workarounds and patches. This maintenance diverts skilled resources from innovation, and upgrading or replacing such systems is often labor-intensive, risky, and expensive. In many cases, organizations find themselves stuck, unable to leverage the latest development practices or cloud-native capabilities because their foundational pipelines are obsolete.

Outdated CI/CD systems rarely integrate seamlessly with modern environments. They pose a significant obstacle to adopting advanced methodologies such as containerization, serverless deployment, or microservices architecture. Consequently, organizations face a dilemma: invest heavily in overhauling their pipelines or accept subpar deployment processes that hamper growth and agility.

Investing heavily in application modernization—refactoring code, adopting new frameworks, or redesigning architectures—without concurrently updating the development infrastructure is often a waste of effort. Without reliable, modern deployment pipelines, these modernization efforts are undermined by slow feedback loops, deployment failures, and operational inefficiencies.

The key to successful modernization lies in prioritizing the upgrade or replacement of outdated CI/CD tools. Modern, cloud-native pipelines that are built with scalability, automation, and ease of integration in mind, serve as the enablers for application evolution. When the foundation is solid, organizations can deploy new features faster, reduce errors, and adopt innovative practices with confidence.

Modernization is not solely about updating applications or infrastructure; it begins with transforming the very tools that support development workflows. Legacy, self-made CI/CD systems act as bottlenecks that stifle progress and inflate costs. True potential of modernization initiatives, organizations must invest in modern, reliable, and scalable development foundations first. Only then can they ensure that their application improvements are sustainable, efficient, and capable of meeting future demands.

• Red Hat OpenShift Local Admin Helper

This Helper service allows you to manage and configure the cluster directory from your computer.  When you start your  OpenShift cluster it also start two other processes. 

• Crc.exe (of course since you ran it)
• Crc-background-launcher.exe (this helps manage the background processes that run and manage containers)

Your host file for windows also gets changed so you can actually use the API and console URLs.  This host file also has entries so you can develop routes for you applications.  This is important for the scheduler-form.  For easy viewing and editing I would recommend getting the PowerToys application. 

• https://learn.microsoft.com/en-us/windows/powertoys/

The host file has a lot of entries for OpenShift. You will noticed that most use apps-crc.testing as their top level domain.  This is important because the Red Hat Windows service handles that top level domain and ensure you application gets to the right destination.  We will setup a route named schedulerform.api.crc.testing for the scheduler-form.  This will allow you to view the form  and submit data to the scheduler.

To start let clone the scheduler-form form the gitlab.com.

$ git clone https://gitlab.com/keckler-dev/scheduler-form.git

You will need to start up your OpenShift Local cluster.  You will also need to login on the console.

$ crc start
$ oc login --token=……. --server=https://api.crc.testing:6443

Remember you can get your login token from the crc console. Click on Copy login command form the dropdown on your username.

Once you have cloned the repository, switch to the scheduler-form directory.  The organization is similar to the scheduler repository.  Since it has a web UI, you will have extra directories.  Static and templates are added to handle the static CSS file and templates holds the html files.  Take a look at get a feel to how it is setup. 

In the helm directory under the templates is an extra file called route.yaml.  This is where you are defining your application’s URL and how it is attached to the Scheduler-form Service. 

In the spec section file you will have the host line.  This is the URL you application is listening on.  Noticed that the top lever domain is apps-crc.tesing.  The ‘to’ sections defines the service that will handle the requests from the route.  You can have multiple services to a route by adding alternateBackends to the route.  You use the weight line to balance the amount of traffic to each service.  You could use this for canary testing. 

Lets get started, and deploy the helm chart for the scheduler-form.  Ensure your are in the scheduler-form directory and execute the helm install command

$ helm install scheduler-form helm

You will see a new deployment called schedulerform.  It will show 1 pod  running.  In the networking section you will see e a new service called schedulerform in Services.  You can do some testing on the IPs in the pod to ensure everything is working properly.  See post Helm Chart Part -1 Scheduler for instructions.  Additionally you will see a new entry in the Routes section under Services.

There will be a route called schedulerform.  It will have a location http://schedulerform.apps-crc.testing.  You will see that the service it is using is schedulerform.  Click on the URL.  A new window comes up with a form.  You can use this form to input data.  Once you click the Generate Scheduler button, the informations is sent in a POST to the scheduler service http://scheduler:8080/schedule. The results will be the json output of the scheduler and a list of the scheduler by week.

We do not need a route create for scheduler deployment because OpenShift allow communication in the same namespace.  You can call any Service on the port the service is listening on in the same Namespace. 

In conclusion, setting up the Scheduler-form in OpenShift Local involves several key steps, including  cloning the scheduler-form repository, and deploying the helm chart. By following these steps, you can effectively manage and configure your OpenShift cluster, ensuring that your applications are routed correctly and can communicate within the same namespace.

Once you have installed Helm, you can create your basic Helm chart.  I have already created and setup the Helm chart in the Gitlab repository for the scheduler, https://gitlab.com/keckler-dev/scheduler

$ helm create scheduler

There are sever basic information that gets created

Chart.yaml – use for versioning your chart

values.yaml – default values for your chart’s variable

• You can create other values yaml file such as dev.yaml.

Templates directory is created and example deployment.yaml and service.yaml file are available.

Before you run the helm command, create the project and ensure your default project is set to the namespace where the Kubernetes objects will be created

$ oc create namespace scheduler
$ oc project scheduler
$ oc project
scheduler

In order to run the Helm command you should be in the Directory where the Helm chart starts.

$ helm install scheduler helm
 

• Scheduler is the Helm release name.
• helm is the directory of the helm chart

If there is a mistake in your helm chart, fix the issue and redeploy the helm chart

$ helm upgrade
scheduler helm

After the Helm deployment, you will see the OpenShift Project scheduler with Kubernetes objects created.

The Deployments will show scheduler with 1 pod deployed.

The pod will be names scheduler-<random letter and numbers>. It should be running and the logs tab should show the program is running on port 8080.

In the Services object you will see the scheduler service. It will have an IP:8080 associate with it.  Click on the service scheduler and it will take you to the details of the service. 

Testing the install:

1. Go the pods section and click on the scheduler pod.
2. Go to the terminal tab
3. You should be presented with an terminal ‘$’
4. In the directory will be a teams.json file.  We will use this file to test the program. Type in the following

$ curl -X POST -H "Content-Type: application/json" -d @teams.json http://localhost:8080/schedule

You will see the output of the matches created by the scheduler. 

[{"matches":[{"away":"Bye","date":"2024-01-01","home":"Team
A"},{"away":"Team ………….

The Pod is working. Let’s test the service.  From the desktop we are going to setup a port forward to the service. And query the service. Ensure you are in the project Scheduler.

$ kubectl port-forward service/scheduler  8080:8080 -n scheduler

If everything is correct you will see the port forwarding happening.  The desktop localhost on port 8080 is pointing to the scheduler service in the OpenShift project scheduler.  Execute the same curl command as above on your local desktop.  You should see the same output. 

If you get Failed to connect to localhost port 8080: Cannot connect to server. You probably killed the kubectl port forward command.  Make sure it is running and use a different powershell/cmd interface for the curl command.  Ensure the teams.json file is in the directory when you make your curl command.

By following this guide, you have successfully set up Helm and deployed a Helm chart for the Scheduler application on OpenShift. The process included creating the Helm chart, configuring it with necessary parameters, and deploying it to the OpenShift project. You also learned how to troubleshoot and upgrade your Helm chart if any issues arise during deployment. Finally, you validated the deployment by testing the application within the pod and through the service using port forwarding.

This setup ensures that your Kubernetes objects are properly managed and deployed, providing a robust environment for your Scheduler application. Whether you’re managing more complex applications or scaling your deployments, this foundational knowledge will be invaluable.

For more detailed information and further learning, don’t forget to explore the tutorials and guides available on the Helm documentation site.

Helm Chart Part 2 will be about the Scheduler form and how it interfaces with the scheduler service. We will also discuss the Route object and how it is setup with OpenShift Local.

1. How to Get and Deploy OpenShift Local

1. In order to download and install OpenShift Local you will need a Red Hat account.  This is free.  Sign up at https://developers.redhat.com/.
2. Download OpenShift Local: Visit the Red Hat OpenShift Local download page and download the version for your OS. https://developers.redhat.com/products/openshift-local/overview  Make sure you are on the local tab.
3. Install CodeReady Containers (CRC): Extract the downloaded file.
4. RUN: “crc setup” (Use Powershell)
5. Pull Secret: During the install process, you will need to provide the pull secret.

2. How to Set Up CRC to Use 4 CPUs and  12GB of Memory

crc start --cpus 4 --memory 12288

1. If you start you CRC with this, you will have to ALWAYS start it with this command.

3. How to Retrieve Users and Passwords After Setup

1. Retrieve the Admin Credentials: Use the command “crc console” to access the OpenShift web console.
2. Find the Admin User and Password: Look for the credentials in the console or use the command crc config view to view the current configuration, which includes the admin user and password. “crc config –credentials”

4. How to Change the Network in Hyper-V to Use the External Switch

1. Open Hyper-V Manager: Go to the Hyper-V Manager.
2. Select Your Virtual Machine: Right-click on the virtual machine running OpenShift Local and select “Settings.”
3. Change Network Adapter: Under the “Hardware” tab, select the network adapter and click “Remove.”
4. Add a New Network Adapter: Click “Add” and select the external switch you want to use.
5. Restart the Virtual Machine: Restart the virtual machine to apply the changes.

Note on External switch:  I have seen where the crc virtual machine does not allow connections to it when you start it up.  If the 'crc start' is stuck:
1) exit the 'crc start'
2) do a 'crc stop'
3) edit the crc VM and remove the network adapter
4) do a 'crc start (with your aruguements for cpu and memory)'
5) when it is up, go back to the VM and add the external network adapter back in

5. Log into OpenShift Web Console

1. Run: crc console, this will open the OpenShift Web UI in a browser
2. Login:  use the kubeadmin and password from the crc output to log in.  See step 3 on how to retrieve the usernames and passwords if you did not copy the output.
3. CLI access to OpenShift: In the upper right corner is your username.  The drop down will give you access to your user preference and “Copy login Command”.  The Copy Login Command will give you a token and the ‘oc’ command to login into the cluster from a command line. 

6. Expand the Disk space.

You will need to expand the disk space if you are going to add any projects and pods.

1. Shutodwn CRC VM: “crc stop”
2. Open Hyper-V Manager: Launch Hyper-V Manager from the Start menu.
3. Select Your VM: Right-click on your CRC VM and select Settings.
4. Edit Virtual Hard Disk: In the Hardware section, select Hard Drive and click Edit.
5. Expand Disk: In the Edit Virtual Hard Disk Wizard, select Expand and specify the new size for your virtual hard disk. Make it 100GB.
6. Finish: Click Finish to apply the changes.
7. Start the VM: “crc start” * if you started you orginial crc with crc start –cpus 6 –memory 12288, then start it with the arguments.

By following the detailed steps outlined in this guide, you can efficiently set up OpenShift Local on Windows 11 with Hyper-V, ensuring your system meets the necessary hardware requirements and configurations. From enabling Hyper-V and creating an external virtual switch to configuring CRC with the optimal resources and retrieving user credentials, this setup provides a robust foundation for your local development environment. With OpenShift Local up and running, you’re now ready to deploy and manage containerized applications, making full use of the powerful features OpenShift offers. Stay tuned for more advanced tutorials and projects that will take your development skills to the next level.

Hardware Requirements

In the previous article I discussed the requirements.  https://www.kecklers.com/setting-up-openshift-local-on-windows-11-with-hyper-v/  Here it is again:

• 4 virtual CPUs
• 10.5 GB memory minimum – best to use at least 12GB
• 35 GB of storage space
  • This is the minimum. I recommend allocating more space if you plan to do more than what is demonstrated here.
  • Adjust this by issuing CRC config commands before running the crc start command.

Detailed Hardware Requirements

The following is the hardware I am using on my desktop to setup Hyper-V and house the OpenShift Local VM

• Operating System: Windows 11 PRO (Windows Home Edition is not supported)
• CPU: Intel® Core i7-4700F, 21MHz, 20 Core(s), 28 Logical Processor(s)
• Memory: 64GB
• Storage: 2TB drive

Step-by-Step Setup

Step 1: Enable Hyper-V

1. Press Windows + R, type optionalfeatures.exe, and press Enter.
2. In the Windows Features dialog, check the box for Hyper-V and click OK.
3. Restart your computer.

Step 2: Create an External Virtual Switch

1. Open Hyper-V Manager by pressing Windows + R, typing virtmgmt.msc, and pressing Enter.
2. In the Actions pane, select Virtual Switch Manager.
3. Select External and click Create Virtual Switch.
4. Name the switch (e.g., “External Switch”) and select the network adapter that is connected to your physical network.
5. Ensure the checkbox “Allow management operating system to share this network adapter” is checked.
6. Click Apply and then OK.

By following these steps, you can ensure your Hyper-V environment is properly configured with an external virtual switch, allowing your VMs to access the internet. This foundational setup is crucial for running OpenShift Local efficiently and preparing for advanced containerized application deployments. The hardware I am using is more than enough, but you are dealing with a Windows setup, not Linux. More is better. bhad bhabie age

Hardware Requirements

To get started, OpenShift Local says you need 4 CPUs, 9Gbs of memory and 35Gb of storage space. This will not work.  Below is the virtual settings I used on my Hyper-V setup to get OpenShift Local to work.  You will need Windows 11 PRO because the Home edition is not supported.

• 4 virtual CPU
• 10.5 GB memory minimum – best to use at least 12GB
• 35 GB of storage space
  • This is the minimum.  I would recommend more space if you are going to do more than what I am demonstrating.
  • I would do this by issuing crc config commands before doing the ‘crc start’.

OpenShift Local Requirements

OpenShift Local is a minimal OpenShift Container Platform 4 cluster that you can run locally on your development workstation. It is perfect for development and testing use cases.

 Here are the steps to install and set up OpenShift Local:

1. Download OpenShift Local: Visit the Red Hat Developer website and download the OpenShift Local installer.
2. Install Hyper-V: Ensure Hyper-V is enabled on your Windows 11 system. You can do this by running the following PowerShell command:
   powershell
   ‘Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-Management-PowerShell’
3. Setup External Virtual Switch for your VMs
4. Run the Installer: Unzip the downloaded installer and run the setup. Follow the prompts to complete the installation3.
5. Start OpenShift Local: Use the crc start command to start the OpenShift Local cluster. This will take a few minutes to initialize4.

Creating and Managing Applications

Once your OpenShift Local setup is complete, you can start creating and managing applications. Here’s a high-level overview of the process:

1. Create Two Programs: Develop two separate programs that will reside on images in the same namespace.
2. Deploy the Programs: Use oc commands to deploy the programs as pods in the OpenShift Local cluster.
3. Set Up Ingress and Communication: Configure ingress to allow external access to your applications and set up communication between the pods.
   1. For the Ingress controller, I will be setting up the Nginx Operator

By following these steps, you can set up an OpenShift Local environment on Windows 11 with Hyper-V, creating a foundation for more advanced containerized applications. Stay tuned for future articles where we will dive deeper into creating and managing these applications.