►
From YouTube: Birds of a Feather: How to Train Your KubeAdmins - Stephany Spencer, USA TODAY NETWORK
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
Birds of a Feather: How to Train Your KubeAdmins - Stephany Spencer, USA TODAY NETWORK
Containers and Kubernetes management is a new skillset. You can't go out and hire as many experts as you'd like, so how do you train your own? This BOF will describe how USA TODAY NETWORK brings new hires up to speed in this brave new world. This is a chance to discuss what has worked well, not so well and what we can all do better going forward. Bring your on-boarding stories to share and discuss how we can build more Kubernetes "experts".
To learn more: https://sched.co/GrTf
A
All
right,
so
thanks
everyone
for
coming
to
listen
to
me
today.
I
know,
there's
a
lot
of
great
talks
to
choose
from
so
my
name
is
Stephanie
Spencer
and
I've
been
working
at
USAA
today
network
for
about
a
little
under
a
year
so
and
before
this
job
I
took
like
a
semi,
hiatus
and
I
was
working
in
University
land,
and
so
since
joining
USA
Today
I've
spent
the
last
year
learning
how
to
be
a
kubernetes
admin,
and
so
this
is
a
topic.
A
That's
really
dear
to
my
heart
and
I
spend
a
lot
of
time
thinking
about
mostly
because
I've
gone
through
the
process.
Now
this
is
I
wanted
to
remind
everybody
that
this
is
a
birds
of
a
feather
so
really
I'm,
hoping
to
have
a
discussion,
because,
while
I
have
ideas
on
how
we
could
do
things
better,
I
know,
everybody
else
has
gone
through
their
own
trials
about.
A
A
We
run
all
of
those
digital
rug
presences
on
gke
and
over
the
past
year,
we've
migrated
from
numerous
small
kubernetes
clusters
to
multiple
large
kubernetes
clusters
and
we
split
up
our.
We
run
multi
tenant
clusters
across
25
plus
different
developer
groups
like
over
300
developers.
We
for
those
that
are
curious.
We
do
our
multi
tenant
based
on
namespace
level
and
sometimes
even
dedicated
node
pools.
A
No
because
I
closed
them
out
and
forgot
to
save
them
right
before
this,
so
we're
gonna
wing
it
yep
I
had
something
but
no
not
now,
so
we
will
have
a
microphone
that
we
could
come
over
and
talk
about
ideas,
so
please
feel
free
jump
in
add
to
the
conversation.
This
is
a
discussion,
so
I
was
gonna
first
start
and
talk
a
little
bit
about
how
we
did
ours,
how
I
have
gone
through
see
if
this
is
coming
up
there
we
go
now.
Let
me
get
that
on
the
screen.
Oh
sorry,
give
me
one.
Second.
A
While
I
figure
this
out
so
we
began
when
I
started
I,
we
had
a
little
bit
of
a
outline
for
what
people
can
do
working
with
kubernetes,
we
had
some
basic
labs.
That
said,
all
right,
you
are
a
developer,
you're,
a
new
hire.
What
you
want
to
do
is
go
through
these
labs
to
figure
out
how
of
ära
pieces
all
work
together.
Now
that
was
great
except
the
Liao's
were
really
focused
on.
This
is
our
technology
and
not
really
on.
Why
would
you
want
to
use
that?
A
All
right-
and
this
is
what
we
begin
all
of
our
developers
are
on-
is
this
like
platform
labs
page,
where
we
walk
through
a
lot
of
the
technologies
that
we
have
available
to
everybody,
but
in
particular,
over
the
past
year,
I've
spent
a
lot
of
time
thinking
about
what
we
do
and
how
do
we
onboard
people?
So
we
began
our
own
set
of
labs
for
moving
developers
off
of
existing
cost
clusters
on
2gk.
A
We
have
a
really
wide
range
of
people
I'm
talking
about
not
just
our
new
hires
within
our
group,
our
cloud
engineers,
but
we
also
need
to
have
a
certain
level
of
expertise
in
all
of
the
developers
out
there
and
while
they
may
not
need
the
same
ultimate
depth,
the
steps
are
still
much
the
same.
For
the
first
part,
so
we've
come
up
with
is
a
process
where
we
go
through
and
break
out
the
various
pieces,
and
we
try
to
make
it
so
that
we
everything
get
builds
on
each
other.
So
the
basic.
A
How
do
you
connect
the
cluster?
What
is
a
container
registry?
Let's
get
started
and
on
through
using
home
and
accessing
your
secrets
and
so
forth.
Now
this
has
worked
well,
I'd,
say
better
than
the
previous
system.
In
that
we've
tried
to
broaden
it
so
that
more
people
it
was
accessible
to
more
people
without
coming
in,
without
having
all
that
background
knowledge,
because,
as
you're
probably
aware,
kubernetes
is
hard.
A
And
I
would
like
I'm
sorry
I
got
distracted,
that
what
I'd
like
to
hear
are
some
ideas
about.
How
can
we
break
this
down
and
make
this
more
accessible
to
what
mm
to
our
developers
to
the
folks
that
just
need
to
use
kubernetes?
They
just
need
to
run
their
applications
and
by
following
that
path
we
can
build
up
that
expertise
because
those
so
my
first
question,
if
I
had
had
my
slides
that
I
would
like
to
hear
back
is
ideas
on
how
to
present
the
kubernetes
ecosystem
to
folks.
A
Usually,
everybody
starts
with
that
big
chart
of
here's
kubernetes,
here's
your
controllers
or
in
your
muster
at
CD
and
so
forth,
but
that's
too
much
so
my
first
question:
is
anybody
found
a
good
way
to
break
that
down
outside
of
the
FIP
ebooks
I
mean
they're
great
and
all
don't
get
me
wrong.
I
have
some
little
stuffed
animals
around
here
too,
but
open
the
floor
to
ideas
on
how
to
introduce
kubernetes
without
overwhelming
or
just
shout
it
out
if
he
doesn't.
B
C
On
that,
in
general,
documentation,
if
we're
breaking
things
and
documentation
Xin
to
personas
at
other
companies
that
have
been
at
actually
getting
people
who
are
within
that
ecosystem
of
persona,
to
help
write
in
that
documentation
and
building
out
lab
work
as
you're
doing
it
has
really
helps
focus
of
like
where
your
assumptions
lie.
So.
C
E
So
when
it
came
to
the
engineers
and
having
them
get
things
online
and
actually
working
in
kubernetes,
what
we
did
is
we
built
the
skeleton
of
the
deployment.
The
animal
are
the
yamo
files
and
service
files
and
all
those
things
he
presented.
Those.
But
then,
in
a
group
presentation
we
actually
just
started
a
HelloWorld
application
and
worked
through
the
HelloWorld
application
and
networking,
and
all
of
that
and
it
kind
of
demystified
a
lot
of
the
things
that
they
were
worried
about.
A
E
A
E
G
A
H
H
You
know
what
the
next
API
call
might
need
to
be,
or
what
the
next
you
know,
coop
CTL
command
would
be
those
but
not
giving
that
it
like
say:
hey,
okay,
once
you
know
how
to
find
that
initial
information
we're
gonna,
let
you
flounder
a
little
bit
right
to
get
the
time
that
it
takes
to
really
understand
it,
because
it
because
it
is
a
very
complex
ecosystem
and
you've
got
to
learn
a
little
bit
by
floundering
and
trying
things
out
and
fail.
You
know
you
know
about
get
lists.
H
I
I've
been
trying
to
create
a
like
a
series
of
I
know
walkthroughs,
where
I
just
take
like
a
very
small
piece
of
something
that
somebody
might
need
to
do
like
templating
and
then
just
have
like
the
basic
amount
of
stuff
in
involved
in
that
and
then
having
it,
something
that
can
actually
walk
through
and
do
themselves
and
then
peppering
it
with
like
lots
of
watches
so
that
they
can
actually
watch
how
the
objects
are
interacting
and
created
together.
So
like
they're,
creating
a
deployment
actually
have
another
tab.
That's
watching
pods
and
watching
replica
sets.
I
J
J
Yes,
so
with
regards
to
the
software
deployment
right,
so
what
challenges
were
facing
now,
so
what
we're
solving
right,
what
problem
we
have
and
when
we
break
from
manolito
micro
services,
what
does
it
mean
for
us
how
we
deploy
so
what
we
have
to
change
and
what
tools
we
need
to
use
for
them
to
to
achieve
that,
and
then
already
we
can.
You
know
breaking
these
to
multiple
pieces
like
how
it's
designed
and
so
on
and
so
forth,
but
we
have
to
understand
why
we
need
it
to
begin
with.
So.
K
See
if
I
can
do
this
with
the
speaker,
that's
close,
I
think
a
big
part
of
getting
people
there
with
a
minimum
of
frustration
is
for
them
to
know
that
there
is
not
just
that
there
is
support,
but
there
is
support
whose
purpose
is
to
be
that
support,
not
just
hey.
If
you
have
a
problem
paying
one
of
our
admins
and
slack
and
they'll
get
back
to
you
when
they're
not
doing
something
else,
there
need
to
be
people
who
that
is
their
priority.
K
Is
you
know,
you're
our
new
crop
of
people
that
were
on
boarding
on
this?
We
want
to
make
sure
you
get
on
board
it,
and
so,
if
you
ping
them,
they
will
get
back
to
you
right
away,
because
that
is
their
job
is
to
be
your
on
board,
at
least
for
this
week.
It
doesn't
mean
that
you
have
to
have
somebody
that
that's
their
only
job,
but
like
hey,
we're,
gonna
rotate,
you
off,
you
know,
instead
of
doing
your
on-call
week,
you're
gonna
be
doing
this
this
week.
This
is
your
on-call
week.
Do.
K
Think
you
put
as
many
avenues
out
there
as
you
can,
whether
it's
slack
or
tickets
or
whatever,
because
different
people
feel
more
comfortable
accessing
that
help
in
different
ways.
I
mean
I
personally,
have
absolutely
no
problem
with
just
dropping
a
slack
message
and
then
get
back
to
me.
When
you
see
it
some
organizations
people
feel
more
comfortable.
If
they
have
a
ticket,
they
can
look
at
bookmark.
K
A
K
G
L
So
well
gonna
tell
how
loud
to
talk.
So
we've
done
two
things
and
a
lot
of
it's
already
been
mentioned
around
making
sure
that
there's
a
direct
channel
to
from
my
standpoint,
I'm
an
Operations
guy,
so
a
direct
channel
to
the
operations
team
to
really
help
with
answering
questions,
especially
when
the
development
teams
are
first
going
into
kubernetes
and
we
ramped
up
very
slowly.
We
didn't
try
and
boil
the
sea.
L
Actually
in
our
operations
Channel,
we
have
an
internal
slack
like
tool,
so
the
developers
actually
sit
on
the
same
channel
that
we
do.
They
answer
questions
if
we
don't
get
around
to
it
or
if
we
don't
respond
quickly
enough
in
a
lot
of
cases,
they
do
we
actually
went
and
we
started
out.
I
had
a
saying
of
kubernetes
isn't
broken
every
time.
L
Any
developer
came
to
me
and
said
it's
not
working
I
always
said:
kubernetes
is
broken,
let's
dive
in
and
try
and
see
where
the
actual
problem
is,
and
so
now
I
have
other
devs
saying:
kubernetes
isn't
broken,
which
is
really
kind
of
cool,
and
then
one
other
thing
I
was
going
to
offer
is
from
an
administrator
side
which
is
really
where
I
am
I'm.
Not
a
developer.
L
L
A
That
help,
when
you
were
doing
it
that
way,
did
it
help
identify
what
those
little
cups
of
water
we're
going
to
be.
Since
you
went
through
exactly
the
same
process,
you're
trying
to
teach
others,
or
did
that
informant
or
did
you
just
kind
of
go
into
it
with
an
idea
of
how
you're
gonna
categorize
it
first
and
then
make
yourself
run
through
it?
First
actually,.
L
The
the
development
teams
somebody
much
smarter
than
I
decided,
which
applications
that
make
our
company
money
we're
going
to
go
into
kubernetes
first,
so
we
were
able
to
find
that
small
application
that
the
good,
highly
skilled
development
team
could
work
with,
learn
how
to
do
it,
and
then
we
could
start
learning
on
what
problems
we
might
have
as
we
rolled
it
out
into
kubernetes
and
how
we
would
scale
it
things
of
that
nature.
But
what
I
learned
from
doing
that
or
what
I
learned
is
we
are
going
through?
L
That
is
I
needed
to
personally,
as
the
operator
I
needed
to
understand
more
how
the
entire
platform
would
work.
So
I
started
trying
to
anticipate
what
thing
are
they
going
to
try
and
use
next?
Let
me
go
try
and
use
that
first
so
that
when
the
development
team
comes
to
me
and
says,
I
want
to
use
scheduled
tasks
or
cron
jobs
or
whatever
they
call
them
nowadays,
I've
already
used
it
I
learned
how
it
worked
when
it
was
in
pre-alpha
and
I
understand
how
it
works,
so
that
I
can
help
the
development
teams.
L
M
So
one
of
the
practices
that
our
team
found
to
be
really
effective
for
not
just
onboarding
new
people,
but
also
for
educating
people
who
have
been
around
but
didn't
quite
know
all
the
different.
You
know
pieces
that
went
into
our
platform.
It
was
just
the
idea
of
going
the
well
agile
route
of
saying
we're.
A
M
N
One
of
the
big
tools
that
we
used
for
training
a
lot
of
our
administrators
when
we
initially
on-boarded
into
kubernetes,
was
a
coop
con.
Strangely
showing
people
lots
of
links
to
different
recorded
presentations
here
was
pretty
invaluable
for
our
admin
team,
although
we
did
kind
of
up
to
point
a
gun
to
their
head
and
say,
sit
down
and
watch.
This
hour-long
talk
also
sharing
source
code,
all
of
our
developers,
all
of
our
admins.
All
of
our
templates.
N
We
all
contribute
all
the
manifests
to
a
central
repo
where
everyone
can
see
everyone
else's,
and
this
kind
of
lets
us
evangelize,
I,
guess
the
things
that
best
fit
our
needs
so
that
our
anyone
can
see
at
a
moment
what
that
what
they
might
need
to
do
to
do
like
a
like
a
stateful
set
deployment
or
something
like
that
and
also
coop
CTL,
explained
I'm,
not
sure
if,
anyway,
if
you
all
are
familiar
with
that,
but
it
has
been
the
most
useful
command
for
all
of
anybody.
Who
has
a
question
of
how
do
I?
A
N
I
mean
we
definitely
don't
point
people
and
just
say:
hey,
go
to
YouTube,
but
there's
different
topics
for
different
items
like
for
resource
requests
and
limit
setting.
Tim
Hawken
had
a
great
one
at
goop,
cones
2016
or
for
just
the
general
architecture.
You
know,
there's
there's
a
lot
of
there's
a
lot
of
good
ones
out
there,
so
it
does
definitely
need
to
be
curated,
but
it's
curated
by
the
people
who
first
started
using
the
system
and
then
need
to
advance
that
to
the
rest
of
the
organization.
H
One
of
the
things
that
I
liked
from
the
point
of
the
gentleman
back
there
was
this
idea
of
unifying
tools,
one
of
the
things
that
we
did
operationally.
That's
really
helped
us,
as
we
matured
is
to
decide
that
we
were
gonna,
invest
heavily
in
Prometheus
within
kubernetes,
and
so
we
said,
every
single
thing
we
deploy
as
a
platform
component
has
to
be
monitored
with
Prometheus.
H
So,
whether
that's
a
sidecar
or
you
know,
compiled
something
into
the
docker
image
and
then
when
we
were
made
that
same
requirement
for
application
development
teams,
we
had
a
lot
of
patterns
that
were
already
developed
and
we
we
really
built
a
community
around
prometheus
Prometheus
and
kubernetes
and
kind
of
linked
those
things
together,
so
that
now
it's
like
okay,
well,
there's
a
number
of
strategies
that
we've
done.
We
have
a
number
of
examples
and
it's
just
another
way
that
you
can
bring
in
kind
of
an
expertise
that
might
cross
between
admins
and
developers.
D
Then,
if
they
don't
have
the
doctor
experience,
we
can
really
have
for
them,
but
right
now
we
have.
We
actually
have
automated
pipeline
to
do
that.
So
really,
based
on
the
experience
is
like
they
say.
If
you
never
use
doctor,
try
with
the
docker
to
replicate
the
VN
solution.
If
you
use
docker,
then
how
do
you
try
to
wrap
your
docker
compose
with
the
community?
D
If
you
use
Grenada
before
then
we're
talking
about
how
you
restructure
your
kind
of
manual,
customed
architecture
and
pipeline
with
the
kinetic
components,
so
they
can
become
very
nature
for
us
and
because
we
always
have
someone
who
is
more
experienced,
then
we
also
do
something
like
lunch
and
then
to
just
share.
But
I.
Think
to
the
point
that
I
feel
the
problem
is
not
about
onboarding.
For
us,
it's
more
about
how
we
eyes
like
define
a
clear
responsibility
of
ownership,
because
after
onboarding
people
know
about
it
but
who's.
Maintaining.
D
What,
because,
as
cognitive
becomes
so
easy
from
training
our
model
to
deployment
and
the
we
also
have
the
pipeline,
it
become
a
little
bit
difficult
to
say,
hey,
who
is
taking
care
of
what
it
looks
like
the
data
Santa
can
take
some
care
something,
but
that
the
Deaf
op
can
also
do
something.
And
so,
when
a
request
coming
over
is
like
there's
a
lot
of
coordination,
and
we
just
don't
have
a
very
creation.
So
the
workflow
can
be
good
with
someone
who
is
pretty
experienced
but
can
be
a
chaotic
when
someone's
less
experienced.
K
I
just
want
to
go
back
to
when
somebody
was
talking
about.
You
know
sending
people
links
to
videos
and
having
a
watch
party
and
I
think
that
the
collaborative
discussion
of
the
the
content
is
great.
I
myself
would
be
hesitant
to
send
somebody
a
video
and
say
make
sure
you
watch
this
because
we're
all
gonna
sit
around
and
talk
about
it.
K
So
just
I
would
say
if
you,
if
you
have
some
media
format,
that
you
want
people
to
consume,
make
sure
there
are
alternative
formats
and
methods
for
them
to
get
the
same
info
and
then
have
the
meeting
and
say:
okay,
I
expect
everybody
either
watch
the
video
read
the
transcript
did
the
exercises.
You
know,
listen
to
the
audio
in
the
car.
Whatever
now,
let's
sit
down
and
talk
about
it.
K
F
So
we
had
a
lot
of
experience
in
this
specific
issue,
since
we
work
with
at
least
30
university
researchers
and
the
researchers
could
be
something
like
who
just
their
first
coding
project
did
is
finish
their
first
coding
project
in
MATLAB
for
for
solving
some
math
problems,
yeah
very
early
stage,
and
what
we
found
helpful
is
to
document
exactly
what
they
are
working
on
or
they're
solving.
So,
for
instance,
maybe
all
they
need
to
do
is
insert
run
a
image
inside
the
community.
F
So
we
document
you
know,
here's
a
template,
you
replace
the
image
tag
to
something
that
you
built
locally
and
another
thing
we
found
helpful
as
a
lot
of
in
the
concepts
in
darker
are
a
lot
more
easier
to
grasp
than
kubernetes.
So
what
we
told
our
our
users
is
just
run
this
in
docker,
and
then
we
created
a
document
saying
these
commands
translate
to
this
in
kubernetes
and
and
there's
another
perspective
to
this.
F
We
also
have
very
experienced
or
power
users
for
or
users
who
need
power
access
to
kubernetes,
or
maybe
some
we're
bringing
a
new
employee.
In
that
case,
what
we
found
helpful
is
there's
a
project
on
github
called
kubernetes
the
hard
way
and
there's
also
a
tutorial
in
google
cloud.
That
goes
over
some
of
the
cube
killer
comment,
so
we
just
say
you
know:
go
through
this
documentation
or
community
the
hard
way
or
go
to
the
google
cloud
tutorial
and
follow
the
instructions.
So
those
two
are
also
helpful.