OpenShift In a Nutshell - Episode 03 - Infrastructure part I

Presentation By:
Behnam Loghmani
Spring 2016
IRAN OpenStack Users Group
OPENSHIFT
IN A NUTSHELL
(Episode 03)
Infrastructure

IRAN Community| OpenStack.ir
Agenda:
●
Overview
●
Master's Components
●
High Availability Masters
●
Iran OpenStack Community
OpenShift Infrastructure

Overview

●
Within OpenShift, Kubernetes manages containerized applications across a
set of containers or hosts and provides mechanisms for deployment,
maintenance, and application-scaling.
●
Docker packages, instantiates, and runs containerized applications.

A Kubernetes cluster consists of one or more masters and a set of nodes.
You can optionally configure your masters for high availability (HA) to ensure that
the cluster has no single point of failure.

Master's Components

The master manages nodes in its Kubernetes cluster and schedules pods to
run on nodes.
The master is the host or hosts that contain the master components, including
the API server, controller manager server, and etcd.

Components
●
API Server
●
Etcd
●
Controller Manager Server
●
Virtual IP
●
Pacemaker
●
HAProxy

API Server
The Kubernetes API server validates and configures the data for pods, services,
and replication controllers. It also assigns pods to nodes and synchronizes pod
information with service configuration.
API Server Can be run as a standalone process.

●
OpenShift API v1
GET /oapi/v1/clusternetworks
DELETE /oapi/v1/clusternetworks/{name}
●
Kubernetes API v1
GET /api/v1/namespaces/{namespace}/pods
GET /api/v1/namespaces/{namespace}/persistentvolumeclaims/{name}
API Server (Cont.)
https://docs.openshift.org/latest/rest_api/openshift_v1.html
https://docs.openshift.org/latest/rest_api/kubernetes_v1.html
More details:

etcd
etcd stores the persistent master state while other components watch etcd for
changes to bring themselves into the desired state. etcd can be optionally
configured for high availability, typically deployed with 2n+1 peer services.

Controller Manager Server
The controller manager server watches etcd for changes to replication controller
objects and then uses the API to enforce the desired state. Can be run as a
standalone process. Several such processes create a cluster with one active leader
at a time.

Virtual IP
Optional, used when configuring highly-available masters with the pacemaker
method. There is one virtual IP (VIP) and it is managed by Pacemaker.
The VIP is the single point of contact, but not a single point of failure, for all
OpenShift clients that:
●
cannot be configured with all master service endpoints, or
●
do not know how to load balance across multiple masters nor retry failed master
service connections.

Pacemaker
Optional, used when configuring highly-available masters with the pacemaker
method.
Pacemaker is the core technology of the High Availability Add-on for Red Hat
Enterprise Linux, providing consensus, fencing, and service management. It can be
run on all master hosts to ensure that all active-passive components have one
instance running. Pacemaker is also available in CentOS 7 and Fedora.
Another option is to use HAProxy load balancer to switch between API endpoints.

HAProxy
Optional, used when configuring highly-available masters with the native method to
balance load between API master endpoints.
The advanced installation method can configure HAProxy for you with the native
method. Alternatively, you can use the native method but pre-configure your own
load balancer of choice, or use the pacemaker HA method instead.

High Availability Masters

While in a single master configuration, the availability of running applications
remains if the master or any of its services fail. However, failure of master services
reduces the ability of the system to respond to application failures or creation of
new applications. You can optionally configure your masters for high availability
(HA) to ensure that the cluster has no single point of failure.

Runbook:
A runbook entry should be created for reconstructing the master. A runbook entry
is a necessary backstop for any highly-available service. Additional solutions merely
control the frequency that the runbook must be consulted. For example, a cold
standby of the master host can adequately fulfill SLAs that require no more than
minutes of downtime for creation of new applications or recovery of failed
application components.

Use a high availability solution to configure your masters and ensure that the
cluster has no single point of failure. The advanced installation method provides
specific examples using either the native or pacemaker HA method, configuring
HAProxy or Pacemaker, respectively. You can also take the concepts and apply them
towards your existing HA solutions using the native method instead of HAProxy.

Moving from a single master cluster to multiple masters after installation
is not supported.

Role Style Notes
etcd Active-active Fully redundant deployment with
load balancing
API Server Active-active Managed by HAProxy
Controller Manager
Server
Active-passive One instance is elected as a
cluster leader at a time
HAProxy Active-passive Balances load between API master
endpoints
With HAProxy

Role Style Notes
etcd Active-active Fully redundant deployment with
load balancing
Master service Active-passive One active at a time, managed
by Pacemaker
Pacemaker Active-active Fully redundant deployment
Virtual IP Active-passive One active at a time, managed
by Pacemaker
With Pacemaker

OpenShift Architecture
Iran OpenStack Community

OpenShift Architecture
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 03 - Infrastructure part I

Recommended

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to OpenShift In a Nutshell - Episode 03 - Infrastructure part I (20)

Recently uploaded (20)

OpenShift In a Nutshell - Episode 03 - Infrastructure part I