OKD 4.19: Air-Gapped Install Guide For Single-Node Clusters

Hey guys! Setting up OKD, the community distribution of Kubernetes that powers Red Hat OpenShift, in an air-gapped environment can seem like a daunting task, especially when you're aiming for a single-node cluster. This guide dives deep into the process, focusing on OKD 4.19, and breaks down the steps you need to follow, including mirroring images with Harbor registry. If you've hit a wall trying to get your images mirrored correctly or are just starting to plan your air-gapped installation, you’re in the right place. We'll cover everything from preparing your environment to verifying your installation, making sure you have a smooth experience. Let's jump right in and get your OKD single-node cluster up and running!

Understanding Air-Gapped Environments and OKD

Before we dive into the nitty-gritty, let's make sure we're all on the same page. An air-gapped environment, simply put, is a network or system that is physically isolated from other networks, including the public internet. This isolation is crucial for security reasons, often in industries like finance, government, or defense, where sensitive data needs maximum protection. Installing OKD in such an environment adds a layer of complexity because OKD, like its upstream counterpart OpenShift, relies heavily on container images and online resources during installation and operation. So, the primary challenge here is to get all the necessary components, especially those container images, into your air-gapped network. We achieve this by mirroring, which is essentially copying images from a public registry to a private one within your network, like Harbor. Mirroring ensures that your cluster can access the required images without needing an internet connection, maintaining the integrity of your air-gapped setup. Understanding this fundamental requirement is the first step towards a successful installation. So, let's keep this in mind as we proceed, ensuring that every step we take respects the air-gapped nature of our target environment.

Why Choose OKD for Air-Gapped Environments?

You might be wondering, why choose OKD for an air-gapped environment in the first place? Well, OKD's robust architecture and container-centric approach make it a compelling choice. Its design is inherently geared towards managing and deploying applications in containers, which aligns perfectly with the needs of a secure, isolated environment. Moreover, OKD’s community-driven nature means you get a continuously evolving platform with the latest Kubernetes features and security patches. In an air-gapped setup, this is particularly valuable, as you want a platform that can operate self-sufficiently and securely. Furthermore, OKD’s modular design allows you to tailor the installation to your specific needs, choosing only the components you require, which can simplify the setup process in a restricted environment. For instance, you can opt for a minimal single-node cluster, reducing the footprint and complexity. By choosing OKD, you're selecting a platform that not only fits the bill technically but also offers a vibrant community and a wealth of resources to support your air-gapped deployment. This combination of features makes OKD a strong contender for your secure container orchestration needs. So, let's leverage these advantages as we move forward with our installation.

Key Challenges in Air-Gapped OKD Installation

Okay, let's be real—installing OKD in an air-gapped environment isn't a walk in the park. There are some serious hurdles we need to address head-on. The first, and arguably the biggest, challenge is the image mirroring process. OKD relies on a vast array of container images, and getting them all mirrored correctly to your private registry, like Harbor, can be tricky. You need to ensure you've identified all the required images, tagged them correctly, and transferred them without any hiccups. Then, there's the configuration aspect. You'll need to configure OKD to pull images from your private registry instead of the default public ones. This involves modifying installation configurations and cluster settings, which can be complex and error-prone. Another challenge is handling updates and upgrades. In an air-gapped environment, you can't simply pull updates from the internet, so you'll need a strategy for keeping your cluster up-to-date with the latest security patches and features. This usually involves manually downloading updates and applying them, which requires careful planning and execution. Finally, troubleshooting can be tougher in an air-gapped setup. When things go wrong, you can't easily access online resources or community forums from within the environment, so you'll need to be resourceful and have a solid understanding of the system to diagnose and fix issues. But don't sweat it, guys! We'll tackle each of these challenges step-by-step in this guide, ensuring you have a clear path to a successful installation.

Preparing Your Environment for OKD 4.19

Alright, before we get our hands dirty with the actual installation, let's set the stage by preparing our environment. This step is crucial, guys, as a well-prepared environment can save you a ton of headaches down the road. First, we need to ensure we have a suitable machine to host our single-node OKD 4.19 cluster. This machine should meet the minimum hardware requirements specified by the OKD documentation, including sufficient CPU, memory, and disk space. Next up is setting up our Harbor registry. If you haven't already, you'll need to deploy a Harbor instance within your air-gapped network. This registry will serve as the central repository for all the container images OKD needs. Make sure Harbor is properly configured and accessible within your network. Then, we'll need to configure our workstation, which is the machine we'll use to interact with the air-gapped environment and perform tasks like mirroring images. This workstation needs to have the necessary tools installed, such as the oc command-line tool (the OpenShift CLI) and podman or docker for handling container images. We'll also need to configure credentials for accessing both the Harbor registry and the OKD cluster. Lastly, we'll need to plan our network configuration, ensuring that the OKD cluster and Harbor registry can communicate with each other within the air-gapped network. With these preparations in place, we'll be ready to move on to the exciting part: mirroring those images! So, let's roll up our sleeves and get this environment prepped and ready for action.

Hardware and Software Requirements

Let's talk specifics about what you'll need in terms of hardware and software to get your OKD 4.19 single-node cluster up and running smoothly. For hardware, you'll want a machine with at least 16 GB of RAM, though more is always better, especially if you plan on running resource-intensive workloads. You should also have a CPU with at least 4 cores to ensure decent performance. As for disk space, aim for at least 120 GB, but again, this depends on your use case and how much data you'll be storing within the cluster. Now, onto software. You'll need a Linux-based operating system on your machine. Popular choices include Red Hat Enterprise Linux (RHEL), CentOS, or Fedora, but other distributions should work as well. Make sure you have the latest updates and patches installed for your chosen OS. You'll also need a container runtime, such as Podman or Docker, to manage container images. Podman is often preferred in air-gapped environments due to its rootless capabilities, which enhance security. Speaking of container tools, you'll definitely need the oc command-line tool, which is the official OpenShift CLI. You can download it from the official OKD website or through your distribution's package manager. Additionally, you'll need skopeo, a command-line utility for working with container images and registries. Skopeo is super handy for copying images between registries, which is exactly what we'll be doing for mirroring. Finally, make sure you have a web browser installed for accessing the OKD web console once the cluster is up. Having all these hardware and software prerequisites in place will set you up for a hassle-free installation experience. So, double-check your setup and let's get ready for the next step!

Setting Up Harbor Registry

Now, let's dive into setting up Harbor Registry, a crucial component for our air-gapped OKD installation. Harbor acts as our private container registry, storing all the images OKD needs to run, without relying on external internet access. First things first, you'll need to deploy a Harbor instance within your air-gapped network. There are several ways to do this, but the most common is using Docker Compose. You can grab the latest Harbor release from the official GitHub repository and follow the installation instructions. During the setup, pay close attention to the configuration options, especially those related to storage and networking. You'll want to ensure Harbor has enough storage to accommodate all the OKD images, which can be quite substantial. Also, configure Harbor to use a static IP address or a DNS name that's resolvable within your air-gapped network. Once Harbor is deployed, you'll need to create a project within Harbor to store your OKD images. A project is essentially a namespace within Harbor that helps you organize your images. Give your project a meaningful name, like “okd” or “okd419”. Next, you'll need to create a user account in Harbor that you'll use to authenticate when pushing and pulling images. Make sure this user has the necessary permissions to access the project you created. Finally, verify that you can access the Harbor web interface from within your air-gapped network. This is a good way to ensure that Harbor is running correctly and that your network configuration is working as expected. With Harbor up and running and properly configured, you'll have a secure and reliable place to store your OKD images. This is a key step in our air-gapped installation journey, so let's make sure we get it right!

Configuring Your Workstation

Let’s talk about configuring your workstation – the command center from which you'll orchestrate the OKD installation. This workstation needs to be equipped with the right tools and configurations to interact with your air-gapped environment effectively. First up, make sure you have the OpenShift CLI (oc) installed. This is your primary interface for managing OKD, so it's essential. You can download the oc binary from the official OKD website, or install it using your distribution's package manager if available. Next, you'll need a container runtime like Podman or Docker. As mentioned earlier, Podman is often preferred for air-gapped setups due to its rootless capabilities, enhancing security. Install your chosen container runtime and ensure it's running correctly. Once you have your container runtime, you'll need skopeo, a versatile command-line utility for handling container images. Skopeo allows you to copy images between registries, inspect image manifests, and more. You can typically install Skopeo using your distribution's package manager. Now, let’s configure access to your Harbor registry. You’ll need to log in to Harbor from your workstation using the docker login command (even if you're using Podman, it's compatible with Docker's authentication methods). Provide your Harbor registry's address, username, and password when prompted. This will store your credentials in your workstation's configuration, allowing you to push and pull images without repeatedly entering your credentials. Finally, ensure your workstation can communicate with your air-gapped network and specifically with your Harbor registry. You might need to configure DNS settings or add entries to your workstation's hosts file to resolve your Harbor registry's address. With your workstation properly configured, you'll have all the tools you need to mirror images, deploy OKD, and manage your cluster. So, take the time to set this up right, and you'll thank yourself later!

Mirroring OKD 4.19 Images to Harbor

Alright, guys, this is where the rubber meets the road! Mirroring the OKD 4.19 images to your Harbor registry is a critical step in the air-gapped installation process. Without these images, your cluster simply can't function. This process involves identifying the required images, pulling them from the public registry, tagging them appropriately, and pushing them to your private Harbor registry. First, you'll need to gather a list of all the images required for OKD 4.19. The official OKD documentation provides a list of these images, but it can be quite extensive. You can also use the oc adm release mirror command to generate a list of images. Once you have the list, you'll iterate through each image, pulling it from the public registry using podman pull or docker pull. After pulling an image, you'll need to tag it with your Harbor registry's address and the appropriate project name. This ensures the image is pushed to the correct location in Harbor. For example, if your Harbor registry is at harbor.example.com and your project is named okd, you might tag an image like this: podman tag <source_image> harbor.example.com/okd/<image_name>. With the image tagged, you can now push it to Harbor using podman push or docker push. Repeat this process for all the required images, and you'll gradually populate your Harbor registry with everything OKD needs. Keep a close eye on the process and verify that each image is successfully pushed to Harbor. This meticulous approach will ensure that your air-gapped OKD cluster has all the necessary resources to thrive. So, let's get those images mirrored and pave the way for a successful installation!

Identifying Required Images

Okay, let’s break down the crucial task of identifying the required images for your OKD 4.19 installation. This step is like making sure you have all the ingredients before you start cooking – you can't bake a cake without flour, right? Similarly, OKD needs a specific set of container images to function correctly. The good news is, there are a few ways to get this list, and we'll explore the most reliable methods. The first place you should always check is the official OKD documentation. It usually provides a comprehensive list of images required for each version, including 4.19. This list is often organized by component, making it easier to understand which images are needed for specific parts of the cluster. Another handy tool is the oc adm release mirror command. This command, part of the OpenShift CLI, can generate a list of images that need to be mirrored for a particular OKD release. You can run this command against a live OKD cluster or a release image to get the list. The output will typically be a YAML file containing all the image references. When compiling your list, pay close attention to the image tags. OKD images are tagged with specific version numbers, and you'll need to ensure you're mirroring the correct versions for OKD 4.19. Mirroring the wrong versions can lead to compatibility issues and installation failures. As you identify the images, keep a well-organized list. This will help you track your progress as you pull and push images to your Harbor registry. You can use a spreadsheet, a text file, or even a dedicated image manifest tool to manage your list. With a complete and accurate list of required images, you'll be well-prepared to tackle the mirroring process. So, let's get those images identified and move one step closer to our air-gapped OKD cluster!

Pulling and Tagging Images

Now that we've identified the images, let's get our hands dirty with the actual process of pulling and tagging them. This is where we download the images from the public registry and prepare them for upload to our private Harbor registry. Think of it as gathering the ingredients and prepping them for the recipe. First, you'll need to use a container runtime, like Podman or Docker, to pull the images from the public registry. The command you'll use is either podman pull <image_name> or docker pull <image_name>, depending on which runtime you're using. Replace <image_name> with the full image name and tag from your list. For example, it might look something like podman pull quay.io/openshift/okd:4.19.0. As you pull each image, it's a good idea to verify that the pull was successful. You can do this by checking the output of the command or by listing the images available on your system using podman images or docker images. Once you've pulled an image, the next step is to tag it with your Harbor registry's address and the appropriate project name. This is crucial because it tells the container runtime where to push the image. The tagging command is podman tag <source_image> <target_image> or docker tag <source_image> <target_image>. The <source_image> is the image you just pulled, and the <target_image> is the new name that includes your Harbor registry's address and project. For example, if your Harbor registry is at harbor.example.com and your project is named okd, you might tag an image like this: podman tag quay.io/openshift/okd:4.19.0 harbor.example.com/okd/okd:4.19.0. This tag tells the container runtime to push the image to the okd project in your Harbor registry. Pay close attention to the tagging process, as a mistake here can cause issues later on. Double-check the registry address, project name, and image name to ensure they're correct. With each image pulled and tagged, you're one step closer to having all the necessary components in your private registry. So, keep up the momentum and let's get those images prepped for their new home in Harbor!

Pushing Images to Harbor

Alright, we've pulled the images and tagged them – now it's time for the final push! Pushing the images to Harbor is the last leg of the mirroring journey, and it's where we actually transfer the images to our private registry. Think of it as delivering the ingredients to the kitchen. To push an image to Harbor, you'll use the podman push or docker push command, depending on your container runtime. The command is straightforward: podman push <image_name> or docker push <image_name>, where <image_name> is the tagged image name that includes your Harbor registry's address and project. For example, if you tagged an image as harbor.example.com/okd/okd:4.19.0, you would push it using podman push harbor.example.com/okd/okd:4.19.0. As you push each image, keep an eye on the output of the command. It should show the progress of the upload, including the layers being transferred. If you encounter any errors, address them immediately. Common issues include incorrect credentials, network connectivity problems, or insufficient storage in Harbor. Once an image is successfully pushed, verify that it appears in your Harbor registry's web interface. This is a good way to confirm that the push was successful and that the image is stored correctly. As you work through the list of images, keep track of your progress. You might want to mark off each image as you push it to avoid accidentally skipping one. If you have a large number of images to push, consider using a script to automate the process. This can save you a lot of time and effort. With all the images pushed to Harbor, you've successfully mirrored the necessary components for your OKD 4.19 installation. This is a major milestone, so give yourself a pat on the back! Now, let's move on to the next phase: configuring OKD to use your private registry.

Installing OKD 4.19 in Air-Gapped Mode

Okay, guys, the moment we've been waiting for is here! Now that we've got our images mirrored in Harbor, it's time to install OKD 4.19 in air-gapped mode. This is where we bring all our preparations together and build our single-node cluster. The installation process involves several key steps, including generating the installation configuration, configuring OKD to use our private registry, and deploying the cluster. First, we'll need to create an installation configuration file. This file tells OKD how to set up the cluster, including details like the network configuration, the number of nodes, and the image registry to use. You can generate this file using the oc adm create install-config command. Next, we'll need to modify the configuration file to point OKD to our private Harbor registry. This ensures that OKD pulls images from Harbor instead of trying to access the public registry. This involves setting the imageContentSources parameter in the configuration file. Once the configuration file is set up, we can deploy the cluster using the oc adm install command. This command will kick off the installation process, which can take some time depending on your hardware and network. As the installation progresses, keep an eye on the logs for any errors. If you encounter issues, troubleshoot them promptly. With a little patience and attention to detail, you'll soon have your single-node OKD 4.19 cluster up and running in your air-gapped environment. So, let's dive in and make it happen!

Generating the Installation Configuration

Let's kick off the actual installation by generating the installation configuration. This configuration file is like the blueprint for your OKD cluster; it tells the installer everything it needs to know about how you want your cluster set up. The primary tool we'll use for this is the oc adm create install-config command, which is part of the OpenShift CLI. This command will generate a basic configuration file that you can then customize to fit your needs. Before running the command, make sure you're in a directory where you want to store the configuration files. The command will create a directory named openshift in your current directory, and it will contain two important files: install-config.yaml and kubeconfig. The install-config.yaml file is the one we'll be working with most directly. To run the command, simply type oc adm create install-config --dir=<directory_name> in your terminal, replacing <directory_name> with the name of the directory you want to use. The command will then prompt you for some basic information about your cluster, such as the platform you're installing on, the network type, and the pull secret. Since we're installing in an air-gapped environment, you'll need to provide a pull secret that allows you to access the necessary container images. If you don't have a pull secret, you can create one from your Red Hat account. Once you've provided all the required information, the command will generate the install-config.yaml file. Now, before we move on, let's take a moment to inspect the generated file. Open it in a text editor and take a look at the various settings. You'll see things like the cluster name, the base domain, and the networking configuration. We'll be modifying some of these settings in the next step to configure OKD to use our private registry. So, let's get familiar with the configuration file and prepare to tailor it to our air-gapped environment.

Configuring OKD to Use Your Private Registry

Now comes a crucial step in our air-gapped installation: configuring OKD to use your private registry. This is where we tell OKD to pull images from our Harbor registry instead of trying to reach out to the public internet. To do this, we'll need to modify the install-config.yaml file that we generated in the previous step. Open the install-config.yaml file in a text editor. We're looking for a section called imageContentSources. If this section doesn't exist, you'll need to add it. The imageContentSources section is an array of objects, where each object specifies a source registry and a list of mirrors. We'll add an object that points to our Harbor registry and lists the public registries that we're mirroring. Here's an example of what the imageContentSources section might look like:

imageContentSources:
 - mirrors:
 - harbor.example.com/okd
 source: quay.io
 - mirrors:
 - harbor.example.com/okd
 source: registry.k8s.io

In this example, we're telling OKD that when it needs to pull an image from quay.io or registry.k8s.io, it should instead pull it from our Harbor registry at harbor.example.com/okd. Make sure to replace harbor.example.com/okd with the actual address of your Harbor registry and the name of your project. You'll need to add entries for all the public registries that OKD might try to access, such as quay.io, registry.k8s.io, and docker.io. Once you've added the imageContentSources section, save the install-config.yaml file. Next, we'll need to generate the manifests and ignition configs, which are the actual instructions that the OKD installer will use to set up the cluster. We'll do this using the oc adm release extract command. This command takes the install-config.yaml file as input and generates the necessary files. With the imageContentSources configured and the manifests generated, OKD is now properly set up to use your private registry. This is a critical step in ensuring a successful air-gapped installation. So, double-check your configuration and let's move on to the deployment!

Deploying the OKD Cluster

With our configuration set and images mirrored, it's finally time to deploy the OKD cluster! This is the exciting part where we bring everything together and watch our single-node cluster come to life. The primary tool we'll use for this is the oc adm install command, which is the workhorse of the OKD installation process. Before we run the command, make sure you're in the directory where you generated the installation configuration files, specifically the openshift directory. Also, ensure that your workstation has network connectivity to the machine where you're installing OKD. To start the installation, simply run the command oc adm install --dir=openshift. This tells the installer to use the configuration files in the openshift directory to set up the cluster. The installation process can take some time, typically ranging from 30 minutes to a couple of hours, depending on your hardware and network. During the installation, the oc adm install command will print out a stream of logs to your terminal. Keep a close eye on these logs, as they can provide valuable information about the progress of the installation and any potential issues. If you encounter any errors, don't panic! The logs should give you some clues about what went wrong. Common issues include network connectivity problems, incorrect image registry settings, or insufficient resources. If you're unsure how to troubleshoot an error, consult the OKD documentation or the OKD community forums for assistance. Once the installation is complete, the oc adm install command will print a success message, along with instructions on how to access the OKD web console and CLI. Congratulations, you've successfully deployed your single-node OKD 4.19 cluster in air-gapped mode! Now, let's move on to the final step: verifying the installation.

Verifying the Installation

Alright, we've deployed our OKD 4.19 cluster in air-gapped mode, but we're not done just yet! The final step is to verify the installation to make sure everything is working as expected. This is like the taste test after you've finished cooking – you want to make sure the dish is just right. There are several things we can check to verify the installation. First, let's access the OKD web console. The oc adm install command should have printed out the URL for the console at the end of the installation process. Open a web browser and navigate to that URL. You should see the OKD login page. Log in using the credentials you specified during the installation process. Once you're logged in, explore the console and make sure you can navigate around and see the various components of the cluster. Next, let's use the OpenShift CLI (oc) to check the status of the cluster. Open a terminal and log in to the cluster using the oc login command. The oc adm install command should have also printed out the oc login command to use. Once you're logged in, run the command oc get nodes. This will show you the status of the nodes in your cluster. You should see your single-node listed with a status of Ready. You can also check the status of the OKD operators by running the command oc get co. This will show you the status of the cluster operators, which are responsible for managing various aspects of the cluster. All the operators should have a status of True. Another important thing to check is that OKD is pulling images from your private Harbor registry. You can do this by creating a new project and deploying a simple application. When the application is deployed, check the logs to make sure the images are being pulled from your Harbor registry. By performing these verification steps, you can be confident that your OKD 4.19 cluster is installed correctly and is functioning as expected. Congratulations on successfully installing OKD in air-gapped mode! You've conquered a challenging task, and you're now ready to start deploying applications and exploring the power of OKD.

Accessing the OKD Web Console

Let's talk about accessing the OKD web console, which is your graphical interface for managing and monitoring your cluster. Think of it as the dashboard of your OKD installation, providing a visual overview of everything happening in your environment. After a successful OKD installation, the oc adm install command typically prints out the URL for the web console. It looks something like https://console-openshift-console.apps.<your_domain>. If you missed it, don't worry! You can also find the console URL by running the command oc cluster-info and looking for the openshift-console link. Once you have the URL, open a web browser and navigate to it. You'll likely see a warning about an untrusted certificate, especially if you're using a self-signed certificate. This is normal in air-gapped environments, as you're not relying on a public certificate authority. You can safely proceed by adding an exception for the certificate in your browser. On the login page, you'll need to provide your credentials. The default username is kubeadmin, and the password can be retrieved by running the command oc get secrets -n openshift-config kubeadmin -o jsonpath='{.data.password}' | base64 -d. This command fetches the kubeadmin password from a secret in the openshift-config namespace. Once you're logged in, you'll be greeted by the OKD web console. The console provides a wealth of information about your cluster, including the status of nodes, deployments, pods, and services. You can use the console to manage your cluster, deploy applications, and monitor resource usage. Take some time to explore the console and familiarize yourself with its various features. The OKD web console is a powerful tool for managing your cluster, and it's an essential part of your air-gapped OKD experience. So, get comfortable with it and start leveraging its capabilities!

Checking Node and Operator Status

Now, let's dive into checking the node and operator status within your newly installed OKD 4.19 cluster. This is like taking the vital signs of your cluster to ensure everything is healthy and functioning correctly. We'll primarily use the OpenShift CLI (oc) for this task, as it provides a wealth of information about the state of your cluster. First, let's check the status of the nodes. Nodes are the worker machines in your cluster where your applications run. To get a list of nodes and their status, run the command oc get nodes. You should see your single-node listed, and its status should be Ready. If the status is anything else, such as NotReady or Unknown, there might be an issue with the node that needs to be investigated. Next, let's check the status of the cluster operators. Cluster operators are components that manage various aspects of the cluster, such as networking, storage, and authentication. To get a list of cluster operators and their status, run the command oc get co. This will show you a list of operators, along with their current state. Ideally, all operators should have a status of True, indicating that they're functioning correctly. If any operator has a status of False, it means there's an issue with that component that needs to be addressed. You can get more detailed information about a specific operator by running the command oc describe co <operator_name>, replacing <operator_name> with the name of the operator you want to inspect. This will show you events and logs related to the operator, which can help you diagnose any problems. Regularly checking the node and operator status is a good practice for maintaining a healthy OKD cluster. It allows you to quickly identify and address any issues that might arise, ensuring the smooth operation of your applications. So, make it a part of your routine and keep your cluster running in tip-top shape!

Verifying Image Pulls from Harbor

Alright, we're in the home stretch of our verification process! Let's focus on verifying that OKD is pulling images from your private Harbor registry. This is crucial in an air-gapped environment to ensure that your cluster isn't trying to access external registries. To verify this, we'll deploy a simple application and then check where its images are being pulled from. First, create a new project in OKD using the command oc new-project test-image-pull. This will create a new namespace where we can deploy our test application. Next, let's deploy a simple application, like a basic Nginx web server. You can do this using a Deployment and a Service. Here's an example of a Deployment manifest:

apiVersion: apps/v1
kind: Deployment
metadata:
 name: nginx-test
 namespace: test-image-pull
spec:
 replicas: 1
 selector:
 matchLabels:
 app: nginx-test
template:
 metadata:
 labels:
 app: nginx-test
 spec:
 containers:
 - name: nginx
 image: nginx:latest

Save this manifest to a file named nginx-deployment.yaml and apply it using the command oc apply -f nginx-deployment.yaml -n test-image-pull. Now, let's create a Service to expose the Nginx deployment. Here's an example Service manifest:

apiVersion: v1
kind: Service
metadata:
 name: nginx-test
 namespace: test-image-pull
spec:
 ports:
 - port: 80
 targetPort: 80
 selector:
 app: nginx-test
type: ClusterIP

Save this manifest to a file named nginx-service.yaml and apply it using the command oc apply -f nginx-service.yaml -n test-image-pull. Once the application is deployed, let's check the logs of the Pod to see where the image was pulled from. Run the command oc get pods -n test-image-pull to get the name of the Pod. Then, run the command oc logs <pod_name> -n test-image-pull, replacing <pod_name> with the name of your Pod. In the logs, look for messages related to pulling the image. You should see that the image was pulled from your Harbor registry, not from a public registry like Docker Hub. If you see that the image was pulled from your Harbor registry, congratulations! You've successfully verified that OKD is using your private registry. This is the final piece of the puzzle in our air-gapped installation process. You've done a fantastic job, guys! Now, you can confidently start deploying your applications in your secure, air-gapped OKD environment.

Conclusion

And there you have it, guys! We've walked through the entire process of installing OKD 4.19 in an air-gapped environment, from preparing your environment to verifying the installation. We covered setting up your Harbor registry, mirroring the necessary images, configuring OKD to use your private registry, and deploying your single-node cluster. It's been a journey, but hopefully, this guide has made the process clear and manageable for you. Installing OKD in an air-gapped environment can be challenging, but it's also incredibly rewarding. You've now built a secure and isolated platform for running your containerized applications. Remember, the key to a successful air-gapped installation is meticulous planning and attention to detail. Make sure you have all the necessary prerequisites in place, follow the steps carefully, and don't hesitate to consult the OKD documentation or community forums if you run into any issues. With your OKD cluster up and running, you're now ready to explore the power and flexibility of this amazing platform. Start deploying your applications, experiment with different features, and enjoy the benefits of running your own private cloud. Thanks for joining me on this journey, and happy OKD-ing!