►
From YouTube: Intro: CLI SIG – Mengqi Yu & Sean Sullivan, Google
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Intro: CLI SIG – Mengqi Yu & Sean Sullivan, Google
This "intro" session will provide basic information to facilitate new SIG CLI contributors. This session will present an overview of the "kubectl" code base, as well as the basics of the development process. We will give a short history of this project. We will leave a significant amount of time for Q&A.
To learn more: https://sched.co/Grco
A
I
am
Sean
Sullivan
I'm,
a
co-chair
of
the
command-line
interface,
a
special
interest
group
and
today
we're
gonna
I'm
gonna,
give
an
introduction
to
our
cig,
and
so
what
are
we
going
to
talk
about
today?
So
initially
I'm
going
to
talk
about
the
three
sub
projects
of
the
cig,
CLI
and
then
I'm
going
to
talk
about
what
we've
been
working
on
recently
and
what
I
think
is
going
to
be
useful
to
some
of
you
is
how
do
you
get
involved
and
how
do
you
start
contributing
at
the
end?
A
A
It's
only
recently
that
we've
added
a
couple
of
new
sub
projects
and
one
of
those
sub
projects
is
what's
called
the
CLI
SDK,
and
so
what
we
did
was
we
refactored
coop
control
to
get
some
of
the
its
core
functionality
and
we
put
it
in
its
own
repo
and
the
main
motivation
for
this
was
so
that
we
can.
We
can
write
plug-ins,
so
we
could
reuse
that
functionality
in
our
plugins
and
any
other
clients
that
that
might
need
it.
A
So,
in
addition
to
the
CLI
SDK,
there
is
a
repo
for
a
sample
CLI
plug-in
that
that
one
Vallejo
in
the
front
wrote.
So
if
you
have
any
questions
just
you,
could
you
have
the
author
right
in
front
of
you?
You
can
you
could
bother
him,
and
so
the
third
sub
project
that
the
sixth
seal
is
responsible
for
is
relatively
new
and
I.
A
Think
I'm
going
to
spend
a
few
minutes
trying
to
go
over
it
because
it's
so
new
and
most
people
don't
have
any
context
and
it's
called
customize
and
so
customize
lives
in
the
space
of
resource
configuration
management
tools
and
some
other
tools
in
that
space
or
like
helm
or
case
on
it
and
customize
has
a
different
approach
to
resource
management,
whereas
helm
and
case
on
it
and
other
tools
usually
do
their
configuration
management
through
templating
customizes.
Actually,
it
uses
patches
so
that
you
don't
have
to
modify
your
your
llamó
as
you
would
in
other
tools.
A
A
Read
me
and
as
it
shows,
there
is
a
you
know,
the
customize
customization
dot.
Yeah
mole
is
kind
of
like
the
make
file
which
describes
how
this
process
is
going
to
work
and
it
describes
you
know
what
what
are
the
resources
that
it
cares
about,
and
here
its
deployment,
diamo
and
service
diamo,
and
here
are
the
the
two
resources
themselves
and
then
actually
in
this
example.
It
doesn't
really
show
it,
but
you
can,
for
instance,
add
a
prefix
so
that
in
your
production
cluster
you
have.
A
You
know
that
the
actual
name
of
the
of
the
resource
is
going
to
be
prod,
WordPress
or
staging
dot
WordPress,
and
so,
as
you
can
see,
the
Y
amell's
are
actually
they
have
no
templating
in
them
and
they
are
valid.
Yamo
configuration
yellow.
So
so
this
this
example
is
going
to
be
fairly
simple
and
I'll.
Point
you
in
the
direction
of
how
we
can
how
you
can
find
out
more
if
you're,
if
you're
interested.
But
in
that
example
you
could.
You
would
have
here's
what
the
the
file
structure
would
look
like.
A
It
would
have
that
customization
dot,
llamo
and
then
the
other
resources
service,
dog,
llamo
deployment,
llamo
and
then
in
order
to
omit
the
valid
resource
configs.
You
would
call
customize
build
so
so
that's
slightly
that
that's
going
to
be
not
completely
true
because,
as
I'm
gonna
describe
later
on,
one
of
the
things
we're
working
on
is
combining
customized
into
coop
control
so
that
you
can,
you
can
use
it
and
I'll
get
to
that
in
a
bit.
That's
I
know
that's
probably
slightly
confusing
for
now,
but
hopefully
I'll
address
it
later.
A
A
So
let's
dig
into
coop
control
plugins
for
a
little
bit,
so
our
new
mechanism
for
implementing
plugins
is
get
style
plugins,
and
what
is
what
does
that
mean?
So
that
means
that
when
you
create
a
binary,
that
is
a
plug-in
as
long
as
you
put
it
in
your
path,
and
it
has
a
particular
name
naming
convention,
then
it
will
be
run
by
coop
control
and
so
an
example
would
be
if,
like
for
the
sample
plug-in,
let's
just
pretend
that
it's
your
sub
command
or
your
plug-in
is
called
command
foo.
A
So
you
would
create
a
binary
and
it
could
be
a
bash
script.
It
could
be
in
any
language
that
you
like
as
long
as
the
the
path
as
long
as
it's
within
the
path.
Coop
control
will
first
try
to
run
it
as
a
core
command.
If
it
doesn't
find
it,
then
it's
going
to
start
searching
through
the
path
for
a
particular
binary
called
coop
cuddle,
foo
and
if
it
finds
it,
then
it'll
pass
the
environment
variables
and
it'll
pass
the
parameters
onto
that
plug-in.
A
So
we've
also
begun
a
manager
for
plugins
so
that
we
have
kind
of
day
2
functionality
kind
of
how
to
update
how
to
discover
plugins.
I'll,
be
honest,
that's
that's
pretty
it's
in
a
very
protein
state.
It's
not
it's
not
well
formed,
and
if
that's
something
that
you're
interested
in
please
see
me
afterwards.
A
So
currently,
this
the
coop
control
code
lives
in
two
locations
that
are
in
kubernetes
main
kubernetes
core
and
because
of
that,
it's
kind
of
grown
to
depend
on
things
that
it
shouldn't
depend
on,
and
so
that's
actually
our
biggest
challenge
in
trying
to
move
it
into
its
own
codebase
is
that
there
are
quite
a
few
difficult
to
untangle
dependencies,
but
we're
actually
pretty
close
to
it.
Now
and
and
the
advantages
we
feel
that
will
have
by
moving
coop
control
into
its
own
code
base.
A
Are
we
feel
that
we'll
have
faster
development
velocity
and
we
think
that
we
can
simplify
the
code
base,
and
so,
if
you're
interested,
there
is
a
sim
Briella
issue
that
just
describes
this
effort,
so
just
to
talk
a
little
bit
more
about
what
we're
doing
and
moving
functionality
into
the
server.
So
we
feel
that
we
don't
want
a
thick
client.
So,
whatever
complications
or
complexity
that
we
have
in
a
client
make
it
difficult
for
other
clients
to
actually
use
that
functionality,
for
instance,
like
coop
control
apply.
A
So
if
there
were
another
simple
client
that
wanted
to
to
duplicate
the
all
of
the
code
that
in
the
client
apply
it's
just
not
possible.
So,
but
if
long,
if
it's
just
an
endpoint
on
the
server,
then
it's
significantly
easier
for
other
clients
to
be
able
to
to
use
this
functionality,
and
so
the
the
two
efforts
currently
underway
are
and-
and
we've
already
done.
Most
of
this
we've
moved
printing
to
the
server
side.
A
So
all
of
the
the
logic
that
knows
about
particular
fields
to
print
that
was
a
significant
amount
of
complexity
to
be
in
coop
control
and
it's
been
moved
to
the
server
and
and
again
one
is.
It
was
central
in
that
effort
and
we
still
have
a
fallback
now
in
coop
control,
but
eventually
that's
going
to
that.
A
So
one
of
the
the
efforts
that's
that's
currently
underway
is
the.
As
I
mentioned
our
previous
sub
project,
customize,
the
template
free
yeah
Mille
configuration
sub
project.
We
intend
to
move
that
into
our
standard
client,
the
the
coop
control
client,
and
so
what
is
what
does
that
mean?
So
I
tried
to
give
an
example
here
of
what
it
would
mean.
So
one
of
the
ways
that
we
we
send
our
configuration
to
the
API
server
is
with
apply
and
we'll
do
it
with
a
minus
F
and
then
the
directory
that
will
have
numerous
llamo
configuration
files.
A
So
if
we
are
able
to
integrate
this
tool
with
coop
control,
then
we
can
actually,
if
you
have
your
customization
Yamma,
what
kind
of
that,
the
the
analog
being
that
make
file
it
will
actually
combine
them
in
in
the
way
that's
described
in
that
customization
llamó
before
it's
applied,
so
it's
actually
transparent.
So
the
only
way
so
so,
if
you
want
to
use
this,
then
you
would
organize
your
your
config
with
customize
or
with
customization
llamo,
and
that
functionality
will
automatically
be
called
if
it
finds
the
customization
llamo
in
that
directory.
A
So
I
hope
that
was
so.
So
if
you,
if
you
have
any
questions,
then
we
have
the
the
Q&A
session
later
and
then
again,
I'm
gonna
be
here
afterwards,
if
you
guys,
if
that
wasn't
clear
so
so
this
is
I,
think
near
and
dear
to
a
lot
of
people's
heart,
which
is
how
do
you
get
involved
so
I'm
gonna
mention
some
resources
here
and,
and
hopefully
this
will
give
you
an
ability
to
how
to
start.
A
It's
it's
a
major
gap
and
we
recognize
that
we
need
to
do
better
and
providing
resources
for
you
to
to
actually
bridge
that
gap
and-
and
it's
probably
cold
comfort
now,
but
we're
actually
in
the
process
of
trying
to
create
resources
to
help
you
bridge
that
gap
and
so
I
think
one
of
our
best
resources
and
I
think,
what's
probably
the
most
productive
way
of
initially
getting
involved
in
the
Six.
Eli
is
a
slack
channel.
A
So
sometime
there'll
be
a
lot
of
discussions
of
the
minutia
that
is
going
to
be
kind
of
not,
as
you
know,
might
not
be
as
useful
to
begin
with,
but
you'll
be
able
to
identify
who
it
is
that
can
help
you
with
your
questions
and
in
addition
to
to
the
slack
channel,
we
have
our
bi-weekly
meetings
on
Wednesdays
at
9:00
a.m.
Pacific
time
and
I
think
that
that's
actually
a
great
way
to
once.
You
sit
in
on
the
it's,
the
the
zoom.
A
The
test
playbook
is,
is
how
we
keep
track
of
the
test
grid
that
we
have
for
6:00
Eli,
but
you
can
see
like
back
on
December
5th.
If
I
could
get
this
correct,
we
you
know
what
the
items
are
on
the
agenda
and
how
it
works.
If
there
was
a
particular
area
that
you
wanted
to
address,
you
can
actually
put
it
in
the
proposed
topic,
so
you
could
see
in
the
next
meeting
we
plan
to
talk
about,
or
at
least
we've
we've
scheduled
time
for
the
the
crew,
aforementioned
crew,
plugin
manager
and
yeah.
A
And
and
that,
actually
you
can
see
it
has
the
umbrella
issue
for
for
coop
cuddle
independence.
We
say
it
says:
remove
coop
cuddle
dependencies
on
KK,
there's
the
updating,
the
pluck
it
plugin
mechanism,
and
so
here's
the
the
things
that
we're
working
on
right
now
and
we
also
have
a
prioritized
bug
list.
So
one
of
the
things
that
you
may
want
to
look
at,
which
is
the
issues
the
coop
cuddle
issue,
coop
control
issues
and
the
label
good
first
issue.
So
right
now
we
only
have
two
of
these
issues
which
are
of
this
label.
A
Okay,
so
I
think
that
we've
gotten
to
the
point
where
you
guys
get
to
ask
me
questions
so,
if
I'm
unable
to
answer
I
hope
to
point
you
in
the
correct
direction,
but
I'll
try
to
answer
whatever
questions
that
you
may
have,
so
one
is
going
to
help
me
out.
If
you
just
raise
your
hand,
if
anybody
has
a
question
wanna
be
able
to
give
you
the
microphone.
B
A
We
backwards
compel
it
excuse
me
backwards.
Compatibility
is
a
major
issue.
That's
it's
a
good
point.
What
we
usually
do
is
so
in
kubernetes
2
standard
for
SKU
version.
Sku
is
that
kubernetes
will
support
both
like
one
version
prior
and
one
version
after
so
like
version
112
would
also
support
113,
one
twelve
and
one
eleven,
and
if
it's
beyond
that
scope,
then
we
we
don't
guarantee
anything,
but
it
requires
several
releases.
Once
you
once
you've
moved
functionality
to
the
server,
then
you're
gonna
have
to
you'll.
We
usually
have
fallback
to
the
client
side.
It's
like.
C
As
far
as
moving
the
print
functionality
to
the
server,
does
that
mean
that
formatting
is
done
on
the
server
or
does
that
simply
mean
that
the
selection
that
fields
has
done
on
the
server,
because
I've
never
seen
any
way
right
now
to
output
like
JSON
or
XML,
instead
of
like
pre
formatted
tabular,
and
that
seems
really
unfriendly.
So
so.
A
We
want
a
thinner
client,
and
so,
if
you
have
it
on
the
client,
then
it
has
to
understand
every
single
type
and
all
of
its
fields
and
and
yeah
we're
moving
towards
a
in
order
to
get
rid
of
skew
problems
in
order
to
remove
the
dependency
on
types
where
we're
trying
to
move
towards
more
just
unstructured
blobs
and
not
understanding
the
go
types
and
in
order
to-
and
this
is
one
of
the
efforts
to
kind
of
help
us
in
that.
In
that
vein,
so
you
look,
you
look
really
dubious.
A
A
So
so
the
the
Tate
the
table
was
more
its.
You
could
think
of
it
as
XML.
It's
just
a
way
to
present
the
data
right.
So
you
you
don't
have
to
show
all
of
the
columns.
You
don't
even
have
to
show
all
the
roads
it's.
It
is
a
way
to
organize
the
data
to
send
to
the
client
so
yeah.
So
that's
yeah,
that's
not
that's
the
direction
that
it's
going
and
I
don't
see
it
changing
so,
but
if
you'd
like
to
discuss
it
more
and
especially
you
know,
I
mean
we'd
love
to
see
feedback.
D
A
A
Right
so
so
the
implementation
is
that
we
have
in
the
CLI
runtime
in
that
that
part
that
I
told
you
that
was
refactored.
That
repository
we
have
what's
called
a
resource
builder
and
that
resource
builder,
it's
implemented
as
it's
kind
of
a
visitor
where
it
will
within
the
code,
you
will
be
presented
in
a
for
loop
with
all
of
the
objects
that
have
been
currently
as
they've,
been
like
marshaled
into
ghosts,
trucks,
and
so
that
is
the
the
touch
point
for
where
customize
is
now
connected.
A
It's
so
that
visitor
normally
it
would
just
it
would.
You
know,
take
the
yamo
and
change
it
modify
it
into
the
go
struct
well,
it
knows
now
that
there's
a
customization
yamo
file,
and
so
it
will
you
go
through
that
process
to
create
the
folder
yeah
mol
using
the
customize
process
and
then
change
it
into
the
ghost
drugs.
Did
that
make
any
sense?
Okay,
so
so
we
hope
to
this
is
actually
under
discussion,
but
we
hope
to
what,
if
we
implement
it
that
way.
Actually
it's
it's
a
PR,
that's
out
now.
A
E
G
Sure
so
it
is
possible
with
plugins
to
address
some
of
this.
This
lack
of
functionality,
if
you
want
to
call
it
that
the
the
sample
sale
I
plug-in
like
Sean
mentioned,
does
essentially
allow
you
to
you,
know
sort
of
add
some
of
this
functionality
to
to
the
CLI
so
like
right
now
you
can
you
can
clone
the
sample,
CLI
plug-in,
compile
it
and
it'll
essentially
behave
like
you
know
this
really
minimal
command.
That'll.
G
Allow
you
to
you
know:
it'll
modify
your
cube
config
underneath
to
change
the
namespace,
it
honors
config
flags,
like
context
user
and
anything
else,
and
essentially
you
know,
allows
you
to
without
knowing
what
a
cube
config
file
is
persist.
You
know
that
the
namespace
for
context
or
user
information,
depending
on
how
you
operate
good,
that
answer
so.
A
I
think
there's
a
more
general
question
there
too,
which
is:
how
do
you
extend
coop,
control
and
I?
Think
that
there's,
from
my
perspective,
there's
two
main
tools:
there's
the
plugins
and
there's
the
the
the
controllers
so
two
like
CR
DS,
to
extend
the
API
and
so
we've
seen
other
other
projects,
for
instance
sto
the
service
mesh
right.
They
have
their
own
command-line
interface
and
it
was
built
to
years
ago.
So
it
it
kind
of
forked
from
coupe
control.
A
But
a
lot
of
the
stuff
is
the
same,
and
now
they
have
to
keep
rebasing
and
so
in
the
future.
What
we
think
is
a
productive
approach
for
these
different
CL
is
in
these
different
projects
is
to
base
it
on
group
control
and
if
you
have
specialized
functionality
that
coupe
control
doesn't
give
you,
then
you
can
add
binaries
through
plugins,
or
you
can
add,
extend
the
API
with
C
RDS
and
your
custom
controllers
to
implement
the
business
logic
of
those
those
new
resources.
A
So
so
I
think
if
sto
were
starting
today
on
a
on
a
CLI,
it
probably
would
have
been
better
to
to
have
plugins
for
the
sto
specific
functionality
and
then
also
to
add
some
sto,
specific
C,
RDS
and
actually
I.
Think
that
that's
the
way
that
they're
moving
is
they're
trying
to
get
rid
of
some
of
the
complexity
in
their
CLI
and
I.
Think
at
least
partially
they've
moved
to
some
new
CRD
some
new
custom
resources.
C
A
So
that
is
what
the
the
crew
project
is
meant
to
address
and,
like
I
mentioned
before,
it's
not
in
a
great
state
right
now,
and
if
it's
something
that
you're
interested
in
then
I
know
that
there
are
people
who
would
love
to
see
extra
development
resources.
So
so
one
of
the
people
that,
if
you're
really
interested
you
want
to
talk
to,
is
Ahmet
Vulcan.
A
B
B
A
B
B
Everything
be
presentation,
and
this
morning
his
keynote
is
another
in
a
long
line
of
examples.
It
seems
like
everybody
who
spends
much
time
with
Q
control
winds
up
building,
at
least
a
bunch
of
shell
aliases
and
most
a
whole
system
to
abstract
it
away
from
the
perspective
of
a
company
or
a
group
of.
A
Developers,
so
so
that
so
I
think
that
that
comes
back
to
exactly
what
we're
talking
about
before
so
I
think
that
now
we
have
actually
a
pretty
good
set
of
tools
to
extend
coop
control
so
that
you
don't
have
to
wrap
it
in
these
special
shells.
You
know
if
you
now
have
plugins
so
like.
If
you
want
to
do
your
special
Airbnb
thing
you
can.
You
know
this
particular
coop
control
command,
it'll
be
coop
control,
Airbnb
foo,
that
particular
binary
or
which
is
what
is,
has
been
a
really
popular
method.
A
Now,
as
I
mentioned,
is
extending
the
API
with
these
custom
resources
and
then
building
the
custom
controllers
that
implement
the
logic
of
those
those
resources
and,
and
so
actually
I
would
highly
recommend.
If
that's
the,
if
you
find
yourself
moving
in
that
direction
towards
custom
resources,
which
is
what
feels
to
be
like
a
really
powerful
Avenue
these
days,
then
I
would
recommend.
A
Looking
into
a
project
called
COO
builder,
soku
builder
will
generate
a
lot
of
these
custom
controllers
are
and
we're
getting
a
little
bit
away
from
the
coop
control,
but
these
these
custom
controllers
are
in
many
ways
just
a
bunch
of
boilerplate
code,
and
so,
if
you
look
at
the
sample
controller
you'll
see
that
you
know
a
lot
of.
It
is
just
boilerplate
and
then
there's
just
this
small
space
where
you're
putting
your
business
logic
in
for
your
particular
custom
resource
and,
and
so
the
COO
builder
actually
will
generate
most
of
this
boilerplate
code.
A
It'll
generate
tests,
it's
actually,
in
my
opinion,
a
really
really
exciting
project
and
one
of
the
talks.
There's
a
talk
on
COO
builder
and
Phil
is
going
to
be
giving
that
talk.
When
is
that
talk
Phil,
they
were
stated
so
so.
Look
up
that
in
your
schedule,
if
you're
using
crts
and
control
and
custom
controllers,
that's
the
way
you
want
to
go
it's
and
it's
getting
a
lot
of
momentum.
F
Lift
just
gave
a
talk
yesterday
about
how
they
use
customize,
to
do
a
bunch
of
stuff
such
as
sidecar
injection
for
envoy
and
and
do
actually
very
complicated
things,
decryption
of
pulling
secrets
or
decrypting
secrets,
and
so
that
sort
of
functionality
is
getting
merged
into
COO
control
directly.
So
who
control
apply
now
will
support
a
lot
of
these
features
that
higher-level
pieces
were
implementing
before
and
what
we
envision
is
that
folks
still
will
want
like
pipeline
tools.
For
instance,
K
native
pipelines,
folks
are
going
to
want
that
for
a
venting
or
they're.
A
F
A
So,
in
my
opinion,
building
your
tool
around
coop
control.
The
central
premise
has
to
be
that
you're
talking
to
an
api
server
right.
So
obviously
the
coop
control
is
going
to
be
the
you
know
the
most
mature
way
to
talk
to
an
API
server
and
if
so,
for
instance,
with
sto,
they
talk
to
an
API
server,
but
then
they
also
have
extra
functionality.
A
A
F
Sorry
I
should
have
played
sorry
booked.
Another
thing
instead
of
plugins.
Another
thing
we're
looking
at
is
many
of
the
cou
control
commands,
take
user
input
in
the
form
of
flags
or
files
and
then
construct
one
or
more
requests
to
the
API
server.
Send
those
requests
then
take
the
response
back
and
format.
It
now
put
it,
and
that
is
actually
something
you
don't
need
to
compile
in
in
go
code
for
write
its
web
browsers
have
solved
this
problem
right
with
HTML.
You
want
a
form
or
something
you
send
it
to
the
server.
Send
it
back.
F
I
think
has
been
brought
up
in
the
past
is
like
what,
if
two
people
named
their
plugin,
the
same
thing
but
C
or
DS
and
api's
already
have
a
name
save
space
or
they
already
have
naming
collision
built
in,
and
so
we
can
use
that
same
mechanism
to
avoid
collision
or
or
prioritize.
The
specific
commands.