►
From YouTube: Never Should You Ever in Kubernetes
Description
Whether you are new to Kubernetes or have some experience under your belt, there are things you should simply never ever do in Kubernetes.
Kendall Miller, President of Fairwinds, was one of the first hires at Fairwinds and has spent the past 6 years making the dream of disrupting infrastructure a reality, while keeping his finger on the pulse of changing demands in the market and valuable partnership opportunities. He joins Stevie Caldwell, Senior Site Reliability at Fairwinds. Stevie supports a growing platform of micro services running on Kubernetes in AWS.
A
A
A
C
B
And
I'm
corey
quinn,
I
make
fun
of
things
that
hold
still
long
enough.
I
write
last
week
in
aws
I
fixed
the
aws
bill
for
fun
because
I
make
terrible
life
choices
and
once
upon
a
time
I
was
an
advisor
to
reactive
ops.
That
kendall
was
the
president
of,
and
one
of
the
things
I
said
is
that
reactive
ops
may
not
necessarily
be
the
best
name,
and
I
was
thinking
they'd
pick
something
great
and
inspiring
and
kendall
instead
said
you're
right,
it's
an
uninspiring
name,
but
people
have
heard
of
it.
A
Minor
detail:
hey
you
got
it.
You
gotta,
you
gotta
go
somewhere,
so
we
actually
invited
corey
to
come
here
and
do
this
and-
and
that
includes
mocking
us,
because
we
believe
it'll
make
for
a
more
entertaining
process.
So
that's
what
you're
here
for
today
we're
gonna,
be
talking
about
all
of
these
wonderful
things
here
related
to
kubernetes,
but
first
a
little
bit
about
fairwinds
and
then
we'll
dive
in
so
fairwinds
is
a
kubernetes
company.
We
provide
managed
services
and
software
as
well
as
a
whole
bunch
of
open
source.
A
All
in
the
kubernetes
space
we've
been
in
business
about
six
years,
used
to
be
called
reactive,
ops,
like
corey,
said,
and
building
and
maintaining
infrastructure
for
lots
and
lots
of
clients
at
scale
for
a
long
time
has
taught
us
what
are
the
macro
problems
that
people
deal
with
in
kubernetes
we've
written
a
bunch
of
open
source
that
address
some
of
those
problems.
We've
also
built
a
sas
product
that
we'll
tell
you
a
little
bit
more
about
at
the
end,
but
that
helps
you
know
if
you're
doing
kubernetes
right.
A
B
A
True
he's
the
only
one
who
can
make
it
work,
he
can
do
it
the
hard
way
or
the
easy
way
I've
heard
but
yeah
well.
So,
let's
dive
in
quick
poll
before
we
get
started
so
that
we
know
a
little
bit
about
the
audience.
So
we
know
where
to
point
folks
to
where
are
you
on
your
kubernetes
journey
and
you
can
fill
this
out
and
then
dave?
You
can
slack
the
results
to
me
and
I'll
read
out
a
few
of
the
I.
B
B
C
A
B
B
A
B
A
Up
and
running
with
kubernetes
in
production,
24
in
pre-production,
24,
just
figuring
out
how
to
spin
up
clusters
and
30
still
in
the
learning
phase,
so
welcome
people
from
all
stripes
and
stages
in
your
kubernetes
journey.
Let's
dive
into
really
bad
ideas.
Never
should
you
ever
in
kubernetes,
so
basics.
Well,
we're
talking
about
kelsey!
Let's
talk
about
doing
kubernetes
the
hard
way.
Why
and
stevie?
Maybe
you
can
jump
in
because
you've
done
kubernetes
the
hard
way
right.
What
was
so
delightful
about
that,
and
why
should
people
maybe
avoid
that.
C
I
think
that's
probably
the
way
to
go
ultimately
and
and
so
similarly
with
kubernetes
like
it's,
it's
good
to
know,
what's
going
on
under
the
hood,
so
that
when
you
have
complex
problems,
you
know
how
to
deal
with
them
or
you
have
some
idea
because
there's
so
many
moving
parts
in
kubernetes,
just
the
certificate
allocation
alone
within
a
cluster.
It's
kind
of
a
mind-boggling
thing,
which
is
why
it's
nice
to
have
automated
things
like
cops
or
whatever
take
care
of
that
stuff
for
you.
C
A
It's
a
good
analogy,
though,
building
a
car
from
scratch
to
understand
how
to
change
the
oil
or
hopefully
someday
change
wheel,
because
those
are
probably
the
problems
you're
going
to
have,
and
will
you
understand
them
better
if
you
built
the
car
from
scratch,
sure
I
guess,
but
it's
maybe
a
little
bit
of
overkill.
What
we're
gonna
say:
corey.
B
There
there
was
a
project-
I
was
a
big
fan
of
linux
from
scratch,
where
you
effectively
build
the
entire
tool
chain
and
build
linux
from
basically
nothing
and
get
some
stuff
installed.
It
was
a
heck
of
a
learning
process
and
it
was
a
great
tool
for
that
and
then,
once
or
twice
I
saw
companies
using
things
in
production
that
they
built
with
linux
from
scratch,
and
it's
oh
honey.
What
is
you
doing?
No
don't
do
that.
A
For
for
the
right
cost
it
can
be,
it
could
be
reallocated
the
I'm
just
going
to
move
on,
because
we
could
talk
about
this
the
whole
time.
But,
oh,
I
do
want
to
stop
and
say:
hey.
There
is
a
question
in
answer
bar.
You
can
drop
questions
in
this
throughout.
We
will
have
a
question
and
answer
section
at
the
end,
if
you're
running
into
things
you're
wondering
are
bad
ideas
or
not,
or
you
just
want
to
heckle
us.
Those
are
all.
A
Options
feel
free
to
drop
down
the
bar
at
the
bottom
and
zoom
has
q
a
drop
questions
in
there.
If
they're
relevant
to
what
we're
talking
about
at
the
moment.
We
may
answer
them
in
the
moment
or
we
may
save
them
all
for
the
end.
Okay,
the
basics
still
assume
kubernetes
is
right
for
your
simple
blog,
so
I
have
just
decided
that
I
really
want
to
be
a
well-known
personality
cory
and
I'm
going
to
start
writing
last
week
in
last
week
in
aws,
where
I
heckle
what
you
write
about
last
week
and
anyways.
B
Gonna
be
the
last
weekend
warrior
for
sure,
but
now
you're
you're.
Right
again,
I
don't
even
need
to
go
that
far
down
the
the
analogy
route.
I
spent
a
few
years
running
wordpress
myself,
which
means
that
now
I
last
week
in
aws
is
a
wordpress
blog
and
I
have
the
good
sense
to
pay
a
vendor
to
handle
it
for
me,
which
means
that
it
turns
out,
if
you
figure,
if
you
do
a
dig
on
the
actual
origin,
that's
right.
Last
week
in
aws
runs
on
gcp.
B
A
B
It's
the
problem
is
when
you're
learning
something
like
kubernetes,
you
need
the
hello
world
equivalent
and
a
blog
historically,
for
when
I
was
doing
puppet
training.
For
example,
standing
up
wordpress
was
one
of
the
capstone
projects
in
the
fundamentals
class,
and
that
was
because
it
was,
it
was
a
three-tier
app.
It
was
well
understood,
easily
well
understood
easy
to
grab
from
at
least
a
variety
of
places
and
cool.
The
problem
is,
I
think,
some
people
get
lost
along
the
way
and
they
think
that
oh
you're,
using
a
simple
application
as
a
blog.
A
B
A
C
I
mean
I
think,
for
me,
the
basics
is,
is
why
do
I
want
to
use
something
very
complex
for
an
offering
that's,
essentially
very
simple,
the
like
the
complexity
of
running
a
kubernetes
cluster,
especially
running
a
production
grade
kubernetes
cluster
first,
the
cost
of
it
is
is
can
be
higher.
You
know
we're
talking
about
running
a
high
availability
cluster
so
that
you,
you
know,
have
maximal
uptime
and
then
just
the
honestly
just
the
brain
power
to
troubleshoot
things
that
aren't
going
correctly
like
it's,
it's
unnecessary.
C
I
have
a
music
website
and
I
you
know
thought.
Should
I
build
this
myself?
Should
I
host
wordpress
locally?
Should
I
build
a
kubernetes
cluster
because
I
know
how
and
that'd
be
very
cool
melding,
my
two
things
together
and
in
the
end
I
was
like
I'm
gonna,
let
wix
take
care
of
this,
like
you
know,
choose
your.
B
B
Do
the
thing
that
differentiates
and
honestly
running
kubernetes
isn't
a
core
competency.
It
was
also
tied
to
the
idea
of
running
of
solving
global
scale
problems,
which
is
great,
but
maybe
when
you're
you
have
a
blog,
that's
99.
Your
monitoring
system
by
volume,
because
baby
seals
get
more
hits
than
your
blog
does.
Kubernetes
might
not
be
the
best
path
forward.
A
So
yeah
like
like
the
real
talk
around
that
is
kubernetes,
is
great.
When
you
need
that
level
of
complexity,
you
don't
for
your
simple
blog
right:
let's
talk
about
running
the
control
plane
on
spot
instances,
cory
you
go
in
there
and
you
tell
people
how
to
optimize
their
cost,
and
you
tell
them
to
put
everything
on
spot
instances
right
I
mean
that's
always
the
conclusion,
but
stevie
you've
actually
seen
this
done.
I
think-
and
why
is
this
a
bad
idea.
C
I
mean
you
know,
I
hesitate
to
say
things
are
bad
ideas
because,
but
I
wouldn't
recommend
it.
We
had
we,
we
had
a
client.
I
think
I
can
speak
about
said
client
with
anonymity
there
who
had,
who
was
running
spot
instances
for
their
control,
plane,
notes,
and
they
had
a
very
bad
time
once
when
their
spot
instances
like
disappeared,
because
you
know
I
I
actually
was
not
here
for
it.
C
B
I
do
want
to
clarify
that
for
those
who
may
not
be
steeped
in
aws
land,
spot
instances
on
aws
or
preemptible
instances
and
other
providers,
I
think,
are
effectively
unused
capacity.
That
is
far
less
expensive,
but
it
can
be
taken
away
at
any
time
as
the
caveat
there,
and
if
you
balance
it
out
correctly,
you
can
you
wind
up
saving
significant
money
and
your
site
stays
up
in
most
cases
that
I'm
aware
of
on
in
kubernetes
environments.
B
The
control
plane
is
not
a
large
percentage
of
your
node
count,
so
the
the
hassle
that
you
get
by
trying
to
save
a
little
bit
of
money
on
just
the
control
plane
piece
and
at
the
cost
of
oh
by
the
way,
we're
about
to
ruin
someone's
day
right,
probably
at
3am,
it's
the
juice
isn't
worth
the
squeeze.
There.
A
You
work
for
the
chaos
team
at
your
company
and
this
is
one
thing
that
you're
trying
to
test.
I
guess
it's
a
way
of
I
mean
in
theory.
It
can
all
be
everything
in
the
cloud
is
ephemeral
and
in
theory
you
can
run
your
control
plane
in
a
way
that
can
be
taken
away,
but
if
the
whole
thing's
taken
away
and
and
you've
you
haven't
it's
adding
additional
configuration
that
you
don't
want
to
have
to
mess
with
full
stop
absolutely.
C
A
C
Well,
yeah,
you
don't
want
to
run
your
like
your
hungry,
your
resources,
hungry
pod,
on
the
nodes
that
are
responsible
for.
Like
your
cluster
running.
You
know
I
I'd
like
to
think
of
it
as
like.
If,
if
you're
throwing
up,
if
there's
a
party,
you
prefer
to
go
to
a
party
at
someone
else's
house
and
then
like
you
can
leave
when
the
party
gets
out
of
control
and
things
start
breaking.
But
if
you're
having
a
party
at
your
house,
the
control
plane
then
like
when
people
start
wrecking
your
house.
C
B
It
does
it
does
get
to
a
good
distinction,
though,
from
from
certain
perspectives
I
mean
other
people
are
going
to
laugh
at
this.
But,
oh,
what
application
are
you
running
on
those
nodes?
The
answer
is
kubernetes
from
an
aws
or
a
provider
perspective
from
a
billing
perspective.
It's
just
one
application
that
behaves
super
strangely,
it
has
no
insight
into
what's
going
on
inside
of
that
application,
so
it
does
all
kinds
of
weird
crosstalk
stuff.
It
spins
things
up.
It
spins
things
down
wow.
B
That
sure
does
a
lot
of
auto
scaling
good
for
you,
and
it
makes
a
somewhat
naive
external
judgment
on
it.
The
the
the
challenge,
of
course,
is
understanding
what
like
what
the
bounds
of
that
that
paradigm
are
for
other
folks.
Oh,
what
application
you're
running
kubernetes
answer
that
in
the
wrong
context,
and
you
look
simple.
A
There
you
go
okay,
well,
let's
move
on
to
security,
so
we've
got.
We've
got
a
couple
different
categories
here
and
we're
going
a
little
bit
slow,
so
we'll
either
speed
up
or
we'll
end
up
skipping
a
few
but
run
a
container
is
root.
You
know,
never
should
you
ever
so
this
this
may
seem
obvious,
but
giving
over
privileged
access
to
anything
in
your
cluster
can
lead
to
over
privileged
behaviors
in
your
cluster.
Maybe
that's
that's
all.
I
need
to
say
about
that
anything
to
add
there
stevie
or
cory.
A
B
Yeah,
generally
speaking,
you
tend
to
want
to
give
the
cto
a
mock
environment.
It's
called
mock
environment
because,
whatever
they
do
in
there
you're
absolutely
going
to
mock
it.
There
is
a
there's,
a
school
of
thought
here
that
I
tend
to
believe
in
which
is,
I
I'm
sure,
having
a
the
cto
having
break
glass
access
to
stuff.
If
they
absolutely
need
it,
yeah,
that's
valuable!
You
want
to
be
able,
you
know
not.
B
Have
individual
sysadmins
hold
the
company
hostage
on
the
other
side
of
it,
though,
if,
if
I
can't
touch
something
that
means
it's
way
harder
for
me
to
break
it
and
I'm
forced
to
do
it
indirectly,
giving
giving
things
like
that
to
folks,
however
highly
in
place,
they
may
be
in
the
organization
very
often
means
that
you're
not
going
to
the
it's
not
worth
doing
and
to
use
a
change
analogy.
No
one
in
my
house
has
my
passwords
for
anything,
not
because
they
would
do
anything
nefarious.
B
I
mean,
if
you
don't
trust
your
partner,
it's
a
different
problem,
but
because
brother
to
protect
them
from
me,
because
as
soon
as
a
computer
here
stops
working
because
you
know
computers,
I'm
immediately
going
to
go
track
down
my
spouse
and
accuse
them
of
atrocities.
Why
did
you
log
into
my
machine
and
screw
up
my
local
python
development
environment?
And
then
everyone
looks
at
me
like
they
probably
should
it's
python
it's
supposed
to
be
that
way.
A
And
man
there's
so
many
like
smart
home
analogies
that
I
want
to
make
with
that,
but
I'm
going
to
stop
speaking
of
mock
environments.
Okay,
let's
talk
about
storing
all
your
secrets
in
plain
text
and
github:
never
should
you
ever
do
that
and
that's
because
people
like
you,
corey
are
sitting
around
looking
for
people
to
store
all
their
secrets
in
github
so
that
you
can
go
in
and
make
fun
of
them
right.
B
I
honestly
disagree
with
this
one,
I'm
a
big
fan
of
checking
in
credentials
to
this
for
a
constrained
test
environment
because
I
don't
know
how
to
configure
kubernetes,
but
if
I
check
the
credentials
in
someone
else
is
going
to
find
those
credentials
spin
up
a
kubernetes
cluster
and
then
get
it
mining
bitcoin.
All
I
have
to
do,
then
is
cancel
the
workloads
that
they've
done
capture
the
configuration
they
set
up
and
there
we
go
it's
it's
a
lot
more
ethical
than
outsourcing
work
to
you
know
your
interview,
candidates.
B
A
We
need
a
we
need.
We
need
to
have
an
entire
webinar
on
how
to
monitor
your
cluster
for
an
appropriate
threshold
of
bitcoin
monitoring,
so
that
you
know
that
now
it
has
been
configured
the
way
you
want
it
to
be
configured,
and
then
you
have
git
ops
setup
sufficiently
enough
that
it's
taking
the
live,
configuration
putting
it
back
and
get,
and
you
just
shut
the
whole
thing
down
copy
that
out
and
go
that's.
This
is
this
is
really
quality
forward.
Thinking
here,
corey
and
I
need
to
pause
for
a
second
there's.
A
Two
people
with
hands
up
you're
welcome
to
raise
your
hands.
I
don't
have
any
way
to
like
unmute
you
and
let
you
ask
a
question
so
type
a
question
in
the
chat.
If
you
have
one
you're
welcome
to
keep
your
hand
up,
but
at
least
it's
virtual
and
your
arm's,
not
gonna,
get
tired
anyways.
Let's
keep
going,
give
your
family
cluster
admin.
I
feel,
like
you've
already
basically
touched
on
this
query.
A
C
It's
it's
the
original,
it's
the
original
gui
yeah.
They
they
literally.
So
they
you
know
they
hard-coded
cluster
ips
into
their
applications
and,
as
most
people
know,
and
some
people
don't,
but
you
know
cluster
ips,
your
pod
ips.
Rather
those
change
your
cluster
ips
change,
those
things
you
can't
rely
on
that.
So
it's
best
to
let
kubernetes
has
these
things
built
in
for
you
to
make
your
life
easier
use.
Them
is
what.
A
C
B
Mean
it
just,
I
think
it's
fine
to
do.
You
just
have
to
understand
what
you're
getting
into
when
you
do.
It
just
means
that
doing
a
migration
is
going
to
involve
hijacking
bgp,
which
apparently
is
easier
than
most
cloud
migrations.
I've
seen
so
yeah,
just
as
long
as
you
know
what
you're
doing
and
can
prepare
accordingly
go
nuts.
A
B
A
Need
to
go
ahead
and
click
all
the
buttons
so
that
you
can
learn
some
of
these
lessons
the
hard
way.
Okay,
let's
get
to
reliability.
Never
should
you
ever
configure
all
the
things
via
a
gui,
because
I'm
putting
I'm
putting
these
I've
got
these
nice
little
mottos
here.
You
need
to
be
able
to
click
it
or
you
get
a
ticket,
don't
be
thick
point
and
click.
These
are
mottos
for
people
who
are
gonna
use
gui
all
the
time.
A
I'm
really
overly
proud
of
these
few
statements,
but
the
the
problem
with
configuring
everything
via
gui.
Is
you
end
up
with
one
person
who
remembers
all
the
buttons
they
pushed
and
unless
that
all
somehow
got
codified
as
code,
maybe
or
that
person
leaves
you
know
it's
really
hard
to
replicate
your
environment
with
clicks,
you
can
write
a
workbook
on
how
to
go
through
and
click
all
the
things.
I
actually
did
this
kind
of
work
in
college.
I
got
paid
to
write
technical
writing.
A
B
I
also
I
don't
want
to
come
across
as
shaming.
There
isn't
there's
an
evolution
here
that
you
go
from
the
least
advanced
to
most
events.
You
start
off
using
the
console,
you
point
and
click:
that's
how
everyone
works.
Then
you
graduate
something
like
terraform
or
cloud
formation,
then
beyond
that
you
get
into
more
even
more
dynamic
stuff
like
pollumi
or
the
cdk,
and
the
ultimate
tier
that
you
finally
ascend
to
is
using
the
console
and
lying
about
it.
So
again,
the
trick
is,
you
have
to
lie
and
not
admit,
you're
doing
it.
B
A
B
For
you,
it
was
seriously
console
recorder.
Two
is
a
extension
that
ian
mackay
out
of
australia
makes
maintains
it's
on
github.
It
sits
there
in
chrome
or
firefox,
and
it
watches
everything
you
do
in
the
console
and
then
generates
out,
not
only
whatever
you
did
whatever
language
you
want,
botto
it
does
it
with
the
cli
option.
It
doesn't
terraform,
it
doesn't
cloud
formation,
doesn't
cdk.
A
Never
should
you
ever
let
your
sres
do.
Rdd
rdd
stands
for
resume
driven
development,
so
you
know
if
your
ops
team
is
like
hey,
you
know.
What
I
want
to
do
is
use
x,
y
or
z,
because
it's
the
hottest
new
thing,
and
I
want
to
be
able
to
put
that
on
my
resume.
That's,
maybe
not
the
best
idea
for
how
to
you
know,
build
your
entire
infrastructure.
A
There's
some
interesting
fancy
tech
out
there
and
go
explore
those
things,
but
don't
use
them
for
the
sole
purpose
of
getting
your
next
job.
I
mean,
unless
you
can
do
that.
I
guess
like
if
you're
gonna,
you
know
if
you
know
where
you
want
to
go,
and
you
know
that
you
need
to
have
experience
with
spinnaker
to
get
there
go
ahead
and
implement
spinnaker.
I
guess
if
nobody's
gonna
notice,
right
or
no
yes,.
C
A
A
Man,
a
lot
of
these
reliability
ones
are
the
ones
that
I
want
to
talk
about,
but
never
never
should
you
ever
run
docker
swarm
on
top
of
nomad
on
top
of
kubernetes,
and
I
this
sounds
ridiculous,
but
I
have
seen
companies
say
they
use
one
to
do
one
piece
of
their
orchestration
another
to
do
the
scheduling
another
to
do
something
else
and
for
some
reason
you
know
just
adding
layers
of
complexity
is
like
attractive
to
some
people.
If
kubernetes
isn't
complex
enough.
B
When
you
start
viewing
the
cloud-native
computing
foundation's
landscape
as
a
to-do
list,
you
generally
wind
up
in
trouble.
We
do
have
a
question
that
I
want
to
draw
attention
to
andy.
Allred
asks
could
slash,
should
we
run
combined
worker
and
control
plane
nodes
I'm
against
this,
but
a
senior
director
is
being
thrown
under
the
bus
by
the
questioner
and
saying
they
want
to
do
it.
B
My
take
on
that
just
to
throw
mine
out
there
before
I
have
the
experts
who
actually
know
what
they're
doing
saying
that
is,
it
usually
comes
from
a
misguided
misunderstanding
of
something:
either
they
saw
it
as
part
of
a
demo
and
thought
it
was
a
best
practice
or
they're
trying
to
save
money
in
some
strange
places.
My
answer
is
a
hard.
No.
I
would
rather
scale
down
the
size
of
the
nodes
for
the
control
plane
and
call
it
good.
But
if
I'm
wrong
on
that,
please
don't
don't
be
shy
about
smacking
me.
C
No,
I
think
this
speaks
back
to
the
like.
Don't
run
workloads
on
your
control,
plane
piece,
there's
a
reason
that
they're
the
best
practice
is
that
they're
separate
you
know
if
they're.
Usually,
these
sort
of
things
are
spurred
on
by
like
cost
concerns,
and
there
are
other
better,
safer
ways
to
run
a
cluster
and
control
your
cost
than
trying
to
combine
your
nodes
all
into
one.
C
A
Yes,
yes,
yeah,
and
we
will.
We
will
get
a
little
bit
some
more
of
that
in
a
minute
but
feel
free
to
keep
the
questions
coming
and
thanks
corey
for
pulling
that
one
out
by
all
means:
never
should
you
ever
easter
eggs,
single
points
of
failure
and
by
easter
egg
we
mean
go
and
hide
really
interesting,
single
points
of
failure.
Corey.
What
do
you
have
in
mind
for
this?
B
Oh,
you
can
hide
places
anywhere,
usually
the
big
one
that
everyone
loves
to
talk
about
is
the
undocumented
thing
that
everyone
quote
unquote
knows
just
ask
the
single
person
who
knows
it,
and
then
they
just
took
a
job
somewhere
else,
and
it's
just
I'm.
Just
gonna
bury
this
landmine
nice
and
pat
for
my
colleague
to
stomp
on
and
then
blame
them
for
it.
Blameless
postmortems
are
harder
to
achieve
when
the
person
you
want
to
blame,
isn't
in
the
room
or
is
no
longer
an
employee,
because
then
I'll
pile
them
up.
B
The
they're
always
single
points
of
failure,
regardless
just
a
question
of
where,
where
in
the
stack
it's
going
to
be
and
trying
to
hide
them,
and
and
oh
we're
just
going
to
pretend
it's
not
there,
but
even
if
you
think
you've
gotten
rid
of
all
of
them,
you
haven't
they're
still
there.
The
trick
is
to
be
realistic
about
what
it
takes
to
down
your
site
for
most
folks.
If
half
the
internet
is
down
today,
it's
okay,
if
you're,
not
showing
people
cat
pictures,
remember
how
good
the
pictures
are.
Maybe
we're
better
for
it.
A
A
A
I
ran
across
a
group
of
people
and
asked
them
what
they
did
and
they
managed
the
infrastructure
for
all
of,
I
think
it
was
all
of
colorado's.
9-1-1
call
centers,
and
I
was
like
oh,
like
dang.
Your
job
actually
is
a
matter
of
life
and
death
when
things
go
down
and
that's
intense,
so
most
people
to
corey's
point
are
doing
things
like
serving
up
cat
pictures
or
twitter
for
pets
right
right,
cory.
B
A
B
I
take
it
a
step
further,
very
often
when
people
build
things
in
a
naive
way,
the
only
part
of
their
application
that
works
when
the
thing
locks
up
is
the
part
that
says
I'm
okay,
so
you
wind
up
with
monitoring,
says
everything's
fine.
So
it's
almost
when
a
customer
internal
external
calls
in
to
say:
hey,
your
nonsense
is
broken
you're,
arguing
with
them
and
implying
they're,
incompetent
and
possibly
calling
them
a
liar.
It
honestly
for
an
awful
lot
of
shops,
their
actual
monitoring
system
they
pay
attention
to
is
twitter
or
the
customer
support
desk.
A
B
I'll
take
a
step
further
monitoring
and
qa
are
aligned
on
the
same
axis.
If
done
well,
you
wind
up
having
there's
very
little
distinguishing
characteristic
between
the
two,
the
biggest
lie
in
all
of.
I
guess
this
industry
is
to
do
in
a
file
like
yeah.
I'm
gonna
get
here,
implement
monitoring
later
yeah
I
have
I
have
so.
I
have
comments
in
the
in
some
of
my
code
that
I'll
go
back
and
fix
this
soon
that
are
older
than
I
am
almost
doesn't.
C
Go
well,
and
if
you
start
your
monitoring
this,
the
sooner
you
start
your
monitoring,
the
sooner
you
can
start
getting
baselines
for
how
your
applications
should
be
behaving,
which
will
inform
a
lot
of
decisions.
You
make
down
the
line
about
like
how
you
scale,
you
know
where
your
traffic
spikes
are
things
like
that.
A
Well,
and
that
gets
us
to
efficiency.
If
you
have
good
baselines,
you
know
how
to
configure
things
to
actually.
You
know
right
size
things
to
actually
scale
up
or
scale
down
when
they're
supposed
to,
but
needing
you
need
that
baseline
you're
right.
That's
that's
a
great
point.
Stevie!
Never
should
you
ever
put
workloads
in
texas-sized
houses
or
tiny
houses
corey.
You
look
like
you're
upset
about
that.
You
want
to
put
your
word
for
it.
B
In
both
directions,
from
my
perspective,
it
comes
down
to
blast
radius.
If
you
have
a
few
big
things
and
one
of
those
things
goes
down,
a
lot
of
things
can
be
affected
you
you
can
do
it,
but
you
need
to
have
the
workload
aware
of
these
things,
so
it
the
classic
example
in
the
before
kubernetes
days.
Back
when
things
made
sense
was
cool.
B
We
have
a
vms
that
do
a
primary
and
a
secondary
for
a
service,
because
the
primary
winds
up
going
down
and,
of
course,
we've
emotioned
those
things
to
be
on
the
same
physical
server,
oh
and
then
that
server
goes
down,
oh
and
by
the
way
those
services
needed
to
bring
a
server
back
up.
Oh
so
it's
there's
that
the
as
far
as
put
everything
in
tiny
houses.
B
I'm
tell
me
more
about
that,
because
I
tend
to
suggest
that
as
a
good
development
practice
we'll
start
off
building
things
in
constrained
environments.
You
can
always
scale
up
if
you
need
to,
but
it's
a
crutch,
you're
eventually
going
to
run
out
of
headroom
on
so
it's
best
not
to
develop
in
that
direction.
But
tell
me
more.
A
Well,
there's
there's
a
difference
between
start
out,
small
and
increase
and
then
there's
a
difference
between
that
and
let's
take
this
thing
that
clearly
needs
significantly
more
computing
power
and
stick
it
on
the
smallest
possible
thing,
and
so
it's
always
going
to
be
running
at
100
cpu
and
it's
still
not
going
to
be
working.
Yeah.
B
A
C
A
lot
of
people
start
off
allocating
way
too
much
and
then
you've
got
way
more
nodes
or
larger
nodes
in
your
cluster
than
you
need,
because
you
know,
kubernetes
schedules,
your
workloads
based
on
what
you
request.
So
if
you
request
200
millicore
and
you
only
use
eight
you're
still
like
that's
you're,
still
like
that,
nothing
else
will
get
scheduled.
That
would
conflict
with
that.
So
then
you
know
you
have
more
headroom
than
you
actually
need
for
your
for
your
applications,
and
I
think
people
struggle
with
that
quite
a
bit
and
what
I've
seen.
B
On
some
level,
two
the
whole
premise
of
kubernetes
and
things
like
it.
If
there
is
anything
like
it,
don't
email
me,
it
has
been
that
you
can
start
to
look
at
your
entire
data
center
side
lens
of
an
operating
system.
So
at
that
point,
you're,
basically
buying
resources,
disk
capacity,
ram,
cpu,
and
at
that
point
it
almost
becomes
a
function
of
economics
and
if
you
take
a
look
in
most
environments
from
most
providers,
the
super
tiny
things
and
the
super
big
things
are
not
the
most
cost
effective.
B
I
mean
one
of
the
most
hilariously
bad
economics
is
some
of
the
instances
that
they
sell
from
aws
that
have
12
terabytes
of
ram
their
market
is
being
for
sap,
hana
and
knowing
nothing
other
than
that
about
sap
hana.
I
know
I
probably
don't
want
to
use
it
and
first
those
instances
are
hilariously
expensive
on
a
cost
for
performance
basis.
B
And
secondly,
I
know
that
it
doesn't
matter
what
the
instance
cost,
because
the
license
for
sap
hana
is
going
to
be
stratospheric
when
they
bit
when
aws
goes
out
of
their
way,
to
build
an
instance
specifically
for
your
workload,
I'm
just
going
to
go
ahead
and
cut
the
at
the
end
of
it's
not
inexpensive.
For
that
workload,
all
right.
A
Getting
to
the
end
of
efficiency
here
and
and
we'll
get
to
q
a
here
in
just
a
second:
never
should
you
ever
ignore
auto
scaling.
So
I'll,
be
relatively
brief
on
this
one.
There
are
a
lot
of
people
using
cloud
and
using
cloud
native
technologies
like
kubernetes
that
make
things
like
scaling,
easy
and
not
auto
scaling
and,
like
that's
one
of
the
biggest
promises
of
the
cloud,
don't
don't
move
to
kubernetes
and
turn
off
auto
scaling.
It's
really
good
at
that.
What
corey.
B
So
the
whole
premise
of
the
cloud
is
that
great
you
can
you
can
auto
scale
to
size.
Your
workload
and
people
are
super
interested
in
implementing
auto
scaling
to
scale
up,
because,
if
you're
not
able
to
serve
your
customers,
your
tcp
now
terminates
on
the
floor
and
everything
breaks,
whereas
people
forget
always
to
figure
out
how
to
scale
down
sensibly
because
the
failure
mode
there
is
you're
just
spending
a
bit
of
extra
money,
and
then
we
saw
when
pandemic
hit.
B
In
many
environments,
where
user
traffic
fell
off
a
cliff
and
infrastructure
spend
is
a
straight
line
because,
oh
well,
we
haven't
ever
actually
tested
scaling
down
some
of
their
native
database
products
for
the
longest
time
aurora.
We
we
can
auto
scale
or
elastically
resize
volumes.
It
was
always
about
making
it
bigger
to
to
in
small
in
the
database,
required
restore
it
to
a
smaller
one
at
which
I
couldn't
believe
it.
But
customers
didn't
really
seem
to
complain
because
it
turns
out.
B
A
B
B
If
you're
going
to
have
it
on
kubernetes,
you
better,
damn
well,
have
a
plan
for
volume,
persistence,
backups,
restores
etc,
but
the
idea
on
its
face
isn't
actively
ridiculous.
You
just
need
to
architect
for
it.
What
happens
if
a
container
goes
away
and
doesn't
get
replaced
for
a
little
while?
How
do
you
wind
up
doing
sinking
on
these
things?
Personally,
I
find
it's
worth
more
pain
than
value
in
many
cases.
B
It's
certainly
not
the
first
thing
I
would
seek
to
shove
into
a
into
a
kubernetes
cluster
unless
I
was
trying
to
get
the
high
score
and
something
horrifying,
but
I
I
also
don't
see
that
it's
necessarily
a
if
I
saw
it
in
an
environment.
My
immediate
response
would
be
tell
me
more.
Not
oh,
my
god.
What
are
you
doing.
C
Yeah,
I
agree
I
mean
I,
I
am
a
strong
proponent
of
using
honestly
if
there
are
solutions
that
are
offered
to
you
that
are
managed
solutions
within
like
the
environment
that
you're
running
in
so,
for
example,
with
aws.
If
you're
running
your
workloads
on
aws,
I'm
a
big
proponent
of
using
you
know,
aws's
data
store
offerings
of
using
rds
or
aurora
or
whatever
versus
rolling
your
own.
Just
because
of
you
know
this
is
this.
I
keep
coming
back
to
this
point
but
like
why
do
it?
C
If
you
don't
have
to,
is
it's
kind
of
what
I
come
back
to
and
with
when
you're
running
you
know,
kubernetes
one
of
the
promises
or
sort
of
the
the
thing
that
is
built
upon.
Is
this
idea
that
all
the
data
is
ephemeral
so,
like
that's,
why
things
get
to
move
around
as
freely
as
they
do
and
it
doesn't
matter
if
you
lose
a
node
or
two
or
whatever?
C
But
when
you
start
getting
into
persistent
data
issues
like
with
databases,
then
you
have
to
as
to
corey's
point,
you
know
you
have
to
plan
accordingly,
you
have
to
think
about.
Where
are
you
storing
that
stuff?
What
happens
when
the
pod
that's
running?
Your
database
needs
to
go
somewhere
else.
Does
it
get
scheduled
on
a
node,
that's
in
another
availability
zone
and
then,
like
the
volume
that
it
was
writing
to,
is
no
longer
available
to
it?
C
B
This
is
also
opinionated.
I
understand
that,
but
I
te
and
the
things
that
I
build.
I
tend
to
wind
up
fronting
them
with
the
data
store
with
a
rest
api,
something
relatively
simple
and
straightforward.
That
takes
a
json
object
that
I
encode
badly
and
then
throw
it
there.
The
reason
being
is
a
little
bit
of
extra
work
and
for
some
performance
cases
I
get
that's
not
going
to
work,
but
on
the
other
end
of
it.
That
means
that
I
can
then
do
a
bunch
of
things
on
the
back
end
of
the
data
store.
B
I
can
replace
it
with
something
else
entirely.
I
can
migrate
providers
and
it
doesn't
require
me
to
re-architect
everything
that
talks
to
it.
In
fact,
I'm
told
this
is
an
internal
amazon
thing
where
oh
you
want
to
talk
to
some
other
group.
You
can't
just
sneak
around
their
api
and
talk
to
the
data
store
directly.
That
is
verboten,
so
it's
work
to
get
there.
It
does
add
some
additional
front
loaded
work,
but
it
does
massively
increase
flexibility.
B
A
Right
well:
let's
move
on.
We've
got
a
little
bit
of
time
here.
There's
a
couple
hands
up
we'll
come
back
to
a
wrap
up
here
with
a
few
slides
at
the
end
and
some
some
places
you
can
go
to
get
more
info,
but
if
you
have
questions
feel
free
to
drop
the
questions
in
the
chat
or
the
q
a
right
now,
we've
got
a
few
that
we
can
work
through,
but
they're
still
hands
up.
A
I
don't
know
if
people
are
accidentally
hitting
the
raise
hand
button
or
what
but
feel
free
to
drop
something
in
the
q.
A
it's
right.
Next
to
the
raised
hand
button.
Let's
see
what
types
of
apps
should
I
move
to
kubernetes.
First
wordpress!
No,
I
mean
hey.
That's
that's
that's
a
serious
question.
Most
companies
are
not
actually
cloud
native
they're
cloud
adoptive
and
they
have
something:
that's
big
and
hairy
already
existing
somewhere
in
a
data
center
or
in
the
cloud
that
they're
just
managing
directly
and
they're.
B
I
love
how
the
one
person
you're
asking
me
the
one
person
who
doesn't
work
with
this
stuff
for
a
living,
but
my
take
is
always
pick
something
small
that
if
it
wind
that
ideally
winds
up,
if
it
breaks
it's
not
disastrous,
like
you
know
the
payroll
database,
probably
not
first
wave
and
ideally
something
that
is
stateless.
The
point
where
you
can
have
multiple
instances
of
it
running
well
and
sure
if
you
look
at
it
from
a
where
you're
running,
all
you're,
putting
dealing
with
the
complexities
and
the
challenges
and
travails
of
kubernetes.
B
For
that,
it's
a
proof
of
concept,
because
you're
going
to
learn
things
as
you
go
you're
going
to
learn
the
terminology
you're
going
to
learn
how
things
like
on-call
work,
you're,
going
to
understand
what
this
remaining
of
condescension.
If
you
talk
to
the
wrong
people
about
this
stuff,
but
it's
something
that
you
that
you
get
you
get
your
feet
wet
with
it
in
a
way
that
isn't
actively
painful.
The
trick
is
not
to
stop
there
or
think
that
that's
somehow
a
limitation
of
it.
B
You
have
to
intentionally
choose
something
that
that
works
for
this,
then
you
can
start
moving
up
the
stack
to
things
that
are
more
complex.
You
can
start
looking
at
migrations
that
require
knife
switch
cutovers
and
at
some
point
you're.
Finally,
either
going
to
move
the
the
stuff,
that's
truly
difficult
or
you're
going
to
give
up
halfway.
Declare,
multi-cloud
or
hybrid
victory,
claim
that's
what
you're
aiming
at
the
whole
time
and
call
it
a
day.
B
Not
that
there's
any
shame
in
that
I
mean
that's
what
every
multi-cloud
or
hybrid
story,
mostly
that
you
see,
is,
is
but
you're
in
good
company
when
it
happens
and
there's
also
nothing
no
shame
by
the
way
in
getting
halfway
through
something
and
realizing.
Oh
that
thing's
not
a
good
fit
for
kubernetes.
After
all,
great
I
mean
validate
that
with
people
who
are
not
me
who
know
what
they're
doing,
but
that's
not
inherently
a
terrible
thing,
and
it's
not
a
condemnation
of
what
it
is
you're
doing
or
how
you're
doing
it.
B
The
easiest
thing
in
the
world
to
do
is
build
an
architecture.
A
green
field
on
a
whiteboard
you've
got
something
that
exists.
Maybe
it's
legacy,
which
is
condescending,
engineer
talk,
for
it
makes
money
great
treat
that,
with
a
little
bit
of
respect,
don't
necessarily
just
yellow
it,
because
someone
on
hacker
news
said
it
was
a
good
idea.
It
turns
out
that
conference
stages
are
not
people
testifying
under
oath
you'll,
learn
that
one
way
or
another.
C
Yeah,
I
totally
agree,
there's
no
shame
and
I
think
it's
actually
the
the
smart
move
in
many
cases
to
back
away
when
you
realize
that
it's
not
a
good
fit,
there's
it's
it's
terrible
to
try
and
shoehorn
something
into
kubernetes
that
doesn't
run
well
in
kubernetes.
Because
of
you
know
the
way
it's
designed
or
the
way
it
runs
or
its
dependencies
or
whatever
it
makes
it
a
very
hard
life
for
for
you
and
for
everyone
who
has
to
work
with
it.
Small
services
start
off.
C
A
So
we
had
one
question
come
in.
Is
there
a
solution
to
do
billing
with
cost
breakdown?
For
example,
I
have
one
namespace
for
each
client.
I
want
to
calculate
the
monthly
infra
cost
for
each
namespace.
So
boy
have
we
got
software
for
you
and
boy?
Am
I
glad
you
asked
so
so
we
have
a
tool,
fairwinds
insights,
that
does
relative
daily
cost
it
breaks
down
by
service
and
tells
you
which
namespace
those
things
are
in.
It
also
helps
you
optimize.
A
You
know
the
the
your
resource
requests,
what
you're
requesting
versus
what
you
could
be
requesting
and-
and
we
even
have
some
data
that
shows
you
what
you're
going
to
save
over
time.
So
fairwinds
insights
come
have
a
sales
conversation
with
us.
We'll
save
you
money.
There
are
probably
other
tools
out
there
that
do
something
similar.
This
is
the
one
that
I
know
because
it's
the
one
that
we
make
but
yeah
that's
a
place
to
start.
I
don't
know.
B
B
C
B
C
A
B
Cloudability
is
one
of
the
big
competitors
too
they're
all
right,
but
they're
expensive
in
terms
of
percentage
of
bill,
there's
a
whole
spiel
on
that.
The
problem
I've
seen
when
I,
when
dealing
with
real
customers
who
care
about
kubernetes
workloads,
are
there
are
two
questions
that
they
tend
to
not
see.
A
good
answer
for
one
is
shared
resources,
things
that
have
to
exist.
How
do
you
allocate
and
attribute
those
out
and
the
other?
And
it's
more
nefarious
and
there's
no
great
tooling
option
today
that
I'm
aware
of
is
data
transfer?
B
If
I
have
in
aws,
which
is
where
I
live,
you
have
two
services
talking
to
each
other,
that
data
transfer
is
either
free
or
if
they're,
in
two
availability
zones
for
durability
purposes,
it's
two
cents
per
gigabyte
and
at
scale
when
we're
talking
about
petabyte
scale,
workloads,
that's
a
lot
of
money
and
again
from
the
aws
perspective,
what
application
is
doing?
All
of
that
kubernetes
allocating
things
like
data
transfer,
while
simultaneously
trying
to
teach
your
cluster
to
be
affinity,
have
ac
affinity
is
a
massively
challenging
problem.
B
As
a
as
the
as
the
right
way
to
do
this,
whenever
I
see
tools
aimed
at
this
they're,
always
looking
at
the
dollars
and
cents
of
ram
disk
and
cpu,
which
is
fine,
I
mean
that
is
a
good
starting
point
and
worst
case
you
can
wind
up
looking
at
and
then
just
effectively
proportioning
on
a
proportional
basis.
Until
you
have
one
outlier
application,
that
is
super
chatty.
But
if
that's
you,
it's
also
not
the
hardest
thing
in
the
world.
B
In
most
environments,
once
you're
aware
it's
happening
to
dive
in
and
okay,
what
what
is
the
chatty
thing?
And
then
you
have
someone
pop
up
the
other
side,
and
it's
basically
oh
well,
I
don't
know
how
storage
works,
so
I
just
put
it
all
on
the
wire
and
hope
I
can
transmit
it
all
before
it
comes
back
and
if
I
run
out
of
space
with
that,
I
just
start
setting
it
somewhere
further
away.
Instead,
that's
what
a
storage
area
network
is
right,
just
needs
longer,
cables,
yep.
A
So
stevie
you're
muted-
I
don't
know
if
you're
going
to
add
something
to
that
or
if
you
were
just
agreeing
we're
going
to
wrap
up
here.
There's
one
more
question:
is
it
possible
to
use
fairwinds
insights
on
prem?
The
the
short
answer
is
yes,
there's
there's
a
more
complex
answer
like
it's
it's
coming
very
soon,
but
you
know
if,
if
you're
interested
in
looking
at
fairwinds
insights
go
sign
up,
kick
the
tires,
there's
a
free
trial,
you
can
try
the
sas
product.
A
We
are
not
going
to
give
you
the
on-prem
option
unless
there
is
a
contract
signed.
So
that's
that's
something.
You'd
have
to
look
into
so
go
find
out.
If
the
tool
is
the
right
tool
for
you,
but
then
if
you
need
it
on
prem,
the
answer
is
yes
and
finally,
we
have
a
couple
things
to
show
you
on
your
way
out,
so
go
check
out.
Fairwinds
insights.
I
didn't
intend
to
pull
that
up
and
do
a
you
know
brief.
Showing
of
just
one
thing.
A
Insights
talks
about
security
efficiency,
reliability,
sits
in
your
ci
pipeline
and
helps
keep
people
from
deploying
terrible
things
into
kubernetes.
You
can
watch
this
webinar
and
go
back
and
try
to
educate
your
people
on
all
the
bad
ideas
that
they
should
avoid,
or
you
can
use
our
software
and
it
can
help
you
avoid
those
things
for
you.
So
that's
fairmon's
insights
inside
stopfairwinds.com.
A
B
A
So
let's
go:
let's
go
to
the
end
here
and
just
say
you
know,
we'd
love
for
you
to
answer
this
question.
This
is
useful
for
us
to
know.
You
know
what
people
are
wrestling
with
now,
but
if
you
want
to
go
take
a
look
at,
we
have
a
white
paper
on
kubernetes
best
practices
and
we
will
send
out
these
slides
and
a
recording
of
this.
B
Not
to
potentially
damn
you
with
this
observation,
but
I
do
want
to
say
that
over
the
years
we've
been
talking
to
other
a
lot
of
a
lot
of
my
understanding
of
kubernetes
and
the
non-ridiculous
stunting
parts
has
come
from
conversation
with
you.
Folks.
If
I
were
somehow
cornered
and
had
to
run
kubernetes,
I
would
absolutely
reach
out
to
you
folks,
first
and
see
if
I
could
convince
you
to
do
business
with
me
now.
You
understand
what
kind
of
customer
I
am
is
the
answer.
B
A
Yeah,
if,
if
you
need
kubernetes
help,
fairwinds
has
something
for
you.
We
can
make
your
kubernetes
problems,
go
away
or
help
you
help
your
team
get
software
and
tools
and
practices
in
place.
That
will
help
you
do
so.
So
thank
you
all
for
attending.
This
has
been
never
should
you
ever
in
kubernetes
and
have
a
great
rest
of
your
day.