OpenShift In a Nutshell - Episode 05 - Core Concepts Part I

Presentation By:
Behnam Loghmani
Summer 2016
IRAN OpenStack Users Group
OPENSHIFT
IN A NUTSHELL
(Episode 05)
Core Concepts
part I

IRAN Community| OpenStack.ir
Agenda:
●
Containers and Images
●
Pods and services
●
Iran OpenStack Community
OpenShift Core Concepts

Containers and Images

Containers
The basic units of OpenShift Origin applications are called containers. Linux
container technologies are lightweight mechanisms for isolating running processes
so that they are limited to interacting with only their designated resources. Many
application instances can be running in containers on a single host without
visibility into each others' processes, files, network, and so on. Typically, each
container provides a single service (often called a "micro-service"), such as a web
server or a database, though containers can be used for arbitrary workloads.

Containers (Cont.)
The Linux kernel has been incorporating capabilities for container technologies for
years. More recently the Docker project has developed a convenient management
interface for Linux containers on a host. OpenShift Origin and Kubernetes add the
ability to orchestrate Docker containers across multi-host installations.

Containers (Cont.)
Though you do not directly interact with Docker tools when using OpenShift Origin,
understanding Docker’s capabilities and terminology is important for understanding
its role in OpenShift Origin and how your applications function inside of containers.
Docker is available as part of RHEL 7, as well as CentOS and Fedora, so you can
experiment with it separately from OpenShift Origin.

Docker Images
Docker containers are based on Docker images. A Docker image is a binary that
includes all of the requirements for running a single Docker container, as well as
metadata describing its needs and capabilities. You can think of it as a packaging
technology. Docker containers only have access to resources defined in the image
unless you give the container additional access when creating it. By deploying the
same image in multiple containers across multiple hosts and load balancing
between them, OpenShift Origin can provide redundancy and horizontal scaling
for a service packaged into an image.

Docker Images(Cont.)
You can use Docker directly to build images, but OpenShift Origin also supplies
builders that assist with creating an image by adding your code or configuration to
existing images.

Docker Images(Cont.)
Since applications develop over time, a single image name can actually refer to many
different versions of the "same" image. Each different image is referred to uniquely
by its hash (a long hexadecimal number e.g. fd44297e2ddb050ec4f…) which is
usually shortened to 12 characters (e.g. fd44297e2ddb). Rather than version
numbers, Docker allows applying tags (such as v1, v2.1, GA, or the default latest) in
addition to the image name to further specify the image desired, so you may see the
same image referred to as centos (implying the latest tag), centos:centos7, or
fd44297e2ddb.

Docker Registries
A Docker registry is a service for storing and retrieving Docker images. A registry
contains a collection of one or more Docker image repositories. Each image
repository contains one or more tagged images. Docker provides its own registry, the
Docker Hub, but you may also use private or third-party registries. Red Hat provides a
Docker registry at registry.access.redhat.com for subscribers. OpenShift Origin can
also supply its own internal registry for managing custom Docker images.

Pods and Services

Pods
OpenShift Origin leverages the Kubernetes concept of a pod, which is one or more
containers deployed together on one host, and the smallest compute unit that can be
defined, deployed, and managed.
Pods are the rough equivalent of a machine instance (physical or virtual) to a
container. 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.

Pods(Cont.)
Pods have a lifecycle; they are defined, then they are assigned to run on a node, then
they run until their container(s) exit or they are removed for some other reason.
Pods, depending on policy and exit code, may be removed after exiting, or may be
retained in order to enable access to the logs of their containers.

Pods(Cont.)
OpenShift Origin treats pods as largely immutable; changes cannot be made to a pod
definition while it is running. OpenShift Origin implements changes by terminating an
existing pod and recreating it with modified configuration, base image(s), or both.
Pods are also treated as expendable, and do not maintain state when recreated.
Therefore pods should usually be managed by higher-level controllers, rather than
directly by users.

The recommended maximum number of pods
per OpenShift Origin node host is 110.

Services
A Kubernetes service serves as an internal load balancer. It identifies a set of
replicated pods in order to proxy the connections it receives to them. Backing pods
can be added to or removed from a service arbitrarily while the service remains
consistently available, enabling anything that depends on the service to refer to it
at a consistent internal address.
Services are assigned an IP address and port pair that, when accessed, proxy to an
appropriate backing pod. A service uses a label selector to find all the containers
running that provide a certain network service on a certain port.

Labels
Labels are used to organize, group, or select API objects. For example, pods are
"tagged" with labels, and then services use label selectors to identify the pods they
proxy to. This makes it possible for services to reference groups of pods, even
treating pods with potentially different Docker containers as related entities.
Most objects can include labels in their metadata. So labels can be used to group
arbitrarily-related objects; for example, all of the pods, services, replication
controllers, and deployment configurations of a particular application can be
grouped.

Endpoints
The servers that back a service are called its endpoints, and are specified by an
object of type Endpoints with the same name as the service. When a service is backed
by pods, those pods are normally specified by a label selector in the service
specification, and OpenShift Origin automatically creates the Endpoints object
pointing to those pods.
In some cases, you may want to create a service but have it be backed by external
hosts rather than by pods in the OpenShift Origin cluster. In this case, you can leave
out the selector field in the service, and create the Endpoints object manually.

Endpoints (Cont.)
Note that OpenShift Origin will not let most users manually create an Endpoints
object that points to an IP address in the network blocks reserved for pod and service
IPs. Only cluster admins or other users with permission to create resources under
endpoints/restricted can create such Endpoint objects.

Video Channels
https://www.youtube.com/behnamloghmani
http://www.aparat.com/behnamloghmani

Iran OpenStack Community

Stay in Touch and Join Us:
●
Home Page: OpenStack.ir
●
Meetup Page: Meetup.com/Iran-OpenStack
●
Mailing List: OpenStack-ir@Lists.OpenStack.org
●
Twitter: @OpenStackIR , #OpenStackIRAN
●
IRC Channel on FreeNode: #OpenStack-ir

Thank You
Behnam Loghmani
Iran OpenStack Community Member
Behnam.loghmani@gmail.com
OpenStack.ir
We need to work together to build a better community

OpenShift In a Nutshell - Episode 05 - Core Concepts Part I

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to OpenShift In a Nutshell - Episode 05 - Core Concepts Part I (20)

Recently uploaded (20)

OpenShift In a Nutshell - Episode 05 - Core Concepts Part I