►
From YouTube: Kubernetes - AWS Provider - Meeting 20210625
Description
Recording of the AWS Provider subproject meeting held on 20210625
A
A
Basically,
it's
just
a
pull
request
that
I
opened
up
for
actually
there's
two
pull
requests.
One
of
them
is
two
kubernetes
and
one
of
them
is
to.
I
guess
the
important
one
is
to
kubernetes.
So
let
me
just
that's
the
issue
which
links
to
the
other
pull
requests.
I
should
have
just
linked
the
the
the.
A
This
name
is,
is
hard
coded
and
it's
used
to
create
a
service
account
for
each
control
loop,
so
that
effectively
means
that
the
the
name
you
know
is
you
can't
change
it
unless
you
duplicate
all
this
code
in
your
like
in
the
cloud
provider
itself,
and
that
means
you
can't
change
the
service
count,
and
then
you
can't
change
the
r
back
so
you're
stuck
with
the
r
back
that
that's
bootstrapped
by
default.
So
there's
like
a
couple:
different
control
loops
that
fall
under
the
node
controller
are
back
for
example.
A
A
The
pull
request
it's
I
there
was
a
couple
different
approaches
I
could
have
taken.
I
took
the
most
the
least
invasive
one.
There
was
some
talk
of
whether
I
should
try
to
change
like
the
generic
controller
generic
controller
manager.
Config,
you
know,
takes
a
list
of
controllers
and
change
that.
So,
instead
of
just
a
list
of
controllers,
it's
like
a
list
of
controllers,
plus
their
service
account
name.
That
would
have
been
a
pretty
big
change,
and
I
wanted
to
avoid
that.
A
So
this
this
basically
just
in
a
lot
of
places,
adds
a
client
name
to
some
of
these
init
functions
and
changes.
The
there's
like
these
init
funk
constructors
and
it
just
changes
those
to
include
a
client
name.
Those
can
be
overridden
from
the
cloud
provider.
So
if
you
look
at
what
a
cloud
provider
has
to
do
to
change
these
names,
if
I
get
the
right
yes,
this
one
so.
A
B
A
A
I'm
not
sure
what
or
how
you
would
do
that.
Maybe
you
can
explain,
but
let
me
just
say
that
this
was
motivated
by
I
don't
want
when
we
migrate
to
the
likes
when
eks
migrates
to
the
external
cloud
provider
I
want
to
have,
we
want
to
manage
our
own
rbac,
and
without
this
we
can't
do
that
unless
we
duplicate
a
bunch
of
the
utility
functions
into
our
cloud
controller.
A
B
B
I
get
a
service
account,
token,
that's
bound
with
a
different
audience,
and
then
I
do
some
fancy
exchange.
So
if
I'm
running
under
a
different
to
get
enough
to
get
an
aws,
I
am
token
or
a
token
value
with
aws
iam.
So
if
I'm,
if
I'm
running
under
different
kubernetes
service
accounts,
we
could
then
do
more
fine-grained
allocation
of
cloud
iam
as
long
as
those
are
genuine
kubernetes
service
accounts,
but
anyway
it's
it's
one
to
think
of
for
the
future.
I
guess.
Oh
so.
A
As
long
as
you
specify
dash
dash
use
service
account
credentials
which
we're
doing
right
so
but
there's
weird
stuff,
like
the
node
controller,
the
node
lifecycle
controller,
the
node
ipam
controller,
they
all
have
the
same
identity
and
we
can't
change
that
even
if
we
wanted
to
in
the
external
cloud
provider.
So
this
allows
us
to
change
that.
A
B
B
A
B
Cybrian
has
got
ipv6
working
on
aws,
I
think
with
calico
as
an
overlay,
but
this
is
sort
of
part
of
it
and
I
think
it's
ready
for
review.
I
think
angus
lees
gave
an
early
review
and
had
some
feedback,
and
I
think
cyprian
incorporate
incorporated
that,
and
so
it
now
has
lgtm
from
angus
and
I
think
it's
in
pretty
good
shape.
I
think
it's
basically
additive.
B
If
I
understand
correctly,
because
I
don't
imagine,
most
people
are
currently
running
with
ipv6
so
on
the
nodes
anyway
on
aws
address.
So
if,
if
if
we
are,
if
we
think
it's
good
it,
I
think
it's
a
good
unblocker.
I
think
I
would
love
to
see
more
than
just
calico,
but
I
think
it's
a
great
starting
point
got.