►
From YouTube: Ask an OpenShift Admin (Ep 26): Day 2 Operations, part 1
Description
Congrats! You just installed your OpenShift cluster. Now what? “Day 2” operations refer to everything that happens after the cluster is installed, which could be a lot or a little, depending on how you plan to use the cluster. But what are some specific Day 2 operations? This show, part one of two, will focus on some additional machine, node, and cluster-level configuration, which you may want to implement after deploying.
About Ask an OpenShift Admin:
Do you have questions? We want to answer them! Every Wednesday at 11am ET, hosts Andrew Sullivan and Chris Short sit down to answer your questions about Red Hat OpenShift.
Follow us:
Andrew Sullivan https://twitter.com/practicalandrew
Chris Short https://twitter.com/chrisshort
Subscribe to Red Hat's YouTube channel: https://www.youtube.com/redhat/?sub_confirmation=1
About OpenShift:
Red Hat OpenShift is an open source container application platform based on the Kubernetes container orchestrator for enterprise application development and deployment.
Openshift.com https://red.ht/33Fh6uV
OpenShift on GitHub https://github.com/openshift/
OpenShift on redhat.com https://red.ht/2o4ccDk
#RedHat #OpenShift #Kubernetes
A
B
A
A
B
Think
if
we
get
another,
you
know
good
rainstorm
to
come
through
that'll
do
away
with
a
lot
of
the
pine
pollen.
That's
left
and
we'll
be
we'll
be
back
to
normal,
so
jp
dade.
Thank
you
for
the
the
like
on
the
intro
animation
chris,
and
I
were
actually
just
saying
how
we've
never
actually
listened
to
the
music
that
goes
along
with
it
like
we
know,
there's
music.
A
B
Yeah
yeah
funny
how
that
is
yeah
but
yeah.
No,
the
the
creative
team
has
done
just
phenomenal
work
with
the
move
to
you
know
from
openshift
admin
office
hour
to
ask
an
openshift
admin
and
yeah
all
the
artwork
and
the
reoccurring
stuff
that
they
do
to
to
keep
all
that
up.
So
can't
thank
them
enough.
It's
really
been
great.
Yes
exactly
so,
I
know
we.
We
got
distracted
there
and
went
a
little
off
the
rails,
but
yeah.
B
I
am
andrew
sullivan
technical
marketing
manager
with
the
red
hat
cloud
platforms,
business
units-
and
this
is
one
of
our
office
hours
series
of
live
streams.
So
the
goal
here
is
for
you
our
audience
to
ask
us
literally
anything.
That's
on
your
mind,
whatever
it
is.
That's
bothering
you
that
you
got
questions
about,
or
it's
anything
that
happens
to
come
up
that
you
want
an
answer
to
with
regard
to
openshift.
We
are
here
to
help
so
chris
and
I
both
have
administrative
backgrounds.
B
We
were
both
admins
for
a
number
of
years
in
various
roles
and
various
organizations,
so
we're
happy
to
help
with
those.
If
you
have
a
developer
question,
we'll
do
our
best,
but
I
can't
guarantee
that
that
we'll
be
able
to
answer
that,
but
that
doesn't
mean
that
we
won't
give
up
regardless
of
whether
of
what
question
it
is.
B
If
we
don't
know
the
answer,
we'll
be
sure
to
go
and
find
it,
and
if
we
do
give
you
an
answer
and
it
happens
to
be
wrong,
let
us
know
I
love
to
be
proven
wrong.
I
was
just
having
a
conversation
with
one
of
our
support
guys
this
morning,
you
know
prove
me
wrong.
I
love
it
so
with
that
being
said,
if
you
all
have
any
questions,
don't
hesitate
any
point
in
time.
B
B
We
do
have
a
topic
and
I
try
to
keep
or
try
to
have
something
to
talk
about
in
that
respect,
and
hopefully
it
triggers
some
questions
for
you
as
well,
and
today
that
topic
is
day
two
operations,
so
red
hat
uses
the
nomenclature
where
we
have
this
kind
of
day,
numbering
scheme
day
zero
day.
One
day
two
day,
zero
often
refers
to,
and
I
don't
know
how
ubiquitous
across
the
industry,
this
is
I've
heard
sometimes
different
numbers.
B
I've
heard
different
phases
stuff
like
that,
so
so,
phase
zero
is
often
the
architecture
and
design
phase
phase
one
is
deployment
and
then
phase
two
is
essentially
or
day.
Two
is
essentially
everything
after
that
right
day,
two
until
decommissioning
effectively,
which
could
be
day
10,
000.
wow.
That
would
be
a
long
time.
That's
what.
B
Well,
hopefully,
it's
lots
of
updates
in
between
right,
so
yeah.
Today
I
want
to
talk
about
day
two
and
a
lot
of
this
topic,
spurred
from
a
series
of
blog
posts
that
I
did
back
in
the
gosh
four
or
three
four
four
days
and
it
was
4
3
that
turned
into
a
section
of
the
documentation
and
since
it's
been
a
while,
since
we
talked
about
it-
and
by
that
I
mean
I
don't
think,
we've
ever
talked
about
it
on
the
stream.
It
was
just
in
the
blog
post.
B
I
wanted
to
revisit
some
of
that,
and
importantly,
I
want
to
get
your
perspective,
your
feedback.
What
are
the
things
that
you're
doing
that
you
feel
aren't
well
organized
in
the
documents?
What
are
the
things
that
you
feel
might
be
missing
or
what
are
the
things
that
are
important
to
you
as
our
audience?
From
a
day
two
perspective,
however,
before
we
get
started-
and
I
see
some
chat
coming
in.
A
A
A
A
B
B
A
B
B
But
when
you
step
down
just
one
step,
it's
hugely
and
dramatically
different
yeah
and
we've
talked
about
that
over
a
couple
shows
I'll
see
if
I
can
dig
up
some
of
those
but
effectively
the
trigger.
The
reason
why
we
went
from
openshift
3
to
openshift
4
was
the
introduction
and
widespread
adoption
of
operators
for
all
things
openshift.
B
B
So,
whenever
I
needed
to
change
something
whenever
I
needed
to
administer
those
nodes,
the
preferred
way
was
to
do
it
through
an
answerable
playbook
right.
If
it
was
something
that
red
hatch
like
we
wanted
you
to
do
in
a
controlled
manner,
or
something
like
that,
there's
a
playbook
if
it
was
something
that
still
supported
still
possible,
but
maybe
I'm
not
going
to
say
outside
of
the
norm,
but
just
not
something
that
we
had
a
playbook
for
it
was
sure
ssh
into
the
node
and
do
what
you
need
to
do
or
use.
B
B
Instead
of
running
an
ansible
playbook
that
says,
go
and
start
the
service
on
all
of
the
nodes
and
put
this
configuration
file
in
place
and
all
those
other
things.
Instead,
we
do
it
through.
What's
now
the
machine
config
operator,
where
I
use
the
machine
config
operator
to
push
configuration
out
to
all
of
those
nodes
right.
The
registry.
Similarly
right
the
registry
instead
of
deploying
those
pods
and
and
providing
that
configuration
as
a
config
map,
or
I
think
it
was
a
config
map
back
and
forth,
or
in
a
three
times
before.
B
B
Yeah,
so
that's
a
really
good
point,
and
I
know
that
we
have
and
I've
my
tabs
got
scattered,
because
I
had
to
log
out
and
log
back
in
yeah,
so
somewhere
I've
got
a
link
to
a
an
episode
that
we
did
a
while
ago.
That
was
effectively
what
are
operators
for
openshift
administrators
and
effectively
what
it
does
is
it
takes
all
of
that
knowledge,
all
those
actions,
all
of
those
things
that
were
previously
in
an
ansible
playbook,
codifies
them
and
then
makes
them
available
directly
in
the
cluster.
B
So
before
right,
if
red
hat
created
an
ansible
playbook,
you
could
assume
that
it
was
red
hat
applying.
You
know,
red
hat
engineering,
applying
our
knowledge,
our
expertise
around
the
system
to
say
this
is
how
you
should
configure
it
right
when
I
want
to
configure
x
we're
going
to
do
these
things,
we're
just
putting
that
into
the
kubernetes
cluster
itself
and
then
executing
that
using
kubernetes
native
paradigms.
B
B
A
B
A
B
Yeah,
so
so,
first
for
those
who
regularly
tune
into
this
particular
live
stream.
You
know
that
I
tend
to
start
the
show
off
talking
about
some
things
that
have
come
up
in
the
last
week
or
kind
of
since
the
last
episode
that
I
feel
are
important
to
you,
our
audience
to
administrators
for
open
shifts
that
we
can
bring
up
and
we
can
talk
about
so
a
lot
of
times.
These
come
from
both
you
the
audience
right.
B
If
you
reach
out
and
ask
us
questions
to
help
clarify
things
or
point
out
andrew
you
were
full
of
crap.
You
were
wrong.
I
again
I
enjoy
issuing
retractions
and
corrections,
so
please
don't
hesitate
to
do
that
at
any
time,
but
it
also
comes
internally
right
when
our
field,
folks,
on
our
engineering
folks,
ask
and
answer,
questions
and
stuff
like
that.
I
take
that
knowledge.
I
swirl
it
away
and
then
provide
those
those
pearls
of
wisdom
to
you
all
so
the
first
one
that
I
want
to
talk
about
is
I've.
B
B
B
All
right,
so
I'm
gonna
share
my
screen.
Real
quick
here.
Are
you
the
one?
I
want?
Yes,
yes,
you
are
the
one.
I
want
all
right.
So
please,
let
us
know
in
chat.
If
you
can't
read
this.
Hopefully
it's
big
enough,
so
this
is
just
an
install
config
that
I
have
right.
I
ended
this
one
in
dot
clean
because
it
has
no
pull
secret
inside
of
it
so
or
ssh
key
inside
of
it.
B
B
So
what
that
really
means?
Is
it's
going
to
take
this
slash,
14,
it's
going
to
carve
it
up
into
a
23
for
each
one
of
the
nodes
in
the
cluster
and
then
when
a
pod
is
instantiated
on
that
on
that
node
it
gets
assigned
an
ip
address
from
that
23..
That's
all
it
means
right
and
then
openshift,
sdn
and
iptables
does
effectively
masquerade,
writes
nat
in
order
to
access
those
across
the
the
various
nodes.
B
So
the
second
one
I'm
going
to
jump
down
here
to
the
bottom
service
network.
This
is
just
the
range
of
ip
addresses
that
when
you
create
a
service
object
in
kubernetes
in
openshift,
this
is
the
ip
address
range
that
it
will
be
assigned
from.
So
the
third
one
is
the
important
one
here
and
this
machine
network
dot.
B
So
this
is,
if
you
have
all
of
your
worker
nodes
or
all
of
your
nodes
in
the
cluster,
I
should
say,
have
just
a
single
interface.
It's
not
critical
that
you
configure
this
correctly.
Basically,
the
cluster
will
probably
work.
Just
fine
you'll,
never
notice
it
the
majority
of
the
time
unless
you're
using
a
proxy
or
there's
a
couple
of
other
scenarios
in
there.
So,
for
example,
this
network
automatically
gets
added
to
the
no
proxy
list.
B
So
if
that
happens
to
be
something
that
you're
using
right,
you
want
to
definitely
make
sure
that
it
is
configured
correctly.
Likewise,
if
you
have
more
than
one
interface
make
sure
that
that
value
is
configured
correctly,
because
if
it
doesn't
see
an
interface
that
has
an
ip
in
this
range,
it
basically
takes
the
first
network
adapter
and
particularly,
if
you're
doing
a
non-integrated
install
and
it's
across
different
platforms.
I've
got
some
nodes
that
are
in
vsphere.
I've
got
some
nodes
that
are
in
red
hat
virtualization.
B
I've
got
some
nodes
that
are,
you
know,
quote
unquote,
bare
metal
that
are,
you
know
physical
servers.
Those
interfaces
could
be
in
a
different
order
right.
What
is
you
know?
Maybe
this
machine
network
is
the
first
interface
in
vsphere,
but
it's
the
fourth
interface
on
my
bare
metal
nodes
on
my
physical
nodes
and
that
can
cause
a
lot
of
problems.
B
B
It
is
sometimes
handy
just
as
an
administrator
right
because
simple
is
is,
what's
the
kiss
principle
right,
keep
it
simple
silly.
You
know
I'm
like
that
yeah
yeah!
So
sometimes
that
is
good,
but
it
is
not
a
requirement
from
a
red
hat
perspective,
so
the
next
one
iteration
on
that
is
well.
Should
I
have
a
dedicated
subnet
that
only
hosts
openshift
clusters
and
the
answer
there
is
no.
You
don't
need
to
do
that,
but
there
are
some
things
to
be
aware
of.
B
If
you
have
multiple
openshift
clusters
in
the
same
subnet
and
in
particular,
if
you're
using
ipi,
so
if
you're
using
on-prem
ipi,
so
that
would
be
bare
metal,
ipi
right,
physical
ipi,
vsphere,
red
hat
virtualization
open
stack
in
some
circumstances
so
on
and
so
forth.
Any
of
those
on-prem
ipis.
They
use
a
keep
a
live
d
instance
to
manage
the
virtual
ips
associated
with
api
and
ingress
startup
apps,
so
being
people
id
it
uses,
vrrp,
which
I
don't
remember
what
vrrp
stands
for
now.
A
B
B
So
if
you-
and
it
is
entirely
possible
to
have
a
duplicate
of
those
names
or
of
those
domain
ids,
if
that
happens,
it
can
be
bad
right.
Basically,
it
it'll
think
that
there's
nodes
that
shouldn't
be
there
and
it'll
get
confused
and
you
won't
be
able
to
stand
up,
for
example,
the
the
new
cluster.
The
existing
cluster
will
probably
just
have
some.
You
know,
random
errors
that
show
up.
It
won't
accept
those
new
nodes
because
it
won't
recognize
them,
but
the
new
cluster
wouldn't
stand
up
so
just
be
aware
of
that.
B
Otherwise
than
that
no
no
real
issues,
nothing
to
be
concerned
about
likewise,
it's
perfectly
fine
to
have
a
subnet
that
is
shared
between
openshift
and
other
things
right.
So
you
can,
you
know,
put
your.
I
don't
know
domain
controller
dns
server,
whatever
on
the
same
on
the
same
subnet
as
openshift,
you
won't
have
any
harm,
come
from
that,
whether
it's
ipi
or
upi,
all
right.
I'm
going
to
pause,
because
I
think
there's
some
questions.
A
A
B
B
B
Jp
dade
openshift
sdn
versus
ovn
kubernetes,
so
we
talked
about
that
with
mark
curry
a
couple
of
weeks
ago
and
in
general,
there's
not
a
substantial
difference
between
them.
Ov
and
kubernetes
will
move
to
being
the
default
sdn
in
the
openshift
4.9
time
frame.
I
believe
he
said
for
now.
It
really
depends
on
what
on
whether
or
not
you
need
the
additional
features
or
capabilities
of
ovn
kubernetes,
so
the
big
ones
there
being
cross
operating
system.
So
if
you're
using
windows
nodes,
for
example,
you
need
to
be
able
to
do
that.
B
A
B
B
B
So
the
good
news
is,
you
can
create
these
yourself
so
for
us,
administrators
who
you
know
particularly
like
the
senior
administrators
etc,
who
are
working
on
basically
making
things
as
easy
and
simple
and
consumable
as
possible
for
our
junior
peers,
as
well
as
maybe
as
administrators
for
developers
or
other
people.
You
can
write
these
little
help
scripts
and
it
shows
up
inside
of
the
cluster.
B
B
I
don't
need
the
tour
here
right
in
the
navigation.
Menu
click
add
so
it's
kind
of
this
right.
You
can
step
through.
You
can
provide
as
much
help
or
as
much
detail
inside
of
your
quick
starts
as
you
would
like
the
goal
being
provide
that
help
right
if
you've
got
users
who
are
constantly
asking
you
the
same
questions
over
and
over
and
over
again,
you
can
create
these
quick
starts,
deploy
them
into
the
cluster
and
then
let
them
self-help.
B
B
B
Sad
to
say,
I
think,
is
the
the
the
feeling
I'm
going
to
choose
that
updates
from
4.6
to
4.7
are
still
blocked.
So
this
is
the
same
issue
that
we've
been
talking
about
for
a
few
weeks
now
yeah
effectively.
There
is
so
vmware
with
vm
or
hardware
versions,
14
and
later
enabled
hardware
offload
for
vxlan
rel
kernel
or
the
kernel
in
rel.
8.3
basically
did
the
same
thing
or
had
something
similar
inside
of
there.
B
B
A
B
Yeah,
so
there
appears
to
be
some
workarounds.
I
haven't
tested
any
of
these.
I
I
don't
know
what
our
official
stance
on
any
of
them
is,
but
just
be
aware:
it's
it
is
a
blocker.
It
is
preventing
those
upgrades.
I
know
I
sympathize
even
though
I
empathize
vsphere
is
a
big
platform
for
openshift.
It
is
not
the
only
platform,
and
you
know
I
understand
it's
frustrating
if
you're
not
using
vsphere,
but
it's
blocking
upgrades
for
you
as
well,
so
just
know
that
we're
working
on
it.
B
B
B
So
I
would
suggest
keeping
an
eye
on
this
right.
You
can
click
the
little
watch
button
up
here.
I
think
it's
this
one
follow,
so
you
can
be
alerted
when
they
update
this,
because
this
will
be
changing
in
the
future
and
in
particular,
if
you
watch
the
what's
next
a
presentation
which
was
a
little
over
a
month
ago
now
and
actually
we
can
do
the
openshift.com
new
and
next,
I
think,
is
the
shortcut
link,
something
like
that.
B
Next
to
new
new
next
and
new,
there
we
go
next
and
new.
There
you
go
so
that's
the
shortcut
to
always
get
to
those
two
presentations.
So
what's
next
and
what's
new
anyway.
So
if
you
watch
that
you
remember
that
we
are
are
hoping
to
have
single
node
clusters
in
tech
preview
with
openshift
4.8,
so
4.8
is
still
a
ways
away,
but
remember
that
you
can
access
nightly,
builds
so
in
the
not
too
distant
future,
and
I
haven't
checked
this-
I
haven't
looked
when
nightlys
start
to
become
available
for
4.8.
B
B
A
B
So
I
have
heard
mixed
things
about
right,
because
basically
only
vm
version
or
vm
hardware
version
14
plus,
is
affected,
but
I
don't
know
if
that's
because
we
haven't,
we
just
haven't
heard
about
it.
Yet
with
vm13
vm
hardware
version
13.,
sorry,
I'm
having
a
in
my
head
every
time
I
say
virtual
hardware.
I
just
giggle
a
little
bit
because
virtual
virtual.
A
A
B
Yeah,
maybe
with
vm
hardware
version
13.
It
would
work
just
keep
in
mind
that
vm
hardware
version
13
limits
you
in
other
areas,
most
especially
the
vmware
csi
provisioner.
So
their
provisioner
requires
vm
hardware
version
15
or
later
so
just
be
aware
of
that
it
may
be
possible.
I
would
definitely
recommend
testing
it,
not
using
it
in
production
until
you
have
fully
and
thoroughly
tested
that
you're
not
going
to
experience
any
issues
associated
with
that.
A
B
Yeah,
so
this
is
something
else
right
yeah,
and
this
is
something
that's
a
bit
strange
with
red
hat
and
with
openshift,
specifically,
because
we
sometimes
mistakenly
use
the
term
cluster
api.
When
we
mean
cloud
api,
when
we
really
mean
machine
api,
so
first,
let's
be
careful
with
the
nomenclature
in
the
naming
that
we
use.
B
So
I
want
to
take
a
step
back.
So
cluster
api
is
the
set
of
apis
that
are
being
driven
by
vmware,
and
I
think,
google
for
creating
new
clusters
programmatically
right.
So
basically,
you
submit
a
an
object
right.
A
kubernetes
object
that
says
spin
me
up
a
new
cluster.
That
is,
you
know,
x
and
y
and
z,
parameters
and
cluster
api.
Is
that
api?
That
does
something
with
that
to
instantiate
the
new
cluster.
B
So,
as
chris
pointed
out
earlier,
open
shift
red
hat
rather
than
using
cluster
api.
We
use
a
thing
called
hive.
So
if
we
go
to
github.com
openshifts
and
we
do
a
search
for
hive
here-
you
can
see
we
have
this
hive
and
chris.
I
know
you
liked
this
earlier
in
the
chat
so
from
here
you
can
look
at
hive.
You
can
look
kind
of
across
it
and
it
goes
through
and
kind
of
explains
what
it
does,
how
to
deploy
it,
how
to
take
advantage
of
it.
A
B
A
A
B
A
B
B
Great
you
know
whatever
that
happens
to
be.
I
need
a
very
small
deployment
where
you
know
I
have.
The
you
know
supports
the
features,
the
capabilities
of
openshift,
without
necessarily
all
of
the
resiliency
of
a
three-node
cluster
right,
because
remember
it's
only
one
node!
If
that
node
fails,
you
can't
it's
nothing.
B
Right
so
code
ready
containers
is
targeted
specifically
at
developers,
although
it's
also
applicable
to
us
administrators,
the
goal
being
on
my
laptop
or
my
desktop.
I
use
code
ready
containers
to
instantiate
open
shifts,
and
then
I
can
start
writing
my
application
and
I
can
deploy
it
locally.
I
can
take
advantage
of
it.
It's
kind
of
the
local
version
of
code,
ready
workspaces,
so
code
ready,
workspaces
being
in
a
full
openshift
cluster,
that
development
environment,
that
test
environment
that
I,
as
a
developer,
can
interact
with
so
different
use
cases
for
us
as
administrators.
B
Using
something
like
co-ready
containers
just
wasn't
an
option
right,
you
know,
I
I
had
a
thin
client,
and
that
was
all
I
was
given
and
all
I
was
allowed
to
use
to
do
any
of
my.
You
know
my
stuff
so,
but
I
ironically
and
strangely
I
was
an
administrator,
so
I
had
access
to
vcenter,
and
so
I
could
go
in
and
I
could
deploy
vms
all
day
long
right.
It
was
just
I
couldn't
do
it
locally.
So
that's
awesome,
single
node
cluster,
as
an
administrator
means
that
I
can
deploy
a
cluster.
B
That's
all
so
I
I
know
where
time
flies,
you
know
when
you're
having
fun-
and
I
know
that
we've
gone
through
quite
a
bit
of
time
already.
So
I
I
have
a
series
of
topics
or
a
series
of
things
that
I
want
to
talk
about
with
regard
to
the
day,
two
stuff
that
we
haven't
already
talked
about.
So
the
good
news
is
of
the
gosh
chris.
How
many
bullets
do
I
have
here?
20
20.
A
B
So
that
way
you
can
kind
of
follow
along
at
home
in
your
own
time,
at
your
own
pace,
as
the
case
may
be
I'll
also
say
so,
our
contact
information
is
always
on
those
blog
posts
or
you
can
reach
out
to
us
on
social
media,
on
discord
et
cetera,
to
ask
questions,
don't
hesitate,
you
know
at
any
point
in
time
to
reach
out,
and
you
know
andrew.
Why
are
you
saying
this
or
why
should
I
care
about
this,
or
I
don't
care
about
this?
I
really
care
about
that
type
of
thing.
B
Don't
hesitate
at
any
point
in
time
to
to
reach
out
with
any
of
that
stuff
so
day.
Two
so
remember!
At
the
beginning,
I
said
you
know
day.
One
is
kind
of
the
installation
process.
So
if
you
read
the
little
abstract
that
we
create
for
each
one
of
these
episodes
right,
I
think
this
one
opens
with
like
congratulations.
You
just
deployed
your
cluster.
B
B
B
You
know
one
of
those
important
ones
like
how
do
I
protect
the
cluster
so
today,
what
I
want
to
talk
about
is
again
those
kind
of
low
level
node
and
cluster
level
operations
that
are
important,
or
at
least
from
my
perspective,
important
and
again
these
may
not
apply
to
everyone.
There
may
be
things
that
you
do
care
about,
that.
I
don't
list
here
that
doesn't
mean
that
they're
not
important
just
be
aware
all
right.
B
So
the
first
thing
I
want
to
highlight
here:
aha,
so
I'm
in
the
openshift
4.7
documentation
page
here
and
all
I've
done
so
at
the
top
level.
Here
I've
got
this
post
installation
configuration
section,
so
this
section
of
documentation
is
meant
to
be
a
collection
of
or
an
attempt
at
a
collection
of
these
types
of
operations.
B
B
So
if
you
don't
know
of
anywhere
else
to
go,
this
is
a
good
place
to
start
I'll,
also
offer
if
you
scroll
down
here
to
the
stability
and
performance
section,
there's
a
number
of
things
inside
of
this
section
of
the
documentation
as
well.
That
are
important.
Just
look
through
here.
Look
for
things
that
you
know
check
through
each
one
of
these,
like
cpu
manager.
Right,
do
I
care
about
you
know
using
cpu
manager
for
any
of
my
applications.
Do
any
of
them
need
the
features
that
are
offered
by
this?
B
If
so
well,
deploy
the
operator-
and
you
know,
configure
it
to
take
advantage
of
or
or
to
make
available
those
features
to
those
applications
right.
So
let's
come
back
up
here
to
our.
What
am
I
looking
for
here
I
want
cluster
tests
is
where
I'm
going
to
start.
Actually,
no
I'm
going
to
start
a
machine
test,
so
the
first
one
that
I'll
talk
about
here
is
remember,
particularly
if
you,
you
know
just
followed
the
default
documentation
or
if
you
just
did
a
default,
ipi
install
you're
only
going
to
have
two
or
three
worker
nodes.
B
So,
depending
on
your
sizing,
you
may
need
to
deploy
additional
nodes
right,
and
this
is
where
things
get
and
we've
talked
about
sizing
as
a
topic
before
sizing
can
be
difficult.
You
know
what's
what's
that
saying
about
you
know.
Predictions
are
hard,
especially
about
the
future
yeah,
so
we
can
do
all
of
the
sizing
that
we
want
and
there's
documentation
on
on
how
to
do
that.
B
B
A
A
B
Post
that
one
into
the
chat
here,
oh
thanks,
so
you
know
if,
like
most
things,
openshift
related,
you
don't
have
to
get
it
right
day,
one,
but
it's
definitely
easiest
if
you
get
it
right
day,
one!
So,
let's
say
that
you
know
you
looked
at
this.
You
said:
oh
I'll,
never
have
more
than
100
worker
nodes,
you
know
or
I'll
never
have
more
than
25
worker
nodes.
Four
cpus
and
16
gigabytes
of
memory
for
the
control
play
nodes
is
great.
B
So
what
happens
when
I
hit
60
worker
nodes
and
my
control
plane
just
can't
can't
keep
up.
You
can
change
that
day
too
right,
it's
a
little
bit
of
a
hassle,
isn't
the
right
word,
but
it's
definitely
some
work
compared
to
like
worker
nodes
right
effectively.
The
safest
way
of
doing
it
is
to
fail
the
control
plane
nodes,
one
at
a
time
and
replace
them
with
the
new
resources,
except
with
non-integrated
installs
with
non-integrated
installs.
B
I
think
you
can
turn
off
the
nodes,
adjust
the
resources
and
then
turn
them
back
on,
but
it's
one
of
those
like
yeah.
It's
always
best
to
do
it
or
to
hopefully
get
our
guesstimates
as
close
as
possible
day
one,
but
for
worker
nodes.
Maybe
you
deploy
the
first
set
of
worker
nodes
using
the
defaults,
which
are
relatively
small,
I
think
with
most
cloud
providers,
it's
like
two
cpus
and
eight
gigs
of
ram.
Something
like
that.
B
So
if
that's
not
enough
for
your
workloads
rather
than
spinning
up,
you
know
dozens
of
nodes
or
something
like
that
right.
You
can
resize
these
by
effectively
with
ipi,
creating
a
new
machine
set
and
specifying
a
different
cpu
and
memory
count.
Maybe
I
need
to
change
to
a
different
storage
domain
or
data
store
right,
create
a
new
machine
set.
That's
pointed
at
the
new
data
store
and
then
scale
up
the
new
machine
set
and
scale
down
the
original
one
and
you'll
end
up
with
those
resources.
B
So
that
is
important
for
things
like
maybe
I
have
some
nodes
that
have
gpus.
Maybe
I
have
nodes
that
have
you
know
different
networking
connectivity
or
something
like
that
for
specific
applications?
Maybe
they
have
different
local
storage.
I've
seen
that
happen
before
with
some
customers,
where
they
used
local
storage
on
the
hosts
for
very
high
performance
applications,
like
databases
and
stuff
like
that,
so
I
want
a
subset
of
nodes
that
have
these.
You
know
massive
and
expensive
nvme
devices.
I
only
want
my.
B
So
you
know
having
that
or
doing
that
additional
connectivity
beyond
just
the
initial
connectivity,
node
configuration
and
layout
beyond
the
initial
deployment
is
really
super.
Important.
I'll
also
say
that
you
know
yes,
machine,
auto,
scaler
cluster,
auto
scaler
is
there
to
help
with
some
of
those
actions,
but
they
still
have
to
be
configured
too.
B
B
So
you
know
it's
been
a
minute
since
we
did
an
install
and
oh
no,
I've
completely
lost
track
of
things
like
the
ignition
files
that
I
used
to
spin
up
nodes
originally,
so
you
can
retrieve
that
file
using
that
command
right.
There
oc
extract
so
that
pulls
out
that
ignition
and
we
use
that
we
point
to
the
nodes
with
upi
or
bare
metal
install.
We
point
the
nodes
at
that
file,
that's
hosted
somewhere
on
an
http
server
or
depending
on
the
install
method
like
vsphere
upi.
I
can
attach
it
directly
to
the
virtual
machine
definition.
B
A
A
A
B
So,
in
that
same
line
of
thought,
if
you
are
choosing
to
use
infrastructure
nodes,
remember
they're
not
required,
but
you'll
find
that
most
red
hatters
encourage
you
to
use
them
because
effectively
infra
nodes
and
the
workload
design
for
infra.
So
things
like
the
logging
service
metric
service.
All
that
other
stuff.
Remember,
you
don't
have
to
entitle
those.
Your
entitlements
are
reserved
or
only
necessary
for
nodes
that
have
your
applications
on
them.
B
B
Well,
I
said
I
had
a
link,
but
I
know
where
it's
at
if
we
go
down
here
to
the
nodes
section
and
we
look
for
maybe
it's
machine
management
here,
we
go
creating
infrastructure
machine
sets.
So
this
walks
through
how
to
create
a
machine
set
with
ipi
that
will
deploy.
We
can
scale
it
up.
It
will
deploy
those
new
nodes
that
automatically
or
already
have
that
infrastructure
tag.
B
B
So
this
is
effectively
how
we
go
through
when
we
configure,
for
example,
elasticsearch
was
which
is
a
component
of
the
logging
service,
so
that
it
will
run
on
our
specific
and
only
on
our
specific
infrastructure
nodes,
so
using
a
combination
of
a
toleration
for
the
infra
taint,
as
well
as
a
node
selector
for
those
infra
nodes,
and
I'm
going
to
take
a
look
at
chat
here:
yeah
penguin,
whisperer,
bacon
fork.
I
know
chris
and
I
have
been
chatting
about
it.
B
A
B
B
B
They
recommend
in
their
documentation
a
series
of
worker
configuration
things
for
the
nodes
here,
I'll
copy
this
guy
out
and
bring
it
up.
So
you
can,
we
can
see
down
here.
If
I'm
using
iscsi
with
rel,
then
I
want
to
do
right
make
sure
these
packages
are
installed.
I
want
to
set
the
session
scanning
to
manual
so
on
and
so
forth,
so
that
still
applies
with
openshift
and
with
coreos.
B
And
effectively,
what
this
just
is
doing
is
two
things.
So
first
it
takes
a
little
bash
script
that
applies,
netapp's
recommended
recommendation
recommended
settings,
you
can
do
it
and
then
the
second
part
is
it
takes
that
script
and
it
puts
it
onto
the
node
using
a
machine
config
all
right,
so
we're
creating
a
machine
configuration
right.
Here's
the
name
it's
going
to
apply
to
any
worker
node
or
any
node.
B
That
has
a
role
of
worker
and
we
want
it
to
put
the
contents
of
that
script
up
above
onto
this
path
and
then
we're
going
to
create
a
systemd
unit
that
just
executes
that
script
on
startup
basically
make
sure
every
time
the
node
starts
that
we
start
the
iscsi
daemon
that
we
have
multipath
configured
to
write
all
these
other
things
inside
of
there.
We
also
want
to
make
sure
that
those
services
are
turned
on
as
needed.
B
So
this
is
just
one
example
right.
I
happen
to
have
recently
helped
a
co
or
a
joint
customer,
netapp
openshift
customer
with
exactly
this
problem,
which
is
why
I
use
this
example,
but
there
are
others
out
there
right
there
is.
You
know
I'm
sure
that
dell
emc
I'm
sure
hitachi
fujitsu
right.
Many
of
our
other
certified
partners
make
similar
recommendations.
B
B
B
A
B
B
Yeah,
so
you
know
configuring
time,
synchronization
super
important
one
of
the
first
things
I
do
with
all
of
my
clusters,
so
I'll
I'll
use
that
as
the
last
one
I
talked
about
today,
but
I
also
want
to
highlight
that
if
you
leverage
get
ops
and
the
argo
cd
operator,
you
can
make
this
super
easy
to
reproduce
across
all
of
your
clusters.
Definitely
yeah!
B
So
if
you're
not
familiar
with
git
ops,
if
you
haven't
started
to
look
into
that
and
check
and
see
whether
or
not
it's
a
viable
option,
definitely
definitely
check
out
christian
hernandez
live
stream,
so
his
happens
every
other
thursday,
so
not
tomorrow,
but
next
week
I
believe
is
the
next
one.
Yes,
so
definitely
check
out
his
live
stream.
He
goes
through
a
lot
of
great
stuff
around
how
to
oftentimes
it's
from
a
developer
perspective
right
how
to
deploy
applications,
but
the
same
exact
stuff
applies
to
administrators
and
configuring.
B
The
cluster
he's
also
been
doing,
and
I've
I've
been
helping
to
review
some
of
the
blog
posts
he's
been
putting
on
openshift.com,
so
some
really
great
blog
posts
there
as
well
about
how
to
like.
I
need
to
do
these
things
in
this
specific
order.
I
need
to
create
a
meta
application
of
multiple
applications
right
or
multiple,
I'm
using
application
here,
because
that's
the
get
ops
term,
but
really
it's
any
kubernetes
configuration
that
you
want
to
apply
like
a
machine
config
operation.
B
B
May
be
he's
he's,
probably
you
know
cursing
us
as
he's
listening
like
a
podcast
okay.
So,
as
you
said,
we're
basically
down
to
the
wire
here,
because
we
have
a
hard
stop
at
noon.
Eastern
time,
which
is
in
less
than
two
minutes
now.
So
first
thing
I
want
to
say
is
thank
you
so
much
to
our
audience
today
really
appreciate
everybody
who
has
been
on
who
has
asked
questions
who's
interacted
with
us.
Please
please,
please!
B
If
you
have
any
additional
questions,
if
there's
anything
we
didn't
get
to,
if
there's
anything
you're
curious
about
you
can
reach
out
andrew.sullivan
at
redhat.com.
If
email
is
your
preferred
method,
there's
also
discord,
which
I'm
sure
chris
is
posting.
The
discord
link
right
now.
There
is
also
twitter.
You
can
reach
out
to
me
at
practical,
andrew,
just
like
my
username
there
in
twitch,
which
gets
rebroadcast
across
the
others.
A
That's
that's
all
I
got
so
all
you
got
all
right
further
ado.
Thank
you
all
for
joining
us
today,
really
appreciate
it.
Sorry
I
had
to
duck
out
for
a
little
bit,
but
we
will
find
answers
to
those
questions
that
we
said
we
were
going
to
I'm
already
working
on
a
couple
of
them
right
now,
but
coming
up
next
openshift
commons,
with
one
of
my
very
good
friends
baruch
from
jfrog,
I
can't
say
his
last
name,
and
he
knows
that.
So
that's,
okay!