openshift in a nutshell - episode 03 - infrastructure part i

Presentation By:

Behnam Loghmani

Spring 2016

IRAN OpenStack Users Group

OPENSHIFTIN 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.htmlhttps://docs.openshift.org/latest/rest_api/kubernetes_v1.html

More details:

https://docs.openshift.org/latest/rest_api/openshift_v1.html

https://docs.openshift.org/latest/rest_api/kubernetes_v1.html


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: [email protected]

● Twitter: @OpenStackIR , #OpenStackIRAN

● IRC Channel on FreeNode: #OpenStack-ir

Thank YouBehnam Loghmani

Iran OpenStack Community Member

[email protected]

OpenStack.ir

We need to work together to build a better community

openshift in a nutshell - episode 03 - infrastructure part i

Technology