►
Description
Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Kubernetes SIG CLI: Intro and Updates - Eddie Zaneski, Amazon Web Services; Katrina Verey, Apple; Sean Sullivan, Google
SIG CLI is the special interest group for the command line tooling of the Kubernetes project. The SIG maintains kubectl, kustomize, and related libraries. In this session the SIG CLI leads will provide an introduction to the SIG and an overview of how to contribute including how kubectl is built and tested. They will share the work that's been done the past year and discuss several current and future Kubernetes Enhancement Proposals (KEPs). The session will conclude with open discussion and Q&A.
B
So
what
is
sig
cli?
What
are
we
here
to
talk
about,
as
the
name
suggests?
We
focus
on
the
client
side
tooling,
but
6dli
doesn't
mean
that
we
own
every
conceivable
cli
that
has
every
something
to
do
with
kubernetes.
That
would
be
a
ton
of
stuff
and
pretty
crazy.
What
we
focus
on
is
more
development
and
standardization
of
the
cli
framework
and
its
dependencies,
as
well
as
the
establishment
of
conventions
for
running
cli
commands
and
standards
such
as
posix
compliance.
B
We
also
want
to
improve
command
line
tooling
from
a
developer
and
devops
user
experience
and
usability
perspective.
That
said,
we
do
own
some
specific
code
and
some
specific
command
line
tools.
Some
of
them
you
may
have
definitely
heard
of
before,
such
as
keep
cuddle
and
customize
and
crew
crew,
it
being
the
plugin
framework
for
cubepedal.
B
B
Our
meetings
are
every
single
wednesday
bar
and
cancellations
at
9
a.m,
pacific
time-
and
they
alternate
between
a
normal
sig
meeting,
where
we
have
an
agenda
that
anyone
can
bring
the
items
for
discussion.
So
you
just
go-
and
you
add
your
item
to
the
google
doc
and
we'll
all
be
happy
to
talk
to
you
about
it
and
the
on
the
alternating
weeks.
We
have
a
bug
scrub
and
the
bug
scrubs
themselves
alternate
between
being
focused
on
customized
and
being
focused
on
cube
cuddle.
B
The
first
thing
that
we
want
to
do
today
is
walk
you
through
some
of
the
enhancements
that
we
have
in
progress
with
six
cli
I'll.
Let
you
know
the
status
updates
about
each
one
and
the
first
one
I
want
to
bring
up
is
kept
2775,
which
is
cube,
pedal
delete
protections.
So
this
is
a
very
new
cap.
It's
still
in
the
discussion
phase,
there's
a
discussion
actually
both
on
the
kep
itself
and
on
that
sig
cli
mailing
list
that
I
mentioned
so
go
check.
B
B
The
second
idea
that
we
have
is
for
certain
versions
of
the
cube
cuddle
sleep
command
that
have
an
inherently
large
blast
radius,
so
the
all
and
all
name
spaces
flag.
We
want
to
add
a
artificial
delay
to
the
command
for
a
certain
number
of
seconds
and
that
will
emit
sort
of
a
warning
telling
you
that
we're
about
to
perform
this
very
destructive
operation,
to
give
you
a
chance
to
abort,
if
that's
not
actually
what
you
intended
to
do
so
again.
B
This
is
a
provisional
cap,
there's
a
discussion
in
the
kep
and
on
the
mailing
list
and
we're
seeking
feedback
on
that.
So,
if
you're
interested
please
get
involved,
the
next
cup
I
wanted
to
touch
on
is
q
pedal
debug.
This
one's
been
implemented
for
a
while,
but
it
has
a
new
feature
called
debugging
profiles
that
I
want
to
highlight.
B
This
new
feature
provides
more
configurability
for
generated,
pods
and
containers
that
the
ones
that
are
created
by
the
cube
pedal
debug
command,
making
it
more
useful
in
certain
use
cases.
For
example,
if
you're
debugging
a
node,
you
might
want
your
pod
to
be
created
with
the
net
admin
capability.
Well,
now
you
can
do
that
by
passing
profile
equals
net
admin.
B
Next
up
is
server
slide
apply.
This
one
is
very
exciting.
It's
graduated
to
ga
and
release
122.,
it's
still
not
on
by
default.
There's
an
ongoing
discussion
about
when
and
how
to
do
that.
But
if
you
just
add
that
server
side
flag,
you
will
to
your
reply
command,
then
you
will
be
using
it,
and
I
highly
recommend
that
you
do
part
of
the
point
is,
as
the
name
applies,
to
move
the
implementation
from
the
client
side
to
the
server
side,
so
that
cube
cuddle.
B
With
this
change,
it
also
fixed
a
number
of
bugs
that
weren't
possible
to
fix
in
the
client-side
implementation,
so
there's
some
inherent
advantages
to
switching
over
and
it
introduces
this
new
concept
of
field
ownership
that
allows
multiple
apply
actors
to
collaborate
better
on
the
object's
state,
so
they
can
basically
claim
ownership
of
a
certain
field
and
if
another
actor
attempts
to
take
ownership
of
that
field
as
well
will
generate
a
conflict
so
that
it
won't
it
won't
thrash
anymore.
You'll
actually
have
a
proper
conflict
detection.
In
that
scenario,.
B
Next
up,
we
have
cube
cattle
command
metadata
and
http
request
headers.
Now
this
one
is
adding
a
bunch
of
metadata
to
http
headers
about
the
command
that
you
are
running
with
q
pedal,
so
this
one's
in
beta
as
of
release
122.,
and
it
gives
you
more
insight
into
what
cube
cuddle
commands
are
being
run
against
your
cluster,
make
connecting
those
dots
between
the
user
actually
running
a
command
and
the
request
that
you
end
up
seeing
on
the
api
server.
This
is
a
step
towards
getting
telemetry
on
cue
pedal
usage.
B
B
Specifically,
we
have
the
customized
plug-in
composition,
api
kept
that
one
is
the
simplest
and
it
is
already
moved
to
implementable,
and
then
we
have
the
plug-in
catalog
kept,
which
is
one
of
the
key
features
that
is
going
to
enable
that
plug-in
distribution,
discovery
and
trust.
That
I
mentioned,
and
finally,
we
have
the
krm
functions
register
cap,
which
is
proposing
a
sig
sponsored
implementation
of
of
a
catalog
of
catalog
generation,
so
that
would
result
in
a
sub
project
if
approved
so
that
that's
pretty
exciting.
B
Last
but
not
least,
we
have
kept
2950,
which
is
adding
sub
resource
support
to
cube
pedal.
This
one
would
add
a
new
flag
so
that
commands
like
get
passion
edit
and
replace,
can
deal
with
sub-resources
like
status
and
scale,
which
is
not
possible
today,
we're
targeting
alpha
for
release
123
with
this
feature,
and
with
that
I'm
going
to
hand
it
over
to
eddie
to
tell
us
about
building
and
testing
cue
pedal,
cool.
A
So
we're
going
to
run
through
this
a
bit
because
we
definitely
want
to
have
lots
of
time
for
questions
and
conversations
at
the
end,
so
cube
control
is
what
we
consider
a
staging
repo,
so
this
originally
lived
inside
of
the
kubernetes
kubernetes
main
repo.
We
call
this
kk,
so
cube
control
code
lives
in
kk
currently,
but
we
are
actively
trying
to
migrate
it
out,
and
this
has
been
the
progress,
the
process
of
a
lot
of
awesome
folks
over
the
past
couple
years.
We're
actually
super
close.
A
I
think
we're
trying
to
target
124
where
we
can
release
inversion,
cube
control
independently,
which
would
be
awesome.
We
don't
actually
take
prs
directly
to
cube
control.
They
all
need
to
be
made
against
kubernetes
kubernetes
directly,
but
we
do
like
to
consolidate
our
issues
there
so
to
build
cube
control.
You
just
simply
run
make
cube
control
at
the
root
of
kk
testing
cube
control.
We
have
a
few
different
types
of
testing
unit
tests
and
tests
and
integration
tests
unit
testing
is
very
straightforward.
These
are
your
standard
go
unit
tests.
A
A
The
quick
thing
to
note
is
that
these
will
run
very
quickly
and
do
not
require
a
cluster
at
all
configured
on
your
server,
so
they're
completely
offline.
So
these
are
the
ones
you're
going
to
run
normally
during
testing,
and
if
you
make
a
pr
that
just
makes
a
change
to
a
command
and
doesn't
have
a
unit
test,
I
will
most
likely
ask
you
to
add
one.
So
thank
you.
A
The
end-to-end
test
suite
is
what
we
run
on
our
periodical
tests.
This
tests
kubernetes,
I
mean
cube
control
against
a
active
kubernetes
cluster.
So
you
do
need
a
cluster
to
test
this,
so
you
can
either
use
a
kind
locally
or
have
a
remote
test
cluster.
The
tooling
will
also
help
you
spin
this
up
and
build
one.
This
is
built
using
ginkgo,
which
is
a
behavioral
driven,
go
test
framework,
so
first
you
gotta
make
ginkgo.
A
Then
you
have
to
compile
the
end-to-end
test
suite
and
then
you
have
to
run
this
nice
lovely
long,
ginko
command
again,
there's
like
a
cube
test
command
that
kind
of
hides
some
of
this,
but
this
is
usually
what
I
just
find
in
my
bash
history
and
run
and
change
the
name
of
the
test,
I'm
trying
to
target.
So
last
we
have
our
integration
tests.
These
are
our
bash
tests.
This
will
try
to
spin
up
a
cluster.
It
will
fail
if
you're
on
a
mac
so
usually
have
a
local
cluster
configured.
A
C
You
know
what
you're
currently
applying,
but
somehow
we
also
have
to
specify
what
had
previously
been
applied
and
between
using
those
two
sets
we're
going
to
calculate
what
we
no
longer
need
and
that's
called
the
prune
set,
and
so
you
can
see,
I
put
a
little
set
algebra
up
there
with
a
prune
set.
The
way
this
is
calculated
is
the
previously
applied
objects
that
are
no
no
longer
that
are
being
applied
currently
or
subtracting.
Those
are
going
to
be
the
objects
that
we
want
to
delete
that.
D
C
Okay-
sorry
about
that,
so
so
this
is
a
very,
very
simple
example
of
pruning.
So
if
we
have
an
initial
apply
and
we're
only
applying
two
resources,
we're
applying
a
and
b
and
then
subsequently,
when
we're
pruning,
we
apply
b
and
c.
You
can
see
on
the
third
image
on
the
bottom.
What
we've
calculated
as
a
prune
set
is
what
we
are
not
currently
applying,
but
we
had
previously
applied,
which
is
item
a
and
so
we
prune
or
automatically
delete
that.
So
what
does
that
command?
Actually
look
like?
C
Well,
first,
it
wouldn't
be
a
real
presentation
unless
I
showed
you
some
yaml,
so
I've
highlighted
the
name.
So
this
is
basically
just
two
config
maps
cma
and
you
can
see
that
they've
got.
They
both
have
the
label
cm
label
app
colon
cm
label
and
the
second
apply
is
going
to
be
this.
These
two
config
maps
b
and
c,
and
here's
where
the
rubber
meets
the
road.
C
Now,
here's
where
we
get
into
pruning
so
the
second
apply,
which
has
b
and
c
we're
going
to
add
the
minus
minus
prune
flag
and
somehow
someway
we
have
to
specify
what
we
had
previously
applied
and
the
way
we
do
that.
Simply
in
this
instance
is
we
say
minus
we
say
the
labels
of
app
equals,
I'm
sorry
app
equals
cm
label.
C
Okay,
so
there's
there's
more
flags
that
have
to
do
with
pruning
and
I've
brought
up
this
prune
whitelist
flag,
which
specifies
the
group
version
kinds
which
we've
restricted
the
items
which
can
be
pruned,
and
in
this
case
I've
said
well.
The
gbk
should
be
config
maps.
So
it's
actually
going
to
output
what
we've
done
before.
C
C
Okay,
so
now
we're
going
to
go
over
some
drawbacks
and
there
are
some
significant
drawbacks.
This
is
actually
you
know
if
you're
deleting
objects,
this
is
dangerous
functionality
and,
if
you're
doing
it
with
by
specifying
resources
in
a
label
retrieval
there
are
some
serious.
You
know
there
could
be
some
serious
consequences
and
I've
done
it
myself.
I've
actually
inadvertently
pruned
or
deleted
objects,
because
there
were
extra
objects
that
had
this
label
that
I
didn't
realize
that
ended
up
getting
pruned.
So
you
have
to
be
careful.
C
Okay,
so,
finally,
there
are
corner
cases
with
specifying
namespaces
when
you're
pruning,
so
if
you're
applying
into
a
brand
new
namespace
and
you're
attempting
to
prune
objects
in
a
previous
namespace,
if
none
of
the
objects
that
you're
applying
now
were
are
in
that
previous
namespace
pruning
doesn't
work.
So,
as
you
can
see,
there's
some
serious
drawbacks.
In
fact,
coupe
control
apply
prune,
is
in
alpha
and
has
been
in
alpha
for
many
years.
A
A
We
want
to
refactor
our
cube
control
commands,
so
they
do
not
directly
depend
on
cobra
as
a
library,
so
right
now
take
apply.
For
example,
the
apply
command
takes
in
a
cobra
command
struct.
To
actually
do
anything,
we
want
to
pull
that
out
and
we
want
people
to
actually
consume
the
command
code
as
a
library.
So
if
you
want
to
use
apply
inside
of
your
application,
we
want
you
to
be
able
to
do
that
without
using
cobra.
A
So
we
have
a
few
reworks
of
what
we've
thought
that
looks
like
this
will
be
a
great
place
for
new
first
issues
once
we're
ready
to
get
started
so
start
joining
us
in
the
sig
meetings.
Please
another
one
is
how
we
better
handle
flags.
This
one
comes
up
very
often
cube.
Control
create
is
a
very
imperative
type
of
command,
specifically
with
how
we
pass
flags
to
the
for
the
resource.
A
So
users
want
every
single
flag
possible
for
every
single
component
of
the
resource
to
be
able
to
be
passed
on
the
command
line
and
that's
very
hard
to
maintain
taking
structured
data
and
turning
that
into
command
line.
Flags
is
very,
very
difficult.
It's
not
something
we
want
to
do
so.
We
don't
have
a
solution
for
this,
yet
the
community
wants
support
for
it,
so
we're
kind
of
at
a
stalemate
where
we
don't
know
what
to
do.
So.
A
If
you
have
ideas
or
suggestions,
please
let
us
know
we
want
to
support
folks
that
have
valid
imperative
use
cases,
but
at
the
end
of
the
day,
kubernetes
is
supposed
to
be
a
declarative
driven
system.
So
give
us
your
ideas,
please
cube.
Control
performance
is
something
that
we
need
to
dive
into
at
some
point
when
you're
talking
to
very
large
clusters
the
memory
usage
balloons,
because
we
go
from
json
to
yaml,
then
back
to
json,
then
to
like
ghost
trucks
and
there's
a
lot
of
serialization
in
conversion.
A
That
happens
because
go
is
a
strictly
type
language
without
generics.
Yet
right
and
kubernetes
is
a
very
typed
type
of
api
operation,
so
there's
a
ton
of
serialization.
So
if
anyone
is
a
a
an
expert
when
it
comes
to
profiling
go
applications,
we
could
definitely
benefit
from
your
help
so
feel
free
to
swing
by
and
let
us
know
we'd
love
to
get
that
down
at
some
point
and
new
contributors.
A
We
love
welcoming
new
contributors
to
our
community,
great
new
contributors
sitting
over
here,
newgrad
very
active
in
the
community,
so
whether
you're
a
student
you're,
a
professional
developer,
we
love
having
you
come
by
tube
control,
is
a
very
difficult
code
base
to
jump
into
it's
just
the
unfortunate
nature
of
everything
cube
control
touches
is
inside
of
kubernetes
for
the
api
servers,
so
there's
a
lot
of
different
types.
We
definitely
need
help
solving
some
other
problems,
but
it
is
a
difficult
cold
base.
But
if
you
are
dedicated,
you
really
want
to
learn.
A
B
Of
course,
cube
pedal,
isn't
the
only
code
base
that
we
work
on
so,
if
you're
looking
for
other
opportunities
to
contribute
still
come
talk
to
us?
Let
us
know
what
you're
passionate
about
customize,
I
know,
has
some
opportunities
contributed
and
the
the
functionality
that
shawn
was
just
talking
about
as
well
in
terms
of
making
prototypes
on
new
apply,
we
have
some
more
experimental
stuff
like
that
that
you
could
potentially
help
with
too
so
don't
hesitate
to
reach
out
to
us
if
you'd
like
to
get
involved.
A
A
So
the
question
is:
if
I
want
to
use
the
apply
functionality
from
cubecontrol,
can
I
port
that
into
my
application?
You
can
right
now
it's
not
the
best
to
use,
because
there's
that
tight
cobra
dependency,
we
also
don't
support
versioning
it
right
now
right.
So
there's
no
guarantee
that
we
won't
break
something
on
you.
Once
we
get
to
the
place
where
we
feel
it's
ready
to
be
consumed
as
a
library
type
of
code,
then
we
would
figure
out
how
a
support
cycle
works,
but
as
of
right
now,
you
absolutely
can.
A
A
B
Easy
one
is
to
come
to
the
bug
scrub.
I
would
say
so
you
we
have
those
every
other
week
you
can
come
and
if
you
have
an
issue
that
you
want
to
ask
about,
that's
a
good
opportunity,
but
it's
also
a
good
opportunity,
like
you'll,
see
the
issues
that
we're
talking
about
as
we
triage
them.
There's
opportunities
to
claim
issues
every
single
week
that
we
that
we
do
that.
So
that's
a
good
way
to
get
started
too
yeah.
A
C
I
think
I
think
we
should
really
emphasize
that
actually
showing
up
in
person
to
the
meetings
you
know
it
takes
it
to
the
next
level.
It's
really
hard
to
interact
just
through
online
through
the
issues.
If
you
can,
you
know,
I
know
that
it's
not
easy.
It's
it's
9
a.m.
Most
of
the
meetings
are
9
a.m,
pacific
time,
which
doesn't
fit
with
a
lot
of
other
or
other
contributors,
but
if
you
can
show
up
in
person
that
actually
is,
I
think,
it's
easier
to
to
get
involved
than
through
just
the
issues
and.
A
B
C
A
Oh
gosh
cool
well
we'll
hang
around.
We
really
would
just
want
to
hear
feedback,
and
we
mentioned
the
control
headers
kept.
That's
something
that
we'd
actually
like
to
talk
about
at
some
point
where
currently
the
cubecontrol
can
send
all
the
command
information
via
headers
to
the
api
server.
It's
currently
not
really
persisted
anywhere
to
logs,
but
we
would
love
a
way
for
operators
to
opt
in
to
sharing
that
data.
A
Once
we
write
it
somewhere,
so
we'd
love
to
know
how
you're
using
cube
control,
we
can
figure
out
how
to
anonymize
it
take
out
anything.
You
know
pii
wise,
but
we
really
we'd
love
to
know
where
to
put
our
efforts
in
terms
of
commands
and
plugins,
and
how
are
you
using
cubecontrol
cool?
Thank
you
for
having
us
thanks
for
coming.