►
Description
Red Hat OpenShift on VMware? As a popular infrastructure choice for OpenShift deployments, VMware provides a large number of integrations and capabilities to enhance the usefulness, integration, and experience for applications deployed to Red Hat OpenShift hosted on vSphere. Tune in as special guest Robbie Jerrom from VMware joins us to review and explore all aspects of integration and what it means for your clusters and applications!
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
A
Good
morning,
good
afternoon,
good
evening,
wherever
you're
hailing
from
welcome
to
another
edition
of
ask
an
open
shift
admin.
Today,
we
are
joined
by
a
very
special
friend
from
vmware,
mr
robbie
jerome.
If
I
said
that
wrong,
I'm
sorry
but
andrew
the
cuddlish
curmudgeon
in
the
company.
Would
you
please
introduce
you
know
yourself
and
what
we're
talking
about
today,
absolutely.
B
B
Yeah,
so
you
know,
forgive
me,
I'm
if
I
stumble
over
the
name
of
the
show,
because
we're
still
this
is
the
second
week
third
week
third
week,
I
think
yeah
that
we've
that
we've
had
the
new
name.
So
so
yes,
welcome.
Thank
you
everybody
for
joining
us
today.
This
is
one
of
the
office
hours
series
of
live
streams,
which
means
that
we
are
here
for
you.
We're
here
in
an
ask
me
anything
style
of
interaction.
B
You
know
we
encourage
you
to
ask
us
well
literally
anything
about
openshift,
about
administering
openshift
about
anything,
that's
top
of
mind
in
that
respect,
and
you
can
do
that
at
any
point
in
time
across
any
of
the
platforms
yeah.
We
have
some
fancy
technology
that
that
re-broadcasts
re-broadcast.
A
B
Robbie
and
I
have
been
working
together,
for
I
don't
know
two
plus
years
now,
which
is
kind
of
funny
yeah,
it's
kind
of
funny,
because
I've
I
have
spent
so
much
time
with
you
on
the
phone
and
video
chats
and
all
that
other
stuff.
I
don't
think
we've
ever
actually
met
in
person
which
is
kind
of
funny,
so
well.
B
And
and
robbie,
and
I
we
work
together
quite
a
bit
because
we
are
kind
of
each
other's
interface
into
the
respective
companies.
So
whenever
vmware
folks
want
to
know
about
openshift
things,
you
know
we
he
interacts
with
me
and
vice
versa.
Whenever
I
want
to
know
about
vmware
things,
I
go
through
robbie,
so
it's
been
really
beneficial
for,
for
both
of
us
to
learn
a
lot
about
about
their
respective
stuff.
B
Yeah,
so
for
anybody
who
is
watching
the
stream,
please
feel
free
to
ask
questions.
I'm
going
to
spend
just
a
couple
of
minutes
here
going
over
the
the
top
of
mind
things
so
for
anybody
who
is
a
regular
watcher
of
the
stream
right,
I
tend
to
spend
a
few
minutes
up
front
talking
about
the
things
that
andrew
was
wrong
about
last
week,
which
nobody
sent
me
any
obscene
emails
telling
me
that
I
was
horribly
wrong.
B
And
yeah
every
once
in
a
while,
it
happens
and
the
other
one
is
kind
of
things
that
have
come
up
in
the
last
week
or
so
things
that
I
keep
seeing
internally
and
sometimes
externally
that
I
think,
are
worth
bringing
up
to
you
all
to
our
audience,
sometimes
externally.
So
the
first
one
is
I.
There
was
a
pretty
lengthy
thread
that
happened
this
week
about
the
difference
between
a
open
shift
deployment
that
is
mixed
operating
systems
versus
mixed
in
architectures,
cpu
architectures.
B
B
Yes,
I'll
post
this
into
the
chat,
I
I
have
this.
I
have
this
kubernetes
issue
bookmark
because
I
use
it
at
least
once
a
week-
and
this
is
the
the
kubernetes
issue,
the
upscreen
upstream
issue,
where
we
can't
mix
different
cloud
providers,
essentially
so
when
with
cloud
providers,
what
we're
really
referring
to
is
infrastructure
types.
So
I
can't
have
some
nodes
that
are
deployed
to
vsphere
and
some
nodes
that
are
deployed
to
physical
servers
unless
I
do
a
non-integrated,
openshift
deployment
right.
So
what
used
to
be
called
bare
metal,
upi
yeah?
B
So
second
one
node,
auto
scaling.
This
was
a
question
that
comes
up
somewhat
frequently.
You
know
once
every
week
or
two
we
get
questions
around.
Can
I
have
a
cluster
preemptively
scale
based
off
of
some
sort
of
criteria,
all
right?
So
hey
the
cluster
has
hit
80
cpu
threshold,
or
you
know
70
memory
or
whatever.
That
means
can
we
go
ahead
and
provision
some
extra
nodes
using
the
ipi
mechanism.
B
The
answer
for
that
is,
unfortunately,
no,
but
maybe
so
the
cluster
auto
scale
or
the
node
auto
scale
mechanism
doesn't
work
that
way.
It
doesn't
take
action
until
pods
fail
to
schedule.
So
I
just
submitted
a
job
that
job
needs.
You
know
40
pods
that
have
x
amount
of
cpu
ram
and
at
pod
number
26,
I'm
out
of
capacity
right.
There
is
no
more
cpu
available
right.
It
needs
to
take
action,
so
it'll
it'll
start
spinning
up
nodes
to
be
able
to
schedule
that.
B
So
maybe
that's
creating
a
simple
pod
right.
It's
some
sort
of
automation
that
goes
into
a
pod
deployed
to
the
cluster
that
is
checking
those
metrics
internally
and
just
says:
hey,
you
know,
does
an
oc
scale
or
something
like
that
against
the
machine
set
and
basically
the
same
thing,
but
done
externally
right,
something
your
external
monitoring
system.
Whatever
you
happen
to
be
using,
that
is
watching
those
metrics
and
then
taking
action
for
you,
the
last
one
that
I
have
here
is
extracting
ignition
files.
B
This
was
a
fun
one,
so
somebody
asked
me
you
know
hey.
I
I
accidentally
broke
my
or
deleted
the
installation
folder
for
my
cluster
and
I
need
to
add
some
more
nodes.
This
is
a
upi
install.
How
do
I
get
the
ignition
files
so
that
I
can
add
those
nodes
right,
because
you
know
you
have
to
provide
ignition.
So
how
do
I
get
that
out
of
my
cluster?
B
So
there
is
a
command
that
we
can
use.
Let
me
see
if
I
can
share
screens
here,
you
can
do
it.
I
believe
you
know.
Sometimes
it
takes
a
little
faith
all
right
here.
We
go
yes,
always
so
I'm
this
is.
This
is
my
cluster
for
today
come
on
cluster.
This
is
a
vsphere
cluster.
It
is
running
on
vsphere
6.7
u3.
I
believe
so
it
happens
to
be
ipi,
but
really
doesn't
matter
in
this
instance.
So
the
command
here
is
not
that
one.
A
B
B
If
I'm
doing
you
know
bare
metal
or
something
like
that,
this
would
be
what's
hosted
on
that
web
server,
that
we
pass
into
that
and
the
same
thing
we
can
do
for
the
control
plane
nodes-
just
change
this
from,
for
example,
worker
to
I
think
it's
master
yep
so
over
to
master.
We
pull
out
that
one
so
on
and
so
forth.
So
super
straightforward,
I'll
paste
this
command
into
the
chat.
Thank.
B
A
B
B
A
B
So
I
will
be
on
the
streams
I'm
sure
chris
will
be
on
the
streams
as
well
right,
answering
questions
anybody
who's
interested,
please
join.
We
will
be
if
we
can't
answer
the
questions
we'll
take
those
and
we
will
re-ask
them
internally.
Yes,
so,
and
we
have
multiple
ways
of
harassing
the
product
managers
to
get
those
answers,
so
don't
hesitate
to
ask
any
questions
that
you
have
about
what's
coming
in
the
roadmap
for
openshift
all
right,
that's
enough
of
me,
rambling.
B
Yeah,
so
somebody-
and
I
did
not
know
that
you
could
do
this
so
when
we
schedule
these,
especially
now
that
we
are
part
of
the
red
hat's
youtube
channel.
They
schedule
these
like
a
week
or
two
in
advance,
and
apparently
you
can
come
into
that
pending
stream
and
you
can
chat
from
the
time
that
it's
scheduled.
So
somebody
asked
us
a
question
like
last
week,
which
is
pretty
interesting
to
me.
B
B
B
Guy
all
right,
so
we
recently
updated
the
openshift
documentation
and
if
we
scroll
up
here,
I
am
on
the
openshift
4.7
docs,
and
this
is
just
installing
a
cluster
on
vsphere.
So
we
go
to
installing
we
go
to
installing
on
vsphere
and
take
the
first
option
and
if
we
come
down
here,
we
have
this
using
an
openshift
container
platform
with
emotion.
B
So
previously
the
guidance
here
ranged
from
don't
use.
The
motion
v
motion
is
not
supported
to
the
emotion
works
and
it's
a
support,
gray
area,
so
you
probably
shouldn't
do
it,
but
now
it
is
officially
tested.
It
works
right.
It's
fully
supported
to
do,
and
you
can
see
here
compute
only
the
emotion
right,
so
the
compute
only
is
the
important
part
here.
Essentially
that's
what's
tested.
B
So
remember
with
an
open
shift
deployment
with
an
ipi
deployments
or
upi
deployment.
We
will
automatically
configure
and
use
the
intri
vsphere
storage
provisioner.
It's
there
out
of
the
box
and
that's
the
one
that
is
fully
supported
by
red
hat.
The
csi
provisioner
is
different
right.
You
deploy
that
day.
Two,
it
is
supported
by
vmware,
etc.
B
B
However,
if
you
want
to
be
absolutely
sure
and
comfortable
and
not
have
any
worries
about
it
at
all,
I
would
definitely
recommend
doing
a
cordon
and
drain
and
doing
that
storage
via
motion,
while
the
node
is
not
hosting
any
workload
and
if
you
really
want
to
take
it
to
the
maximum,
you
know
security
or
comfort
level.
Turn
that
note
off
right,
shut
it
down.
So
that
way
it's
a
cold
migration.
C
B
Yeah-
and
I
I
should
have
asked
you
this
before
we
started
robbie
of
checking
to
make
sure
that
you
have
a
cluster
on
vsphere
7
with
the
csi
driver.
One
of
the
things
I'm
hoping
you'll
show
is
some
of
that
vcenter
integration
that
comes
with
the
csi
driver,
because
I
think
we
talk
about
that
a
lot,
but
we
haven't
often
shown
it
of
you
know
hey
as
the
vcenter
administrator.
I
want
to
feel
comfortable.
I
want
to
see
the
things
that
I
have.
B
B
So
no,
because
I
think
what
you're
asking
is,
can
I
deploy
some
nodes
to
vsphere
and
some
nodes
that
are
maybe
physical
and
some
nodes
that
are
windows,
maybe
physical
or
virtual,
and
we
can't
mix
like
that,
so
you
can
do
and
I'll
take
it
further
as
windows
worker
nodes
are
only
supported
either
in
azure
or
on
vsphere
api
right.
Those
are
the
only
two
platforms
or
in
the
only.
A
B
Unfortunately,
or
fortunately,
depending
on
your
perspective
yeah,
it
would
need
to
be
a
vsphere,
ipi
deployment,
make
sure
you
watch.
I
think
it
was
two
weeks
ago
we
had
christian
on
maybe
three
weeks
ago,
yeah
we
had
christian
on
the
stream
yeah.
He
talked
about
windows
nodes.
So
there
are
some
caveats
there
right
make
sure
you're
using
ovn
sdn
with
hybrid
mode,
so
that
way,
it'll
work
across
the
different
operating
systems,
all
that
fun
stuff.
B
B
So
what
do
I
mean
by
that?
So
the
machine
api
and
the
machine,
config
operator
etc,
are
designed
or
they
use
to
create
and
destroy
and
configure
nodes
that
are
a
part
of
the
cluster
and
the
cloud
provider
or
what
we
in
cloud
provider
is
a
bit
of
an
overloaded
term
right,
depending
on
who
you're
talking
to
in
red
hat
and
certainly
across
other
vendors
in
the
industry.
B
We
sometimes
use
it
to
mean
different
things,
but
with
openshift
and
with
andrew,
so
the
cloud
provider
is
that
bit
that
talks
to
the
underlying
infrastructure,
provisioner
and
or
provider
rather
and
provisions
manages
those
nodes
it
is
available
through
upi.
Let
me
dig
up
the
link
here
too
many
bookmarks.
B
So
this
kcs
how
to
create
a
machine
set
for
vmware
and
openshift
4.5,
and
this
is,
if
you
deploy
using
upi
and
then
you
want
to
be
able
to
do
node
scaling
right
using
the
the
cloud
provider
right.
The
machine
set
paradigm
inside
of
that
cluster,
so
this
will
bring
back
or
or
introduce
some
of
the
ipi
requirements
to
your
upi
cluster.
So,
for
example,
with
upi,
you
can
do
static
ips
right
and
you
can.
You
have
to
create
the
dns
entries,
the
load
balancer,
all
of
that
other
stuff.
B
B
You
can
always
have
the
the
load
balancer
configured
to
point
at
those,
but
otherwise
it
works
great,
and
it's
really
good,
for
you
know
that
dynamic
provisioning
that
you
want
to
right
dynamically
scaling
the
cluster
up
and
down
that
you
want
to
be
able
to
do
while
also
being
able
to
take
advantage
of
your
external
enterprise
load
balancer.
Instead
of
you
know
the
ipi
people
id
thing
that
we
have
there.
B
B
So,
yes,
very
quickly,
so
machine
api
machines
and
machine
sets
effectively
don't
apply
with
upi
unless
you're
doing
something
like
this
right,
where
you're
creating
that
machine
set
after
the
fact,
so
that
doesn't
exist
for
all
providers.
I
think,
actually,
I
don't
know,
that's
a
good
question.
I
know
we.
I
think
the
only
one
that
it's
documented
for
is
the
only
one
that
we've
really
been
asked
for
that
I'm
aware
of
is
with
vmware
so
yeah,
but
normally
with
upi
without
day
two
configuring,
this
machine
set
configuration.
C
There's
a
quick
one:
there's
a
quick
one,
andrew
back
on
the
csi
topic,
just
come
through
chat,
saying
yeah,
shouldn't
shouldn't
we
use
csi
and
forget
the
built-in
driver
taking
taking
don't
taking
out
the
built-in
driver
taking
out
the
entry
driver
is
is
a
bad
idea.
I
think
andrew
whether
you
want
to
speak
to
that.
B
C
So
you
can
change
the
default
to
the
the
new
vsphere
driver,
which
is
going
to
give
you
the
integrations
into
vcr
and
vcenter
and
visibility
into
the
provision
vmdks
and
and
pvs
up
into
vcenter,
but
don't
spend
too
much
time
trying
to
delete
the
existing
csi
because
the
operator
is
going
to
put
it
back
and
it's
it's
going
to
upset
your
cluster
a
little
bit.
If
you
do
successfully
manage
to
remove
it
so
change
the
default.
Yes,
don't
delete
the
existing
one.
That's
that's!
In
there.
B
Yeah-
and
I
I
would,
I
would
say
and
robby
I
think
you'll
agree
with
me-
I
I
would
encourage
folks
to
use
the
csi
driver,
absolutely
the
the
integration
with
vcenter,
just
the
general
improved
capabilities,
especially
if
you're
also
a
vsan
user
right,
just
the
general
improved
capabilities
and
reporting
and
everything
there.
You
know,
snapshots
the
rwx
of
the
file
modes.
What
am
I
what's
the
word,
I'm
looking
here
for
robbie
with
vc
yeah
we've
got.
C
Yeah,
the
visa,
the
vsan
integration-
you
can
type
storage
policy,
so
you
can
you
can
you
can
set
your
encryption
levels
and
stuff
like
that?
You
can
have
a
number
of
different
policies
that
will
let
you
have
different
different
numbers
of
copies
on
vsan
and
stuff,
like
that,
so
you've
got
far
more
control
if
you're
using
the
new
driver
and
then
you've
got
other
access
to
some
of
the
new
stuff.
C
B
B
A
B
Yes,
you
can,
the
problem
is
doing,
it
is
messy,
and-
and
by
that
I
mean
the
way
to
do
it
inside
of
the
cluster
post,
deployment
is
to
either
create
a
machine
config
for
the
nodes
right
and
then
for
each
node
right
have
a
machine
config
that
goes
in
and
drop
something
into
like
etsy
sysconfig
network
dash
scripts
or
into
the
network
manager
directory
right.
That
tells
it
what
its
static
ip
is.
B
B
So
the
recommended
way
of
doing
it
for
better
for
worse,
is
to
reload
the
nodes.
You
know
take
them
down
one
at
a
time:
reload
use
the
the
vm
property.
You
know
now
that
now
that
we
can
use
the
vm
property
to
add
that
static
ip
information
and
and
do
it
that
way,
so
I
I
know
that
that's
not
the
not
the
most
friendly
or
the
most
ideal
way,
but
you
know
sometimes
I
have
to
remind
people
that
we
treat
core
os
as
an
appliance
and
as
disposable.
B
B
B
I
know
this
isn't
a
question,
it's
a
it's
a
statement,
but
I
really
want
to
touch
on
something
important
here
and
robbie,
and
I
have
been
talking
about
this
for
well
basically
two
years,
and
that
is
what
is
the
relationship
between
nodes
deployed
openshift
nodes
deployed
to
vmware
or
to
vsphere,
with
drs
with
resource
reservations,
and
you
know
that
type
of
resource
management,
type
of
principles
so
I'll
I'll.
Ask
you
robbie
right?
B
C
It's
it's,
it's
actually
fairly
straightforward.
So
with
esx,
you
know
vsphere
clusters.
The
system
is
looking
after
the
cpu
memory
for
you.
So
when
you
deploy
vm
onto
the
cluster,
it's
going
to
give
you
the
resources
and
balance
them
based
on
everything
else,
that's
running
on
that
cluster
or
on
that
esxi
host.
C
If
that
host
starts
to
become
resource-contrained
constraints,
you're
using
up
too
much
memory
or
too
much
cpu
workloads
will
get
get
pulled
back
and
you
might
get
as
much
cpu
or
you
might
become
memory
constrained
that
will
impact
the
performance
of
the
application.
In
this
case
you
know
an
ocp
if
it
slows
down
too
much,
ocp
is
going
to
get
upset
and
think
that
there's
a
problem
with
a
node
or
a
master,
and
and
it's
going
to
try
and
resolve
that.
C
C
These
particular
vms
have
have
shares
most
people
these
days,
just
just
stick
with
reservations,
just
to
guarantee
a
certain
amount
of
resources.
So
in
a
in
a
sort
of
deployment
for
open
shift,
you
would
allocate
some
dedicated
resource
a
resource
pool
for
your
for
your
masters,
for
example,
or
your
control
plane.
C
Now,
that's
for
a
single
esxi
host
across
a
number
of
hosts
in
a
cluster
drs,
which
is
the
dynamic
resource.
Scheduler,
is
going
to
v.
Motion
move,
live
migrate.
The
machines
around
to
make
sure
you've
got
the
best
possible
utilization
for
that
entire
esxi
cluster.
So
it's
going
to
balance
out
those
workloads
for
compute
and
memory
and
io
as
you
go
across.
C
So
if
you've,
if
you're,
if
you're
resource
constrained
to
the
entire
cluster,
then
things
will
move
around
resource
pools
will
kick
in.
So
you
you've
got
the
flexibility
to
to
over
commit
resources.
To
say
I
need
to
use
300
gigabytes
of
the
300
300
gigabytes
of
the
250
gigabytes.
I've
got
on
this
eso
I
host,
because
I
know
that
actually,
all
of
these
vms
that
are
are
my
openshift
cluster-
aren't
all
going
to
be
fully
utilized
all
the
time.
C
I
just
want
them
to
think
that
they
have
the
resources
and
the
workloads
will
balance
out
appropriately.
So
it's
just
a
way
of
protecting
critical
parts.
I
protect
some
of
my
workers.
I
protect
the
masters
by
giving
them
resource
pools,
but
unless
you
are
actually
running
out
of
memory,
it's
not
going
to
kick
in.
C
Yeah
so,
and
it
depends
on
your
workload
and
how
dynamic
you
want
to
be
and
how
you
know
whether
we
have
for
a
development
cluster,
for
example,
over
commit,
would
make
sense
if
you're
in
a
production
cluster-
and
you
know
the
workload
you
understand
it,
then
maybe
you
don't
overcommit,
but
with
kubernetes
when
it
schedules
a
workload,
it
says
you
know
have
I
got
50
gigs
of
ram,
and
this
much
cpu
and
kubernetes
says
yes,
I
could
schedule
this
pod
here
and
off
you
go.
It
doesn't
go
back
and
check.
C
You
know,
that's
that's
just
running
that
resource
is
allocated
to
that
workload
and
if
that
workload
doesn't
actually
use
what
you
asked
for.
So
it
uses
one
gigabyte
of
ram
and
almost
no
cpu
those
resources
are
wasted.
Now
the
sphere
esx
is
constantly
monitoring.
It's
constantly
looking
at
memory
utilization
and
cpu
utilization.
C
So
it's
going
to
rebalance
it's
going
to
do
some
clever
things
with
things
like
memory
compression
to
make
sure
you
get
the
most
out
of
whatever
workload
is
running
on
that
platform,
so
you
can
safely
over
commit
memory
you
can
safely
over
commit
cpu
and
openshift
is
completely
unaware.
It's
quite
happy.
C
Esx
will
will
do
things
like
reduce
the
amount
of
cpu
you
have
so
that
the
vm
will
actually
slow
down
which
will
slow
down
the
processing
of
your
of
your
of
your
workload
and
linux
and
kubernetes
is
completely
unaware
of
that
it.
Just
it
just
starts
to
run
a
little
bit
slower.
It
does
some
time
shifting
on
it
to
to
make
sure
every
every
virtual
machine
gets
a
a
cpu
cycle
and
it
does
the
same
with
hyper
threading
as
well.
You
know,
hyper
threading
is
effectively
half
a
cycle
on
esx.
C
You
don't
get
half
a
cycle,
it
will
that
that
thread
will
get
scheduled
twice
if
it
lands
on
a
hyper
thread.
So
it
does
some
really
clever
stuff.
Yeah,
you
can
really
get
into
it
and
get
super
nerdy
if
you,
if
you
want
to
get
into
cpu
cycles
and
numera
awareness
and
stuff
like
that,
so
you
can
really
tune
the
the
performance
of
the
cluster
and
or
you
can
just
overcommit
a
little
bit
and
monitor
it
to
see
how
it's
going,
but
it
can
drop
off
very
very
quickly.
C
So
to
your
point,
andrew
about
being
cautious
and
saying:
look
don't
over
commit
resources.
If
your
workload
is,
you
know
if
you
are
actually
using
32
meters
ram,
you
are
using
all
that
cpu
all
the
time,
then
there's
no
benefit
to
overcommit
and
the
esxi
schedule
is
still
going
to
try
and
deliver
that
capability.
C
So
if
you
know
that
workload
is
always
going
to
be
busy,
don't
overcommit
it
just
say
right.
This
is
a
prod
workload.
This
is
how
much
it
needs
put
it
in
a
resource
pool
and
it's
fine,
but
for
dev
clusters
or
build
clusters
where
you've
you've
got
this.
You
know
fairly
rapidly
moving
memory
and
cpu
requirement
as
things
get
built
and
destroyed,
and
you
can
get
more
more
bang
for
your
buck
on
the
hardware.
If
you,
if
you
go
with
the
over,
commit
yeah.
B
And
I
I'll
say
you
know
I
want
to
get
get
all
nerdy
and
down
in
the
weeds
on
that.
I
don't
know
if
we
have
enough
time,
especially
because
we're
continuing
to
get
more
questions.
Thank
you,
everybody
for
questions,
we're
going
to
address
those,
but
I
know
you
and
I
have
talked
about
you-
know
creating
some
sort
of
usually
it's
referred
to
as
like
a
best
practices
guide
or
something
like
that.
B
C
C
C
If
you
want
to
do
some
stuff
with
nsx
and
plug
that
into
openshift,
you
can
do
that
as
well,
depending
on
what
version
of
vcf
you're
running
on
so
yeah,
it
integrates
really
nicely
and
andrew's
kind
of
demonstrated
that
we
have.
We
even
have
documentation
around
how
you
do
it
and
some
best
practices
on
that.
B
B
B
And
do
an
oc
debug
against
one
of
the
nodes,
so
we'll
just
pick
one
of
these
one
of
these
guys
it'll
pull
down
that
debug
pod
here
in
just
a
moment,
and
once
that
comes
up
we'll
do
a
just
as
it
says
here
we'll
do
a
change
route
to
slash
host
and
then
I
can
do
like
a
simple.
U
name
dash
a
so
you
can
see
this
brand
new
4.7.2
node
is
running
kernel
4.18.0-240,
so
pretty
easy
to
find
out
the
real
actual
running
kernel.
A
At
it
yeah
I
got,
I
got
roger
moore
handled,
I
think
just
pointing
them
to
the
container.
Catalog
was
a
huge
help.
So
if
you're
trying
to
run
containers
as
root
and
open
shift,
you're
going
to
have
problems
and
that's
okay,
we
want
you
to
have
those
problems
because
running
everything
is
root,
is
not
a
healthy
practice.
B
Yep
yep
yeah,
it's
you
know
the
whole
security
thing
that
we
we
forcefully
place
upon
you,
whether
you
want
it
or
not,
are
infranodes
declarable
in
the
install
config.yaml,
not
in
install
config.
You
can
create
them
in
the
manifest
and
have
them
deployed
when
the
cluster
is
set
up,
but
you
still
have
to
day
two
go
in
and
modify
the
workloads
to
actually
schedule
on
to
them.
Christian
hernandez
did
a
great
stream
on
this.
B
B
Late
summer,
early
fall
last
year,
fair
enough
so
and
for
anybody
who
doesn't
know
we
do
have
a
weekly
blog
post
on
openshift.com
blog
goes
out
friday
morning,
where
we
recap
everything
that
was
in
the
show.
We
provide
links
to
all
the
stuff.
That's
here.
So
if
you
missed
the
links
in
the
chat
or
anything
like
that
or
if
you,
if
you
didn't
see
something
that
I
typed,
you
can
always
go
back
into
that
blog
post
and
and
find
all
that
information
again.
It
publishes
thus
far.
It's
always
published
friday
morning.
B
B
Know
I
I
I
always
feel
bad,
because
I
talk
to
you
a
lot
in
like
what
is
effectively
mid-afternoon
for
me
and
I
know
that's
like
early
evening.
You
know
time
for
you
and
you
always
brush
it
off
as
oh,
but
I
have
to
deal
with
you
know
the
west
coast
time
zone
because
that's
you
know
vmware
stuff
and
I
I
still
feel
bad
yeah.
A
B
C
C
If
you
want
to
start
building
a
you
know,
resiliency
into
it,
and
making
sure
that
your
your
control
planes
are
spread
across
physical
esxi
hosts.
You
need
to
go
into
virtual
center.
You
need
to
to
tag
the
vm
and
say
right.
This
is
my
first
control
plane.
This
is
my
second.
This
is
my
third.
None
of
these
folks
can
exist
on
the
same
esxi
host,
at
which
point
if
they're
already
on
an
esxi
host
vsphere
will
just
v-motion
them
off
and
they'll
get
put
on
physically
different
servers.
C
So
if
you
do
lose
a
you
know,
a
physical
piece
of
tin,
you're
you're
only
going
to
lose
one
of
those
control
knows
at
a
time.
You
can
do
exactly
the
same
thing
for
workers.
So
if
you
have
a
bunch
of
different
workers
that
you
you've
you've
tagged
with
different
workloads,
you
can
use
affinity,
rules
to
spread
those
out
across
esxi
clusters
and
depending
on
the
size
of
your
environment,
that
may
also
extend
out
to
physical
racks
in
the
data
center.
So
you
can
have
a
policy
that
will
let
you
say
right.
C
Actually,
I'm
only
going
to
have
one
control,
node
and
control
node
vm
per
rack
in
my
data
center,
and
I'm
going
to
put
these
workers
across
the
esxi
hosts.
So
you,
you
can
be
get
quite
sophisticated
with
your
rule,
set
as
to
where
you
want
parts
of
openshift
to
be
deployed
either
in
vcf
or
in
or
in
just
a
homegrown
home
built,
vsphere,
environment
and
vsphere
is
going
to
take
care
of
that.
C
Openshift
is
not
going
to
not
going
to
care.
The
the
only
thing
you
need
to
be
aware
of,
of
course,
is
if
you
provision
up
a
new
openshift
node
or
you
or
you
recreate
a
control
plane.
That's
that's
gone
that
doesn't
have
an
affinity
tag
by
default,
so
you
need
to
go
in
and
recreate
or
use
an
automation
to
to
do
that,
for
you
right
here.
C
Yeah,
it's
really
cli
the
other.
The
other
thing
to
remember,
which
is
a
nice
feature,
is
you
know:
we've
got
a
little
tick
box
that
says
highly
available
tick,
that
tick
box
for
the
control
plane
nodes
or
you
know
any
of
the
nodes
really
that
way.
If,
if
we
do
lose
a
node
because
of
a
hardware
failure
or
it
just
stops,
responding
for
whatever
reason
these
fills
spin
it
up
somewhere
else
immediately,
and
it's
it's
really
really
quick
at
doing
that.
C
So
if
you
lose
a,
I
mean
if
you
lose
a
worker
because
of
a
hardware
failure
vsphere
can
often
put
the
worker
back
before.
Openshift
has
realized
that
it's
it's
lost,
that
mode
to
start
with
and
yeah,
and
it
will
and
then
the
kubernetes
layer
will
schedule
pods
and
handle
all
of
its
internal
workload
magic
as
well,
so
they
work
really
well
together,
but
out
of
the
box,
those
settings
aren't
aren't
turned
on
so
high
availability
for
control,
plane,
affinity,
rules
to
make
sure
you're
not
landing
on
particular
physical
hosts.
B
And
the
only
thing
I'll
add
is,
I
always
recommend
soft
affinity
rules
just
in
case,
especially
if
you
have
relatively
small
number
of
nodes
in
the
cluster.
You
know
if,
if
you
have
a
cluster,
that's
you
know
only
three
nodes:
drs
cluster
vmware
cluster,
that's
only
three
nodes
and
you
set
hard
affinity
rules
for
like
the
three
control
plane
vms.
B
If
one
of
those
physical
nodes
goes
down,
then
it
won't
restart
that
vm
that
control
plane
vm,
because
it
would
violate
that
heart
of
anti-affinity
rule
if
it's
a
soft
anti-infinity
rule
it'll,
restart
it
and
then,
when
that
physical
capacity
comes
back,
it'll
it'll
automatically
move
it.
So,
in
the
interest
of
time,
I'm
gonna,
I'm
gonna
rapid
fire.
Some
questions
here
so
daniel-
and
this
is
in
referring
to
the
csi
provisioner
primary
benefits
come
if
you're
using
vsan,
then
right.
C
Yep,
no,
absolutely
if
it's
a
data
store
in
in
vsphere,
you
can
apply
the
same
storage
policies
that
you
can
with
your
with
your
traditional
data
stores.
As
you
carry
vsan,
we
talk
about
vsan.
Obviously,
because
it's
our
thing
but
yeah
anything,
that's
a
data
store
in
vsphere
cns
is
going
to
take
care
of
it
for
you
and
you
can
you
get
that
visibility
at
the
at
the
vmware
level?
So
it's
not
just
tied
down
to
vsat.
C
B
B
B
Why
such
hate
for
dhcp-
you
know
I
don't
I
don't
know.
I
wish
I
knew
andrew's
opinion
is
there's
a
lot
of
old-school.
Think
about
dhcp
right.
It
was
never
used
in
the
data
center
for
security
reasons
right.
You
know.
Oh
anybody
can
just
go
in
and
plug
in
and
get
an
ip
address
and
stuff
like
that.
But
that
being
said,
that's
you
know
just
my
opinion.
B
B
Oh,
we
we
addressed
that
one.
So,
unfortunately,
no,
oh,
we
did
no
yeah,
so
you
can
create
them
at
install
time
just
to
just
quick
revisit
you
can
create
them
at
install
time
by
putting
the
machine
set
yamls
into
the
manifest
file.
So
you
would
do
a
openshift
install,
create
manifest
and
then
dump
them
in
there.
So
we'd
provision
them,
but
you
would
have
to
go
in
after
the
fact
and
modify
the
services
to
actually
deploy
over
there
jp
data.
B
I
see
that
I
debug
into
the
node
I've
used
ssh
to
access
the
nodes,
so
my
prefer.
So
what
is
your
preferred
way
of
accessing
the
nodes?
It's
one
more
dangerous
than
the
other,
so
I
tend
to
use
the
debug
simply
because
it's
easier,
you
know,
I
don't
have
to
you,
know,
use
a
specific
or
provide
the
specific.
B
B
B
C
B
Yeah,
I
think
this
is
a
and
andrew
needs
to
get
more
familiar
with
with
acm,
but
I
think
what
you're
thinking
is
like
where's,
my
v
center,
so
I
can
vcenter
right.
I
can
have
multiple
clusters
like
could
I
have
you
know
cluster
one
in
here
and
then
this
is
my.
You
know:
openshift
admin
console
or
whatever
for
that
cluster
and
go
down
to
cluster
two
and
see
that
one
and
so
one
interface,
where
I
can
join
all
of
my
clusters
to
be
able
to
manage
them
or
same
thing
with
cockpit
right
cockpit.
B
A
B
A
B
Yeah
fault
tolerance
is,
it
is
the
same
vm
executing
on
two
separate
hosts
at
the
same
time.
So
if
one
of
the
hosts
fails,
the
other
one
picks
it
up
and
runs
with
it
immediately
and
to
your
point
waleed,
there
is
a
a
limit
of
eight
cpus
per
vm
for
that
and
it
that
that
using
fte
while
it's
fine,
if
you
need
it,
be
aware
of
two
things
one
it
can.
A
C
Yeah
I
mean
we
can
use
vrealize
automation
to
do
the
one
click
button
that
kicks
off
the
deployment
for
you
there's
some
stuff
up
front
that
you
obviously
have
to
provide
with
the
configuration
I
mean
andrew.
We
messed
around
with
it
with
the
upi
installer
and
creating
ignition
files
and
automated
that
stuff
ipi.
I
think
it's
it's
fairly
trivial
to
do
actually.
C
And-
and
we
realize
we'll-
let
you
will
automatically
provide
all
that
stuff
so
yeah,
we
don't
have
anything
out
the
box,
because
vrealize
is
mostly
around
what
is
your
environment?
Look
like
how
do
you
want
to
automate
it,
but
we
have
customers
that
have
that
one
click
normally
we
we
use
it
with
some
governance
wrapped
around
it,
so
the
one-click
deployment
is
is
more
around.
Are
you
allowed
to
deploy
that
32
node
openshift
cluster,
or
perhaps
do
you
want
to
get
someone's
permission?
First.
B
C
Yeah
I
mean
we
spend
a
lot
of
time
talking
to
customers
that
have
well
a
lot
of
the
other
solutions
in
the
portfolio
that
are
normally.
You
know,
vm
based,
but
we've
been
moving
everything
to
kind
of
being
more
container
focused
over
the
last
last
few
years.
So
I'm
going
to
take
the
opportunity
to
share,
share
a
slide
and
share
a
screen,
so
give
me
a
sec,
and
I
will.
A
B
B
So
I
would
say
andrew's
opinion
is
that
anti-affinity
rules,
soft
anti-affinity
rules-
are
strongly
recommended
for
the
control
plane
nodes,
probably
for
infrastructure
nodes,
if
you're
using
those,
definitely
ones
that
are
running
routers
and
then
worker
nodes.
It's
really
going
to
depend
on
you
and
your
applications
and
a
number
of
other
things.
You
know
one
of
the
things
I
I
a
conversation
for
another
time
is
you
know
the
philosophy
of
do
I
you
know
if
I'm
deploying
openshift
to
vsphere
or
really
any
virtual
infrastructure
right?
Do
I
have
fewer
larger
nodes?
B
A
C
C
C
But
the
the
other
thing
we've
been
working
on
a
lot.
Is
you
know?
How
do
you
do
day
two,
and
how
do
you
see
the
openshift
workloads?
The
applications
are
running
openshift
alongside
all
of
your
other
workloads,
so
feeding,
feeding
all
the
logs
into
something
like
log
inside
a
login
site
cloud
along
with
esx
logs,
along
with
vm
workload
logs
and
getting
that
end-to-end
view.
C
So
you
know
we
focus
very
much
on
making
sure
openshift
works
around
everything
and
plugs
in
the
way.
You'd
expect
it
to
so
I
mean
we
don't
really
have
time
to
go
into
any
of
this
stuff,
but
it
you
know,
there's
there's
lots
of
other
things.
Beyond
just
the
cloud
provider
interface
we've
been
working
on.
B
Yeah,
I
know
you
know
having
and
at
the
bottom
of
your
slide
there
you
had
the
open
shift
on
vmc
on
vmware
cloud
on
aws
that
one's
near
and
dear
to
my
heart,
because
you
and
I
have
worked
on
that
one
together
and
published
that
so
anybody
who's
a
vmc
customer
and
they
want
to
deploy
openshift
onto
vmc.
That's
now
a
fully
supported
platform
robbie
and
I
went
through
and
did
the
deployment
guide
for
that,
and
you
know
that
was
where
I
got
re-re-familiarized
with
like
log
insight.
B
You
know
the
last
time
I
used
login
site
was
see.
This
is
2021
so
nine
years
ago
it
was
a
great
product.
Then
I
can
only
assume
it's
only
gotten
better.
You
know
in
many
ways,
but
it
was
one
of
those
like
I've
forgotten
it
existed
so
and
you
can
absolutely
configure
you
know
openshift
to
if
you
don't
want
to
use
the
openshift
logging
service,
for
whatever
reason
you
know,
if
you've
got
login
site,
you've
already
got
one.
Do
you
want
to
use
two?
B
B
Everyone
has
that,
so
I
think
we
are
at
the
top
of
the
hour
now.
So
thank
you,
everybody
for
all
of
your
really
phenomenal
questions
great
session.
I'm
gonna
take
as
many
of
these
as
I
can.
I'm
gonna
put
them
into
the
blog
post,
I'll
I'll,
try
and
and
link
to
where
we
answer
them
in
the
video
as
best
as
I
can.