►
From YouTube: ROSA Resilience | Amazon Web Services
Description
Ryan Niksch (AWS) and Charlotte Fung (Red Hat) show how OpenShift and AWS aggregate to provide customers with the resilience they need for their business goals. This session will briefly touch on each of the different layers of OpenShift.
Learn more at: https://go.aws/3yDae0q
Subscribe:
More AWS videos - http://bit.ly/2O3zS75
More AWS events videos - http://bit.ly/316g9t4
ABOUT AWS
Amazon Web Services (AWS) is the world’s most comprehensive and broadly adopted cloud platform, offering over 200 fully featured services from data centers globally. Millions of customers — including the fastest-growing startups, largest enterprises, and leading government agencies — are using AWS to lower costs, become more agile, and innovate faster.
#redhat #openshift #redhatopenshiftserviceonaws #rosa #AWS #AmazonWebServices #CloudComputing
A
A
Right,
so
what
we
have
here,
Charlotte
is
a
architecture
diagram
of
the
red
hat
openshift
service
on
AWS
or
Rosa,
and
this
is
a
very
generic
architecture
for
a
public
facing
cluster.
So
we've
got
these
entry
points
where
developers,
customer
administrators
or
red
XS
sorry
or
are
coming
in
over
the
Internet
through
a
collection
of
AWS
load
balancers,
and
we
can
see
that
here
on
the
top
of
the
diagram.
I
want
to
quickly
talk
to
you
about
what
are
some
of
the
resilience
factors
of
open
shift
in
itself
and
how
those
complement
resilience
on
AWS.
A
One
of
the
things
that
you've
got
in
this
architecture
is
openshift.
Has
a
control
plane
made
up
of
Master
nodes,
and
there
are
three
of
those.
Why
three?
Why
is
it
always
this
magical
number
of
three
and
and
what
happens
if
one
of
those
control
plane
nodes
has
to
fail
whether
there
is
something
wrong
from
a
software
or
a
hardware
perspective.
B
Thank
you
Ryan
for
that
question.
As
you
said,
we,
the
the
basic
like
the
default
deployment,
always
comes
with
three
control
plane
because
that's
the
brain
like
this
is
what
controls
your
cluster
and
you
want
to
make
sure
that
is
always
available,
because
if
one
fails,
then
you
have
to
to
carry
over
the
job
of
the
one
that.
A
B
Yeah,
it's
more
about
just
making
sure
that
at
least
there
is
a
minimum
of
two.
If
one
does
fail,
why
the
cluster
is
able
to
spin
up
or
why
a
SRE
team
is
able
to
detect
that
that's
a
failure
in
one
of
the
Clusters
like
one
of
the
control
plane
and
be
able
to
spin
up
a
third,
and
so
those
two
can
still
be
able
to
handle
all
the
API
calls
that
come
into
the
cluster
and
be
able
to
like
do
whatever
needs
to
be
done
and.
A
The
fact
that
there's
two
remaining
you
don't
see
a
performance
degradation,
you
don't
see
any
impact
to
the
customer
in
a
in
a
traditional
open
shift
or
a
self-managed
openshift.
So
if
we
look
at
ocp
or
the
openshift
container
platform,
the
customer
would
be
managing
all
of
this,
so
the
customer
would
detect
this.
They
would
be
responsible
for
correcting
that
failed
node,
even
though
openshift
still
is
continuing
to
work.
A
B
A
A
That's
exactly
what
I,
as
a
business
owner,
hope
for
I
want
to
shift
to
the
the
infrastructure
layer
and,
more
most
importantly,
this
router,
this
this
router
layer
that
we
have
over
here.
This
is
facilitating
how
my
customers
get
to
the
actual
application
workloads.
So
my
customers
are
coming
in
through
a
collection
of
load
balancers
they
get
to
the
router
layer
and
that
router
layer
routes,
traffic
to
my
worker
nodes,
where
my
pods
or
my
applications
will
be
running.
What
happens
if
a
router
fails?
So
let's,
for
example,
blow
up
this
one?
B
So
when
a
router
fails
and
that's
why
we
have
like
the
two
infra
notes
to
act
to
account
for
the
high
resiliency
such
that,
if
one
router
fails
traffic
is
automatically
routed
to
the
other,
and
that
also
gives
a
SRE
time
to
spin
up
another,
because
this
is
still
managed
for
you.
So
you
really
don't
get
to
know
that
it
was
a
failure
and
then
that's
the
second
infra
that
gets
spun
up
for
you
and
takes
over.
A
That
and
configuration
wise,
the
registry,
the
route
and
the
monitoring
layers.
There
are
actually
a
lot
simpler
than
the
xcd
or
the
actual
controllers,
so
these
are
even
easier
and
faster
to
replace
should
something
fail.
I
would
argue
that
infrastructure
teams
could
probably
replace
these
within
in
a
few
minutes
with
the
automation
that
they
have
at
their
hands.
B
You
are
absolutely
correct,
so
this
deployment
that
we
have
here
is
just
the
default,
as
we
said
at
the
beginning
for
anyone
that
wants
to
get
started,
but
for
your
production
we
highly
recommend
that
you
make
use
of
the
multi
easy
deployment
which
helps
you
like
helps.
You
spread
out
your
resources
in
three
different
availability
zones,
which
accounts
for
high
availability,
High
resiliency
for
tolerant
such
that.
A
Okay
and
and
these
availability
zones,
they
are
the
closest
construct
that
AWS
has
to
a
physical
data
center
they're,
not
actually
data
data
centers.
There
are
collections
of
physical
buildings,
but
they're
the
closest
construct
we
have
to
a
physical
data
center,
so
what
you're
actually
saying
is
you're,
taking
that
openshift
cluster
and
you're,
making
sure
that
there
are
control
infrastructure
and
working
out
spread
evenly
across
separate
physical
data
centers.
So,
if
I
compare
this
to
an
on-premises
environment,
it's
like
me
having
three
distinct
data:
centers,
protecting
against
failure
and
really
we've
got
the
open
shift.
A
A
If,
if
one
of
these
had
to
fail,
my
expectation
would
be
that
kubernetes
would
detect
that
and
try
and
move
the
workloads
around
openshift
also
has
the
ability
to
deal
with
that,
not
just
from
a
kubernetes
workload
perspective,
but
also
from
an
infrastructure
perspective.
We've
got
an
auto
scaling
mechanism
built
into
openshift.
How
does
that
work.
A
A
So
again,
we've
got
that
resilience
mechanism
of
openshift
from
a
application
or
a
pod
perspective,
combined
with
the
infrastructure
side
coming
through
from
that
machine
set,
and
this
is
all
in
a
single
region
taking
advantage
of
openshift
and
multiple
availability
zones
and
scaling
constructs
Charlotte.
Thank
you
for
joining
me
as
always
a
fantastic
pleasure
to
work
with
you
and
thank
you
for
joining
us
here.