►
Description
As resilience use-cases proliferate, Chaos Engineering has become a compelling practice for enhancing your application resilience in production. If you’ve ever gone through the pain and anxiety of responding to an unexpected failure in your production system, then Chaos Engineering is the right fit for you.
Whether you want to run chaos manually or through CI/CD! Litmus brings together configurable environments to trigger chaos experiments automatically with the change in application states. Chaos on the Edge with Litmus brings together thought leaders, technologies, and customers across the entire Kubernetes community to share their knowledge and insight. If Chaos Engineering is on your radar, this is a talk you won’t want to miss!
A
Hola,
namaste
and
a
very
warm
welcome
to
this
talk,
automating
chaos
with
litmus
chaos
to
ensure
kubernetes
application,
resiliency
first
things.
First,
I
would
like
to
thank
the
organizers
for
organizing
this
amazing
kcd
africa
edition,
and
I
would
also
like
to
thank
all
the
viewers
and
all
the
participants
and
all
the
speakers
who
have
ended
up
making
this
conference
a
success,
and
I
look
forward
to
many
more
editions
of
kcd
africa.
A
Moving
on
introducing
myself.
My
name
is
prithvi
raj
and
I'm
based
out
of
bhubaneshwar
odisha
india.
India
is
going
through
a
very
tough
time
due
to
the
covet
19
crisis,
and
I
hope
everyone
is
praying
for
india
and
we
pray
for
the
same
that
we
get
out
of
this
condition
very
soon.
I've
been
I
work
at
chaos
native
as
a
community
manager
for
litmus
chaos,
and
since
one
year
I
am
working
with
litmus
kiosks.
I
joined
my
data
back
in
2020
and
then
chaos
net,
focusing
on
chaos,
engineering
itself.
A
My
co-speaker
is
cyan
model,
who
I
mean,
there's
a
lot
to
talk
about
him,
but
he
majorly
works
as
a
software
development
engineer,
as
well
as
a
chaos,
engineering,
a
chaos
engineer
point
a
new
term
which
has
been
coined
after
chaos.
Engineering
came
into
play
and
he's
gonna
talk
more
about
the
technical
aspects
and
I'll
start
with
the
introduction.
So
moving
on
to
the
agenda
that
we
have
in
hand
first
things
first
we'll
be
talking
about
chaos.
A
What
is
kiosk
engineering
and
a
lot
of
people
might
be
knowing
about
the
term
knowing
what
chaos
tests
are
exactly,
but
it's
also
for
the
ones
who
do
not
know
about
it
and
obviously,
then
we'll
be
moving
on
to
okay
us
using
the
cloud
native
of
kubernetes
systems.
What
exactly
is
litmus
chaos
and
further
sign
we'll
be
taking
forward
talking
about
the
crds
and
how
you
can
install
litmus
and
you'll,
be
giving
a
technical
demo
and
showing
you
dashboards
and
how
you
can
deploy
your
kiosks
experiment
to
your
first
year's
test?
A
So
first,
first
things.
First,
I
would
like
to
thank
the
cncf
for
obviously
thinking
about
chaos,
engineering
as
one
of
the
technologies
to
look
up
to
one
of
the
most
sought
after
technologies
in
2021
and
beyond,
and
I
think
you
all
might
agree
that
chaos
testing
is
coming
up
in
a
grand
way.
So
what
exactly
is
chaos
testing
before
that
I'll
start
with
an
example?
Obviously,
as
you
can
see,
my
my
ppt
or
my
page
shows
slide
shows
that
down
times
are
expensive.
A
Kiosk
engineering
is
a
term
coined
by
netflix
netflix
coined
this
term
and
netflix
started
off
chaos
way
back
in
2011
and
they
started
it
to
test
their
systems
to
check.
How
does
chaos
function
so
basically,
chaos
engineering
is
nothing
but
putting
it
or
putting
in
or
inducing
a
fault
in
the
system
to
figure
out.
How
will
the
system
actually
react
when
there's
an
outage
or
when
there
is
a
downtime,
so
basically
predicting
what
will
happen
in
the
future
beforehand,
so
that
that
outage
doesn't
occur
in
future
and
doesn't
occur
when
the
system
is
in
production?
A
So
why?
Why
is
chaos
testing
important
or
exactly?
Why
should
you
think
about
chaos,
because
you
need
to
test?
You
know
you
shouldn't
wait.
We
believe
in
the
chaos
first
principle.
That
is
why
test
your
system
when
it
already
goes
through
an
outage,
why
I
don't
test
it
before,
and
this
also
helps
in
activating
the
feedback
loop
in
the
devops
system.
A
Devops
engineers
and
sres
need
to
focus
on
chaos
engineering
so
that
they
can
go
ahead
with
proactive
testing
in
production
staging
in
the
ci
cd
anywhere,
and
they
can
actually
predict
what
can
happen
and
save
their
systems
from
these
outages.
So
how
is
like
what
exactly
is
the
state
of
kiosk
engineering
till
now?
Obviously,
there
are
standard
practices,
a
few
companies,
big
companies
like
amazon,
netflix
flipkart,
I
mean
the
apple
google.
These
companies
have
already
started
practicing
chaos
in
some
way
or
the
other,
but
this
is
limited
to
experts
and
enthusiasts.
A
Those
are
already
aware
of
what
chaos
is
or
those
are
already
aware
of
what
exactly
chaos
engineering
does.
They
are
more
into
adoption
and
slowly
people
have
started
adopting,
although
the
the
there's
still
time
to
it,
and
obviously
it's
part
of
large
deployments.
Various
companies
have
come
out,
let's
say
ibm
and
maybe
various
folks
are
applying
chaos
in
their
large
deployments,
but
we
believe
that
small
deployments
are
you
know.
A
Individuals
should
also
get
started
practicing
chaos
because,
as
of
now,
those
have
already
burned
their
hands,
those
who
have
already
seen
what
how
an
outage
occurs
for
them.
As
a
resolution
is
chaos,
engineering,
but
a
chaos,
engineering
practice
can
be
a
resolution
for
each
and
every
engineer
or
each
and
every
company.
So
moving
on,
we
can
see
kubernetes.
As
we
know,
we
are
talking
about
kubernetes
here.
It's
it's
already
crossed
the
chasm.
A
It
has
already
reached
the
mainstream
market
and,
as
you
can
see,
most
of
the
people
are
majority
of
the
people
have
adopted
kubernetes
in
some
way
or
the
other
to
build
their
infrastructure
or
architecture.
But
what
about
chaos?
Engineering?
How
is
chaos,
engineering
faring
in
the
chasm?
We
believe
chaos
engineering
is
yet
to
cross
the
chasm
it's
still
in
the
early
market
and
we
are
seeing
you
know
early
adopters,
there's
early
adoption,
but
it's
yet
to
see
me
go
to
the
mainstream
market
in
form
of
a
huge
business
or
in
form
of
huge
adoption.
A
There's
still
a
lot
to
do
and
a
lot
to
develop
so
that
people
can
adopt
chaos
and
there's
there's
a
lot
of
fear
in
people's
minds
as
well.
That
should
I
adopt
chaos.
Undoubtedly,
you
should
go
ahead.
Adopting
chaos,
engineering,
because
testing
for
infrastructure
and
systems
moving
on
how?
How
is
it
typically
done?
How
is
chaos
engineering
practice?
Usually,
chaos
is
giving
practice
to
game
days
and
some
of
them
have
already
integrated
them
in
their
ci
series.
But
as
of
now
only
sres
are
practicing
chaos.
Engineering.
A
Here
chaos
engineering
is
practiced
by
basically
q,
a
engineers,
sres
or
devops
engineers,
but
most
of
the
developers
have
still
not
started
engaging
in
chaos
engineering,
but
we
believe
that
every
developer
should
try
and
practice
cures
in
some
way
or
the
other.
If
not
today,
think
about
it
tomorrow,
manual,
planning
and
execution
is
happening.
It's
it's
obviously
necessary,
but
preparing
a
roadmap
is
something
we
believe
can
help
enterprises
or
help
companies
come
forward.
Adopting
chaos.
Observability
is
a
very
important
aspect.
A
People
need
to
think
about
monitoring
these
chaos
tests
and
which
is
obviously
not
a
commodity.
Everyone
needs
to
think
about
observing
the
chaos
test.
So
what
is
happening
so
typically,
as
of
now
there's
a
long
road
ahead,
people
need
to
start
looking
at
what
are
the
practices
that
they
need
to
start
to
adopt
chaos
or
to
get
started
with
your
engineering,
because,
all
in
all,
eventually
it's
gonna
increase.
A
Your
resilience
increase
your
reliability,
so
moving
on
we'll
be
talking
about
cloud
native
chaos,
engineering,
what
is
exactly
cloud
native
chaos
and
how
does
kiosk
engineering
function
in
the
kubernetes
world?
Obviously
kubernetes
is
a
very
dynamic
space
and
every
now
and
then
with
such
a
huge
amount
of
adoption
and
with
highly
dynamic
applications
being
built,
there
might
be
an
outage
or
a
fault
here
and
there
and
there
are
security
concerns
or
there
might
be
concerns
of
testing
amongst
engineers
and
sres.
So
how?
A
How
does
chaos
engineering
come
into
play
on
in
the
kubernetes
way
or
in
the
community
space?
Obviously,
for
example,
there
might
be
an
outage
in
a
pod
and
a
node,
so
experiments
like
pod
delete
or
no
delete
respectively
come
into
play
and
help
you
understand
and
analyze
how
your
system
might
behave.
There
are
a
lot
of
experiments
that
can
come
up.
I
I
have
heard
about
black
hole,
experiments
and
unlimited
experiments
that
that
can
be
possible.
A
But
what
exactly
is
cloud
native
chaos
engineering,
so
the
principles
that
we
believe
of
cloud
native
kiosk,
obviously
it
needs
to
be
open
source
open
source
is
the
future.
Every
other
technology
is
coming
out
to
be
open,
so
the
cloud
native
world
is
obviously
based
on
open
source
technologies,
which
further
leads
to
community
collaboration.
It's
very
important
for
the
community
to
come
out
and
suggest
changes
or
work
together,
hand
in
hand
suggesting
what
are
the
additions
or
what
are
the
issues
that
can
be
created
and
how
a
project
can
develop.
A
Obviously,
with
with
kiosk
engineering
having
custom
resources
and
all
the
ml
files,
I
think
an
open
api
and
life
cycle
management
is
very
important
for
chaos,
engineering
to
be
cloud
native
and
obviously
scalability.
We
do
not
talk
about
scalability,
but
scalability
is
very
important,
and
that
is
why,
as
kubernetes
is
being
like,
the
principle
of
kubernetes
are
being
changed
by
github.
Skilltops
is
very
important
for
kiosk
engineering
to
be
adopted
and
for
users
to
get
a
whole
new
experience
and
observability.
A
As
you
know,
as
I
mentioned,
monitoring
is
very
important
ex
these
experiments
and
how
their
function
should
be
monitored.
So
open
observability
helps
users
to
monitor
these
experiments
properly.
So
moving
on
litmus,
as
you
know,
follows
all
these
principles
and,
I
think,
is
a
cncf
sandbox
project.
Having
a
pool
of
amazing
experiments,
we
will
go
to
go
back
to
the
next
slide
and
talk
about
it
and
they
follow
all
these
principles
and
it
is
built
for
modern
chaos.
Engineering.
A
It
is
coming
up
in
such
a
way
where
chaos,
engineering,
the
dynamism
of
chaos,
engineering
will
change
and
testing
will
will
become
feasible
and
easier
for
each
and
every
engineer
out
there
testing
on
their
communities
architectures.
So
what
exactly
is
nothing
but
an
open
source
tool
set
practicing
highly
scalable
kiosk
engineering
practices
for
sres
developers,
kubernetes
engineers,
software
engineers,
who
who
want
to
practice
chaos
tests
in
somewhere
and
want
to
bring
in
the
resiliency
in
some
form
to
their
communities
applications?
As
you
can
see
the
stats.
A
Obviously
stats
do
not
define
a
lot,
but
it
has
got
a
pool
of
contributors,
1600
plus
github
stars.
We
are
talking
about
community
here
at
the
cncf
kcd
africa
and
community
is
what
is
what
matters
when
I
joined
back
last
year,
this
project
just
had
60
slack
members
and
500
github
stars,
but
now
you
can
see,
there's
a
pool
of
experiments.
A
The
github
stars
are
increasing
and
the
project
is
seeing
amazing
amount
of
attraction
in
the
community,
and
we
believe
that
in
the
upcoming
years
this
chaos
testing
is
going
to
be
the
go
to
project
or
go
to
technology.
To
look
forward
to
with
this,
I
would
like
to
hand
over
to
my
co-speaker
scion
model,
who
will
be
getting
into
the
in
depth
of
fitness
chaos
and
kubernetes
applications
resiliency.
Thank
you.
Folks.
B
B
So
to
start
off
with,
I
am
going
to
show
you
how
you
can
install
litmus.
So
there
are
two
ways
you
can
do
it
either
using
helm
or
you
can
directly
apply
the
manifest.
So
if
you
visit
the
litmus
docs
beta,
dot,
netify
app-
and
you
move
over
to
this
installation
section
and
over
the
con
over
to
control
plane,
you
should
be
able
to
see
installation
using
helm
and
using
cubesat
apply
the
manifest
command.
So
this
is
the
2.2.0
manifest
that
is
currently
we
have
the
current
version
we
have.
B
You
can
use
that
version
or
you
can
go
to
the
github
repository,
which
is
litmus
chaos
litmus
github.com
and
go
to
this
folder
called
litmus
portal.
Once
you
are
inside
the
folder
scroll
down
to
see
the
readme
section
and
you
should
be
able
to
see
installation
using
k
test
manifest,
so
you
can
either
apply
the
master
latest
cluster
scope
manifest
or
the
2.0
beta
4
manifest.
B
B
B
So
if
you
take
a
look
at
this
diagram,
this
is
basically
the
crds
that
linmus
leverages
the
three
primary
chaos
crds
we
have
is
chaos,
experiment,
kiosk,
engine
and
class
results.
So
what
we
have
here
is
chaos.
Experiment
comes
first,
which
has
been
fetched
from
chaos
hub
now.
What
is
chaos
up?
We
have
a
list
of
different
experiments
listed
down
in
our
hub,
which
is
hub.litmuscloser
io.
B
If
you
visit
this
particular
hub,
you
would
see
a
lot
of
public
chaos,
experiments
already
up
and
running
for
you,
so
you
can
pick
any
one
of
these
experiments.
They
are
predefined
and
you
can
either
build
on
top
of
it
or
you
can
just
use
this
pretty
fine
ones.
Now
this
is
what
chaos
hub
is.
You
can
pull
this
experiments
and
start
you're,
injecting
chaos
directly
with
the
predefined
configurations,
so
the
chaos
experiment.yaml
is
what
pulls
this
particular
chaos
experiment.
So
the
kiosk
experiment,
crd,
is
basically
a
low
level
chaos.
B
Your
chaos
experiment
itself
with
the
default
tunables.
Now
chaos
engine
is
what
binds
the
application
instance
with
this
particular
experiment.
A
chaos
engine
is
what
would
trigger
your
chaos
injection
in
your
particular
application.
So
chaos
experiment
is
only
installing
the
experiment
not
injecting
it
kiosk
engine
would
bind
your
application
instance
with
the
experiment
and
inject
it,
and
the
chaos
result
is
what
would
store
all
the
default
parameters,
the
status
of
your
experiment
and
those
things.
So
it
will
save
a
word.
It
will
say:
if
you
have
probes
in
your
system
it
will.
B
It
will
save
the
status
of
your
probes,
the
success
percent
and
those
things.
So
it's
basically
store
the
metrics.
So
what
chaos
operator
will
do
is
it
will
take
a
deeper
watch
into
chaos
engine
and
whenever
a
kiosk
engine
is
triggered,
it
will
also
spawn
a
kiosk
runner
and
the
chaos
runner
part
is
who
is
responsible
for
spawning
multiple
chaos,
jobs
and
these
chaos?
Jobs
are
nothing
but
the
particular
chaos
experiment
which
are
so.
Let's
say
you
want
to
run
a
40
liter
of
container
kill.
B
So
the
kiosk
runner
would
the
net
kia
center
part
would
spawn
multiple
quadra
pod,
delete
or
multiple
container
kill
jobs
that
you
have
scheduled
as
per
your
particular
tunables.
So
you
can
do
all
these
tunings
in
the
chaos
engine
itself.
So,
whatever
a
way
you
have
tuned
and
overridden
the
basic
tunings
in
that
particular
manner,
the
kiosk
runner
would
generate
successive
chaos,
jobs.
You
can
either
change
the
chaos
duration.
You
can
add
annotations
to
control
the
blast,
radius
and
all
those
kinds
of
things.
So
that's
it
in
a
high
level.
B
So
let's
go
back
to
the
previous
watch
statement
and
take
a
look
so
now
we
can
see
that
this
has
been
finished.
If
I
just
get
out
of
the
watch
command-
and
I
see
take
a
look
at
the
installed
steps,
so
you
can
see
that
it
has
installed
this
configure
this
namespace
litmus
and
the
configmap
deployment
services,
the
rule
bindings
and
all
the
dependencies
that
are
needed,
for
it
must
run.
If
you
install
a
helm
or
apply
the
beta
manifest
you
need
to
install
the
name,
create
namespace
of
litmus
first.
B
So
if
you
go
through
this
documentation
of
how
to
install
you
can
find
all
these
different
details.
But
if
I,
if
you
apply
the
latest
master,
manifest
it'll
create
the
namespace
for
you
now
that
we
have
litmus
installed
and
let
me
go
back
to
the
watch
statement
since
this
is
going
to
be
handy,
I'll,
open
another
tab
and
I'll
check
I'll.
Take
a
look
at
those
I'll.
Take
a
look
at
the
different
services
that
are
there
currently
in
litmus
same.
B
Space,
so
we
can
see
that
there's
the
litmus
for
the
front
front,
end
the
server
service
and
the
server,
so
we
need
the
node
ip
followed
by
the
port
in
order
to
visit
our
front
end
service.
So
in
this
case
I'll
just
go
and
I'm
going
to
use
my
mini
qyp
with
this
particular
front-end
port.
There
is
going
to
be
this
colon.
B
B
Since
you
are
a
new
user,
and
this
is
a
fresh
cluster,
you
installed
it
on
you
should
you
will
be
treated
with
a
project
creation
onboarding
step,
so
you
need
to
confirm
your
password
if
you
have,
if
you
want
to
create
a
new
password
at
the
time
of
the
first
login,
I'm
just
going
to
keep
it
the
same,
and
my
project
name
would
be
demo.
So
this
is
only
a
one-time
thing
for
new
users.
B
So
if
you
create
another
user
as
an
admin,
they
would
have
to
go
through
this
onboarding
process
just
once
so
this
is
my
control
plane,
the
litmus
control
plane
that
I
have,
and
there
are
multiple
options
that
you
can
do.
You
can
schedule
a
workflow.
You
have
particularly
one
agent
right
now.
You
can
see
your
project
up
at
the
top.
You
can
see
your
details
if
you
have
set
up
an
email
which
you
want.
B
If
you
have,
if
you're
a
first
time
login,
you
have
to
set
it
up
manually,
so
you
can
set
up
your
email,
you
can
log
out,
you
can
edit
your
profile
and
you'll
see
all
the
project
related
details
like
who
is
sharing,
who
you
are
sharing
your
projects
with,
so
you
can
invite
other
people
as
well
into
your
project.
You
can
give
them
your
editor
owner,
different
types
of
access
and
there's
something
called
as
an
agent.
So
what
is
an
agent?
It
is
basically
when
you
install
litmus
by
default.
B
We
create
a
self
agent
which
is
already
running
in
your
particular
cluster.
So,
with
the
help
of
this
agent,
we
will
be
running
all
the
chaos
experiments
in
this
particular
agent.
So
if
you
want
to
create
an
so,
if
you
want
to
also
include
an
external
agent,
you
can
do
so.
You
can
connect
an
externalization
by
clicking
on
this.
You
have
to
go
through
this
process
to
download
it.
My
ctl
binary
and
connect
your
own
personal
external
agent.
B
So
we
are
going
to
use
the
self
agent
for
now
and
if
you
go
to
settings,
you
have
the
teaming
option
where
you
can
invite
new
team
members
who
are
already
a
part
of
litmus
and
then
you
can
choose
the
rule.
Like
I
mentioned
and
there's
another
section
called
as
a
workflow,
which
is
where
your
workflows
will
be
scheduled
whenever
whenever
you
should
use
the
workflow,
this
is
where
you'll
be
able
to
view
all
the
different
details
of
the
workflow.
B
If
you
create
a
schedule-
and
you
do
not
just
run
it
once,
if
you
want
it
to
be
a
scheduled
cron
job,
then
you
can
do
the
same
and
all
the
schedules
will
be
visible
here,
and
you
also
have
some
predefined
templates
that
you
can
use
to
directly
inject
yours
without
any
configuration.
So
you
can
just
use
this
predefined
templates.
B
So
what
you're
going
to
do
is
create
a
scheduler
workflow
on
the
particular
names
on
the
particular
agent
self
agent
that
we
have
already
now
moving
forward.
We
have
four
different
options,
which
is:
we
can
either
create
from
a
set
of
predefined
workflows,
which
is
the
same
as
the
templates,
and
let's
say
you
have
a
particular
pod
delete
or
a
certain
template
which
you
want
to
modify
and
extend
its
capabilities.
So
let's
say
you
have
quarter
lead
and
you
want
some
sort
of
specific
pod
delete
application
method
to
your
enterprise
requirements.
B
So
you
can
save
it.
You
can
modify
it
and
save
it
as
a
template
and
from
the
next
time
onwards
you
can
click
on
this,
create
a
new
workflow
by
cloning,
an
existing
workflow
and
see.
This
is
where
you'll
find
a
particular
template
that
you
have
saved.
So
you
can
use
that
template
and
run
your
workflows
again
and
again
with
the
same
configuration,
and
then
you
have
this
option
of
my
hub.
B
So
what
my
hub
is
essentially
like,
I
already
showed
you
there's
a
kiosk
hub,
so
my
hub
is
essentially
your
own
personal
chart,
your
own
personal
chart.
So
let's
say,
for
example,
I
have
this
demo
chart
here,
so
you
have
to
make
sure
that
this
is
exactly
in
this
particular
format.
So
you
have
to
have
a
charts
folder
and
inside
of
it
you
can
create
your
own
personal
chaos
experiment.
B
So
I
have
generic
experiments,
which
are
all
this
notetained
no
drain
disk
fill
this
clause
and
I
also
have
a
code
dns,
which
is
code
in
a
squad,
delete
experiment,
and
these
are
the
different
metadatas,
the
icons
and
the
back
html
experiment
yeah.
So
now,
if
I
go
to
the
portal-
and
I
select
the
hub
I'll
only
be
able
to
seek
yourself.
So
if
I
visit
this
here
sub
section,
I
should
be
able
to
see
chaos
up
only
which
is
exactly
if
I
view
this.
B
It
is
exactly
similar
to
this
hub,
so
we
already
have
this
inbuilt
with
the
litmus
portal.
So
whenever
you
open
portal,
you
should
already
have
hub
pre
like
already
there,
but
if
you
want
to
connect
your
own
hub,
you
can
choose
the
connect
new
hub
section,
I'll
name,
my
hub
as
demo
hub
and
I'll
just
give
my
get
url,
which
is
in
this
case
this
one.
So
I'll
just
use
this
get
url
and
I
just
want
the
mask
branch
to
be
mastered.
So
it's
public
repo.
So
I'm
using
it
as
public.
B
If
you
have
a
private
repo,
you
can
either
choose
to
ssh
or
use
the
access
token
and
just
add
the
deploy
key
in
your
get
repository.
That
should
work.
So
if
I
submit
it
now,
I
should
be
successfully
adding
the
demo
hub
to
my
list
of
qr
subs.
So
if
I
view
this
demo
hub
now,
I
should
be
able
to
see
all
the
generic
experiments
as
well
as
the
core
dns
experiment,
which
is
just
one
that
I
had
in
this
git
repo.
B
So
this
is
one
feature
that
allows
you
to
create
your
own
custom
charts.
If
you
want
to
and
then
use
your
enterprise
particular
enterprise
use
case,
so
you
can
create
your
own
experiments,
use
experiments
and
push
them
on
git
github
and
then
use
your
own
hubs
to
schedule.
Yours
according
to
your
needs.
So
now,
if
I
go
to
workflows
and
I
schedule
a
workflow-
and
I
select
my
demo
hub-
there's
also
an
option
to
import
a
workflow
from
yaml.
B
B
B
I
should
be
able
to
see
a
visualization
of
the
right
side,
which
is
giving
me
an
exact
example
of
what
would
happen
when
like
how
this
experiment
would
look
how
this
workflow
would
look
when
I
finalize
it-
and
I
see
the
visualization,
so
this
is
just
a
demo
visualization
of
a
predicted
visualization
that
it
should
happen
once
we
select
it.
So
you
can
of
course,
click
on
edit
ml
and
see
the
different
yaml
configuration
so
like
I
mentioned
chaos,
engine
chaos
experiments
at
the
top.
You
would
have
the
kiosk
experiments.
B
A
B
All
different
chaos,
experiments
and,
if
I
scroll
down,
I
should
be
able
to
see
the
chaos
kind
chaos
engine
and
these
are
the
chaos
engine
of
the
two
particular
experiments
that
I
just
installed
all
right.
So
if
and
there's
an
option
called
a
virtue,
so
reverse
schedule
actually
allows
you
to
revert
all
the
particular
chaos
that
has
been
happened.
If
you
turn
it
to
false,
it
will
not
reward
it
and
your
chaos
metadata
all
the
experiment,
details
job
details
will
be
persistent
and
will
be
present
there.
B
B
This
is
how
the
workflow
details
would
look
like.
This
is
the
current
step
that
is
running.
It
will
install
all
the
chaos
experiments.
It
will
spawn
up
the
port,
lead
and
container
kill
experiment,
and
once
we
click
on
the
particular
node,
it
will
also
give
us
the
cures
results
as
well
as
the
logs.
So
let's
this
is
the
master
node.
So
that's
why
we
are
getting
a
total,
an
entire
overview.
So
this
is
just
a
graph
view.
B
So
these
are
the
same
things
that
I
talked
about
when
I
was
discussing
the
crds,
and
this
is
the
experiment
that
we
just
the
kiosk
experiment
that
we
just
created
so
demo.
This
one
is
running
and
since
it
has
installed
the
different
experiments,
it
will
create
more
two,
two
more
experiments
which
are
port,
delete
and
chaos
container,
kill,
and
that
would
be
working
on
this
particular
target
that
we
have
so
current
target
is
nginx
application,
which
is
already
inbuilt.
B
So,
let's
just
wait
for
this
experiment
to
finish
so
now
that
the
install
experiment
finished,
we
have
a
container
kill
that
is
in
the
pending
state.
So
if
I
visit
the
logs
again,
I
should
be.
If
I
visit
the
watch
statement
again,
I
should
be
able
to
see
the
another
instance
pop-up,
which
is
called
an
initializing
state,
and
this
is
the
container
kill
chaos,
experiment
that
is
trying
to
install
itself
and
inject
geos.
B
B
So
now,
if
I,
if
I
visit
the
container,
if
I
visit
the
container,
kill
node,
I
should
be
able
to
see
the
logs
as
well
as
the
chaos
results
as
well.
So
right
now,
it's
running!
That's
why
we
don't
have
any
kiosk
results
once
it
finishes,
we'll
be
able
to
see
the
case
results
so
yeah.
That's
that's
it
for
the
portal,
how
you
can
inject
your
personal,
your
own
chaos.
If
I
also
go
ahead
and
change
my
charts
detail
in
this
section,
let's
say
generic
port
delete.
B
If
I
modify
the
body
lead
experiment
here
and
I
come
back
to
this
scheduling
a
workflow
and
viewing
that
particular
experiment.
I
should
be
able
to
also
see
the
changes
there,
so
whatever
change
you
do
in
github
would
also
be
reflecting
your
workflow
itself
and
yeah.
That's
that's
all
about
litmus
and
how
you
can
leverage
it
in
a
high
level
view.
So
this
is
the
exact
architecture
that
I
talked
about.
So
you
have
the
portal.
B
You
have
your
chaos,
workflows
and
the
metrics
and
events
and
the
operators
and
the
different
experiments
that
are
running
so
these
are
all
exported
into
chaos
results.
So
the
case
results.
You
can
also
monitor
the
chaos
results
using
prometheus
with
the
kiosk
interleaved
analytics.
Also,
you
can
run
this
on
a
bare
metal
environment
as
well
as
public
clouds,
aws,
azure
or
vmware
with
the
bare
metal
environment.