On Premise vs.

Cloud

Cloud computing has grown very popular for enterprises, everything from
saving time and money to improving agility and scalability. On the other hand, on-
premise software – installed on a company’s own servers and behind its firewall –
was the only offering for organizations for a long time and may continue to adequately
serve your business needs. Additionally, on-premise applications are reliable, secure,
and allow enterprises to maintain a level of control that the cloud often cannot.

On-premise software requires that an enterprise purchases a license or a copy

of the software to use it. The entire instance of software resides within an
organization’s premises, there is generally greater protection than with a cloud
computing infrastructure. So, if a company needs all this extra security, why would
they dip its proverbial toes into the cloud? The downside of on-premise environments
is that costs associated with managing and maintaining all the solution entails can run
exponentially higher than a cloud computing environment. An on-premise setup
requires in-house server hardware, software licenses, integration capabilities, and IT
employees on hand to support and manage potential issues that may arise.

In a cloud environment, a third-party provider hosts everything for you. This

allows companies to pay on an as-needed basis and effectively scale up or down
depending on overall usage, user requirements, and the growth of a company.

Key differences also include:

1. Deployment
2. Cost
3. Control
4. Security
5. Compliance
IAAS, PAAS, SAAS:
Basics

Containerization: Containerization involves the packaging of software code and all

related dependencies for running uniformly without any issues on any infrastructure.
Containerization is generally assumed as a supporting element or alternative for
virtualization.

Traditional methods involved code development in a particular computing

environment, and transfer of code development to a new environment resulted in
errors and bugs. Containerization deals with this problem through bundling of the
application code with configuration files, dependencies, and libraries for running it.
Containers virtualize the operating system instead of hardware. Containers are more
portable and efficient.

Compatibility issue gave rise to the origin of containers.

Container: A container is a standard unit of software that packages up code and all its
dependencies so the application runs quickly and reliably from one computing
environment to another.
 Containers take up less space than VMs (container images are typically tens of
MBs in size), can handle more applications and require fewer VMs and Operating
systems. Virtual machines (VMs) are an abstraction of physical hardware turning one
server into many servers. The hypervisor allows multiple VMs to run on a single
machine. Each VM includes a full copy of an operating system, the application,
necessary binaries and libraries - taking up tens of GBs. VMs can also be slow to boot.

Dockers (platform-as-a-service): Docker is an open-source software designed to

facilitate and simplify application development. It is a set of platform-as-a-service
products that create isolated virtualized environments for building, deploying, and
testing applications. There are various types of containers LXC, LXD, LXCFS etc.
Docker uses LXC containers. We cannot run windows based container in a linux
environment.

Images can exist without containers, whereas a container needs to run an image
to exist. Therefore, containers are dependent on images and use them to construct a
run-time environment and run an application.

A Docker container image is a lightweight, standalone, executable package of

software that includes everything needed to run an application: code, runtime, system
tools, system libraries and settings. Container images become containers at runtime
and in the case of Docker containers - images become containers when they run on
Docker Engine.

Kubernetes (Container as a service): Kubernetes is a container orchestration system.

It provides an open-source toolkit for the creation of a fault-tolerant scalable platform
meant for automation and central management of containers. The other features
include sturdy container deployment, effective persistence in storage, and multi-cloud
support. You can also find Kubernetes as a promising instrument for monitoring
container health and management of computing resources. The support of auto-scaling
features and real-world use cases can simplify the applications of Kubernetes, thereby
raising its popularity. If a container goes down, another container needs to start.
Wouldn't it be easier if this behavior was handled by a system? That's how Kubernetes
comes to the rescue! Kubernetes provides you with a framework to run distributed
systems resiliently. It takes care of scaling and failover for your application, provides
deployment patterns, and more.

Orchestration: IT teams must manage many servers and applications, but doing so
manually isn’t a scalable strategy. The need to combine multiple automated tasks and
their configurations across groups of systems or machines increases. That’s where
orchestration can help.

Ansible is an open-source automation tool, or platform, used for IT tasks such

as configuration management, application deployment, intra-service orchestration, and
provisioning. Automation frees up time and increases efficiency. And Ansible, as
noted above, is rapidly rising to the top in the world of automation tools.

Automation: While automation refers to a single task, orchestration arranges tasks to

optimize a workflow.
OpenShift

OpenShift is a platform that allows you to run containerized applications and

workloads and is powered by Kubernetes & Docker undercover. It is an open source
development platform, which enables the developers to develop and deploy their
applications on cloud infrastructure.

OpenShift is capable of managing applications written in different languages,

such as Node.js, Ruby, Python, Perl, and Java. OpenShift supports a very large variety
of applications, which can be easily developed and deployed on OpenShift cloud
platform.

https://www.youtube.com/watch?v=KTN_QBuDplo&t=59s

Architecture

1. Infrastructure layer: Also knows as base layer, where you can host your applications on
physical servers, virtual servers, or even on the cloud (private/public).
2. Service layer: The service layer is responsible for defining pods and access policy. The
service layer provides a permanent IP address and host name to the pods; connects
applications together; and allows simple internal load balancing, distributing tasks across
application components.
3. Master

The Main node is responsible for managing the cluster, and it takes care of the worker
nodes. It has four components:

(a) Etcd/ Data Store: It stores the configuration information, which can be used by each
of the nodes in the cluster.

(b) API Server: The Kubernetes API server validates and configures the data for
pods, services, and replication controllers. Any administration request goes through the
API; these requests are SSL-encrypted and authenticated to ensure the security of the
cluster. It also assigns pods to nodes and synchronizes pod information with service
configuration.

(c) Controller Manager Server: This component is responsible for most of the collectors
that regulate the state of the cluster and perform a task. It can be considered as a
daemon which runs in a non-terminating loop. The key controllers are replication
controller, endpoint controller, namespace controller, and service account controller.
The controller manager runs different kind of controllers to handle nodes, endpoint, etc.

I. Replication controller: A replication controller ensures that a specified number

of replicas of a pod are running at all times. If pods exit or are deleted, the replica
controller acts to instantiate more up to the desired number. Likewise, if there are
more running than desired, it deletes as many as necessary to match the number.
II. Health & Saclaing: Monitors the health of pods and scales them based on CPU
utilization. If a pod fails, the main node restarts it automatically. If it fails too
often, it is marked as a bad pod and is not restarted for a temporary time.

(d) Scheduler: It is a service in master which is responsible for distributing the

workload. It is responsible for tracking the utilization of working load on cluster nodes
and then placing the workload on which resources are available and accepting the
workload. In other words, this is the mechanism responsible for allocating pods to
available nodes. The scheduler is responsible for workload utilization and allocating
a pod to a new node.
4. Worker nodes: The worker node is made of pods. A pod is the smallest unit that can be
defined, deployed, and managed, and it can contain one or more containers. These
containers include your applications and their dependencies.
5. Registry: It is a place where all images are saved locally. OpenShift Container Platform
can utilize any server implementing the container image registry API as a source of
images, including the Docker Hub, private registries run by third parties, and the
integrated OpenShift Container Platform registry.
6. Persistent Storage

Managing storage is a distinct problem from managing compute resources. OpenShift

Container Platform uses the Kubernetes persistent volume (PV) framework to allow
cluster administrators to provision persistent storage for a cluster. Developers can use
persistent volume claims (PVCs) to request PV resources without having specific
knowledge of the underlying storage infrastructure.

PVCs are specific to a project, and are created and used by developers as a means to
use a PV. PV resources on their own are not scoped to any single project; they can be
shared across the entire OpenShift Container Platform cluster and claimed from
any project. After a PV is bound to a PVC, that PV cannot then be bound to additional
PVCs. This has the effect of scoping a bound PV to a single namespace, that of the
binding project.

7. Routing layer: This represents all the routes created for different applications where
incoming traffic will pass through routing layer.

https://www.youtube.com/watch?v=0swOh5C3OVM

8. Kubernetes Node: Following are the key components of the Node server, which are
necessary to communicate with the Kubernetes master.

(a) Docker: The first requirement of each node is Docker which helps in running the
encapsulated application containers in a relatively isolated but lightweight operating
environment.

(b) Kubelet Service: This is a small service in each node, which is responsible for relaying
information to and from the control plane service. It interacts with etcd store to read the
configuration details and Wright values. This communicates with the master
 component to receive commands and work. Each node has a kubelet that updates the
node as specified by a container manifest, which is a YAML file that describes a pod.

(c) Kubernetes Proxy Service: This is a proxy service which runs on each node and helps
in making the services available to the external host. It helps in forwarding the request to
correct containers. Kubernetes Proxy Service is capable of carrying out primitive load
balancing. It makes sure that the networking environment is predictable and accessible
but at the same time it is isolated as well. It manages pods on node, volumes, secrets,
creating new containers health checkup, etc.

9. Infrastructure nodes: are nodes that are labeled to run pieces of the OpenShift
Container Platform environment.
Currently, the easiest way to manage node reboots is to ensure that there are at least three
nodes available to run infrastructure. The scenario below demonstrates a common mistake
that can lead to service interruptions for the applications running on OpenShift Container
Platform when only two nodes are available.

Node A is marked unschedulable and all pods are evacuated. The registry pod running on
that node is now redeployed on node B. This means node B is now running both registry
pods. Node B is now marked unschedulable and is evacuated. The service exposing the
two pod endpoints on node B, for a brief period of time, loses all endpoints until they are
redeployed to node A.

The same process using three infrastructure nodes does not result in a service
disruption. However, due to pod scheduling, the last node that is evacuated and brought
back in to rotation is left running zero registries. The other two nodes will run two and
one registries respectively.

Terminologies:

 Image − Kubernetes (Docker) images are the key building blocks of Containerized
Infrastructure. Each container in a pod has its Docker image running inside it. When
configuring a pod, the image property in the configuration file has the same syntax as
the Docker command (YAML or JSON files).
 Project − they can be defined as the renamed version of the domain which was present
in the earlier version of OpenShift V2.
 Container − they are the ones which are created after the image is deployed on a
Kubernetes cluster node.
 Node − A node is a working machine in Kubernetes cluster, which is also known as
minion for master. They are working units which can a physical, VM, or a cloud
instance.
 Pod − A pod is a 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. For example,
keeping the database container and web server container inside the pod
 Two services should be running all the time
(a) Docker Service (b) Atomic open-shift node service
Pods

Pods are the smallest, most basic deployable objects. A Pod represents a single
instance of a running process in your cluster. Pods contain one or more containers,
such as Docker containers. When a Pod runs multiple containers, the containers are
managed as a single entity and share the Pod's resources. Each pod is allocated its own
internal IP address, therefore owning its entire port space, and containers within pods
can share their local storage and networking. Containers in a Pod communicate with
each other inside the Pod on localhost. Pods can specify a set of shared storage
volumes that can be shared among the containers.

Lifecycle of pods

A Pod can be in one of the following possible phases:

 Pending: Pod has been created and accepted by the cluster, but one or more
of its containers are not yet running. This phase includes time spent being
scheduled on a node and downloading images.
 Running: Pod has been bound to a node, and all of the containers have
been created. At least one container is running, is in the process of starting,
or is restarting.
 Succeeded: All containers in the Pod have terminated successfully.
Terminated Pods do not restart.
 Failed: All containers in the Pod have terminated, and at least one container
has terminated in failure. A container "fails" if it exits with a non-zero
status.
 Unknown: The state of the Pod cannot be determined.
Secrets

The Secret object type provides a mechanism to hold sensitive information

such as passwords, OAuth tokens, and ssh keys, OpenShift Container Platform client
configuration files, docker configuration files, private source repository credentials,
and so on. Secrets decouple sensitive content from the pods.

Kubernetes Secrets are, by default, stored as unencrypted base64-encoded

strings. By default they can be retrieved - as plain text - by anyone with API access, or
anyone with access to Kubernetes' underlying data store, etcd.

A Secret can be used with a Pod in three ways:

 As files in a volume mounted on one or more of its containers.

 As container environment variable.
 By the kubelet when pulling images for the Pod.
Service Accounts

Every time you log in a user will be created, you can get the list of users from
the command oc get users. Three types of accounts user, system and service accounts.

A service account provides an identity for processes that run in a Pod.

When you (a human) access the cluster you are authenticated by the apiserver
as a particular User Account. Processes in containers inside pods can also contact the
apiserver. When they do, they are authenticated as a particular Service Account (for
example, default).

When a person uses the OpenShift Container Platform CLI or web console,
their API token authenticates them to the OpenShift API. However, when a regular
user’s credentials are not available, it is common for components to make API calls
independently. For example:

 Replication controllers make API calls to create or delete pods.

 Applications inside containers could make API calls for discovery purposes.
 External applications could make API calls for monitoring or integration
purposes.

Service accounts provide a flexible way to control API access without sharing a
regular user’s credentials. Every service account has an associated user name that can be
granted roles, just like a regular user. Applications are authorized to perform certain actions
based on the service account selected.

Three service accounts are automatically created in every project:

 Builder: Used by build pods. It is given the system:image-builder role, which

allows pushing images to any image stream in the project using the internal
Docker registry.
 Deployer: Used by deployment pods and is given the system:deployer role, which
allows viewing and modifying replication controllers and pods in the project.
  Default: Used to run all other pods unless they specify a different service account.

Operator

Stateless Application: A stateless application is one that neither reads nor stores
information about its state from one time that it is run to the next. (Automated by
control loop in Kubernetes). Suppose if one pod dies then Kubernetes automated
control will bring it up using control loop automation.

Stateful Application: A stateful application, on the other hand, can remember at least
some things about its state each time that it runs. (So storage is required). It requires
human interaction here to make decisions.

Operator replaces the human interaction with a software operator (code), all the
manual tasks will be done by program by making the decision by checking the state of
the service or replicas of them. It is a custom control loop. It can be used for creating
clusters, backups, synchronizing, checking health, monitoring logs etc. Example:
Prometheus operator, my-SQL operator etc.

Operators are built by business community or operator can be created by SDK

operator tool. They act like an extension of the software vendor’s engineering team,
watching over a Kubernetes environment (such as OpenShift Container Platform) and
using its current state to make decisions in real time.

Suppose let’s say we have databases that is scaled up we might have data
inconsistency issue if one pod goes down. In these cases we can configure operators in
openshift to take care of specific issues.

There will be operator SDK to develop the applications.

https://youtu.be/JMrxPyv9nxQ

Ex: Prometheus and Graphana.

Networking in OpenShift

The smallest unit for communication is pod not a container. Every POD has
unique IP address and containers share the network space of pods. When a pod gets
attached to node it gets its own network namespace and virtual Ethernet connection.
Pod is a host just like a PC.

Types of communication:

 container to container communication

 pod to pod communication
o Intra-node pod
o Inter-node pod
 services to pod communication
 External to service communication (using services)

Intra Pod communication: If pods are in same node then they can directly
communicate without creating a route.

Inter Pod Communication: Routing table is required so initial configuration is

required.
Services are basically collection of different pods having same set of functions. These
are the services that are accessed by the clients/users. Services are required to make a
route.

The first two type can be done using IP address and DNS names but the last two
should be done using the services. ClusterIP is the IP assigned to the service. If we
create route then the service is accessible from outside.

Services – ClusterIP, NodePort, Load balancer, Ingress.

ExternalIP: To permit external access to the service, additional externalIP addresses

that are external to cluster, can be assigned to the service. These externalIP addresses
can also be virtual IP addresses that provide highly available access to the service.

ClusterIP: is a default Kubernetes service. This service is created inside a cluster and can
only be accessed by other pods in that cluster. So basically we use this type of service when
we want to expose a service to other pods within the same cluster.

Nodeport: NodePort opens a specific port on your node/VM and when that port gets traffic,
that traffic is forwarded directly to the service. There are a few limitations and hence it’s not
advised to use NodePort. only one service per port and You can only use ports 30000-32767.

Load Balancer: This is the standard way to expose service to the internet. All the traffic on
the port is forwarded to the service. It's designed to assign an external IP to act as a load
balancer for the service. There's no filtering, no routing. LoadBalancer uses cloud service.

Software-defined networking (SDN): technology is an approach to network

management that enables dynamic, programmatically efficient network configuration in order
to improve network performance and monitoring, making it more like cloud computing than
traditional network management. The most notable difference between SDN and traditional
networking is that SDN is software-based while traditional networking is usually hardware-
based. Because it's software-based, SDN is more flexible, allowing user’s greater control and
ease for managing resources virtually throughout the control plane.
SDN is managed by plug-ins. It decouples the control plane from the data
plane. Communication with the other hosts goes through port mapping .
OpenShift Container Platform uses a software-defined networking (SDN)
approach to provide a unified cluster network that enables communication between
pods across the OpenShift Container Platform cluster.

OpenShift SDN provides three SDN plug-ins for configuring the pod network:

 The ovs-subnet plug-in is the original plug-in, which provides a "flat" pod
network where every pod can communicate with every other pod and service.
 The ovs-multitenant plug-in provides project-level isolation for pods and
services. Each project receives a unique Virtual Network ID (VNID) that
identifies traffic from pods assigned to the project. Pods from different projects
cannot send packets to or receive packets from pods and services of a different
project.
 The ovs-networkpolicy plug-in (currently in Tech Preview) allows project
administrators to configure their own isolation policies using NetworkPolicy
objects.

On an OpenShift Container Platform master, OpenShift SDN maintains a registry of

nodes, stored in etcd. When the system administrator registers a node, OpenShift SDN
allocates an unused subnet from the cluster network and stores this subnet in the
registry. When a node is deleted, OpenShift SDN deletes the subnet from the registry
and considers the subnet available to be allocated again.

OpenShift DNS: Every single pod, container will be assigned a DNS name that can
be used to communicate with the pods.

If you are running multiple services, such as frontend and backend services
for use with multiple pods, in order for the frontend pods to communicate with the
backend services, environment variables are created for user names, service IP,
and more. If the service is deleted and recreated, a new IP address can be assigned to
the service, and requires the frontend pods to be recreated in order to pick up the
updated values for the service IP environment variable. Additionally, the backend
service has to be created before any of the frontend pods to ensure that the service IP
is generated properly and that it can be provided to the frontend pods as an
environment variable.

For this reason, OpenShift has a built-in DNS so that the services can be reached by
the service DNS as well as service IP/port. OpenShift supports split DNS by running
SkyDNS on the master that answers DNS queries for services. The master listens to
port 53 by default.

This prevents having to restart frontend pods in order to pick up new services,
which creates a new IP for the service. This also removes the need to use environment
variables, as pods can use the service DNS.
Liveness & Readiness Probe OpenShift (Application Health)

In software systems, components can become unhealthy due to transient issues

(such as temporary connectivity loss), configuration errors, or problems with external
dependencies. OpenShift applications have a number of options to detect and handle
unhealthy containers.

A probe is a Kubernetes action that periodically performs diagnostics on a

running container.

Currently, two types of probes exist, each serving a different purpose:

1. Liveness Probe: A Liveness probe checks if the container in which it is

configured is still running. If the Liveness probe fails, the kubelet kills the
container, which will be subjected to its restart policy. Set a Liveness check by
configuring the template.spec.containers.livenessprobe stanza of a pod
configuration.
2. Readiness Probe: A readiness probe determines if a container is ready to
service requests. If the readiness probe fails in a container, the endpoints
controller ensures the container has its IP address removed from the endpoints
of all services. Set a readiness check by configuring the
template.spec.containers.readinessprobe stanza of a pod configuration.

Probes can be configured in 3 ways:

1. HTTP Checks: The kubelet uses a web hook to determine the healthiness of
the container
2. Container Execution Checks: The kubelet executes a command inside the
container
 3. TCP Socket Checks: The kubelet attempts to open a socket to the container.
The container is only considered healthy if the check can establish a
connection.

PV and PVC

Managing storage is a distinct problem from managing compute resources.

OpenShift Container Platform uses the Kubernetes persistent volume (PV) framework
to allow cluster administrators to provision persistent storage for a cluster. Developers
can use persistent volume claims (PVCs) to request PV resources without having
specific knowledge of the underlying storage infrastructure.

PVCs are specific to a project, and are created and used by developers as a
means to use a PV. PV resources on their own are not scoped to any single
project; they can be shared across the entire OpenShift Container Platform
cluster and claimed from any project. After a PV is bound to a PVC, that PV cannot
then be bound to additional PVCs. This has the effect of scoping a bound PV to a
single namespace, that of the binding project.

PVs are defined by a PersistentVolume API object, which represents a piece

of existing storage in the cluster,

PVCs are defined by a PersistentVolumeClaim API object, which represents

a request for storage by a developer. It is similar to a Pod in that Pods consume node
resources and PVCs consume PV resources. For example, Pods can request specific
levels of resources, such as CPU and memory, while PVCs can request specific
storage capacity and access modes. For example, they can be mounted once read-write
or many times read-only.
 https://docs.openshift.com/container-platform/4.1/storage/understanding-
persistent-storage.html#:~:text=PVCs%20are%20specific%20to%20a,and%20claimed
%20from%20any%20project.

OpenShift clusters can be provisioned with persistent storage using NFS. Persistent
volumes (PVs) and persistent volume claims (PVCs) provide a convenient method for sharing
a volume across a project. While the NFS-specific information contained in a PV definition
could also be defined directly in a pod definition, doing so does not create the volume as a
distinct cluster resource, making the volume more susceptible to conflicts.

https://www.youtube.com/watch?v=0swOh5C3OVM
What are image pull secrets?

If you are using OpenShift Container Platform’s internal registry and are
pulling from imagestreams located in the same project, then your Pod’s service
account should already have the correct permissions and no additional action should
be required. However, for other scenarios, such as referencing images across
OpenShift Container Platform projects or from secured registries, then additional
configuration steps are required.

1. Allowing Pods to reference images across projects:

When using the internal registry, to allow Pods in project-a to reference images in
project-b, a service account in project-a must be bound to the system:image-puller
role in project-b.

2. Allowing Pods to reference images from other secured registries:

The config.json file for Docker clients is a Docker credentials file that stores your
authentication information if you have previously logged into a secured or insecure
registry. To pull a secured container image that is not from OpenShift Container
Platform’s internal registry, you must create a pull secret from your Docker
credentials and add it to your service account.
Build Strategies

In OpenShift, build is a process of transforming images into containers. It is the

processing which converts the source code to an image. This build process works on
pre-defined strategy of building source code to image. To create custom build settings
edit the YAML build configuration files and import the same in builds section to make
the respective changes. Below is the list of available strategies:
1. Docker Build: This is the process in which the images are built using Docker
file by running simple Docker build command. We need to write a docker file
& commands to run & convert to image. We need to provide the docker file
along with the source code.
2. Source to Image: this is basically a tool, which helps in building
reproducible/reusable images of source code. These images are always in a
ready stage to run using the Docker run command. No need of docker
commands. It directly injects the application source code into ready-to-run
docker images using simple commands. Then these ready-to-run images
would be converted into docker containers.
3. Custom Build: these are the builds which are used for creating base Docker
images.
4. Pipeline Strategy: Providing the Jenkinsfile. Include in the build
configuration a reference to the Git repository that contains the Jenkinsfile or
provide along the application code.

Image Streams (pointers or references)

 We don’t want to build the code every time and create a docker image to it then
convert it to docker container. Sometimes we can use the readily available/custom
built docker images for specific applications (Eg: python image, ruby image, java
image) where we can directly insert the application source code to then and run them
directly to convert to docker containers. By this way we have reduced a step by not
creating a docker image for every application.

In the build configuration file we give the address/location of the source code.
But if somehow the image gets updated, then there might be issues in the performance
or problems of code. To prevent such issues, we have Image streams. Image streams
maps the actual location of the Images of source code to the image names with
the project. They are like pointers to the actual docker images not docker images
them-selves.

Image streams are created after pulling the images. The advantage of an image
stream is that it looks for updates on the new version of an image. This is used to
compare any number of Docker formatted container images identified by tags. Image
streams can automatically perform an action when a new image is created. All the
builds and deployments can watch for image action and perform an action
accordingly.
OpenShift components such as builds and deployments can watch an image
stream to receive notifications when new images are added and react by performing a
build or a deployment.

Role and Bindings

RBAC – role based access control.

Roles are collections of policy rules, which are sets of permitted verbs that can be
performed on a set of resources.

Different roles: admin, basic-user,cluster-admin,cluster-status,edit,self-

provisioner,view
 Roles can be used to grant various levels of access both cluster-wide as well as
at the project-scope. Users and groups can be associated with, or bound to, multiple
roles at the same time. You can view details about the roles and their bindings using
the oc describe command.

A role binding grants the permissions defined in a role to a user or set of users.
It holds a list of subjects (users, groups, or service accounts), and a reference to the
role being granted. A RoleBinding grants permissions within a specific namespace
whereas a ClusterRoleBinding grants that access cluster-wide.

3 components in RBAC

Roles: defines permissions boundaries.

Subjects: Users (human or an application), or user groups.

RoleBingdings: specifies which Subjects have which Roles.

Security context constraints (SCC):

In addition to authorization policies that control what a user can do, OpenShift
provides security context constraints (SCC) that control the actions that a pod can
perform and what it has the ability to access. Administrators can manage SCCs using
the CLI.

SCCs are objects that define a set of conditions that a pod must run with in order to be
accepted into the system. They allow an administrator to control the following:

 Running of privileged containers.

 Capabilities a container can request to be added.
 Use of host directories as volumes.

Two SCC are added to host by default:

The users and groups fields on the SCC control which SCCs can be used. By
default, cluster administrators, nodes, and the build controller are granted access to the
privileged SCC. All authenticated users are granted access to the restricted SCC.
Privileged SCC: allows privileged pods. Allows host directories to be mounted as
volumes. Allows a pod to run as any user. Allows a pod to run with any MCS label.

Restricted SCC: ensures pods cannot run as privileged. Ensures pods cannot use host
directory volumes. Requires that a pod run as a user in a pre-allocated range of UIDs.
Requires that a pod run with a pre-allocated MCS label.

Requests, Resource Quotas & Limits

Using quotas and limit ranges, cluster administrators can set constraints to
limit the number of objects or amount of compute resources that are used in your
project. This helps cluster administrators better manage and allocate resources across
all projects, and ensure that no projects are using more than is appropriate for the
cluster size. If not requested specifically the default values will be assigned to project.

Resource Quota: A resource quota, defined by a ResourceQuota object, provides

constraints that limit aggregate resource consumption per namespace/project. It can
limit the quantity of objects that can be created in a namespace/project by type, as well
as the total amount of compute resources and storage that may be consumed by
resources in that namespace/project.

If project modifications exceed a quota usage limit, the server denies the action. An
appropriate error message is returned explaining the quota constraint violation and the
currently observed usage stats are in the system.

Limits: A limit range, defined by a LimitRange object, enumerates compute resource

constraints in a project at the pod, container, image, image stream, and persistent
volume claim level, and specifies the amount of resources that a pod, container,
image, image stream, or persistent volume claim can consume. This capacity is not
guaranteed nor reserved also.
All resource creation and modification requests are evaluated against each LimitRange
object in the project. If the resource violates any of the enumerated constraints, then
the resource is rejected. If the resource does not set an explicit value, and if the
constraint supports a default value, then the default value is applied to the resource.

Requests: If the project/namespace requirements go outside the defaults (quotas), we

can raise a service Now request to the corresponding team and do the needy if the
requested compute resource is less than the Limits and other constraints.

Limits > Requests

Deployment Strategies

A deployment strategy determines the deployment process, and is defined by

the deployment configuration. Each application has different requirements for
availability (and other considerations) during deployments. OpenShift Container
Platform provides strategies to support a variety of deployment scenarios.

1. Rolling Strategy: The Rolling strategy is the default strategy used if no

strategy is specified on a deployment configuration. A rolling deployment
means you to have both old and new versions of your code running at the same
time. A rolling deployment slowly replaces instances of the previous version of
an application with instances of the newer 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.

When to use - When you want to take no downtime during an application

update and when your application supports having old code and new code
running at the same time.

2. Recreate Strategy: will execute any pre lifecycle hook, Scale down the
previous deployment to zero, Execute any mid lifecycle hook, Scale up the new
deployment, Execute any post lifecycle hook.
 A recreate deployment incurs downtime because, for a brief period, no
instances of your application are running. However, your old code and new
code do not run at the same time.

When to use: When you must run migrations or other data transformations
before your new code starts. When you do not support having new and old
versions of your application code running at the same time.

3. Custom Strategy: The Custom strategy allows you to provide your own
deployment behaviour.

4. Advanced Deployment Strategies:

a) Blue-Green Deployment: Blue-green deployments involve running two
versions of an application at the same time and moving production traffic
from the old version to the new version.

When to use: Use a blue-green deployment when you want to test a new
version of your application in a production environment before moving
traffic to it. Blue-green deployments make switching between two different
versions of your application easy.

b) A/B Deployment: A/B deployments generally imply running two (or more)
versions of the application code or application configuration at the same
time for testing or experimentation purposes. The simplest form of an A/B
deployment is to divide production traffic between two or more distinct
shards — a single group of instances with homogeneous configuration and
code.

When to use: When you want to test multiple versions of code or

configuration, but are not planning to roll one out in preference to the other.
When you want to have different configuration in different regions.
CLI commands

1. Must-gather: Bulk collect data about the current state of your cluster to debug issues.
$ oc adm must-gather
2. Top: Show usage statistics of resources on the server.

$ oc adm top pods and $ oc adm top images

3. Cordon: Mark a node as unschedulable. Manually marking a node as unschedulable

blocks any new pods from being scheduled on the node, but does not affect existing
pods on the node.

$ oc adm cordon node1

4. Drain: Drain a node in preparation for maintenance.

$ oc adm drain node1

5. Node-logs: Display and filter node logs.

$ oc adm node-logs --role master -u NetworkManager.service

6. Un-cordon: Mark a node as schedulable.

$ oc adm uncordon node1

Appendix
Software Tools of the Trade

Integrated development environment (IDE): An IDE is a software application that

provides comprehensive facilities to computer programmers for software
development. An IDE normally consists of at least a source code editor, build
automation tools and a debugger. Examples: Visual Studio, Eclipse, Android studio,
NetBeans, JDeveloper etc.
Version control: Version control, also known as source control, is the practice of
tracking and managing changes to software code. Version control systems are
software tools that help software teams manage changes to source code over time. As
development environments have accelerated, version control systems help software
teams’ work faster and smarter. They are especially useful for DevOps teams since
they help them to reduce development time and increase successful deployments.
Version control software keeps track of every modification to the code in a special
kind of database. If a mistake is made, developers can turn back the clock and
compare earlier versions of the code to help fix the mistake while minimizing
disruption to all team members. Example: Git, CVS, SVN, mercurial, TFS etc.

Source code management (SCM) is used to track modifications to a source code

repository. SCM tracks a running history of changes to a code base and helps resolve
conflicts when merging updates from multiple contributors. SCM is also synonymous
with Version control. Example: git, cvs, svn, mercurial,GitHub etc.

Issue tracking: Issue tracking software is a customer service tool that records
incoming support cases from start to finish. The app monitors the cases’ progress and
provides updates to the user whenever there's a change on the customer's ticket. This
ensures that service cases are completed on-time and that no customer is overlooked
by the support team. Example: Hubspot, Atlassian JIRA, Zoho, Backlog etc.

CI/CD: CI/CD is a method to frequently deliver apps to customers by introducing

automation into the stages of app development. The main concepts attributed to
CI/CD are continuous integration, continuous delivery, and continuous deployment.
CI/CD is a solution to the problems integrating new code can cause for development
and operations teams.

The "CI" in CI/CD always refers to continuous integration. Successful CI

means new code changes to an app are regularly built, tested, and merged to a shared
repository. It’s a solution to the problem of having too many branches of an app in
development at once that might conflict with each other.
 The "CD" in CI/CD refers to continuous delivery and/or continuous
deployment, which are related concepts that sometimes get used interchangeably.
Continuous delivery usually means a developer’s changes to an application are
automatically bug tested and uploaded to a repository, where they can then be
deployed to a live production environment by the operations team.

Continuous deployment (the other possible "CD") can refer to automatically

releasing a developer’s changes from the repository to production, where it is usable
by customers. It addresses the problem of overloading operations teams with manual
processes that slow down app delivery. Example: Jenkins, circleci, TeamCity,
Bamboo, GitLab etc.

Code Review: Code review is a part of the software development process which involves
testing the source code to identify bugs at an early stage. A code review process is typically
conducted before merging with the codebase. An effective code review prevents bugs and
errors from getting into your project by improving code quality at an early stage of the
software development process. Example: Github, Review Board, Crucible, CodeScene,
UpSource, Gerrit etc.

Test Management Tools: The term “Test Management” encompasses anything and
everything that testers do and take the help of a best and efficient test management software
to perform this task.

Creating and maintaining release/project cycle/component information, Creating and

maintaining the test artifacts specific to each release/cycle for which we have- requirements,
test cases, etc., Establishing traceability and coverage of the test assets, Test execution
support – test suite creation, test execution status capture, etc., Metric collection/report-graph
generation for analysis, Bug tracking/defect management.

The test management process involves the set of tasks/activities that are mentioned
above. This process is critical, detail-oriented and instrumental in order to make sure that the
entire testing effort is successful. Example: qTest, Zephyr, XQual, TestMonitor, IBM rational
quality Manager etc

Agile management tools: Agile is a project management methodology, mainly used for
software development, which is attributed to the division of a whole task into multiple
smaller tasks and attach them with the short & incremental phases of work known as sprints.
The main intention behind this approach is rapid & early delivery, frequent reassessment &
adaptive planning, continuous improvement and flexible response to change.

Agile testers need to monitor their project constantly for this management tools are
required. Example: monday.com, Jira, Zephyr, Soap UI etc.

DevOps
Error Log

1. Minishift - cannot start - Error starting the VM: Error getting the state for host: machine does
not exist error from CMD)

Solution: minishift delete --clear-cache (command), Restarting minishift will recreate all
necessary stuff.
2. Copy files from local to VirtualBox

https://www.howtogeek.com/189974/how-to-share-your-computers-files-with-
a-virtual-machine/

3. Defualt password for Ubuntu is Ubuntu.

4. Install minishift in linux
https://computingforgeeks.com/how-to-run-local-openshift-cluster-with-
minishift/
5. Insert shared drive between virtual box and local machine

https://www.howtogeek.com/189974/how-to-share-your-computers-files-with-
a-virtual-machine/
6. Network discovery turn on
https://www.google.com/search?
q=network+discovery+is+turned+off&rlz=1C1CHBF_enIN914IN914&oq=net
work+dis&aqs=chrome.0.0i457j0i20i263j69i57j0j0i20i263j0l3.4863j0j7&sour
ceid=chrome&ie=UTF-8
 7. VirtualBox fails with “Implementation of the USB 2.0 controller not found”
after upgrading
https://askubuntu.com/questions/453393/virtualbox-fails-with-implementation-
of-the-usb-2-0-controller-not-found-after

Questions And Answers

Daily Roles:
1. We used to support the application team for pre, during and post deployment issues
and support.
2. We used to perform certificate management using ECP(Enterprise cloud
platform) tool
a. Creation
b. Renewal
c. Deletion
Certificate Manager is a service that helps to manage and deploy secured public
and private digital certificates such as Secure Socket Layer/Transport Layer
Security (SSL/TLS). Certificate Manager provides a security repository of private
keys, certificates and prevents outages during certificate expiry by providing push
notifications.
3. We handled project and application deletion: For this we used to create CR for
retrievement, once done we used to notify this retrievement in ECAB and DCAB.
Deletion was done using tickr tool.
4. We used to get incidents for horizontal and vertical scaling of pods using ticker
tool. Scale up and scale down of pods in ticker tool. (Horizontal scaling is where the
number of application instances or containers is increased. Vertical scaling is where
system resources like CPU and memory are increased. Scaling can be done
automatically or manually. We can configure the vertical or horizontal auto-scalar
where you set request & limit of CPU & memory in resources in deployment
YAML file, the configure HPA thresholds, if the value exceeds HPA then it triggers
the auto-scalar. Manual scalar can be done in web console topology)
5. We used to resolve the Connectivity issues of application using ticker tool and
splunk tool
a. Check logs (command) /temp/tomcat/pod-name/logs
 b. We will check the File system space usage
c. We will restart the pod by scaling up and down
6. Application gets hung
a. Check logs /temp/tomcat/pod-name/logs
b. Check for DB connectivity issues, java connectivity issues, server issues…
c. File system space usage check
d. Scaling up and down of pods using ticker tool
7. Nasamount issued: This one will be handled by our counterpart, using mapping and
node restart issue.
8. Pod memory issue: For this deployment config file we will be ending the memory up
on the applications – restart the process if they need more cores then we will provide
with many cores like up-gradation from 24 to 40 as an example.
9. Project quota updation: Through API we will update project quota

Kinds of PV Used
NFS, AWS Elastic Block Store (EBS),Azure Disk, Azure File, Cinder, Fibre Channel, GCE
Persistent Disk, HostPath, iSCSI, Local volume, NFS, Red Hat OpenShift Container Storage,
VMware vSphere.

EmptyDir
Gets created as soon as the pod gets assigned to the node. The simplest volume type is
EmptyDir, which is a temporary directory on a single machine. Administrators may also
allow you to request a persistent volume that is automatically attached to your pods.
Containers are not persistent by default; on restart, their contents are cleared.

Checking cluster health OpenShift

 To verify the end-to-end functionality of an OpenShift Container Platform cluster, build
and deploy an example application.

Create a new project  you can check the logs to follow the build -> once the build is
complete, two pods should be running: a database and an application -> Visit the
application URL. The Cake PHP framework welcome page should be visible -> once
the functionality has been verified, the project can be deleted:

 Creating alerts using Prometheus

 You can integrate OpenShift Container Platform with Prometheus to create visuals and
alerts to help diagnose any environment issues before they arise. These issues can include
if a node goes down, if a pod is consuming too much CPU or memory

 Host Health

To verify that the cluster is up and running, connect to a master instance, and run the
following:

$oc get nodes

The Ready status means that master hosts can communicate with node hosts and that the
nodes are ready to run pods (excluding the nodes in which scheduling is disabled).

Which part does name resolution?

SkyDNS is a distributed service for announcement and discovery of services built on top of
etcd. It utilizes DNS queries to discover available services. This is done by leveraging SRV
records in DNS, with special meaning given to subdomains, priorities and weights.

DNS (Domain Name Server) resolution is the process of translating IP addresses to domain
names. When a profile is configured to look up all numeric IP addresses, Webtrends makes a
call to the network's DNS server to resolve DNS entries.

DNS Lookup:Translates numeric IP addresses into domain names.

The DNS Operator implements the dns API from the operator.openshift.io API group. The
operator deploys CoreDNS using a DaemonSet, creates a Service for the DaemonSet, and
configures the kubelet to instruct pods to use the CoreDNS Service IP for name resolution.

Horizontal & vertical pod:

Scale up and scale down of pods in ticker tool. (There are two types of scaling:
horizontal and vertical. Horizontal scaling is where the number of application instances or
containers is increased. Vertical scaling is where system resources like CPU and memory are
increased at the running application’s or container’s runtime. Horizontal scaling can be used
for stateless applications, whereas vertical scaling is more suitable for stateful applications.)
 A horizontal pod autoscaler, defined by a HorizontalPodAutoscaler object, specifies
how the system should automatically increase or decrease CPU utilization & Memory
utilization.

You can create a horizontal pod autoscaler with the oc autoscale command and
specify the minimum and maximum number of pods you want to run, as well as the CPU
utilization or memory utilization your pods should target.

Bootstrap Process

Bootstrap - a temporary machine that runs a minimal Kubernetes used to deploy the
OpenShift control plane. It will be deleted at the end of the installation.

Boot strapping:

In computing, bootstrapping refers to a process where a simple system activates another more
complicated system that serves the same purpose. It is a solution to the Chicken-and-egg
problem of starting a certain system without the system already functioning. The term is most
often applied to the process of starting up a computer, in which a mechanism is needed to
execute the software program that is responsible for executing software programs (the
operating system).

In modern computers, the first program the computer runs after a hardware reset invariably is
stored in a ROM known as bootstrap ROM. as in "pulling one’s self up by the bootstraps."

Process

The bootstrap machine creates the master machines that make up the control plane. The
control plane machines then create the compute machines, which are also known as worker
machines.

After the cluster machines initialize, the bootstrap machine is destroyed. All clusters use the
bootstrap process to initialize the cluster, but if you provision the infrastructure for your
cluster, you must complete many of the steps manually.

Admission controllers?
An admission controller can intercept requests sent to the Kubernetes API server. For
example if a new pod is created a request will be sent to the Kubernetes API server and this
can be intercepted by admission controller.
 An Admission Controller is a subroutine that's invoked after a request to the API is
authenticated and authorized, but before it's persisted to etcd. Admission Controller
serve the purpose of mutating and validating resources to be persisted, such as adding various
annotations and defaults and making sure that they conform to specific restrictions.

Examples:

 AlwaysAdmit: This admission controller allows all pods into the cluster.
 AlwaysPullImages: This admission controller modifies every new Pod to force
the image pull policy to Always.
 AlwaysDeny: Rejects all requests. AlwaysDeny is DEPRECATED as no real
meaning.
 CertificateApproval, CertificateSigning, ect are admission controllers

Command to get the list of services?

$ oc get svc

Kubectl?
The kubectl command line tool lets you control Kubernetes clusters

Command to check resource utilization in OpenShift?

Octop or ocpod

Namespace
Organise resources in Kubernetes. If we have DB team, monitoring team, OPS team etc., it is
better to separate all individual resources into different namespaces.

Namespaces are intended for use in environments with many users spread across multiple
teams, or projects. Namespaces provide a scope for names. Names of resources need to be
unique within a namespace, but not across namespaces. Namespaces cannot be nested inside
one another and each Kubernetes resource can only be in one namespace.

Number of nodes
Red Hat recommends a minimum of three infrastructure nodes for production
deployments. This ensures that the services have resources available and are able to migrate
in the event of host maintenance or failure.

Kubernetes Cluster Management. A highly available cluster is composed of at least 3 master

nodes, each running a member of the etcd distributed database and all the Kubernetes master
components (API, controller manager and scheduler).

Officially, Kubernetes claims to support clusters with up to 5000 nodes.

Kubelet

The kubelet is the primary "node agent" that runs on each node. It can register the node with
the APIserver using one of: the hostname; a flag to override the hostname; or specific logic
for a cloud provider.

The kubelet works in terms of a PodSpec. A PodSpec is a YAML or JSON object that
describes a pod. Kubelet ensures that the containers described in those PodSpecs are running
and healthy.
I am terminating a node if it is stuck on docker side
What kind of PV ? trident..NFS and empty DIR
File system quota for empty dir
If I give a path of a file on OpenShift volume? How will you find which container it
belongs to
Which part hosts DNS service in OpenShift
Are you using Front end routers?
Difference between draining a node and abruptly shut down a node?
What is equivalent of kubectl ?
A particular node is unresponsive what will you do?
When tenant reports there is node issue, like multiple pods on 1 particular node are not
getting spin-up, but the same time other nodes are fine. So what will you do to
remediate the issue?
Unschedule that node and drain the node which is having issue.
Reboot a node without disturbing the pods? Steps?
How to Check health of cxd cluster?
Etcd commands
Where you check if PODS are not scaling even if you have it in deployment config ?
All pods are fine and working but the application inside it is not? (probes)
How to make sure if one particular application is reaching your pOd?
How logs are shipped from cluster to kibana?
Prometheus what is the level of work you have done?
https://www.youtube.com/watch?v=h4Sl21AKiDg&t=230s
Ansible coding experience?
What is citadel ?
who takes care of issues of master in kubernetes?
How to upgrade 4.1 to 4.3 to 4.4
Deploying openshift on IBM cloud and AWS cloud?
Prometheus and graphana?