►
From YouTube: Kubernetes Patterns - Roland Huß, Red Hat
Description
Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io. The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Kubernetes Patterns - Roland Huß, Red Hat
The way developers design, build, and run software has changed significantly with the evolution of microservices, containers and Kubernetes. This talk dives into common, reusable patterns and principles for designing and implementing cloud-native applications on Kubernetes. This talk focus on the most established patterns. It will revisit basic patterns like "Predictable Demands" or "Service Discovery" but also dive into prominent patterns "Sidecar", "Elastic Scale" or "Operator". Live demos back this presentation. This presentation is ideal for developers and architects who want to learn more about a pattern-based approach to implementing common Kubernetes usage scenarios.
https://sched.co/ZerV
A
And
welcome
to
this
talk
about
kubernetes
patterns,
my
name
is
roland
hills,
I'm
a
software
engineer
from
red
hat
and
currently
I'm
working
on
k
native,
which
is
a
serverless
platform
on
top
of
kubernetes.
All
the
patterns
I'm
going
to
show
you
today
are
described
in
this
book
that
I
have
written
together
with
my
friend
belgium.
You
can
get
a
free
copy
of
this
book
by
following
this
link.
This
copy
has
been
sponsored
by
red
hat.
A
A
A
in
this
book,
christopher
alexander
and
his
co-workers
are
describing
a
pattern
language
which
can
be
applied
on
the
field
of
architecture.
So
what
is
a
pattern
in
that
sense,
so
this
classical
pattern
always
has
a
name.
A
name
is
very
important,
because
patterns
form
a
kind
of
a
language
which
is
interconnected,
so
you
have
patterns
which
are
related
to
other
patterns
and
they
form
a
repeatable
solution
to
a
certain
set
of
problems.
So
it's
not
a
very
concrete
solution,
but
kind
of
a
solution.
A
The
gang
of
four
picked
up
that
idea
and
transformed
it
on
the
field
of
software
engineering.
So
this
was
a
very
famous
book.
I
guess
everybody
of
you
already
heard
about
it.
It's
design
patterns
for
object,
oriented
software,
and
it
contains
all
this
famous
pattern
that
we
all
know
and
love
like
a
singleton
like
a
factory
like
a
delegate
and
many
many
more
again.
This
pattern
has
a
certain
schema
they
are
described,
they
all
have
a
name
and
they
form
an
interconnected
kind
of
mini
language.
A
Okay,
kubernetes
the
other
part
of
this
presentation,
of
course,
cleveland's
patterns.
But
I
don't
talk
much
about
kubernetes
here,
because
I
assume
you
already
know
quite
a
bit
of
kubernetes.
Otherwise
you
wouldn't
join
the
keep
con,
but
just
for
very
super
brief
recap.
So
the
main
ingredient
for
kubernetes
is
the
pot.
It's
the
atom
of
kubernetes
and
the
pot
is
kind
of
abstraction
over
the
containers
and
there
are
really
describe
the
runtime
contract
for
a
container
so
how
containers
can
run
within
the
project.
A
A
Then
your
code
live
lives
in
such
a
port
and
is
executed
in
the
port
and
around
that
you
have
tons
of
other
entities
which
allows
you
to
to
declare
how
the
application
is
supposed
to
be
running,
and
you
see
here
a
whole
bunch
of
them,
and
this
is
important
that
you
always
declare
what
you
want
to
have.
You
do
not
tell
communities
do
that
and
that
and
that
step
by
step,
but
you
declare
what
kind
of
a
target
state
we
come
to
this
concept
in
a
little
bit
later.
A
So
now,
let's
dive
into
the
patterns,
so
we
have
different
pattern
categories,
so
we
organized
the
24
patterns
in
different
categories.
One
of
them
are
the
foundational
patterns.
These
are
more
or
less
the
intrinsic
features
of
kubernetes.
The
reason
for
that
is
that
kubernetes
itself,
as
a
platform,
is
the
implementation
of
certain
patterns
for
distributed
computing,
and
we
really
find
some
core
concept
in
the
foundational
category.
A
On
top
of
that,
we
have
structural
patterns
which
really
take
kind
of
the
foundational
primitives
and
combine
them
into
something
new
on
top
of
that
or
a
little
bit,
not
really
on
top
of
that.
But
a
little
bit
on
this
side
are
the
configuration
patterns,
which
is
all
about
how
you
can
configure
applications.
A
A
A
A
So
we
have
a
core
entity
in
kubernetes,
which
is
called
the
deployment,
and
this
is
really
all
about
declarative,
rather
imperative
deployments
before
the
deployment
and
the
resource
was
introduced
into
qranius.
All
you
could
do
was
kind
of
a
imperative
deployment
with
a
client
application,
so
cube
control
which
allows
you
to
do
certain
things
like
rolling
updates.
A
So
in
the
relative
deployment,
you
really
say
step
by
step.
What
should
be
done
for
rolling
up
that?
Which
means
that
you
have
a
set
of
new
copies
of
your
set
of
old
copies
of
your
application,
a
set
of
new
copies
and
how
you
can
really
scale
the
old
ones
down
and
scale
up
the
old,
the
new
ones,
and
this
is
done
step
by
step
as
mentioned,
however,
with
deployment
we
introduced,
this
has
been
a
declarative
way
how
you
can
declare
your
deployment
strategy
by
just
saying.
A
Okay,
I
want
to
have
a
rolling
update.
I
want
to
have.
This
is
my
new
image,
and
now
you
please
do
this.
For
me,
deployment
kubernetes
resource
holds
the
template
report
so
that
the
deployment
can
create
new
ports
for
you.
It
creates
replica
sets
on
the
fly,
so
it's
kind
of
a
manager
for
your
replica
sets.
So
we
will
see
this
in
a
second.
It
allows
also
for
rollbacks
to
an
older
version.
If
you
do
an
update
and
two
several
update
strategies
are
declared
within
your
deployment.
Descriptor.
A
Here
we
see
now.
The
different
types
of
declarative
deployments
are
one
of
the
role
deployment,
which
is
just
about
how
you
can
create
a
zero
downtime
upgrade.
So
you
in
this
example,
you
have
a
version
1
0,
which
is
your
old
versions.
You
have
three
copies
running
in
a
replica
set
there,
which
is
managed
by
a
deployment.
A
Of
course,
this
kind
of
deployment
doesn't
work.
Does
it
always
work,
so
your
application
really
needs
to
be
tailored
for
being
able
to
being
upgraded
within
a
rolling
deployment.
For
example,
your
back
end
state,
like
our
database,
need
to
be
able
to
run
with
both
versions,
so
version
1.0
and
1.1,
so
for,
if
you
have
a
schema
upgrade
between
those
versions,
you
have
to
do
this
very
carefully
so
that
your
database
schema
really
can
support
both
versions.
A
The
next
one
would
be
a
fixed
deployment.
This
is
a
little
bit
easier
for
from
the.
So
it's
a
bit
easier
from
our
implementation
side.
It's
because
all
your
old
versions
are
scaled
down
to
zero.
Immediately
at
once,
and
as
soon
as
they
are
down,
then
your
new
ones
gets
be,
get
been
scaled
up.
So
then
you
have
a
kind
of
a
little
bit
of
a
time
gap
between
those
versions
so
down
time
and
the
service
actually
really
switched
over
to
the
new
one.
After
that,
then
there
are
variation
of
both
of
those
deployments.
A
So
these
two
deployments,
like
fixed
deployment
and
a
rolling
update
deployment,
are
really
supported
directly
by
kubernetes
via
the
deployment
resource.
But
if
you
want
to
have
some
more
sophisticated
deployment
strategies,
then
you
can
do
that
as
well,
but
then
you
have
to
do
it
manually
by
managing
multiple
deployments
or
you
use
a
platform
like
k
native,
which
also
supports
which
is
kind
of
a
has
a
concept
of
a
service
creative
service,
which
is
a
simplification
of
a
deployment
which
also
allows
you
to
create
these
these
strategies.
A
I'm
going
to
show
you
now
we
are
so
called
traffic
splitting
so
for
a
release.
You
still
have
you
have
your
old
version,
1.
1.0
covered
by
one
deployment.
You
create
a
new
deployment
with
a
new
reference
to
1.1,
and
so
you
have
both
versions
running
at
the
same
time.
However,
this
also
the
service
always
look
still
points
only
to
the
old
version.
A
A
Another
variation
of
the
rolling
update
is
the
canary
release
where
you
say
you
make
a
rolling
update,
but
you
stop
in
the
middle.
So
in
this
case
you
just
maybe
you
have
three
replicas
set
replicas
for
your
old
and
your
old
version,
but
then
you
scale
up
one
port
with
your
new
version
and
your
server
still
goes
to
both
of
them,
but
you
have
maybe
ninety
percent
of
your
traffic
then
goes
to
the
old
version,
but
only
ten
percent
of
the
new
one.
A
So
you
can
try
out
some
stuff
and
say:
okay,
I'm
it's
okay
for
me
that
you
can
scale
up
the
new
version,
make
it
a
full
rolling
deployment
or
you
say:
no,
that's
not
what
I
wanted
to
have.
Let's
go
back
to
the
old
version.
This
is
easily
done
again
using
k
native.
This
is
super
simple
to
do.
If
you
don't
use
k
native,
you
can
do
this
manually
as
well.
So
here's
a
nice
diagram
also
from
the
book
where
you
see
how
these
deployments
are
working
over
time.
A
So
on
the
x-axis,
you
have
the
time
on
the
y-axis.
You
have
the
number
of
instances
running.
The
blue.
One
is
the
old
version.
The
green
dotted
curve
is
the
new
version
for
auric
deployment.
You
have
a
gradual
degrees
of
the
old
version,
an
increase
of
the
newer
version,
fixed
deployment.
You
have
a
kind
of
a
little
gap
where
nothing
is
running
blue
green
release.
A
Is
you
have
a
certain
time
where
both
versions
are
running,
and
this
is
also
important
to
note
that
for
this
case,
you
need
twice
of
the
capacity
for
your
application,
which
means
your
cluster
must
be
large
enough,
that
your
application
can
run
in
two
copies
which
can
be
on
an
issue
or
maybe
not
for
canary
release,
use
the
kind
of
a
rolling
update
which
which
should
just
stop
in
the
middle.
Like
that
and
then
at
the
end,
you
can
decide
what
you
want
to
do.
Okay,
this
is
all
about
the
declarative
deployment.
A
This
is
all
about
runtime
collaboration
of
containers.
We
have
already
seen
in
one
of
the
slides
at
the
beginning
that
in
a
pot,
you
can
have
multiple
containers
in
these
pots.
These
containers
can
communicate
with
each
other
either
via
the
network,
so
we
are
localhost
in
a
certain
port
or,
if
set
up,
probably
with
a
shared
volume,
so
that
one
container
can
write
on
this
volume
and
the
other
one
can
read
it.
A
For
example,
it's
a
little
bit
similar
to
aop
in
the
programming
world,
where
you
have
also
this
aspect-oriented
programming
and
add
autonomous
concerns
to
your
application,
like
logging
or
security,
and
as
I
mentioned
it's
all
about
separation
of
concerns,
so
you
can
compose
your
stuff
and
and
all
the
in
this
example
for
here
you
see
that
the
main
container
is
an
http
server
which
serves
certain
data
from
a
disk
and
all
the
requests
that
come
in
just
serve
the
disk.
So
the
main
container,
just
this-
is
kind
of
a
static
http
server.
A
So
with
this
setup,
you
do
not
have
to
touch
the
http
server
at
all
and
can
add
a
new
functionality
like
updating
when
something
changes
directly
by
adding
a
sidecar
container.
This
is
a
good
example
how
you
can
really
enhance
your
application
with
without
really
touching
it,
and
one
of
the
most
prominent
examples
in
this
category
are
really
service
meshes,
which
actually
does
this
so
inject.
A
Some,
let's
have
a
quick
look
into
two
variations
or
specific
variations
of
the
site
container.
So,
first
of
all
the
adapter,
this
is
all
about
how
you
can
decouple
the
access
to
a
container
from
the
outside
world,
which
means
that
you
can
add
adapters
depending
on
the
needs
requirements
for
certain
systems.
Here.
In
this
example,
we
have
again
our
main
container
application.
Let's
assume
you
have
certain
metrics,
which
you
want
to
monitor.
A
Now
the
other
side
exposes
these
metrics
to
prometheus
in
the
prometheus
specific
format,
and
so
the
main
application
doesn't
know
anything
about
prompters,
but
you
can
still
connect
to
prometheus
for
monitoring,
and
if
you
change
your
monitoring
system,
like
let's
say
you
switch
to
nagios,
then
you
just
exchange
the
adapter,
and
still
your
application
does
not
need
anything
to
know
about
this.
This
is
about
how
you
expose
data
in
a
uniform
fashion
to
the
outside,
and
the
ambassador
is
kind
of
the
opposite.
A
A
A
This
is
also
a
pattern,
and
it's
here
it's
about
how
you
can
manage
large
and
complex
similar
configuration
data
similar
in
the
sense
that
you
might
have
deployment
scenarios
where
you
have
different
stages,
like
a
development
environment
like
a
staging
environment
like
a
production
environment,
and
all
of
this
has
kind
of
similar
configuration,
except
for
certain
connection
parameters,
for
example
like
a
database.
So
you
have
the
development
environment
needs
to
connect
to
the
development
database,
the
production
environment
to
the
production
database
and,
of
course,
you
can
copy
over
all
this
into
your
applications.
A
But
if
you
do
it
naively,
you
have
to
create
different
images.
Container
images
for
all
of
these
applications,
which
is
not
very
very
nice,
but
this
pattern
actually
tries
to
solve
this
problem
by
introducing
an
init
container
in
that
container
is
something
which
starts
before
your
main
container
starts,
and
let's
assume
this
in
the
container
contains
a
template.
Processor
you
have
in
your
image.
You
have
a
configuration
template,
which
means
all
the
shared
parts
are.
A
This
are
given
there,
but
you
have
placeholder
for
the
variables
like
the
database
connection
url
and
this
template
processor
then,
would
pick
up
all
these
configuration
parameters
from
a
config
map,
for
example,
and
then
puts
it
into
the
template.
Processor.
The
temple
processor
also
picks
up
the
template,
and
then
the
final
configuration
is
stored
in
the
shared
volume
and
what
the
main
containers
just
does.
It
picks
up
this
already
processed
configuration
data
and
serves
it
to
or
use
it
for
for
itself.
A
For
here,
a
good
example
could
be
jpos
or
whitefly,
which
is
in
java
e
application
server,
and
here
you
see
it's
a
graphically,
so
you
have
a
template.
Processor.
You
have
the
configuration
templates,
the
temperature
would
mount
your
config
map
as
a
volume
takes
the
templates
which
are
coming
directly
from
the
init
containers
image
processes.
It
creates
the
processed
images
into
the
configuration
file,
your
main
application
charts
just
mount
and
reads
the
configuration
and
of
course,
the
only
thing
you
have
to
change
for
different
environments
is
just
different.
A
Config
map
volumes
for
different
environments,
so
you
would
put
into
the
into
the
copic
map
only
those
parts
which
are
different
for
these
environments.
Here's
how
it
looks
like
in
the
resource
descriptor,
so
you
would
have
here
a
deployment,
and
you
see
the
inner
container
just
picks
up
a
kind
of
a
prepared
image
which
contains
the
templates.
A
A
First
of
all,
let's
have
a
quick
look
to
the
outside
to
the
non-kubernetes
world
and
how
service
discovery
works
there.
So,
typically,
you
have
a
producer,
so
this
is
the
one
who
offers
you
a
service.
The
producers
registers
its
service
in
the
service
registry
like
console,
for
example,
and
then
you
have
a
consumer
who
needs
to
do
an
active
lookup
to
the
registry.
A
For
example,
the
name
gets
back
a
reference
to
this
to
the
service
and
then
invokes
the
service
in
the
third
step.
Sometimes
there
are
hn
involved,
which
are
just
which
you
have
to
connect
to
your
services
with
kubernetes,
it's
a
little
bit
different,
because
the
service
register
is
really
part
of
qrs
itself.
It's
all
that
the
consumer
already
has
a
name
as
for
the
lookup,
and
this
lookup
happens
behind
the
scenes,
so
this
is
done
by
kind
of
a
proxy.
This
is
either
a
reproxy
or
kind
of
a
virtual
proxy,
and
you
can
imagine
this.
A
Is
this
the
kinetic
the
kubernetes
service
which
is
used
here,
and
so
in
that
sense
the
proxy
also
selects
the
ports
and
evoke
the
service
afterwards.
Now,
let's
have
a
look
into
the
different
kind
of
discoveries.
So,
first
of
all,
we
have
internal
services
covering
which
is
used
by
services
or
by
application
ports
which
are
running
within
the
cluster,
so
every
application
has
kind
of
dependencies
and
these
dependencies
can
be
either
within
the
cluster
or
outside
the
cluster.
A
If
they
are
within
the
cluster,
you
can
can
just
call
your
dependencies
via
a
kubernetes
service,
and
this
service
is
kind
of
a
mini
load
balancer
for
your
pots,
and
these
pots
are
selected
by
label
selectors.
You
can
have
multiple
service
purpose,
there's
also
kind.
You
can
configure
a
session
affinity
on
our
p
address
of
the
client
port
so
that
the
client
port
with
certain
appear
address,
always
lands
at
the
other.
Fixed
port
and
readiness
probes
are
really
used
to
indicate
that
the
service
is
ready.
A
A
If
you
have
to
access
services
outside
the
cluster.
So
like
an
external
system,
you
can
do
this
also
with
the
kubernetes
service.
But
in
this
case
you
don't
enter
a
label
selector
into
the
service,
but
just
either
create
so
called
an
endpoints
resource
which
has
a
list
of
ip
addresses
that
should
be
used,
and
this
endpoint
has
the
same
name
as
a
service.
A
So
in
this
case,
if
a
request
comes
from
a
port
to
this
service,
then
the
endpoints
are
consulted
and
then
just
delegated
to
the
external
system,
or
you
use
a
service
of
type
external
name
and
there
you
can
just
put
in
a
external
dns
name,
which
then
is
used
all
the
time
if
you
access
the
server.
So
this
service
is
then
kind
of
a
proxy
for
this
external
name.
A
A
The
simplest
one
to
configure
is
the
node
port,
you
just
add
a
type
notebook
to
your
service
and
then
every
node
in
your
cluster
exposes
this
port
to
the
outside
world
and
directs
you
to
this
service
and
the
service
again
just
delegates
to
the
ports
yeah.
The
benefit
is,
of
course,
it's
easy
to
configure
other
the
the
drawback
is
that,
if,
of
course,
you
need
to
know
that
the
port
is
available
for
for
you
to
expose,
so
you
have
to
manage
certain
port
ranges
for
your
services,
which
you
want
to
expose
on
your
cluster.
A
This
is
true
for
every
service
in
the
cluster
that
you
want
to
expose
over
the
node
port,
and
also
this
port
is
not
always
stable.
So
sometimes,
typically,
you
will
get
a
random
port.
You
can
also
pin
this
port,
of
course,
but
this
requires
tons
of
management
for
you
and
also
for
a
user
running,
for
example,
accessing
your
service
via
web
browser.
It's
not
easy.
It's
not
so
nice
to
to
have
to
specify
a
port
there.
Then
you
have
the
other
two
possibilities
to
use
a
load
balancer
or
an
ingress
for
load
balancer.
A
This
is
kind
of
from
service
offered
by
your
kubernetes
provider,
or
typically
also
a
cloud
provider,
and
this
is
different
from
provider
to
provider.
So
load
balancer
is
something
which
is
outside
of
the
cluster
image
out
of
the
cluster.
They
have
different
characteristics
also,
but
what
you
do
for
your
servers?
You
can
define
the
time
log
balancer,
and
then
you
have
a
kind
of
a
one-to-one
relationship
from
a
load.
Balancer
ip2,
your
service
there.
A
The
alternative
is
to
use
an
ingress
which
is
a
kind
of
an
own
resource
entity
which
is
managed
within
the
kubernetes
cluster.
You
have
ingress
controller
behind
that,
and
this
increased
controller
also
exposes
the
increase
to
the
outside.
You
can
also
dispatch
to
multiple
services.
This
is
not
not
so
easy
with
a
load.
Balancer
here
is
the
example
how
you
specified
ingress,
as
as
you
see
you
can
specify
different
context,
paths
which
is
nice
so
that
you
can
really
dispatch
to
different
services.
A
A
So
finally,
let's
have
a
look
into
the
advanced
petals
and
these
are
patterns
which
are
do
not
fit
really
well
in
the
other
categories,
but
they
are
described
more
advanced
concepts
like
elastic
scale,
which
is
about
horizontal
ports
and
vertical,
put
autoscaler
based
on
current
resource
usage
and
also
about
image
builder,
which
is
allows
you
to
create
container
images
within
a
cluster.
But
for
this
talk
we
I've
selected
the
controller
operator
which
are
very
important
concepts
of
kubernetes
itself.
A
Let's
start
with
the
controller,
the
controller
pattern
is
all
about
how
you
get
from
the
current
state
to
the
target
stack.
I
already
mentioned
that
kubernetes
is
all
about
state
reconsolidation,
which
means
that
that
you
declare
your
state
what
you
want
to
do,
and
it's
up
to
kubernetes
to
perform
certain
actions
to
get
to
this
state.
A
This
works
that
it
periodically
observes
the
actual
state
and
then
analyzes.
The
actual
state
makes
it
diff
against
the
target
state
that
you
have
declared
in
the
cluster
and,
if
there's
any
difference,
then
it
acts
on
in
that
form
that
it
tries
to
decrease
the
gap
between
the
actual
and
the
target
set.
And,
of
course,
ideally,
this
gap
gets
zero
so
that
it's
that
there's
no
difference
anymore
yeah.
So
this
is
how
kubernetes
works
itself.
There
are
tons
of
controllers
who
are
doing
exactly
this
kind
of
loop
all
the
time.
A
Technically,
it
works
that
it
connects
the
controller
connects
to
the
api
server.
The
control
controller
is
kind
of
in
regular
application
running
in
the
background
and
then
observe
the
api
server
that
this
is
by
observing
events
which
are
emitted
by
the
api
server.
If,
when
there
is
a
change
in
the
cluster
depending
on
these
events,
it
analyzes
whether
it
needs
to
act
or
not.
If
there
are
some
action
required
again
contacts
the
api
server
and
this
api
server
then
works
on
behalf
of
this
action.
A
A
A
What
you
see
here
is
kind
of
a
curl
which
watches
for
events,
so
it
creates
the
api
server
and
then
it
reads
the
event
for
every
event.
It
extracts
the
event
and
checks
whether
the
event
has
been
modified
and,
for
example,
it
watches
for
certain
config
maps
by
name
and
if
such
such
a
conflict
map
has
been
modified,
it
takes
an
action,
and
this
action
in
this
example,
which
is
also
part
of
the
books
example
which
you
can
download,
is
to
restart
a
port
which
has
a
certain
label
that
points
to
this
conflict
map.
A
Coming
now
to
our
last
pattern,
the
operator,
the
operator
is
all
about
how
you
can
encapsulate
operational
knowledge
into
an
executable
software.
It's
a
little
it's
a
little
bit
similar
to
the
controller
and
in
fact
it
is
based
on
the
controller.
So
here's
a
definition
of
what
this
an
operator
is.
So,
first
of
all,
we
have
this
very
nice
quote
from
jimmy
zielinski,
which
really,
I
think,
brings
it
to
the
point.
An
operator
is
a
community
controller,
so
it's
on
top
of
our
controller,
but
it
understands
two
domains.
A
One
is
the
kubernetes
domain
itself,
like
a
controller
does
but
also
something
else,
and
this
on
by
combining
this
knowledge
between
the
co
between
kubernetes
and
this
custom
domain
knowledge,
it
can
automate
tasks.
The
same
way
like
a
human
operator
would
do
when
it
would
have
to
operate
the
software.
A
It
knows
it
has
to
watch
the
config
map
with
the
name
web
app,
config
and
then,
as
soon
as
this
config
map
changes,
restart
all
ports
which
match
this
selector
here,
okay,
okay,
so
we
can
now
have
now
seen
controllers
and
operators
and
how
do
they
compare
to
each
other?
This
is
a
kind
of
also
kind
of
a
one
view
on
how
you
can
categorize
controllers
operators.
This
is
based
on
flexibility
and
complexity
of
this.
So,
for
example,
controllers,
which
is
a
more
simpler
concept
than
operators.
A
They
typically
operate
on
standard
resources
like
labels
or
also
on
config
maps
and
other
stuff.
You
can
configure
them
with
config
maps
as
well,
but
if
you
have
more,
if
you
have
a
higher
requirement
for
your
domain,
then
you
probably
move
on
to
operators
that
are
watching
custom
resource
definitions
or
if
you
want
it,
even
have
it
more
complex
and
more
flexible.
You
can
create
an
own
aggregate
api
which
hooks
directly
to
the
api
server
and
that
so
that
you
can
be
accessible
via
the
rest
api
directly
from
the
api
server.
A
Then
there
is
another
classification
which
you
can
put
on
custom
resource
definitions
themselves,
so
we
distinguish
between
installation,
crds
and
applications
here
these
installations.
Here
these
are
really
about
how
you
can
operate
an
application
like
prometheus,
like
kafka
cluster,
like
anything
about
which
you
want
to
run
in
your
kubernetes
cluster
and
how
you
and
this
installation
here
these
describe
the
installation
of
the
application
itself.
A
A
Yet
another
example
is
the
service
monitor,
which
is
there
for
registering
kubernetes
services
with
prometheus
so
that
as
soon
as
you
install
a
service
config
sorry
service
monitor,
then
your
promethos
server
will
monitor
the
service
which
is
referenced
within
the
service.
Monitor
other
example
could
be
a
kafka
topic,
which
is
also
available
if
you
use,
for
example,
the
sturenzio
stream
separator,
and
this
would
introduce
a
kafka
topic
in
your
kafka
cluster.
A
If
you
are
looking
for
operators
which
are
which
are
there
you
there,
the
operator
up
is
a
very
good
starting
point.
It
contains
a
catalog
of
available
operators.
It
contains
instructions
how
you
can
install
these
operators
in
your
cluster
and
this
catalog
is
constantly
growing.
So
I
really
recommend
to
go
to
operatedub.io.
A
If
you
want
to
create
your
own
operators,
you
have
tons
of
possibilities.
There
is.
You
can,
of
course
write
it
in
any
language,
but
there
are
some
frameworks
which
can
help
you
to
create
those.
The
most
famous
one
is
the
operator
sdk,
which
is
also
which
you
can
find
on
github,
and
this
allows
you
to
create
operators
in
the
golang
language.
A
So
this
is
all
what
I
have
for
you.
Thank
you
very
much.
I
hope
you
enjoyed
the
the
session.
You
have
seen
some
of
the
operators
you'll
find
more
in
the
book
that
you
can
download
and
yeah.
I
hope
and
show
you,
the
the
kubecon
and
hopefully
next
time
we
can
meet
us
in
person
again.
Thank
you
very
much.