►
From YouTube: Debugging Kubernetes Applications on the Fly
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Hi
everyone
thanks
for
joining
me
here
today.
My
name
is
josh.
Hendrick
I'm
a
senior
solution,
engineer
at
rook
out
and
today
I'm
going
to
talk
to
you
a
little
bit
about
debugging
kubernetes
applications
on
the
fly
so
we'll
talk
about
today
is
is
starting
with
really
the
evolution
of
software
development
and
and
why
organizations
today
are
considering
adopting
kubernetes
as
their
platform
of
choice
for
running
distributed
cloud
native
applications
at
scale.
A
We'll
look
at
some
of
the
challenges
that
organizations
typically
face
when
they're
they're
making
those
decisions,
and
probably
some
of
the
questions
that
you
should
ask
yourself.
If
you're
thinking
about
moving
towards
towards
kubernetes
or
or
maybe
you've
already
started
it.
We'll
look
at
some
of
the
the
challenges
developers
often
face
when
they're
debugging
kubernetes
applications.
It's
a
different
approach
from
traditional
application
servers
that
many
might
be
used
to.
A
So
we'll
we'll
talk
a
little
bit
about
that
and
finally,
we'll
we'll
talk
about
a
potentially
better
approach
to
debugging,
one
that
takes
advantage
of
modern
debugging
tools
that
can
really
save
developers
a
lot
of
time
and,
at
the
end
of
the
day,
of
course,
make
your
customers
happy,
because
you're
solving
their
issues
at
a
faster,
more
rapid
pace,
so
we'll
jump
into
it
and
talk
a
little
bit
about
how
things
have
changed
recently
right.
A
So
there's
been
a
number
of
changes
in
the
recent
years
in
terms
of
how
we
build
you
know,
develop
and
deploy
software
applications
at
scale.
A
A
number
of
years
ago
we
were
building
these
tightly
coupled
single
applications,
which
required
these
big
bang
releases.
It
required
organizations
to
align
across
different
teams
to
come
together
to
put
out
these.
What
we
now
call
monolithic
applications
right,
these
softwares
that
were
composed
of
these
components
that
couldn't
be
interdependently
deployable.
A
What
we
realized
very
quickly
is
that
we
needed
a
better
approach,
and
the
approach
that
was
initially
taken
was
a
move
towards
what
we
called
service
oriented
architectures,
where
we
started
to
decouple
these
application
components
allowed
them
to
be
a
little
bit
more
interdependently
deployable.
They
were
more
coarse-grained
services
that
communicated
over
apis
to
one
another
and
that
brought
us
to
to
really
where
a
lot
of
organizations
are
today.
And
if
you
talk
to
the
vast
majority
of
organizations,
they
are
moving
or
have
moved
towards
a
paradigm.
A
We
now
call
microservices
right,
which
consists
of
having
a
number
of
loosely
coupled
interdependently
deployable
components
that
really
fit
well
into
agile
development
paradigms,
where
you
have
teams
that
are
responsible
for
building
one
or
more
different
services,
and
it
makes
life
easier
in
that
those
individual
services
can
be
deployed
independently
of
one
another.
A
If
one
component
goes
down,
it
doesn't
take
down
the
entire
application
and
and
really
allows
for
running
applications
at
scale
in
a
little
bit
easier
approach
and
kubernetes
has
really
been
the
platform
of
choice
for
those
organizations
that
are
looking
to
build
microservices
and
we'll
talk
a
little
bit
about
why
that
is,
and
before
I
jump
into
that
it
wouldn't
be
a
a
tech
conversation.
If
we
didn't
throw
in
a
a
dilbert.
I
like
this
one,
I
thought
it
was.
It
was
quite
funny
because
it
really
resonates
with
with.
A
I
think
the
initial
thought
of
a
lot
of
organizations.
Do
we
need
to
re-architect
our
our
applications,
or
can
we
just
take
them,
put
them
in
containers
and
move
them
to
the
cloud
or
move
them
to
kubernetes
and
get
the
value
that
we're
looking
for
a
lot
of
times.
As
you
probably
know,
it's
not
quite
that
simple
right.
A
You
can't
just
containerize
something
push
it
to
a
new
platform
and
expect
to
get
all
the
benefits
and
all
of
all
of
the
value
out
of
it
requires
a
little
bit
more
thought
in
terms
of
of
re-architecture
and
really
educating
everyone
from
the
organization
on
on
new
approaches
and
new
paradigms.
A
Taking
these
these
monoliths
doing
a
lift
and
shift
with
with
some
level
of
re-architecture
towards
these
cloud
or
or
on-prem
deployments
a
lot
of
the
and
actually
all
of
the
the
major
cloud
providers
now
have
these
manage
kubernetes
offerings
which
allow
organizations
to
deploy
their
applications
in
either
an
on-prem
or
cloud-based
kubernetes
cluster.
A
A
lot
of
organizations
are
even
moving
their
ci
cd
workloads
onto
platforms
like
kubernetes,
which
allow
really
for
a
lot
of
resiliency
and
scale
as
they
build
and
deploy
those
kubernetes
applications
and
and
the
adoption
is,
is
really
growing
incredibly
fast.
So
organizations
have
been
adopting
this
for
the
last
number
of
years
and
even
more
are
are
jumping
on
lately.
A
A
So
kubernetes
is
nice
because
it
can
automatically
do
that
for
you,
based
on
the
specification
that
you
tell
it,
you
tell
it
how
you
want
to
how
you
want
to
run
your
application
and
it
handles
all
of
that
underlying
scheduling
and
deploying
of
your
application
for
you
of
of
different
containers
and
different
components
so
that
they're
running
in
the
right
places
at
the
right
time.
A
It
allows
for
self-healing
as
well,
so
you
can
automatically
replace
any
failing
containers
or
kubernetes
pods
that
are
running.
So
if
something
goes
down,
it
can
handle
automatically
bringing
those
back
up
and
it
tries
to
do
that
automatically
for
you
and
it's
flexible.
It
allows
you
to
run
on-prem
and
the
cloud.
A
lot
of
organizations
are
looking
at
hybrid
deployment
models
where
you're
running
some
things
on-prem.
Some
things
in
the
cloud
and
it's
it's-
it's
really
an
amazing
tool
if
you
take
the
time
to
to
do
it
right.
A
So
there
are
adoption
challenges
right,
anytime,
you're,
moving
to
to
a
new
platform
and
paradigm
like
kubernetes,
you're
you're.
Definitely
gonna
gonna
face
challenges
all
right.
So
there's
things
like
you
have
to
learn
how
to
set
up
your
kubernetes
cluster
right.
So
it's
new
education
for
your
operations
and
devops
team
who
are
responsible
for
managing
these
clusters.
You
you
first
have
to
move
your
application
into
containers.
If
you
haven't
done
that,
that's
definitely
the
first
thing
you
should,
you
should
think
about.
You
have
to
learn
how
to
deploy
those
containers
into
kubernetes.
A
So
if
you
have
ci
cd
components
and
tools,
it
requires
probably
and
possibly
re-architecting
those
to
make
sure
that
you
can
deploy
efficiently
and
in
an
automated
approach.
Kubernetes
under
the
hood
uses
yaml
files
to
manage
really
the
specification
of
how
you
should
run
those
kubernetes
applications
a
lot
of
times.
A
Organizations
are
packaging
up
their
kubernetes
apps,
using
something
called
helm,
charts
think
of
helm,
charts
like
the
package
manager
for
for
kubernetes
applications.
If
you
will,
then
you
have
to
automate
all
of
this
stuff.
You
have
to
constantly
improve,
provide
feedback
and,
of
course,
all
while
delivering
business
value
to
to
your
customers
right
and,
of
course,
it
requires
a
new
approach
to
debugging
when
when,
when
things
can
go
wrong,
so
before
you
just
go
out
there
and
move
your
application
to
kubernetes,
you
really
need
to
ask
yourself
a
number
of
questions.
A
Right
is
kubernetes
actually
going
to
reduce
your
cost
right.
It
doesn't
necessarily
offer
that
immediately.
It
doesn't
necessarily
give
you
immediate
efficiency,
but
it
offers
you
new
levels
of
scalability
that
you
can
get
by
by
choosing
to
use
it
and
if
you're
not
as
we
talked
about,
if
you're
not
containerized,
that's
that's.
A
Definitely
the
first
approach
and
you're
not
really
going
to
gain
much
if
you're
not
first
containerizing
your
applications,
you
know
looking
at
breaking
down
your
monolith
simply
doing
a
simple
lift
and
shift
onto
a
different
platform
may
cause
you
more
headache
than
than
value.
So
you
need
to
spend
the
proper
time
re
re-architecting
your
application
and
and
will
allow
you
to
move
faster
right.
It
requires
new,
build
and
deploy
capabilities.
You
need
to
learn
and
understand
a
new
platform.
A
All
of
these
things
come
in
come
into
play,
and
is
it
better
than
what
you
currently
have
right?
So
are
you
gonna
see
immediate
performance
improvements,
or
will
that
cause
you
new
problems
that
you're
not
not
necessarily
aware
of
yet
so
all
in
all,
it's
not
a
magic
bullet.
A
That's
going
to
immediately
solve
all
your
problems,
but
it
can
absolutely
help
you
scale
and
provide
a
lot
of
value
if
you're
willing
to
put
in
the
work
so
looking
at
debugging
applications
that
are
running
in
in
kubernetes
the
developers
that
we
talk
to
still
tend
to
think
of
this
as
as
a
big
challenge.
So
it's
a
new
approach
that
developers
need
to
to
understand
and
learn,
simulating
the
exact
situations
or
conditions
that
allow
you
to
find
the
root
cause
of
a
problem
can
often
be
a
challenge.
A
So
the
traditional
approach
of
debugging
and
especially
debugging
locally,
can
be,
can
be
difficult
when
you,
when
you
think
of
how
you
traditionally
debug
a
lot
of
organizations,
go
and
look
at
application
logs
they're
used
to
going
into
a
virtual
machine
or
an
application
server.
Looking
at
logs
and
and
trying
to
figure
things
out
and
oftentimes,
even
debugging
remotely
can
can
be
a
challenge.
Applications
are
often
locked
down
in
clusters.
A
Developers
may
not
have
access
to
the
kubernetes
clusters,
there's
security
mechanisms
and
things
in
place
that
can
make
it
hard
for
developers
to
even
get
the
information
that
they
need
and
then
there's
there's
the
the
the
fact
that
you
have
to
learn
new
approaches
to
actually
get
that
information.
A
There's
new
tools
that
developers
need
to
become
familiar
with
cube,
control
or
cube
cuddle,
whichever
you
like
to
call
it,
has
it's
basically
a
command
line
tool
that
allows
you
to
interact
with
the
kubernetes
cluster,
get
information
from
your
your
kubernetes
pods
get
logging
information
back
and
a
lot
of
organizations
choose
to
lock
those
down
for
developers,
so
debugging
can
be
a
little
bit
slower
than
than
in
traditional
approaches,
and
when
we
look
at
some
of
the
limitations
of
debugging
locally,
this
is
where
there's
oftentimes
a
big
challenge.
A
A
lot
of
organizations
that
are
used
to
traditional
application
servers
developers
can
spin
up
those
application
servers
on
their
local
laptop
run,
the
application
and
debug
in
a
fairly
similar
environment
that
they
would
have
in
their
test
environments
or
or
even
in
their
production
in
environments
out
there
with
kubernetes
a
lot
of
the
times.
It's
it's
a
bit
different.
A
You
can't
oftentimes
run
a
kubernetes,
a
full-blown
kubernetes
cluster
on
your
local
laptop,
so
the
environments
that
are
running
out
there
in
your
cloud
are
often
using
higher
powered
servers
that
can
be
difficult
to
reproduce
and
there's
a
lot
of
different
options
for,
for
that,
there's
things
like
mini
cube,
which
allow
you
to
spin
up
kubernetes
clusters
and
a
number
of
different
others
on
your
local
laptop.
A
In
that
case,
developers
basically
control
the
configuration
versioning
branching
of
the
of
the
script,
which,
which
can
be
a
challenge
and
don't
give
you
the
exact
configuration
conditions
that
you
often
need
to
reproduce
issues,
but
it
can
oftentimes
be
a
good
start,
at
least
in
a
development
environment
and
there's
open
source
solutions
like
docker
compose
that
are
out
there
that
allow
developers
to
have
a
script
which
can
run
one
or
more
micro
services,
databases
all
all
at
the
same
time
and
allow
you
to
spin
it
up
from
the
command
line
with
a
single
command.
A
So
developers
can
run
a
single
command
spin
up
all
the
microservices
in
one
go
and
have
the
application
running
running
locally,
but
the
underlying
infrastructure-
that's
running
those
components,
is
completely
different
than
your
kubernetes
cluster
a
lot
of
times.
So
it
allows
you
to
find
some
issues,
but
not
not
always
all
of
the
issues
really.
Ultimately,
the
system
that
you
care
most
about
really
lives
in
your
in
your
production,
environment
there's
also
issues
with
debugging
remotely
right.
A
So
when
you
think
about
how
you
go
and
access
your
your
applications,
if
you
look
at
kubernetes,
it
is
accessing
a
kubernetes.
Pod
can
be
an
unstable
operation.
Kubernetes
behind
the
scenes
is
responsible
for
how
and
when
it
schedules
your
containers
to
run
you
may
ssh
into
a
running
kubernetes
pod
kubernetes
may
kill
it
before
you
have
the
chance
to
get
the
data,
so
you
need
to
have
the
proper
logging
and
and
infrastructure
in
place
to
make
sure
you
can
get
the
data
that
you
need.
A
Traditional
logging
and
and
log
files,
of
course
is,
is
an
approach.
Most
organizations
are
taking
today
to
save
information,
application,
specific
data
that
they
need
to
debug
things.
There's
other
approaches
like
taking
kubernetes
traffic
and
redirecting
that
to
a
local
debugger
that
might
be
running,
which
is
great
for
for
lower
level
development
or
lower
level
test
environments,
but
production
environments
that
are
locked
down.
That's
oftentimes
not
an
option,
because
that
would
be
a
major
security
vulnerability,
there's
also
other
solutions
and
things
that
can
make
it
easier
to
to
get
debugging
information.
A
Things
like
istio
or
linker
d,
which
are
service
meshes
that
are
oftentimes,
ideal
places
to
put
in
debugging
information,
or
you
know,
tracing
capabilities,
but
at
the
end
of
the
day
they
don't
always
give
you
the
ability
to
get
down
to
the
root
cause
of
an
issue
that
may
be
within
within
your
code.
They
can
give
you
insight
into
performance,
slowdowns
and
things
like
that,
but
not
always
code
level
code
level,
defects,
so
it
can.
A
It
can
highlight,
for
example,
this
specific
microservices
is,
is
running
slow,
but
maybe
not
exactly
why
that
may
still
require
a
developer
to
go
back
and
dive
into
the
code
to
find
the
root
cause
of
a
specific
issue
right
and
given
that
developers
spend
so
much
of
their
time
going
in
and
trying
to
fix
bad
code
or
you
know,
debug
applications
really
having
the
right
tools
to
to
optimize
that
time.
That
they're
spending
debugging
remotely
is
is
oftentimes
critical
right.
A
So
so
there's
there's
the
the
typical
things
like
configuration
drift
that
you
need
to
keep
keep
keep
in
mind.
You
need
to
be
able
to
simulate
the
right
data
conditions
within
your
application,
and
so
you
know
debugging
remotely
is
nice,
but
there's
oftentimes
a
lot
of
concerns
that
that
cause
slowdowns
or
don't
allow
you
to
get
all
of
the
information
that
you
need
in
order
to
debug
those
applications
effectively.
A
So
really
in
in
cases
like
this,
where
you're
looking
to
debug
remotely
there
are
more
modern
cutting
edge
debugging
tools
that,
in
a
lot
of
cases,
can
really
remove
the
need
for
development
teams
to
have
to
go
in
and
create
specialized
defect.
Reproduction
environments,
a
lot
of
organizations
are,
are
taking
their
production
environments
when
they
find
a
defect,
spinning
it
up
in
a
a
lower
test
environment,
trying
to
reproduce
the
issue
there
and
there's
a
lot
of
back
and
forth
and
time
that
can
be
wasted
when,
when
doing
those
things.
A
So
what
we'll?
What
we'll
look
at
next
is
a
little
bit
of
a
more
modern
approach
to
debugging
kubernetes
applications.
A
So
there
there
are
a
a
new
set
of
of
debugging
tools
that
are
out
there
called
remote
debugging
applications
that
allow
you
to
debug
applications
really
on
the
fly.
Without
having
to
make
changes
to
your
code
or
create
defect,
reproduction
environments,
they
allow
developers
to
go
in
and
immediately
get
the
data
that
they're
interested
in
really
really
on
demand.
A
So,
if
you
think
of
a
traditional
process,
debugging
logs
right,
most
organizations
and
most
developers
use
debugging
logs
as
the
primary
method
of
of
debugging
and
what?
What
happens
when
a
developer
wants
to
resolve
a
defect?
A
They'll,
go
in
they'll
they'll
find
the
logs
that
they're
interested
in
they'll
search
through
to
see
if
they
can
find
some
hints
or
some
clues
that
give
them
an
indication
of
what
the
problem
might
be
and
if
they
can't
find
the
information
that
they're
interested
in
what
they'll
have
to
do
is
they'll
have
to
go
back
to
the
code.
They'll
have
to
potentially
add
more
log
lines
to
the
code.
They'll
have
to
then
go
once
they've
added.
A
They'll
have
to
oftentimes
wait
for
the
next
deployment
window.
If
there's
shared
test
environments
once
it's
actually
pushed
into
their
their
test
environment
or
their
production,
environment,
they'll
then
have
to
wait
for
the
data
and
then
they'll
have
to
go
back
into
the
log
search
for
the
data
and
if
they
don't
find
the
data,
they
need
it's
kind
of
an
iterative
process
that
they
continue
on
in
terms
of
trying
to
trying
to
get
clues
into.
A
What's
what's
actually
going
wrong,
and
so
at
many
organizations
this
can
take
anywhere
from
from
hours
or
or
even
days
or
weeks,
depending
on
the
amount
of
regulation
or
lockdown
that
might
be
in
place.
So
it
definitely
brings
up
the
need
for
a
better
approach,
some
something
that
reduces
the
amount
of
context.
Switching
that
often
happens
the
the
amount
of
wasted
time
that
that
developers
have
something
that
they
can
use
to
actually
just
go
in
immediately,
while
the
application
is
running.
A
So
really
what
these
debugging
tools
and
these
these
remote
debuggers
that
we're
talking
about,
allow
you
to
do
is
really
quickly
and
instantly
collect
remote
data
on
demand
from
your
application,
and
so
that's
really
a
a
a
nice
segue
into
talking
about
these
remote
debugging
tools.
A
So
with
these
new
modern
distributed
applications
that
can
have
many
different
components,
running,
there's
a
lot
of
places
and
a
lot
of
areas
where,
where
things
can
go
wrong
and
it's
not
often
easy
to
find
the
source
of
those
problems
so
using
remote
debuggers
and
what
we're
looking
at
here
is
is
kind
of
a
simplified
view
of
of
the
kubernetes
architecture
right
and,
if
you're
not
familiar
with
the
kubernetes
architecture.
A
There's
a
lot
of
different
components
involved,
but
in
general,
there's
a
couple
key
things:
there's
a
command
line
tool
which
allow
you
to
interact
with
the
kubernetes
cluster,
an
api
server
that
allows
for
communication
back
and
forth.
There's
a
scheduler
which
handles
scheduling
your
kubernetes
containers
and
pods
and
with
on
different
nodes
within
your
kubernetes
cluster
and
there's
this
master
component.
That
manages
all
of
that.
A
What
what
they
allow
you
to
do
is
to
go
in
and
set
these
data
collection
points
within
your
running
applications
to
collect
snapshots
of
data
from
the
app,
and
that
consists
of
things
like
local
variable
data.
So
you
can
see
all
of
the
local
variables
just
like
you
would
in
a
local
debugger.
You
can
view
stack
traces,
profiling,
information,
tracing
information
and
that's
all
packaged
up
and
delivered
to
the
developer
on
demand
wherever
they
need
it
so
and,
and
these
things
often
run
across
the
the
entire
environment,
they
can
run
in
development
environments.
A
They
can
run
in
in
staging
or
test
environments
and
even
in
production
environments
for
these
production
grade
remote
debuggers.
So
it's
something
that
that
really
allow
developers
to
take
the
most
advantage
of
of
their
time,
make
your
customers
happier
and
and
reduce
the
overall
time
it
takes
to
identify
and
and
solve
some
of
these
defects.
A
So
there's
a
lot
of
different
options
out
there.
If
you're
not
using
a
remote
debugging
solution
today,
they
can
really
allow
you
to
have
a
overall,
better
approach
and
give
your
customers
a
little
bit
better
satisfaction
when
they're
using
your
your
application,
because
you're
solving
their
defects
really
on
demand
and
as
quickly
as
you
can.
A
So
that's
it
that's
what
I
wanted
to
to
talk
to
you
about
today.
If
you
have
any
questions
or
you'd
like
to
follow
on
and
get
get
any
more
information,
I'm
happy
to
chat
with
you
at
any
point
in
time
feel
free
to
send
me
an
email,
josh
rookout.com
with
any
questions
or
comments
and
I'd
love
to
talk
to
you
more
thanks
again
for
tuning
in
bye.