►
From YouTube: SIG Cluster Lifecycle: kubeadm Deep Dive – Alexander Kanevskiy, Timothy St. Clair & Luke Marsden
Description
Want to view more sessions and keep the conversations going? Join us for KubeCon + CloudNativeCon North America in Seattle, December 11 - 13, 2018 (http://bit.ly/KCCNCNA18) or in Shanghai, November 14-15 (http://bit.ly/kccncchina18).
SIG Cluster Lifecycle: kubeadm Deep Dive – Alexander Kanevskiy, Intel, Timothy St. Clair, Heptio, & Luke Marsden (Intermediate Skill Level)
About Alexander
Alexander has 20 years of experience in area of creating Linux distributions for different market segments, SCM, Infrastructure, Release Engineering, Continuous Integration & Delivery and various build systems. Previous projects: BlackCat Linux, ASPLinux, OpenWall, Maemo, MeeGo, Tizen, Yocto Currently employed by Intel, Open Source Technology Center in Cloud Technologies group as Architect.
About Luke
Luke is the CEO and Founder at Dotmesh. He is also a Kubernetes SIG lead for SIG-cluster-lifecycle, where he was involved in developing the first version of kubeadm. He previously worked on Developer Experience at Weaveworks, where he spoke and taught at conferences, meetups and trainings on cloud native topics such as container networking, monitoring with Prometheus, continuous delivery and OpenTracing. Before that he was the CTO and Founder at ClusterHQ, where he got involved right at the start of the Docker and Kubernetes journey, collaborating closely with Docker and others to develop the first Docker volume plugin mechanism and build the first implementation of container persistence, Flocker.
About Timothy
Timothy St. Clair is a Staff Software Engineer at Heptio and is a core contributor to the Kubernetes project, a Steering Committee member, and a lead on SIG-Cluster-Lifecycle. Timothy is also a PMC member Apache Mesos Project, and has worked on the development and integration of various open source distributed systems projects, including Kubernetes, Mesos, Tachyon, Hadoop, and Condor.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
A
Hello,
cool
hi,
everyone
we
are
going
to
do
a
30
minute
talk
with
three
speakers,
so
we've
got
10
minutes
each.
My
name
is
Luke
Luke
Marsden
from
top
mesh
and
yeah.
This
is
kubernetes
cube
admin
deep
dive.
So
so
we
all
work
together
in
the
special
interest
group
or
cluster
lifecycle,
and
for
quite
a
while.
A
Then
Tim's
going
to
work,
talk
about
upgrades,
self-hosting
and
H
a
which
are
the
areas
where
we're
developing
cube
admin
in
the
future,
and
then
Alexander
is
going
to
talk
about
using
cube
admin
in
an
enterprise
environment,
in
particular
in
a
locked-down
environment
where
you
might
not
have
all
the
usual
sort
of
access
to
the
internet
and
nice.
Things
like
that
that
you
might
be
used
to
otherwise
so
jumping
straight
into
the
intro
history.
A
So
if
she
sort
of
cast
your
mind
back
to
September
2016,
this
is
around
the
time
that
this
all
got
started
and
at
the
time
kubernetes
was
insanely
hard
to
install
it
was
there
was
this
this
project
from
Kelsey
Hightower
called
kubernetes.
The
hard
way
has
anyone
ever
heard
of
Linux
from
scratch.
Yeah
we're
you
surprising.
Number
of
people
have
heard
of
Linux
from
scratch,
like
where
you
compile
your
own
compiler
and
stuff,
like
that.
A
If
kubernetes
the
hard
way
felt
a
little
bit
like
that,
it
was
like
you
spin,
your
own
TLS
certificates
and
you
put
them
in
all
the
right
places,
and
you
start
all
the
right
containers
and
press
go
and
then
everything
works,
but
it's
really
fiddly
and
like
kubinashi's,
the
hardware
was
intended
as
a
tool
for
it
was.
It
was
documentation
for
learning
how
kuva
Nettie's
worked
on
the
inside,
but
it
wasn't
very
great.
A
It
wasn't
a
great
experience
for
people
who
actually
just
wanted
a
functional
and
also
to
be
honest
at
the
time
docker
had
just
launched
this.
This
thing
called
docker
swarm
and
docker
swarm
was
insanely
easy
to
install.
There
was
a
I
think
it
was
like
docker
swarm
in
it
and
docker
swarm
join,
and
that
was
it
and
so
Joe
and
the
team
working
on
on
kubernetes
sort
of
as
a
group.
A
We
all
felt
the
pressure
to
to
be
competitive
with
this
user
experience
and
that's
a
good
thing,
I
mean
that
competition
and
drove
us
to
to
build
something
better.
The
other
thing
that
was
happening
was
that
there
were
lots
of
projects
to
install
kubernetes
sort
of
coming
up
and,
and
everyone
was
sort
of
reinventing
the
wheel,
and
it
was
a
shame
that
there
was
so
much
repetition
of
epic
efforts.
A
So
what
we
decided
to
do
was
to
to
spin
up
this
new,
this
new
kubernetes
sig
called
sig
cluster
lifecycle
for
managing
the
whole
lifecycle
and
building
tools
and
tool
kits
around
installing
kubernetes,
upgrading,
kubernetes
and
and
so
on.
So
one
of
the
first
things
that
we
talked
about
and
a
really
important
decision
that
we
made
early
on
was
that
we
were
not
going
to
try
and
manage
provisioning,
bootstrapping
and
add
ons.
A
The
reason
for
this
was
that
there
was
a
huge
variety
in
how
people
wanted
to
provision
machines,
so
I
guess
I
should
take
a
step
back.
The
way
you
get
a
cluster
is
that
you
get
some
computers
and
then
you
bootstrap
kubernetes
on
them,
and
then
you
install
some
add-ons
for
essential
services
like
networking
and
storage,
and
we
talk
to
people,
and
there
were
just
so
many
ways
that
people
wanted
to
get
machines
like
getting
machines
was
something
that
was
tremendously
diverse
as
a
in
in
terms
of
how
people
did
it.
A
Lots
of
people
like
using
terraform
lots
of
people
like
using
cloud
formation.
Lots
of
people
want
to
work
on
bare
metal.
Some
people
want
to
use
raspberry
PI's
and
there
isn't
a
consistent
way.
It
was.
We
realized
early
on
that
if
we,
if
we
got
into
the
provisioning
game,
that
we
just
sort
of
get
stuck
in
a
quagmire,
but
that's
the
work
that's
now
happening
under
the
auspices
of
the
cluster
API
and
that's
great,
but
we
decided
not
to
start
there
now
sort
of
back
in
September
20
2016.
A
So
we
decided
to
focus
on
these
two
areas
of
bootstrapping
and
add-ons
and
I
can
show
you
how
that
works
so
didn't
have
time
for
a
full
demo,
but
I'm
gonna.
Take
you
through
some
screenshots
of
some
terminals
really
quickly.
The
first
release
of
cube
admin
was
in
1.4
and
it
looks
a
little
bit
like
this
so
step.
One
is
up
to
you
get
some
computer's
running
Linux,
so
you
do
that.
However,
you
like
and
by
the
way
cube
admin
was
designed
to
be
used.
A
It
was
designed
to
be
automated
around
as
well,
so
we
one
of
the
really
nice
things
that
happened
soon
after
we
released
cube
admin
was
that
we
saw
lots
of
projects
popping
up
on
github
that
used
cube
admin
as
an
implementation,
detail
of
broader
kubernetes
provisioning
techniques,
and
we
saw
terraform
scripts
that
wrapped
cube
admin.
We
saw
things
that
install
cube
admin
on
on
GC,
and
this
was
great.
This
is
exactly
what
we
wanted
to
happen
because
those
those
those
tools,
those
those
projects
were
much
much
simpler
than
they
would
have
been
without
cube
admin.
A
So
that
was
the
point.
So
this
is
how
you
can
create
a
cluster
using
cube
admin
step.
One
install
docker
step
to
install
Kubler,
cube
admin
and
cube
cuddle,
and
these
are
all
just
apt-get
install
commands
at
the
moment
I'm
assuming
Ubuntu.
Then
you
run
cube
admin
in
it
on
the
master
node.
Then
you
have
a
master
node
and
then
you
take
the
output
of
the
cube.
Admin
join
command
that
cube
admin
and
it
spits
out-
and
you
paste
that
into
some
other
computers
and
those
computers
where
you've
already
installed,
are
install
the
tools.
A
You
then
run
cube.
Admin
join
and
now
you've
got
your
first
node
in
the
cluster
and
then
you
do
the
same
thing
again
and
now
you've
got
your
second
node
in
the
cluster,
and
now
you
have
a
three
node
cluster
ready
to
go
almost
except
the
state
that
cube
admin
gets
you
to
is
just
a
cluster
that
doesn't
have
networking
working
yet,
and
so
you
can
think
of
cube
admin
really
as
a
way
of
getting
a
bare
bye
set
up.
A
You
can
now,
however,
install
some
networking,
so
I'll
use
the
example
of
using
weave
net
here.
Two
lines
is
pretty
easy.
You
can
then
add
some
more
add-ons.
So
if
you
want
to
you
can
install
some
storage
and
I
use
the
example
of
my
project
mesh
here
and
then
you
have
a
cluster,
that's
ready
for
your
apps,
so
it's
pretty
simple.
A
However,
these
cube
adnan
clusters
initially
were
hard
to
upgrade.
We
didn't
when
we
got
the
first
release
out.
We
didn't
yet
have
a
documented
way
of
upgrading
them
and
that
kind
of
sucked.
So
that's
something
that
we've
since
solved
with
better
documentation,
but
there's
also
additional
work
going
on
to
make
that
easier,
and
the
other
thing
that
that
people
really
wanted
was
the
ability
to
have
multiple
masters
and
so
to
have
high
availability.
So
Tim's
now
going
to
talk
about
the
work,
that's
underway,
to
solve
those
problems
and
over
to
Tim
hello.
A
B
I'm
gonna
be
talking
about
self
hosting
upgrades
in
H,
a
with
cuvee
DM
and
those
who
have
been
around
sequester
lifecycle
for
a
while
know
that
we've
been
talking
about
it
for
a
while
right.
So
some
of
these
things
are
really
kind
of
hard
and
Tim
Hawkins
had
the
feature
corkscrew.
Eventually
it
leads
to
a
point.
This
is
an
example
of
a
feature
circle,
because
if
you
change
one
thing,
it
will
affect
the
behavior
of
the
others.
B
So
we
had
to
think
long
and
hard
about
how
we
wanted
to
do
things,
and
we
also
wanted
to
incorporate
the
best
practices
before
we
enable
these
things.
We're
actually
at
a
point
now.
I
think
we
can
actually
get
the
first
bootstrapping
point
into
self
hosting
properly
done
so
that
way
we
can
move
on
to
the
next
points.
We
already
have
the
ability
to
H
a
and
we
have
the
ability
to
upgrades,
but
again
these
things
are
interrelated.
So
what
exactly
is
self
hosting?
For
those
who
don't
know
about
it?
B
It's
basically
running
kubernetes
on
Corinne,
eighties,
or
you
can
think
of
it
like
a
turducken
right.
So
we're
only
running
it
in
one
particular
type
of
mode.
If
you
look
at
all
the
documentation
of
ways
to
do
self
hosting,
we
are
not
going
to
we're
only
going
to
run
the
control
plane,
we
are
going
to
run
HCD
in
self-hosted
mode.
There's
been
a
number
of
issues
that
have
existed
and
the
chorus
folks
who
tried
to
do
it
several
times
have
given
up
on
it.
We're
also
not
going
to
run
coublon
on
couplet.
B
That
gets
to
the
point
where
you
have
really
weird
behavior,
because
you
have
to
do
a
whole
bunch
of
extra
mounting
of
your
couplet
into
your
google
--it.
If
that
sounds
confusing
it's
because
it
is
it's
not
a
good
idea,
but
the
primary
reason
for
enabling
self-hosting
is
ease
of
upgrades
using
the
kubernetes
primitives.
The
whole
sort
of
sunset
horizon
future
is
that
you
want
to
use
all
the
same
tools
that
you
use
for
kubernetes
to
deploy
and
upgrade
kubernetes
right.
B
There's
also
a
desire
to
be
supportable.
If
you
start
doing
these
one-off
implementations,
you're
kind
of
alone
in
the
wilderness
right
and
we
don't
want
to
have
that
support
route
going
forwards
because
a
lot
of
times
that
becomes
technical
debt
or
a
burden
over
time,
there's
also
a
legacy
and
long
tail
of
untenable
supportive
configurations.
B
People
enable
things
and
then
you're
stuck
with
them
like
I
mentioned,
but
one
of
the
major
precursors
for
us
doing
some
of
these
enablement
slyke's,
such
as
self
hosting
some
of
the
control
plan
components,
is
that
we
really
want
component
configuration
and
version
semantics
around
the
arguments
for
the
individual
components
right.
That
is
a
key
feature
which
will
be
very
nice.
Hopefully
in
111
we
should
have
dynamic
Kubla
configuration
in
place
that
will
ease
a
ton
of
burdens
that
exist
currently
with
the
many
deployments.
B
So
what's
the
status
I'd
say
it's
still
alpha
with
a
single
node
environment.
You
can
set
up
multi-node
environment,
it's
actually
better
to
do
it.
That
way.
If
you
have
a
if
you
were
currently
using
cube
ATM,
because
you
have
less
chance
of
a
single
point
of
failure,
you
still
have
the
DC
outage
a
problem
with
the
current
version,
but
currently
we're
trying
to
rethink
the
problem
to
avoid
the
checkpoint
dilemma
right
and
try
to
prevent
us
from
having
to
constantly
think
about
these
things.
B
When
you're
coming
back
online,
there's
an
edge
case
that
you
have
to
deal
with,
which
is
basically,
you
need
a
single
point
or
bootstrapping
point
for
you
to
come
back
online.
So
one
of
the
things
we're
gonna
be
writing
up
this
cycle,
and
hopefully
get
reviewed
to
implement
next
cycle
is
a
kubernetes
enhancement
proposal
that
we
were
calling
I've
called
the
sentinel
or
Joe
has
referred
to
as
the
pilot
light
right.
B
So
how
does
it
work?
What's
the
idea
behind
the
pilot
light
cubm
deploys
a
single
static
manifests
called
the
kou
minium,
sentinel
or
pilot
light.
The
sentinel
checks
of
an
api
server
is
running.
Basically,
a
sentinel
file
on
the
machine
in
a
well-defined
location
like
bar
run
kubernetes.
If
it's
not
there,
it
deploys
a
static
manifest
within
its
local
/xe.
B
Manifest
location
waits
for
the
kulit
to
check
in.
What's
the
coop
of
check-ins
it'll
find
out
that
it
has
a
bound
pod
to
it.
That
bound
pod
will
then
be
spun
up,
and
the
spun
up
pod,
that
is
actually
a
self-hosted
container,
will
contain
a
sentinel
marker
that
will
drop
on
the
machine
and
then
the
original
sentinel
will
then
shut
down
the
API
server.
B
So
upgrades
again
upgrades
are
an
artifact
of
whether
or
not
you're,
using
cell
phone
sting
and
whether
or
not
you're
deploying
an
H
a
so
again
we're
trying
to
distill
the
best
practices
ensuring
that
we
only
rely
on
beta
features.
We
actually
got
bit
by
some
things
that
were
updated
to
be
a
component
config
in
the
1:10
cycle,
so
we
have
to
work
out
the
details
there,
the
the
Signet
working
folks,
but
last
but
not
least,
and
as
a
community,
we
can
always
benefit
from
this.
We
need
more
testing
and
testing
cycles.
B
I,
don't
know
if
any
of
you
have
ever
taken
a
dot,
zero
release
of
communities
and
said
yes,
this
is
the
best
thing
to
do,
install
this
right
away
on
my
prod
cluster
right,
but
if
that
you're
all
laughing
because
it
is
kind
of
funny.
But
the
idea
is
that
we
want
to
get
our
tests
better
right
and
we
are
building
out
it's
more
testing
infrastructure
and
making
it
better
over
time.
B
There's
a
conflation
of
a-qing
of
the
control
plane
and
hea
of
your
workloads.
People
always
conflate
those
ideas.
The
control
plan
can
completely
go
down
and
your
workloads
will
still
be
running.
You've
been
many
times
with
auto-scaling
groups
on
cloud
providers.
You
won't
even
notice
it.
The
machine
will
come
back
online
and
your
control
plane,
just
pretty
much
went
away
and
come
back
came
back
so
instead
spend
a
lot
more
time
focusing
on
your
workloads.
Those
are
the
things
that
are
important
to
your
business.
B
Those
are
the
things
that
really
matter
right
a
lot
of
times
unless
you're
in
a
high
churn
environment
where
your
workloads
are
coming
and
going
all
the
time.
Hha
adds
a
lot
more
complexity
than
it
does
solutions
that
it
provides
right.
So,
when
you're
checking
off
check
boxes
when
you're
talking
to
your
CIO
make
sure
you
check
out
the
our
workloads
are
highly
available
right.
B
You
can
also
provide
extra
learning
for
your
masters
and
understand
your
tolerance
for
failure.
What's
your
mean
time
to
recover
that
you
care
about?
What's
your
mean
time
to
failure?
What's
the
flux
rate
of
your
cluster,
how
your
workloads
are
coming
and
going
and
changing
so
what's
the
status
you
can
do
it
all
today
with
could
be
a
name
if
you
want
to
there's
documentation
for
it.
It's
not
the
easiest
thing
in
the
world,
but
it's
it's
doable
so
with
@cd,
there's
documentation
that
exists
to
deploy
your
cluster
and
NCD.
B
There
also
exists
upgrade
instructions
for
how
to
do
it,
we're
coming
up
with
better
documentation
in
111
to
basically
use
at
city
phases
or
aku
medium
phases,
because
there
exists
mackerel,
sort
of
behavior
inside
of
the
phases,
sub-command
active,
vector,
API
servers.
It
requires
just
a
minor
configuration
change
and
that's
all
documented
controller
and
scheduler.
The
only
thing
I'm
really
kind
of
want
people
to
think
about
over
time
and
we're
gonna
add
this
behavior.
B
These
are
the
most
common
standard
features
that
people
ask
for,
and
they
constantly
query
us
on,
but
there's
a
whole
bunch
of
other
planning
that
goes
into
this.
There's
planning
for
ingress,
there's
planning
for
egress.
We
constantly
get
asked
questions
about
air
gapped
environments
like
how
do
we
get
all
our
containers
working
in
this
environment
at
a
totally
air-gapped
way,
there's
also
load
balancers
and
that's
all
kinds
of
fun
stuff.
That
alexander
is
going
to
talk
to
you
about.
C
Well,
thanks
Tim,
so
hello,
everyone
I'm
Alexander
can
I
have
skin
I
wanted
to
talk
about
were
things
which
might
be
obvious
for
many
of
you,
but
looking
at
what
issues,
what
we
get
an
incubating
since
I
think
release
1.6
like
from
different
users
from
what
I
myself
stepped
on
I
wanted
to
cover
a
few
things.
Where
was
scenario
and
running
cube.
Idiom
is
not
wet
smooth
as
Luke
was
showing
in
his
screencast.
C
So
what's
the
problem?
The
world
is
not
video.
If
you
work
for
small
companies,
internet-
company,
you
might
have
good
internet
connection,
you
have
freedom,
what
you
to
use,
but
if
you're
an
enterprise
you
must
probably
have
a
rules
like
what
kind
of
Linux
distributions
you
are
using.
What
kind
of
network
policies
you
have
well,
in
the
worst
case
scenario,
you
you
are
located
in
the
country
which
decides
which
internet
resources
you
want
to
access.
So
let's
first
look
at
installation
upgrades,
so
you
saw
in
my
screencast
look
installed
couple
of
packages
on
Ubuntu.
C
C
The
thing
is
with
support
for
those
distributions
and
a
variety
of
distributions
is
white,
and
the
problem
starts
when
you
try
to
use
our
packages
from
our
distributions,
which
we
don't
support,
or
if
some
distributions
try
to
provide
my
own
versions
of
utilities
and
you
try
to
apply
the
cube
ADM
documentation
on
top
of
it,
you
get
into
problems.
So
my
small
how-to
in
wet
scenario,
is
what
don't
try
to
mix
select
one
thing.
So
if
you
follow
cubed
iam
documentation
use
the
common
Asian
and
use
web
packages
from
cube
atm.
C
If
you
select
your
render
distribution.
Well,
you
stuck
with
your
vendor,
but
in
reality,
what
those
packages
do?
It's
not
a
rocket
science.
We
bring
just
few
standard
binaries
to
a
system,
so
it's
cube
IDM
itself,
it's
cob
LED,
one
old
agent,
cube
CTL,
which
helps
you
to
communicate
with
api
server
and
few
standard
CNI
plugins,
which
we
need
well
plus
dependencies
like
two
standard
agilities,
like
IP
tables,
whatever
else
is
needed
on
your
system.
So
again,
it's
not
rocket
science.
C
The
thing
is
those
parameters,
most
probably
not
one
which
you
want
to
use
documentation,
says,
go
and
modify
this
view
by
DM
conf.
Probably
it's
not
a
good
idea.
My
recommendation
is
create
your
own
local
drop
in
for
system
d
and
you
can
easily
override
with
parameters
what
you
need
to
change.
What
it
will
allow
you
to
do.
You
will
see
when
the
parameters
on
upstream
on
our
side
will
be
changing,
and
you
will
always
know
what
you
have
changed
it
in
your
local
system.
C
So
next
thing
we're
calling
home.
So
we
we
get
set
of
box
which
says
like
ironically,
you
buddy
I'm
in
it,
and
it's
stuck
with
something.
So
we
have
several
places
where
QP
DM
accessing
the
network,
like
one
place,
is
resolved
in
version
files,
so
you
saw,
for
example,
in
Luke.
Screencast
is
Alec,
he
said
cube
area
minute
and
he
got
one
point
ten
point
two
like
well
latest
release.
What
happens
behind
with
scenes
is
what
QB
DM
go
to
download
repository,
read
a
special
file
and
resolves
it
like?
C
Ok,
user
wants
to
have
latest
version.
So
it's
one
point
and
point
to
ATO
moment
and
we
have
support
for
couple
of
such
labels,
so
you
can
be
like
stable,
latest
and
greatest
release.
You
have
stable.
One
means,
like
you
automatically
upgrade
one
nine
to
110
and
all
you
can
be
more
precise,
like
I
want
to
stay
on
one
nine
line.
The
same
thing
goes:
latest
label
latest
label
allows
you
to
get
all
the
better
versions:
release
candidate
versions
and
so
on.
C
So
next
thing
what
kubernetes
actually
tried
to
do
it
fetches
three
images
from
with
registry,
so
all
the
images
what
we
are
referencing.
It
comes
from
our
kubernetes
registry
on
google
to
first
images
so
infrastructure,
one
like
paws
and
etcd.
We
have
my
own
release
cycle.
So
if
you
want
to
do
like
really
offline
installation
of
your
cluster,
you
must
probably
want
to
do
yourself.
C
Few
steps
to
download
and
save
it
and
when
I
import
on
your
nodes
well
last
for
is
part
of
our
release
process.
So
if
you
go
to
download
really
download
server
for
each
release,
we
have
directory,
which
contains
all
the
binaries
all
with
docker
images.
So
you
can
get
them
and
when
reuse
it.
Obviously,
it's
not
browsable
directory
browsable
in
the
browser,
but
to
get
the
list
of
files.
What
is
where
you
can
use
where
Google
utilities
to
actually
get
the
content
and
when
play
yourself,
try
to
find
what?
C
C
If
you're
lucky
you
get
a
proxy
which
you
can
get
to
access
to
internal
external
world,
but
this
proxy,
most
probably
doesn't
have
access
back
to
your
LAN
segment,
and
this
is
where,
like
most
of
the
confusions
for
people
peirong,
so
you
need
to
configure
with
setup
like
to
explain
to
cube
ATM
and
components
where
to
go.
If
you
want
to
access
different
network
resources.
First
part
is
your
container
runtime
interfaces.
It
needs
to
be
able
to
fetch
free
images
from
outside
world.
You
need
to
HTTP
proxy
from
your
local
registries.
C
So
many
of
the
things
what
I
said
here
we
can
be
detected
by
pre-flight
checks
and
what
we
observe
would
many
times
in
web
block.
Reports
is
what
the
people
eyes
disabled
with
checks
or
ignore
warnings
or
well
skipped
in
previous
versions.
So
one
message
which
I
wanted
to
say:
don't
ignore
way,
which
checks
if
I
have
something
most
probably
it
will
lead
to
a
problems,
and
if
you
see
what
checks
misbehave,
please
come
back
to
us
open
the
issue.
We
will
look
how
to
how
to
solve
it.
So
thank
you.
D
C
Yes,
well
a
bit
long.
The
answer
so
specifically
for
etcd
check
if
I
remember
correctly
how
it's
currently
implemented
it
able
to
detect
what
it's
external,
so
it
will
go,
try
to
connect
to
it.
It
will
check
what
it's
appropriate
version
and
if
it's
red,
it
will
just
say
nothing
if
it
will
be
something
not
satisfied,
it
will
produce
warning
and
yes
for
starting
from
I
think
1/9
release.
We
have
ability
to
actually
finder
in
control
over
check
our
pre-flight
checks.
C
So
if
we
check
is
producing
error,
you
can
say
ignore
pre-flight
check
errors
and
when
you
put
a
check
ID
like
comma
separated
list,
so
you
can
do
multiple
of
files.
So
what
that
means
it
will
like.
We
check
will
still
be
running
where
a
check
will
produce
warming.
So
you
will
see
what
something
is
still
not
what
we
expected.
E
C
C
Well,
local
artifacts.
You
need
to
have
all
the
images
in
wet,
sweat,
sweat
park.
So
another
thing
which
I
mentioned
this
resolving
of
cube,
kubernetes
version
and
argument.
So
the
hint
here
is
what
default
it
has
a
label
and
it
tries
to
resolve
it.
But
if
you
specify
it
explicitly
saying
I
want
version
110,
it
will
not
go
anywhere.
It
will
just
use
wet
version.
C
B
That's
a
good
queen
talking
about
how
to
make
it
easier
for
people
so
there's
already
a
pre
pull
images
command.
So
that's
part
of
it.
I
think
we
could
probably
make
it
even
easier.
So
if
you
have
ideas,
please
open
an
issue
right
so
and
we
gladly
we've
been
pretty
aggressive
in
the
111
cycle
about
triaging
issues
and.
G
B
So
we
don't
natively,
run
containerized
versions,
because
then
it
becomes
a
little
bit
weird
with
home
propagation.
So
we've
other
people
do
that,
but
we
the
the
easiest
way
to
give
the
couplets
the
whole
system
host
and
properly
use
the
you
know,
systems
DS,
C
group,
namespace
hierarchy
is
to
make
it
a
system
to
unify.
B
Otherwise
you
have
to
do
a
bunch
of
extra
special
tricks
to
make
that
all
clean
and
proper
the
there
people
have
asked
about
it,
but
it's
not
been
the
highest
priority
thing
for
us
to
do,
because
the
current
implementation
usually
works
for
most
folks.
I
do
know
that
other
people
do
this
like
it's
done
inside
of
coop
spray,
but
coop
spray
comes
with
its
own
complexities
and
other
problems
that
comes
along
with
it
too.
So
a.