►
From YouTube: Keptn Beyond 1.0: Sailing into the...-Thomas Schuetz & Andi Grabner, Brad McCoy, Ana Medina
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe in Amsterdam, The Netherlands from April 17-21, 2023. 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.
Keptn Beyond 1.0: Sailing into the Future - Thomas Schuetz & Andi Grabner, Dynatrace; Brad McCoy, Basiq; Ana Margarita Medina, Lightstep
Speakers: Ana Margarita Medina, Andreas Grabner, Thomas Schuetz, Brad McCoy
After reaching the incubating status, the Keptn community is looking towards the bright future of the project. What lands lie ahead in the Cloud Native seas? And how do we plan to help day 2 operations?
Keptn integrates with most of the great projects in the CNCF landscape (and beyond) that help teams to deliver and operate their cloud native workloads. The integration happens through open event standards (CloudEvents, CDEvents) which is why Keptn makes it easy to connect tools and orchestrate the application lifecycle regardless of your toolchains. What could make Keptn better? Upstreaming and generalizing the best of it!
In this talk we’ll talk about new initiatives in the project: standardizing deployment events and APIs on the Kubernetes level, Keptn Lifecycle Controller for pre- and post-deployment checks, making SLOs accessible through Keptn Lighthouse and OpenSLO, and new hot integrations with other tools from the cloud native landscape.
A
I
think
you're
all
you're
all
in
the
right
spot
right,
because
we
we
give
you
a
little
overview
of
where
we,
where
we
are
where
we,
where
we
have
been
where
we
are
and
where
we're
going,
and
you
see
four
people
on
the
slide
bread
was
supposed
to
present
as
well.
Unfortunately,
he
had
to
leave
a
little
earlier
going
back
to
New
Zealand,
so
he
couldn't
make
it.
A
B
A
C
So
my
name
is
I'm
a
principal
engineer,
dynatrist
and
I.
Think
I'm
the
only
one
at
the
stage
who
contributes
code
to
Captain,
so
I'm,
a
captain,
maintainer,
yes
and
I-
was
a
platform
and
systems
engineer
for
about
the
last
two
decades
and
I'm
trying
to
get
all
of
my
experience
into
Captain
to
make
the
world
a
bit
a
bit
of
a
better
place.
B
So
I
mentioned
I
come
from
the
world
of
reliability,
I
spent
a
year
and
a
half
at
Uber
doing
a
story,
work
specifically
chaos,
engineering
and
helping
Uber
move
from
bare
metal
to
Cloud
infrastructure.
It
was
really
knowledgeable
stuff,
then
spent
four
years
at
Gremlin
doing
Chaos
engineering
and
during
that
time
I
got
a
chance
to
meet
Andy
and
Andy
was
like
hey
SRE,
like
amazing
Hot
Topic,
the
Google
srebook
had
come
out
in
2016
2017.
folks
are
starting
to
learn
more
about.
B
Oh,
our
systems
are
getting
a
lot
more
complex
and
it
takes
a
lot
to
keep
these
up
and
running
as
a
lot
of
you
possibly
have
known,
and
how
is
it
that
we
can
do
better?
What
are
things
that
we
can
automate?
Where
is
the
industry
going
and
what
that
takes
us
to
is
when
we
think
about
reliability,
we
look
at
our
SRE
teams.
Our
SRE
teams
end
up
doing
so.
B
So
we
got
to
use
more
metrics
that
tie
into
reliability
like
service
level
indicators,
agreements,
objectives
and
with
that
we
get
to
think
of
like
how
can
we
make
it
better
and
Captain
takes
that
into
account?
We
think
about.
Let's
look
at
all
those
duties
that
I
just
showed
you.
How
do
we
automate
them?
How
do
we
standardize
them?
How
can
we
make
sure
that
we're
still
thinking
about
experimentation
in
terms
of
leveraging
a
lot
of
the
other
tooling
internally
or
other
cncf
projects.
B
And
with
Captain,
what
we're
trying
to
do
is
that
we're
trying
to
bring
reliability
closer
to
every
single
developer.
How
is
it
that
they
can
know
that
they
can
actually
deploy
an
application,
because
there's
this
their
infrastructure
is
ready
or
how
is
it
that
they
can
know
that
as
they're
deploying
their
services
is
not
just,
they
deployed
it
and
Cube
cuddle
says
that
the
pods
are
up
and
running,
but
that
users
are
actually
able
to
have
a
good
experience
and
that
ties
into
some
of
the
work
that
Thomas
is
going
to
talk
about
next
too.
A
We've
been
learning
a
lot
about
folks
that
have
been
using
captain
and
what
I
really
like
about.
So
in
my
role
as
I
mentioned
in
the
beginning,
I'm,
an
advocate
I
really
try
to
help
people
adopt
this
type
of
Technology
right.
We
want
to
provide
tools
to
really
ensure
that
your
systems
stay
reliable
and
resilient,
and
you
mentioned
that
I
mean
slos
is
a
big
topic.
Everything
that
Google
has
been
talking
about
in
their
SRE
handbook
and
in
the
workbook.
Has
anybody
reads
the
S3?
A
Is
anybody
familiar
with
the
SUV
practices,
yeah,
so
I
think
what
I
think
is
interesting
with
Captain.
What
we
try
to
solve
is
we
try
to
make
sure
that
your
systems
stay
reliable
or
are
reliable
before
you
deploy
into
an
environment?
Can
I
get
shifting
left?
We
want
to.
We
actually
use
slos
before
we
deploy
into
an
environment,
because
you
don't
want
to
deploy
it
into
an
environment
that
is
not
ready
and
after
you
deploy
it.
A
Just
as
you
say,
we
want
to
make
sure
that
not
the
pots
are
up
and
running,
but
everything
is
good.
So,
at
the
core
of
Captain,
we
have
to
come.
We've
applied
some
of
the
practices
from
the
side,
availability,
engineering
book
and
tarash
made
a
really
nice
comment:
Tara
she's
one
of
the
performance
engineers
at
Facebook.
He
invited
us
to
present
at
his
performance
Summit
two
years
ago
and
he
said
Captain
feels
like
a
reference.
Implementation
of
Google's,
SRE
engineering
and
site
reliability,
workbook
so
I
think
that's
a
great
testimonial
from
an
expert
out
there.
A
What
else
have
you
learned
over
the
last
three
years?
So
Captain
was
in
well.
It
was
born
in
2019
three
years
ago,
actually
January.
So
it's
almost
going
to
be
four
years
and
there's
a
couple
of
use
cases
that
we've
seen
people
adopt
captain
for
the
most
common
one
is
automated
release,
validation.
This
is
an
example
here
from
rifles
and
software.
It's
the
software
organization
that
builds
all
of
the
online
banking
software
in
Austria
and
also
for
other
parts
of
Europe,
and
they
are
integrating
Captain
into
the
Jenkins
pipeline.
A
So
after
it
gets
deployed,
Captain
automatically
validates
their
slis
and
slos
by
pulling
the
data
from
the
observability
platform.
So
automated
release
radiation
is
really
big.
The
next
one
is
end-to-end
delivery.
This
is
an
example
from
sap
they
have
initially
used
Spinnaker
for
their
Canary
rollouts
and
they
switched
to
Captain
letting
Captain
basically
do
all
of
the
continuous
delivery
rollout
and
making
the
decisions
against
based
on
is
lows
on.
When
is
a
good
time
to
roll
out
the
next
batch
of
canaries,
and,
as
you
can
see
here-
saving
80
percent
with
the
80
percent.
A
He
actually
meant
two
things
speed
in
terms
of
deployment,
but
also
reduction
of
the
configuration
that
is
necessary
last
use
case
that
we
also
see
adopted
all
the
remediation.
This
is
from
PNG
Procter
Gamble.
They
were
in
the
initial
phases
and
were
using
Captain
to
react
on
a
problem
in
production
and
then
having
Captain
automatically
execute
remediation
actions.
If
you
want
to
read
more
about
this,
all
of
these
three
use
cases,
we
have
a
YouTube
video
on
the
captain,
YouTube
channel
for
rifa
as
an
sap
and
PNG.
A
So
you
can
see
you
know
it's
widely
adopted
now.
The
other
thing,
though,
is
we
got
a
lot
of
questions
over
the
last
years
and
I
see
some
of
you
in
the
room
that
we,
some
of
you
came
to
us.
Some
of
you
actually
gave
us
some
really
honest
feedback,
because
if
you
look
at
Captain
the
first
time
you
say
so
that
means
your
new
deployment
tool.
That
means
you're
competing
with
Argo
you're
competing
with
Spinnaker.
Is
that
what
you
do?
10
people
say
so
you're
monitoring
tool,
because
you're
looking
at
slos?
A
Is
that
what
you
do
or
are
you
an
auto
remediation
tool?
Are
you
an
SLO
tool
because
you're
doing
a
solos,
so
you're
a
testing
tool,
because
you
also
execute
tests
or
well
you
also
workflow
engine,
because
you
can
do
all
these
things.
So
we
got
a
lot
of
questions
because
I
think
we
really
went
off
into
many
different
areas
and
we
built
something
that
can
be
used
for
all
of
these
things.
But
remember
we
started
with
all
of
this.
A
2019,
the
world
2019
looked
a
little
bit
different
I
think
in
2022
at
least
most
of
the
people
we
talk
to
they're
using
Argo,
CD
or
Flex
for
the
deployment
they
are
much
better
suited
for
that
they
have
Argo
rollouts
for
Canary
deployments.
You
don't
need
Captain
for
that,
all
right,
that's
great
observability
platforms.
We
have
open
Telemetry
with
Prometheus,
we
have
light
step.
We
have
Diana
Trace.
These
are
all
great
observability
tools,
so
we
don't
need
to
think
that
Captain
is
an
observability
tool.
A
A
The
second
thing
we
learned:
we
have
built
a
lot
of
Integrations,
even
though
we
standardized
on
a
protocol
or
on
a
on
a
format.
We
had
to
build
a
lot
of
Captain
Services.
However,
most
of
them
have
been
built
but
are
not
well
maintained,
because
most
of
the
people
are
really
tending
to
go
back
to
the
core
use
case,
which
is
I
use.
My
other
tools
for
deployment
I,
don't
need
Captain
to
do
my
deployment.
So
please
give
me
a
better
integration
into
the
existing
way.
How
I
do
things
I
want
to
use?
A
C
Yes,
thank
you.
Andrew.
In
the
time
we
have
developed
Captain,
we
developed
a
lot
of
possibilities
to
extend
other
tools
into
captain,
so
we
had.
We
had
around
three
integration
options.
One
was
dedicated
Captain
Services,
which
was
a
bit
heavyweight
because
everyone
who
wanted
to
integrate
the
tour
had
to
create
an
uncapped
service.
To
achieve
this,
the
second
one
was
that
we
created
our
own
Runner
called
the
job
executor,
which
made
everything
a
bit
easier,
but
also
not
also
was
not
the
perfect
approach
for
doing
this.
C
C
You
can
integrate
almost
everything
with
a
job
executor,
but
none
of
them
was
really
really
nicely
maintained,
so
I
think
from
the
from
the
Integrations.
We
had
five
to
six
from
maintained.
Right
and
last
but
not
least,
we
were
an
event-based
manner
system
and
we
had
our
control
plane
and
every
tour
which
has
been
used
needed
a
subscription
on
our
control
plane
and
the
management
of
the
subscriptions
was
also
kind
of
challenging.
C
So
we
decided
to
go
on
A,
New
Path
and
what
we
found
out
in
the
last
three
years
and
I
think
every
one
of
you
agrees
is
that
kubernetes
is
the
leading
platform
for
our
Cloud
native
apps,
so
I
think
a
few
thousand
people
are
here
at
the
conference.
I
think
this
is
to
prove
that
kubernetes
is
the
Easter
platform
for
this.
The
second
thing
is
that
gitops
is
the
dominant
approach
to
deliver
these
apps,
so
we
need
to
find
a
way
how
to
get
continuous
delivery
on
the
on
the
platform.
C
Instead
of
having
a
whole
lot
of
tools.
Therefore,
we
try
to
standardize
task
definitions,
evaluations
and
application
life
cycles
using
captain.
So
we
want
to
get
all
of
these
things
into
the
into
the
cluster.
We
don't
want
to
be
out.
So
sorry,
we
want
to
be
abandoned,
neutral
and
if
anyone
should
be
able
to
integrate
in
a
very
easy
way-
and
last
but
not
least-
and
this
is
the
thing
I
mentioned
before-
Captain-
shift
your
delivery
process
to
the
platform
in
a
cloud
native
way
and
pipeline
lists.
C
C
C
C
It
works
with
all
of
the
all
of
the
principles
of
key
tops
and
we
are
trying
to
make
the
delivery
pipeline
list
external
tools
and
control
planes
should
be
easily
easy
to
integrate.
So
we
created
some
kind
of
custom
resources
for
our
for
our
Integrations,
where
you
can
specify
your
tasks
either
inline
you
can
use
them
from
a
from
a
web
server
or
whatever,
but
I
think
this
is
done
in
a
very
intuitive
way
and
very
easy
for
each
for
each
of
the
in
the
integrators.
C
You
get
deep
insights
in
your
deployment
process
as
we
will
see
for
armful
and
further
consequence.
So
you
see
it
every
at
every
point
in
time
where
your
deployment
stays
at
the
moment.
How
successful
it
was,
how
mature
will
your
process
will
be
and
where
you
can
evolve
your
deployment
process
and
last
but
not
least,
you
get
Cloud
native
and
application
aware
control
over
your
deployments.
C
C
In
fact,
all
of
them
tune
nothing
more
than
applying
anything
as
something
to
kilometers,
and
this
is
where
our
work
begins.
So
after
you
deploy
something
to
kubernetes
and
when
you
define
an
application,
we
are
doing
application,
pre-deployment
checks
or
tasks
and
evaluations.
Therefore,
you
could
check,
for
instance,
if
you
have
enough
infrastructure
to
get
the
application
running
at
the
booth.
I
showed
an
example
where
I
tried
to
test.
If
there
is
enough,
if
there
are
enough
processors
left
to
get
this
application
running
in
further
consequence.
C
C
This
runs
per
workload
after
after
that,
so,
after
all
of
the
pre-deployment
tasks
have
finished,
we
can
let
you
kubernetes
its
work
and
schedule
the
port
and
after
the
port
has
been
deployed,
deployed
and
is
running.
We
can
do
the
same
thing
with
post
deployment
tasks
also
on
a
workout
level,
but
on
an
application
Level
too.
C
Furthermore,
our
lifecycle
controller-
is
they
want
tasks
with
simple,
simple
scripts,
so
everything
you
do
here,
such
as
checking
for
infrastructure,
Readiness,
validating
error
budgets
or
for
post
deployment
things
running
tests
and
evaluated
slos
can
be
done
in
a
way
which
the
most
of
us
understand.
So
in
a
you
can
write
simple
typescript
functions
in
the
future.
A
C
C
We
have
a
web
hook
running
this
webhook
checks
for
this
labels
or
annotations,
and
if
they
are
set,
we
are
injecting
our
own
scheduler
extension
and
with
these
schedule,
extensions
listens
on
our
custom
resource
definitions
takes
care
of
that.
Your
pre-deployment
tasks
have
finished
and
when
they
are
finished,
we
let
we
bind
the
port
until
our
scheduler
binds
support
and
therefore
advancing
kubernetes.
A
Very
cool
and
what
I
loved
about
it?
Also
the
feedback
we've
received.
That
means,
however,
whatever
you
use
right
now
for
a
deployment
tool.
Some
of
you
work
in
organizations
that
have
multiple
tools.
If
you
try
to
enforce
pre
and
post
deployment
checks
in
your
tools,
you
potentially
need
to
re-implement
the
same
thing
in
Jenkins
and
gitlab
in
auto
tools
and
with
this
we're
bringing
all
of
these
life
cycle,
Checks,
Into,
The,
Core
platform
and
that's
the
beauty.
B
And
the
I
think
one
of
the
other
wins
with
it,
too,
is
that
you
actually
get
to
standardize
the
based
on
the
severity
of
your
the
services.
So
when
we
think
about
having
those
large-scale
systems
like
those
10
critical
applications
like
those
kind
of
get
to
keep
the
exact
same
evaluations,
so
that
you
kind
of
keep
up
that
same
sim
or
similar
like
service
level
objective
at
the
end
of
the
day,.
C
So,
and
what
you
see
on
this
slide
here
is
that
you
can
get
you
can
get
more
information
about.
What's
going
on
in
your
in
your
deployment
process,
buy
this
Matrix
and
traces
we
are
exposing
from
are
from
open,
tele
with
open
Telemetry.
So,
for
instance,
we
managed
to
get
information
about
how
much
time
passed
between
two
deployments
on
a
workloading
application
Level,
and
this
is
a
good
indicator
for
the
maturity
of
your
of
your
deployment
process.
C
Furthermore,
we
let
you
know
how
often
the
deployment
failed
and
succeeded,
which
is
also
very
nice
when
you
want
to
find
out
how
good
your,
how
good
your
application
is
developed
when
it
gets
to
production
and
on
the
other
side
we
also
get
a
full
Trace
over
our
deployment
process.
So
we
know
how
long
it
takes
to
run
to
until
the
poll
runs.
We
know
how
long
our
pre-deployment
tests
checks,
run,
post
deployment
checks
and
so
on.
C
So
we
always
know
where
we
can
approve,
and
the
very
nice
thing
in
this
case
is
that
we
notice
on
the
application
Level.
So
when
we
deploy
a
whole
application
at
not
only
one
workload,
we
know
how
long
it
took
to
deploy
the
whole
application,
and
this
is
very
important
in
some
in
some
cases,
as
I
told
you
before,
you
can
run
your
own
tasks
and
evaluations,
and
some
of
you
might
have
wondered
how
this
looks
like.
So
this
is
some
kind
of
a
configuration
for
that
we
have.
C
C
The
second
thing
we
created
was
was
a
captain
evaluation
definition,
and
this
is
here
to
find
out
how
to
check
some
metrics
against
thresholds
to
find
out
if
your
application
simply
runs
just
for
completeness.
This
might
change
a
bit
in
the
moment
in
the
future,
as
we
as
the
project
evolves
and
as
we
know
in
which
direction
this
will
go.
C
Furthermore,
you
get
vendor
neutral
obserability
using
the
open,
Telemetry
stuff,
the
integration
of
external
tools
and
your
own
code
is
very
easy,
so
you
simply
have
to
write
a
function.
You
can
easily
integrate
in
webhooks
and
whatever
you
like,
and
this
in
a
very
simple
way,
and
last
but
not
least,
the
whole
thing
is
in
installable
and
configurable
in
a
very,
very
easy
way,
so
the
configuration
is
in
your
kubernetes
manifests
and
in
two
to
three
external
customer
resource
definitions.
The
installation
is
one
manifest
at
the
moment.
C
A
Yeah
exactly
so,
first
of
all,
just
to
recap:
we
have,
if
you
go
to
the
captain
website
right
now,
you
will
see
what
Captain
100
looks
like
our
first
iteration
of
it
that
I
mentioned
in
the
beginning.
We
are
currently
targeting
a
1-0
release
in
November
and
then
with
a
long
time,
support.
There's,
also
all
the
information
you
can
find
on
what
we
built
here-
lifecycle
controller,
the
future,
the
stuff
that
we
learned
over
the
three
years
and
really
making
it.
A
So
please
you
know
if
you
see
any
of
them,
thank
you
and
if
you
are,
if
you
happen
to
be
in
the
room
and
recognize
yourself,
thank
you
as
well
yeah,
the
last
thing
before
we
open
up
for
Q
a
if
you
want
to
get
in
touch
with
us.
Please
join
the
conversation
on
the
cncf
Slick.
There
is
a
captain
Channel
and
now
also
the
captain
app
lifecycle
working
group.
You
know
you
can
also
help
us
by
storing
us
on
GitHub
and
spreading
the
words
giving
us
feedback.
I.
Think
that's
very
important.
A
I
see
people
taking
pictures,
that's
great
if
I'm
not
mistaken,
there's
one
more
thing
exactly
if
you
like
this
session,
please
give
us
feedback,
that's
always
very
welcome
and
we
have
a
lot
of
Swag
here.
There's
like
t-shirts
in
medium
large,
small
and
extra
small.
We
have
stickers,
we
have
some
hits
and
we
have
even
more
of
the
swag
down
at
the
captain.
Booth
in
the
Pavilion
I
think
we're
still
there
until
4,
30ish
or
five
o'clock,
but
now
we
have
one
minute
for
questions
or
maybe
two
or
three
yeah.
A
A
However,
you
right
now
need
to
integrate
Captain
Bono
on
your
existing
pipelines,
so
one
use
case
will
be
instead
of
integrating
and
calling
Captain
Bono
from
all
of
your
pipelines,
install
the
captain,
lifecycle
controller
and
as
a
pre
or
a
post
task.
You
can
trigger
your
existing
Captain
sequences.
For
instance,
there
will
be
an
option
so.
A
D
A
Thank
you
and
the
thing
like
going
further
Thomas
was
saying
right
now:
the
SLO
validation
we
just
started
with
it
on
the
captain,
life
cycle,
control,
I'm,
pretty
sure
we'll
get
on
par
with
what
we
have
in
Captain
1.0.
We
are
also
working
with
the
openness,
hello
Community,
to
figure
out
how
we
can
also
adapt
this
standard
right.
E
C
So,
currently,
cap
nap
is
a
bundle
of
workouts
and
this
one.
This
bundle
has
a
version.
Therefore,
you
can
define
an
application
in
a
way
where
say
I
have
the
application.
For
instance,
our
theme
application
was
called
The,
Potato
Head
and
we
had
five
workouts
in
different
versions,
and
this
is
what
what
an
app
defines
for
us.
So
we
are
not
doing
Progressive
delivery.
At
the
moment,
we
are
only
making
sure
that
the
application
in
this
version
with
the
workloads
in
several
versions
is
available
at
the
moment.
F
C
A
C
A
A
What
you
think
I've
shown
earlier
we're
currently
supporting
prompt,
ql
queries,
and
we
also
want
to
get
on
par
with
what
we
have
there
with
the
concept
where
you
can
plug
in
different
providers,
where
you
specify
in
a
crd,
what
type
of
query
you
want
to
execute
against
that
Target
environment
and
that
query
is
then
executed
by
a
data
source
provider
and
I'm
sure
there
will
be
some
standard
implementations
for
whatever
like.
If
we
decided
to
go
with
open
SLO
and
they
already
have
a
provider,
then
they
should
work.
C
I
think
for
us
in
the
future,
this
will
be
simply
an
observability
provider
where
we
can
query
data.
Definitely
is
this:
we
didn't
write
it
until
now,
but
it
might
be
possible
in
the
future.
So
if
you
have
some
requests
such
as
this
or
I
want
to
discuss
these
things
a
bit
a
bit
more
detail
and
we
can
stay
in
touch
and
talk
about
this
and.