►
From YouTube: Getting Started with the Spinnaker Operator and Amazon EKS - Fernando Freire & Praseeda Sathaye
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
Getting Started with the Spinnaker Operator and Amazon EKS - Fernando Freire, Armory & Praseeda Sathaye, AWS
Spinnaker is a cloud-native continuous delivery platform that provides fast, safe, and repeatable deployments for every enterprise. Learn from practitioners at AWS and Armory about how to get started with the Spinnaker Operator on Amazon EKS. We’ll take you through the journey of setting up a fresh EKS cluster, installing the Operator, and using Kustomize with Git to create a GitOps workflow to manage the lifecycle of your cluster. We’ll also cover basic deployment patterns in Spinnaker so you can quickly onboard teams in your organization. Join us and learn how to accelerate your organizations’ delivery velocity today!
A
A
We'll
also
show
you
a
little
bit
about
your
first
deployment
Pipeline
and
where
you
can
go
from
there,
so
who's
going
to
be
guiding
you
through
this
today,
I'm
Fernando
I'll
be
one
half
of
the
presentation
today,
I'm
a
software
engineer
at
Armory,
I'm,
just
delivering
product
Innovation,
I,
guess
in
the
in
the
open
source,
space
and
I'm
joined
here
by
my
partner
proceda.
Thank.
A
So,
to
lay
the
foundation
for
what
we're
going
to
be
talking
about
the
rest
of
the
day,
we're
going
to
start
real
simple,
so
we're
going
to
talk
about
the
difference
between
CI
and
CD.
Continuous
integration
are
coming
from
platforms
that
you're
very
familiar
with
at
this
point:
Jenkins
GitHub
actions,
Circle
CI,
all
these
tools
right
and
they're,
really
responsible
for
getting
you
to
the
point
where
you
have
a
Deployable
artifact.
A
But
what
happens
once
you
have
that
artifact
there's
likely
a
whole
bunch
of
constraints
that
you
have
to
work
with
when
you're
sending
that
artifact
into
an
environment
where
you're
going
to
get
consumer
level
traffic
right?
So
let's
say
you
have
a
microservice
that
you've
been
developing
for
some
time.
You
want
to
send
it
to
a
production
environment.
What
do
you
do
with
that
Docker
container
or
that
jar
file?
A
That's
where
Spinnaker's
sweet
spot
is
so
Spinnaker
gives
you
the
ability
to
describe
imperatively
all
the
things
that
you
need
to
do
in
order
to
ship
that
artifact
to
somewhere,
where
your
users
can
actually
access
it.
So
we're
not
going
to
go
through
this
whole
diagram
just
at
once.
We're
actually
going
to
go
piece
by
piece,
so
we're
going
to
talk
about
the
first
element
today.
How
do
you
actually
get
a
Spinnaker
cluster
running
we're
going
to
use
something
called
the
Spinnaker
operator,
which
is
this
open
source
kubernetes
operator?
That's
going
to
help!
A
Now
your
users
when
they
actually
get
into
Spinnaker,
and
they
want
to
start
doing
deployments
they're
going
to
want
to
pull
artifacts
from
a
number
of
different
sources.
So
Spinnaker
gives
you
the
ability
to
Define
artifacts
in
GitHub
in
ECR,
elastic
container
registry
and
whole
Bevy
of
other
tools,
but
today
we're
going
to
focus
on
these
two
and
then
once
you've
got
those
artifacts
that
you're
ready
to
deploy
with
we
build
pipelines
which
are
composed
of
stages
which
are
composed
of
tasks
that
allow
you
to
take
that
artifact
and
describe
a
deployment
to
that
environment.
A
So,
for
example,
if
you
wanted
to
take
a
Docker
container
that
you
wanted
to
ship
into
a
kubernetes
cluster,
you
describe
a
build,
or
you
know,
pull
from
a
Docker
registry
or
from
a
Jenkins
build
that
Docker
container
bundle
it
up
with
your
kubernetes
manifest
and
then
apply
it
to
the
cluster.
And
then
maybe
you
want
to
add
a
little
bit
more.
On
top
of
that,
maybe
you
have
policy
constraints
within
your
environment.
You
want
to
make
sure
you're,
adding
labels.
A
You
want
to
make
sure
you're,
adding
or
you're
not
exposing
any
ports
that
you
shouldn't
be.
These
are
all
things
that
you
know
you
can
describe
as
a
part
of
a
Spinnaker
pipeline
and
then,
of
course,
you
can
also
deploy
to
a
number
of
other
targets.
So
that's
another
strength
of
spinnakers
where
you
can
not
only
deploy
to
a
kubernetes
cluster,
but
you
can
also
deploy
to
Amazon.
B
Thank
you.
So
you
know
everything
now
the
cool
things
what
we
discussed
about
the
Spinnaker
just
we
talked
about
so
let's
see
how
we
can
use
this
in
our
use
case
today
and
we'll
tie
everything
end
to
end
so
we'll
talk
about
the
Persona
based
delivery,
as
most
of
our
AWS
customer
follow
this
as
a
guiding
principle
for
continuous
integration
and
continuous
delivery
life
cycle.
Here.
What
you
see
is
the
platform
team
Persona.
B
They
are
the
admins
Central
team,
the
ones
who
put
guard
rails
to
empower
their
developers
in
the
organization
and
make
it
easy
for
the
application
development
team
to
onboard
new
application
or
release
application
faster,
and
this
team
will
be
responsible
for
the
setup
and
installation
of
all
the
tools
and
infrastructure
required
for
the
development
teams
to
work
and
very
easily
right.
So
for
our
use
case
here,
this
team
will
be
creating
the
eks
cluster
using
the
eks
blueprint.
B
I'll
talk
about
this
in
a
minute.
Next,
they
will
be
responsible
for
installing
the
Spinnaker
operator,
which
Fernando
already
went
through
and
Spinnaker,
as
you
all
know,
is
many
microservices
that
perform
different
functions
right,
so
we'll
be
using
customize
to
create
these
paneka
Services
here
so,
and
we
are
also
going
to
use
customized
patch
configuration
feature
for
integration
with
different
AWS
services.
For
example,
if
you
see,
on
the
left
hand
side,
we
will
configure
S3
to
purchase
the
metadata
of
Spinnaker
applications
and
Pipeline,
and
then
we
will
be
configuring.
B
The
load
balancer
to
expose
the
Spinnaker
UI,
we'll
also
be
configuring.
The
Amazon
ECR
as
the
docker
registry
and
Fernando
will
go
through
all
this
configuration
during
the
demo,
so
I
want
to
quickly
highlight
about
Amazon
eks.
If
anyone
is
new
over
here,
basically,
it's
a
managed
kubernetes
service
at
AWS,
and
it
provides
the
flexibility
of
kubernetes
with
the
security
and
resiliency
of
being
a
AWS
managed
service.
Amazon
eks
is
fully
extreme
certified
and
conformant
kubernetes.
What
does
that
mean
for
customers
is
like
they
can
migrate,
their
self-managed
kubernetes
platform?
B
If
it
works
there,
they
don't
need
to
re-architect.
It
will
work
with
eks
and
Amazon
AWS
support
kubernetes
versions
longer
than
the
Upstream
Community,
to
give
the
customers
more
time
to
plan
and
roll
out
their
upgrades.
It
currently
supports
four
kubernetes
versions,
as
you
see
over
here,
it's
from
120
to
123.
B
in
a
nutshell,
goal
of
Amazon
eks
is
to
make
kubernetes
operation
very
simple
and
help
customers
run
kubernetes
in
trusted
and
secure
way,
and
if
you
are
interested
to
learn
about
Amazon
eks,
we
have
a
continuous
day
session
tomorrow
as
part
of
kubecon.
So
please
do
attend
that
if
you
are
over
there,
then
now
moving
on
to
the
eks
blueprint-
and
this
is
the
one
which
we
have
used
in
today's
demo-
to
create
the
eks
cluster.
This
was
released
like
few
months
back,
so
it's
brand
new.
That's
why
I
wanted
to
introduce
this.
B
This
is
basically
an
open
source
framework
that
allows
customers
to
configure
and
deploy
complete
eks
clusters
based
on
the
AWS
best
practices
and
recommendation.
So
what
do
you
mean
by
complete
eks
cluster
right?
It's
a
cluster
that
is
bootstrap
with
all
of
the
operational
software
and
add-ons
that
a
customer
will
need
in
order
to
run
their
workloads
at
the
end
of
the
day.
B
So
implementation
of
this
eks
blueprint
is
via
infrastructure
as
code
and
you
can
use
it
in
terraform
or
cdk.
For
today's
session
we
have
used
terraform
one.
It
has
a
wide
range
of
popular
open
source
integration,
as
pre-built
modules.
You
can
check
it
out.
We
have
Argo
CD,
we
have
other,
you
know
like
flux,
CD
and
all
those
modules
as
part
of
this,
which
customer
can
just
enable
to
use
it,
and
it's
fully
extensible
as
it's
implemented
as
infrastructure
as
core
right,
so
customer
can
take
it.
B
B
Okay.
So
earlier
we
talked
about
the
platform
Persona
right,
and
this
is
the
Persona
from
the
development
or
devops
team
perspective.
So
these
two
teams
can
be
the
same
or
can
be
different.
It's
based
on
your
organizational
size
or
based
on
their
requirement
business
functionality,
but
their
own
main
focus
is
to
develop
test,
build
and
deploy
the
application.
They
do
not
care
about
setup
or
tools
required
for
all
these
things
right.
B
They
are
developing
so
as
soon
as
they
push
the
code
changes
and
it
will
go
to
the
CI
continuous
integration
process
and
then
that
where
it
will
push
the
docker
image
to
the
Amazon
ECR
Amazon
ECR
is
AWS
manage
container
registry
and
as
soon
as
the
image
gets
landed
into
ECR,
it
will
trigger
the
Spinnaker
Pipeline,
and
this
artifact
is
going
to
get
used
in
the
entire
stage
over
here
and
we
are
going
to
use
the
the
this
image.
Artifact
will
be
based
on
the
test
deployment
spec
using
the
customize
overlay
for
Dev.
B
As
you
see
over
there,
it
will
pull
that
information
from
that
git
and
then
the
deployment
spec
will
be
used
to
deploy
the
application
to
eks
test
environment
and
we
have
an
approval
process.
We
have
set
it
over
here
for
the
manual
intervention
and
once
that
approval
is
done,
it
is
going
to
move
to
production
and
that's
what
we
are
going
to
show
you
in
part
of
our
demo,
which
is
the
coolest
part
of
this
session.
B
B
Okay,
as
I
mentioned
before,
we
are
going
to
use
the
eks
blueprint
and
if
you
see
like
this
is
the
blueprint
what
we
have
used
so
the
the
form
of
blueprint.
What
we
used
is
like
creating
a
new
VPC,
but
you
can
still
use
the
existing
VPC
blueprint
as
well
it's
available
here
so
once
you
clone
this
repository,
then
you
can
basically
do
terraform
in
it
and
then
you
can
Target
apply
to
create
the
VPC
eks
cluster
and
all
the
add-ons.
What
you
require
for
this?
A
So
once
we
have
an
eks
cluster
The
Next
Step
that
we
need
to
worry
about
is
how
do
we
actually
get
Spinnaker
running
in
our
environment,
so
we're
going
to
use
a
combination
of
customize
and
the
operator
today
to
get
to
that
point.
So,
if
you're
new
to
customize
there,
it
is
one
of
many
tools
within
the
ecosystem
that
can
be
used
to
manage
configuration
within
kubernetes.
A
couple
other
popular
ones
are
like
Helm
Captain,
not
maybe
not.
A
Captain
scaffold
is
the
one
that
I
was
thinking
of
and
they're
all
meant
to
manage
the
complexity
of
all
of
these
xaml
files
that
we're
shipping
over
to
kubernetes.
So
for
today,
we're
going
to
be
focusing
on
customize
and
customize.
A
strong
suit
is
less
on
providing
a
shrink,
wrapped
packaged
experience
for
installation
and
more
on
providing
you
the
ability
to
Define
very
precise
edits
within
a
yaml
document.
A
So
what
we
see
here
is
a
customized
manifest
if
you're
familiar
with
older
development
tools
like
make.
This
is
the
equivalent
of
like
a
make
file
right,
which
is
basically
describing
the
things
that
we
want
and
the
places
that
we
want
them
to
go.
So
we've
got
our
customization
here,
we're
going
to
specify
our
namespace
So
today
we're
going
to
be
installing
Spinnaker
in
the
Spinnaker
namespace,
and
then
we've
got
this
notion
of
components
here
now,
if
you
are
familiar
with
customize,
this
may
be
less
familiar
to
you.
A
So
we
have
a
core
component
which
gives
us
the
base
Spinnaker
service.
Crd
then,
on
the
next
line.
Here
we
have
our
default
kubernetes
Target.
So
this
is
going
to
create
a
service
account
inside
of
the
kubernetes
cluster,
where
we're
going
to
install
the
operator
and
Spinnaker
we're
going
to
be
able
to
define
a
persistence
layer
here
which
is
going
to
allow
us
to
store
our
application
and
pipeline
metadata
inside
of
S3
and
then
we're
going
to
Define
Docker
artifact,
which
is
going
to
allow
us
to
pull
images
from
an
ECR
registry.
A
So,
what's
really
neat
about
the
component
approach
is
that
allows
us
to
bundle
up
a
lot
of
this
configuration
in
a
way
that
abstracts
the
complexity
of
this
configuration
to
the
end
user?
So
if
you
are
a
platform
team
of
platform
teams
or
if
you're,
even
just
trying
to
share
a
lot
of
this
configuration
across
individuals
on
your
team,
you
don't
necessarily
need
them
to
understand.
Every
single
configuration
file.
That's
going
in.
A
You
can
kind
of
bundle
it
up
according
to
the
the
unit
that
you're
you're
trying
to
apply,
and
this
allows
us
to
easily
swap
out,
for
example,
if
we
wanted
to
go
to
an
in-cluster
persistence
layer
instead
of
S3,
we
can
easily
swap
the
components
here
and
then
do
a
migration
of
data
from
those
two
data
sources
out
of
band
here.
The
last
thing
I'll
mention
about
components,
is
that,
as
you
can
see
here,
it
allows
us
to
pull
from
a
git
repository.
A
So
if
you
want
to
share
configuration
across
clusters
a
common
configuration
of
class
clusters,
you
can
do
that
and
you
can
also
reference
like
you
see
here,
a
branch
on
that
repository,
so
you
don't
always
have
to
keep
something
in
the
same
repository
that
you
are
installing
in.
So
what
we're
going
to
do
is
we're
going
to
show
you
what
some
of
the
patches
are
inside.
You
know
not
inside
of
these
components,
so
the
simplest
one
that
we
could
possibly
show.
You
is
a
version
definition.
A
So
in
this
case
this
is
all
we
need
to
Define
in
order
to
change
the
version
inside
of
Spinnaker
service
definition.
So
here
we're
pulling
the
129
release
and
the
way
that
customize
knows
how
to
install
that
or
apply
that
to
the
rest
of
the
cluster
is
through
this
Patch's
strategic
merge
field.
So
this
is
going
to
allow
us
to
to
declare
hey.
This
is
a
snippet
of
config
that
I
want
and
I
want
you
to
add
it
into
this
base.
Definition
that
we've
defined
up
here.
A
The
next
thing
we'll
show
you
is
an
S3
bucket.
So
if
you
follow
that
eks
blueprint,
it's
going
to
have
you
create
a
service
account
for
front
50
to
actually
store
all
of
this
information
in
S3.
So
this
gives
us
the
ability
to
specify
the
service
account
that
we're
going
to
use
along
as
the
bucket
that
we
actually
want
to
store
data
in
then.
The
next
thing
that
we
want
to
look
at
is
our
git,
repo
and
ECR
patches,
because
they're
well,
the
ECR
patches
are
a
little
bit
more
complex.
A
So,
let's
quickly
look
at
git
repo
here,
we're
essentially
saying
I.
Want
you
to
go
to
GitHub
and
I.
Want
you
to
use
this
token
that
I've
stored
in
GitHub
and
be
able
to
or
allow
my
end
users
to
retrieve
information
from
git
repos
that
I
provide
access
for?
Within
that
token
and
then,
finally,
the
last
one
that
we
want
to
show.
A
You
is
the
ECR
registry,
because
this
one
looks
a
little
bit
different
than
the
other
customized
patches
that
we've
seen
so
in
certain
cases,
edits
become
difficult
within
customize,
and
so
they
provide
you
a
Json,
a
way
to
define
a
Json
path
in
a
value
that
you
want
to
replace.
So
you
can
get
even
finer
grained
with
the
changes
that
you
want
to
make.
A
So
in
this
case,
we're
making
an
edit
to
the
first
account
that
we've
defined
for
Docker
Registries
we're
going
to
be
pointing
to
an
ECR
registry,
and
then
we're
going
to
point
to
the
particular
images
that
we
want
to
pull
and
then
the
last
piece
that
is
really
neat
here.
If
you
are
new
to
the
Spinnaker
space,
is
the
ability
to
define
a
way
to
retrieve
credentials
for
pulling
those
Docker
images.
So
Amazon,
of
course,
provides
a
number
of
ways
for
you
to
access
resources
in
a
least
privileged
manner.
A
So
in
this
case,
because
we
are
using
a
private
registry,
we
need
to
tell
Spinnaker
how
to
pull
credentials
for
those
Docker
containers.
So
we
specify
the
command
here,
which
is
essentially
getting
an
authorization
token
and
formatting
it
a
little
bit
with
the
tools
that
are
on
the
container
to
be
able
to
get
that
token
and
authenticate
requests
to
ECR.
A
A
A
And
what
this
is
going
to
do
is
it's
going
to
download
the
manifests
into
my
local
environment
and
then
I'll
be
able
to
apply
them
after
we've
got
them
out,
and
while
this
is
downloading
I
guess
I'll
talk
a
little
bit
about
what
we're
going
to
do
once.
This
is
all
downloaded,
so
you're
going
to
get
a
bundle
of
custom
resource
definitions
and
manifests
that
operate
on
those
custom,
resource
definitions,
so
crds
or
custom
resource
definitions
are
a
way
for
you
to
extend
the
kubernetes
API.
A
What
the
operator
does
is
it
defines
that
Spinnaker
service
manifest
that
we've
just
been
looking
at
and
then
the
operator
itself
hooks
into
events
that
are
created
around
those
objects,
so
anytime
I
apply
a
Spinnaker
service
configuration.
The
operator
is
listening
to
events
recognizing
that
there's
a
change
and
then
it's
going
to
reconcile
that
change
inside
of
the
cluster
and
I'm,
not
sure
why
this
isn't
downloading
so,
luckily,
we've
got
it
all
locally
already,
so
we've
got
it
in
this.
Deploy
directory
and
I'll
quickly
show
you
what
that
looks
like.
A
You
know
values
just
like
we've
seen
with
our
ECR
registry
and
our
GitHub
repository,
and
then
the
operator
figures
out
how
to
stand
the
rest
of
it
up
and
what
it's
actually
going
to
do.
Is
it's
going
to
take
that
configuration
that
declarative
configuration
and
then
split
it
into
configuration
files
and
deployments
for
all
of
the
services
inside
of
the
Spinnaker
ecosystem?
So
I'll
quickly
show
you
what
that
looks
like
here
and
then
we'll
talk
through
what
what
it's
doing
behind
the
scenes.
A
Okay,
so,
as
we
can
see
here,
we've
got
all
of
our
Spinnaker
Services
running
and
what
the
operator
has
done
behind
the
scenes,
assuming
we
had
just
applied.
All
of
our
configuration
here
is
that
the,
for
example,
the
GitHub
configuration
for
example
that
was
turned
into
settings
that
cloud
driver
understands
it,
creates
a
config
map
and
then
or
a
secret
in
this
case
and
loads
it
into
that
cloud
driver
pod.
A
So
these
are
all
things
that
you
can
configure
on
your
own
or
you
kind
of
let
the
operator
do
it
for
you
and
then
it's
going
to
do
that
for
each
and
every
service
on
on
down,
and
there
are
some
more
complex
configurations
that
you
can
Define
that
will
generate
configuration
for
multiple
services
and
in
that
case,
instead
of
you
having
to
manually,
remember,
hey
I
need
to
go
restart
these
end
Services.
The
operator
is
going
to
recognize
when
that
change
needs
to
happen,
and
it's
going
to
restart
those
services
on
your
behalf.
A
So
what
we've
ended
up
doing
is
once
we've
applied
this
service
we've
actually
defined
it
with
a
load
bouncer.
So
we've
got
it
up
over
here
and
I'm
going
to
make
this
a
little
bit
larger
and
then
we're
going
to
move
into
our
application
demo
here
so
I
will
hand
it
off
to
proceda
to
guide
us
through
the
application.
B
Yeah,
so
in
the
interest
of
time
we
have
already
created
the
pipeline
over
here,
which
you
see
Spinnaker,
Summit,
2022
and
we'll
see
what
all
stages
we
have
created
in
those
in
the
pipeline.
So,
as
I
showed
in
the
diagram
we
have
configuration
which
basically
pulls
the
information
from
the
ECR.
What
we
have
set
up
before
and
then
in
the
next
stage,
bake
test
manifest.
We
are
looking
to
the
GitHub
repo
for
our
application
and
we
are
looking
at
the
overlay
test,
customization
yaml,
because
we
are
deploying
it
to
the
test
environment.
B
So
everything
is
handled
via
customize
here
and
next
going
to
the
deploy.
It
will
use
the
Manifest
whatever
is
there
and
it
will
deploy,
and
we
have
added
again
the
next
stage,
which
is
in
first
someone
showed
before,
like
we
need
stakeholders
to
actually
decide
on
whether
it
can
move
to
production.
So
we
did
add
that
and
then
similarly
like
for
the
big
production
manifest,
it
is
going
to
look
at
the
overlay
production,
customization
yaml,
to
deploy
those
to
the
production
environment.
B
B
So
now
this
is
just
a
manual
thing
we
have
shown,
but
now
we
are
going
to
show
it
in
the
real
world
scenario
where
we
will
have
like
continuous
integration
process
via
Jenkins,
and
then
it's
going
to
do
the
build
testing
and
everything
and
make
sure
that
it
has
the
image
pushed
to
the
HCR
repository.
So
that's
what
it
is
doing
over
here
and
now
this
as
soon
as
it
lands
in
the
ECR.
You
should
see
the
build
triggered
over
here.
The
pipeline
should
get
triggered
and.
B
B
B
Okay,
and
if
you
are
interested
and
excited
about
this,
please
feel
free
to
look
at
this
information
over
here.
The
first
link
actually
points
to
ek's
blueprint
that
we
have
used
for
today's
demo,
so
you
can
contribute
as
well.
If
you
want
to
contribute
any,
you
know
modules
into
it.
It's
based
on
both
terraform
and
cdk.
This
link
is
for
terraform
and
the
second
one
is
the
ecase
workshop
that
I
publish
for
our
AWS
customers
to
get
started
on
if
it
has
like
all
the
basic
features
of
vks.
B
So
it's
it's.
It
really
works
for
the
immersion
days
for
the
customers
and
the
third
one
is
the
eks
best
practice
when
you're
really
starting
with
eks.
This
is
the
right
place
to
go,
because
it
has
a
different
modules
based
on
security,
networking
and
reliability,
where
you
can
check
like
how
to
get
started
started
with
the
eks
cluster.
A
And
then,
finally,
if
you're
curious
about
the
resources
that
we
use
today
in
this
Workshop
they're
published
in
this
repository
as
well,
we'll
go
ahead
and
get
the
slides
published
on
sketch
as
well.
If
you
want
to
go,
look
at
that
or
take
a
picture
of
the
screen.
The
other
repository
that
we'll
highlight
here
is
these
customized
patches
repo.
So
this
is
a
set
of
components
that
we've
been
building
out,
that
manage
a
number
of
common
configuration
use
cases
when
you're
trying
to
get
Spinnaker
up
and
running,
and
lastly,
we'd
love
it.
A
If
you
were
inspired
today
by
this
talk
or
any
of
the
talks
that
you've
seen
today
to
start
contributing
to
the
Spinnaker
Community,
we
link
to
the
community
Pages
here,
there's
a
number
of
ways
to
get
involved.
If
you
weren't
in
the
TOC
this
morning,
it's
as
simple
as
filing
an
issue,
it's
as
simple
as
joining
slack,
the
barrier
is
low
to
get
started
and
we'd
love
to
help.
You
contribute
more
to
the
project.
A
Is
the
question
is
the
installer
open
source?
The
answer
is
yes,
so
there's
a
Spinnaker
operator,
that's
open
source.
We
also
have
one
for
our
Armory
product,
but
that's
not
the
the
focus
of
today.
It's
really
the
open
source
Spinnaker
operator
and
those
customized
patches
are
open
source
as
well
for
you
to
use
yes.
A
Yeah
excellent
question
so
to
repeat
it
for
the
stream.
The
question
was:
are
there
other
benefits
to
the
operator?
Besides
just
restarting
services,
and
the
answer
is
yes,
so
the
operator
currently
manages
secrets
on
your
behalf,
so
you
can
store
secrets
in
S3.
You
can
storm
in
volts.
You
can
store
them
in
kubernetes
itself.
A
So
if
you
wanted
to,
for
example,
store
that
GitHub
token
as
a
Peak
secret
inside
of
the
cluster,
you
could
do
that
and
reference
like
a
special
string
inside
of
that
service,
config
and
it'll
get
resolved
before
the
application
is
actually
stood
up.
So
you
have
like
a
consistent
experience
depending
on
what
your
backing
Secret
store
is
to
Define
Secrets
within
the
cluster.
A
There's
also
a
few
other
things
that
it'll
do
like,
for
example,
it'll
help.
You
stand
up
the
load
balancers.
Of
course
it's
just
an
annotation
on
the
service,
but
if
you
have
more
complicated
setups,
then
it'll
try
and
do
some
some
smarts
there
to
help
you
out-
and
you
know,
there's
just
all
the
benefits
of
the
the
operator.
I
guess.
A
Pattern
within
kubernetes
are
patterns
that
your
benefits
that
you
would
get,
and
you
know
it's
something
that
we
want
to
continue
contributing
to
and
growing
in
terms
of
like
what
it
helps.
You
do
ultimately
right
like
I
can't
remember
how
long
ago
this
was,
but
one
of
the
ideas
behind
the
operator
pattern
was
to
encapsulate
as
much
human
operational
knowledge
inside
of
that
software.