►
From YouTube: Five Hundred Twenty-five Thousand Six Hundred K8s CLI’s - Phillip Wittrock & Gabbi Fisher, Apple
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.
Five Hundred Twenty-five Thousand Six Hundred K8s CLI’s - Phillip Wittrock & Gabbi Fisher, Apple
With the success of the Kubernetes ecosystem, users now have a many choices when it comes to Kubernetes tools. While it's great for users to have options, lots of choices can make it difficult for Kubernetes users to make decisions or know where to start. Additionally, organizations may use several different tools internally that users must familiarize themselves with. A high-level understanding of the this ecosystem is necessary to easily navigate the world of Kubernetes. Gabbi and Phillip will provide an overview of well-known and up-and-coming Kubernetes CLIs. They will then explore the broader architectures used by these tools, and finally how users should think about their own tools they are building. CLI’s covered include kubectl, helm, kustomize, k/jsonnet, kpt, cue and k14s . CLI patterns covered include templating, DSLs, OpenAPI / schema and configuration functions.
https://sched.co/ek9o
A
A
A
B
So
the
first
problem
we're
going
to
look
at
is
you
want
to
define
your
application
in
some
higher
level
construct
construct
that
maps
to
some
lower
level
apis?
So,
for
example,
what
you
want
to
do
is
run
a
golang
program
rather
than
saying
I
want
to
run
this
deployment
service,
config
map,
et
cetera,.
B
The
second
sort
of
problem
we
often
see
is
you
really
want
to
run
the
same
construct
in
varying
ways
across
environments
and
the
ways
they
vary
usually
are
at
a
relatively
low
level.
So,
for
instance,
do
you
want
to
run
your
go
program
in
staging
canary
prod
us
west,
prod
us
east
all
with
slightly
varying
values.
B
And
the
third
problem,
we're
going
to
look
at
is
really
about
taking
high
level
supplemental
concerns
that
are
loosely
coupled
to
any
specific
abstraction
or
any
specific
invariant
and
really
just
cut
across
them
right.
So,
for
instance,
you
want
to
set
up
logging
or
some
sort
of
a
sidecar
container
for
all
your
applications,
whether
they
are
golang
or
spring
boot
or
rails
or
node.js,
or
something
else.
B
And
when
you're
building
a
production
grade
system
you're
likely
going
to
need
to
come
overcome
all
of
these
problems
right
so,
for
instance,
you're
going
to
want
to
say,
I
want
to
run
my
golang
application.
I
want
to
run
it
with
splunk
logging
and
I
want
to
run
it
in
staging
canary
in
production
all
with
slightly
varying
values.
A
B
So
the
cli's
approach
these
problems
in
a
couple
of
different
ways
and
the
way
a
cli
approaches.
A
problem
really
has
a
big
impact
on
what
tradeoffs
it
offers
and
how
well
it's
able
to
address
each
one.
So
we're
going
to
go
through
each
of
the
kind
of
high-level
approaches
that
cli
use
to
tackle
these
problems
and
show
an
example
using
a
real
tool.
B
A
A
A
B
All
right,
and
so
gavin
just
demonstrated
using
helm
with
templating
some
of
the
great
things
about
templeton
are
is
a
relatively
simple
approach.
It's
relatively
easy
to
understand.
What's
going
on,
and
it's
relatively
mature
and
sort
of
the
limitations
of
templating
are
that
there's
really
only
so
much
you
can
put
into
the
template
as
inputs
right,
so
you
can't
supply
every
field
that
you
want
to
maybe
set
in
the
low
level
types
and
it
doesn't
natively,
really
tackle,
variance
or
cross-cutting
concerns.
B
The
second
sort
of
approach
we're
going
to
look
at
is
yaml
composition
and
so
an
example
of
this
is
customize.
With
yaml
composition.
The
inputs
specified
by
the
user
are
still
in
the
native
form
of
the
api
that
the
server
supports,
and
so
really
it's
about
breaking
up
your
yaml
configuration
files
into
composable
pieces
and
factoring
out
either
like
a
common
thing
like
a
namespace
from
a
bunch
of
different
yaml
files.
A
In
fact,
you
can
layer
customize,
on
top
of
other
clis,
more
focused
on
abstraction,
like
helm,
using
customize,
you
can
post
process
helm,
charts
and
create
variants
of
out
of
the
box
applications
and
even
better.
You
can
generate
these
variants
instead
of
having
to
manually
fork
and
modify
your
application.
Configuration.
A
All
right,
so,
in
our
last
example,
we
briefly
covered
how
you
could
customize
the
configuration
of
your
helm,
chart
application
using
the
values.yaml
file.
But
what
about
the
case
where
you
actually
want
to
have
two
different
variants
of
these
helm:
charts,
one
for
staging
and
one
for
a
production
cluster
and
just
to
dive
into
this
example?
A
little
more.
Let's
say
I
wanted
to
have
different
metrics
retention
dates
for
my
different
prometheus
servers
deployed
to
staging
versus
production
clusters.
A
A
A
A
So,
to
run
this,
we
can
create
a
small
script
around
the
customized
cli
that
allows
us
to
just
apply
these
patches
whenever
we
want-
and
we
can
invoke
in
this
example-
which
patch
we
want
to
use
by
using
a
environment
variable
to
say
what
environment
we're
deploying
to.
So
we
are
going
to
set
our
deployment
environment
to
staging
and
then
we're
going
to
run
helm
install
similar
to
last
time,
but
we're
going
to
add
a
new
argument
called
post
renderer
and
what
this
does
is.
B
Thanks
for
the
demo
gabby,
and
so
as
we
saw
that
a
yaml
composition
is
great
for
producing
like
a
variant
or
factoring
out
some
piece
of
yamamo
from
another
piece
variant
or
animal
composition
allows
multiple
layers
to
be
defined.
So,
unlike
templating,
which
tend
to
be
binary
relationships,
you
can
stack
more
and
more
layers
on
top
of
each
other
and
they
do
stage
true
to
the
underlying
api.
B
So
you
can
understand
like
how
you,
if
you
want
to
set
a
particular
field,
it's
relatively
straightforward,
to
understand
how
to
set
it
that
field
really
their
limitations.
Are
that
one
they
cannot
express
higher
level
abstractions.
You
are
operating
at
a
low
level,
inserting
snippets
here
and
there.
So
if
you
just
want
to
say,
set
this
field
and
then
it
goes
and
generates
a
bunch
of
different
other
stuff,
that's
not
something
you're
going
to
get
from
yaml
composition
and
it
can't
express
any
sort
of
dynamic
or
reactive
logic.
B
B
The
third
approach.
We're
gonna
look
at
are
configuration
domain,
specific
languages
and
configuration
dsls.
Are
languages
specifically
designed
for
users
to
express
configuration
and
solve
problems
related
to
configuration,
they're
optimized
for
expressing
and
composing
and
transforming
configuration
data,
and
they
frequently
use
something
like
inheritance
or
unification
as
their
primary
technique.
A
A
And
you
can
see
that
what
is
spat
out
are
our
deployment
manifests
with
our
corresponding
custom
retention
dates
and
just
to
show
this
typing
in
action.
Let's
set
replicas
up
here
to
a
string
which
it's
not
supposed
to
be
and
you'll
see
that
we
q
was
able
to
give
us
an
error
related
to
this
mismatch
between
types.
B
B
B
It's
often
part
of
a
framework
which
can
do
more
than
just
expressing
configuration,
but
can
also
manage
stuff
like
rolling
out
your
configuration
or
solving
other
problems
for
you
and
oftentimes.
These
frameworks
are
capable
of
pulling
in
configuration
from
other
sources,
so
you
can
use
helm
or
customize
or
a
dsl
tool
with
them
as
an
input
source.
B
There
is
complexity
that
comes
with
writing
a
program
like
the
ability
to
just
look
at
the
program
and
know
that
this
is
going
to
output.
The
right
thing
is
more
challenging
when
you
have
functions
and
you
have
for
loops
and
branches
and
these
sorts
of
things
and
that
when
they
are
packaged
with
an
orchestration
solution
that
it
may
be
difficult
to
tease
the
two
apart
and
they
may
be
tightly
coupled
enough
that
you
can't
just
use
the
general
purpose
sdk
with
your
arbitrary
orchestration
solution.
You're
using
today.
B
A
So
in
this
root
deployment
animal
we
provide
information
merely
relating
to
what
kpt's
reconciliation
of
sorts
will
match
on
to
add
for
more
fields
to
a
particular
deployment,
and
we
use
something
called
a
starlark
script
to
handle
that
in
kpt
land.
But
we
won't
delve
into
that
too
much
in
this
demo
just
know
when
we
run
kpt
function
run
and
then
try
to
run
it
to
get
the
yaml
and
enable
star.
So
we
can
run
that
starlog
script.
A
B
The
the
cons
are
one
that
writing
a
controller,
for
instance,
is
more
difficult
than
writing
a
template,
and
that's
true
here
as
well:
you're
evaluating
a
much
broader
set
of
inputs
and
reconciling
the
state
of
the
system.
So
it's
going
to
be
more
difficult
to
write
those
modules
because
they
are
more
sophisticated,
and
the
second
limitation
here
is
that
it
is
a
really
relatively
new
and
experimental
approach.
B
A
All
right
now
that
we've
had
a
chance
to
go
over
five
technique,
use
techniques
used
by
kubernetes
clis.
We
can
evaluate
how
each
type
of
cli
can
help
us
with
certain
objectives.
So
on
the
top
two
rows.
Templating
and
ample
composition
emerge
as
the
ideal
option
for
folks
who
want
to
keep
their
logic
simple.
A
A
Moving
down
the
y-axis,
we
can
see
that
domain-specific
languages
and
general
purpose
languages
offer
similar
functionality
with
less
simplicity,
traded
for
more
customizability.
The
choice
between
the
two
language-based
options
hinges
on
how
declarative
versus
imperative
you
want.
Your
logic
to
be
dsls
are
also
great
if
you
invest
in
your
configuration
system
and
can
standardize
on
a
single
approach,
whereas
general
purpose
languages
are
useful.
A
If
you
want
to
develop
solutions
in
a
language
you're
already
familiar
with
or
want
to
ingest
multiple
input
types
into
an
orchestration
system
with
some
last
mile
changes
and
finally,
our
relative
newcomer,
controller-esque
clis,
allows
you
to
layer
and
combine
logic
so
for
folks,
looking
to
mix
and
match
logic
on
various
types
of
inputs,
as
well
as
try
something
kind
of
fun
and
new
controller-esque
clies
might
be
a
good
fit
for.
You.