►
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
SIG Cloud Provider Deep Dive - Walter Fender, Google & Yassine Tijani, VMWare
The long-term goal of SIG Cloud Provider is to promote a vendor-neutral ecosystem for our community. New vendors providing support for Kubernetes should feel equally empowered to do so as any of today’s existing cloud providers. More importantly, SIG Cloud Provider is focused on ensuring a consistent and high-quality user experience across providers. This deep dive will focus on the efforts to finalize the removal of cloud-specific code from the Kubernetes code base and develop a migration strategy for in-tree to external providers. This session will also cover the evolving SIG governance structure following from the merging of individual cloud provider SIGs as working groups under SIG Cloud Provider, as well as any other major topics raised by the cloud provider community.
https://sched.co/Uafo
A
B
A
A
B
First,
what
is
the
CPI,
which
is
one
one
of
the
main
interface
that
we
own?
The
CPI
is
the
cloud
provider
interface,
so
basically,
it
enables
cloud
providers
and
infrastructure
providers
to
integrate
natively
with
kubernetes.
So
the
main
implementation
of
this
interface
by
providers
is
a
binary
or
container
that
is
called
the
CCM.
This
interface
mainly
provide
integration,
with
instance,
lifecycle
load,
cinque
route
management
zones,
and
this
interface
can
be
found
and
imported
under
the
cloud
provider
repository
in
the
Kuban
ares
org.
B
So
how
do
we
push
changes
to
the
CPI
as
a
community?
Well,
first,
it
starts
with
a
cap
once
we're
happy
with
the
design
we
start
extending
the
CPI.
This
extension
is
done
under
the
staging
directory
of
the
kubernetes
kubernetes
repository
this
stage
in
their
directory
is
usually
published
to
external
repositories,
so
that
providers
do
not
import
the
whole
kubernetes
cube,
Nettie's
repository,
but
just
imports
the
cloud
provider
one.
B
So
after
we
are
we're
extending
the
interface,
we're
cutting
basically
a
release
of
kubernetes,
and
then
the
providers
can
choose
to
implement
or
not
the
new
feature,
and
once
this
choice
is
made,
usually
when
upgrading
Kuban
Ares,
the
user
can
have
the
feature
enabled.
So
one
note,
though,
is
that
providers
have
two
chests
their
implementation
against
the
latest,
supported
versions
of
kubernetes,
which
usually
brings
more
confidence
for
the
provider.
A
The
CCM
built
by
the
cloud
provider
runs
all
the
controllers
that
do
need
to
be
run,
do
need
to
talk
to
the
cloud
provider
itself
and
if
you
pull
this
standard
CCM
that
we
have
in
KK
today,
what
you're
gonna
find
is
it
has
three
controllers
in
it:
I
believe
the
service
controller,
the
route
controller
and
the
cloud
node
controller.
So
one
question
is
hey:
is
it
possible
for
me
to
run
other
controllers
than
just
those
three?
The
answer
is
yes,
and
in
fact,
Google
is
going
to
have
to
do
that.
A
So,
let's
take
a
quick
look
at
what
how
exactly
Google
will
do
that?
So
the
first
thing
is
we
look
at
legacy
providers.
This
is
the
version
of
the
node
I,
pan
controller,
that
Google
uses
and
Google's.
The
only
one
that
uses
it
so
Google
is
gonna
want
to
take
the
node
IPAM
legacy
provider
controller
and
run
it
in
their
CCM.
A
So
how
do
we
make
that
happen?
So
the
first
thing
is
we
get
into
command
cloud
controller
manager,
app
controller
manager
go
and
we
find
this
wonderful
little
function
called
nuke,
a
new
cloud
or
new
controller
initializers.
Excuse
me
and
that's
got
a
mapping
of
the
name,
the
external
name
of
the
controller,
to
the
section
of
code
that
actually
initializes
and
starts
that
controller,
and
so
what
Google
will
have
to
do
and
what
you
might
have
to
do.
A
If
you
have
a
custom
controller,
is
add
a
line
like
the
one
I
have
in
bold
here,
which
says:
controllers,
know
type
and
is
equal
to
start
no
type,
an
controller.
This
is
a
little.
This
is
how
you
do
it
today.
It
is
a
little
clunky.
We
know
we
need
a
better
way
to
extend
this.
We
have
some
ideas,
but
we
also
know
that
they
needs
to
be
backward
compatible
and
so
you've
seen
and
I
have
some
ideas
and
you
you'll
see
that
coming
up
in
a
future
cube
con.
A
So
that
sounds
great
I've
added
node
IPAM
controller
to
my
CCM,
but
isn't
there
a
node,
ipam
controller
running
in
the
KCM?
Yes,
there
is
so
one
of
the
things
that
hat
would
need
to
happen.
Is
we
can
look
in
the
command
line,
reference
for
the
cube
controller
manager,
and
we
can
find
this
little
flag
that
you
can
provide
called
dash,
dash
controllers
that
takes
a
string
slice
and
what
it
does
is
allows
you
to
twiddle,
which
controllers
are
actually
running,
and
so
what
I
can
do?
A
A
Okay,
some
part
way
through
my
migration.
Take
down
my
next
KCM
new
KCM
and
see
see
em
come
at
the
new
version
and
then
I
take
away.
My
last
KCM,
which
happened
to
be
the
master
and
boom
I,
now
have
CCM
master
Casey,
a
master
and
hot-hot
backups
of
each
of
them
running
in
my
new
master
at
the
new
version
and
everything's
good
right
and
the
second
we'll
look
at
it
a
little
more
closely.
A
None
of
our
controllers
were
written
to
actually
have
more
than
one
instance
of
them
running
at
the
same
time,
and
so
I
can't
guarantee
you
something
went
wrong,
but
something
might
go
wrong
and
we
don't
want
to
chance
it,
especially
since
that
something
is
going
to
go
wrong
during
the
migration
and
then
when
I'm
done
and
my
poor
on
call
or
essary
or
taking
a
look
they're
trying
to
work
out
what
went
wrong
and
everything
looks.
Fine
I've
got
one
copy
of
the
service
and
route
controller
running
in
the
CCM
everything's
good.
A
So,
let's
look
at
what
actually
happened
during
that
migration
so
same
picture,
but
instead
of
a
KCCI
master
I'm
showing
you
where
the
service
and
Route
controllers
are
running
so
I
take
down
that
first
KCM
and
I
bring
up
a
new
case
Yemm
and
a
new
CCM,
except
that
new
CCM
is
also
running
a
service
and
Route
controller,
retro
and
I.
Take
down
that
next
case.
Yemm
and
things
didn't
get
better
and
then
I
take
down
the
old
case
Yemm
and
suddenly
everything
looks
good,
and
this
is
where
we
fool
our
poor
sr8.
A
Let's
not
do
that.
So
the
idea
to
how
we're
going
to
fix
it.
We've
got
a
cap
for
it,
but
the
basic
idea
of
how
we're
going
to
fix
it
is
that
we're
gonna
add
an
additional
leader
election
lock,
which
is
just
for
this
migration
and
so
that
leader,
election
lock
is
across
both
versions
and
so
to
be
able
to
run
the
service
or
route
controller.
A
If
you're
interested
in
the
really
gory
details
for
what
I
just
described,
there
is
an
entire
cloud
controller
manager,
migration,
cap,
Andrew
psyche
him.
My
co-chair
myself
and
several
members
of
the
cloud
provider
extraction
team,
including
you
seen
Nick
Turner
and
a
few
others,
have
worked
fairly
hard
to
put
together
the
second
link
that
I
have,
which
is
actually
a
proof
of
concept
where
we
can
show
this
working
and
one
of
the
nice
things
about.
It
is
while
it's
intended
to
solve
the
problem
of
migrating
from
a
KCM
only
to
a
KCM
plus
CCM
model.
A
So,
as
I
said,
the
essential
idea
is
that
the
LOC
defines
which
controllers
it
runs
across.
So
it's
it's
configurable,
so
it
doesn't
have
to
be
this
service
and
route
controller.
It
can
be
going
back
to
an
earlier
example
the
service
the
route
and
to
the
node,
iPad
and
controller,
and
then
and
we
define
which
sets
of
versions
you
want
to
run
on.
So
we
don't
all
have
to
migrate.
At
the
same
time,
AWS
could
could
migrate
one
release
earlier,
or
one
release
or
later
than
Google,
and
that
would
be
fine.
A
So
next
problem
removing
persistent
volumes,
so
first
thing
I
would
like
to
do
is
say
a
big
thank
you
to
six
storage.
This
was
a
lot
of
work.
It
continues
to
be
a
lot
of
work.
I
would
especially
like
to
thank
Michelle
ow
for
from
six
storage
for
the
and
David
you
for
the
huge
amounts
of
work,
they've
done
and
trying
to
get
this
working
across
the
community.
A
This
is
a
storage
problem,
but
it
is
also
a
cloud
provider
problem
and
you
know
toward
that
end.
If
any
of
you
want
to
create
a
CSI
driver,
the
cloud
provider,
team,
myself
and
recycling
and
etc,
we
have
repos
ready
for
you
to
go
into
where
you
can
do
the
development
for
your
CSI
driver.
So
what's
the
problem,
the
problem
is
that
many
of
the
entry
providers
AWS
google
asher,
have
things
like
GCE,
PD
or
AWS
ECB,
and
if
I
want
to
attach
those
to
a
node
attach
those
to
a
pod,
mount
them,
etc.
A
I've
got
to
make
cloud
calls
and
originally
that
cloud
call
was
done
directly
from
the
cubelet.
Then
we
made
things
a
little
better
and
we
created
a
flex
driver
and
that
kind
of
worked,
but
it's
scripts
and
it's
not
consistent,
doesn't
monitor
well.
We've
also
tried
doing
it
from
the
controller
manager
that
works
a
lot
better,
but
you
still
then
need
to
have
some
sort
of
driver
running
on
in
the
cubelet
itself.
So
today
the
idea
is
that
there's
a
daemon
set
for
every
volume
type
that
you
want
to
run.
A
A
We
got
to
worry
about
control.
We
got
to
control
the
versions
right,
so
you
know
the
control
plane
needs
to
talk
to
it.
The
local
needs
to
talk
to
it.
We've
got
to
make
sure
that
all
of
the
relevant
api's
that
are
needed
for
that
are
all
in
places,
and
then
we
have
the
legacy.
So
there
is
a
CSI
driver
type
and
then
you
can
enumerate
within
that
which
type
it
is
within
CSI,
but
we
have
the
legacy
GC
epd
or
AWS
ECB
drivers,
and
so
those
also
need
to
be
dealt
with.
A
And
the
idea
is
that
we'd
Riteish
we,
the
goal,
is
to
turn
them
into
a
Shem.
So
in
the
beginning,
there'd
be
a
switch
and
when
you
say
use
GC
EPD,
you
know
you
can
control
whether
it
uses
the
old
style
and
goes
through
the
cloud
provider
directly
or
whether
it
goes
through
CSI
and
it
would
default
to
going
through
the
old
style
and
then
it
release
later.
We
flip
it
and
now
it
defaults
to
going
through
the
Shem.
A
That's
a
fairly
long
and
extended
system,
and
we
are
coordinating
closely
with
the
storage
team
to
make
all
of
that
work.
In
the
meantime,
at
the
same
time,
I
told
you
there's
always
new
stuff
going
on.
We've
got
things
that
were
just
added
to
the
CSI,
like
snapshot
and
restore
image
from
snapshot,
it's
fairly
significant
work
and
it's
really
going
to
be
dependent
on
cloud
providers.
If
you
want
that
stuff
to
be
fast
and
efficient.
A
So
so
we
don't
want
to
just
this
kind
of
reiterates.
We
don't
want
to
just
delete
those
volume
types
right,
it's
a
little
too
final
and
there's
no
rollback.
We
always
want
to
be
able
to
roll
back.
We
want
things
to
continue
working.
We
want
to
make
sure
that
we
have
a
Venusian
till
we're
absolutely
certain
everything
is
going
well.
A
B
So
now
we're
going
to
talk
a
bit
about
provider,
specific
networking,
so
networking
in
kubernetes
land
chance
to
be
not
easy,
so
a
provider
can
ease
the
integration
with
kubernetes
and
help
the
users
navigate
this
land.
There
are
two
main
areas
where
the
provider
can
integrate
with
kubernetes
the
first
one
is
ipam
pod,
IP
management
and
the
second
one
is
routing,
basically
routing
network
packets
through
the
providers
infrastructure.
B
Well,
the
the
implementation
has
to
obey
to
certain
rules
for
kubernetes
to
work.
The
first
one
is
that
the
pod
can
communicate
well
with
all
the
other
nodes
with
now.
The
other
one
is
that
both
with
host
networking
enabled
can
communicate
with
all
the
other
parts
on
the
all
the
nodes
without
nad
and
without
not,
and
the
last
one
is
that
agents
on
the
notes
such
as
Kuebler
daemon
sets
and
so
on,
can
communicate
with
all
pods
on
the
same
node.
B
So,
let's
start
with
not
a
native
Aipom,
so
for
I
Pam
there
are
true:
the
provider
can
integrate
with
the
first
one
is
integration
to
enable
pod
ciders,
so
this
tends
to
be
controller
based.
So
what
did
that?
What
this
does
basically
is
that
it
sets
the
knot,
spec
but
cider
field,
to
do
so.
It
usually
reconciles
cloud
infrastructure
to
assign
a
subnet
to
this
field,
and
then
you
have
to
do
so.
B
You'd
have
to
disable,
as
Walter
said
previously,
on
the
slides
you'd
have
to
disable
the
node
ipam
controller
that
is
built
in
into
kubernetes
and
start
your
own.
The
second
item
is
a
native
pod
IPS,
so
this
sense
to
be
done
through
the
CNI
and
it
is
daemon
set
based.
So
you
don't
need
to
manage
a
complex
configuration
other
than
CNI
configuration.
It
is
usually
based
on
node
local
resources,
usually
outsiders
that
were
affected
to
the
node
object
or
secondary
network
interfaces
that
were
are
available
in
the
VM.
B
So
another
feature
for
native
pod
I
piece.
If
you're
relying
on
if
you're
relying
on,
for
example,
native
IPS,
is
device
plug-in.
So
let's
say,
for
example,
you
have
an
implementation
of
device
plug-in
you
could
you
use
your
users?
Can,
for
example,
let's
say,
request
a
native
IP
and
then
get
scheduled
based
on
the
availability
of
this
IPS
on
the
nodes.
B
So
with
that,
we
can
talk
now
about
erosion,
so
for
not
even
native
routing.
The
first
obvious
solution
is
to
rely
on
the
native
pod
IPS
that
were
assigned,
so
this
doesn't
require
that
much
because
the
native
pod
IPS
are
usually
routable
through
the
infrastructure,
so
there's
not
much
to
do
there
so
for
the
other
variants.
B
A
B
To
create
the
network
namespaces
on
the
containers
and
the
nodes,
there's
also
the
CPI
that
plays
into
this.
The
CPI
has
an
interface
that
is
built
into
it
that
enables
Quarian
routes
and
the
list
of
routes
to
and
update
them.
There's
also
the
route
controller
that
leverages
the
CPI.
And
finally,
you
could,
for
example,
enable
this
feature
in
at
the
cube
controller
level
by
enabling
the
flag
configure
called
routes.
So
this
is
very
convenient
for
users
that
do
not
want
to
have
native
pod
IPs.
B
For
some
some
other
reasons,
and
the
last
variant
is
basically
inline
in
their
routes
on
at
the
node
level.
For
this
one,
you
need
to
have
the
node
on
the
same
subnets.
Basically,
and
then
you
just
have
to
have
you
just
need
a
daemon
set
that
will
always
updates
the
routes,
basically
on,
given
the
pods
that
are
scheduled
or
the
disturb
Nets
that
are
assigned.
B
Another
way
to
integrate
where
your
provider
with
Cuban
Aries
is
KMS,
so
KMS
is
a
key
management
system.
It
enables
users
to
manage
keys
at
once
onto
a
central
place.
Usually
providers
have
already
KMS
systems
that
are
available,
so
it
helps
users
to
like
to
centralize
everything,
kubernetes
VMS,
everything
in
in
the
KMS.
So
how
does
cuba
Nerys
use
kml
a
KMS
systems?
Basically,
kubernetes
has
something
that
is
called
envelop
encryptions.
Basically,
it
relies
on
a
local
key
to
increase
the
data
at
rest.
B
B
B
Lastly,
or
well,
another
integration
points
that
we
can
see
is
the
on
the
cluster
lifecycle
land,
so
there's
a
project
called
cluster
API,
which
is
which
enabled
the
clarity
of
cluster
management,
but
before
before
talking
about
cluster
API,
let's
talk
a
bit
about
lifecycle
management
of
kubernetes
clusters.
First
of
all,
it's
super
hard
to
create
clusters
for
users.
There's
a
lot
of
things.
There's
a
lot
of
knobs
to
tweak
to
have
a
fully
functioning
clusters.
B
So
what
if
we
could
manage
infrastructure
as
kubernetes
api
s'?
So
this
is
what
is
cluster
api?
It's
basically
mapping
infrastructure
to
kubernetes
objects.
We
have
the
notion
where
that
is
a
machine
deployments
that
map's
exactly
to
a
deployment
same
for
machine
set
when
you
think
about
machine
set,
you
think
about.
You,
have
to
think
about
replica
set
same
for
machine
for
parts,
and
we
have
the
notion
of
a
cluster
that
declares,
for
example,
the
version
of
the
cluster
and
so
on,
and
so
on.
So
you
as
a
provider.
B
What
would
you
need
to
implement
to
leverage
cluster
api
so
to
implement
a
cluster
api
provider?
You
need
to
first
understand
the
architecture
of
cluster
api.
Cluster
api
is
based
on
two
main
resources.
The
first
one
is
cluster
and
the
second
one
is
machine
for
cluster.
You
have
a
generic
CRD
that
is
created
and
has
I
would
say
the
main
fields
that
are
common
to
every
provider,
such
as
the
version
of
kubernetes
rivers
in
and
so
on,
and
this
reference
is
what
we
call
the
infrastructure
resources.
B
Reference
to
the
in
the
cluster
resource
same
for
machine,
you
would
have
a
reference
to
AWS
machine
and
you
would
have
another
thing:
another
reference
which
is
a
cube,
ATM
config.
Basically,
when
a
machine
is
created,
the
provider
will
rely
on
a
cube,
ATM
config,
true
in
to
have
a
cube,
ATM
join
command
executed
and
the
machine
so
that
the
machine
can
join
the
cluster.
A
Alright,
so
there's
also
little
bits
of
dirty
laundry
or
other
things
that
need
to
be
cleaned
up,
so
the
cube
API
server
today
has
this
little
feature
called
SSH
tunnel.
It's
been
deprecated
for
over
a
year
now,
DIMMs
has
reserved
the
right
to
try
and
delete
that
code,
although
I
think
I
should
get
to
do
it
personally,
we
need
to
replace
it.
A
So
the
idea
of
the
SSH
tunnel
and
the
reason
it's
a
problem
is
it's
a
it's
an
SSH
client
that
runs
in
the
cube,
API
server
and
when,
when
you're
having
problems
with
certain
types
of
connectivity,
you
can
configure
it
to
make
an
ssh
client
request
against
an
ssh
D
server
running
on
the
node,
and
but
that
means
the
node
have
the
sshd
daemon
has
to
have
the
right
set
of
keys.
So
then
you
need
make
a
cluster
or
a
club
provider
call
to
propagate
those
keys.
A
So
there
are
many
reasons
we
don't
like
this,
but
from
the
sig
cloud
provider
perspective,
it's
actually
that
cloud
provider
call.
We
don't
like
API
machinery
also
wants
it
gone.
They
have
their
reasons
I'm
off
once
it
gone.
They
have
their
reasons,
so
we've
come
up
with
this
thing
that
we
call
the
connectivity
server.
If
you
want
to
know
why
it
has
a
k'
in
it,
it's
primarily
because
connectivity
is
a
common
word
and
we
decided
we
wanted
to
be
able
to
actually
grep
and
find
things
that
were
specific
to
this.
A
The
idea
is,
we
want
to
be
able
to
communicate
under
conditions
when
classic
IP
routing
doesn't
work.
So
for
some
of
you
who
may
not
be
aware,
that's
pretty
common
in
gke,
it
may
also
be
common
in
other
scenarios
as
well.
I
know
I've
gotten
interest
from
both
Microsoft
and
Amazon
to
solve
this
problem,
I've
also
gotten
it
from
very
small
cloud
providers.
No
one
has
even
heard
of
that,
need
it
to
solve
it
where
they
want
to
do
like
a
custom,
VPN
solution
on
top
of
this,
and
so
the
entire
thing
was
designed.
A
With
that
in
mind,
it
also
tries
to
not
conflate
the
issues
of
how
you
do
that
routing
from
how
you
serve
the
api's.
So
it
solves
how
I
get
the
routing
done
and
it
leaves
problems
of
how
to
do
api's
to
the
cube
api
server,
so
it'll
actually
lower
the
complexity
of
the
cube
api
server,
and
that
was
the
whole
point.
We
wanted
a
general
solution
and
a
general
solution
that
could
be
revved
changed
without
having
to
Rev
and
change
the
cube
api
server.
A
If
you
are
interested
the
code
for
the
reference
implementation
of
this,
which
I
own
well
kubernetes,
SIG's
own,
but
I
I'm
listed
in
the
owners
file
is
under
the
API
server
network
proxy.
There
are
several
other
community
members
and
you
know
shout
out
for
anyone
who'd
like
a
smaller
kubernetes
project,
to
work
on
with
a
small
codebase.
This
is
a
great
place
to
get
your
feet
wet.
A
So
how
does
it
work?
Now
the
idea
is,
there
are
several
ways,
but
the
reference
implementation
that
you'll
find
for
GCE
has
a
idea
of
running
sidecars
in
both
the
master
and
the
cluster.
So
we
have
these
things
called
connectivity
agents
right
now.
I
have
them
set
up
as
a
daemon
set,
so
there's
one
running
in
every
agent
or
in
every
there's
one
agent
running
in
every
node
and
it's
configured
to
know
how
to
talk
to
the
server
normal
direction
of
communications.
So
it
will
connect
to
the
the
connectivity
server
or
and
advertise
hey
hey.
A
A
A
It
is
important
to
understand
in
this
model
the
the
the
egress
selection
service
and
the
protocol
between
the
API
server
and
the
connectivity
server
is
defined
as
part
of
the
kubernetes
cap,
the
way
the
agent
and
the
proxy
server
or
connectivity
server
talk
to
each
other
is
not
part
of
the
cap.
It
is
deliberately
not
part
of
the
cap.
The
intent
is
that
this
is
something
that
the
cloud
provider
can
swap
out
to
meet
their
needs.
We
provide
a
reference
implementation.
A
The
reference
implementation
today
is
going
to
be
talking,
G
RPC
with
M
TLS
right,
and
so
we've
got
a
good
starting
place
for
you.
If
you've
got
ideas
of,
we
need
to
do
VPN
instead
reach
out
to
us
we're
happy
to
help
onboard
you
get
that
switch
going,
but
it's
deliberately
left
open
so
that
you
can
do
what
is
needed
for
you.
A
I
know
that
one
or
two
of
the
cloud
providers
have
even
suggested
they'd
like
to
look
at
ways
in
which
they
can
reverse
this
and
actually
have
both
directions
of
communication
go
through
this
tunnel.
So
even
when
the
cubelet
needs
to
talk
to
the
cube
api
server,
it
would
go
over
the
tunnel.
So
there's
plenty
of
things
in
that
direction
that
we're
looking
at
doing
all
right.
So
we've
gone
through
a
lot
of
material
we've
gone
through
all
of
it.
A
A
Why,
even
when
the
extractions
done,
this
SIG
is
not
done
and
there
will
continue
being
a
need
and
I
think
one
good
way
of
looking
at
it
is
if
we
actually
go
to
the
cate-cate
co-main
page
and
just
look
up
what
is
kubernetes
I
like
this
little
quote:
kubernetes
is
a
portable
extensible
open-source
platform
for
managing
containerized
workloads
and
services
that
facilitates
both
declarative
configuration
and
automation.
It
has
a
large,
rapidly
growing
ecosystem,
kubernetes
services,
support
and
tools
are
widely
available.
So
I'm
gonna
pick
that
apart
for
a
minute,
so
it's
portable
and
extensible.
A
That's
an
ongoing
effort.
Right.
We've
talked
about
new
features
like
the
snapshotting.
We've
talked
about
new
cloud
providers
coming
online
and
those
things
are
not
going
to
stop
right.
I
mean
this
is
an
ongoing
effort
it
and
we
wanted
to
remain
widely
available,
and
it's
only
wildly
available.
If
we
keep
on
that
ongoing
effort.
The
range
of
workloads
change,
the
features
of
cloud
providers
grow,
tooling
changes.
We
have
new
versions
of
cube
kado,
we're
looking
at.
A
We
have
new
versions
of
how
we
want
to
run
operators
and
controllers
new
ways
that
we
want
to
optimize
file
systems,
databases,
and
all
of
this
is
an
ongoing
effort.
That
means
the
cloud
providers
are
going
to
need
to
keep
doing
work
and
not
just
traditional
cloud
providers
either.
I
wouldn't
be
surprised
that
there's
a
couple
people
in
the
audience
who
are
looking
to
create
a
cloud
provider
that
is
just
their
company's
data
center
for
migrating
their
traditional
workload
on
to
kubernetes.
That's
still
a
cloud
provider.
A
We
need
to
support
those
people,
and
that
is
a
community
effort.
Right
and
every
week
we
have
I,
don't
know
how
many
six
26:36
each
of
them
are
moving
forward.
They
have
interesting
things
they
want
to
do
and
some
of
the
time
when
they
want
to
do
one
of
those
interesting
things
it
involves
coming
back
to
the
cloud
providers
and
working
out
how
to
do
it
in
a
way
that
doesn't
hurt
some
of
our
community
members,
which
is
to
say
some
of
those
cloud
providers.
A
A
A
Right
so
the
look
that
I
mean
right
now:
CCM
is
in
a
weird
bit
of
a
weird
spot,
so
the
latest
version
of
CCM
is
actually
is
both
entry
and
out
of
tray
simultaneously.
So
the
entry
is
a
reference
implementation
and
it
will
run
the
node
cloud
controller,
the
service
controller
and
the
route
controller.
A
The
expectation,
however,
is
that
honestly,
the
people
who
are
most
using
CCM
today
are
the
folks
who
are
not
in
tree,
so
I
would
expect
that
it's
going
to
be
companies
like
rancher
Oracle
that
are
most
likely
to
be
running
the
CCM
and
the
version
of
the
KK.
The
version
of
CCM
you
find
in
KK
today
doesn't
even
have
those
cloud
providers
linked
in
so
I
am
almost
certain
I.
A
I'm
sorry
I'm
still
not
yeah,
so
we
have
cubelets,
so
cubelet
is
running
on
and
so
right
now
today,
cubelet
is
you
uses
the
two
things
cubelet
needs
from
cloud
provider?
Are
the
ability
to
mount
and
unmount
a
drive,
so
that
was
the
CSI
stuff
I
touched
on
and
the
the
credential
provider
stuff
so
we're
actually
so
on
the
curtain.
So,
on
the
I'll
tell
you
right
now
on
the
mount
unmount,
that's
easy!
That's
CSI!
A
We
discussed
that
in
the
extension,
the
credential
provider
is
probably
our
longtail
right
now,
a
member
of
the
the
sig
who's.
Not
here
is
currently
responsible
for
getting
the
cap,
so
the
cap
I
think
isn't,
has
not
yet
hit
implementable,
but
those
are
the
two
problems
we
need
to
solve
and
then
the
goal
right
now
and
I'm
actually
in
conversations
with
a
couple
of
the
people
in
this
room
right
now
on
how
we
make
sure
that
that
cap
gets
to
implementable
in
118,
okay,
so
for
a
cubelet,
those
are
the.
A
B
A
That
is
an
aspirational
goal
just
to
be
clear,
but
here's
the
thing
I
don't
want
to
advertise
too
loudly.
That
is
an
aspirational
goal.
I
have
been
teased
several
times
with
this
cube
kind
of
oh
we're
in
the
same
place
we
were
last
year
right,
yeah,
we
are
and
that's
why
I'm
publishing
a
date,
because
last
year
we
didn't
put
deadlines
and
we
got
nowhere.
The
cloud
providers
needed
date
to
motivate
people
and
to
get
get
things
to
happen.
B
So
yeah
there's
right
now:
there's
not
a
list
for
a
cloud
provider
getting
started
that
lists
all
the
integration
points.
This
talk
was
meant
to
be
a
starting
point,
but
this
will
definitely
be
I.
Guess
something
that
we'll
work
on
at
some
point.
You
have
a
guide
that
lists
all
the
integration
points.
Even
here
we
didn't
list
everything
because
there's
still
identification
and
authorization
webhooks,
for
example,
but.
A
I
mean
thank
you
for
the
reminder
on
the
shout
out.
If
you
have
these
sort
of
questions
and
we've
fallen
down
and
there's
a
lot
of
stuff,
so
there
are
places
we've
fallen
down.
If
you
look
up
sick
cloud
provider,
we
have
meetings
every
other
week
and
so
definitely
come
to
those
meetings
and
add
an
agenda
item
that
just
I
mean
in
your
free.
You
know,
make
sure
you're
part
of
the
kubernetes
dev
org
and
you
can
add
agenda
items
and
you
can
say
hey
guys:
I
need
a
cloud
provider
getting
started
guide.
So
yeah.
A
Please
show
up
to
that.
If
you're
interested
in
other
things,
we
have
a
slack
channel,
definitely
ask
questions
on
the
slack
channel.
We
also
have
things
like
the
the
API
machinery
network,
proxy
slack
Channel,
and
we
have
a
cloud
provider
extraction,
slack
Channel.
So
all
of
those
are
good
ways
to
reach
out.
Also
I'm
chef
taco
on
github,
my
co-chair
is
Andrew
psych
him
on
github,
so
feel
free
to
reach
out
to
either
one
of
us.
That's
exactly
the
sort
of
thing
we
should
be
helping
with.