►
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
Tutorial: A Day in the Life of a Cloud Native Developer - Randy Abernethy, RX-M, LLC
In this 90 minute, hands on tutorial, attendees will get a chance to work with a comprehensive set of modern cloud native tools from the CNCF software stack. The tutorial will take users on an end to end journey through some of the most important tools and processes involved in constructing, packaging, deploying and managing a working microservices application. Each lab step will introduce a new CNCF project and demonstrate how that project adds value in a cloud native tool chain. Participants will leave with an overarching understanding of the benefits associated with a fully cloud native developer experience. Projects used in this practical field trip include: Kubernetes, Prometheus, Envoy, Fluentd, gRPC, Containerd, Helm, Harbor and Telepresence. Attendees will need a laptop and an ssh client to complete the hands on labs.
https://sched.co/MPh0
A
All
right:
well,
why
don't
we
go
ahead
and
start
up
good
afternoon
and
welcome
everybody,
my
name's
Randy
Abernathy-
and
this
is
a
day
in
the
life
of
a
cloud
native
developer
and
we
got
a
crazy
amount
of
stuff
to
go
through
in
this
short
90
minutes.
So
I'm
gonna
get
right
to
it.
We
originally
a
dark
tent.
We
were
kind
of
a
cloud
native,
consulting
and
training
shop
and
we
we've
been
in
the
CNC
F
since
they
they
began
and
we
had
this
idea.
A
You
know
hey,
let's
do
like
a
you
know,
kind
of
a
talk
on
all
the
projects,
that'd
be
kind
of
cool
and
then
it
just
it's
gotten
less
cool
over
time.
Right
because
there's,
like
you
know
so
many
projects
we've
had
to
start
picking,
and
so
this
may
be
the
the
the
the
biggest
one
that
we've
done,
but
we
still
feel
like
it's
got
some
value,
so
9
CN
CF
projects
in
90
minutes
right,
that's
a
lot!
A
So
you
get
the
idea,
there's
going
to
be
like
10
minutes
per
project,
if
you're
expecting
a
marianas
tent
trench,
deep
dive
on
any
of
this
stuff.
You
are
in
the
wrong
place
right,
you're
gonna
be
swimming
in
the
first
4
feet
of
the
ocean
around
the
equator.
Twice,
that's
what
we're
gonna
do
we're
gonna!
Look
at
a
lot
of
these
projects.
Get
a
really
you
know
kind
of
hands-on.
You
know
a
real
idea
of
what
they
are
and
how
they
work.
You're,
gonna
install
them
from
scratch.
A
A
If
you
would
like,
but
I
would
recommend
against
it
for
two
reasons:
number
one:
you
could
mess
up
your
laptop
we're
gonna,
install
a
lot
of
stuff
and
you
know
hack
a
lot
of
things
together
because
we're
all
about
speed
in
this
session,
not
prettiness
necessarily-
and
so
we've
got
a
machine
for
everybody
to
use
these
VMs.
If
you
don't
already
have
a
sheet,
you
can
grab
one
from
one
of
the
guys
back
here.
My
good
friends
from
giants
worm
helping
us
out.
A
Thank
you
thank
you,
and
so
this
is
basically
an
IP
and
a
link
to
a
key,
and
so
that's
your
your
access,
just
SSH
into
this
box.
Do
everything
in
there.
The
other
thing
that
we
prefer
you
to
use
the
VMS
for
is
that
it's
just
going
to
work
right
for
that
virtual
machine
is
a
known
quantity.
It's
starting
from
a
place
that
we
understand
and
that
all
the
steps
operate.
You've
got
something
installed
on
your
laptop
that
we
can't
know
about.
There's
no
way.
We
can
make
sure
that
it.
A
You
have
a
good
experience,
so
so,
at
the
end
of
the
day
you
know,
we've
got
these
nine
projects,
I'm
going
to
kind
of
introduce
each
one
of
them,
I'm
going
to
give
you
an
overview
of
the
lab,
tutorials
stuff
and
then
I'm
going
to
shoot
the
gun,
and
you
guys
have
about
eight
minutes.
Ish
to
you,
know,
work
through
the
lab
stuff
tinker
around
play
and
ask
questions.
This
is
not
a
presentation,
so
you
cannot
interrupt
me.
You
can
ask
questions
at
any
point
in
time.
A
Obviously
is
a
lot
of
people,
so
we
have
to,
you,
know,
have
a
little
bit
of
decorum,
but
I
will
absolutely
you
know,
take
sidebars
and
answer
questions
and
I
prefer
to
do
it
on
the
mic.
So
everybody
else
hears,
because
some
of
the
best
content
comes
from
interactions
where
people
have
really
good
ideas
and
good
questions
about
things.
I
don't
have
all
the
answers
right.
A
These
are
nine
projects,
there's
a
lot
going
on
here,
but
I've
played
with
a
lot
of
them
and
some
of
them
fairly
heavily,
so
we'll
we'll
definitely
have
some
fun
discussing,
and
the
last
thing,
then,
is
we'll
look
back
and
review
real
quickly.
What
that
step
did
now?
If
you
get
behind
in
general,
you
can
pretty
much
just
skip
any
of
the
steps
right.
There's
nine
steps,
one
for
each
of
the
projects,
so
you
can
skip
one
of
them
and
jump
right
into
the
next
one
without
too
much
trouble
for
the
most
part.
A
If
there
is
any
problems,
though,
while
you're
you're
moving
through
the
labs,
one
of
the
things
that
you'll
see
here
is
a
link.
Maybe,
on
the
next
page,
we've
got
a
zoom
chat
up
my
firm's
based
in
Miami
and
San
Francisco,
so
some
hearty
folk
from
the
west
coast
and
I
see
a
bunch
of
you
guys
in
here
too,
so
a
good
good
job
getting
here
at
5:00
in
the
morning.
Those
people
are
online
and
they
can
answer
questions.
A
So
if
you
get
stuck
on
something,
you
know
that
that
might
be
a
good
way
to
go.
I'm
gonna
run
around
and
answer
questions
as
best
I
can
as
well.
All
the
code
is
in
this
URL.
It's
pretty
easy
to
remember
it's
github
calm
and
then
it's
the
org
is
rx
dash
M
and
then
it's
koukin
EU,
20
19,
so
the
instructions
in
the
in
that
repo
are
gonna.
A
You
know
give
you
everything
you
need
to
know
from
here
on
out,
so
you
really
won't
need
anything
else
for
me
once
you've
got
that
link
in
this
sheet
of
paper.
So
that's
the
link
again
in
a
little
bit
louder,
form
and
at
the
bottom
for
people
who
don't
like
typing
I'll,
leave
that
up
for
just
a
second
and
then
we'll
we'll
move
on
some
other
things
about
the
the
environment.
A
The
the
pace
I
will
like
kind
of
give
more
time
for
certain
labs
than
others,
because
I
think
some
of
them
are
covered
a
little
bit
more
deeply
or
maybe
just
take
a
little
more
time
to
get
through.
So
it
won't
be
exactly
ten
minutes
per
module,
but
it'll
be
pretty
pretty
close,
all
right,
so
I'm
gonna
move
on.
If
you
need
help
with
any
of
this
stuff,
just
let
one
of
the
guys
or
myself
know
and
we'll
we'll
get
you
the
links
you
need.
This
is
the
the
chat
and
I'll
just
read
it
out.
A
So
it's
zoomed
us
/j,
slash,
seven,
five,
eight
one,
one:
nine!
Four!
Six:
six
again:
that's
HTTP
colon
whack,
whack,
zoom,
dot,
US,
/,
j,
/,
seven,
five,
eight
one,
one,
nine,
four,
six,
six!
Sorry!
It's
not
easier
to
remember,
but
if
you
need
that
again
also
I'll
pop
that
out,
we
didn't
print
that
on
these
sheets.
Unfortunately,
because
it
just
kind
of
popped
up
at
the
last
minute,
we
had
to
increase
our
plan
and
they
changed
the
link
on
us,
oh
and
then
one
last
thing:
shoutout
to
Amazon.
A
All
of
these
boxes
are
being
provided
by
Amazon.
So
thank
you,
Amazon
and
in
the
kubernetes
side
of
things,
we're
going
to
be
using
eks.
So
we've
got
an
e
KS
cluster
back
there
running
some
30
40
nodes
that
you
guys
will
be
deploying
to
and
playing
around
with
as
well.
So
the
lab
box.
This
guy
is
your
box
to
work
on
and
to
do
whatever
you
want
with
and
then
we'll
be.
You
know
interacting
with
the
e
KS
cluster
on
the
back
end.
So
what
are
we
going
to
build?
A
Obviously
we
got
90
minutes
and
we
have
all
these
projects.
We're
focused
on
the
project's
not
on
building
some
sophisticated
piece
of
software.
We're
gonna
build
a
simple
microservice
using
G
RPC,
that's
one
of
our
projects
and
then
we're
gonna
build
a
simple
client.
We're
gonna
use
go
just
because
for
the
heck
of
it
right
any
go
programmers
here:
okay,
alright,
there's
like
four,
so
you
guys
are
in
trouble
because
everybody
just
saw
you
raise
your
hands
alright,
so
so
we're
gonna,
keep
it
simple
and
we're
gonna
go
fast.
A
You
know
simple
client
that
we'll
use
for
testing
all
this
stuff
and
then
a
service
that
we
can
deploy,
and
you
know,
experiment
within
all
these
projects.
So
let's
go
ahead
and
start
G.
Rpc
g
RP
c
stands
for
g
RPC
remote
procedure.
Call
it's
the
famous
recursive
backronym
duck
when
you
don't
want
to
admit
what
your
first
letter
stands
for.
G
RPC
is
a
really
awesome
piece
of
technology
because
it
allows
you
to
build
interfaces
that
are
very
fast
and
efficient,
and
it
also
is
very
structured.
A
I
worked
at
a
trading
shop
for
a
while,
and
we
built
a
pretty
big
trading
system.
It
wasn't
huge,
but
did
it
at
about
a
billion
us
a
day
and
we
needed
it
to
work
right
and
we
used
IDL,
and
it
was
this
sort
of
magical
thing.
I
didn't
really
like
the
IDL
language
we
use,
but
I
loved
what
it
did
to
the
teams
and
the
way
they
were
organized
and
when
I
hear
people
talk
about
G,
RPC,
I,
hear
them
say
those
same
things:
they're
like
wow.
A
G
RPC
is
the
language
of
communications
for
the
performance,
parts
of
kubernetes
and
docker
to
container
D
another
one
of
the
projects.
We're
going
to
talk
about
so
in
the
cloud
native
computing
foundation.
Ecosystem
G
are
pcs,
pretty
darn
important.
It's
a
fundamental
piece
of
kit
that
people
use
to
build
things
so
not
bad
to
understand
understanding
the
concept
of
protocol
buffer
is
a
way
that
you
describe
things
that
can
be
serialized
and
the
concept
of
G
RPC,
which
is
the
thing
that
creates
the
RPC
wrapper
on
those
C.
A
Realizations
also
gives
us
this
this
polyglot
friendliness,
so
we
can
communicate
between
many
different
languages,
which
is
really
important
in
a
micro
service
world.
You
can
mandate
that
everything
is
going
to
happen
in
at
your
shop
right
up
until
you
buy
a
c-sharp
only
company
right,
and
then
you
have
to
figure
out
how
to
put
things
together.
So
there's
there's
a
lot
of
value
in
G
RPC.
It's
also
operating
over
HTTP.
If
you've
seen
any
video
talks
and
we're
gonna
do
a
little
is
do
here
as
well.
A
You
know
that
there's
just
all
these
rich
features
you
get
from
systems
and
software
that
know,
or
that
have
HTTP
traffic
and
one
of
the
magic
things
about
HTTP
and
why
you
still
even
in
a
world
where
a
lot
of
people
are
using
G
RPC,
are
gonna,
have
REST
API
s
on
the
out
side
of
things.
Is
that
it's
easy
to
adopt
its
tool
lists,
and
it
also
has
this
lovely
thing
where
there's
a
separation
of
information
and
metadata
from
the
core
application.
A
A
I'll
pop
up
a
couple
of
things
on
the
screen
in
just
a
second
to
help
you
get
started,
but
that'll
be
our
first
step
and
that
that
little
service
that
you
create
we're
gonna,
then
package
it
into
a
container
we're
gonna,
deploy
it
on
kubernetes
we're
going
to
Pat.
You
know
we're
going
to
take
all
of
the
kit
and
wire
it
up
into
a
helm,
chart
we're
gonna,
use
telepresence
and
see
how
we
could
debug
it.
You
know
we're
gonna,
just
keep
exploring
this
whole
field
of
CN
CF
projects.
A
So
in
this
step
we're
gonna
try
to
understand.
You
know
how
the
RPC
system
works
right.
Some
of
you
and
I
know
are
gonna.
You
know,
I'll
be
really
like.
Have
some
of
these
projects
cold
and
it's
gonna
be
a
little
boring,
but
for
others-
maybe
it's
your
first
time
so
we're
gonna
create
an
interface
definition
in
IDL.
We're
gonna,
build
the
micro
service
and
go
so
maybe
get
a
little
exposure
to
go.
A
If
you
haven't
seen
that
before
and
then
the
JavaScript
client,
what
we've
done
for
this
session,
because
it's
so
short,
is
we've
actually
simplified
some
things
and
taken
some
stuff
out
so
that
we
could,
because
we
had
people,
we
timed
people
and
still
pretty
tight,
so
we're
gonna
drop
the
JavaScript
we're
just
gonna
dude
go
so
we
don't
have
to
install
another
language
and
mess
with
a
bunch
of
extra
stuff.
So
just
go
alright,
so
the
lab
doc
and
completing
step
one
is
the
next
chore.
A
So
you
know
generally
what
you
do
is
you
know
fire
up
some?
Let
me
get
my
screen
shared
here,
real
quick
generally.
What
you
do
is
is
fire
up.
You
know
some
some
ssh
client
drop
to
the
command
line.
You
know
whatever
I
use
MOBA
axe
firm
on
Windows.
It's
pretty
awesome
if
you
haven't
tried
it
and
then
once
you're
there.
If
you
go
to
the
repo
alright
that
we
pointed
you
at
and
when
you
pull
that
up
real
quick.
A
So
the
readme
that
you'll
see
staring
you
in
the
face
right.
There
is
going
to
tell
you,
hey
SSH,
into
your
box,
clone
this
repo
right,
this
very
repo
and
get
started,
and
so
each
of
the
sub
directories
here
step
one
step
two
step:
three
is
a
new
project,
so
a
new
project
that
we'll
explore,
and
so
at
the
end
of
this
first
readme
it's
got
a
little
markdown
link.
A
These
are
all
just
marked
down,
so
you
can
download
them
and
you
know
copy
and
paste
from
them
in
Adam
or
whatever
it
is
you
like
sublime
or
something,
and
so
you
just
jump
over
here
to
step
one
which
is
the
readme
under
the
step,
one
directory
and
and
get
started
so
GRP
see
installing
go
we're
gonna
start
with
that.
We're
gonna
then
set
up
G,
RPC
and
protocol
buffers
so
protocol.
Buffers
Pro
talk
is
the
compiler.
A
That's
going
to
take
your
IDL,
your
interface
description,
language
that
you
create,
which
I'll
scroll
a
little
bit
looks
like
that
right.
We're
going
to
use
we're,
gonna
use,
proto,
three,
so
protobuf
three
latest
and
greatest
and
we're
gonna,
create
a
simple
service
interface
and
we're
gonna
then
create
a
few
message:
resources
that
we
can
use
to
pass
around
and
then
we're
going
to
compile
that
into
code
and
the
beautiful
thing
about
most
of
these
cross-platform
RPC
systems.
Modern
RPC
systems,
is
they
allow
your
interface
to
evolve
much
like
a
REST
API.
A
So
when
you
add
new
methods
to
a
REST
API,
it
doesn't
break
the
old
clients.
When
you
add
new
parameters
or
new
return
values
in
a
json
doc,
it
doesn't
break
old
clients.
If
you
do
it
right,
if
you
think
about
it
ahead
of
time
and
sort
of
design
for
evolution,
you
can
get
a
lot
of
mileage
out
of
an
interface
without
versioning
it
and
the
same
thing
happens
with
with
protobuf,
and
that's
one
of
the
elegant
facets
of
it.
And,
of
course,
it's
very
very
fast
and
it's
gonna
create
a
binary.
A
Serialized
object.
That's
going
to
be
smaller
than
any
json
would
ever
hope
to
be
so
a
lot,
a
lot
of
advantages
and
wins
in
in
the
protobuf
side
of
things,
and
then
g
RPC
gives
us
the
RPC
wrappers
that
we
need
to
make
it
work
and
because
protocol
buffers
and
gr
pcr
platform
and
cross-language,
you
can
use
them
with
nodejs.
You
can
use
them
with
go.
You
can
use
them
with
C++
and
Java
and
all
sorts
of
stuff,
and
it
makes
it
very
easy
to
integrate
applications
in
a
microservice
world.
A
A
We
will
tear
down
all
this
infrastructure
sometime
today,
because
an
Amazon
is
generous,
but
not
infinitely
generous,
and
so
so
the
boxes
will
go
away,
but
they'll
be
around
probably
for
an
hour
after
this
session.
So
if
you
did
want
to
work
on
it
in
the
next
session
or
something
like
that,
you'd
be
welcome
to,
and
of
course,
you
know,
as
long
as
you've
got
a
kubernetes
cluster
back
there
that's
been
set
up
right.
You
could
do
all
these
labs
anytime.
You
wanted.
If
you
were
gonna,
do
something
like
this
on
your
own
box.
A
A
Pretty
much
all
the
configs
and
all
of
the
code
that
you'll
need
are
in
these
markdown
files.
So
there's
no!
You
know
in
there
in
very
rare
cases,
there
are
some
big
heavy
helm
installs
for
like
Prometheus,
and
things
like
that
that
we'll
do
separately
an
EF
case
stack
I.
Think
as
well,
but
that's
about
it.
Everything
else
is
in
the
markdown.
So
if
you
want
to
copy
and
paste
or
if
you
you
know,
are
wondering
what
you
should,
you
know
take
with
you
that
repos
got
everything
in
it.
A
And
keep
in
mind
as
we
move
forward
into
the
other
projects,
if
you're
not
done
with
the
current
step,
you
can
keep
working
on
it.
Of
course
you
can
just
you
know,
lend
me
half
an
ear
or
no,
your
at
your
choice
and
I'll
introduce
the
next
project,
and
that
should
give
you
a
little
bit
of
a
buffer
window
too,
to
wrap
up
a
previous
step.
B
B
A
You
can
think
of
this
process
as
kind
of
like
the
tasting
menu
right.
You
get
you
get
to
see,
you
know
and
really
see
like.
You
will
actually
use
every
one
of
these
things,
but
you
won't
use
it
a
lot
right,
but
it'll
give
you
enough
of
an
idea
where
you
want
to
dig
deeper
I've
heard
some
people
asking
some
questions
in
the
ISTE
Oh
talk
like
how
do
I
dig
debug
my
service
in
the
mesh
and
I
was
like
telepresence.
A
You
know,
and
there
I
never
heard
of
telepresence
well
you're
gonna
hear
about
telepresence
in
here
and
you're
gonna.
Try
it
so
it'll
it'll
give
you
a
real
concrete
feel
for
each
of
these
projects.
Even
if
it's
you
know
high
level,
you'll
you'll
have
a
concrete
instead
of
an
abstract
understanding
of
what
they
do.
I
hope.
A
So
if
you're
not
a
go
programmer,
you
might
find
the
kind
of
the
go
package
management
sort
of
interesting
most
other
languages,
have
a
package
manager
like
pip
for
Python
or
NPM
for
node.
That
sort
of
thing
go,
of
course,
was
a
language
built
much
more
recently
than
many
of
these
others,
and
they
sort
of
just
thought
about
that
day,
one,
but
apparently
they
didn't
think
about
it.
A
Quite
all
the
way,
because
it's
a
lot
of
people
have
had
some
pretty
disastrous
challenges
with
the
package
management
at
scale,
and
so
they
basically
one
of
the
biggest
things
that
just
happened,
was
a
complete
revamp
of
gos
package
management
system.
So
you're
sort
of
one
foot
on
both
sides
of
the
train
tracks
at
the
moment,
but
it's
going
to
be
better
soon
and
a
lot
of
people
are
looking
forward
to
it
all
right.
A
Well,
what
people
are
still
working
and
cranking
away
on
gr
PC
and
playing
with
that
I'd
like
to
introduce
container
D
so
our
second
project,
so
first
CN
CF
project,
G
RPC
heavily
used
in
the
CNC
F,
and
it
is
the
API
of
container
D
right.
So
you
can
see
from
the
architectural
model
here:
you've
got
the
couplet.
A
This
is
just
a
model
of
like
kubernetes
and
how
it
would
interact
with
container
D,
so
you've
got
the
couplet
and
the
couplet
has
the
ability
to
then
talk
to
container
D
through
its
API
and
container
D
has
a
container
runtime
API
and
it
has
also
support,
for
you
know
the
kubernetes.
You
know
types
of
features
and
is
you
know
pretty
much
good
to
go
a
nice
thing
about
it?
Is
it's
the
container
manager
under
docker?
A
Now,
if
you're
using
micro
services,
that's
probably
a
weird
thing
to
try
and
do
anyway,
you
just
kill
with
it.
You
know
there
are
supposed
to
be
ephemeral,
right,
kill
the
container
and
just
start
new
ones.
You
know,
but
you
know
for
some
things.
It
does
have
some
interesting
benefits.
So
container
D
is
a
full-featured
container
manager
and
it
has
a
client
CTR.
A
But,
unlike
docker,
which
has
a
REST
API
because
docker
was
designed
to
be
exposed
over
a
network
if
you
wanted
to
doesn't
by
default,
but
if
you
wanted
to
the
container
D
runtime
was
really
designed
to
run
on
a
box
and
not
be
accessed
remotely,
though
you
could,
if
you
wanted
to,
and
it
was
designed
to
be
fast
right,
because
if
docker
is
calling
this
thing
all
the
time
we
needed
a
quick
API
rest
might
not
be
the
best.
So
G
RPC
is
the
API
there
for
container
D
and
C.
Tr
is
the
client.
A
So
when
you
install
docker,
you
get
container
D
and
you
get
CTR,
but
most
people,
just
don't
ever
look
at
them
or
know
about
them
or
use
them.
Ctr
and
container
D
are
capable
of
moving
images.
You
can
export
import,
you
can
push
and
pull
you
can.
You
know
start
containers
you
can
list.
Containers
has
a
lot
of
neat
features
and,
as
I
mentioned
a
few,
you
know
low-level
features
that
even
docker
doesn't
have.
And
of
course
it's
got.
A
Various
shims,
so
I
mentioned,
run
C,
but
it
can
also
interact
with
sort
of
the
virtual
machine
style
containers,
the
kata
guys,
and
then
this
the
Windows
stuff.
It's
a
it's
a
pretty
prolific,
little
container
manager,
because,
if
you're,
using
docker
you're
using
container
deep
so
step,
two
is
to
containerize
this
little
g
RPC
service
that
we
built
in
step.
A
Docker
has
a
build
system,
docker
files,
things
like
that
container,
these
more
a
runtime
sort
of
container
manager
and
that's
a
good
thing
right.
It
has
a
much
smaller
attack
surface,
it's
lighter
weight,
and
so
it's
better
for
production
environments,
but
it
gives
you
sort
of
the
same
assurances
that,
under
the
covers,
the
same
thing
is
running
your
container,
so
in
dev
and
test
you
might
have
docker
and
then
in
production
you
might
have
container
D
it's
fully
supported
by
kubernetes.
A
B
A
Absolutely
so,
there's
I,
don't
know
a
lot
of
people
in
here,
300
something,
and
so
if
you
are
like
it,
hey,
what's
up
with
this
network,
yeah
there's
300
people
on
the
Wi-Fi,
and
so
at
least
you're.
Not
using
your
box
right,
amazon's
network
is
the
thing
downloading
packages
and
installing
you
know,
images
and
stuff
like
that.
So
we
we
kind
of,
did
think
about
that,
and
I
don't
know
if
we
can
get
a
better
solution
just
because
the
Wi-Fi
is
what
it
is.
A
You
might
switch
to
your
phone
if
you're
experiencing
a
lot
of
problems.
I
know
I
it
with
everybody
using
it
right
now.
I'm
sure
the
experience
has
changed,
but
I
bet
I've
found
the
Wi-Fi
here
is
actually
pretty
pretty
good
anybody.
Anybody,
having
raise
your
hand
if
you
have
in
latin,
see
issues,
okay,
a
couple
people
yeah
up
and
down
a
little
bit
yeah.
So
I
guess
we
just
have
to
cope.
A
Harborough's
our
next
project,
so
you've
got
a
micro
service
or
several
you
know.
A
single
micro
service
does
not
an
application
make,
and
that's
some
of
the
reasons
that
we
need.
Many
of
these
tools.
There's
this
proliferation,
we're
getting
outnumbered
by
these
little
bits
of
code
flying
around
all
over
the
place
and
we
need
to
orchestrate
them
and
coordinate
them,
and-
and
we
also
need
to
have
a
way
of
storing
and
retrieving
them,
and
in
that
way
a
registry
which
is
a
place.
A
You
can
push
an
image
and
pull
it
from
is
kind
of
like
a
database
right
where
you
put
stuff
that
you
care
about,
and
you
get
it
back
later.
But
in
the
case
here
it's
these
little
packages
of
code
and
we
have
a
big
community,
but
especially
VMware,
to
thank
for
harbor,
which
is
a
really
awesome
registry.
That
has
a
whole
lot
of
great
features.
It's
not
like
one
of
the
light
ones
that
you
would.
A
You
know
find
out
there
in
the
early
days
where
you
could
run
it
and
push
stuff
to
it,
but
you
would
never
trust
it.
In
a
production
environment
might
not
scale,
doesn't
have
a
replication
features
or
any
kind
of
security.
Harbor
is
a
really
rich
platform
and
there's
a
lot
of
lot
of
folks
working
on
it.
It's
it's
part
of
a
few
key
ecosystems
in
the
kubernetes
space
as
an
integral
component,
so
I'm
definitely
going
to
be
around.
So
what
we're
gonna
do
is
in
this
next
section.
A
We're
gonna
use
harbor
now
harbor
is
actually
fairly
easy
to
install,
but
the
docker
image
ecosystem
wants
to
be
TLS
right
and
as
soon
as
you
go
there
right.
It's
a
big
headache,
because
now
the
sudden,
you
need
a
sign,
cert
and
a
lot
of
blah
or
you
have
to
use
these
switches
and
restart
Damons,
and
all
this
you
know,
and
a
cluster
of
eks
machines
isn't
going
to
like
breaches
and
security
like
that.
So
at
the
end
of
the
day,
it's
it's
better
to
have
something
like
this
set
up
in
advance.
A
So
we've
already
got
a
harbor
system
set
up
and
it
is
a
multi-tenant
environment.
It
has
the
ability
to
support
different
you
and
so
in
the
lab.
It's
gonna
ask
you
to
to
take
your
containerized
image
and
push
it,
and
so
we're
going
to
we've
got
creds
for
harbor
in
there
so
that
you
can
poke
around
in
the
GUI.
A
A
But
if
you,
you
know,
walk
through
this
next
step,
three
you're
gonna
get
a
chance
to
not
only
explore
the
harbor
GUI,
but
also
to
push
your
image
up
to
harbor,
to
see
how
you
can
tag
images
with
the
appropriate
name
to
send
them
around
to
different
to
different
registries
and
to
pull
them
back
down.
We're
gonna
do
all
that,
of
course,
from
container
D.
So
some
some
of
these
steps
are
going
to
reinforce
your
experience
with
the
previous
steps
and
give
you
a
chance
to
play
with
those
tools
more
as
well.
A
And
one
of
the
things
that
you
might
think
about,
while
you're
working
is
that
these
projects
that
are
part
of
the
CNC
F,
they
are
not
only
lucky,
but
they
are
worthy.
The
CNC
F
has
a
very
bright
technical
oversight
committee
that
meets
regularly
looks
at
these
project
submissions
from
different
open-source
projects
that
would
like
to
become
part
of
the
foundation
and
they're
really
careful
to
think
about
projects
that
have
the
right
diversity
that
aren't
controlled
by
a
single
organization
that
have
the
the
interest
and
the
willingness
to
develop.
A
We
don't
have
time
for
in
this
session
and
there's
overlap,
of
course,
between
them
and
some
of
them.
Even
directly
compete,
but
I
think
you
know
it
is.
It
is,
to
some
degree
a
bit
of
a
curated
group
of
projects
and
they
have
they
have
some
affinity
and
some
synergy
amongst
them
and
I
think
you'll
see
that
develop
as
we
go
through
here.
It
becomes
easier
to
work
and
to
do
things
the
further
you
go
down
this
trail
rather
than
harder
right,
which
is
weird
because,
usually
the
more
gunk
you
add,
the
worse,
it
gets.
A
A
All
right,
so
this
next
one's
a
little
bit
of
a
kingpin,
so
we
should
maybe
spend
a
minute
or
two
on
that,
but
also
it's
very
well
known.
So
we
don't
have
to
you
know,
give
it
give
it
too
much
time,
kubernetes,
pretty
amazing
platform.
There
are
a
lot
of
other
neat
things
out
there
that
do
similar
stuff,
but
kubernetes
has
really
been
a
force
of
nature.
A
You
know,
Google,
you
know
built
this
thing
and
it
was
a
tremendous
gift
and
I
know
that
they
have,
you
know,
been
paying
the
salaries
of
a
huge
quantity
of
developers.
Who
are
you
know
rare
and
precious
resources
to
work
on
this
thing
and
to
contribute
it
out
there.
So
big
thanks.
Everybody
owes
to
Google
for
for
bringing
this
about
and
making
an
open-source
and
starting
the
whole
cnc
f
off
with
it,
and
the
the
kubernetes
project
has
grown
and
grown
and
grown,
and
it's
become
pretty
darn
large.
It
was.
A
A
The
the
social
organization,
is
a
marvel
that
all
of
that
stuff
happens
and
it
works,
and
you
know
it's
not
perfect,
there's
gotchas
and
issues,
but
at
the
end
of
the
day
you
know
people
work
it
out
and
they
find
ways
forward
and
it's
been,
it's
been
really
a
pretty
amazing
project.
So
thanks
Google
and
everybody
else,
who's
contributed
to
it.
Red
Hat
huge,
huge
bunch
of
work
on
on
kubernetes
from
from
from
the
Red
Hat
folks
and
and
everybody
that
Red
Hat
has
bought.
A
So
some
other
things
to
think
about,
as
we
go
into
this
this
section
is
that
Google
sort
of
kind
of
moved
this
this.
This
idea
of
you
know
doing
imperative
things
into
this
more
declarative
approach,
and
there
are
other
platforms
that
had
done
it
before,
but
you
know
kubernetes
really
put
that
forward
strongly,
and
so
you
know
this
is
our
friend
we're
used
to
this.
A
Djamel
files
describe
everything,
and
even
now,
the
the
newer
tools
that
are
coming
along
sort
of
work
in
the
kubernetes
way,
like
sto,
for
example,
are
completely
configured
in
the
same
way.
And
so
we
have
these.
You
know
static,
declarative
kinds
of
manifests
that
we
use
to
describe
things
that
run
in
our
kubernetes
clusters.
And,
just
you
know,
I
don't
want
to
assume
that
everybody
has
used.
A
Kubernetes,
I'm
sure,
there's
somebody
in
here
and
not
used
kubernetes,
okay,
yeah,
okay,
so
there's
some
people
so
kubernetes
when
you,
when
you
want
to
run
a
workload
in
kubernetes
in
in
the
most
generic
case,
you
would
create
a
deployment
and
the
deployment
is
basically
a
time
series
of
replica
sets
and
the
replica
sets
have
templates
for
the
pods,
which
are
the
things
that
house
your
containers
right.
So
we
might
have
five
pods
of
a
certain
version
and
that's
are
going
to
be
managed
by
a
replica
set
that
the
deployment
holds.
A
Then
we
might
create
a
new
replica
set
through
the
deployment
with
a
bunch
of
pods
that
are
a
higher
version,
and
now
we
can
roll
forward
and
back
right.
Because
we've
got
this
backlog
of
all
these
different
replica
sets
and
that's
one
of
the
things
that
we
want
in
a
resilient
system.
We
want
to
be
able
to
recover,
we
want
to
be
able
to
you,
know,
roll
back
easily.
We
want
it
to
be
a
snap,
not
a
nightmare
and
the
thing
that's
hard
or
difficult
or
risky,
and
so
kubernetes
makes
that
easy
with
the
deployment.
A
And
then
we
have
services.
When
you
want
to
access
some
implementation,
it's
not
always
going
to
be.
In
the
same.
You
know
physical
form.
The
API
is
really
what
you
want
to
consume
right.
So
when
you
think
about
G
RPC
G
RPC
IDL
is
the
API
there's
no
implementation.
A
kubernetes
service
is
the
API.
There's
no
implementation,
it
says
here's
what
you
connect
to
and
I
am
representing
by
my
name
right
by
the
service
name,
the
things
I
will
offer
you,
but
you
don't
need
to
care
how
it's
going
to
be
implemented.
A
Maybe
maybe
this
deployment
is
running
under
nginx
and
has
a
bunch
of
you
know
PHP,
and
then
this
is
running
under
Apache
and
it's
got.
You
know
passenger
with
a
bunch
of
Python
applications
or
something
same
exact
functionality,
totally
different
implementation.
One
service
right
could
combine
both
of
those
deployments,
and
so,
if
you
don't
trust
engine
X
or
Pachi,
either
you
want
both
of
them.
You
want
true
diversity.
Just
like
people
want
multi-cloud
right.
That's
what
services
bring
to
the
table.
That's
what
IDL's
bring
to
the
table.
A
They
abstract
the
interface
from
the
implementation,
and
so
kubernetes
has
just
that.
The
deployment
is
the
way
that
you
get
the
workloads
up
and
running,
and
the
service
is
the
way
that
you
expose
it
to
people
to
consume
and
the
way
that
you
separate
them
from
whether
there's
two
pods
or
a
tea,
whether
you
separate
them
from
you
know,
what's
in
those
pods
which
version
they
are
that
sort
of
thing,
so
in
step,
four,
what
we
want
to
do
is
we
want
to
take
that
little
micro
service
that
we've
created.
A
We
want
to
create
a
deployment
for
it,
and
then
we
want
to
deploy
it
onto
a
kubernetes
cluster.
So
the
kubernetes
cluster
that
we've
got
to
work
with
is
a
like
30,
some-odd,
node,
I.
Think
35
node
eks
cluster
running
fairly
large
instances,
so
it
should
have
no
problem
running
the
300
odd
deployments.
You
guys
are
gonna
hammer
at
it,
but
we'll
see
I'm
sure
you'll
tell
me
if
it
does
and
then
we're
gonna
start
up
some
services
so
that
we
can
gain
access
to
it.
Now
here's
the
rub.
A
There
are
three
kinds
of
services
in
kubernetes
that
most
people
refer
to.
There's
the
cluster
IP.
You
know
you're
just
your
standard
service
where
you
get
a
virtual
IP,
but
that's
only
good
inside
the
cluster,
because
a
virtual
IP
is
a
IP
that
nobody
actually
has
right.
It's
it's
in
the
IP
tables
of
all
the
nodes
and
koop
proxy
is
injecting
it
in
there
or
the
Sdn
solution
is
doing
it,
whatever
the
case
may
be,
and
so
since
we're
outside
the
cluster,
your
laptops
are
outside
the
cluster.
A
The
VMS
that
you're
using
for
workstations
are
outside
the
cluster.
You
won't
be
able
to
use
those
dips
without
some
trickery.
The
next
thing
that
you
get.
If
you
want
to
go
one
step
higher,
is
you
can
get
a
node
port
in
a
node
port?
You
still
have
a
cluster
IP,
so
you
still
have
a
dip
inside
the
cluster,
but
you
get
a
port,
so
usually
some
30,000
or
higher
port,
and
that's
your
port,
you
own
it.
No
node
in
the
entire
cluster,
can
use
that
port
for
anything
but
accepting
traffic
to
your
service.
A
And
so,
if
you
hit
one
of
the
nodes
in
the
cluster
on
that
port,
it's
gonna
forward
that
traffic
right
into
your
service
and
voila.
So
you
can
get
in
ingress
right
to
the
cluster
with
a
node
port
service
and
you
can
design
your
own
solutions
and
for
how
you'd
like
to
do
that.
The
other
kind
of
service
is
a
load
balancer
and
the
load.
Balancer
has
the
option
of
invoking
a
cloud
plug-in
or
some
platform.
A
Now
the
bummer
is
that
we
were
notified
fairly
recently
that
all
of
the
upgrades
in
number
of
machines
for
Frankfurt,
where
we're
running
all
this
stuff
were
accepted,
but
they
forgot
the
elastic
load
balancers.
So
in
the
lab,
it's
gonna
say:
hey
start
a
load
balancer
service,
so
you
can
get
into
it
from
the
outside
and
it's
gonna
have
a
public
IP
or
a
public
DNS
name
all
that
sort
of
stuff,
and
that's
not
actually
going
to
happen
for
anybody,
but
the
first
twenty.
So
if
you
were
fast,
you
already
got
one.
A
If
you
didn't
you
know
well,
so
how
do
you
get
to
your
service?
How
can
you
test
it?
Well,
there's
a
bunch
of
different
ways
for
those
kubernetes
hacks
out
there.
You
know
you
can
just
run
a
pod
and
you
know
executive
to
and
test
it
from
inside
the
cluster,
but
but
but
for
those
who
aren't
you
can
pick
the
public
IP
of
any
node
in
that
cluster
and
then
the
node
port
for
that
service,
and
you
can
connect
there
instead.
A
So
in
the
lab,
if
it
tells
you
to
use
the
elastic
load,
balancer
a
public
dns
name
for
your
service
and
you
don't
see
one
that'll
be
because
there
aren't
any
more,
but
you'll
still
get
a
service
in
kubernetes.
Right
because
remember
it's
a
plug-in!
You're
gonna
get
a
cluster
IP
and
a
node
port,
because
you
always
get
a
cluster
IP.
If
you
want
a
node
port,
you
get
a
node
port
and
a
cluster
IP,
and
if
you
want
a
load
balancer,
you
get
a
load
balancer
and
a
node
port
and
a
cluster
IP.
A
A
We
help
you
get
connected
over
the
note
port
if
you
have
have
trouble
and
we
have
been
pinging
Amazon
pretty
readily,
but
that's
one
of
the
things
that
they
don't
just
flip
the
switch
and
set
up
a
whole
bunch
of
extra
ones
on
so
sorry
about
that,
but
give
it
a
try
and
I
think
you'll
find
that
the
labs
still
pretty
fun
and
will
give
folks,
maybe
another
five
minutes
to
work
through
it.
Before
we
move
on
to
helm.
A
All
right
so
and
again,
you
know,
keep
your
pace
if
you're
still
even
on
lab
two.
That's
fine
or
step
two.
You
know
pick
up
the
stuff
you're
interested
in
and
and
and
take
your
time,
but
I'm
gonna
go
ahead
and
while
you're
working
talk
about
helm
for
a
sec,
so
one
of
the
things
that
you
start
finding
when
you
use
kubernetes
and
anger,
is
that
you
don't
need
just
a
deployment
and
a
service.
You
often
need
five
deployments
and
five
services.
You
may
also
need
some.
A
You
know
security
stuff,
you
may
need
you
know,
buying
role,
bindings
and
cluster
roles
and
cholesteral
bindings
and
service
accounts,
and
all
these
types
of
things
you
know
config
maps
and
and
so
on
and
so
forth.
So
there's
all
of
these
great
little
utilities
in
the
form
of
resources
that
you
have
in
kubernetes,
but
keeping
them
all
together.
A
When
you
start
getting
a
decent-sized
application
deployment,
you
know,
kind
of
organize
is
tricky,
and
so
what
helm
brings
to
the
table
is
a
way
to
create
a
chart
and
a
chart
is
essentially
a
directory
and
in
that
directory
you
can
have
many
many
many
of
these
sort
of
resources.
But
one
of
the
problems
with
static
resources
right
files
that
you've
checked
into
github
is
they're
pretty
brittle
right.
You
could
have,
for
example,
a
deployment
that
has
some
environment
variables
in
it,
and
things
like
that.
A
A
If
we
could
say,
let's,
let's
do
all
the
tricky
stuff
once
and
only
once
and
then
just
plug
in
the
simple
little
like
different,
you
know
gateway
or
different
DNS
or
different,
whatever
it
is,
and
and
kind
of
keep
the
the
the
heavy-machinery
you
know
pinned
down
and
just
feed
in
some
parameters
and
so
with
helm.
We
have
the
ability
to
parameterize
the
configs
that
kubernetes
consumes,
and
so
we
can
create
these.
A
I've,
seen
a
lot
of
people.
You
might
have
heard
about
operators
right,
I've,
seen
a
lot
of
people
go
gung
ho
on
operators,
we're
gonna,
write
all
these
operators
and
go
and
engineering
writing
software.
It's
not
easy.
It's
also
not
cheap
and
when
you
think
about
what
you
can
do
with
helm
and
maybe
a
cron
job
or
two,
and
then
you
look
at
what
some
of
these
operators
do.
I,
frankly,
deeply
questioned
their
worth
they're
harder
to
maintain
harder
to
change
harder
to
update.
A
They
do
have
more
power
and
more
capabilities
for
sure
they're
integrating
with
kubernetes,
but
is
that
a
good
thing
right?
What
happens
when
kubernetes
changes?
Well,
you
got
to
maintain
that
right.
So
you
need
to
have
a
really
really
darn
good
reason
to
build
an
operator,
and
this
is
my
opinion
right.
This
is
not
you
know,
gospel
by
any
means,
but
but
I
just
think
that
the
bar
is
a
lot
higher
than
people
are
making
it.
A
People
like
the
shiny
new
thing
they
want
to
build
operators
helm
solve
so
many
problems
way
up
that
stack
in
my
opinion,
and
it
does
it
in
a
much
easier
to
maintain
faster
and
more
predictable
way.
So
it's
a
great
tool
for
deploying
even
sophisticated
applications.
I've
been
involved
in
projects
where
we
used
helm
to
deploy
stateful
set
database
s
of
service
solutions
in
Cassandra,
for
example,
and
we
thought
about
operators.
We
looked
at
it
long
and
hard.
We
just
right,
we
couldn't
justify
it.
A
We
couldn't
figure
out
why
we
would
actually
do
that
and
when
everything
that
we
needed
was
already
there
in
kubernetes.
Now
this
you
go
back
maybe
a
year
and
maybe
your
mind
changes
all
together,
because
you
don't
have
local
provisioners
and
all
other
things
that
are
coming
around
in
storage
and
stuff.
You
know
you
got
to
keep
your
eye
on
kubernetes,
it's
a
fast
moving
target,
so
helm,
really
great
tool,
lots
of
lots
of
great
features
and
our
next
step
step.
A
Five
is
to
package
up
your
whole
entire
application,
and
for
us
it's
just
a
deployment
into
service
into
a
helmet
art
and
to
deploy
it
with
that
helm
chart.
So
we
I
think
you
wiped
out
your
your
service,
your
deployment
and
service.
In
the
last
step
of
the
last
or
in
the
last,
you
know,
phase
of
the
last
step,
and
so
in
step.
Five,
we'll
redo
it
all
again,
but
this
time
with
helm
all
right
so
give
everybody
another
five
minutes
to
work
through
that
and
then
we'll
start
talking
about
observability.
A
A
A
All
right,
so
our
next
project
to
discuss
is
previous
second
project
to
graduate
I,
believe
second
project
in
the
foundation
and
an
important
thing
to
have.
If
you've
got
containerized
micro-services
being
dynamically
managed,
you
know,
there's
there's
one
on
this
machine
for
awhile,
then
it's
gone,
and
it's
over
here
now
or
there's
three
more
that
show
up
over
there.
A
You
know
things
are
moving
around,
it's
very,
very
tricky
to
sort
of
understand
and
take
the
temperature
of
a
cluster
of
thirty
five
machines
that
are,
you
know,
slowly
constantly
victim,
moving
scaling
scheduling
moving
stuff
around,
and
so
the
the
inspiration
for
Prometheus
was
the
the
internal
monitoring
system
that
Google
was
using
Borgman.
So
we
hear
tale
and
Prometheus.
You
know
kind
of,
took
a
lot
of
learnings
from
different
places
and
tried
to
you
know
kind
of
package
it
all
together
and
it's
a
it's
a
system
that
doesn't
have
to
work
on
kubernetes.
A
Well,
the
downside
of
that
is,
if
that
thing
that's
collecting
them
starts
getting
overwhelmed
because
you're,
adding
more
nodes
to
your
cluster,
more
pods
are
starting
up
more
things
are
happening
and
you're
just
pushing
more
and
more
metrics
that
things
are
going
to
get
crushed
at
some
point
and
it
has
the
choice
of
either
shedding
data,
which
is
gone
for
good
or
crashing
right.
I
mean
capacity,
is
capacity,
and
you
can't
exceed
the
physical
limits
of
a
machine.
Well,
the
neat
thing
about
Prometheus
is
it?
A
Does
the
exact
opposite
it
reaches
out
and
collects
the
metrics
from
the
things
that
it's
been
told
to
collect
them
from
now?
Of
course
you
can
have
a
push
system
with
pull
stuff
and
you
can
have
a
pull
system
with
push
stuff.
You
can
create
agents
that
will
accept
streaming
metric
and
then
create
an
endpoint
that
prometheus
can
scrape
right.
A
So
you
can
you
can
solve
that
problem,
lots
of
different
ways,
but
Prometheus
fundamentally
has
sort
of
changed
the
way
people
think
about
metrics
when
you're
building
a
micro
service
in
the
in
the
longer
version
of
this,
we
would
actually
do
this.
You
would
probably
want
to
create
a
metrics
route
or
some
interface
that
could
be
scraped,
and
so
anybody
who's
got
interesting.
Metrics,
then,
can
be
scraped
by
Prometheus.
If
there's
a
standard
format
for
those
metrics.
Hence
we
have
open
metrics
right.
A
So
a
lot
of
these
neat
kind
of
things
happen
inside
the
the
CNC
F,
and
you
know,
standard
metrics
formats
also,
you
know,
are
valuable
in
many
other
projects
and
Prometheus
also
has
a
really
elegant
time:
series
query
language,
so
it
they
they
broke
with
the
norm.
They
said:
look,
we
don't
want
to
do
sequel.
We
like
sequel,
it's
great,
but
this
isn't
a
relational
database.
A
A
For
example,
if
you
have
a
system,
that's
fairly
well
balanced,
you
know
the
memory
readings
on
that
system
might
be
pretty
flat
over
a
period
of
time
or
the
I/o
on
a
particular
device.
That's
not
being
used
might
be
zero
forever.
Well,
if
you
see
a
bunch
of
zeros,
you
can
sort
of
allied
all
the
repetition
right
you
can.
A
The
whole
stack
can
be
managed
through
Prometheus
and
another
neat
thing
about
prometheus
is
that
because
it
generally
runs
on
a
box,
it's
not
a
scale
out
type
of
thing.
It
makes
it
simple
if
you
have
bad
problems
in
your
kubernetes
cluster.
The
last
thing
you
want
to
do
is
run
your
metering
and
monitoring
stuff
on
your
kubernetes
cluster,
because
now,
when
you
need
it,
the
most
you
don't
have
access
to
it.
A
So
a
lot
of
people
will
just
stand
up
a
VM
and
run
Prometheus
on
that
by
itself
and
they'll
do
two
of
them
right.
You
don't
want
to
have
too
many
guys
scraping
the
endpoints,
because
it
is
overhead,
but
at
the
end
of
the
day,
if
one
of
your
you
know
your
your
monitoring
systems
goes
down.
You're
not
gonna,
be
happy.
If
you
don't
have
another
so
step,
six
is
to
monitor
your
applications.
So
the
idea
here
is
we're.
A
The
three
projects
that
are
kind
of
related
here
in
this
this
position,
six,
seven
and
eight-
are
our
helm-
are
not
helm,
Prometheus
and
fluent
II
in
the
context
of
the
efk
stack
and
then
also
sto,
and
this
is
because
observability
being
able
to
see
what's
going
on
in
your
application,
has
lately
been
described
as
having
three
orthogonal
facets:
meters
right,
which
is
your
time
metrics
data
that
you're
scraping
and
then
logging
right,
which
are
events
that
take
place.
Somebody
logged
in
somebody
logged
out
I
got
bad
data
right.
A
Those
are
things
that
happen
and
you
put
them
in
a
log
and
that's
managed
in
a
different
way
than
the
metrics
data
and
then
finally,
you've
got
tracing
where
you
have
context,
specific
information
that
you
want
to
know
about.
A
user
made
a
call,
and
these
things
happen
because
of
it
right.
I
want
to
look
at
this
span
of
activity
that
occurred
because
of
this
one
thing
right:
what
was
the
amplification
of
calls
through
the
system
that
occurred
and
how
do
I?
A
A
All
right
on
to
project
number,
seven,
so
fluent
e
fluent
e
is
a
really
cool
project.
It's
been
done
a
couple
of
different
times
by
different
folks,
because
it's
this
thing
that
you
just
sort
of
need.
Once
you
start
having
lots
of
applications
emitting
log
data
events,
you
need
to
do
something
with
them.
You
need
to
collect
them
together
to
try
to
make
sense
of
them,
especially
in
a
distributed
application.
When
you've
got
a
problem,
you
know
getting
a
picture
of
everything,
that's
happening.
A
The
cluster
means
collecting
all
of
that
log
data
and
being
able
to
analyze
it,
and
so
there's
a
lot
of
tools
out
there.
You
can
use
for
this
stuff,
but
fluent
D
has
really
been
a
particularly
useful
one.
It
was
written
in
Ruby
and
there
was
an
era
where
a
lot
of
DevOps,
II
sort
of
sysadmin
stuff
was
done
in
Ruby.
A
You
know,
in
particular
single
thread
of
execution
right
in
in
the
code
that
you
write
at
any
given
time.
Even
though
you
can
model
concurrency,
you
can't
get
parallelism,
and
so
what
they've
actually
done
is
they've
figured
out
the
really
choke.
You
know
tricky
choke
points
and
they've
recoded
them
in
C,
so
there's
native
libraries
in
most,
you
know
these.
You
know
scripting
languages
like
Python
and
Ruby
and
they've
really.
A
You
know
leverage
that
in
fluent
D
to
make
fluent
D
still
really
fast
and
efficient
and
low
overhead,
but
yet
still
into
like
the
other
counterpart
that
you
would
come
up
with
from
the
elastic
stack
would
be
the
log
stash
guy
right.
So
log
stash
is
the
Java
app,
so
you're
gonna
run
a
JVM
and
then
you
know
Ruby
is
its
Ruby,
so
neither
of
those
guys
were
ever
going
to
be
that
crazy,
fast,
but
or
resource
efficient.
A
And
if
you're
talking
about
something
you're
going
to
put
in
a
with
you
and
you're
gonna
have
a
hundred
and
ten
of
them
on
a
box.
You
might
want
to
think
about
different
architectures
right.
Is
there
a
way
I
can
have
one
of
them
and
just
you
know
not
not
not
run
them
all
over
the
place
and
also,
you
might
want
to
say,
hey.
We
have
a
basic
job
in
a
cloud
native
environment,
take
standard
out
stream
it
to
a
JSON
file
and
let
something
you
know
tail
it
and
forward
it.
A
So
you
don't
need
to
be.
You
know
the
Swiss
Army
knife
MacGyver
tool
like
fluent.
He
really
is,
and
so
both
the
logstash
folks
and
the
originally
treasurer
data
folks
kind
of
came
up
with
another
option,
which
was
to
have
a
very
lightweight
written
in
C.
Super
fast
version
of
fluent
D
called
fluent
bit
one
for
metrics,
and
you
know
different
one
for
this
and
that
and
the
other
thing,
and
so
it's
a
it's
an
ecosystem.
A
Really
this
whole
fluent
D
thing
nowadays
and
you
can
build
what
they
like
to
call
a
unified
logging
layer
where
you
use
fluent
bit
in
embedded
systems
and
you
use
fluent
bit.
Maybe
in
containerization
scenarios
where
you
actually
are
going
to
have
many
many
copies
of
this
thing,
packaged
in
pods
and
then
on
the
host
box
or
in
an
aggregator
role.
You
would
have
fluent
D
why.because
fluent
e
is
so
powerful.
It's
it's
massively
configurable.
A
You
can
create
pipelines
that
parse
and
transform
and
do
all
sorts
of
things
that
make
your
log
data
easier
to
ingest
into
the
storage
engine
that
you're
gonna
use
to
do
your
analytics
and
one
of
the
popular
stacks
that
people
like
to
put
together
is
elastic,
search
and
Cabana,
but
many
people
like
fluent
D
as
an
option
in
in
the
place
of
log
stash.
So
you
know
you
can
solve
any
problem
with
either
one
of
those
tools
but
fluent
DS
part
of
the
CNC
F.
A
It's
a
great
tool,
and
now
that
treasure
data
is
part
of
arm
you've
got
a
bigger
organization.
That's
that's
helping
but
of
course,
fluent
DS
an
open
source
project,
lots
of
people
involved
with
it
my
firm,
actually
just
finished,
putting
together
the
fluent
D
course
that
the
Linux
Foundation
I,
think
announced
today.
So
we're
really
proud
of
that
and
it's
a
you
know
it's
a
really
useful,
useful
bit
of
kit
and
fits
into
a
lot
of
scenarios.
A
When
you
are,
you
know
running
a
large
kubernetes
cluster
and
you
have
multiple
groups
or
organizations
or
business
units
using
it,
and
you
want
to
have
one
cluster,
because
it's
more
efficient
for
your
team
who
manages
the
cluster,
but
you
want
to
have
different.
You
know
constituents
making
use
of
it.
Do
you
run?
You
know
one
Prometheus,
or
do
you
run
many
we're
going
one
for
each?
You
know
constituency
and
it's
an
interesting
question
and
I.
A
Don't
think
there's
any
one
right
answer
without
enough
context,
but
you
can
see
people
who
do
both
where
you
can
have
a
in
Prometheus.
A
very
popular
model
is
to
have
a
federated
Prometheus
engine,
scraping
all
the
core
kubernetes
stuff
and
then,
when
people
create
a
namespace
and
deploy
an
application
where
they
need
to
monitor
their
app
right,
the
the
platform
people
might
not
know
what
to
think
about
the
app
or
what
metrics
to
care
about,
and
the
app
people
don't
know
about
what
things
to
care
about
on
the
platform.
A
So
there
really
is
a
separation
of
concerns
there.
So
quite
often
you'll
see
you
know.
Maybe
every
namespace
having
a
Prometheus
instance
that
those
people
who
have
that
namespace
use
and
you
can
kind
of
see
the
same
thing
with
elasticsearch.
So
with
this
helmet
art,
you
kind
of
get
the
idea
you
can.
You
can
blot
these
things
out
as
often
as
you
like
or
as
infrequently
as
you
like.
A
A
Okay,
so
our
second
to
last
project
fills
out
the
observability
piece
of
the
equation
in
a
micro
service
environment,
but
it
does
a
whole
lot
more
than
that.
You
know
if
you're
thinking
about
observability
to
thinking
about
tracing
and
logging
and
and
and
metrics
and
there's
all
of
that
baked
into
sto
as
well
as
a
lot
of
other
features.
Sto
has
really
robust
traffic
management
and
I
see
a
lot
of
people
like
they
start
reading.
A
Some
of
the
features
that
sto
provides
as
a
project
and
they
sometimes
get
get
confused
as
doesn't
doesn't
kubernetes
do
that
already,
for
example,
you
could
run
sto
on
a
single
kubernetes
cluster
if
you
like,
but
you
can
also
use
this
do
to
mesh
together,
VMs
and
kubernetes
clusters
running
containers.
You
could
use
sto
to
mesh
together
multiple
kubernetes
clusters,
even
in
different
clouds
or
in
different.
A
You
know
on
Prem
off
Prem
types
of
models,
so
it's
really
powerful
for
that
and
that's
what
it's
largely
known
for,
but
it
also
has
really
robust
traffic
management,
and
so
people
will
say:
hey
you
know,
I've
got
a
service
and
I
have
you
know
ten
pods
and
the
traffic
gets
distributed
across
them
yeah.
But
what
happens
when
you
want
to
roll
out
version
two,
and
you
want
to
send
some
traffic
to
version
two?
A
Well,
you
can
you
just
give
those
guys
the
same
label
that
the
service
is
picking
up
and
it'll
start
sending
traffic
to
them,
but
it's
going
to
send
the
amount
of
traffic
to
them
that
they
represent
as
a
constituent
of
the
pool.
If
there's
five
pods
here
and
there's
ten
total
pods
they're
gonna
get
half
well
what?
If
there's
you
know
explosions
going
on
over
there?
Because
it's
really,
you
know,
like
you,
just
wanted
to
test
it
a
little
bit.
A
You
don't
have
that
choice,
but
with
this
deal
you
do,
you
can
say,
send
5%
of
the
traffic
to
those
guys
there
could
be
70
of
those
pods
and
three
of
these
5%.
That's
what
you're
going
to
get
so
these
virtual
services
that
is
do
lets
you
create
give
you
really.
You
know
rich
power
over
the
traffic.
They
also
give
you
the
ability
to
do
things
that
introspect
into
the
the
the
traffic
moving
across
the
wire.
A
If
the
right
protocol
is
in
play,
which
is
HTTP,
and
so
this
also
means
to
some
degree,
we
get
some
benefit
from
G
RPC,
which
runs
over
HTTP
too
as
well.
So
it's
Gio's,
you
know
gr
co-heir
HTTP,
where
it
can
do
things
like
look
at
a
certain
header
and
send
traffic
one
way
because
of
the
header,
or
look
at
the
route
and
send
traffic
a
certain
way
because
of
the
route.
It
also
has
policy.
A
So
when
you
think
about
part
of
this
teo
is
this
pilot
piece
that
you
know
does
a
lot
of
the
routing
management
stuff.
The
policy
side
of
that
is
the
mixer
and
policies
more
like
yes
or
no
right
this.
This
is
going
to
be
allowed
or
it's
not
going
to
be
allowed
right.
I'm
not
gonna,
allow
this
traffic
I
am
gonna,
allow
it
rate
limit
quotas.
You
know
things
like
that
and
then
another
big
piece
of
the
puzzle
is
that
sto
has
security
baked
into
it.
A
So
if
you
have
two
services
that
you've
built
and
this
one's
calling
this
one
through
our
G
RPC,
you
can
use
mutual
TLS
in
the
sto
model.
Where
you'll
get
you
know,
encrypted
security
and
mutual
off.
Both
parties
will
be
able
to
guarantee
that
the
other
ones
who
they
say
they
are
and
there's
a
certificate
management.
A
You
know
system
all
built
in
so
the
neat
thing
for
me
as
a
developer
right
at
heart
and
soul,
I'm
really
pretty
much
a
C++
developer
and
when
I,
when
I
think
about
what
sto
brings
to
the
table,
it's
all
the
stuff
I
don't
want
to
do
its
these
cross-cutting
concerns
right
security
like
I,
don't
want
to
secure
the
Seventeenth
microservice
right.
I
just
want
that
to
happen.
I
don't
want
to
worry
about
health
checking.
A
A
It's
if
it's
broken,
then
something's
is
so
bad
wrong
that
you
just
don't
care
right,
where,
if
all
the
sudden
that
other
guy
moves
into
a
micro
service
and
now
you've
created
some
abstraction
and
he
makes
that
call
and
doesn't
recover
when
the
call
fails,
because
there's
a
network
blip,
then
your
application
crashes.
Well,
what
is
do
is
all
about
is
using
envoy
as
a
proxy,
which
is
also
CN,
CF
project.
So
you
could
argue
we're
sort
of
covering
ten
projects
here.
So
envoys
under
the
covers
and
envoy
is
injected
into
your
pod.
A
Finally,
so
in
this
last
lab,
you're
gonna
actually
see
sto
in
action.
We
have
this
do
running
in
the
cluster,
but
it
is
not
engaged
in
your
namespace
because
you
don't
have
the
label
on
it
and
this
labs
gonna.
Have
you
put
the
label
on
there
so
that
the
sto
injector
starts
injecting
on
void
containers?
You
run
your
service
again
and
you'll
see
automatically
there's
all
these
Envoy
proxies
in
there
and
that's
the
hook
right.
A
That's
the
thing
that
gives
sto
the
ability
to
do
all
these
amazing
things
to
do
mutual
TLS,
because
you
never
communicate
outside
your
pod
anymore,
everything
that
happens
from
your
micro
services,
local
loopback
to
envoy,
and
then
the
envoys
talk-
and
this
is
what
gives
this
do-
the
power,
because
the
Sto
control
plane
is
talking
to
all
the
envoys
and
giving
them
the
instructions,
so
have
fun
with
that
one
and
maybe
I'll,
give
folks
another
minute
and
then
we'll
hit
our
last.
Our
last
item.
A
All
right
so
I'll
take
the
last
five
minutes
to
kind
of
hit
a
little
bit
of
telepresence
here.
This
is
a
project
brought
out
by
the
awesome
folks
at
data
wire,
really
cool
project
and
just
like
the
first
time
I
saw
it.
I
was
like
I
needed
exactly
that.
I
got
this
is
so
cool.
It's
a
project
that
lets
you
basically
say:
I've
got
a
deployment
running
in
a
cluster
right,
I,
take
the
container
that's
running
over
there
and
crashing,
and
burning
and
I
run
it
on
my
machine
and
it
works.
A
A
So
what
telepresence
allows
you
to
do
is
literally
replace
the
deployment
pods
with
the
proxies
the
telepresence
proxies
and
connect
those
proxies
to
the
actual
implementation
that
you're
running
on
your
Mac
under
a
debugger
stepping
through
the
code
you're
getting
you're
literally
taking
something
that
you're
debugging
locally
and
wiring
it
into
all
of
those
funky
things
happening
inside
that
cluster
and
being
able
to
watch
them.
Real-Time
now
is
this
gonna
impact
clients
who
happen
to
be
making
a
request
against
that?
A
I
love
this
you
when,
when
you
walk
code
as
an
engineer,
you
you're,
like
I,
never
really
realized
that
this
kind
of
worked
like
that
wow.
It
changes
your
whole
mindset
right,
and
this
is
a
tool
that
lets
you
do
that
in
a
very
interesting
and
creative
way,
so
telepresence
super
cool
project
and
it's
like
crazy,
easy
to
use
and
amazed
we
fast
to
deploy
and
it
doesn't
care
what
debuggers
editors
are
ID
ease.
A
You
want
to
use
it
just
kind
of
works,
so
really
really
awesome,
awesome
bit
of
kit,
and
so
the
last
lab
is
to
play
around
with
telepresence
and
so
I
mean.
We've
only
got
a
few
more
minutes.
So
I
want
to
thank
everybody
for
coming,
really
appreciate
you
coming
out
and
listening
to
me,
I'm
Iran
for
a
little
bit
feel
free
to
reach
out
and
communicate
if
you
need
any
help
with
stuff.
A
After
the
fact,
you
want
to
try
to
redo
any
of
the
labs
or
anything
like
that,
or
just
for
whatever
reason
and
I
hope
that,
if
nothing
else,
you
kind
of
can
see
how
this
milieu
of
projects
from
the
CNC
F
they
they
have
affinity.
They
have
this.
You
know
kind
of
central
core
around
which
they
orbit.
That
really
gives
them
the
ability
to
work
together
effectively
and
in
very
creative
and
powerful
ways.