►
Description
OKD Best Practices for DNS/DHCP server configuration
Guest Speaker: Josef Meier (Rohde and Swartz)
OKD Working Group
Testing and Deployment Workshop
2021 03 20
Hosted by: Diane Mueller (Red Hat)
A
B
B
Currently
we
are,
there
okd
helped
us
a
lot
in
yeah,
my
company,
a
lot
in
getting
in
touch
with
kubernetes
and
gaining
the
skills
for
that,
because
kubernetes,
vanilla,
kubernetes
is
not
yeah
an
easy,
easy
thing
and
we
yeah
we.
We
used
okd
to
learn
that
all
and
now
we
are
in
a
stage
where
we
move
parts
of
our
kubernetes
clusters
to
openshift
for
having
more
production
loads
and
getting
the
support
from
red
hat
yeah.
B
And
now
I
try
to
show
you
a
little
bit
about
my
first
or
what
I
thought
are
the
the
heaviest
steps
in
the
beginning.
If
you
start
with
user
provisioned
infrastructure
and
with
dns
dhcp
and
an
external
load
balancer.
B
Can
you
see
my
my
screen
share?
I
hope
so
you
yeah!
Thank
you.
This
is
a
diagram
of
my
home
lab
I'm
running
here
at
home,
I'm
using
I'm
using
a
vmware
vsphere.
I
bought
a
license
for
that's
very
suitable
for
home
lab
users.
It's
it
costs
around
150
bucks.
B
It's
called
the
mva
user
group
advantage
edition.
You
have
to
pay
150
euros
for
one
year
license.
I
think
that's
pretty
affordable
for
home
labs.
Why
do
I
use
vsphere
at
home
because
I
like
to
have
an
environment
here
in
my
home
lab
sets
similar
to
the
one
I
use
in
my
company
and
yeah?
That's
why
I'm
using
the
mbrv
sphere
it's
running
on
a
on
a
ryzen
pc,
it's
a
very
capable
one.
It
has
16
physical
cores
and
the
32
was
multi-threading
enabled
you
don't
need
that
much
course.
B
Don't
be
frightened
of
that,
but
I
like
to
have
possibilities
and
to
yeah
to
add
more
workers
to
play
with
new
things.
One
thing
I
tried
at
home
is
virtual.
Openshift
virtualization
are
based
on
cupert,
and
this
requires
a
little
bit
more
horsepower
than
you
normally
have
on
your
test
or
on
your
laptop.
B
So
we
have
one
pc
for
vm
there.
This
year
I
have
another
computer
running,
an
epic
attached
storage,
I'm
using
truna's
core
community
edition,
but
this
year
truna's
scale
will
go
into
general
availability.
B
I
like
that,
because
this
one
will
have
a
small
kubernetes
cluster
running
on
it,
where
you
can
deploy
your
helm
charts
and
I
like
to
have
some
components
outside
of
my
okd
cluster,
because
I
am
constantly
deleting
and
creating
clusters
to
test
new
things,
and
I
yeah
I
like
to
have
the
possibility
to
have
some
components
outside
of
my
cluster.
B
Yes,
and
on
the
top
of
the
image
you
see
my
dns
dhcp
server
and
also
the
load
balancer
component,
it's
running
on
a
raspberry
pi.
Maybe
you
ask
yourself
why
I'm
not
running
on
helper
vm
in
my
vsphere
environment?
I'm
doing
that,
because
I
also
constantly.
B
B
So
yes
and
I
have
a
dsl
modem,
a
router,
that's
connected
to
the
internet
and
the
first
thing
you
should
know
if
you
want
to
set
up
a
dns
and
dhcp
server
at
home,
you
should
be
sure
that
no
other
of
this
service
is
running
in
your
in
your
subnet.
B
In
my
case,
I
had
to
turn
off
the
dhcp
server
and
the
dns
server
running
in
my
in
my
dsl
router
before
well.
I
have
to
say
in
between
because
for
sure
during
the
installation
you
need
internet
access.
You
need
dhcp
dns
server
if
things
go
wrong,
but
if
the
custom
build
servers
are
running,
you
don't
need
see
yeah
servers
in
the
fritz
box
anymore.
B
What
do
you
have
to
achieve
here
on
the
vmware
vsphere
server?
There
are
a
few
vms
created
during
the
installation
process
and
just
for
your
information,
I
use
the
instructions
from
as
a
github
repository
of
okd,
it's
located
in
github.com
openshift
okd.
B
B
That's
a
tool
that
can
take
about
infrastructure,
uses
a
domain
specific
language
for
that,
and
there
is
also
a
terraform
provider
available
for
vsphere.
I
have
seven
vms
one
bootstrap
vm
three
masters
and
three
workers.
You
don't
need
so
much
vms
nodes.
Normally
I
have
this
is
my
standard
setup.
I
don't
want
to
yeah
take
care
about
with
limited
cpu
and
memory
space.
I
want
to
go
and
have
fun.
B
That's
because
it's
7
vms
in
the
first
step
in
the
installation,
is
that
the
bootstrap
vm
starts
creating
a
fake
control
plane.
This
takes
only,
I
think,
a
few
minutes.
It
depends
on
how
fast
your
internet
speed
is.
If
you
have
a
local
registry
in
your
home
labs
and
things
can
be
faster
because
of
improved
network
speeds
normally
have
in
your
home.
Lab.
B
Then
second
step
is
that,
in
addition
to
the
bootstrap
node,
you
have
your
master
nodes.
The
master
nodes
are
constantly
using
the
load.
Balancer,
that's
running
on
the
raspberry
to
get
ci
condition
configuration
files
from
the
bootstrap
node
and
if
the
bootstrap
remote
is
in
a
later
stage
of
a
stage
of
its
installation,
it
will
provide
with
a
local
web
server.
This
ignition
file
to
all
the
masters
that
are,
they
are
constantly
calling
for
that.
B
If
they
get
this
ignition
files
from
the
bootstrap
vm,
they
are
provisioning
themselves,
say
normally
boot
twice.
I
boot
once
sorry
in
minimum
and
to
boot
into
a
new
version
of
your
operating
system
and
you
fit
your
records
version
because
you
start
initially,
you
start
with
yeah
this
vm
template,
that's
run
that's
stored
in
vsphere
and
beginning
from
this
operating
system
version
say:
vms
are
running
waiting
for
the
ignition
file
say,
get
it
fetch
a
new
or
the
say,
os
version,
that's
determined
for
a
certain
okd
release.
B
They
are
booting
into
the
new
os
version
and
join
the
fake
control
plane.
That's
created
that's
running
on
the
bootstrap
node.
If
the
control
pane
is
running,
then
in
the
next
step
the
bootstrap
load
node
stops
serving
an
ignition
file.
The
load
balancer
will
see
that
and
turn
off
the
bootstrap
communication.
B
In
this
phase
you
could,
in
theory,
delete
your
bootstrap
vm,
because
you
don't
need
it
anymore,
then
the
worker
vms,
they
are
running
all
the
time
and
also
I'm
fetching
an
ignition
file
for
the
workers
from
at
this
time,
the
control
plane
that's
running
with
our
masters.
B
They
are
constantly
pulling
for
that
and
if
the
master
control
as
a
control
plane
is
set
up
again,
a
web
server
will
serve
the
ignition
file
for
the
workers,
so
workers
will
fetch
the
ignition
files
load,
the
current
version
of
fedora
chorus
boot
into
it
and
finish
the
installation,
and
afterwards
you
have
a
running
okd
cluster.
B
So
to
achieve
that
said,
you
have
a
load,
balancer
and
dns
dhcp
server.
You
have
to
set
up
a
little
bit
in
advance.
I
created
some
documentation
about
this
process.
Don't
get
frightened!
It's
it's
lots
of
text.
I
only
will
sweep
fast
over
that.
B
I
think
I
used
a
lots
of
standard
documentation.
You
can
find
on
the
internet,
it's
nothing
special
about
that.
B
B
I
have
two
domains.
I
have
my
home
lab
net
domain
where
everything
in
my
in
my
home
is
regis
registered
to
and
then
I
have
a
sub
domain.
C1.
It's
c1
means
a
cluster
one
home
labnet,
where
all
my
kubernetes
nodes,
my
okade
nodes,
are
running.
Inside
my
I
have
a
dhcp
range
and
I
use
a
static
eyepiece
for
the
most
important
nodes,
because
I
yeah,
because
I
tried
lots
of
installation
strategies
I
like
to
have
fixed
ips
for
the
most.
B
For
the
most
important
vms
and
for
them
I
use
static
piece
for
sure.
If
I
create
dynamic
nodes
through
machine
sets
later,
I
can
use
a
dhcp
for
them,
but
yeah
it's
a.
I
use
a
mixed
scenario
for
that
for
them.
B
First,
you
have
to
do
the
usual
things
I
use
raspberry,
pi
os
for
my
recipe.
I
update
a
package
list.
I
give
them
a
static
ip.
Then
I
install
isc
dhcp
server.
In
my
case,
I
use
that
for
the
dhcp
server
I
set
up,
see,
isn't
it
part
configure?
I
do
the
basic
configuration
here
resist
business
file
and
the
first
section
is
for
dynamic,
dns
yeah.
It's
not
nothing
special
about
that.
B
I
here
this
section
is
served
by
the
dhcp
server
every
time
a
new
node
requires
an
internet
address
your
etc
resolve.
Conf
file
will
be
filled
by
parts
of
this
options
here
here
we
have
the
definition
of
our
subnet
rate
of
sorry,
our
dhcp
range,
and
here
are
the
the
static
ip
sections
where
I
use
the
mac
address
that
is
configured
by
terraform
in
vsphere
to
serve
c
vms
that
are
registrating
themselves
or
I'm
asking
for
ip
addresses
fixed
ip
addresses.
B
I
do
that
for
the
bootstrap
master
nodes,
worker
nodes
and
yeah
that
sets
it
for
the
dhcp
server.
The
next
thing
is
setting
up,
say:
dns
server,
it's
a
little
bit.
Yeah
more
files
are
involved
in
this
because
I
use
bind
for
that.
I
started
with
dns
mask,
but
I
was
not
convinced
with
its
features
so
as
I
throw
it
out
very
quickly
and
use
bind
also
for
that.
You
find
lots
of
information
in
the
internet
and
it's
nothing
special
in
the
configuration
about
that
that
I
use.
B
We
have
a
access
control
list
here,
where
I
say
every
ip
from
my
subnet
in
the
home
lab
can
access
the
dns
server.
I
have
yeah.
I
configure
it
also
as
a
forwarder.
If
a
domain
name
is
not
known
to
the
dns
server,
it
will
forward
its
request
to
our.
I
think.
It's
google
see
google
dns
servers
the
internet
here.
I
turn
off
a
few
security.
B
Switches
because
I
had
problems
with
that
and
I
yeah
I
don't-
have
the
energy
to
find
out
how
to
make
it
really
really
secure,
but
I
will
improve
that
the
next
time.
It's
a
aside
task.
I
gave
myself
here.
I
define
my
zones,
I
have
a
home
lab
net
zone.
I
have
the
zone
where
okay
will
run
its
vms.
B
It's
referencing,
a
file
where
I
configure
the
records,
as
described
in
the
official
documentation,
and
I
have
a
reserve,
a
reverse
zone
setup,
because
it's
yeah
it's
best
practice
you
you
don't
really
need
it
for
a
home
lab,
but
I'm
using
it,
because
I
I
wanted
to
try
out
how
to
set
this
up
here.
We
have
a
few.
Yes,
this
is
a
the
zone
file
for
my
home
lab
in
real
life.
B
A
lot
of
entries
are
here
because
I
use
things
other
than
okt
that
are
using
this
dns
server,
and
this
is
a
setup
for
my
reverse.
Lookup.
A
reverse
zone
file
so
here
is
now
is
interesting
part
because
here
we
have
the
sound
file
for
c1
cluster,
one
home
labnet,
and
you
will
see
yeah
lots
of
records
here.
B
These
are
the
records
that
are
required
by
okd
to
work.
We
have
here,
wildcard
cname,
that's
everything
here
is
going
to
the
load
balancer.
This
is
the
internal
api
jamie
talked
about.
We
have
an
external
api
record
here.
We
have
c
workers,
the
master,
the
bootstrap
node
and
the
load
balancer
node,
that's
pretty
much.
B
B
B
Here
we
have
a
load
balancer
for
the
ignition
configuration
file
server
and
because
maybe
you
remember
it's,
the
first
step
is
that
the
bootstrap
node
will
serve
the
ignition
files
afterwards.
Also,
the
master
files
will
serve
them
and,
if
say,
serves
the
ignition
files,
bootstrap
mode
output,
step
node
will
stop
serving
the
conditional
files
and
the
switch
over
is
controlled
by
the
load
balancer,
and
here
we
have
the
routes,
say:
port
80
for
http
local
lenses,
and
it's
the
same
for
https.
B
I
have
provided
all
my
nodes
to
see
local
lenses
because
I
like
to
move
the
open,
shifter
or
okd
router
around
between
the
nodes
to
test
things.
That's
why
I
not
only
have
the
workers
in
the
list,
but
also
the
masters.
B
If
you
reboot
your
node,
you
should
check
if
all
system
d
services
are
still
running
or
if
there
are
errors
thrown
out.
You
can
use
var,
lock
and
syslog
to
find
to
troubleshoot
if
something
goes
wrong,
but
my
experience
is
that
if
you
follow
this
guide
here,
it's
not
so
much
as
it
looks
like
then.
Normally
it
should
work
rather
fast
and
then
in
the
end,
you
have
external
components:
load,
balancer,
dns,
server,
dhcp
server,
it's
a
setup.
I
think
it's
rather
common
in
in
lots
of
companies.