►
Description
Don’t miss out! Join us at our upcoming hybrid event: KubeCon + CloudNativeCon North America 2022 from October 24-28 in Detroit (and online!). 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.
Seeing is Believing: Debugging with Ephemeral Containers - Aaron Alpar, Kasten
Most Kuberrnetes developers are familiar with the painful process of debugging a pod within a cluster. Fortunately, a new, cutting-edge approach — ephemeral containers — simplifies debugging running pods and more! With ephemeral containers, you can dynamically deploy a container that shares pod resources. These containers use Linux namespaces to share network and process resources so debugging can occur using a container image of your choosing. During this talk, Aaron will cover the what, why and how of ephemeral containers, and the underlying mechanics that make ephemeral containers useful for debugging and testing.
A
Hello,
welcome,
hey.
My
name
is
linsa,
I'm
the
moderator
for
this
session.
I
work
for
a
small
company
solo
that
I
always
specialize
in
application
networking.
We
still
have
some
spaces
up
front
if
you're
brave
enough
to
walk
on
the
first
row.
Second
row,
so
please
welcome
aaron.
To
present
you
a
scene
is
believing
debugging
with
female
containers
all
right.
Thank
you.
B
B
B
So
today,
I'm
going
to
talk
about
ephemeral,
containers
so
and
what's
important
about
ephemeral
containers
is
that
the
they
are
more
than
just
containers
that
stick
around
for
just
a
little
while
they're
a
very
important
piece
to
kubernetes
architecture.
I'm
gonna
give
you
a
little
bit
of
that
and
hopefully
reasons
why,
as
well
as
a
lot
of
the
technical
background
that
makes
ephemeral
containers
work
and
hopefully
by
seeing
that
technical
background,
you'll
get
an
understanding
of
what
their
power
is
so
anyhow,
so
let
me
proceed.
B
This
is
gonna,
be
a
pretty
technical
presentation,
so
I
I
encourage
you
to
download
the
slides
that
are
up
on
sketch
for
this.
I
just
happened
to
update
them
about
a
half
an
hour
ago,
so,
if
you've
already
downloaded
them,
try
to
download
them
again.
The
content
remains
largely
the
same.
So
the
ordering
of
a
few
of
the
slides
and
I've
emphasized
some
details
in
the
new
ones.
So,
if
you're
following
along,
I
encourage
you,
definitely
encourage
you
to
download
the
slides.
I've
got
a
lot
of
console
type
text
in
here.
B
A
couple
of
slides
the
fonts
are
small,
so
I'm
hoping
that
folks
can
see
them
yet
another
reason
to
download
the
presentation.
Anyhow,
let
me
get
started
before
I
get
started
about
talking
about
ephemeral
containers,
I'd,
be
sure
to
talk
about
what
you,
what
you're
gonna
need
in
this
presentation.
This
presentation
is
a
is
both
me
presenting
and
talking
about
it
as
well
as
a
sort
of
self-driven
tutorial.
B
B
In
this
case,
I'm
using
kind
which
happens
to
be
what
kubernetes
uses
for
their
own
testing.
It's
fairly
feature
full
and
it
will
certainly
do
the
trick
for
our
presentation.
It
does
use
a
docker,
so
there's
implied
that
you'll
need
docker
installed
to
make
this
work.
I
think
that's
pretty
standard
at
this
point.
I'm
gonna
also
be
using
postgres.
B
B
Okay,
so
you're
gonna
see
a
bunch
of
slides
that
look
like
this
so
and
the
blue
there's
see
the
dollar
sign
there.
That
is
a
command
prompt.
That's
in
bold
right
next
to
it
blue
text.
That
is
something
you
can
copy
and
paste
into
a
shell,
and
you
should
get
output.
That
looks
a
little
bit
like
the
gray
text
that
follows
it
so
voila.
B
So
this
is
my
command
to
create
a
kind
cluster,
just
type
that
in
kind
create
cluster
it'll,
go
about
its
business
and
create
a
new
local
cluster.
For
you,
after
you've
got
a
new
local
cluster
installed.
You
can
install
help,
so
this
is
command
to
install
helm.
I
use
bitnami
repos
it's
in
there
create
a
namespace
for
it
and
then
use
helm3
to
install
that.
B
At
that
point,
you
should
kind
of
be
all
set.
You
got
kind
installed.
You've
got
postgres
installed.
You
might
want
to
check
your
versions
just
to
make
sure
that
you've
got
the
correct
stuff
installed.
I
am
running
with
bleeding
edge.
This
is
another
reason
to
use
kind
is
that
you
can
get
the
latest
latest
versions
of
kubernetes
as
as
well
as,
of
course,
kube
controls
be
compatible
with
that,
then
I
can
go
ahead.
B
B
This
means
that
if
you
install
kubernetes
123,
they
will
be
enabled
by
default,
so
you're
not
going
to
have
to
set
any
feature
gates
or
anything
like
that,
which
is
nice
all
of
the
platforms,
as
far
as
I
know,
have
a
123
on
their
edge
release.
So
if
you
want
to
get
if
you
want
to
play
around
with
ephemeral
containers
on
something
like
gke
or
what
have
you
either
it'll
just
be
installed
by
default
or
go
take
a
look
at
the
edge
releases
and
you
should
be
able
to
find
it
for
installation.
B
So,
with
all
this
ephemeral
containers
start
with
debugging.
These
are
the
cases
that
you'll
primarily
see
on
all
example,
sites
for
ephemeral
containers
and
a
vast
majority
of
literature.
That's
out
there
is
about
debugging
using
ephemeral
containers.
So
I'm
going
to
start
with
that.
I'm
going
to
talk
just
a
little
bit
about
debugging
in
general,
in
kubernetes,
very
high
level,
and
then
I'm
going
to
do
a
deep
dive
into
femoral
containers
and
not
so
much
the
process
of
actually
debugging.
B
B
Okay,
so
this
is
debugging
by
attaching
pro
hopefully
everybody's
familiar
with
this.
This
is
where
you
might
have
a
paw.
That's
having
problems
and
you're
you've
deployed
this
pod
with
like
a
debian
release,
or
maybe
even
a
red
hat
release,
and
you
just
shell
into
it
directly
and
you
run
commands
and
try
to
figure
out.
What's
going
on
here,
here's
an
example
of
doing
that:
coupe,
cuddle
exec
and
we
just
run
a
bench
bin
shell
or
what
have
you
in
the
pod?
B
So
we
can
go
ahead
and
log
in
and
to
bug
debug
into
it.
This
is
so
you
can
debug
by
attach,
or
you
can
debug
by
copy,
which
I'm
not
sure
everybody
really
knows
about,
but
this
is
using
the
actual
debug
command.
It
allows
you
to
take
a
cop,
create
a
copy
of
your
pod.
So
pods
are
the
smallest
unit
of
scheduling
right
so
with
the
current
infrastructure.
B
What
you
have
to
do,
if
you
want
to
run
a
new
process
in
a
pod
other
than
executing
into
it,
is
that
you're
going
to
have
to
create
a
copy
of
it
with
a
new
container
or
with
whatever
debugging
tools,
a
new
image
or
whatever
debugging
tools
that
you
want.
So
this
is
debugging
by
copy,
and
what
this
does
is.
It
creates
a
copy
of
the
container
and
it
runs
that
it's
a
little
awkward,
but
it
works.
B
B
If
you
want
to
change
that
container,
to
include
additional
tools,
you're
going
to
have
to
copy
it-
and
this
requires
doing
some
foo
magic
on
your
workloads
to
make
that
work
so
like
if
you're
working
with
a
deployment
or
you're
working
with
a
stateful
set,
it's
you're
gonna
make
a
copy
of
the
pod,
and
then
the
stateful
sets
gonna,
look
at
it
and
see
that
it's
replicas
of
change
and
then
it's
gonna
start
up.
Another
pod
and
you're
gonna
have
to
set
your
services
to
point
at
the
right
pod.
B
Anyhow,
it's
a
little
bit
of
a
mess,
but
you
can
once
you
get
the
hang
of
it.
It
works
ephemeral.
Containers
get
around
this
and
I'll
talk
a
little
bit
about
this.
This
is
how
you
debug
by
ephemeral
containers,
so
you've
got
kubernetes
one
two
three
installed
cut
by
kind:
you've
got
postgres
in
there,
as
my
previous
example
copy
and
paste
that
command
in
there
and
what
you
get
is
an
ephemeral
container
busybox
standard
set.
So
this
this
is
a
it
actually
runs.
A
new
container.
The
pod
stays
the
same.
B
A
new
container
is
added
to
it,
which
is
really
handy.
This
is
a
little
bit
of
a
little
bit
of
a
special
container.
It's
probably
not
going
to
be
obvious
immediately
because
all
containers
within
a
pod
get
to
share
the
same
network
resources.
So
so,
anyhow
by
default
you'll
see
network
resources
shared.
That's
that's
really
nice,
and
this
is
this
ideal
case
for
doing
more
complicated,
debugging
and,
as
we'll
see,
we
can
get
really.
We
can
get
really
complex.
B
B
So
this
is
the
ephemeral
container
spec,
so
I've
run
the
previous
command
boom
and
what
I
get
is
a
new
ephemeral
container
that'll
be
evident
in
the
pi
in
the
pod
spec.
Here's
the
ephemeral
container
spec.
So
I'm
going
to
go
ahead,
get
the
pot
as
yaml
and
down
here
I
know
the
font
is
small
I'll
blow
it
up
in
a
second,
we
have
a
spec.
We
have
our
containers
there
and
we
have
a
new.
We
have
a
new
property
ephemeral
containers.
B
This
is
a
zoom
in
group
to
that
and
again
here
we
see
it.
So
this
lists
all
my
ephemeral
containers,
for
which
I
have
one
now.
So
that's
executing
there's
another
important
part
of
this,
and
if
I
get
it
again
and
I
look
through
it
and
again
I
blow
it
up-
we
also
on
the
status
property,
the
spec.
I
also
get
a
ephemeral
container
entry,
so
we
got
two
new
entries
in
the
resource.
The
ammo
for
the
resource.
B
B
So
I
I'm
I'm
set,
I
can
debug
with
ephemeral
containers.
I
know
what
the
I
know
what
to
look
for
on
the
specs,
so
I
can
see
what
the
status
is
of
ephemeral
containers
see,
which
ephemeral
containers
are
running
and
again
this
the
spec
is
changed
on
the
pod
as
it's
running,
which
is
unique.
That's
one
of
the
things.
That's
really
nice
about
ephemeral
containers,
but
what
is
a
femoral
container,
so
this
is
actually
going
to
be
a
majority
of
the
presentation
and
I'm
going
to
try
to
spend
some
time
on
this.
B
A
container
can
be
thought
of
as
sandbox
right
so
you're
in
the
sandbox
you're
executing
commands,
and
what
you
can
see
is
limited.
You
can't
see
the
entire
system.
You
can't
see
into
other
pods
right.
You
can't
really
see
into
other
containers.
Actually
you're
you're
in
a
you're,
basically
you're
in
a
container,
can
be
seen
as
a
sandbox.
B
B
So
I'm
going
to
talk
about
linux
namespaces
in
this,
so
linux,
namespaces,
control,
container
isolation,
linux
namespaces
are
the
things
that
don't
allow
you
to
see
outside
the
container
into
the
rest
of
the
system.
So
you
can
play
with
these
name
spaces,
so
you
can
see
various
parts
of
other
containers.
B
So
it's
really
nice
and
this
this
is
really
what
ephemeral
containers
are
about.
Is
controlling
linux.
Namespaces
I'll
talk
a
little
bit
about
this.
There
are
many.
There
are
many
namespaces,
here's
just
a
few
mount
pid.
These
are.
These
are
roughly
listed
in
the
order
of
importance.
Mount
pid
net
ipc,
there's
a
bunch
of
them
there's
some
resources
at
the
end,
I'm
going
to
talk
about
these
and
there's
some
resources
at
the
end
and
I'll
talk
about
those
two,
each
each
name
space
is
identified
by
an
inode.
B
B
B
So,
as
I
said
before,
you're
going
to
need
to
you're
going
to
need
privileged
access
to
the
note
to
make
this
work
and
here's
an
example
of
this.
So
what
I'm
doing
here
is
is
one
of
my
first
examples
of
linux.
Namespaces
is
that
I'm
gonna
log
in
to
the
control
plane
node?
This
is
the
basically
the
only
when
you
use
kind.
It
is
the
only
node
you
got
by
default
and
I'm
going
to
take
a
look
at
the
namespaces
for
pid1.
B
Pid1,
of
course,
is
the
init,
and
I
can
see
those
by
ls-l
slash,
proc.
Everybody
should
know
what
slash
proc
is
one
which
is
pid
one
and
then
for
each
process
in
in
proc,
there's
an
ns
and
under
the
ns
directory
you'll,
see
all
the
namespaces
listed
out
over
here
on
the
left.
We've
got
or
the
right.
B
B
So
now,
if
I,
if
I
that's
from
the
node
perspective,
what
I
can
do
is
I
can
go
in
and
do
the
same
thing
and
take
a
look
at
my
postgres
processes
that
are
running
on
the
node.
So
that's
sorry,
the
previous
slide
was
from
the
inet
perspective.
This
is
taking
a
look
at
postgres,
which
is
running
in
a
running
in
a
container
within
the
kubernetes
cluster.
So
here
I
get
my
pid
for
postgres
ips.
B
It
is
an
example,
and
then
here
what
I
do
is
I
get
all
the
name
spaces
for
the
progress
and
I
can
list
all
of
those
out
now.
These
are
the
name
spaces
that
the
containers
actually
going
to
use
to
run
postgres
in
and
here's
a
zoom
in
of
that
as
well.
The
identifiers
for
this
aren't
so
important
and
I'll
we'll
see
more
of
this
in
just
a
second.
B
So
those
are
how
you
see
namespaces
you
can
you
can
look
in
proc
you
can
see
which
namespaces
are
identified
with
which
process
in
the
example
that
I
had
before
we
looked
at
pid
one,
and
then
we
looked
at
our
postgres
namespaces
for
our
postgres
process.
Those
will
come
up
in
just
a
second
looking
at
them.
Doesn't
do
you
much
good?
B
What
you
really
want
to
be
able
to
do
is
execute
something
with
a
certain
set
of
namespaces
set.
This
is
what
a
command
called
ns
enter.
Does
it
allows
you
to
enter
a
set
of
namespaces
and
execute
commands
as
though
you
were
in
that
namespace,
so
when
you're
in
a
container,
this
is
really
what
you're
doing
is
running
a
shell
with
nsenter.
B
This
is
an
example
of
running
ns
enter.
I'm
here,
I'm
gonna
run
ns
enter
in
the
postgres
namespace,
specifically
for
network,
so
ns
enter
dash
dash
network,
and
then
I
give
it
a
namespace
file
in
proc
that
says
start
up
a
command
using
whatever
namespace
then
using
the
network
namespace
for
whatever
postgres
is
using,
and
here
I
just
run
sstcp.l
just
to
see.
What's
listening,
and
here
we
go.
B
If
I
want
it's,
it's
a
little
tedious
to
list
out
all
of
the
namespaces
that
you
you
want
to
use
so
there's
a
shorthand.
It's
called
target
target
basically
allows
you
to
give
it
a
pid
and
it
will
enter
the
namespace
of
that
process.
It's
really
handy!
So
if
you
have
a
shell
somewhere
or
you
have
some
sort
of
command
and
you
want
to
see
the
universe
from
the
viewpoint
of
that
process,
this
is
how
you
do
it.
B
So
I'm
going
to
show
you
what
what
things?
What
doing
this
looks
like
from
the
node
executing
being
in
a
namespace
versus
what
it
looks
like
from
the
container.
So
here's
a
coupe
cuddle
exec
here,
I'm
I'm
exacting
a
command
in
the
in
the
default
container
in
my
pot
right
so
ps
ejf.
I
just
want
to
see
what
the
processes
are.
So
here
I
go.
Ps-E-F
excuse
me,
those
are
the
processes.
B
This
should
look
familiar,
and
this
is
the
view
that
we
get
if
I
exec
directly
into
the
node
and
then
I
do
an
ms
enter
given
a
target
of
my
postgres
process
and
I
do
a
ps
ef,
basically,
the
same
thing:
you'll
notice,
if
I
switch
between
these
two
slides,
the
output
is
basically
exactly
the
same.
So
this
the
ns
enter
command.
Basically,
is
the
same,
as
I
said
before
is
the
same
thing
as
running
within
a
a
container
in
a
pod.
B
B
Okay,
so
that's
sort
of
the
background
I'll
get
into
some
more
details
and
again
a
little
bit
like
that
blue,
the
blue
text.
I
was
telling
you
about
and
entering
in
that
I'm
going
to
use
this
comparison
technique
of
moving
between
slides
in
a
few
cases
to
show
you
what
what
what
the
what
changes
when
you
do
certain
commands
so
ephemeral
containers
when
you
start
in
ephemeral,
containers
network
namespace
is
shared
by
default,
really
handy,
there's
a
bunch
of
other
namespaces
that
are
also
shared.
This
is
certainly
the
most
important.
B
I
think
you
can
share
other
namespaces,
so
you
can
kind
of
tweak
things
and
change
your
perspective
from
the
from
the
container.
So
here's
a
namespace
when
debugged
by
attaching
so
this
I'm
going
to
go
directly
into
the
postgres
node
and
I'm
going
to
go,
go
ahead
and
do
an
ls-l
self
ns.
So
a
self,
if
you
haven't
heard
of
that
is
just
whatever
the
current
process
is
so
I'm
in
a
container
I'm
just
doing
a
ps.
B
Now,
I'm
doing
this
next
command
is
a
coupe
cuddle
debug.
So
this
is
a
con.
This
is
a
femoral
container,
debug
right
again
into
postgres,
so
before
this
is
like
exacting
into
the
container
and
running
a
command.
This
is
starting
a
femoral
debug
container
against
the
same
pot
and
against
the
same
container.
So
so
here
I
go
ahead
and
start
it
a
femoral
container
with
an
image
of
busy
box.
This
will
start
a
this
will
start
a
new
container
there.
B
B
B
When
I
look
at
my
mount
points
or
when
I
look
at
my
file
systems,
I'm
going
to
see
my
own
files
c
groups
has
to
do
with
permissions.
I'll
talk
about
a
little
bit
in
a
minute,
but,
as
you
can
see
my
net
between
the
two
yellow
things
right
there,
my
net
namespace
remains
the
same.
So
when
I
do
like
an
ss
or
an
ifconfig,
or
something
like
that,
I'm
going
to
see
the
same
network
resources
as
the
rest
of
the
pod
would
normally
see.
B
B
The
default
container
is,
I
can
set
up
a
specific
target
container,
so
here
we're
doing
a
cube,
cuddle,
debug
and
I'm
specifying
a
target
target
postgres.
That
is
basically
the
same
format
that
you
used
in
nsender
right
dash
target
and
he
gave
it
a
process,
that's
kind
of
what
we're
doing
here
so
notice
here
that
fewer
of
my
namespaces
have
changed.
So
this
means
I'm
sharing
more
with
the
original
pod
and,
what's
most
important,
is
now
you're.
Sharing
the
pid
name
space
with
the
pod.
B
B
So
let
me
talk
a
little
bit
about
ephemeral,
ephemeral
containers
and
how
to
get
access
to
more
so
we
you
may
want
to
get
access.
For
example,
the
file
system
mounts
and
a
few
other
things
and
I'll
talk
about
that.
So
ephemeral
containers
are
a
sub-resource
technically
they're.
Basically,
a
new
resource
off
of
pods.
It
is
a
is
now
a
sub
resource.
B
I
talked
about
this
before
every
time
you
run
an
ephemeral
container,
it
shows
up
in
the
ephemeral
container
process
property
and
the
the
statuses,
the
dynamic
statuses
exit
codes
and
so
on
and
so
forth,
for
those
containers
is
listed,
femoral
container
status,
oh
yes,
unique
names
must
be
used.
I'll
talk
about
that,
a
little
bit
more
in
just
a
second
here's,
a
handy
command
for
listing
out
ephemeral
containers.
B
As
I
said
before,
not
all
properties
are
available
from
coop
cuddle.
You
can
run
cue
couple
exec
to
start
up
ephemeral
containers,
but
there
are
some
name
spaces
that
you
don't
have
access
to
from
the
command
line.
There's
there's
mounts
and
mounts.
Excuse
me
mounts
pids
and
something
else
not
coming
to
mind
regardless
we'll
see
that
in
a
second,
oh,
yes,
you
cannot
remove
or
change
ephemeral
containers
or
ephemeral,
container
statuses.
B
So
you'll
see
this
once
you
try
to
access
the
sub-resource
directly,
you
can
add
ephemeral
containers.
You
cannot
remove
ephemeral
containers
now.
Remember
that
every
time
you
start
in
a
femoral
container,
it's
added
to
the
ephemeral
containers
in
the
pod
and
the
femoral
container
statuses.
This
means,
as
you
start,
ephemeral
containers.
B
B
So
this
is
an
example
of
a
custom
api
call
to
create
an
ephemeral
container.
In
my
case,
I
do
not
have
access
to
volume
mounts
using
the
regular
cube,
cuddle
debug
command
line,
so
this
is
an
example
of
how
you
do
that
one.
Since
it's
a
container,
you
have
access
to
all
of
the
volumes
in
the
pod.
So
what
I
can
do
here
is
do
a
custom.
B
So
you
have
to
be
choosy
about
which
file
systems
you
mount
and
that's
why
you
can't
just
go
ahead
and
share
them
out
main
namespace,
and
if
you
like,
I
encourage
you
to
play
around
with
it,
because
you'll
get
some
interesting
results,
but
regardless
you'll
have
to
pick
and
choose
your
amounts.
This
is
one
way
to
do
it.
B
This
is
an
example
of
the
once
again
the
comparison
of
the
between
the
the
the
mount.
The
excuse
me,
the
ephemeral
container.
I
just
started
with
a
new
mount
notice.
We
get
a
new
mount
namespace,
so
it's
basically
the
same
as
I
had
before
when
I
started
a
femoral
container
by
default,
but
I
created
a
brand
new
name
space,
so
I
can
mount
my
volume
out.
That's
in
the
pod,
so
that's
useful.
B
B
B
You
can
start
it
up
as
a
just
a
regular
container,
but
it's
utility
is
very
limited
as
that,
once
you
start
using
it
as
a
femoral
container
that
it's
its
utility
really
becomes
evident.
So
it's
a
system
level
diagnostic
container.
It
contains
tools
like
s,
trace,
l,
trace,
tcp
dump.
What
have
you
it's
very
nice,
so
this
is
an
example
of
starting
up
a
container
using
net
shoot
as
a
privilege
container.
So
I'm
skipping
a
few
steps
here,
but
that's
okay!
B
B
Here,
I'm
going
to
run
that
chute
and
then,
when
I
do
that,
I
can
do
all
sorts
of
interesting
things
on
my
target
container
that
you'd
never
be
able
to
do
in
a
regular
container.
In
this
case,
I
can
run
s
trace,
for
instance,
so
I
can
look
at.
I
can
look
at
system
calls
that
are
executing.
I
can
look
at
all
the
network
resources
if
you've
got
the
mount
set
up.
You
can
take
a
look
at
the
data.
B
B
Excuse
me:
here's
my
classic
coupe
cuddle
exec,
so
this
is
from
slide
40..
This
is
when
I
logged
in
originally
to
the
pod
to
just
see
all
the
to
see
all
the
see
all
the
name
spaces
as
if
you
just
exact
into
it.
This
is
the
one
using
my
privilege
container,
debug
container
two
there.
You
see
those
two,
those
two
new
name
spaces.
B
B
So
that's
so
with
all
of
that,
given
that
you
can
get
complete
access
to
your
pods
through
ephemeral
containers
to
the
point
of
having
access
to
basically
privileged
privileged
access,
I
encourage
you
to
look
into
c
groups.
This
allows
us
to
talk
about
district
lists,
so
distroless
is
when
you
deploy
containers
that
only
contain
the
application
that
you're
going
to
want
to
run.
They
don't
contain
any
of
the
utilities.
B
So,
with
ephemeral
containers,
you
can
start
to
start
containers
beside
your
application
containers
with
commands
like
ls
and
ps,
and
what
have
you
and
given
that
you
can
have
up
to
you
know
this
sort
of
privileged
access
to
the
pod.
You
can
then
run
those
commands
against
the
containers,
just
as
if
you
were
in
the
container
itself,
so
this
loosens
the
requirement
that
you
have
all
the
tools
required
to
debug
or
even
really
use
your
containers
and
spec
files
within
the
within
the
containers
themselves.
B
B
So
that
is
basically
it
here's
a
list
of
resources.
I
I
encourage
you
to
take
a
look
at
these
guys,
they're
they're,
fairly
valuable
and
they're,
pretty
comprehensive
in
terms
of
c
groups,
which
is
the
next
important
topic
which
I
didn't
have
time
to
cover,
as
well
as
what
makes
containers
work
and
some
of
the
intentions
behind
ephemeral
containers
beyond
simply
debugging,
so
I'll
open
it
up
for
questions.
I
think
I've
got
just
a
few
more
minutes.
B
A
B
It
it
remains
as
an
entry
in
the
pod,
it
goes
away.
You
get
an
exit
code
and
this
once
so.
The
question
is
what
happens
to
an
ephemeral
container
once
it's
done.
If
you
exit
an
ephemeral
container,
the
entry
remains
listed
in
the
pod,
nothing
you
can
do
about
that.
You
will
see
an
exit
status
within
the
ephemeral
container
statuses.
That
says,
you
know.
Was
it
whether
exited
with
a
code
of
one
or
zero?
B
You
can
get
some
log
information
from
it,
which
is
handy
if
you
opened
a
terminal
to
that
ephemeral
container.
If
you
attempt
to
attach
to
it
using
cube,
cuddle
attach
you'll
actually
get
the
last
screen.
You
saw
so
that
it's
kind
of
a
double-edged
sword.
It
allows
you
to
see
any
errors,
last
errors
that
were
output,
but
at
the
same
time,
if
somebody
has
access
to
coop
cattle
attached,
they
could
see
some
sensitive
information
that
might
be
listed
there.
Thank.