►
From YouTube: Cloud Provider Subproject AWS / User Group AWS - Nishi Davidson, Pulumi & Justin SB, Google
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
Cloud Provider Subproject AWS / User Group AWS - Nishi Davidson, Pulumi & Justin SB, Google
SIG AWS is now a sub project of SIG Cloud provider. It is also a User Group. In this session, we will discuss what this means for you and our ongoing roadmap. We will also both demo and discuss features of the 7 projects (previously SIG AWS subprojects) that are part of Cloud Provider Subproject AWS. Bring details of your use cases and feature requests so you can define the future roadmap / feature ask. Also bring your priorities wrt documentation and testing. Finally we will gather together to discuss immediate contributions that folks can make to make these projects meaningful for all users of k8s on AWS.
https://sched.co/UajC
A
I
am
just
in
Santa,
Barbara
Nishi
was
supposed
to
be
here,
but
was
unfortunately
unable
so
I
am
feeling
we
are
filling
in
for
her
and
I
have
been
joined
by
the
very
capable
chen-pang,
a
tap
from
a
diverse
and
Nick
Turner
from
a
diverse
and
hopefully
team.
A
diverse
will
mostly
be
giving
the
update
today
and
I
will
basically
give
a
quick
introduction
about
I
think
mostly
some
mechanics.
A
So
some
other
sort
of
work,
sig
stuff
which
we'll
see
is
not
entirely
accurate
and
then
we'll
dig
into
mark
some
of
the
technical
stuff,
Nick
you're
going
to
talk
about
the
cloud
provider
and
yes,
n
is
gonna
talk
about
CSI
and
then
we're
gonna,
share,
sort
of
our
vision
or
wish
list
for
2020
and
but
we're
really
fingers
crossed.
Gonna
leave
a
lot
of
time
this
time
for
Q&A
and
really
I
want
to
hear
right
what
you
want
to
see
in
2020
for
AWS
and
kubernetes.
A
A
A
So
what
we
did
is
we
changed
a
cig
AWS
so
that
it
is
now
under
the
cig
cloud
provider
umbrella,
it's
no
longer
a
cig,
and
so
what
used
to
be
all
the
sig
clouds
are
now
provider
clouds
and
technically
they
are
no
longer
SIG's.
They
are
sub
providers
underneath
sig
cloud
provider.
I
think
there
were
some.
A
Where
are
things
let's
go
through
that
quickly?
So
if
you
want
to
talk
about
something
kubernetes
native
specific,
it's
still
the
great
place,
a
great
community
to
hang
out
in
or
ask
initial
questions
is
he's
gonna,
be
slack
and
so
provider
a
TBS
is
a
great
community
space.
I
think
a
lot
of
people
are
in
there.
If
you
have
more
in
depth,
questions
snack
is
probably
not
the
best
forum
in
general
for
those
things
and
for
those
the
mailing
list
is
always
a
good
option.
A
A
So
if
it's
a
cloud
provider
thing,
that's
where
that
sig
or
sig
network
or
sick
storage
as
appropriate
and
again
the
goal
there
is
to
make
consistent
decisions
across
the
various
platforms,
so
that
a
networking
decision
feel
and
networking
feels
the
same.
Whatever
cloud
you're
using
bugs
or
suspected
bugs
go
to
github
as
always.
Ideally,
the
goal
is
ideally
go
against
the
correct
project
and
the
goal
is
that
you
know
bugs
don't
sort
of
sit
in
the
KK,
repo
and
sort
of
get
a
little
bit
lost.
A
But
obviously
it
can
be
very
hard
to
know
where
a
bug
is
and
like
figuring
out
where
a
bug
lies
is
almost
half
the
half
the
work.
And
so
it's
it's.
Okay
to
guess
and
put
it
in
KK.
If
you
don't
know,
but
I
would
presumably
I
would
personally
guess
first
and
allow
it
to
be
rerouted
rather
than
putting
into
KK.
But
if
you,
if
you
genuinely
don't
know
or
in
KK
it's
a
fine
place
and
PRS.
A
Hopefully,
you
know
where
your
code
lives,
the
code
that
you're
changing
lives,
and
so
those
do
go
to
the
relevant
project
and,
if
you're
not
clear
on
where
that
code
should
live,
then
discussing
with
the
sig
who
presumably
own
the
code
is
the
right
way
to
establish
that
routing
and
the
goal
there
is
that
contributions
are
easier
than
they
have
historically
been
in
kubernetes,
kubernetes,
so
I
hope
that
makes
sense
to
everyone.
So
now,
if
you're
wondering,
where
did
my
slack
channel
go
and
why
is
it
provider
AWS
and
not
secured
to
us?
A
B
Testing
testing
all
right,
so
so
the
cloud
provider
sort
of
encompasses
all
of
the
cloud
provider
specific
code
in
kubernetes,
and
some
of
the
recent
developments
in
that
space
has
been
around
essentially
removing
it
all
from
kubernetes
core
there's
a
couple
reasons
for
that.
One
of
them
is
just
the
bloat
all
of
the
SDKs
bring
in
a
significant
amount
of
code
bloat.
The
other.
Another
reason
is
that
this
makes
it
a
lot
easier
if
we
have
an
interface
rather
than
you
know
getting
cloud
provider
PRS
merged
into
core.
B
If
we
have
some
sort
of
an
interface
and
the
the
cloud
provider
bits
are
separate,
it
makes
it
a
lot
easier
for
cloud
providers
to
have
their
own
release
track.
They
don't
have
to
wait
for
kubernetes
releases.
If
they
have
a
bug
fix
going
out,
they
don't
have
to
wait
for
that
to
go
out
so
that
overall
I
think
it's
a
really
good
thing
so
again,
migration
out
of
tree.
Basically
what
I
just
said
and
there's
a
kept
about
this
removing
entry
providers
if
you're
interested
in
looking
at
that
in
more
detail.
B
So
one
big
piece
of
this
migration
is
the
cube
controller
manager.
So
if
you're
not
familiar
with
the
cube
controller
manager,
it
is
a
binary
that
is
part
of
the
kubernetes
control
plane,
which
has
a
number
of
controllers
running
basically
control
loops
running
inside
of
it.
Some
of
these
control
loops
have
nothing
to
do
with
anything
cloud
related.
Others
have
a
lot
of
cloud
provider
code
inside
of
them,
so
part
of
this
process
of
breaking
this
out
of
tree
involves
separating
the
cube
controller
manager
into
two
pieces.
B
B
And
in
this
example,
we've
actually
already
broken
out
some
of
the
cloud
controllers
into
the
cloud
controller
manager
and
this
set
of
network
cloud
controllers
is
to
be
broken
out.
So
the
first
step
is
to
point
those
controllers
at
this
migration
lock
and
then
the
next
step
is
to
actually
migrate
them
over
to
the
cloud
controller
manager.
B
So
the
tentative
timeline
for
this-
and
these
are
very
subject
to
change,
but
this
is
just
sort
of
our
high-level
goal
for
next
year,
specific
to
the
AWS
external
cloud,
controller
manager,
we're
looking
at
kind
of
a
0.1
version
in
2019,
and
then
income
2020,
we'd
like
to
have
alpha
at
the
beginning
of
the
year
beta
sometime
around
May
early
summer
and
then
a
ga
closer
to
August
fall.
That
is
very
subject
to
change,
and
it
also
depends
on
the
you
know
how
the
actual
migration
machinery
goes
in
core.
C
Cool,
so
my
name
is
Chen
I'm
coming
from
Amazon
in
case
I'm
working
on
CSI
drivers
was
up
time
today.
I'm
gonna
give
some
updates
about
the
CSI
drivers
development.
We
have
been
made
since
last.
Coupe,
calm,
all
right
so
since
last
year,
I
remember
the
first
release
of
0.1
since
last
coupe
coming
in
2018.
C
Since
then,
we've
already
being
had
a
separate
editions.
Now
the
latest
releases
0.4
it's
already
being
declared
as
a
beta
stage.
Since
then
we
have
being
implemented
several
extra
features,
the
first
ones
CSI
rob
block
volume
where
you
can
actually
declare
a
device
as
rob
block
and
get
it
mounted
into
the
container.
So
that's
it's
gonna
be
useful
for
some
applications.
Like
my
Seco
I
fear.
I
should
procure
super
wanted
to
have
the
high
performance.
You
don't
want
it
to
go
through
actually
or
a
file
system.
C
So
another
extra
scene.
Where
is
a
new
file
system
for
XFS
of
already
supporting
the
ext?
You
see
463.
So
this
is
one
extra
one
we
have
been
adding
incrementally
and
the
last
one,
but
not
least
the
CSI
migration.
If
you
know
the
CSI
is
a
new
initiative
is
trying
to
be.
The
new
model
of
developing
is
out
of
three
driver
for
the
storages
case,
just
because
there's
already
EPS
entry,
plugins
being
written
and
there's
a
migration
problem
has
to
be
solved
in
the
kubernetes
community
by
which
this
quarter
we're
already
seeing
the
ladies.
C
If
you
are
gone
merged
to
make
it
a
flip
to
beta,
but
to
be
careful
about
this,
is
it's
gonna
be
beta
off,
so
that
this
migration,
Flags
gonna,
be
two
flags?
Basically
well
flag?
Is
gonna,
be
policy
as
I'm
migration,
we're
gonna,
say
you're
gonna
turn
on
this
migration,
where
it's
going
to
be
a
separate
flag
which
was
storage,
plug-in
specific,
like
in
the
case
of
AWS,
there's
going
to
be
a
flag
called
CSI
migrating
AWS,
where
it
is
being
beta
but
ID
for
this
off.
C
So
if
you
wanna
turn
it
on,
you
need
to
turn
on
explicitly
so
other
than
those
features.
There
are
several
like.
Like
nice
improvements,
one
of
the
mr.
ham
chart
and
in
customize
you
can
start
using
them
to
install
the
drivers
so
for
the
next
step,
CSI
just
released
a
new
spec
or
1.2,
or
where
the
driver
now
is
still
being
developed
against
a
1.1
spec,
and
the
next
step
is
definitely
keeping
up
and
also
we're
planning
for
the
J
plan.
C
C
C
As
you
can
see,
you
can
able
the
encryption
in
transit,
where
you
gonna
specify
this
TLS
mount
option
where
all
the
traffic
to
change
our
container
and
to
the
EFS
packin
are
encrypted,
and
also
we
added
more
entrant
test
cases.
The
same
to
harada
here
is
the
test.
Cases
are
actually
using
the
upstream
start:
6
storage
testing
suite,
which,
including
a
bunch
of
test
cases,
including
like
static
provisioning,
and
there
was
different
cases
and
also
as
being
compatible
with
eks.
C
I
am
for
service
account
feature
which
just
been
launched
ets
since
a
month
or
two
ago,
where
you
can
actually
just
the
original
way
of
say
authorizing
this
container
into
it
obvious
you
need
to
give
the
worker
node
I
am
role
but
which
sometimes
it's
like
it
not
secure
enough.
You
want
to
really
strip
down
the
scope
where
you
can
use
this
feature.
C
Next
step,
definitely
like
a
ham
chart
more
configurability
and
also
dynamic
provisioning
was
me
what
I
think
about
this
is
because
the
EFS
a
little
bit
special.
They
did.
We
are
expecting
the
way
it's
being
used.
It
feel
free
to
give
us
a
a
few
boxes
like
the
ef-s
is
really
being
created
over
and
over
again,
but
instead,
it's
more
of
user.
Whenever,
as
an
application
being
deployed,
you
are
really
looking
for.
C
Creating
a
new
directory
was
in
a
given
year
face
file
system,
that's
where
we
are
like
a
4c
in
Deus,
dynamic,
provisioning
going
to
work,
and
the
next
one
is
a
provision
in
the
EFS
file
system.
Although,
like
most
of
time,
you
don't
want
this,
but
just
in
case
you
wanna,
add
communities
native
experience
rather
like
to
provision
this
EFS
file
system.
Just
because
it's
a
highly
configurable,
you
can
say
you
want
to
create
a
EFS.
You
know.
Virus
availability
zones
was
different
security
groups
and
how
to
configure
them
in
a
kubernetes
native
way.
C
It
is
being
donated,
since
the
beginning
of
the
year
still
had
several
releases.
The
reason
1s
0.2
has
static
provisioning,
which,
if
you're
familiar
with
this
storage,
should
already
know
like
also
dynamic
provisioning,
where
you
can
create
a
lustre
file
system
on
demand,
which
we
seen.
This
is
handy
for
this
use
cases
FX
for
lustre
is
usually
used
for
like
data
caching
solution,
where
you
can
cache
some
data
from
your
s3,
like
you
might
have
a
terabytes
of
data
lives
inside
of
a
straight
bucket.
C
We
might
not
want
to
download
all
of
them
into
your
file
system
so
that
you
can
start
processing
them
from
FX
for
lustre.
It
provides
a
handy
feature,
whereas
low
lazy
loading,
those
data
zoning
when
they
are
being
accessed
and
also
mountain
option,
you
can
specify
the
a
flock
similar
since
I
am
for
service
account.
Next
step
is
adding
more
and
turn
test
cases
which
already
mentioned.
One
of
them
is
using
the
upstream
test,
Suites
CSI,
1.2
and
harem
chart
and
the
customized.
C
Then
this
is
the
demo
llamo
am
using.
If
you
look
at
their
owning
producing
poster
sections,
the
first
one
is
large
class.
It
is
exactly
the
same
as
a
current
eating.
Trebius
start
class,
the
part
to
have
here
at
the
provisioner,
as
you
can
see,
as
a
kubernetes
door,
I
also
actually
via
CBS,
where
you
we
are
used
to
use
to
provision
a
EBS
volume
using
the
entry
plug-in.
C
C
C
C
A
Cool,
thank
you.
Thank
you.
I
think
we
have
one
last
thing
which
I
think
we
were
gonna
mini
quick
panel
just
to
get
everyone
going
and
get
some
of
the
blood
flowing
we're
talking
about
what
we
want
to
see
in
what
we
hope
to
see
in
2020,
I,
think,
I,
think
I,
sort
of
Matt
I
will
kick
us
off
and
I
think
the
you
mentioned.
The
I
am
service
account.
I
am
for
service
accounts,
mm-hmm,
which
I'm
super
excited
about
and
I
would
love
to
see
that
packaged
as
a
cluster
add-on.
A
I'd
love
to
see
that
so
that
it
can
be
used
everywhere
across
like
eks
and
cops
and
cube
ATM
and
cluster
API
clusters,
and
that
it's
all
consistent
and
that
we
also
try
to
package
all
the
other
things.
We've
talked
about
cloud
provider,
the
CSI
drivers
that
we
have
we
test
them
across
all
the
various
platforms.
You
have
the
same
sort
of
experience
and
to
see
that
happening
across
all
the
cops
having
that
be
awesome.
B
D
B
So
yeah
one
thing
that
I'm
interested
in
it.
We
created
a
helmet
arts
repo
for
a
couple
of
our
at
mesh
add-ons,
so
I'm,
just
kind
of
curious
for
user
feedback.
If
people
have
used
that
or
if
they
like
using
helm
charts
if
they
want
to
see
more
of
our
our
various
offerings
in
helm,
charts
we'd
be
interested
to
know.
B
One
more
I'd
also
like
to
see
you
know,
though
everyone
who
is
either
operating
a
kubernetes
cluster
on
AWS
or
just
a
user
on
AWS.
You
know
I'd
love
to
see
more
people
at
the
cig
meetings.
Bringing
issues
forward,
I
think
we're
gonna
try
to
partially
on
us
like
I,
think
it
sort
of
has
attendance,
has
declined
a
little
bit
recently,
but
I
think
we're
gonna
try
to
step
it
up
next
year
at
the
provider
meetings.
Sorry
excuse
me,
provider
meetings,
yeah
so
and.
B
A
B
So
I
think
one
thing
is:
that's
sort
of
up
to
the
whoever's
packaging
kubernetes
for
you.
So
how
are
you
installing
kubernetes
right
if
you're,
using
a
managed
service
like
eks,
then
you
don't
really
notice
these
changes
for
the
most
part,
if
you're
installing
it
with
you
know,
cube
ADM
or
something
like
that,
then
I
think
all
that's
to
be
determines
exactly
how
the
migration
would
happen.
B
A
I
mean
I,
think
I,
think
that's
why
I'm
excited
or
hopeful
about
cluster
add-ons
if
we
can,
if
we
can
create
the
so
we're
deliberately
trying
to
put
less
into
the
the
core
box,
but
then
I'm
hoping
we
can
have
these
add-ons
that
nicely.
Let
you
in
a
repeatable
fashion,
whatever
tool
kit
using
whether
you're,
rolling
your
own
or
using
eks,
maybe
we're
the,
but
we
certainly
on
me
across
the
open-source
ecosystem
like
we'll
just
be
able
to
drop
those
pieces
in.
A
E
A
That
is,
that
is
what
we're
trying
to
figure
out
in
different
areas,
but
also
in
like
a
cluster
Evans's,
where
I
think
a
lot
of
this
is
happening.
It
would
be
a
big
llamo
file,
for
example,
with
a
bunch
of
descriptions
of
the
things
you
want
to
install
that
are
nicely
modularized
and
the
ones
you
the
ones
you
put
in
there
are
the
ones
you
get
and
there
would
be
a
llamo
file.
You
fork
for,
like
that's
a
pretty
basic
starting
point
and
you
could
have
a
more
advanced
starting
point.
Yeah.
B
So,
like
the
the
ich
eks
specific
approach
to
this
is
not
yet
defined,
but
I
think
we're.
One
thing
we're
thinking
about
is
using
helm
charts
to
make
this
a
lot
easier
and
then
you
know
maybe
there
will
be
some
kind
of
a
managed
add-ons
solution
in
the
future.
I'm,
not
sure
if
I'm
correct
about
that.
Maybe
look.
We
can
comment.