►
From YouTube: Kubernetes - AWS Provider - Meeting 20210430
Description
Recording of the AWS Provider subproject meeting held on 20210430
Discussion: cloud provider extraction effort update, adding feature gate to disable cloud provider to all components, Sigv4 pre-kep, discussion of https://github.com/kubernetes/kubernetes/pull/101592, discussion of https://github.com/kubernetes-sigs/aws-load-balancer-controller/pull/1948 (PrivateLink support for aws-load-balancer-controller).
B
B
We
have
alpha
releases,
for
I
think,
starting
at
118
up
through
1
20
and
working
on
121
and
then
also
trying
to
get
what
we'll
call
beta
releases
out
as
soon
as
possible
for
all
of
those
versions
in
the
next
month.
I'm
hoping,
I
think,
the
the
effort
that
we're
working
on
right
now
with
that.
I
am
looking
into
a
feature
that
was
just
recently
added
to
entry,
which
is
the
leader
migration
feature.
B
So
that's
something
that
that
you
know
eks
needs
for
for
allowing
clusters
to
upgrade
from
a
single
kcm
to
a
kcm
plus
ccm
with
different
leaders,
and
it's
just
some
configuration
basically
and
then
another
piece
to
that
same
repository
is
the
credential
provider
or
yeah.
The
cubelet
credential
provider,
I
think,
is
what
we
call
it.
So
that
is
something
that
a
brick
has
been
working
on
a
lot
where
we
have
an
implementation
of
it
and
he
is
currently
adding
some
type
of
binary.
B
I
think
he's
we're,
starting
with
just
a
github
release
that
can
be
downloaded
and
that
would
go
on
the
worker
nodes
so,
for
example,
eks
the
eks
worker
node
army
is
going
to
have
to
include
that
binary,
along
with
some
configuration
that
cubelet
respects,
which
will
take
the
place
of
the
code.
That's
currently
inside
cubelet
that
provides
the
the
ecr
image
credentials
same
for
cops.
B
B
B
What
was
previously
the
admission
controller,
which
is
now
the
persistent
volume
labeler
controller
has
some
aws
and
google
specific
code
in
it,
and
I
believe
we
need
to
decide
how
to
replace
that.
I
did.
I
did
miss
that
meeting,
so
I
don't
know
the
specifics.
I
need
to
to
re-watch
that
one
andrew.
Do
you
happen
to
want
to
to
update
on
that.
C
C
B
So
that's
all
I
can
think
of
off
the
top
of
my
head
in
terms
of
where
we
are.
I
think
the
timeline
is
getting
tighter.
I
you
know,
I
think
that
the
most
reasonable
first
possible
date
for
actually
I
don't
think
it'll
happen
this
early,
but
actually
taking
cloud
better
code
out
of
up
tree
is
probably
like
124.,
so
the
schedule
is
is
now
coming
out
for
122..
B
C
It's
going
to
be
called
like
disable
cloud
provider
or
something
like
that
and
obviously
it'll
be
introduced
with
alpha
and
off
by
default
and
at
some
point
we're
going
to
flip
that
feature
gate
to
beta
which
will,
by
default.
Like
turn
off
the
cloud
provider,
and
by
turn
off
I
mean,
if
you
ran
a
core
component
with
the
cloud
provider
flag
set
to
anything,
that's
not
external,
then
the
process
just
like
exits
early
in
the
dive
and
so
like
that,
hopefully
like.
That
is
the
strongest
signal
we
can
give
to.
C
Users
like
please
migrate
off
to
the
out
of
tree,
and
but
they
still
have
the
option
and
I'm
sure
most
of
them
will
just
go
with
this
option.
But
they
still
have
the
option
to
flip
the
feature,
gate
off
explicitly
and
continue
to
run
the
the
entry
provider
and
then
at
some
point
we
flip
the
feature
gate
to
ga,
lock
it
and
then
that's
when
they
have
to
migrate.
C
But
the
idea
is
that
that
switch
to
beta
is
going
to
be.
Like
the
you
know,
it's
it's
the
it's
the
it's
like
the
the
best
warning
we
can
give
because
users
and
then
at
that
point
it's
kind
of
like
you
know,
it's
your
fault.
You
know
migrate
off
and
I
think,
like
maybe
hope
I
guess,
like
the
intention
of
teaching,
was
that
it
puts
more.
C
It
makes
the
whole
like
removing
cloud
provider
disabling
it
more
concrete,
and
we
can
just
look
to
the
future
gate
like
when
the
gate
or
target
when
the
feature
gate
goes
beta
and
j,
and
look
at
that
as
like
the
release
timeline
for
when
we're
gonna
really
cut
the
tie
off
and
that
also
decouples,
like
removal
of
the
functionality
from
removal
of
the
coded
film
right
like
we,
don't
necessarily
have
to
remove
the
code
in
the
same
release.
We
disable
it.
We
can
turn
it
off
for
free
releases
and
then
remove
the
code.
B
B
B
So
for
the
the
kept
that
we
were
talking
about
before
we
started
recording,
I
don't
think
necessarily.
We
need
to
rehash
it
here.
I
will
just
add
to
the
agenda
and
mention
it
and
and
if
if
people
are
interested,
they
can
go
watch
there's
the
conversation
in
sigoth
earlier
this
week,
but
just
as
a
quick
summary,
it's
a
a
feature,
that's
interesting
to
eks,
because
it
allows
sig
v4
on
the
client
side
for
kubernetes
sig
v4
is
the
amazon
aws
method
of
basically
authenticating
requests.
B
So
it's
a
it's
a
request.
Signing
mechanism
the
implementation
is
still
being
debated,
but
what
has
been
mostly
agreed
upon
amongst
sigoth
is
a
extension
to
the
existing
exec
feature
in
glanco,
where
in
this
case
a
binary
would
be
exact
and
it
would
return
a
unix
domain,
socket
path
or
a
port
for
use
on
localhost,
which
would
then
be
communicated
to
by
clanco.
So
all
of
the
requests
would
be
sent
to
that.
B
That
would
be
a
proxy
and
there
there
would
have
to
be
that
proxy
that
localhost
proxy
would
have
to
obey
existing
proxy
settings.
So
you
have
you,
have
this
little
bit
of
ch?
You
know
if
you
already
have
a
proxy
set
up.
You
have
some
kind
of
chaining,
but
the
idea
is
that
that
that
whatever
is
listening
on
that
unix
domain,
socket
or
port
is
going
to
do
this.
The
request
signing
and
then
it's
going
to
send
the
request
on
to
the
api
server.
B
There's
already
a
feature
for
a
front
proxy
in
front
of
the
api
server
to
do
any
kind
of
custom
validation
that
you
that
people
need.
So
we
don't
really
need
to
solve
that
that
side
of
it.
It's
really
just
the
client
side.
That
needs
something
yeah
so
I'll,
link
that
in
the
agenda
and
if
people
are
interested,
they
can
just
go
watch
the
sigoth
update.
D
E
D
Yeah
so,
for
example,
if
I
wanted
to
like
yeah
this
is,
I
definitely
watch
that
because,
for
example,
if
I
wanted,
we've
had
a
long-standing
issue,
for
example,
to
have
multiple
ip
addresses
right,
be
supported
in
like
for
in
client,
go
like
now.
You
could
do
it
with
this
plugin
or.
If
I
wanted
to
say,
I
want
to
auto
dial
my
api
server
over
the
only
vpn
wire
guard,
then
I
could.
I
could
do
that
sort
of
thing
now,
right,
yeah,.
A
B
B
B
B
H
C
H
E
B
B
H
H
A
C
B
B
B
H
F
H
D
H
Yeah
subnets
also
doesn't
get
updated
for
the
entry
controller
so
like
we
only
specify
during
creation,
and
we
stick
with
it
and
and
nlps
have
sometimes
they
have
like
a
temporary.
I,
I
have
always
seen
the
temporary
limitation,
but
it
prevents
updating
the
subnets
after
creating.
We
can
enable
additional
aegs,
but
we
cannot
change
the
subnets,
like
I
always
see
in
my
console,
so
it
says
temporary
limitation,
but
something
that
we
might
have
to
be
aware
of
for
these
type
of
things.
B
G
B
Okay,
this
one
I
created
just
wanted
us
to
kind
of
have
something
public
in
either
this
repo,
the
load,
bouncer
controller,
repo
or
both
just
kind
of
telling
users
what
we're
doing
and
based
on
what
we've
talked
about.
I'm
you
know
sort
of
making
the
assumption,
we're
moving
nlp
functionality
to
load
monster
controller,
and
you
know
maybe
we
do
some
kind
of
either
through
just
documentation
or
through
you
know,
a
helm,
chart
a
unifi,
unified
installation
method
so
that
users
can
go
to
one
place
and
just
install
both
of
these.
B
It's
maybe
that,
and
maybe
that's
a
bad
idea.
I
mean
you
know
you
might
get
the
the
ccm
through
your
installer
and
you
maybe
you're.
Looking
for
the
you
know,
I
don't
know
how
you
know:
we're
probably
not
going
to
be
able
to
meet
all
use
cases
here,
but
if
you're
using
at
least
eks
it's
done
for
you
if
you're
using
cops,
it
should
be
very
easy
to
configure
these.
H
H
H
B
Yeah
definitely
I'm
thinking.
One
thing
we
could
do
similar
to
what
we're
doing
upstream,
with
cloud
provider
is,
is
introduce
a
feature
gate
in
ccm
that
disable
at
some
point
disables
nlb
functionality
here
so
they'd
have
to
go
and
re-enable
it,
and
we
can
provide
some
some
message
there
saying
you
know
this
functionality
and
this
controller
is
no
longer
supported.
You
should
move
to
the
load,
balancer
controller.
H
E
A
B
For
the
foreseeable
future,
next
couple
releases
we
will
have
code
in
the
legacy
cloud
provider
location.
So
there's
some
bug
fixes
go
there
and
then,
if
they,
if
they
do,
go
there,
we'll
need
to
try
to
pick
them
back
to
this,
and
I
was
just
thinking
like
well.
You
know
we
could
maybe
import
this
repo
into
legacy
cloud
provider
which
we
were
originally
doing,
the
opposite.
B
And
walter
said
this
repo
imports
parts
of
staging,
so
we
it's
not
safe
to
import
it
into
any
of
the
kk
public
repos.
I
do
not
see
it
importing
anything
from
kk
private
as
long
as
that
remains
true.
I
think
it
should
be
safe
to
import
in
kk
private,
so
I
don't
know
how
important
that
is.
Maybe
we
just
deal
with
cherry
picking
for
now,
because
it
it's
not
going
to
last
forever
so.
H
H
H
B
B
H
H
A
H
D
H
So
here
is
the
thing,
though,
remember
like
we
did
some
entry
fix
for
eks119,
where
they
can
specify
subnet's
annotation
to
choose
the
subnet
they
want.
So
that's
gonna
save
them
here.
So
we
should
mention
that
so,
rather
than
adding
additional
intelligence
to
our
code,
we
should
just
ask
them
to
use
the
annotation
and
they
should
give
it
a
functional
organization.
H
H
B
H
H
A
B
H
So
when
we
create
the
subnet,
we
no
longer
add
the
tag.
So
we
proportionately
for
that,
we
fix
the
entry
provider
to
not
look
at
the
cluster
tag
as
well.
I'll
give
you
the
pr
okay
and
then
you
can
see
if
a
cloud
provider
aws
has
that
fixed.
I
see
the
fixed
in
the
code,
but
I
don't
know
the
code
flows
exactly
to
make
any
further
comment.
H
B
D
So
I
have
a
question:
the
the
it
sounds
like
the
long-term
direction
is
to
get
to
a
much
richer
model
for
load.
Balancers.
Is
that
right
in
the
aws
load,
balancer
controller
project,
article
correctly
and
which
has
like
effectively
like
crds
for
everything?
So
you
can
specify
all
these
things,
and
we
have
less
magic
logic
is
that
is
that
right.
G
D
G
The
answer
gateway
api,
so
it's
a
new
model
for
services,
so
we
plan
to
support
that
as
well.
So
internally
we
kind
of
have
a
crd,
I
mean
kind
of
necessarily,
but
you
memory,
which
is,
I
mean,
specify
all
attributes
and
we
translate
the
invoice
mode
or
service
model
into
our
internal
model
and
then
we
operate
on
the
interface.
So
if
we
support
other
apis
like
the
new
api
introduced
by
google,
we
can
just
write
a
translation
layer
which
translate
their
gateway
api
into
our
internet.
D
That
makes
sense,
I
I
I
think
they
also
even
before
adding
an
official
api
added
a
like
additional
crd.
I'm
gonna
try
to
find
the
docs
for
that,
because
it's
a
nice
trick
to
still
support,
still
support
custom
features
without
having
to
do
as
much
without
having
to
get
everything
into
the
core
apis
or
I'll
paste.
The
link.
G
Yeah,
so
this
one,
so
we
didn't
chunk
the
api
when
we
turned
targets
into
nlp.
So
if
we
have
900
targets,
this
900
target
will
be
registered.
At
the
same
time,
however,
the
elb
side
they
will,
they
might
re,
reject
targets.
I
mean
you
know,
I
mean
too
many
targets
in
a
single
call.
I
mean
the
behavior
country
is
unspecified,
so
if
they-
and
if
that
happens,
they
will
reject
the
registrar,
call
infinitely
and
and
they
will
throw
to
the
customer.
So
I
made
a
pair
to
fix
it
by
reaches
targets.