Decoding the OpenShift Journey: Understanding the Corresponding Terms in OpenShift and Kubernetes (2)

When diving into the world of container orchestration, it’s not uncommon for beginners to get overwhelmed with the sea of terminologies, especially when you are juggling between two closely related platforms: OpenShift and Kubernetes. Both are powerful in their own right, and while OpenShift is built on top of Kubernetes, they each have their unique set of terms.

In this blog post, we’ll demystify some of these terminologies by drawing parallels between OpenShift and Kubernetes. Here’s a list of corresponding terms and how they differentiate:

Project vs. Namespace

• OpenShift: Project
  - It is essentially a Kubernetes namespace with additional annotations.
  - Provides an isolation for resources, which is useful in multi-tenant environments.
  - Enforces a unique name across the cluster.
• Kubernetes: Namespace
  - Used to segment cluster resources between multiple users.
  - Does not come with additional annotations by default.

In Kubernetes, an annotation is a way to attach arbitrary, non-identifying metadata to objects. Unlike labels, which are used to identify and select objects, annotations are not used to select or group objects. Instead, they’re primarily intended to store metadata that provides additional information or context about an object.

Route vs. Ingress

• OpenShift: Route
  - A method to expose a service at a host name.
  - Provides features like path-based routing, SSL/TLS termination, and load balancing.
• Kubernetes: Ingress
  - An API object that manages external access to services within a cluster.
  - Typically requires an Ingress Controller (e.g., Nginx, Traefik) to work.

DeploymentConfig vs. Deployment

• OpenShift: DeploymentConfig
  - A proprietary OpenShift object
  - Supports additional features like hooks during the lifecycle of application deployment.
• Kubernetes: Deployment
  - Provides declarative updates for Pods and ReplicaSets.
  - Automatically handles rolling updates.

ImageStream vs. Docker Image

• OpenShift: ImageStream
  - Represents a series of related Docker images, typically versions of the same application.
• Kubernetes: Refers directly to Docker Images via fully qualified domain names.

BuildConfig vs. CI /CD Pipelines

• OpenShift: BuildConfig
  - Describes a single build definition and a set of triggers for when a new build should be created.
• Kubernetes: Does not have a direct counterpart. However, CI/CD integrations like Jenkins or Argo can provide similar functionality.

S2I (Source-to-Image) vs. Container Building Tools

• OpenShift: S2I
  - A tool for building reproducible container images from source code.
  - Injects source code into a container image and produces a new, ready-to-run image.
• Kubernetes: Relies on external container building tools like Docker.

OC CLI vs. Kubectl CLI

• OpenShift: OC CLI
  - A specific command-line interface tailored for OpenShift.
  - Provides functionalities to manage both Kubernetes and OpenShift-specific resources.
• Kubernetes: Kubectl CLI
  - A command-line tool to interact with a Kubernetes cluster.

This primer scratches the surface of the expansive universe of OpenShift and Kubernetes. Remember, OpenShift builds upon Kuberentes, leading to significant overlap. Grasping the differences and similarities between their terms can boost your confidence in stand-up meetings and improve your conversations about both platforms. As you dive deeper and understand these nuances, you’ll find navigating the orchestration landscape becomes smoother. Continue your learning journey, and happy orchestrating!