►
From YouTube: CodeReady Containers; Simplified Deployment and Cluster API for Desktops - Gerard Braad, Red Hat
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
CodeReady Containers; Simplified Deployment and Cluster API for Desktops - Gerard Braad, Red Hat
With the introduction of OpenShift 4.0, a new method of installation targeting cloud providers was introduced. For CodeReady Containers we provide a simplified method to enable this installation for desktop hypervisors, like kvm, xhyve/hyperkit and Hyper-V on respectively Linux, macOS, and Windows. I will talk about the lessons learned with the previous approaches used to enable desktop deployments, like minikube and minishift and how we improve on this and how we enable the Cluster API to target desktop virtualization. Using the Cluster API it will be possible to scale out and add additional nodes to the cluster, and in our case, you will be able to add nodes to desktop hypervisors.
https://sched.co/NrnV
A
A
So
before
red,
head,
I
worked
on
large-scale
OpenStack
deployments
and
I
developed
a
lot
of
codes
that
deal
with
agile
projects,
and
it
probably
also
explains
a
little
bit
why
I
kind
of
care
about
what
I'm
doing
here
so
currently
I'm
working
on
container
technology,
everything
targeting
docker,
kubernetes,
Putman,
OpenShift
and
then
specifically
developer
tools.
The
tools
that
I
develop
are
all
kind
of
utilizing
virtualization
to
simplify
a
problem
that
we're
having
these
can
be
liver,
KVM,
hyper-v,
hyper
kid
and
something
else
that
we
are
doing
machine
drivers.
A
So
part
of
my
work
is
that
I
worked
on
mini
cube.
Probably
people
have
used
that
before
it's
almost
essential.
If
you
want
to
learn
about
what
kubernetes
is
so
the
project
that
I
worked
on
at
that
moment
is
called
mini
shift
and
now
working
on
code,
ready
containers,
so
developer
tools,
developer
tools.
Is
we
didn't
read,
had
a
division
that
is
kind
of
focusing
on
tooling
that
has
to
deal
with
developing
container
based
applications.
A
Container
based
applications
is
a
completely
different
way
of
how
you
should
look
at
your
application
and
for
a
lot
of
people
that
was
kind
of
like
how
to
start
so
with
in
Red
Hat.
They
saw
that
there
were
a
lot
of
tools
in
the
market,
mesosphere
and
and
kubernetes,
not
even
a
thing
yet
and
they
thought
of
well.
Maybe
we
need
something
and
they
called
it
a
to
be
the
atomic
developer
bundle.
They
provided
different
tools
to
get
it.
A
You
get
you
going
on
developing
container
based
applications
and
over
time
that
developed
just
like
kubernetes
became
a
thing
more
like.
We
should
have
something
that
targets
specifically
how
to
be
develop,
applications
targeting
that
and
that
became
mini
shift.
So
many
she
has
started
out
as
a
prototype
tool
from
I'm,
not
mistaken.
Jimmy
Dyson
worked
a
lot
on
kubernetes,
but
for
Red
Hat,
specifically
on
open
shift,
and
he
took
the
source
code
from
any
coop
forked
it
and
changed
some
stuff
making
it
work
for
our
purposes,
which
was
good.
A
A
No,
and
especially
here,
because
it
is
not
easy
to
get
kubernetes
up,
it's
especially
not
easy
to
get
OpenShift
up
and
running,
and
if
people
tell
you
oh,
you
should
run
it
on
AWS.
That's
not
an
answer
you
want
to
hear.
That's,
certainly
not
something!
You
could
do
as
most
developers,
let
alone
that
you
have
access
to
AWS
or
whatever.
So
that's
why
we've
worked
on
this
and
we've
notice
a
lot.
So
one
of
the
things
of
most
of
the
things
we
learned
was
this:
the
lessons
learned
and
I'm
pretty
sure.
A
There's
a
guy
there
sitting
who's
from
mini
cube
our
colleagues
in
a
way.
So
what
we
notice
is
networking
always
complicated
deployment.
If
you
understand
how
many
cube
works,
how
you
understand
how
docker
for
Windows
or
Mac
works?
It's
a
virtual
machine
and
a
virtual
machine
is
not
your
native
machine.
There's
networking
involved
the
virtual
networking
layer
so
as
soon
as
a
company
would
deploy
this
kind
of
tool.
We
ran
into
issues
like
oh,
but
I
need
to
use
a
VPN
to
access
my
company
resources.
A
Well,
that
should
not
be
an
issue
right,
but
my
VPN
tool
uses
a
router
all
so
every
traffic
all
of
it
will
go
through
the
VPN.
Oh
that's
painful,
because
that
means
that
the
yet
a
fear
access
to
that
VM
will
also
all
of
a
sudden
go
over
the
VPN,
which
is
in
that
moment,
not
local
anymore.
So
we
ran
into
a
lot
of
issues
here,
also
the
other
stuff
that
we
notice
is.
A
There
were
firewalls
involved
and
proxies,
especially
on
if
you're
doing
Windows
the
deployment
tools
like
your
virus
scanner,
McAfee
Symantec,
endpoint
protection,
whatever
tool
there
could
be,
they
might
inspect
your
packages
and
might
in
that
case
hey.
This
is
a
network
segment
that
we
don't
know
they
will
block
the
tray.
The
exes
now
or
proxies
even
and
especially
here
proxies
will
be
company
proxies.
Our
resources
need
to
be
accessed
on
a
different
place
or
via
a
proxy.
You
actually
get
access
to
it.
A
A
A
Besides
that,
we
were
also
working
on
lip
machine.
If,
if
you
know
what
lip
machine
is
any
of
you,
maybe
okay,
good
one
or
two
fingers
go
up.
So
it's
a
library
that
the
people
at
docker
made
specifically
for
setting
up
docker
runtimes
on
platforms
where
they
could
self
contain
it.
So,
even
on
Linux,
for
instance,
you
would
can't
run
up
or
spin
up
a
very
simple
VM
and
within
that
VM
that
would
be
a
docker
container
runtime
environment.
A
Well,
that's
great
because
that
means
that
you
can
kind
of
replicate
on
other
platforms
you're
using
a
VM
on
windows
in
the
VN
on
Mac
OS,
and
it
would
all
be
similar
in
a
way.
However,
this
docker
library
is
dependent
on
the
resources.
At
that
moment,
a
doctor
would
put
into
it
and
the
community
effort
docker
decided
at
some
point
in
time.
Well,
this
is
not
a
library
we
will
be
using
anymore,
but
we
and
mini
Cube
we're
relying
on
it.
A
We
are
forked
from
mini
cube,
so
we're
not
mini
cube,
and
we
had
talked
many
times
with
several
of
these
team
members.
What
we
can
do
there
we
might
be
able
to
integrate
a
way
to
post,
start
and
and
pre
start
to
be
able
to
actually
get
something
in
there
that
we
can
run
our
commands
for
them.
Deploying
our
tools
and
a
lot
of
these
ideas
did
formalize,
but
they
were
not
in
the
time
schedule
that
we
were
trying
to
develop
it
one
of
them.
That,
of
course,
was
integrated
was
cube.
A
Admin
now,
but
for
in
our
case
we
would
like
to
have
had
that
earlier,
but
yeah.
Unfortunately,
so
what
we
did
instead,
is
we
faked
a
lot
of
the
issues?
Ssh
issues
were
trying
to
get
access
to
the
machine
stability
issues
with
networking,
especially
even
in
lip
machine.
We
have
many
issues
resolving
a
around
the
idea
of
localization
and
internationalization,
but
we
notice
that,
unfortunately,
for
us,
it's
very
hard
to
deal
with
a
fork
project.
A
A
So
now,
I'm
gonna
talk
a
little
bit
about
what
then
OpenShift
for
code
ready
containers
and
cluster
api
is
so
open.
Shift4
is
a
new
version
yay,
but
just
like
the
previous
version
of
openshift,
it
provides
everything
you
want
to
get
your
source
to
running
an
application,
what
we
call
source
to
image,
but
it
provides
with
that
a
lot
more.
A
It
becomes
a
trusted
enterprise,
kubernetes
solution,
highly
available,
which
actually
is
for
us,
a
thing
that
we
don't
need
and
install
a
provision,
infrastructure,
auto
update
operators,
and
it
would
be
deployed
on
RedHat,
core
OS,
but
yeah.
We
want
to
provide
a
developer
tool
that
you
could
run
on
your
local
machine
and
they
even
came
it
well,
there's
a
new
installer.
This
new
installer
is
also
a
product
from
the
lessons
they
learned
related
to
the
installers
they
had,
they
had
ansible
scripts
and
and
they
had
a
different
installation
method
and
it
didn't
work
for
us.
A
It
targets
example,
for
example,
the
the
cloud
providers
when
the
first
release
came
out
a
targeted
AWS
specifically,
but
now
over
time
it
will
support
Azure
and
will
also
support
to
bring
your
own
hardware
and
stuff,
but
usually
what
it
will
do
is
it
will
try
to
maintain
the
nodes
in
the
cluster,
and
this
is
what
we
call
the
installer
provided
infrastructure
API
with
that
it
will
create
nodes
that
run
Korres
red
head
Korres
to
do
that.
It
actually
creates
minimal,
bootstrap
and
master
nodes
to
form
that
control
plane.
A
This
is
all
kind
of
like
as
what
the
the
cluster
API
would
expect.
So
and
after
that
work,
your
notes
are
created
using
the
cluster
API.
So
how
will
that
look
like?
So
this
is
Francis
your
cloud
provider
see
it
as
your
AWS
or
something
else.
It
will
integrate
an
initial
bootstrap
VM.
This
bootstrap
VM,
actually
in
cope,
encompasses
kind
of
like
a
net
CD.
As
an
initial
start
for
your
cluster.
It's
an
ephemeral
VM.
It
means
that
this
VM
will
not
stay
around
after
the
cluster
has
been
created.
A
All
the
masters
will
be
provisioned
and
started
and
created
at
the
same
time,
with
the
information
from
the
booster
PM.
So
after
that
is
done,
you
get
rid
of
the
bootstrap
after
that
cluster
API
comes
into
play,
so
the
cluster
API
is
a
way
to
deal
with
the
creation
of
notes
within
a
very
general
way.
For
instance,
if
you
want
to
create
notes
on
a
platform
like
Amazon,
you
don't
want
to
know
and
specifically
want
to
know
the
Amazon
API
to
talk
from
your
cluster.
A
How
to
create
these
notes
so
for
day,
one
there's
an
installation
of
installation
of
the
cluster
and
for
2d
day
to
operations.
It
deals
with
management,
how
to
scale
out
how
to
maintain
them.
So
this
is
what
it
will
look
like.
Then,
after
the
masters
are
created,
the
cluster
is
ready
in
a
way,
but
you
can't
run
a
workload.
The
Masters,
the
control
plane
is
marked
as
tainted.
A
It
talks
to
the
control,
plane
and
retreats
that
definition
and
those
notes
will
be
created
so
great,
but
this
is
mostly
targeting
cloud
providers
so
for
us
that
wouldn't
work.
So
how
do
you
develop
this
on
a
developer
environment?
That's
local!
How
do
you
gonna
test
actually
that
something
for
the
cluster
API
works
as
expected?
So
one
of
the
things
that
we
did
in
our
teams
is
we
worked
on
the
libvirt
cluster
API,
specifically
a
provider
and
for
the
cluster
API
that
deals
with
local
lippert
environments.
A
So,
in
this
repository
you
can
find
more
information
about
that
for
sure.
I
will
later
actually
show
a
video
about
that.
As
a
short
demo,
it's
still
for
now
in
our
situation,
it
creates
the
bootstrap
using
terraform
yeah,
but
the
so
it
will
look
like
this,
so
there
will
be
an
operating
system
with
a
virtual
machine
monitor
in
this
case
livered,
there's
a
bootstrap
that
it
gets
created
and
the
same
masters
exactly
the
same
situation.
A
So
for
the
lipfird
provider
there
will
be
no
difference
in
how
we
deploy
and
then
again
we
instruct
the
cluster
api
to
create
the
worker
nodes.
But
then
that's
not
what
we
want.
If
you
want
to
have
a
development
tool
locally,
we
don't
want
to
create
a
high
available
environment.
So
we
want
a
tool
that
provides
a
local
openshift
for
cluster.
We
can
have
a
new
start.
Luckily,
we
have
a
new
tool
and
the
opportunity
needs
to
do
that,
but
hey
it
needs
to
be
familiar.
A
Okay,
it
needs
to
be
simple
to
use.
It
needs
to
do
start/stop,
delete
and
setup
and
emphasize
here
on
setup,
so
we
wanted
to
stay
as
both
as
possible
close
to
what
mini
cubed.
This
is
what
we
have
done
before.
That's
the
same
as
we
did
with
mini
shift.
So
we
want
to
do
that
again,
because
this
is
what
people
expect,
although
we
do
introduce
a
new
command
like
setup.
A
A
So
this
is
actually
kind
of
where
the
the
the
problem
for
are
started.
It's
more
like.
How
do
we
do
that
then?
So,
let
me
see
so
we
created
a
single
node
cluster
according
to
this
repo,
where
we
prefer
to
deploy
master
and
worker
on
a
develop
of
a
machine
in
a
single
VM
instance,
which
means
that
we
needed
to
disable
certain
things.
We
untain
the
virtual
machine
and
now
what
we
do
at
the
end
is
we
create
actually
a
VM
image,
very
simple:
we
bundle
it
up.
A
This
tale
took
away
the
problem
for
us
that
we
had
with
actual
packaging
it
up,
because
when
we
did
an
installation
before
it
mini
shift,
people
would
start
it.
It
will
pull
images
from
the
network,
we
would
touch
remote
registries.
These
might
not
work
because
there
was
no
network
connectivity
or
it
was
burdened.
So
now
you
download
a
whole
bundle
of
a
VM,
and
at
that
moment,
when
you
do
start
it
unpacks
it.
It
starts
the
VM
and
everything
is
there.
A
So
the
only
problems
that
you
will
encounter
is
the
cluster
is
up
and
then
so,
if
the
network
is
then
unavailable,
that's
a
different
situation.
At
least
you
have
your
cluster
yeah,
so
people
said
but
hey,
but
then
I
have
a
download
with
it's
1.9,
G
or
more
well.
If
you
do
a
stop-start
delete
and
start
delete,
stop
whatever
you
order,
you
do
that
as
soon
as
you
delete
it,
something
before
with
many
shift
for
mini
queue.
A
A
If
we
want
to
do
nightly
releases,
for
instance,
of
open
shift
or
even
kubernetes,
it's
slightly
more
difficult
because
you're
not
going
to
create
these
images,
although
we're
now
considering
it
may
be
actually
to
do
that,
yeah
so,
but
then
there's
another
thing:
people
still
actually
want
to
be
able
to
scale
out
and
the
Machine
set.
They
asked
us,
but
now
I
have
that
single
node
VM
and
a
single
node
cluster.
Is
it
possible
to
actually
use
the
cluster
API?
Yes,
it
is.
We
are
now
at
the
moment,
still
developing
it.
A
It's
that
kind
of
a
work
in
progress.
There
needs
to
be
some
changes
for
that,
because
you
miss
some
images
on
your
local
machine,
but
it's
actually
possible
to
actually
also
talk
to
the
same
environment
and
say
well
scale
out.
I
have
a
single
node
cluster,
but
now
I
want
several
workers.
Is
that
possible?
Yes,
sure
change
the
replica
set
and
it
will
create
for
you
new
workers,
because
it
will
be
able
to
talk
at
that
moment
to
your
local,
liver,
liver
daemon.
So
that
will
look
like
this.
A
This
is
kind
of
at
the
moment
of
a
handwork.
You
need
to
do
a
little.
You
need
to
enable
liver
to
listen.
You
will
need
to
be
able
to
talk
to
this
end
point.
It
has
to
be
very
specific
because
it's
now
hard-coded
in
in
the
lippert
environment,
but
that's
actually
kind
of
what
we
always
deploy.
So
this
should
work.
We
changed
the
the
the
replicas
from
zero
to
actually
what
you
want
and
it
should
be
able
to
spin
up.
A
Your
worker
notes
actually
says
here
zero,
but
it
should
be
too
so
so
now
the
current
state
that
we
have
with
code
rated
containers
we
are
able
to
deploy
on
live
earth
and
KVM
as
the
original
targets.
We
had
a
lot
of
good
feedback
about
that.
We
are
still
now
working
on
the
actual
hi
packets
solution.
We
we
bumped
into
some
issues,
but
they
were
related
to
some
driver
issues.
We
have
resolved
them
now
and
they
ship
will
be
proposed
upstream
and
we're
kind
of
now,
looking
at
hyper-v
I'm
just
beginning
to
do
that.
A
So
I
see
that
the
time
is
quite
short
future,
as
I
said
already,
we
want
to
be
able
to
work
on
hyper-v,
but
this
needs
specific
support,
and
if
you
know,
if
you
having
a
cluster,
you
need
to
be
able
to
use
DNS
and
specifically
for
OpenShift,
it
will
actually
have
inter
cluster
communication
based
on
domain
names.
So
we
need
to
provide
the
DNS
solution.
We
have
been
testing
it
now
for
VirtualBox
and
it
works
perfectly
so
we'll
be
able
to
see
if
this
will
also
work
for
hyper-v.
A
Our
next
step
after
that
is,
we
are
anticipating
or
really
to
release
an
upstream
project
for
this
mini
chef
was
always
upstream
first,
but
unfortunately,
for
this
situation
now
is
how
open
ship
got
released.
We
have
to
kind
of
do
the
reverse.
We're
now
looking
at,
if
Fedora
chorus
will
have
an
image
for
that
or
CentOS
to
provide
our
basis
for
that,
but
the
other
stuff
that
we
are
actually
also
in
looking
into
is
done
well.
Besides
that
we
could
also
integrate
tools
for
pop
man
and
builder.
A
We
have
been
working
before
with
people
who
did
about
a
boot
department
project
for
that
and
we're
trying
to
see
if
we
can
help
out
with
harmonizing
some
of
these
images
and
and
tooling
set
for
that.
We're
also
looking
at
the
machine
drivers
again,
especially
for
mini
coop,
is
this
will
be
very
helpful.
We've
solved
a
lot
of
issues
that
are
related
to
networking
like
static
IP,
and
we
would
like
to
see
how
we
can
help
with
that
to
get
that
up
and
running
for
them
and
more
cooperation,
hopefully
in
the
future,
with
them.
A
A
But
the
way
that
communication
is
handled
is
slightly
different,
so
we're
looking
at
how
it's
possible
to
kind
of
have
an
intermedia
if
we
want
to
do
that
on
your
local
machine
that
understands
the
win
RM
protocol
for
management
to
actually
start
local
machines
on
hyper-v.
This
is
very
preliminary.
We
haven't
made
any
decision.
We
kind
of
have
the
same
problem
for
high
packet.
High
packet
itself
has
no
management
tooling
whatsoever,
so
there
are
no
tools
actually
to
easily
deal
with
lifecycle
of
that.
So
is
there
something
that
we
might
have
to
create
for
that?
A
If
we
really
want
to
create
a
local
cluster
API
provider
for
that-
and
these
are
questions
that
we
have
and
would
like
seriously
to
hear
from
people
if
what
their
thoughts
about
that
is
so
I
will
stop
here.
I
would
like
to
thank
you.
That's
my
reach.
Yet,
if
you
want
to
sync
up
and
talk
to
me
again,
if
you
want
to
send
me
an
email,
particularly
about
mini
shift
or
quadratic
containers,
please
send
it
to
Red
Hat.
A
B
Thank
you
for
your
presentation.
I
have
a
question
actually
I.
Think
I.
Miss
turn
just
to
the
word
desktop
virtualization,
because
I'm
was
trying
to
do,
is
to
put
the
GUI
applications
inside
a
container
and
then
managed
by
varieties.
So
actually
we
are
already
succeeded
in
putting
the
linux
based
application
inside
the
container.
C
B
A
That's
not
the
purpose
of
our
project,
but
I
I
know
that
people
have
been
looking
at
that,
especially
specifically
for
Windows
containers
and
stuff
I,
wouldn't
be
able
to
answer
that,
for
you.
I
could
ask
around
what
we
can
do
about
that,
because
one
of
the
things
that
we
even
as
mini
cube,
also
talked
about
many
times.
A
B
C
A
Right
right,
right:
okay,
so
in
mini
shift
and
in
mini
cube,
you
can
have
multiple
instances
on
your
machine,
which
is,
if
you're
working
on
a
different
project
or
different
streams.
It
could
be
very
helpful.
I
understand
that
for
many
shift
this
was
possible
and
Femina
queue,
because
the
resources
that
you
reuse
on
a
machine
were
kind
of
quite
minimal.
A
It
wasn't
that
much
so
at
this
moment
since
we're
quite
early
with
the
code
ready
containers,
we
have
decided
to
be
now
a
single
profile,
a
single
instance,
but
in
future
it
is
possible
for
us
to
very
easily
provide
the
support
to
have
multiple
instances.
We
have
everything
in
our
code
base
already
handling
this.
There
are
multiple
ways
to
talk
to
the
VM.
We
have
names
properly
coded
for
that.
We
could
even
have
multiple
virtual
machines
within
an
instance
like,
for
instance,
a
master
and
a
worker,
so
we
already
have
support
for
multi
node
cluster.
A
So
we
have
support
for
that
in
future.
But
at
this
point
in
time
it's
not
something
we
have
focused
on
we've
now
only
got
the
first
alpha
release
out
for
I.
Think.
Is
it
three?
Four
weeks,
so
it's
it's
very
early
on,
but
I
would
definitely
see
people
requesting
it.
So,
yes,
it's
it's
an
option.
It's
it's
possible.
I'm!
Just
gonna
tell
you
when.