►
From YouTube: kubeadm office hours 2020-10-14
A
A
A
As
you
may
know,
there
is
a
new
working
group
in
kubernetes
called
working
group,
naming
that
recently
had
a
meeting
and
just
in
santa
barbara
joined
this
meeting
and
asked
the
question
hey.
Are
you
sure
that,
like
master
to
control
plane
is
the
actual
rename
we
are
looking
for?
And
everybody
said
yes,
but
basically
justin
is
looking
for
something.
That
is
a
more
like
an
official
statement
on
this
topic.
A
A
The
second
psa
is
that
the
insecure
serving
of
the
core
components,
the
control
plate,
components
such
as
cube
api
server,
cube
scheduler
and
a
cube
controller
manager
are
being
removed
as
a
functionality.
Basically,
these
components
have
a
particular
flag.
That
is
a
difference
between
the
components,
but
it
can
be
dash
dashboard
or
dash
dash
in
secure
port.
A
A
The
insecure
port
functionality
itself
was
deprecated
for
a
very
long
time,
and
120
appears
to
be
the
release.
When
we
are
going
to
remove
the
functionality,
the
flags
themselves
are
planned
to
remain
dormant
or
no
operation,
basically
for
a
few
more
releases
so
that
they
don't
break
user
infrastructure
immediately.
A
A
A
They
are
in
a
way
correct,
because
minor
cubelet
upgrades
minor
release,
couplet
upgrades
require
that
you
normally
evict
all
the
pots
from
this
node,
because
the
idea
is
to
restart
the
couplet,
and
the
cubelet
basically
requires
that
nothing
is
running
on
the
node,
except
for
maybe
static
ports,
and
this
is
in
the
the
documentation
of
somewhere.
In
the
couple
docks
now,
I
should
try
to
somehow
open
the
my
response.
It's
like
anyway.
A
A
Ideally,
we
would
want
this
particular
nodes
to
enter
enter
maintenance
mode,
which
is
you
know,
drain
and
cordon
is
what
they
are
doing,
but
if
we
don't
do
that
around
the
static
port,
manifest
is
if
this
nodes
fails
completely
and
if
the
node
is
scrapped.
For
some
reason,
if
the
load
is
completely
removed,
this
means
the
coordinates
or
other
critical
parts
will
be
stuck
or
on
the
node
for
the
timeouts
that
is
defined
somewhere
in
the
scheduler,
which
is
five
minutes
by
default.
A
A
So
I
think
a
compromise
here
is
to
go
with
the
suggestion.
With
the
user,
the
user
is
giving
which
is
basically
drain
and
concordant
only
around
the
corporate
upgrade
like
we
are
doing
for
the
worker
nodes,
but
instruct
the
users
that
in
case
they
see
a
problem
with
critical
ports
such
as
coordinates.
C
A
Yeah,
it's
a
bit
of
a.
How
do
I
say
it's
a
bit
of
a
stretch,
this
problem,
if
you,
if
you
drain
around
the
static
pot,
upgrade
you
don't
gain
anything
because
the
static
pots
upgrades
you
don't
have
to
drain
right,
but
if
the
static
port
upgrade
fails
and
the
user
cannot
recover
from
the
backup
for
some
reason,
then
critical
ports
can
be
stuck
on
this
note
and
the
user
might
decide
to
scrub.
The
note
like
I
explained
and
then
the
like
critical
services
can
be
lost
for
a
period
of
time.
C
C
C
B
A
B
B
B
Yes,
but
I
was
thinking
in
terms
of
the
actual
update
of
cubelet
on
the
worker
node
there's
a
transition
point
of
obviously,
when
you
install
the
new
instance
of
the
new
version
of
the
cubelet
and
the
old
one,
the
old
version
of
a
cubelet
has
to
die,
and
at
that
point
we
run
risk
of
losing
a
pod
that
might
be
executing.
Am
I
correct
there?
If
we
do
this
live.
A
A
A
Yeah,
the
corporate.
We
assume
that
the
couplers
will
continue
to
run
and
manage
these
critical
parts,
but
imagine
that
you
have
high
level
infrastructure
that
is
watching
for
the
health
of
the
control
plane
node
in
general,
like
if
you
see
that
the
node
is
failing,
but
not
not
the
couplet
side.
Of
the
note.
The
api
server
bot,
for
instance,
is
not
running
there.
C
C
A
C
B
B
A
A
A
B
A
A
A
B
Right
now,
there's
a
request
out
for
information.
There
is
no
decision
at
this
point
on
any
action.
They
were
just
simply
trying
to
identify
what
sort
of
croft
has
been
generally
generated
through
the
successive
updates
of
kubernetes
and
what
metadata
has
been
obsoleted
trying
to
identify
if
anyone's
still
using
the
obsoleted
metadata.
A
A
D
Yeah,
I
think
I've
I've
got
I've,
seen
a
concrete
example
with
the
beta
os
label,
right
so
say,
for
example,
someone's
installing
an
older
version
of
calico,
so
cni
that
targets
the
beta
annotations
and
then
they're
no
longer
existent,
then
that
cni
has
broken,
and
I
think
that's
more
in
scope
for
the
cluster
add-ons
operator
rather
than
cube
adm,
so
it
so
those
kind
of
like
dynamic,
pods
or
dynamics.
Core
services
are
very
much
in
scope
for
the
cluster
add-ons
project
at
which
kubernetes
may
eventually
consume.
B
A
It's
under
storage
sink
yeah.
I
haven't
seen
these
efforts,
but
like
basically
anytime,
you
create
something
that
is
alpha
and
it's
changing
and
things
like
that
if
people
start
actively
consuming
it,
especially
in
product
and
and
you
break
them,
nobody
is
going
to
be
happy
and
what
we
try
to
do
in
kubernetes
and
projects
like
cube
idm
is
try
to
make
the
transition
as
smaller
as
possible,
but
sometimes
it's
a
bit
difficult.
So.
A
A
So
I
haven't
had
seen
such
a
use
case
before
and
also
the
user
said,
I'm
using
bgp.
I
don't
know
how
to
pronounce
this.
You
and
I
know
the
standard,
but
they
have
big
gaps
in
the
standard.
So
basically
the
user
is
trying
a
very
weird
case
to
connect
the
worker
node
to
the
cursor
and
what
they're
seeing
is
that
our
code
for
it
from
borrowed
from
api
machinery
that
detects
a
particular
ip
from
gets
a
ip
from
an
interface
and
says?
Okay,
I
saw
that
you
have
this
ip.
A
A
We
apply
dynamic,
defaults
to
a
advertised
address.
That
is
not
needed
on
worker
modes
and
this
is
where
it
fails.
Basically,
this
is
the
logic
that
tries
to
default
dynamically
default,
the
api
server
other
than
advertise
others
on
worker
modes-
and
I,
like
I
said
to
this-
I
I
don't
think
we
should
be
fetching
the
init
configuration
at
all
on
worker
nodes.
A
A
D
A
B
A
Cubedium
any
command
like
joining
it,
we
sorry
join.
In
particular,
we
always
fetch
the
init
configuration
from
the
cluster
construct.
A
an
init
configuration
object
that
also
stores
the
acoustic
configuration
object
and
all
the
component
conflicts
in
there,
like
the
discussion
from
last
time,
was
that
we
shouldn't
fetch
component
config.
Sorry,
the
q
proxy
component
config
and
store
it
in
this
like
ephemeral.
Indeed,
configuration.
A
And
I
think
for
workers
in
particular,
we
are
calling
this
init
config
function
during
freak
preflight,
which
results
in
the
fetch.
I
think
we
should
probably
add
a
flag
somehow
here
that
if
this
is
like,
we
should
skip
this
during
non-control
plane
joint
pretty
much.
I
think
this
is
what
we
should
do.
C
A
C
Yeah,
I'm
not
sure
I
can
follow.
I
think
that
we
are
talking
about
two
problems
and
my
gut
feeling
is
that
we
have
to
solve
them
separately,
so
one
is
to
fix
the
other
solution
and
the
other
one
is
to
avoid
to
read
what
is
not
necessary
when
joining
a
node,
but
they
are
to
separate
program.
In
my
opinion,.
A
A
D
Yeah,
because
what
I
think's
happening
is
client
go
is
trying
to
select
an
outbound
interface
to
reach
the
api
server
and
it's
trying
to
filter
the
interfaces
on
the
available
things.
So
even
if
we
pass
cube,
adm
cubelet's
gonna
fail.
I
think
at
some
point
anyway.
So
I
think
this
is
really
about
ipv6
support.
D
Yeah,
I
think
it's
gonna
fail,
because
the
machine
doesn't
have
basically
we're
doing
a
check
that
is
either
a
valid
like
private,
ipv,
private
or
public
ip
address,
or
it
has
to
be
linked
global
ipv6,
but
the
machine
doesn't
have
any
only
has
the
link
local
address,
which
is
okay.
If
it's
on
the
same
subnet,
we
should
allow
that
connection.
D
D
Because
I
don't
think
that
we-
I
don't
think
so.
I
think
we
should
not
be
downloading
the
init
configuration,
but
I
think
they're
this
we're
only
seeing
that
it
is
a
problem
because
client
go
is
failing
so
or
api
machinery
is
failing.
So
this
is
really
api.
Machinery
fix
to
support
this
type
of
networking
and
independently.
We
probably
shouldn't
be
downloading
unit
config,
so
we
can
make
it
password
up.
It's
just
going
to
fail
at
the
next
step.
I
think
at
the
next
connection
to
the
api
server.
A
A
D
A
D
E
Yeah,
I
I
just
agree
exactly:
this
is
the
problem
not
ours.
It
has
to
handle
from
top
down,
and
the
api
server
should
handle
that
so
an
issue
against
api
server
to
ensure
that
ip
forwarding
is
taken
care
of
routing
is
taken
care.
Whichever
way
they
do,
it
is
there
to
take
care
of
not
us.
We
should
not
change
anything
here.
I
agree
well.
A
Cuba
dm
is
fairly
convalidation
step.
This
is
what
the
user
is
seeing.
The
validation
step
is
performed
by
code,
that
is
in
api
machinery,
but
I'm
talking
about
for
api
machine
has
a
library
here.
Api
machinery
is
a
library,
it's
not
the
api
server
that
is
failing.
We
are
just
consuming
some
functions
to
perform
the
validation,
sorry
that
to
check
the
what
ip
others
use.
E
D
The
service
we're
not
talking
so
api
machinery,
we're
not
talking
about
anything
that
cuba
dm
is
doing
around
setup
of
a
cluster.
This
is
a
client.
This
is
the
client
code
of
kubernetes
itself.
It
doesn't
support
this
networking
environment.
So
we
need
to
change
that
low-level
client
library,
which
is
used
in
everything
in
lots
of
places
so
used
in
kubelex
using
cube
adm,
it's
using
cluster
api.
All
of
these
things
won't
work
in
this
environment.
D
So
we
need
to
change
that
underlying
library,
which
is
api
machinery,
and
then
everything
will
start
working,
but
this
is
also
highlights
that
we're
doing
something
we
don't
need
to
do
in
cube
adm,
which
is
we
don't
need
to
download
the
init
configuration,
so
it
would
have
failed
anyway.
The
kubelet
would
have
broke
at
some
point,
but
it's
also
highlighted
that
we're
doing
doing
something
stupid.
We
can
clean
that
code
up
and
separately.
We
need
to
deal
with
this
api
machinery
issue.
C
Okay-
and
there
is
all
this,
this
code
should
not
fail,
but
it
is
acceptable
that
the
logic
basically
does
not
resolve
to
anything
and
because
we
we
say
over
time,
we
are
adding
some
more
knowledge
to
the
to
this
piece
of
code
and
we
are
becoming
able
to
detect
in
new
different
type
of
networks
configuration,
but
there
will
be
some
always
a
network
configuration
that
we
cannot
detect,
and
so
in
that
case,
kubernetes
should
aggressively
aggressively
tell
to
the
user.
Sorry,
my
my
internal
logic
for
detecting
the
ip
address
speed.
C
C
First
thing
that
I
will
look
is
that
why
it
is
fading
with
by
throwing
an
exception.
At
least
this
was
the
impression
that
I
got
second,
I
will
look.
Are
we
able
to
so?
I
I
think
that
returning
to
the
user,
unable
to
select
the
ap
is
something
that
is.
It
is
acceptable.
That
means
that
our
logic
simply
does
not
handle
this
type
of
networking.
C
A
Yeah
sure,
but
even
if
they
provide
this
address,
explicitly
it's
going
to
be
applied
to
the
like
the
api
server
for
on
a
worker.
Note
that
doesn't
exist
like
the
api
server
doesn't
exist
on
work
or
not.
This
is
what
we
are
seeing
here.
So
in
any
case,
let's
move
to
the
next
topic.
Just
for
britain,
if
you
want
to
just
comment
on
the
ticket
as
well,
I
I
would
like
to
see
us
to
stop
fetching
the
q
proxy
configuration
and
the
init
configuration
from
the
coaster
for
work.
C
C
A
A
A
I
really
don't
want
to
create
a
mess
if
we
have
yet
another
repository.
If
we
have
the
cubanium
library
repository,
this
means
that
we
have
to
version
it
independently.
Then
kubernetes,
maybe
one
day
is
going
to
be
in
k,
slash
kbm.
It
has
to
consume
this
library.
This
sounds
great,
but
we
are
doing
it
before
cube.
Adm
is
moved
out
and
before
we
have
decided
whether
cube
adm
is
going
to
follow,
kkk
cadence
or
not
follow
the
kkk
cadence
seek
architecture
are
currently
saying
you
should
not
follow
the
kkk
cannons.
A
A
E
A
C
A
A
C
Shash
to
to
be
honest,
it
is
something
doable
given
that
our
main
target
is
cluster.
Our
initial
target
is
cluster
api
and
we
control
what
it
happens
in
in
cluster
api,
or
there
is
a
good
collaboration
between
the
two
teams
and
but
to
be
honest,
I
I
like
having
release
release
notes
and
so
it
starts.
C
C
C
A
A
D
A
A
A
A
We
have
the
main
cubadiem
process,
and
now
we
expose
the
same
thing
as
the
library
like
we
are
breaking
this
project
into
so
many
fractions
that
I
don't
see
how
how
easy
for
us
is
going
to
be
made
to
make
changes
in
the
future,
like
everything
is
going
to
break
because
everything
is
exposed
yeah.
It's
a
interesting
discussion.
A
C
A
Yeah
I
was
there
yesterday,
but
I
was
preparing
the
slides
for
kubecon,
so
I
couldn't-
or
rather
I
forgot
about
this
topic
so
yeah
like
like
if
I
have
to
provide
a
public
statement
on
this
topic,
I
like
the
program,
progress
idea,
but
I
see
that
everybody
is
doing
their
own
thing,
like
the
questions
project
is
doing
something.
Some
companies
like
red
hats,
have
solutions.
A
Google
still
use
the
legacy
other
manager,
everybody
has
a
different
solution
for
the
add-on
management
problem,
and
if
we
enable
this
plug-in
binary
idea,
we
are
essentially
just
adding
yet
another
solution,
even
if
I
think
it's
like
one
of
the
better
ones.
There
are
some
cavities
around
like
how
do
you
manage
plugins
on
on
notes
that
don't
need
the
plugin
binaries?