OpenShift Interview Questions and Answers

OpenShift is a cloud development Platform as a Service (PaaS) hosted by Red Hat. It’s an open source technology which helps organizations move their traditional application infrastructure and platform from physical, virtual mediums to the cloud. It supports a very large different of applications, which can be easily developed and deployed on OpenShift cloud platform.

OpenShift provides a common platform for enterprise units to host their applications on cloud without worrying about the underlying operating system. This makes it very easy to use, develop, and deploy applications on cloud. One of the key features is, it provides managed hardware and network resources for all kinds of development and testing. With OpenShift, PaaS developer has the freedom to design their required environment with specifications.

There are different features supported by Open Shift.

• Openshift has rich command line toolset.
• Multiple database and Language Support
• Provides support for continuous integration and release management.
• Extensible Cartridge System
• One-Click Deployment
• Multi Environment Support
• Standardized Developers’ workflow
• Automatic Application Scaling
• Responsive Web Console
• Rich Command-line Toolset
• Provide support for remote SSH login to application.
• Rest API Support
• Self-service on Demand Application Stack
• Remote Debugging of Applications
• Built-in Database Services
• Continuous Integration and Release Management
• IDE Integration

OpenShift Origin is the upstream community project used in OpenShift Online, OpenShift Dedicated, and OpenShift Container Platform. Built around a core of Docker container packaging and Kubernetes container cluster management, Origin is augmented by application lifecycle management functionality and DevOps tooling. Origin provides an open source application container platform. All source code for the Origin project is available under the Apache License (Version 2.0) on GitHub.

OpenShift Online is Red Hat’s public cloud application development and hosting service. It is an offering of OpenShift community using which one can quickly build, deploy, and scale containerized applications on the public cloud. It is Red Hat’s public cloud application development and hosting platform, which enables automated provisioning, management and scaling of application which helps the developer focus on writing application logic.

OpenShift Dedicated is Red Hat’s managed private cluster offering, built around a core of application containers powered by Docker, with orchestration and management provided by Kubernetes, on a foundation of Red Hat Enterprise Linux. It’s available on the Amazon Web Services (AWS) and Google Cloud Platform (GCP) marketplaces.

OpenShift Enterprise by Red Hat is a Platform as a Service (PaaS) that provides developers and IT organizations with an auto-scaling, cloud application platform for deploying new applications on secure, scalable resources with minimal configuration and management overhead. OpenShift Enterprise supports a wide selection of programming languages and frameworks, such as Java, Ruby, and PHP. Integrated developer tools, such as Eclipse integration, JBoss Developer Studio, and Jenkins, support the application life cycle.

In OpenShift Routes is a way to externalize the services by providing externally reachable hostname. In OpenShift routes are created using routers developed by admin.

In this from source code images are created. In Source-to-image strategy source code is downloaded and compiled and deployed in same container. From same code image is created.

OpenShift Container Platform (formerly known as OpenShift Enterprise) is Red Hat’s on-premises private platform as a service product, built around a core of application containers powered by Docker, with orchestration and management provided by Kubernetes, on a foundation of Red Hat Enterprise Linux.

OpenShift automates source code management, application builds, deployments, scaling, health management and more.

A pod is collection of containers and its storage inside a node of a Kubernetes cluster. It is possible to create a pod with multiple containers inside it. Following is an example of keeping a database container and web interface container in the same pod.

A deployment strategy is a way to change or upgrade an application. The aim is to make the change without downtime in a way that the user barely notices the improvements. The most common strategy is to use a blue-green deployment. The new version (the blue version) is brought up for testing and evaluation, while the users still use the stable version (the green version). When ready, the users are switched to the blue version. If a problem arises, you can switch back to the green version.

A rolling deployment slowly replaces instances of the previous version of an application with instances of the new version of the application. A rolling deployment typically waits for new pods to become ready via a readiness check before scaling down the old components. If a significant issue occurs, the rolling deployment can be aborted.

All rolling deployments in OpenShift Origin are canary deployments; a new version (the canary) is tested before all of the old instances are replaced. If the readiness check never succeeds, the canary instance is removed and the deployment.

A deployment is completed by a pod that consumes resources (memory and CPU) on a node. By default, pods consume unbounded node resources. However, if a project specifies default container limits, then pods consume resources up to those limits. Another way to limit resource use is to (optionally) specify resource limits as part of the deployment strategy.

The Blue/Green deployment strategy minimizes the time it takes to perform a deployment cutover by ensuring you have two versions of your application stacks available during the deployment. We can make use of the service and routing tiers to easily switch between our two running application stacks—hence it is very simple and fast to perform a rollback.

In OpenShift master has inbuilt OAuth server which generates tokens that can be used for API authentication.

On OpenShift, if your application is scalable, HAProxy sits in front of it and accepts all incoming connections. It parses the HTTP protocol and decides which application instance the connection should be routed to. This is important as it allows the user to have sticky sessions.

Feature toggles are a technique where both versions of your feature are included in the same code base, but are surrounded by logic to execute on or the other based on external factors such as a property value or database switch. This is a useful technique to separate the deploy from usage in any setup, multiple server groups, single group and legacy monoliths.

The Downward API is a mechanism whereby pods can retrieve their metadata without having to call into the Kubernetes API. The following metadata can be retrieved and used to configure the running pods:

• Labels
• Annotations
• Pod name, namespace, and IP address
• Pod CPU/memory request and limit information
• Certain information can be mounted into the pod as an environment variable, whereas other information can be accessed as files within a volume.

OpenShift CLI is used for managing OpenShift applications from the command line. OpenShift CLI has the capability to manage end-to-end application life cycle. In general, we would be using OC which is an OpenShift client to communicate with OpenShift. OpenShift CLI is capable of performing all basic and advance configuration, management, addition, and deployment of applications.

In OpenShift application, auto scaling is also known as pod auto scaling. There are two types of application scaling as follows.

• Up (vertical scaling)
• Out (horizontal scaling)

Imagine you have a successful start-up and your user base is growing. As the user base expands, application load and demand increases. To keep up with this demand you either need to add servers (horizontal scaling) or get bigger ones (vertical scaling).

Vertical Scaling: To accommodate higher load using vertical scaling, your application remains in one place and you give it more resources. For example, you might add a larger machine with more CPUs, faster CPUs, memory, or disk space. Cost continues to rise as you add more hardware resources.

Horizontal Scaling: To accommodate higher load using horizontal scaling, multiple instances of an application are created and the application load is balanced across independent nodes. This has several advantages because you can:
Use ordinary hardware and thus keep the price of your hardware use reasonable Deploy hundreds or thousands of nodes and load balance the application between them

Docker helps to create lightweight liner based container while Kubernetes helps in orchestrating and managing containers. OpenShift is built on top of Docker and Kubernetes. All the containers are built on top of Docker cluster, which is basically Kubernetes service on top of Linux machines, using Kubernetes orchestrations feature. In this process, we build Kubernetes master which controls all the nodes and deploys the containers to all the nodes. The main function of Kubernetes is to control OpenShift cluster and deployment flow using a different kind of configuration file. As in Kubernetes, we use kubctl in the same way we use OC command line utility to build and deploy containers on cluster nodes.

• HTTPassword
• LDAP
• Allow ALL
• Deny All
• Basic Authentication

OpenShift security is mainly a combination of two components that mainly handles security constraints.

Security Context Constraints (SCC): It is basically used for pod restriction, which means it defines the limitations for a pod, as in what actions it can perform and what all things it can access in the cluster.

Service Account: Service accounts are basically used to control access to OpenShift master API, which gets called when a command or a request is fired from any of the master or node machine.

It can be defined as server with certain specification like memory, CPU. It is fundamental unit for running an application

Volume security clearly means securing the PV and PVC of projects in OpenShift cluster. There are mainly four sections to control access to volumes in OpenShift.

• Supplemental Groups
• fsGroup
• runAsUser
• seLinuxOptions

In OpenShift, Labels are identifying metadata consisting of key/value pairs attached to resources. Labels are used to add identifying attributes to objects that are relevant to users and can be used to reflect architectural or organizational concepts. Labels can be used in conjunction with label selectors to uniquely identify individual resources or groups of resources.

Examples:

• Release
• Environment
• Relationship
• DMZBased
• Tier
• Node types
• User type

OpenShift Pipelines give you control over building, deploying, and promoting your applications on OpenShift. Using a combination of the Jenkins Pipeline Build Strategy, Jenkins files, and the OpenShift Domain Specific Language (DSL) (provided by the OpenShift Jenkins Client Plug-in), you can create advanced build, test, deploy, and promote pipelines for any scenario.