►
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
Intro: Cloud Provider SIG - Chris Hoge, OpenStack Foundation & Steve Wong, VMware
SIG Cloud Provider is focused on ensuring a consistent and high-quality user experience across providers and acts as a central group for developing the Kubernetes project in a way that ensures all providers share common privileges and responsibilities. New vendors providing support for Kubernetes should feel equally empowered to do so as any of today's existing cloud providers. We will go over historical context, status, and direction of efforts currently underway including the transition of individual provider SIGs to sub-projects and ongoing work in extracting provider code from the main Kubernetes repository.
https://sched.co/NrrN
A
B
A
Steve
Wong
I'm
I'm,
not
an
official,
an
official
leadership
position
of
say
cloud
provider,
but
I
do
work
in
cig
VMware
that
does
the
cloud
provider
for
running
kubernetes
on
top
of
VMware
infrastructure.
I
work
for
VMware
I've
been
active
in
kubernetes
dating
back
to
2015,
but
back
in
that
era
it
was
I
was
mostly
active
in
storage
and
I'm,
also
active
in
the
IOT
in
the.
D
D
A
The
cloud
provider
started
and
it
turns
out
that
the
cloud
provider
started
one
way,
but
it's
moving
in
a
slightly
different
direction
and
we're
going
to
tell
you
why
it's
changing
and
how
it's
changing,
and
by
we're
gonna
close
with
a
description
of
how
this
SIG
cloud
provider
say
actually
works.
Just
in
case
you
want
to
get
involved
with
the
activity.
A
Word
learn
even
if
you're
not
actively
involved
how
you
can
go,
find
the
historical
record
of
the
agenda
that
how
decisions
got
made
and
made
me
look
at
some
YouTube
videos,
because
sometimes
that
kind
of
context
can
help
you
understand.
What's
going
on
so
the
mission
of
sake
cloud
provider
is
to
manage
to
allow
kubernetes
to
run
in
a
way
that's
neutral
to
all
public
and
private
cloud
providers.
You
know
public
cloud
browsers.
A
The
origin
story
for
cloud
providers
are,
and
still
the
case
as
of
1:14.
Then
all
of
these
abstraction
layers
for
eight
very
popular
things
to
host
kubernetes
on
are
like
integrated
into
the
very
fabric
of
kubernetes
itself,
seemed
like
a
good
idea
when
kubernetes
was
getting
started
to
make
it
convenient
to
where
you
could
just
deploy
it
and
it
just
works,
but
just
like
they
say
in
kubernetes,
being
a
host
of
Micra
services.
Monolithic
isn't
always
good
and
bundling
in
these
things
by
default
had
some
issues.
What
were
the
issues?
Well,
you
know
really.
A
Kubernetes
should
be
an
orchestration
layer
managing
only
the
standardized
parts,
not
the
thorny
aspects
of
unique
that
are
unique
to
any
pop,
any
particular
deployment
pattern.
People
also
came
to
the
conclusion
that
inclusion
of
these
things
could
constitute
an
endorsement
of
a
particular
platform
to
Burnett.
The
kubernetes
project
doesn't
want
to
be
a
kingmaker
coming
up
with
the
specific
list
of
what's
authorized
and
not
the
other
issues
are
that
by
bundling
in
this
code
it
became
very
tightly
coupled
so
suppose.
A
Let's
take
an
instance
where
there's
a
bug
that
affects
one
particular
cloud
provider,
just
in
the
interest
of
fairness,
I'll
hypothetically
suggest
it's,
the
company
I
work
for
there's
a
bug
in
the
VMware
implementation
security
issue,
and
we
need
to
get
it
patched
right
away.
Well,
if
that
code
is
in
tree,
we
have
to
cut
a
full
kubernetes
release,
pass
all
the
tests
to
get
out
out
there,
and
that
slows
the
release
time.
You
really
don't
want
that
to
happen.
A
You'd,
look
unless
there's
a
really
good
reason
too
tightly
couple
it
like
now,
there's
a
lot
of
value
and
not
having
coupled
release
cycles.
It
also
allows
independent
releases
to
these.
If
one
particular
cloud
provider
came
out
with
some
fancy
feature
because
they
changed
something
in
a
particular
public
cloud
might
give
them
the
option
to
enable
that
without
waiting
for
a
kubernetes
release
cycle.
So
there
is
both
problems
and
opportunities
that
can
be
solved
by
taking
cloud
providers
out
of
tree.
B
You
know-
and
this
includes
both
the
providers
who
are
in
tree
and
the
providers
who
are
out
of
tree
to
start
on
that,
and
so
there
there
are
two
major
things
that
we
have
to
do.
The
first
is
that
you
to
make
a
way
to
have
all
the
cloud
providers
in
the
out
of
tree
and
then
once
you
have
accomplished
that
and
set
that
stage,
then
you
can
start
taking
out
the
cloud
providers
out
of
tree
and
then
everybody
has
their
own
provider.
B
So
we
started
by
for
all
the
supported
entry
providers,
the
provider
code
has
been
officially
deprecated
and
their
dependencies
are
being
moved
to
staging
and
Walter
has
been
one
of
the
key
people
who
have
been
working
on
this
effort.
You
know
and
really
driving
it
forward,
because
he
has
such
a
strong
expertise
and
the
kubernetes
code
base
and
how
to
disentangle
all
of
those
tightly
coupled
resources
into
what
we
call
the
kubernetes
staging
staging
directory.
B
What
would
you
call
that
yeah
staging
subdirectory
that
where
we
can
say
that
these
are
api's
that
external
that
providers
depend
upon
and
they
won't
change
with
the
entry
providers
moved
to
staging
after
the
upcoming
release,
they
will
have
a
path
to
room
removed
in
the
following
release.
So
our
goal
is
that
by
the
end
of
2019,
there's
going
to
be
no
entry
provider
code.
All
of
that
will
be
gone,
and
so,
if
you
are
running
a
cloud
provider
and
you
you
have
tree-
you
have
code,
that's
entry.
B
I
think
OpenStack
is
a
good
example
of
this,
because
you're
more
likely
to
be
running
your
own
OpenStack
code,
you
should
be
thinking
about
migrating
from
using
what
ships
with
kubernetes
to
what
to
what
ships
from
you
know
the
individual
provider
and
then
finally,
any
unmaintained
provider
code
is
going
to
be
removed
entirely,
and
so
we
just
could
really
just
had
this
next
release.
A
few
last
week,
I
guess,
and
then
we
should
be
removing
that
code
in
during
this
release,
cycle
right,
yeah,
I,
think
the
dead
code
is
gonna,
be
moving
out.
B
I
think
you
went,
UPS
I
went
back
okay,
so
for
the
out
of
tree
providers,
we
want
to
introduce
the
cloud
controller
manager,
so
the
cloud
controller
manager
replaces
the
cube
controller
manager
and
is
a
daemon
that
embeds
the
following
cloud:
specific
controllers,
the
node
controller,
the
router
controller
and
the
service
controller.
Now,
if
you're
familiar
with
the
kubernetes
code
base,
you
might
be
thinking.
Where
does?
Where
does
my
volume
controller
go
and
they
kind
of
help
explain
that
I'll.
A
If
you
counted
the
Flex
drivers
and
they
were
tightly
coupled
and
on
the
same
release
cycle
as
kubernetes,
more
and
more
storage
solutions
were
coming
to
the
to
try
to
jump
in
the
pool
and
it
just
became
probably
even
more
unmanageable
than
it
was
with
cloud
providers
once
it
got
up
to
30,
some
any
one
of
which
could
have
bugs
holding
up
a
release
and
because
of
this
kubernetes
moved
to
an
architecture
called
the
container
storage
interface.
Now,
unlike
the
cloud
provider,
the
container
storage
interface
is
cross
container
Orchestrator.
A
So
this
is
an
industry
standard
that
supports
not
just
kubernetes
but
Apache
mezzos,
Cloud,
Foundry,
docker
and
potentially
other
orchestrators.
So
it
starts
with
a
vendor
doing
an
implementation
of
a
CSI
plug-in
and
then
kubernetes
has
a
new
interface
to
use
the
external
storage
plugin.
Now
it
turns
out
that
this
is
coupled
to
the
external
cloud
provider,
because
I
believe
it's
fair
to
say
that
every
person
doing
a
maintaining
a
cloud
provider
elected
that
when
we
transition
out
of
tree
from
the
cloud
provider.
We
don't
want
to
engage
in
this.
A
We
test
matrix
of
testing
external
cloud
provider
with
internal
storage
and
again
with
external
storage
and
ending
up
with
this
grid
of
things
that
you
have
to
support.
So
a
decision
got
made
by
everybody.
I,
don't
know
if
there
ever
was
an
official
statement
for
practically
speaking.
If
you
go
to
an
external
cloud
provider,
you're
going
to
have
to
go
to
external,
an
external
CSI
based
storage
plug-in
as
well
and.
B
A
B
But,
but
it
is
worth
mentioning,
though,
that
if
you
are
looking
for
a
CSI
driver-
and
you
will
there's
a
good
chance
that
you
will
find
it
with
the
cloud
provider
code
for
for
a
particular
vendor,
so
keep
that
in
mind.
What,
if
you
you
know
when
you're
thinking
about
the
you
know,
the
storage
controllers
that
they
often
wind
up
in
the
same
place,
yeah.
C
Especially
if
the
CSI
driver
is
specific
to
the
cloud
provider,
so
CSI
gets
interesting
because
there
are
two
flavors.
There
are
going
to
be
things
like
Amazon's,
EBS,
CSI
driver
and
then
something
like
you
know,
a
just
a
local
file
system
driver
which
is
also
CSI,
and
so
those
will
be
found
in
different
places
and.
A
For
the
one
where
you're
gonna
land
in
an
on-prem
scenario,
typically
the
if
you're
running
on
a
hypervisor,
it
will
have
a
bundled
CSI
but
you're
really
free
to
use
a
bunch
of
others,
potentially
two
that
have
nothing
to
do
with
that
hypervisor.
So
it
is
entirely
possible
to
use
many
CSI
plugins
at
the
same
time,
and
there
are
perhaps
use
cases
where
it's
a
smart
thing
to
do
right
right.
A
B
Okay,
so
we're
gonna
spend
a
little
bit
more
of
this
talk
discussing
the
nuts
and
bolts
of
how
you
build
your
own
cloud
provider,
because
because
because
this
is
you
know,
this
is
important
if
you're
providing
a
cloud
service
or
you
want
to
be
involved
in
the
development
of
someone
else's
cloud
provider.
You
know
it's
it's
important
to
understand
this
process,
so
the
first
step
is,
you
need
to
write
a
package
that
will
satisfy
the
cloud
provider
interface.
B
The
next
step
is
to
create
a
copy
of
the
cloud
controller
manager,
main
go
and
import
your
package
and
so
you're
taking
the
package
that
implements
the
interface
and
you're
wrapping
it
inside
of
an
executable
that
is
common
amongst
all
the
cloud
providers
and
initializes.
You
know
it
has
an
init
block
that
loads
your
provider
code
and
then,
finally,
you
go
through
the
work
of
publishing,
which
means
building
testing.
You
know
you
know,
building
it
testing
the
your
code
works
both
through.
B
B
And
so,
if
you
have
a
cloud
that
spans
multiple
zones,
you
know
this
gives
you
a
way
to
handle
clusters
that
are
spread
across
those
zones,
as
well
as
cluster
specific
clusters,
which
is
cloud
specific
information
about
the
running
clusters.
So
if
you
have
multiple
clusters
running
and
finally
routes
and
so
cloud
specific
cloud,
specific
information
about
networking,
yeah.
B
D
B
B
It's
configured
with
a
standard
set
of
options,
and
these
can
be
extended
to
match
the
requirements
of
your
cloud
and
a
starting
template
is
provided
by
the
kubernetes
cloud
controller
manager
directory.
We
have
a
link
to
that
right
there
and
on
the
next
slide,
we
also
have
just
you
know
again.
This
is
we've
cut
a
little
bit
of
the
code
out
because
there's
there
a
lot
of
comments
there,
but
this
is
basically
the
gist
of
everything
that
you
need
to
be
able
to
create
your
binary.
B
So
you
bring
in
a
number
of
imports,
include
you
know,
including
your
cloud
provider
as
well
as
some
optional.
You
know
the
Prometheus
plain
gold,
plugins
and
four
metric
registration,
and
you
basically
have
a
in
an
initializer
log,
so
you
sent
your
Cloud
Controller
manager,
commands
initialize
the
logs
and
then
execute
the
command
and
all
of
your
command
line.
Options
are
kind
of
hold
in
and
so
that
beforehand
in
the
Cloud
Controller
manager
app.
B
B
So
so
both
have
to
be
implemented
and
you
need
to
run
the
end-to-end
testing
and
these
have
to
be
reported
to
test
grid.
If
you've
done
this-
and
you
can
demonstrate
that
you
that
your
that
your
particular
cloud
has
as
implemented
these
tests
and
also
has
a
critical
mass
of
users,
then
your
cloud
can
become
a
these
tests
will
become
gating
for
the
kubernetes
release
and.
A
Which
is
yes,
and
the
key
is,
even
though
they
they're
moved
out
of
trees.
So
they're,
not
part
of
kubernetes,
it's
possible
that
somebody
made
a
change
to
kubernetes
itself
that
broken
when
running
on
your
cloud.
Even
if
your
cloud
provider
is
fully
compliant
and
passes
all
your
tests-
and
we
want
to
know
about
that.
B
Okay,
so,
finally,
once
you
built
your
cloud
provider,
then
you
want
to
run
it
and
so
to
accomplish
this.
There
are
a
few
things
that
you
have
to
do
when
you
start
your
cube,
API
server,
where
previously
you
would
say
cloud
provider
and
the
name
of
your
cloud
provider.
Instead,
you
specify
cloud
provider
external
and
then,
when
you
start
start
your
CCM
binary,
you
set
the
cloud
provider
flag
to
be
the
name
of
your
cloud
provider
and
the
and
then
the
cloud
config
flag
to
the
plat
to
the
path
of
your
cloud
configuration
now.
C
B
Ok,
so
when
you're
running
in
production
use
a
daemon
set,
this
is
why
they
were
made,
and
your
cluster
will
behavioral
change
in
a
few
ways,
notably
specifying
cloud
exciter
cloud
provider.
External,
will
add
a
taint
to
note
cloud
provider,
kubernetes
dot,
IO
uninitialized.
The
effect
of
this
will
be
that
there
will
be
a
no
schedule
during
initialization,
and
so
you
some
changes
is
that
that
you
actually
can't
do
work
on
the
cloud
until
your
cloud
provider
is
up.
So
you
set
the
taint
to
make
sure
that
you
give
it.
B
You
give
the
cloud
provider
time
to
initialize
cloud
information
about
the
nodes
in
the
cluster
will
no
longer
be
retrieved
using
a
local
using
local
metadata,
but
instead
all
API
calls
to
retrieve
node
information
will
go
through
a
cloud
controller
manager.
This
means
that
for
larger
clusters,
you
may
want
to
consider
if
your
cloud
controller
manager
will.
B
D
B
Is
something
that
you'll
want
to
think
about,
because
there
have
been
reports
of
cloud
providers
who
kubernetes
hits
the
rate-limiting
on
the
on
the
on
the
cloud
and
you'll
want
to
adjust
those
limits
appropriately?
If
you
know
that
you're
going
to
be
running
kubernetes
inside
of
your
cloud
with
that
integration
in
place.
B
That
you
set
a
toleration
also
so
that
the
CCM
can
bootstrap
itself,
so
so
that,
once
you
load
the
cloud
provider,
you
want
to
be
able
to
load
that
you
know
if
you're
running
it
as
a
daemon
set,
that
you
load
it,
that
that
you
ignore
the
taint
so
that
it
can
be
scheduled
and
it
can
be
brought
up
and
that
process
can
be
started.
And
so
this
is
also
another
important
aspect
of
when
you
decide
to
run
it
as
a
daemon
set.
B
A
B
So
so,
if
you
want
to
join
the
cloud
provider
sig,
we
have
a
slack
Channel
sig
cloud
provider
and
all
the
cloud
providers
themselves
also
have
their
have
their
own
slack
channels,
so
you
can
communicate
with
them.
The
Google
Group
is
a
community
sig
cloud
provider.
It's
a
fairly
low
volume
mailing
list,
but
important
communication
does
happen
on
that
and.
A
You
do
you
should
grow
in
join
the
group,
because
a
lot
of
the
documents
have
access
gated
to
members
only
and
so
there's
no
particular
qualifications
other
than
providing
an
email.
But
once
you
join
the
group,
it
will
end
these
situations
where
you'll
see
a
doc
list
length,
try
to
open
it
and
you'll
get
permission
denied.
So
the.
B
I'm
one
of
the
chairs
of
the
sig,
along
with
Jago
McLeod
and
Andrew
psych
him,
but
really
one
of
the
great
things
about
sig
cloud
provider
is
there's
a
tremendous
amount
of
work.
That's
going
on
and
you
know,
and
you
know,
even
though
there
are
like
the
sig
chairs
the
the
when
you
show
up
and
you
do
work
within
the
within
the
sig,
you
know
it.
Can
you
know
it's?
Actually,
you
are
seen
as
a
leader
within
the
sig
and
you
know
and
there's
a.
B
Amount
of
work
that
that
can
be
done,
particularly
in
finalizing
the
extraction
process
and
then
coming
up
with
these
commonalities
that
we're
going
to
be
sharing
across
the
the
providers,
and
so
if
this
is
something
work
that
you're
interested
in
please
show
up
in
the
slack
Channel
show
up
and
github.
You
know
talk
about
the
issues
that
you
want
to
work
on,
and
we
were
are
more
than
happy
to
guide
you
in
the
direction
to
become
you
know:
positive
contributors
to
the
sig.
A
E
A
B
B
So
if
you're
interested
in
continuing
over
development,
then
you'll
want
to
actually
start
use
some
of
the
things
we
talked
about
here
to
build
an
external
provider
for
that,
but
essentially
so
I.
Think
if
I
understand
your
question
its,
how
do
you?
How
do
you
schedule
the
nodes
on
the
on
the
cluster
and
sig
cloud
provider?
Isn't
doesn't
worry
about
how
a
node
is
created?
C
If
I
can
add
to
that,
the
first
thing
I'd
mention
is
I
would
go
talk
to
sig
cluster
lifecycle,
because
how
denotes
come
into
an
existence
is
something
that's
usually
dealt
with
by
cluster
lifecycle
right
now,
once
the
node
exists
and
it
has
been
created
in
kubernetes.
How
will
you
provision
that
node?
According
to
the
cloud
provider?
That
is
exactly
what
the
cloud
provider
sig
cloud
provider
is
concerned
about,
but
getting
the
node
into
existence.
You
need
to
talk
to
a
cluster
lifecycle
and
then.
B
B
E
C
And
to
be
more
specific,
if
you
want
to
not
go
through
too
much
pain.
Well,
maybe
you
may
want
to
think
about
helping
us
actually
move
over
into
staging
rather
than
having
us
just
delete
it.
If
it's
something
you
care
about,
rather
because
once
it's
deleted,
you're
gonna
have
to
go
in
the
look-back
machine
to
find
an
older
version
of
it,
and
probably
you
know
copy
that,
and
if
you
can
just
keep
it
going,
you
maybe
better
off
right.
B
B
You
know
to
the
idea
of
if
there
is
demand,
for
you
know,
for
people
to
be
able
to
attend
the
meetings
at
the
time,
that's
good
for
them
to
accommodate
that
either
by
changing
the
the
meeting
time
or
adding
a
you
know,
a
tick-tock
meeting,
so
that
we,
you
know
it's
us
European
friendly
one
time
and
asia-pacific
friendly
on
the
other
time.
I
think.
C
If
you
look
up
Andrew
psych
him
and
you
look
for
the
roadmap,
he
actually
has
a
very
nice
breakdown
quarter
by
quarter
of
what
each
of
our
goals
are
for
cloud
provider,
extraction
and
cloud
provider
through
the
end
of
2020,
once
we
have
everyone
out,
I
think,
there's
gonna
be
a
lot
of
you
know
looking
in
and
trying
to
determine.
What's
next
I,
imagine
that's
a
lot
of
how
do
we
make
a
better
interface
to
doing
various
things
that
are
undoubtedly
going
to
be
coming
up?
C
It
may
be
things
like
how
to
support
specialized
custom
hardware.
Do
we
want
to
move
to
more
of
the
CSI
style
model
for
some
of
the
various
pieces?
Also,
we
have
this
never-ending
list
of
these
little
tweaky
things
about
things
like
how
to
name
names.
Nodes
get
named:
how
can
we
make
that
consistent
across
cloud
providers
for
transitions
for
hybrid
clouds,
for
that
sort
of
thing,
and
also
for
things
like?
C
How
do
you
determine
a
note
is
dead
and
what
are
the
calls
that
need
to
be
made
notes
have
health
checks
that
they
make
against
the
cube
api
server
when
a
certain
numbers
have
been
missed?
Now
we
have
to
determine
okay.
Is
this
node
just
slightly
unhealthy
or
was
it
removed
by
the
underlying
cloud,
and
so
the
some
of
those
sort
of
lifecycle
models
need
to
be
looked
at
fairly
closely.
Ok,.