►
From YouTube: Kubernetes SIG CLI: Intro And Updates - Eddie Zaneski, Chainguard; Katrina Verey, Sean Sullivan
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2023 in Amsterdam, The Netherlands from April 17-21. 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, Chainguard; Katrina Verey, Shopify; Sean Sullivan, Google
Speakers: Sean Sullivan, Katrina Verey, Eddie Zaneski
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. They will share the work done over the past year and an introduction to the kuberc KEP for defining user preferences. The session will conclude with Q&A.
A
D
D
So
we've
already
done
our
introductions
here
and
so
initially
you
know
what
is
the
six
CLI,
so
we
establish
the
conventions
for
writing.
Cll
commands,
including
post-6
compliance
and
improving
the
command
line,
tools
from
a
developer
and
devops
user
experience
and
usability
experience
or
perspective.
D
So
that
was
a
mouthful
and
so
what
is
it
specifically?
What
are
the
concrete
artifacts?
So
the
first
one
that
everybody
probably
knows
is
Coupe
control,
which
is
our
standard
command
line
tool
to
communicate
with
the
Clusters
and
when
I
first
joined.
Actually
Coupe
control
was
the
only
sub
project,
but
now
that
you
know
I,
look
up
here,
I
see
that
we
have
quite
a
few
other
artifacts
and
repositories.
D
So
in
addition,
the
CLI
runtime
and
the
CLI
experimental
repositories
are
are
for
libraries,
especially
the
CLI
runtime.
It
is
for
libraries
for
building
command
line
tools
and
finally,
we
have
the
krm
functions,
which
is
a
client-side
functions
that
operate
on
kubernetes,
declarative
configurations
and
that's
kind
of
the
newest
of
our
sub
projects.
D
D
A
Yes,
so
a
little
bit
of
what
we've
been
doing
and
I'm
not
going
to
go
through
all
the
features
that
we've
been
doing,
the
slides
that
we
will
ensure
that
are
on
scat
are
not
yet
there
but
we'll
you
can
track
them
and
have
a
look
through
all
the
links
and
see
what
we've
been
doing.
What
I
would
like
to
use
our
spot
here
is
to
give
shout
outs
to
all
the
folks
that
are
actually
working
on
those
features,
so
Nikita
Arda,
Lao,
Katrina
Jordan,
our.
A
There
are
changes
with
regards
to
how
we
pick
the
default
containers
from
from
the
resources
that
exist
through
an
annotation
we're
pushing
the
cube,
cuddle
events.
So
if
you
know
so
far,
you
probably
were
primarily
consuming
events
through
Cube
cuddle
get
command
we're
working
to
to
make
the
events
command
a
little
bit
more
smarter
than
just
get
by
default.
It
will
be
similar,
but
it
will
allow
you
to
have
a
little
bit
more
control
about
the
filtering.
So
if
you
combine
like
describe
describe,
will
always
show
you.
A
The
information
with
the
event
related
to
a
particular
resource
get
did
not
have
that
ability
and
we
could
not
embed
this
kind
of
functionality
and
get
because
get
is
more
generic
comment
for
every
kind
of
resource.
So
that's
why
we
started
working
on
on
the
cubecado
events
command.
The
new
additions
that
we
are
putting
together
is
to
improve
the
explain
information.
A
That
needs
to
be
done
if
you're
interested
in
working
on
any
of
those
that
there
are
on
the
slides
or,
if
you're
interested
in
in
pursuing
some
of
your
own
Like
Son
mentioned
the
six
CLI
bi-weekly
call
is
the
best
options
or
Pingas
on
slack.
Send
an
email
to
the
mailing
list
start
the
discussion,
and
that
will
be
probably
the
best
option
to
to
get
the
discussion
rolling
and
with
that
I
think.
B
Thanks
mache,
so
this
next
segment
is
one
that
we
did
at
kubecon
EU
as
well.
So
apologies
to
those
of
you
who
have
already
seen
it,
but
the
issue
of
declarative
and
imperative
workflows
and
the
distinction
between
those
two
things
being
misunderstood
has
come
up
a
bunch
of
times
in
our
Sig
over
the
past
year
and
we
feel
like
there's
a
really
important
message
for
the
Sig
members
to
understand
and
to
help
other
end
users
as
well
understand
about
how
these
things
work.
B
So
with
that,
what
are
we
really
talking
about
here?
What
are
we
talking
about
in
terms
of
configuration
management
workflows
in
the
documentation?
This
is
called,
object,
object,
management
techniques
and
there
are
basically,
if
you
want
to
have
an
object
in
your
kubernetes
cluster,
say
you
want
a
deployment
to
exist
or
a
service
to
exist.
There
are
a
few
different
ways
you
can
go
about
making
that
happen,
and
those
are
referred
to
as
the
object
management
techniques.
B
There
are
two
categories:
imperative
and
declarative
and
within
with
an
imperative,
there
are
two
subcategories
which
I'll
get
to
in
a
moment,
but
the
message
that
we
want
to
deliver
is
that
these
categories
here
are
should
be
considered
mutually
exclusive.
A
given
kubernetes
object
should
be
managed
using
only
one
of
those
techniques.
If
you
choose
one
technique
and
you
stick
to
it,
otherwise
mixing
and
matching
will
result
in
undefined
Behavior.
So
let's
go
over
those
techniques.
B
There
we
go
the
first
one
is
the
imperative
commands.
So
this
is
a
really
simple
approach
like
if
you're
just
experimenting,
you're,
trying
you're
getting
to
know
kubernetes
you're
doing
some
training
or
you're
messing
around
with
a
local
cluster.
This
is
an
appropriate
technique.
It
basically
means
that
you're
operating
directly
on
live
objects
in
the
cluster,
using
control
commands
that
take
care
of
everything
that
you
want
to
do.
So,
if
you're,
using
Cube
control,
create
you'll,
be
passing
it
arts
and
flags
that
describe
the
object
that
you
want
to
create.
B
For
example,
this
is
the
lowest
barrier
to
entry,
but
it's
also
only
suitable
for
development
projects,
because
it
doesn't
give
you
a
way
to
support,
say
A,
Change,
review
process,
there's
no
possibility
of
an
audit
Trail
no
source
of
Records.
Besides,
what's
live
so
not
good
for
Disaster
Recovery,
you
can't
tell
what
you
use
to
create
the
object
in
the
first
place.
B
For
one
thing:
it
works
only
on
individual
objects
and
individual
files,
because
if
you
are
operating
across
the
site,
you
might
need
to
do
different
operations
for
different
objects.
So
say
maybe
some
don't
exist
yet
so
you
need
to
use,
create
others.
You
need
to
use,
update
others,
you
need
to
perhaps
delete,
so
you
need
to
do
them
one
at
a
time,
because
you
can
only
do
one
operation
at
a
time
with
these
imperative
commands.
The
other
major
downside
is
that
it.
B
This
does
not
work
very
well
for
objects
where
key
fields
are
populated
by
other
actors
in
the
system
say
a
controller.
The
classic
example
here
is
a
load
balancer
service,
which
has
an
external
IPS
field.
That's
going
to
be
populated
by
a
controller
and
if
you
just
do
Cube
control
create
of
one
of
those
services
that
those
IPS
will
get
populated
and
if
you
use
replace
with
the
same
file
that
you
had
before
you're
going
to
override
that
field
and
it
will
get
cleared,
which
was
not
what
you
wanted
to
do.
B
B
Specifically,
Cube
control
apply
is
much
more
sophisticated
command
because
it
actually
will
figure
out
for
you
whether
you
need
to
create,
update
or
delete
the
object
and
that
lets
you
work
with
a
set
of
objects
and
on
which
operate
different
operations
might
be
required
within
set.
It
has
the
same
advantages
for
version
controlling
auditing
that
we
just
discussed
because
you're
working
with
files
again,
but
it
also
is
able
to
retain
changes
made
by
other
writers,
even
if
the
changes
are
not
merged,
backed
by
you
into
the
into
the
object
file.
B
B
So
the
point
again
here
is
that
once
you're
familiar
with
the
distinction
between
these
three,
it's
important
to
remember
that
you
should
stick
to
one
or
the
other
for
a
given
object,
because
the
mixing
the
together
results
in
undefined
Behavior.
So
what
when
we
come,
come
bring
this
back
to
acute
control
for
the
declarative
technique?
It
really
is
just
Q
control
apply.
So
when
you
want
to
create
your
objects,
use
Q
control
apply
when
you
want
to
make
an
update
to
them.
Use
Q
control
apply
again.
B
But
the
gotcha
here
that
some
folks
find
unintuitive
is
that
other
commands,
like
Q
control,
roll
out
undo.
That
is
also
an
imperative
command
that
is
going
to
have
undefined
behavior
when
combined
with
apply
some
of
them
they're,
also
a
set
like
edit
and
set
and
patch
and
scale
that
are
somewhere
in
the
middle,
where
they
do
have
a
somewhat
predictable
Behavior.
B
If
you
understand
what
they
do,
but
a
lot
of
folks
seem
to
expect
that
if
you
do
an
apply
and
then
edit
and
apply
the
apply
is
going
to
overwrite
the
changes,
but
from
applies
perspective.
Edit
is
an
external
actor
that
it's
collaborating
with,
so
it
it
does
not
actually
actually
do
that.
So,
in
summary,
undefined
Behavior
means
that
it's
gonna.
You
have
to
really
understand
how
all
of
these
commands
work
and
what
they
do
to
use
them
safely.
B
So
it's
it's
really
best
in
most
cases
to
just
stick
to
the
one
strategy
and
not
mix
them
together.
This
is
warned
about
in
The.
Docks
I
now
have
the
screenshots
from
here
from
the
docs
and
there's
a
link
at
the
bottom
that
you
can
follow
to
read
more
about
all
of
these
strategies
and
how
they
work
and
what
the
best
practices
are
and
yeah
again
please
use
apply.
C
C
So
when
we
think
about
Cube
configs,
everyone
has
gotten
a
cube
config
from
their
cloud
provider
when
they've
created
a
cluster
right.
The
problem,
a
lot
of
folks
run
into
is
your
Cube.
Config
is
tied
to
a
particular
cluster,
but
you
could
sometimes
have
multiple
contacts
with
multiple
clusters,
and
so
this
gets
really
hard
when
we
want
to
ship
files
around
or
drop
it
in
a
CI
system,
and
the
issue
is
that
Cube
control
is
a
very
old
tool
that
we
can't
make
a
lot
of
breaking
changes
to
because
everyone
uses
it
in
pipelines.
C
Everyone
has
these
archaic,
bash
scripts
and
it
needs
to
keep
working.
So
when
it
comes
to
keeping
control,
our
hands
are
very
much
tied
and
so
the
goals
of
what
we're
trying
to
accomplish
are.
We
want
to
maintain
Cube
controls,
strong
guarantees
and
backwards
compatibility
I
want
to
be
able
to
opt
you
into
new
default
behaviors.
That
would
be
breaking
changes,
and
these
are
we
want
to
consider
this.
A
per
client
configuration
right.
C
C
You
don't
want
to
have
your
settings
in
there
that
get
blown
away
when
you
get
a
new
Cube
config
dropped
on
top
of
it,
and
so
we
sought
out
how
to
solve
this
problem,
and
we
put
this
kept
together
and
we
talked
through
some
of
the
use
cases,
and
so
I
want
to
be
able
to
have
delete
confirmation.
This
is
something
that
I've
been
the
soapbox.
I've
been
standing
on
for
the
past
like
three
years
is.
It
is
very
easy
for
you
to
delete
everything
in
your
cluster.
C
If
you
accidentally
delete
a
namespace,
you
accidentally
delete
everything
in
that
namespace.
If
you
accidentally
delete
all
namespaces
you've
just
blown
away
your
entire
cluster
and
it
will
just
listen
right.
There's
no
confirmation.
Are
you
sure
you
want
to
delete
everything,
so
we
want
to
add
interactive
confirmation
that
says
yo
you
about
to
delete
everything.
Are
you
sure
you
want
to
do
this?
We
can't
do
that
because
it
is
a
backwards,
breaking
change,
so
ndci
pipeline
any
script.
That's
expecting
that
command
to
just
run
without
asking
for
user
input
it
breaks.
C
We
talked
about
ways
to
do
this.
You
could
try
to
detect
if
you're
running
in
the
CI
environment,
the
fun
thing
about
CI
environments.
Are
they
fake
being
an
actual
interactive
terminal
to
have
pretty
outputs
in
color
for
you
right?
So
this
isn't
a
problem
that
we
can
just
solve
by
by
hacking
around,
so
we
also
want
to
be
able
to
add
colored
output
by
default.
So
if
you
want
to
opt
in
to
pretty
tables
and
colors,
we
can't
do
that
in
a
CI
run
or
any
sort
of
thing.
C
That's
expecting
output,
because
it
adds
those
magic,
133m
characters
that
you
may
have
seen
when
you
copy
paste.
People
want
to
be
able
to
Define
aliases
for
cube
control
commands
and
some
folks
want
to
be
able
to
Define
default
Flags
and
we're
looking
for
your
use
cases
so
anything
that
you'd
like
us
to
see
to
add
changing
or
breaking
compatibility.
C
That's
something
that
users
would
want
to
opt
into
there's
just
a
giant
list
of
things
that
if
we
were
to
rewrite
Cube
control
today,
we
would
not
do
it
the
way
it
was
done,
so
our
hands
are
tied
on
a
lot
of
the
situation,
so
this
is
a
way
that
we're
trying
to
attempt
to
make
those
changes
and
give
folks,
maybe
more
sane
defaults,
and
so
this
is
the
config
that
we
came
up
with
I,
don't
really
like
it,
and
so
we
want
feedback.
We
want
thoughts
on
it.
C
The
solution
for
these
command
dailies
is
this
is
the
first
one
we
attempted
right
so,
if
I
want
to,
if
you
want
to
opt
in
to
delete
confirmation
on
every
single
delete
command,
you
run
I,
don't
want
you
to
have
to
pass
a
flag
that
says
yes,
I
want
delete
confirmation
on
every
delete,
Command
right
that
doesn't
help
anyone,
because
it's
an
accident
right.
It's
a
human
error
where
you
forget
to
do
that
flag.
C
It's
a
human
error
where
you
delete
the
wrong
thing,
and
so
the
original
thought
we
had
was
to
take
the
commands
that
you're
running
and
set
a
set
of
default
flags
that
will
be
tacked
onto
that
command.
So
that's
what
you
can
see
in
this
example
here,
so
the
the
third
one
down.
It
says
the
flags
confirm
default
to
true
and
that
will
match
the
delete
command.
C
I!
Don't
really
like
this!
It
solves
the
problem,
though,
and
so
every
time
we
think
about
how
to
solve
this
problem
it
we
keep
getting
stuck
on
different
bits.
What
will
be
usable
what's
easy
to
modify
in
configure
so
we're
looking
for
feedback?
Is
this
something
you'd
like
to
to
configure?
Is
this
how
you
like
to
opt
into
these
behaviors?
It
needs
to
be
extendable.
It
needs
to
be
easy
for
folks
to
opt
in
and
change
behaviors.
C
We
don't
necessarily
want
to
have
a
setting
file
for
every
single
flag
or
default
command
that
comes
in
here
and
there's
a
lot
of
folks
that
want
to
they've
asked
for
default
aliases
for
commands
before
you.
So
the
first
example
you
can
see
getdb
prod
it
would
pass
a
set
of
flags
or
configs
that
you
would
have
on
here.
So
save
some
folks
for
typing
same
thing
with
the
last
one
here,
Sig
auth
has
the
authentication
plugins.
C
If
you've
used
a
cloud
provider
before
they
want
to
be
able
to
allow
list,
only
a
certain
set
of
auth
plugins
that
your
program
can
run
on
your
computer
because
it
turns
out
this
could
be
a
security
risk.
This
these
are
arbitrary
binaries
that
just
get
called
from
another
config
file
right.
So
we
want
to
be
able
to
allow
lists.
You
only
want
these
certain
authenticators
of
these
binaries
to
be
ran.
C
C
So
talk
to
your
your
bosses
to
see
if
you
can
spend
a
chunk
of
your
work
time
or
maybe
half
a
day
or
something
so
yeah
we'd
love
to
hear
from
you
I
think
we
have
another
microphone
somewhere
for
questions
being
run
up,
but
let
us
know
anything
we
talked
about
today.
Anything
you'd
like
to
see
anything
that
bothers
you
about
Cube
control
in
general,
anything
about
the
cap
we
just
talked
about,
but
yeah.
We
got
plenty
of
time
we.
This
is
a
chance
for
us
to
listen
to
y'all.
C
So
Cube
control
is
a
go
project,
so
it's
strictly
statically
typed.
It's
very
easy
for
us
to
Marshal
something
like
this
into
a
struct
and
use
that
elsewhere.
So
that's
why
a
lot
of
the
the
kubernetes
stuff
is
done
with
the
ammo,
because
we
can
take
that
Marshall
it
into
a
go
type.
That's
the
same
thing
we
did
here.
This
is
versioned
and
extendable,
so
we
can
have
different
versions
We
tossed
around
the
idea
of.
If
you
were
using
a
certain
version,
we
would
automatically
opt
you
into
default
Behavior.
C
B
I
guess
the
yeah,
the
other
Cube
and
fig
is
also
yeah
yeah.
That
way,
and
it's
just
a
very
common
strategy
across
the
ecosystem,
including
for
the
exact
reasons
Eddie
mentioned,
like
the
ability
to
have
a
kind
who
can
verify
that
we're
loading.
The
right
thing
in
the
version
versioning
capability
is
super
super
handy.
A
A
I'm.
Actually
I
was
when,
when
Eddie
was
presenting
this,
this
file
I
started
wondering
that,
instead
of
doing
default,
Flags
like
he
proposed
here,
we
could
actually
allow
overriding
the
default
commands
with
aliases.
So
normally,
if
you're,
if
you're
working
on
on
a
Linux
environment,
and
if
you
log
in
as
root
it,
has
a
default
default
Alias
for
RM,
which
always
asks
for
confirmation.
A
So
I
was
actually
thinking
that,
maybe
that
something
like
that
in
a
cube,
color
would
be
better
because
I'm
not
explicitly
saying.
Oh,
this
is
a
default
side,
but
I'm
actually
saying
oh,
this
is
actually
what
the
daily
should
be
doing.
In
my
case,
there
are
options.
I
just
realized
that
when
Eddie
was
talking
about
that,
it
could
be
a
good
approach,
and
maybe
we
actually
should
focus
more
on
about.
Oh
just
provide
a
general
aliasing
mechanism
and
people
that
will
give
a
lot
of
flexibility
with
regards
to
default,
slacks
and
whatnot.
A
B
C
Yeah
so
I
just
this
is:
can
you
blow
that
up
maybe
a
little
more?
This
is
the
actual
struct
for
a
cube
config.
So
this
is
what
your
Cube
config
gets
marshaled
into
and
if,
if
you
you
probably
can't
see,
but
there
is
actually
a
preferences
field,
that's
old
and
it
actually
scroll
down
just
a
tiny
bit
much
eh.
There's
a
color
field
that
most
people
don't
know
about.
It
doesn't
actually
do
anything.
It
was.
They
thought
that
it
would
one
day
but
yeah.
So
this
is
what
we're
trying
to
separate
out
from.
C
That
came
up
that's
great
feedback.
It
is
on
the
it's
definitely
we
mentioned
in
the
cap
as
a
future
thing
to
hit.
We
don't
know
how
to
tie
that
forward.
So
if,
if
you
could
tell
us
what
you'd
like
to
see
all
the
drafts
I
came
up
with,
for
that
were
got
really
messy
tying
it
to
a
context
because
it
gets
even
more
nested
and
then
you
have
to
map
things
to
there.
A
Need
help
working
on
that,
like
literally
someone
needs
to
step
up
and
help
to
finish
the
cap,
help
with
the
implementation,
help
Gathering
the
feedback
and
pushing
the
implementation
through
all
the
alpha
beta
to
GA
stages,
the
sooner
the
more
people
will
be
interested
in
it
and
there
they
start
working
on
it.
The
better
it'll
be
and
the
scenario
will
be
available
for
everyone
to
use
and
I'm,
not
saying
that
we
will
solve
all
the
use
cases
from
from
the
get-go.
That's
not
the
point,
that's
why
we're
introducing
versionet
config
files.
A
A
E
Yeah
I
guess
I
got
ownership
somehow
yeah
I
mean
our
localization
is
not
in
a
great
place
as
far
as
like,
if
you're
using
it
in
another
language
and
I
would
say
like
ninety
percent
of
the
of
the
output
is
still
in
English,
even
though
you're
trying
to
use
it
in
another
language,
so
I
don't
think.
We've
made
a
decision
on
that.
Yet
I
mean
you're,
welcome
to
attend
some
of
the
Sig
meetings
and
provide
some
feedback,
or
we
can
talk
about
it
now.
E
So
it's
still
kind
of
up
in
the
air
I
think
we
would
like
it
to
be
better
so
that
that's
I
think
it
was
proposed
that
well,
if
we
can't
do
it
well,
maybe
we
should
just
remove
it.
I,
don't
know
that
that's
the
answer,
but
that's
certainly
on
the
table
to
remove
it
all
together
or
turn
it
off
for
some
languages
that
are
incomplete.
E
E
E
No,
it's
really
helpful
to
hear,
hear
your
thoughts
on
that
I.
Think
at
the
very
least,
we
need
to
improve
the
the
mechanism
that
people
can
contribute.
It's
too
hard
to
localize
right
now.
There's
there's
it's
not
it's
not
easy
to
do
and
I
think
we
need
to
make
it
easy
to
do
and
that's
going
to
at
the
very
least,
you
know,
help
improve
the
coverage
and
I.
Think
part
of
it.
I
mean
there's
a
lot
of
ideas
on
some
of
the
ideas.
E
E
How
bad
is
it
and
so
that
we
can
measure
it
and
see
that
it's
improving,
and
maybe
we
have
some
metrics
and
say
we're
going
to
turn
off
any
language
that
doesn't
have
more
than
50
of
its
output
or
something
and
then
we
don't,
we
won't
remove
it,
but
we'll
turn
it
off
and
then
or
or
maybe
there
we
trigger
some
issue
to
be
created
and
say
hey.
We
need
help
improving
Korean
translations
because
it's
Fallen
below
this
threshold.
E
Well,
you
know
so
we
do
have
a
survey
in
the
works
and
I
I
created
a
pull
request
for
or
an
issue
I
guess,
rather
for
a
survey
that
I
I.
Don't
we
don't
have
any
timetable
for
when
that's
going
to
be
created,
but
it
is
something
we
want
to
do
and
what
I
think
what
we
want
to
make
sure
is
that
it's
getting
to
the
right
people.
E
So
we
want
to
hear
from
people
who
use
Coupe
cuddle
in
one
of
the
languages
that
are
supported
and
then
I
mean
part
of
it
is
just
to
find
out
how
valuable
is
it
because
it's
it's
one
thing
for
you
know
somebody
who
who's
native
language
is
English
to
look
at
it
and
say
well.
This
is
not
good.
We
should
just
remove
it,
but
if
that
yeah
it
doesn't.
C
We
also
just
had
a
conversation
with
Brendan
Burns,
one
of
the
creators
of
kubernetes,
and
he
mentioned
he
worked
on
the
original
International
inter
nationalization
I-18n
and
the
the
the
thing
that
he
recommended
to
us
going
forward
is
to
have
because
it's
easy
to
have
someone
come
in
and
do
it
once,
but
then
it
drifts
so
much,
which
is
what
happened
originally.
So
how
do
we
put
a
blocking
job
or
a
a
pager
that
goes
off
whenever
we
need
someone
to
come
back
in
or
maybe
we
set
up
an
interval?
C
Someone
wants
to
be
a
language
owner.
They
can
come
in
every
month
or
three
months
to
do
it.
So,
yes,
we
definitely
want
to
support
the
International
Community
for
sure
any
other
questions
I
think
we're
out
of
time.
We'll
hang
around
we'll
head
to
Booth
car
afterwards,
but
yeah
feel
free
to
ask
us
anything
and
thanks
so
much
for
coming
and
yeah
we're
nice.
So
talk
to
us.
Please.