►
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2021 Virtual from May 4–7, 2021. 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.
The Building Blocks of DX: K8s Evolution From CLI to GitOps - Katie Gamanji, Cloud Native Computing Foundation
In the past years, Kubernetes has become the default container orchestrator framework, setting the standards for application deployment in a distributed architecture. Wider adaptability of the tool prompted the diversification of the end-user base, and a consistent DX for cluster interaction became essential for Kubernetes. The community channeled herculean efforts towards the enhancement of developer experience by extending the cluster CLI, building portals, and highly-responsive UIs. This talk will focus on the cluster DX chronicles, showcasing tools which contributed to wider adoption for Kubernetes. An emphasis will be placed on cluster CLI and how it can be extended using kubectl plugins and wrappers. This will be followed by an introduction of widespread cluster state managers, covering mechanisms such as GitOps, ClickOps, and even SheetOps.
https://sched.co/ek9l
A
Hello:
everyone,
my
name,
is
katie
comanche
and
currently
I
am
an
ecosystem
advocate
for
the
cncf.
I
have
joined
cncf
quite
recently,
and
my
responsibility
within
this
role
is
to
grow
the
end
user
community,
but,
more
importantly,
to
close
the
gap
between
the
end
user
feedback
and
the
projects
currently
residing
within
the
cncf
landscape.
A
A
We
had
tools
such
as
docusperm,
apache,
mesos,
kubernetes
and
all
of
them
provided
a
viable
solution
to
run
containers
with
scale.
However,
kubernetes
took
the
lead
in
defining
the
principles
of
how
to
run
these
containerized
workloads.
Nowadays,
kubernetes
is
known
for
its
portability
and
adaptability,
but,
more
importantly,
for
its
approach
towards
the
clarity
of
configuration
and
automation,
and
this
can
actually
be
seen
in
numbers.
When
you
look
at
the
cncf
survey
in
2019,
more
than
50
percent
of
the
companies
are
using
kubernetes
in
production.
A
The
hour
42
are
actually
prototyping
kubernetes
as
a
viable
solution
to
move
forward.
When
a
transition
towards
the
contributor
community,
there
are
more
than
2
000
engineers,
actively
collaborating
towards
virtual
future,
build
out
and
bug
fixing,
and
when
we
look
into
the
end
user
community,
more
than
23
000
attendees
were
registered
at
the
kipcons
around
the
world.
A
Now,
if
you
look
into
all
of
this
tooling,
some
of
them
are
going
to
provide
similar
capabilities
such
as
service
mesh,
networking,
storage,
runtime
and
many
more
and
a
more
diverse
tooling.
That
means
we're
going
to
have
a
more
diverse
user
base
as
well,
because
engineers,
with
different
capabilities,
we'll
need
to
interact
with
the
cluster
either
to
manage
the
cluster
or
deploy
to
the
classroom.
A
As
such,
we
can
identify
three
main
personas
of
three
main
user
groups
here:
the
application
developers,
application
operators
and
infrastructure
operators.
The
application
developers
are
the
engineers
which
don't
necessarily
need
to
interact
with
the
cluster.
However,
they
will
need
to
be
aware
that
they
can
application
is
going
to
be
containerized
as
such,
they
will
focus
on
the
business
logic,
but
at
the
same
time,
they'll
need
to
be
aware
to
develop
endpoints
such
as
liveness
and
readiness
probes.
A
The
application
operators
on
the
other
side
are
the
engineers
which
will
interact
with
the
cluster
and
deploy
the
application.
They
will
be
aware
of
all
the
resources
within
the
cluster
and
any
components
that
are
necessary
to
make
sure
that
the
application
is
up
and
running
at
all
time
and
infrastructure
operators
are
the
engineers
which
will
not
only
understand
all
the
resources
within
the
cluster,
but
they'll
be
aware
how
to
create,
manage,
configure
and
delete
a
cluster
from
scratch.
A
A
We
have
the
support
for
declarative
and
imperative
management
techniques
when
we
refer
to
the
imperative
technique.
That
means
that
we're
going
to
operate
on
the
live
object
straight
away,
so
this
is
going
to
be
an
engineer
which
will
either
create
or
delete
a
resource,
and
this
is
going
to
be
straightaway
visible
within
the
cluster.
A
However,
on
the
downside
of
this
approach
is
the
fact
that
it
has
no
source
for
the
configuration,
so,
if
you'd
like
to
share
this
configuration
with
either
other
teams
or
with
a
wider
organization,
that's
going
to
be
difficult
for
us
and
that's
why
we
have
a
declarative
approach
which
allows
the
operations
on
file
stored
locally.
So
we
have
the
full
representation
of
our
manifest
in
yaml
and
we'll
be
able
to
apply
them
to
the
cluster.
A
The
good
thing
about
this
approach
is
the
fact
that
it
allows
the
directory
level
operations,
usually
when
we
deploy
an
application,
we're
going
to
have
a
deployment
and
that's
going
to
be
associated
with
a
service
service
account
configuration
map,
maybe
we're
going
to
have
a
secret
and
ingress,
and
that's
already
more
than
six
components
we
require
with
the
imperative
approach,
we'll
have
to
create
all
of
these
resources
manually.
However,
with
the
declarative
approach,
we
have
direct-to-level
operations
which
will
allow
us
to
create
all
of
these
resources
with
one
command.
A
A
Now
cluster
ctl
is
a
cluster.
Tipsy.
Tail
is
a
great
way
to
explore
the
cluster
assets.
However,
it
is
generally
and
wrongly
assumed
that
everyone,
interacting
with
kubernetes,
is
going
to
be
flamed
in
cuba.
Ctl
a
clear
path
was
discerned
from
the
community
from
this
point
to
further
enrich
and
extend
the
cluster
dx
to
make
it
available
inclusive
to
engineers
of
all
levels.
A
As
such,
when
we
mention
dx
enhancement,
we
can
refer
to
four
main
principles:
simplicity,
optimization
transparency
and
durability.
Simplicity
means
that
any
changes
or
any
new
tooling
that
we
introduce
to
interact
with
the
cluster
needs
to
remove
some
of
the
complexity
rather
than
making
it
more
difficult
for
our
engineers
to
get
information
from
the
cluster.
A
Transparency
is
a
principle
which
should
be
true
at
all
times
when
we
introduce
new
techniques
to
interact
with
the
cluster.
Our
engineers
should
always
be
aware
where
the
application
is
deployed
and
how
they
can
connect
to
it.
It
is
going
to
be
a
major
blocker
if
we
don't
have
the
transparency,
because
we're
going
to
become
the
bottleneck
when
the
application
team
will
require
to
troubleshoot,
for
example,
during
a
production
incident,
and
the
last
principle
I
would
like
to
mention
is
durability.
A
Any
changes
that
we
introduce.
They
should
just
be
the
building
blocks
of
the
interactions
in
the
features
it
should
be,
something
which
is
easily
extensible
but,
more
importantly,
it's
something
which
is
going
to
stick
with
our
developers.
It's
quite
important
to
introduce
these
changes
frequently,
but
with
a
good
pacing
to
remove
the
developer
fatigue
as
well.
A
A
A
The
location
of
the
file
should
be
in
one
of
the
binary
folders
defined
in
the
path
environmental
variable
as
such.
In
this
example,
I
have
it
under
slash
user
local
beam
and
the
file
name
for
a
plugin
should
be
always
prefixed
by
cube
ctl,
followed
by
the
actual
command.
So
here
we
create
a
greetings
plugin
and
the
file
name
is
obviously
going
to
be
cube.
Ctl
greetings
once
the
file
is
in
the
right
path,
with
the
right
naming,
we
don't
need
to
do
any
install.
A
It
will
be
automatically
identified
by
cube
ctl,
and
we
can
validate
that
by
doing
a
list
of
our
plugins,
and
you
can
see
the
first
result
is
going
to
be
our
greetings,
followed
by
any
other
plugins.
We
have
installed
on
our
machine
and
to
test
that
our
plugin
is
working.
It's
just
enough
for
us
to
do
cubesat
greetings,
and
this
will
go
to
our
shell
script,
we'll
execute
that
and
print
our
echo
command
as
simple
as
that.
A
Now
this
stage
we
could
extend-
or
we
could
share
some
of
these
plugins
with
wider
organization.
However,
over
time
there
are
plugins
which
were
found
useful
across
the
community
and
it
was
required
to
have
a
centralized
mechanism
to
collect
index
and
distribute
these
plugins.
And
currently
this
capability
is
provisioned
by
crew.
A
You
can
think
about
crew
as
a
service
discovery
for
plugins.
Currently
it
allows
the
install
of
more
than
90
custom
commands
for
cube
ctl
and
a
cool
feature
about
crew
as
well
is
the
fact
that
it
has
its
own
version
manager.
So
you
can
have
it's
your
kind
of
separate
way
of
managing
a
plugin
for
crew,
rather
than
to
make
it
very
similar
to
your
project
versioning,
and
if
you
look
into
the
most
widely
used
plugins
at
the
moment,
there
are
plenty
of
them,
but,
as
you
can
see,
search
manager
has
taken
the
lead.
A
Quite
quite
abruptly,
I
would
say
it
has
more
than
seven.
Seven
hundred
thousand
downloads
at
the
moment
and
search
manager
is
a
plugin
which
allows
you
management
of
the
tls
for
kubernetes
cluster
ingress
engine
x
is
another
plugin
which
allows
the
inspection
of
your
nginx
controller
within
kubernetes
crew,
which
is
our
plugin
to
install
our
plugin.
So
we
have
a
slight
inception
here,
has
been
downloaded
more
than
150
000
times
so
astonishing
amount
of
of
number
tail
is
another
plugin
which
allows
the
streaming
of
logs
from
a
collection
of
pods.
A
A
The
first
section
is
going
to
be
informative,
while
the
second
one
is
going
to
be
a
guide
on
how
to
install
the
plugin
on
different
operating
systems
as
such
in
the
informative
part,
we're
going
to
have
the
version
the
page
to
our
repository
along
the
charts
description,
while
in
the
platform
side
we're
going
to
have
information
on
how
to
install
our
plugin.
So,
for
example,
we're
gonna
point
to
the
right
binary.
A
Now,
currently,
let's
see
how
to
distribute
our
greetings
plugin
to
do
so,
I'm
just
going
to
list
all
the
plugins
I
have
currently
available
on
my
machine.
I
don't
have
the
greetings
plugin
and
I
can
further
validate
that
by
doing
a
plug
crew
list
which
will
list
all
the
plugins
which
are
installed
crew,
the
greetings
plugin
is
not
there
anymore.
A
Of
course,
we
actually
need
to
specify
our
exactly
binary.
That's
going
to
be
executed
for
our
qctl
command.
Now,
let's
install
this
particular
plugin
with
crew.
With
that
I'm
going
to
do
a
quick
ctl
through
install
and
I'm
going
to
point
it
to
the
manifest
that
we
have
seen
just
plug
in
the
camera.
A
We
see
our
greetings
plugin
with
its
version
as
well,
and,
of
course
I
can
do
a
plugin
list.
It
will
be
identified
as
well
just
over
here
and
to
further
validate
that
our
plugin
works.
I'm
just
going
to
do
a
cube,
ctl
greetings.
We
will
go
to
our
shell
script
and
output.
Our
hello
cloud
native
message.
A
Cool
this
pretty
much
concludes
the
demo
for
the
crew
plugin.
Before
I
move
forward,
I
would
like
to
leave
a
few
takeaways
about
the
cube
ctl
plugins.
One
of
the
most
important
fact
about
cubesat
plugins
is
the
fact
that
we
can
further
extend
our
cli
and
provide
this
tailored
experience
for
our
end
users.
A
Another
thing
worthwhile
to
mention
is
the
fact
that
we
currently
cannot
override
the
existing
uctl
commands,
so
it
keeps
it
called.
Getpods
is
always
going
to
perform.
The
same
operation
will
not
be
able
to
change
that.
However,
we
still
have
a
bunch
of
plugins
which
are
just
one
install
away
with
crew.
A
Now
one
referred
to
the
wrappers:
these
usually
focus
on
a
graphical
representation
of
our
cluster
state,
so
the
wrappers
are:
how
can
we
visualize
some
of
the
resources
by
using
the
cubicle
commands,
as
mentioned
it's
all
about
this
operational
view
of
the
cluster
state?
So
it's
going
to
be
easier
for
our
end
users
to
understand.
A
Another
cool
key
feature
about
developers
is
the
fact
that
they
are
developer
first
now,
when
you
have
a
ui
of
your
cluster
state,
you
have
a
finite
amount
of
clicks
that
you
can
actually
perform
within
your
dashboard.
As
such,
it
can
really
help
this
developer
first
experience
because
our
engineers
will
be
able
to
explore
what's
happening
in
the
cluster
in
finite
world
of
actions
but,
more
importantly,
keep
still
wrappers.
Currently,
most
of
them
actually
are
providing
a
basic
coverage
of
the
cubesat
operations.
A
So
mainly
it's
going
to
focus
on
the
read-only
commands
such
as
gibson
keeps
it
you'll
get.
However,
it
provides
some
support
for
operations
such
as
scale,
debate
and
port
forward,
and
when
we
look
currently
into
the
ecosystem,
there
are
plethora
of
tools
by
provisioning,
the
ui
capabilities
from
which
octant
is
one
of
the
most
prominent
tools.
A
It
has
been
developed
by
vmware
actually
by
their
sra
team
and
in
addition
to
the
presentation
of
the
cluster
state
for
the
developers,
they
have
sections
for
the
kubernetes
operators
as
well,
so
they'll
be
able
to
see
the
nodes
and
any
information
associated
with
that
canines
is
another
terminal.
Ui
actually,
which
has
a
wrapper
around
all
the
qtl
commands
and
lens
is
another
tool
which
is
a
kubernetes
id
and
it
can
be
installed
on
any
operating
system
as
a
standalone
application.
A
Now
these
two
tools
have
completely
different
ways
of
provisioning.
The
template
capabilities,
however,
helm
at
the
moment,
uses
a
template
driven
approach,
which
means
we're
going
to
have
the
yaml
representation,
with
the
options
to
inject
values,
to
our
templates,
controversial
idea
here,
but
helm
tilts
slightly
towards
the
imperative
approach,
and
this
is
because,
if
you
think
about
of
a
chart
that
actually
includes
our
charts
or
it
has
like,
we
have
a
helm
umbrella
chart
which
actually
utilizes
avatars
as
well.
A
Customize
on
the
other
side
uses
a
template-free
approach,
meaning
that
we're
going
to
have
the
full
representation
of
our
manifest
and
that's
why
we're
going
to
have
declarative
approach
and
the
way
customize
works.
If
you'd
like
to
further
tailor
your
configuration,
that's
going
to
be
done
through
the
deep
mergers
now
to
tailor
your
application
or
your
deployment
for
free
help.
You'll
have
to
use
multiple
values
files,
while
we've
customized
you're
going
to
have
a
base
and
multiple
overlays,
and
once
we
have
our
templating
layer
introduced.
A
A
A
If
something
goes
wrong
in
production,
if
you
would
like
to
use
a
new
version
or
if
you'd
like
to
revert
to
an
older
version,
is
this
going
to
be
represented
by
a
myriad
of
clicks
or
it
is
going
to
be
something
you'll
be
able
to
restore
from
the
state
start
somewhere?
So
this
is
an
area
to
be
thought
about
with
this
approach
with
the
githubs
technique.
Actually,
some
of
these
issues
are
tackled.
The
githubs
approach
is
represented
by
a
set
of
git
repositories,
which
represent
the
desired
state
of
our
application.
A
A
The
githubs
model
works
with
a
full
approach,
which
means
that
if
it
identifies
any
changes
to
the
indicate
repositories,
it
will
be
able
to
identify
them
and
apply
them
to
the
cluster,
but,
more
importantly,
we're
going
to
have
a
version
state
of
our
cluster,
meaning
that
we
always
can
revert
using
git
to
a
version
of
the
cluster
which
was
up
and
running
and
with
no
issues
in
production
and
currently
the
github's
capabilities
are
provisioned
by
tools
such
as
flux
and
argo.
Cd
flux
is
a
tool
provisioned
by
weaveworks
and
currently
is
a
sandbox
cncf
project.
A
And
to
end
on
a
lighter
node,
I
would
like
to
introduce
quite
a
controversial
technique
which
is
sheet,
helps
and
shootouts
aims
to
control
the
kubernetes
state
using
google
spreadsheets.
It's
a
very
new
technique.
It
hasn't
been
developed
that
much,
but
at
the
moment,
if
its
mission
is
to
replace
xiaomi
with
spreadsheets.
A
So
if
you
heard
or
hear
heard
of
your
engineers
complain
about
yaml,
you
can
allow
them
to
manage
the
kubernetes
stage
with
spreadsheets
and
to
actually
showcase
this
particular
model.
I
would
like
to
use
the
shootouts
technique
to
scale
an
application
currently.
So
at
the
moment
I
have
let
me
just
move
this
slightly.
A
I
have
already
my
cluster
linked
to
a
google
spreadsheet.
Where
I
can
see
as
mentioned
here,
I
can
see
all
of
my
namespaces
and
currently
in
my
terminal
you'll
be
able
to
visualize
all
my
pods
in
my
argo
city,
namespace
and
currently
sheet
ops
actually
only
allows
the
scale
operations.
However,
it's
something
you
truly
care
about.
You
can
further
extend
it
to
support
other
operations
and
techniques
as
well.
A
So
if
I
would
like
to
increase
my
paragracity
radius
amount
of
replicas
to
free
instead
of
one,
I'm
just
changing
it
to
my
desired
state
in
my
google
spreadsheet-
and
this,
as
you
can
see,
is
already
applied
to
my
clustering
and
the
same
goes
with
the
scale
down
operation.
I
can
scale
it
to
2
and
this
will
be
able
to
be
identified
and
it
will
delete
the
cluster
or
cluster.
It
will
delete
a
pod
straight
away.
A
A
If
you
have
any
questions
in
regards
to
today's
talk,
please
reach
out
I'm
going
to
be
available
on
social
media
such
as
twitter,
now
and
team,
as
well.
You'll
find
a
more
detailed
blog
about
this
particular
talk
on
my
medium
account
as
well.
I'm
writing
any
other
blogs
on
the
new
tooling
that
I'm
exploring
you'll
be
able
to
find
them
there
enjoy
the
rest
of
the
conference.
Thank
you.