►
From YouTube: Kubernetes SIG CLI 20230503
Description
Kubernetes SIG CLI bi-weekly meeting on May 3rd, 2023.
Agenda and Notes: https://docs.google.com/document/d/1r0YElcXt6G5mOWxwZiXgGu_X6he3F--wKwg-9UBc29I/edit#bookmark=kix.11h01h1pxtb7
A
A
So
let's
go
into
the
next
section
of
our
meeting,
which
is
where
we
get
to
meet
the
new
members.
If
there's
anybody
who
is
new
or
hasn't
been
here
for
a
while
and
like
to
reintroduce
yourself
or
introduce
yourself
to
the
rest
of
the
Sig,
this
is
your
opportunity
and
of
course,
this
is
just
voluntary.
C
I
submitted
the
topic
to
discuss.
It
is
my
first
time
I
participate
in
the
meeting
and
in
this
sig
in
general,
I
work
for
a
Google
Cloud
as
a
developer
relation
engineer
and
use
and
in
the
past,
contributed
to
kubernetes
a
couple
of
times
glad
to
be
here
and
hope
for
a
productive
discussion.
Thank
you.
A
D
C
When
users
want
to
wait
until
the
service
receives
as
IP
address
and
right
now,
it
can
be
done
based
on
events.
It
can
be
done
based
on
the
state,
and
the
only
way
to
do
it
is
to
wait
by
validating
the
specific
Json
path,
status,
dot,
load,
balancer,
dot,
Ingress
and
IP
and
because
say
p
is
not
known
ahead.
Of
the
time
can
be
known.
C
A
A
D
E
In
the
Json
path,
Library
like
we
wouldn't
have
to
make
changes
within
the
library
we
just
split
the
thing
up
and
say:
if
there's
nothing
on
the
other
side
of
the
equal
sign
or
like
probably
shouldn't
make
it
nothing
like
there's
a
I,
don't
know,
we
would
have
to
figure
out
something
that's
meaningfully
unique
to
base
that
off
of
further
to
for
it
to
look
up
like
a
quote.
Unquote,
any.
C
C
Basically,
with
the
minimal
changes
it
is
as
I
mentioned,
it
is
basically
an
extension.
So
if
it
is
okay,
I
will
create
a
new
issue.
I
believe
that,
like
Reviving
The,
closed
issues
will
be
confusing
because
it
is
in
general,
a
separate
topic.
I
will
reference
this
issue
inside,
and
can
you
provide
the
guidelines?
What
should
come
next
after
the
issue
is
opened.
A
A
C
F
F
F
D
H
Yes,
so
we
discussed
this
in
last
community
meeting
I
asked
I
mean
I
want
to
add
announcement
in
the
qprint
helper.
We
have
one
callback
that
we
call
on
what
deleted
or
evicted
I
also
wanted
to
add
the
callbacks
for
when
the
deletion
eviction
started
or
when
it's
failed,
so
it
I
have
added
it
and
also
entered
the
test.
I
would
like
someone
to
review
it.
If
there
is
anything
that
need
to
be
changed,
I
can
I
can
improve
the
changes.
H
A
F
F
A
H
D
F
F
F
Another
one
I
was
hoping
that
Brian
would
be
here,
for
we've
talked
a
few
times
about
needing
to
rework
port
forward.
There's
tons
of
old
issues
that
are
brought
back
up.
I
tried
to
fix
a
bug
this
week.
I
have
an
open
PR
that
I
need
to
get
back
to
some
feedback
on,
but
the
I
think
what
we
wanted
to
discuss
was.
We
do
want
to
rewrite
port
forward
and
a
lot
of
that
old
library
code.
The
dependency
there
is
on
speedy
and
so
I
know
that
y'all
had
a
plan
to
start
switching.
F
A
D
A
Okay,
great
I
just
have
a
couple
of
slides,
so
I
know
for
myself.
Since
we
we're
in
the
coupon
code,
we
don't
really
get
to
see
a
lot
of,
or
at
least
I
don't
I'll
speak
for
myself,
a
lot
of
the
what
happens,
kind
of
in
the
back
end
and
and
some
of
our
commands
actually
are
reaching
all
the
way
into
the
Container
run
times,
and
so
what
I
was
gonna
show
was
since
we're
starting
an
effort
to
move
from
Speedy
to
websockets
was
a
couple
of
diagrams
about.
A
What's
going
on
for
some
of
our
Cube
cuddle
commands
that
are
using
these
bi-directional
streaming
protocols.
So
what
is
a
bi-directional
streaming
protocol
So
currently
kubernetes
is
using
Speedy.
We
hope
to
move
to
websockets,
since
it's
better
supported
and
at
a
very
high
level.
What
speeding
websockets
are.
They
are
you're
able
to
throw
arbitrary
streams
of
data
in
both
directions
instead
of
your
typical
HTTP
sender,
request
and
then,
once
you
look
at
that
request,
you
send
a
response.
A
These
bi-directional
streaming
protocols
allow
much
more
much
better
low
latency
for
for
a
bunch
of
different
applications
and
for
us
those
applications
are
I.
Put
the
commands
here,
like
Coupe,
cuddle,
exec,
cuddle
copy,
Coupe
cuddle
attach
or
the
aforementioned
Coupe
cuddle
port
forward,
and
so
this
particular
diagram
attempts
to
give
a
better
explanation
of
what
the
different
touch
points
are
when
we
do
a
coupe
cuddle,
exec,
usually
for
most
of
our
Coupe
cuddle
commands,
they
are
just
talking
to
the
API
server
and
the
API
server
is
responding.
A
In
this
case.
The
API
server
and
the
kublet
are
proxying.
These
commands
to
The
Container
runtime
and,
as
you
can
see
on
the
bottom,
there
is
for
the
container
runtime
interface.
There
is
an
ad
hoc
server
created
on
the
container
runtime
by
doing
a
call
to
The
Container
runtime
interface
called
get
exec
on
a
particular
node
or
on
a
particular
container
runtime,
and
then
it
proxies
again
using
Unix,
sockets
and
and
actually
grpc
in
between
the
the
kublet
and
the
container
runtime.
A
That's
being
communicated
over
this
connection,
that
we
call
remote
command,
which
unsurprisingly,
allows
us
to
run
a
command
on
a
container
on
one
of
the
nodes
and-
and
it
turns
out
that
we
Multiplex
the
the
standard,
input,
standard
output
and
standard
error
onto
this
one
connection
and
then,
on
the
other
end.
I
try
to
illustrate
that.
Actually,
these
the
the
data
that's
coming
in
on
standard
input
is
actually
connected
to
the
standard
input
on
that
on
that
container
and
the
same
for
the
standard
output
and
the
standard
error.
A
A
And
so
how
is
it
that
we
we
get?
This
connection
since
you
know
the
we
have
a
rest.
Api
for
for
kubernetes
well
are
are
1.1
request
that
we
send
is
actually
upgraded
to
this
streaming
protocol,
and
this
is
what
this
HTTP
request
and
response
look
like
so
for
for
kubernetes
and
the
the
purple
here
is
the
exact
sub
resource,
meaning
that
we're
we're
doing
an
exec
command
and
the
exact
exact
command
is
actually
one
of
the
query
parameters.
A
So
the
two
most
important
headers
are
the
connection
upgrade
and
what
what
bi-directional
streaming
protocol
that
we're
going
to
upgrade
to
and
then
in
the
in
the
reddish
pink,
are
the
possible
versions
that
we
can
negotiate
for,
for
which,
which
versions,
The
Speedy
server
on
the
container
understands
and
that
server.
If
it's
successful
it's
going
to
send
and
you
can
see
in
the
blue,
it
sends
a
a
101
switching
protocols
with
another
hat,
with
the
same
header
of
the
upgrade
Speedy
3.1
and
It
The
Chosen
version
of
the
protocol.
A
A
So
this
talks
about
why
we
want
to
transition
from
Speedy
to
websockets,
which
I'm
not
going
to
go
too
deeply
into
here,
but
it's
it's
basically
that
Speedy
has
been
deprecated
for
many
many
years
and
and
websockets
is
the
only
bi-directional
streaming
protocol.
That's
that's
even
really
supported
anymore,
and
so,
if
you
have
any
intermediaries,
like
proxies
or
L7,
load,
balancers
or
gateways,
they
have
to
speak
this
protocol.
A
Okay.
So
this
is
a
diagram
showing
how
we,
how
we're
going
to
attempt
to
or
how
we
are
attempting
to
address
the
transition
and
basically,
what
we're
trying
to
do
is
just
do
web
sockets
from
the
client
to
the
API
server.
Since
that
solves
our
problem,
and
then
we
don't
want
to
really
touch
all
the
rest
of
the
elements
or
components
in
the
system.
A
In
our
cluster,
because
that's
going
to
be
that's
going
to
really
be
difficult
to
to
move
to
get
out,
since
we
would
have
to
basically
change
all
the
different
container
runtimes,
which
is
where
this
bi-directional
streaming
protocol
is
terminated,
and
so
instead,
what
we
want
to
do
is
that
the
API
server
have
a
proxy
that
is
going
to,
and
we've
already
got
a
a
proof
of
concept
of
this.
We
terminate
the
websockets
and
all
of
the
data.
A
All
of
these
channels
that
are
that
are
received
at
the
websocket
server
are
then
thrown
onto
a
speedy
client,
which
is
communicating
Upstream
the
same
way
it
was
before
so
we
we
already
have,
if
you're
interested
in
looking
at
it,
this
particular
PR
as
a
work
in
process.
We
have
the
stream
translator
proxy
working.
These
are
examples
of
some
of
the
exact
commands
and
copy
commands
that
are
working,
and
so
that's
actually
I
think
I've
spoken
quite
a
bit.
A
F
A
A
So
so,
I,
don't
know
why
that
that
is
the
case
because
HTTP
like
I,
said
http
2.0
is
Speedy
basically,
and
you
would
think
that
it
would
be
very
easy
to
access
the
functionality.
That's
already
there
for
this
bi-directional
streaming
and
it
it's
not.
It's
actually
yeah
I,
don't
I
and
I.
Honestly,
I
don't
know,
and
maybe
there's
something
that
I'm
missing,
but
when
I,
when
I
present
I'm
gonna
actually
present
this
and
a
little
bit
more
at
the
API
Machinery
meeting
in
an
hour
and
a
half
I.
F
G
F
A
And
so
one
of
one
of
the
commands
that
we
use
this
remote
command
sub
protocol
with
is
Coupe
cuddle
copy
and
could
cuddle
copy
is
not
its
own
sub
resource,
it's
actually
and
and
I
think.
Maybe
a
lot
of
us
have
already
seen
this.
If
you
do
a
copy,
it
actually
just
runs
an
exec
where
the
command
is
tar,
and
so
this
is
why
you
can't
do
a
coupe
cuddle
copy.
A
A
G
G
A
A
So
so,
during
this
exercise,
I
initially
had
the
opportunity
to
kind
of
dig
into
the
Container
run
time,
because
that's
where
the
speedy
and
the
websockets
initially
would
have
been
terminated
and
so
I
I
had
some
had
some
fun
digging
into
some
areas
that
I
don't
usually
get
to
dig
into.
And
of
course,
then
we
we
realized
that
actually
trying
to.
A
If
the
servers
on
the
container
runtime,
then
we'd
have
to
change
every
single
container
runtime
like
container
D,
cryo
and
all
of
them
before
we
could
actually
get
this,
and
so
it
was.
We
wanted
to
reduce
the
scope
of
of
this
effort
to
get.
You
know
most
of
what
we
needed
by
just
translating
the
websockets
to
Speedy
at
the
API
server.
D
F
A
So,
all
of
so
it
turns
out
there's
actually
web
search,
websocket
code
already
through
littered
throughout
the
system
and
it's
all
the
the
standard,
Library
websocket
stuff.
So
we
and
the
proof
of
concept
PR
that
that
we
based
this
on
that
Mikhail
Missouri
created,
he
used
the
gorilla
websockets
Library.
A
As
you
said,
it's
the
best
best
supported,
or
at
least
until
a
couple
months
ago
was
the
best
supported,
and
even
this
the
go
standard,
Library
websockets
said:
go
use
the
gorilla
websockets
and
that's
not
the
case
anymore.
So
so
there
is
you're
right.
There
is
a
big
question
as
to
what
library
and
this
Library
does
the
framing
and
has
control
frames.
You
know,
but
basically
we
shouldn't
be.
A
You
know
we
should
we
don't
have
any
visibility
as
to
how
it's
Framing
and
sending
these
arbitrary
length
messages.
It's
just
like.
It
goes
in
one
end
and
comes
out
the
other,
and
we
get
to
to
say
what
that
data
means.
But
how
it's
being
transmitted
you
know
is
is
part
it's
an
RFC
but
there's
multiple
libraries
which
have
implemented
this
websockets
RFC
and-
and
it's
actually
not
clear
which
one
to
use
right
now.
A
F
A
G
Yeah,
but
he
gets
logs,
doesn't
necessarily
need
bi-directional.
Although
x-off
Exotics
off
might
help
a
bit,
I
would
explain.
We
have
a
cluster,
that's
a
bit
unhealthy
and
we're
getting
eofs
from
Cooper
to
logs,
but
not
from
anything,
that's
going
via
the
Speedy
connection,
so
that
one.
Maybe
that
would
be
hard
to
explain
that
very
interesting.
A
Since
this
issue
has
been
going
on
for
eight
years,
it's
kind
of
hard
to
to
get
your
mind
around
all
of
it
and
so
I've
put
in
tons
of
Links
at
the
bottom
for
the
issues
and
the
PRS,
and
also
some
explanations
and
some
diagrams
on
what
this
this
means,
and
so
hopefully
this
this
document
will
will
be
able
to
be
the
one
place.
You
need
to
go
to
to
know
about
this
particular
issue.