►
From YouTube: Continuous Delivery Meets Custom Kubernetes Controller - Suneeta Mall & Simon Cochrane
Description
Want to view more sessions and keep the conversations going? Join us for KubeCon + CloudNativeCon North America in Seattle, December 11 - 13, 2018 (http://bit.ly/KCCNCNA18) or in Shanghai, November 14-15 (http://bit.ly/kccncchina18)
Continuous Delivery Meets Custom Kubernetes Controller: A Declarative Configuration Approach to CI/CD - Suneeta Mall & Simon Cochrane, Nearmap (Intermediate Skill Level)
Building and maintaining streamlined continuous integration and delivery (CI/CD) pipelines is often challenging. It is even harder on Kubernetes since the deployments are, rightfully so, safely guarded by the API Server of the cluster. Organizations tend to lockdown the API Server, restricting the ability to use an external CI tool. Using external CI tools thus comes at a cost of security, access, and ease-of-use. Nearmap dealt with these challenges using intrinsic Kubernetes principles. We use CircleCI, Amazon Web Service (AWS) Elastic Container Registry (ECR) and a custom Kubernetes controller to achieve a declarative configuration approach to continuous deployment. In this talk, we discuss the challenges faced, provide an in-depth analysis of our declarative CI/CD approach and how Nearmap is enabling self-managed continuous deployments of Kubernetes clusters.
About Suneeta
Suneeta Mall is a Senior Software Engineer at Nearmap – a leading provider of high resolution aerial imagery. She is leading the efforts of containerizing and migrating Nearmap services to Kubernetes (on Amazon Web Services) from Amazon’s Elastic Compute. In her 10 years of software industry experience, she has worked on solving variety of challenging technical and business problems in the field of DevOps, Tele-communication, travel, GIS, big data and machine learning. She has actively contributed to innovation portfolio of IBM (where she has worked before) and is also a Doctoral candidate at University of Sydney.
About Simon
Simon is a Director of Engineering at Nearmap specializing in providing high resolution aerial imagery over the web and embracing the Kubernetes world in order to efficiently run services in the cloud. Simon has inhabited the Sydney startup space for over 15 years building everything from social network apps to virtual ISP provisioning software.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! 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.
A
Good
morning,
distel
morning,
just
my
name
is
Simon,
and
this
is
Anita
and
we're
here
to
talk
about
continuous
delivery
on
kubernetes.
That's
a
much
simpler
title
than
the
official
one
up
there.
Quite
a
mouthful
I'm
not
going
to
try
to
pronounce
it
so
I'm
going
to
talk
about
the
journey
that
we
went
on
through
looking
at
all
the
different
options
in
continuous
delivery,
a
new
map.
A
What
worked
for
us
and
what
didn't
the
neatest
thing
going
to
talk
about
the
solution
that
we
ultimately
came
up
with,
which
we
have
since
open-source
so
as
you
might
be
able
to
tell
from
our
accents
a
lot
but
we're
from
Australia.
So
thanks
for
having
us
here-
and
this
is
a
picture
of
the
Sydney
Opera
House
for
you-
but
it
is
a
top-down
picture
of
the
Sydney
Opera
House,
because
we're
from
the
map,
we
do
high-definition
aerial
photography
from
aeroplanes.
A
A
Quba
Dinis
doesn't
really
help
us
with
this.
It
specifically
says
that
on
their
web
page-
and
it
says
that
CI
CD
workflows
are
determined
by
organization
cultures
preferences,
as
well
as
the
technical
requirements,
which
is
a
fancy
way
of
saying
that
there's
no
one-size-fits-all
solution
for
this
stuff.
That's
a
bit
of
a
shame,
because
it
is
pretty
easy
to
set
up
a
kubernetes
cluster
these
days,
but
setting
up
a
CD
pipeline
to
go
along
with
it.
We've
found
this
not
so
easy,
so
we
started
off
a
lot
like
most
people.
A
Probably
do
we
use
keep
control
to
deploy
our
pods
out.
We
define
a
container
in
a
configuration
file,
use
the
latest
tag
and
to
play
that
out
there
using
the
latest
tags,
not
such
a
great
idea.
We
found
that
so
we
started
parameterizing
our
configuration
files,
storing
version
numbers
inside
those
we
use
get
hashes
for
our
version
numbers
we're
talking
about
deploying
internally
here.
So
we
don't
need
the
overhead
of
semver,
but
we
have
to
manage
that
per
cluster
because
they're
all
running
different
versions-
and
this
is
all
very
manual.
A
A
People
have
been
doing
continuous
integration
for
quite
some
time,
doing,
builds
unit
tests
and
getting
those
feedback
loops
in
place,
but
the
right-hand
side,
the
actual
deployment
out
to
your
production
environments,
doing
verification
there.
It's
not
so
well
understood
and
that's
what
we're
going
to
focus
on
today.
A
lot
of
organizations
already
have
their
own
build
service
such
as
Jenkins.
There
are
plenty
of
other
good
ones
as
well,
so
here's
a
high-level
view
of
a
typical
CD
pipeline,
just
looking
at
all
the
main
actors
involved.
A
So
we
have
our
developers
pushing
code
to
a
git
repository
Jenkins
pulls
that
in
builds.
It
creates
a
container
image
pushes
that
out
to
a
container
registry.
Now
we
need
to
set
up
some
kind
of
workflow
in
Jenkins
in
order
to
do
the
deployment
and
it
can
do
that
using
queue
control
or
talking
directly
to
the
API
server.
A
We
need
to
set
some
access
controls
in
Jenkins,
but
that's
okay,
it's
part
of
our
infrastructure,
so
we
trust
it
so
does
the
deployment
and
then
our
clusters
ultimately
pulling
the
container
image
and
create
the
pods,
but
we
need
to
set
up
with
Jenkins
server
and
maintain
that.
So
what
we're
calling
these
managed
build
tools.
These
things
are
becoming
a
lot
more
popular
because
they're
just
so
easy
to
get
up
and
running.
We
use
circle
CI,
but
there
are
plenty
of
other,
really
good
ones
out
there.
A
So
to
get
up
and
running,
you
just
commit
some
configuration
to
your
git
repo.
You
link
your
repo
to
the
tool
and
you're
off
and
away
the
problem
here
now
is
that
when
you
want
to
set
up
the
similar
sort
of
workflows
to
do
a
cube
control
to
play
into
our
clusters,
we
need
to
expose
our
API
servers
or
the
control
plane
of
our
clusters,
essentially
to
the
world,
because
these
services
run
in
the
cloud.
We
also
need
to
store
those
access
credentials
in
these
third-party
services.
A
So
let's
look
at
some
other
options.
Now,
normally
I'd
run
through
these
in
a
bit
more
detail,
but
I,
don't
at
the
time
I'm
going
to
skim
through
them,
but
generally,
these
are
all
very
good
tools.
They
just
happen
to
focus
on
different
things
that
didn't
quite
fit
our
requirements,
but
I
will
stop
on
this
one,
because
this
is
quite
close
to
what
we
were
after,
if
we
flux
you
may
have
heard
of
it
here,
our
pipeline
is
building
container
images
pushing
those
to
the
container
registry.
A
Now
we
have
some
sort
of
config
updater,
that's
monitoring
their
container
registry
for
changes
and
when
it
detects
those
it
pushes
the
configuration
changes
out
to
a
git
repo,
which
is
a
configuration
stored
there
for
our
cluster
another
process
running
inside
the
cluster
of
the
player.
Then
the
text
layers
changes
out.
There
pulls
the
config
in
and
initiates
the
deployment.
So
let's
talk
a
little
bit
about
this
approach.
You've
probably
heard
it
as
well
as
been
mentioned
a
few
times.
This
get
ops
idea
and
there's
a
lot
of
advantages
to
using
git
ops.
A
You've
got
all
of
your
cluster
changes
in
config
history
in
history,
and
you
can
restore
your
cluster
to
any
point
in
time
that
our
experience
of
storing
version
numbers
specifically
in
source
control
is
that
it
is
very
noisy
and
it
tends
to
drown
out
the
rest
of
your
configuration
history,
which
is
arguably
a
lot
more
important,
so
we're
not
against
storing
configuration
in
source
control.
We
do
that.
A
We
store
a
very
simplified
single
version
of
our
application
configuration
alongside
the
source
code,
and
we
do
that
by
removing
all
the
cluster
specifics
from
it
by
using
things
like
kubernetes,
DNS
and
external
services.
Allow
you
to
do
that.
So,
if
you're
not
again
storing
your
configuration
in
source
control,
how
do
you
deal
with
things
like
version
number,
history
and
rollback
so
rollback?
First,
we
find
that,
if
we're
delivering
very
frequently
and
doing
small
updates,
that
rollback
is
something
that
we
very
rarely
need
to
do.
A
We
tend
to
roll
forward
when
there's
a
problem,
that's
gone
out
to
production
and
because
it's
a
small
change,
we
generally
know
what
what
the
issue
is
when
it's
gone
out
there.
So
we'll
cut
a
new
release,
push
it
through
our
CD
pipeline,
which
is
completely
automated
and
then
get
a
fix
out
into
production.
If
your
pipeline
is
manual
in
any
sort
of
way,
then
that's
going
to
be
a
lot
harder
to
do,
because
the
turnaround
time
is
not
so
great.
A
So
again
we're
not
saying
the
rollback
isn't
necessary.
We
just
don't
need
to
necessarily
optimize
for
that,
so
we
would
tend
to
rollback
by
cutting
a
new
release
on
an
older
commit
and
then
just
pushing
that
through
our
CD
pipeline
again,
because
it's
all
automated,
we
can
turn
around
that
very
quickly.
A
Finally,
the
history
history,
we
store
inside
the
cluster
itself,
the
version
history,
and
we
find
that
that's
okay,
the
main
problem
with
doing
that
approach
is,
if
you
did
happen
to
lose
that
information.
Somehow,
if
your
cluster
failed,
then,
if
you've
kind
of
lost
that
history,
but
we
store
all
of
our
our
master
branches,
represent
the
current
version
of
all
our
software.
So
it's
easy
to
restore.
A
So
none
of
these
tools
really
fitted
what
we
were
after
so
we
kind
of
went
back
to
basics
and
said:
okay,
how
can
we
create
a
really
simple
CD
pipeline
and
what
would
that
look
like?
So
first,
let's
define
some
goals
for
this
pipeline.
We
want
to
be
able
to
bring
our
own
integration
tool,
so
these
are
well
known,
solve
problems
right
people
have
been
doing
integration,
continuous
integration
for
some
time.
We
don't
want
to
have
to
use
any
additional
infrastructure,
so
we
already
have
our
build
build
server.
A
We
have
our
container
registry
and
we
have
our
kubernetes
cluster.
That
should
be
enough
for
us
to
build
a
pipeline.
We
want
to
utilize
existing
kubernetes
concepts
as
much
as
possible
right,
so
we're
invested
in
the
platform
we
want
to
make
whatever
use
of
that,
we
can
to
our
advantage,
and
we
want
to
focus
on
supporting
a
full
automation,
although
we
do
want
to
be
able
to
allow
manual
steps
where
needed,
but
we're
aiming
for
that
full
automation.
A
And
finally,
we
want
to
support
best
practices
in
the
industry,
so
we
want
our
environments
to
be
secure.
We've
all
wanna
be
able
to
do
verifications
as
we
do
our
deployments
through
things
like
Bluegreen
deployments.
We
want
to
be
able
to
solve
urgent
history
and
rollback,
and
we
want
good
visibility
into
what's
going
on
in
our
cluster.
So
we
want
to
be
able
to
see
what
versions
of
our
applications
are
running
when
rollouts
are
happening
and,
of
course,
when
failures
occur,
so
that
we
can
respond
to
them.
A
So
a
simple
pipeline
might
look
something
like
this.
So
again,
we're
building
container
images
we're
pushing
those
to
a
container
registry.
Our
cluster
is
pulling
in
the
images
as
well
in
order
to
create
pods.
The
difference
here
is
we're
now
pushing
version
information
directly
into
the
container
registry
and
we
have
a
service
running
inside
the
cluster.
That's
monitoring
the
container
registry
for
changes
and
initiating
deployments
when
it
detects
those,
and
because
this
is
a
service
running
there,
we
can
add
a
lot
more
smarts
to
it
as
well.
A
A
So
the
advantages
of
this
approach
is
that
we
don't
need
to
set
up
any
additional
resources.
In
particular,
we
don't
need
to
access
resources
such
as
our
cluster
needing
to
access
to
get
repo
this,
which
is
a
bit
of
a
problem
when
you're
dealing
with
private
repos.
We
don't
need
all
these
separate,
config
repos
around
right.
We
try
to
store
a
single
version
of
our
application,
configuration
alongside
the
source
code
and
then
that
met
also
matches
the
releases
as
they
go
out.
A
So
it's
a
simplified
configuration
and
this
whole
thing
is
easy
to
set
up
and
manage.
So
now
we're
going
to
talk
about
our
realization
of
this
simple
CD
pipeline.
So
tonight
it's
going
to
talk
about
that
and
remember:
we've
open-sourced
out
everything
that
she's
talking
about.
So
please
go
away
and
do
try
this
at
home.
Thank.
B
You
Simon
a
CD
pipeline
that
easily
integrates
into
your
existing
infrastructure
sounds
great,
isn't
it
and
what
would
be
a
better
way
to
implement
the
CD
solution
on
communities
infrastructure
then
use
intrinsic
communities
principle
and
leverage
on
its
strengths
non
right?
That's
exactly
what
we
thought
enter
the
world
of
container
version
manager.
It
does
exactly
that
it
is
build
using
communities,
extension
point,
custom,
resource
definition
and
custom
controller.
It
also
heavily
relies
on
communities
abstractions
such
as
deployment
config
maps
and
many
more
to
manage
and
maintain
the
components
of
CD
pipeline
thinking
about
it
more.
B
We
should
probably
rename
this
solution
that
we
are
calling
container
version
manager
to
cube
CD
or
even
K
CD,
but
we'll
think
about
that.
So,
let's
see
what
container
version
really
is.
It
defines
set
of
rules
for
managing
container
version.
What
you're,
looking
at
here
is
is
a
CV
spec
example,
CV
short
for
container
version,
and
what
that
declares
is
that
my
app
container
of
all
the
workload
that's
matching?
B
The
selection
criteria
should
always
be
from
image
repository
CVM
example,
and
that
it
should
be
running
a
container
version
tag,
demo,
environment
tag
and
that
this
state
is
at
max
allows
to
be
out
of
date
by
30
seconds
and
your
cluster
works
towards
achieving
that
state,
and
it
covers
all
the
workload
so
meaning
all
up.
We
won't
work
load
and
also
batch
workload,
including
cronin
jobs.
B
So
let's
look
at
what
makes
this
state
achievable.
There
are
three
components
as
a
part
of
the
solution
that
works
towards
achieving
that
state.
We
have
got
container
version
controller
container
registry
sinker
in
a
set
of
command
lines
tool
for
you
to
easily
integrate
it
into
your
existing
CR
infrastructure,
and
this
is
the
high-level
architecture
that
you
are
seeing.
Controller
on.
B
So,
let's
dive
more
into
all
these
components,
specifically
first
off
controller
controller,
reacts
to
any
changes
into
CV
resource
and
handle,
handle
them
appropriately
and
just
like
any
other
custom
controller
of
kubernetes.
It
uses
informal
factory
for
change
notification,
and
this
is
a
snippet
from
informer
Factory
handle
that
we
have-
and
this
would
probably
be
very
familiar
to
all
of
you
who
have
written
custom
controller
at
one
point,
but
this
just
to
illustrate
that
we
are
using
informal
factory
for
optimization
point
of
views.
B
The
controller
is
also
responsible
for
creating
and
updating
CR
sinkers,
and
it's
very
smart
in
a
way
that
it
deli
it
passes
the
onus
of
maintaining
the
sinkers
to
kubernetes
by
creating
a
deployment
for
it.
As
you
can
see
here,
I'll
add
it
in
the
section.
It
also
keeps
the
owner
references
to
the
CV
resource,
thereby
letting
kubernetes
manage
these
thinkers
but
CV
resource.
B
So
to
illustrate
more
if
a
CV
resource
is
deleted,
communities
will
implicitly
drop
these
thinkers
and
now
little
things
like
that
is:
what's
making
these
solution
more
native
to
kubernetes
and
and
letting
it
manage
itself,
and
it
that's
not
it.
It
also
provides
visibility
on
the
version
status
or
at
your
cluster
level.
That
is,
you
can
come
in
and
interrogate
for.
The
versions
of
your
resources
that
you
are
running
in
your
cluster
and
controller
would
be
able
to
provide
more
detailed
information
on
that.
B
Sinkers
they
are
responsible
to
ensure
that
the
container
state
has
declared
by
severe
source
is
always
met,
and
they
are
the
components
it
in
the
center
it
does
so
by
pulling
into
or
talking
to
container
registry
what
it
does
is
it
pulls
into
container
registry.
Looking
for
the
version
of
the
container,
that's
tagged
with
the
specified
tag,
and
once
it
finds
the
version,
it
compares
it
with
all
the
versions
that
matching
the
selector
expressions
and
any
discrepancy
in
this
version,
check
least
to
our
rollout
workflow.
B
So,
first
off,
you
would
like
to
validate
what
we
are
deploying
and
ensure
that
we
are
happy
with
it.
Validations
could
be,
validations
could
be
very
open-ended.
Some
of
you
would
like
to
verify
make
sure
that
there
isn't
any
code
regression
or
quality
checks,
things
like
smoke
tests
or
even
looking
at
container
vulnerability,
scans
or
verifying
the
signatures
of
the
container.
B
So
there
isn't
an
into
what
what
individual
or
organization
would
like
to
validate
the
image
on,
and
that's
why
we
have
hooks
for
validation
that
you
could
plug
in
and
in
a
successful
validation
would
lead
to
a
roll
out
operation.
So,
as
a
part
of
roll
out,
what
happens?
Is
we
the
part
spec
of
the
selected
work?
Workloads
are
patched.
We
use
strategic
merge
as
a
batch
strategy
to
allow
for
any
external
changes
into
parts.
B
Back
external
changes
could
be
in
terms
of
replica
count
or
even
resources,
the
various
conflicts
that
could
be
changed,
but
it
shouldn't
modify
anything
else,
other
than
version
and
the
rollout
as
part
of
the
rule
out
the
Native
community
strategies
are
honored
because
the
sinkers
doesn't
perform
the
rollout
itself
but
passes
the
instruction
to
control
panel
of
the
cluster
which
performs
the
rollout
and,
as
a
result,
all
the
native
strategies
are
honored.
If
unspecified.
B
Obviously
default
is
assumed,
so
native
simple
rollout
strategies
are
are
noise,
but
what
about
when
we
talk
about
complex
roll
out
roll
out
like
canary
and
Bluegreen
deployments,
so
it's
possible
to
use
its
CV
manager
solution
to
realize
these
sort
of
deployment
strategies.
However,
in
some
cases
there
will
be,
there
may
be
a
manual
intervention
that
would
be
required.
We
are
actively
working
on
improving
that
and
we
will
look
at
these
a
bit
more
detail.
B
B
You
should
switch
around
from
your
DNS
records,
based
on
what
namespaces
in
production
and,
what's
on
the
test
and
using
similar
approach
can
be
used
to
realize
these
sort
of
deployment.
We
do,
however,
have
an
automated
solution
for
Bluegreen
deployments,
but
the
deployment
only
support
at
this
point
at
service
level.
So,
as
you
can
see
in
this
figure,
this
service
see
blue
the
blue
and
green
sea
services
using
green
and
blue
and
deployments.
All
you
have
to
do
is
opt
in
for
a
strategy
in
your
CVD
source
configuration
saying
that
just
blue
blue
green
strategy.
B
B
Successful
test
results
would
lead
to
flip
of
the
switch
where
your
test
service
will
not
become
live.
So
this
is
very
standard.
Bluegreen
deployment,
it
just
very
first
level
implementation
that
we
have
done
for
blue
green,
but
we
are
actively
working
on
the
so
mistakes
happens.
We
all
make
mistakes
and
they
are
interesting.
What
happens
when
failure
happens
when
a
when
a
rollout
fails?
Excuse
me
Oh,
we're
all
forward.
We
fix
our
issues
and
we
roll
forward.
That's
exactly
what
we
do
at
near
map
and
CV.
B
Manager
is
also
written
with
that
philosophy
in
mind.
However,
having
said
that,
it
is,
it
does
understood
that
roll
out
doesn't
like
roll
forward
doesn't
fit
all
the
use
cases.
So
optional.
Roll
back
is
also
supported,
wherein
you
could
opt
in
for
a
roll
back
and
if
a
roll
roll
out
fails,
then
it
would
roll
back
using
the
historical
version
information
that
it
has
available.
But,
more
importantly,
we
notify
for
a
fail
on
a
failed,
not
failed,
rollout.
B
We
notify
and
that
could
be
plugged
in
into
notification
in
any
of
your
notification,
engine
slack
or
pager
duty
or
any
any
of
the
system
that
you
use.
So
that's
handy
too,
to
come
in
and
manually
intervene
should
should
the
need
be
so
just
want
to
summarize
on
sinkers.
These
are
the
components
sitting
in
in
in
the
middle.
B
There
would
be
as
many
thinkers
a
husband
know
for
as
many
see
video
sources,
you
have
the
interface
with
the
container
registry
and
talk
to
API
server,
and
by
doing
that,
they
implicitly
manage
all
you
workloads,
CI
twos.
These
are
the
commands
shown
on
the
right.
They
they
just
set
up
a
Dockers
command
line
that
you
plug
in
into
your
bash
script
of
your
choice
of
Co
infrastructure
and
it's
as
simple
as
just
calling
CV
manager,
CR
tags,
add
and
details
of
your
image
manifest.
B
So
a
simple
pluggable
CD
pipeline
should
be
low
maintenance
and
easy
to
install
right.
We
have
got
it
down
to
the--
simple
one-step,
install
only
which
is
just
about
installing
CV
manager,
defining
your
CV
resources
for
all
the
workloads
and
integrating
into
your
existing
CI
pipeline.
From
this
point
onward,
the
this
the
components
of
this
pipeline
works
towards
achieving
the
cluster
itself
work
towards
achieving
this
declared
state
itself,
and
they
also
manage
and
maintain
themselves
so
periodically.
B
B
So
there
are
several
other
benefits
to
using
this.
It's
obviously
self
managed,
as
we
talked
about
and
low
maintenance.
This
approach
allows
for
a
clear
separation
of
concerns
at
all
level.
The
cluster
again
is
responsible
for
managing
the
updates
or
deployments,
and
even
the
components
of
CD
pipeline
are
clearly
their
responsibility
is
clearly
defined
and
separated,
and
what
that
leads
to
us
is
leads
us
to
his
reduced
security
risk
and
allows
the
possibility
of
using
external.
We
provided
CI
CD
tool
where
you
don't
have
to
expose
your
control
panel
or
API
server
to
external
entities.
B
It's
completely
open
source.
We
welcome
feedback
in
contribution.
It's
a
very
native
solution,
as
I
touched
upon
before
yeah
the
we
do
capture
monitoring,
we
do
monitor
the
CD
pipelines,
so
they
are
various
stats
available
and
it
provides
more
visibility
into
what's
happening
on
your
cluster
in
terms
of
coercion
updates.
B
So
how
do
you
maintain
versions
of
your
service
to
you?
Do
you
have
a
single
point
of
contact
where
you
come
in
and
ask
for
the
current
version
of
all
your
services
or
or
even
look
at
the
historical
records?
Or
do
you
manage
it
externally?
It
varies
organization
to
organization,
but
at
near
map.
We
think
it's
the
responsibility
of
the
cluster
to
maintain
that
information
and
tell
us,
as
in
what
version
it
is
currently
running,
and
what
are
the
previous
versions
that
it
has
run
before.
B
So
that's
why
controller
or
CV
Manager
exposes
several
rest
interfaces
to
explore
these
information.
These
are
couple
of
interfaces
that
we
have
that
allows
you
to
see
the
current
versions
of
your
cluster.
There
are
Jason
in
HTM
formats.
Html
is
primarily
provide
to
integrate
into
your
monitoring
system.
Should
you
have
one,
and,
as
mentioned
early,
it's
an
opt-in
feature
for
release
history
that
you
can
obtain.
It
uses
conflict
map
to
maintain
the
real
know,
the
previous
real
release,
history
and
this
information
is
exposed,
or
it's
just
interfaces
for
your
use.
B
We
also
capture
a
variety
of
starts,
including
successful
deployments
and
variety
of
failure,
failure,
deployment
attempts,
and
we
also
kept
our
sensor.
Several.
Even
notifications
and
service
check
from
all
these
components,
our
CD
pipelines
or
controller
sinkers,
and
what
that
all
leads
to
leads
us
to
is
this
beautiful
thing
called
V?
We
call
deployment
dashboard
that
keeps
reminding
us
how
frictionless
deployment
can
be
and
how
productive?
We
are,
but
we
couldn't
do
anything
about
the
friction
of
the
desk
chair.
Unfortunately,
so
you
might
wonder
if
this
approach
would
scale
to
demand
because
they
could.
B
If
you
are
running
thousands
of
services,
then
there
might
be
equal
in
number
of
sinkers.
That
would
run
in
your
cluster.
We
monitored
the
resource
utilization
of
these
paths
and
they
were
very
small.
This
approach
has
worked
really
well
for
us.
We
will
we
would
we
think
that
it
would
work
for
very
busy
clusters
as
well,
but
we
would
like
to
see
what
happens
when
you,
when
you
guys
try
and
see.
We
do
would
like
to
hear
definitely
we'd
like
to
hear
from
you
and
see
how
how
it
goes
so.
B
I
can't
finish
off
before
talking
about
the
best
practices
using
this
solution.
We
think
that
much
to
master
is
a
is
a
is
one
of
the
best
practice
that
should
be
used
when
using
CV
Manager,
because
it's
a
well
understood
trigger
and
keeps
your
master
branch
a
replica
of
your
release
and,
like
us,
should
you
use?
Should
you
keep
your
config
alongside
of
source
code?
That's
a
very
good
way
to
to
go
back
to
a
previous
version
if
at
all
that
that
need
arise
and
also
for
it
for
your
reference
as
well.
B
If
you're
not
distributing
your
services
to
external
third
parties,
then
we
recommend
using
git,
because
a
more
readable
versions
like
somewhere
or
any
other
naming
schemes
are
very
parallel
to
get
versions.
The
only
benefit
they
provide
is
readability,
which
probably
is
not
that
relevant.
If
you
are
releasing
very
frequently
like
us,
we
do
recommend
using
dashboard.
B
Cv
Manager
is
completely
open
source
under
available
under
MIT
license.
The
instructions
to
get
you
started
is
available
on
the
blog
near
map.
Are
you?
Oh,
it's
probably
very
easy
to
find,
but
the
last
path
is
CVM
intro
and
we
also
have
a
sample
example
based
on
this
solution.
That
would
give
you
an
idea
of
the
kind
of
configuration
that's
required
and
there
is
a
video
to
get
you
started.
That's
also
attached
to
the
blog,
but
Simon
here
will
give
you
guys
a
quick,
rundown
and
demo
of
the
application.
Ok,.
A
Great
Thank,
You
Sameera,
so
we're
running
out
of
time,
so
I'm
gonna
try
and
do
a
very
quick
demo
here.
Just
to
show
you
how
easy
it
is
to
get
a
CD
pipeline
up
and
running
so
I've
gotten
a
simple
application
here:
communities
configuration
with
that
we've
got
a
deployments
here
and
we've
got
a
our
container
image
with
the
version
as
well.
We've
also
got
a
service
and
an
ingress
in
here
just
so
we
can
access
the
application.
A
So
if
we
look
at
kubernetes
what
that
looks
like
at
the
moment
we're
running
a
couple
of
pods
in
our
dashboard
and
then
the
application
itself.
So
it's
just
a
simple
echo
service
that
goes
back
what
we
put
in
the
URL
and
there's
a
dancing
monkey
for
some
reason.
That's
all
good!
So
we
wanted
to
update
our
application.
Say
we
wanted
to
I,
don't
know,
make
the
the
message
that
we
echo
back
uppercase,
so
normally
then
I
would
have
to
go
and
rebuild
the
image.
A
Push
that
to
a
container
registry
or
cube
control,
apply
all
that
stuff
and
I
get
the
new
version,
but
that's
very
manual.
So
we
want
to
automate
that
by
so
that
every
time
we
commit
to
the
repo
it
will
automatically
get
deployed
out,
you
know
into
our
cluster.
So
in
order
to
do
that,
firstly,
I
need
to
install
CV
Manager,
so
we
can
do
that
with
a
simple
cube.
Control
apply,
there's
also
a
helmet
art
for
it
as
well.
A
Then,
assuming
everything
goes
well.
So
what
we
can
see
here
is
that
we've
created
a
custom
resource
definition
and
a
deployment
for
our
CV
manager.
App
now
something's
happened
to
you
with
a
config
map.
Let
me
just
quickly
run
that
again
good
old
demos,
let's
see
if
that
worked,
that
time.
Okay.
So
now,
if
we
go
back
into
the
cluster,
we're
going
to
go
to
the
system
namespace,
and
we
should
see
that
CV
manager
up
there,
that's
now
started
up
and
you'll
see
also
a
sink.
A
pod
has
also
started.
A
So
that's
the
pod,
that's
neither
mentioned
earlier
is
actually
managing
the
CV
manager
itself
and
keeping
it
up
to
date.
So
that's
all
up
and
running
now,
that's
good.
The
next
step
is
that
we
need
to
add
some
configuration
to
our
application
to
tell
it
that
we
want
it
to
be
managed
by
the
CV
manager.
So
here's
some
of
the
some
example
configuration
for
that.
We
basically
define
the
repo
that
we
wanted
to
monitor
for
changes.
The
tag
represents
the
tag
on
the
container
image.
That
is
the
current
version
for
this
particular
cluster.
A
The
polling
time
was
just
how
regularly
we
checked
the
container
registry
now
the
select.
This
is
how
we
define
what
workload
is
actually
being
managed
by
this
resource.
So
what
we
need
to
do
is
just
go
down
to
our
deployment
here
and
add
a
label
that
matches
that
selector
and
finally,
we
need
to
specify
the
container
name,
because
obviously
there
can
be
multiple
containers
with
different
versions,
so
that
needs
to
match
the
name
of
the
container
down
here,
all
right.
So
that's
all
we
need
to
do.
We
can
now
just
do
a
queue.
A
Okay,
so
now
we
can
see,
we've
created
the
container
version
configuration
there
and
we've
updated
dated
the
deployment.
So
let's
go
back
into
the
cluster,
we'll
jump
back
to
our
default
namespace
where
our
application
is,
and
we
can
see
now.
Another
sinker
has
appeared
and
that's
now
managing
our
final
step
is
to
go
into
our
build
tool
and
set
up
our
workflow
step
for
that.
So
here
we're
using
circle
CI,
we
have
a
very
basic
build
that
creates
a
container
image
pushes
out
to
a
registry.
So
we
just
need
to
add
an
additional
step
here.
A
This
is
invoking
the
CV
Manager
command
inside
a
docker
container.
Just
writing
the
the
add
tags
sub
command.
We
specify
the
repo
the
tag
so
you'll
notice
that
this
tag
should
match
the
tag
that
we
defined
here
in
the
CV
manager
resource
and,
finally,
the
we
have
to
identify
which
actual
image
we're
updating.
A
So
if
we
go
to
our
build
tool
now,
which
was
circle
CA,
we
should
see
that
appear
there.
It
is,
it
will
start
running
now.
Hopefully
it's
not
going
to
pull,
though
we'll
have
to
build
the
whole
container
from
scratch,
in
which
case
it
will
take
a
few
minutes,
but
generally
this
would
take
less
than
a
minute
to
run,
and
once
that
completes
that
we'll
have
tagged.
The
container
image
in
the
repo
and
our
CR
stinker
should
pick
that
up
and
deploy
out
our
new
application.
A
A
That's
actually
already
updated,
ISM
I
love
it.
Oh
there
we
go
so
we
can
see
now
it's
actually
doing
a
rolling
deployment
there
for
those
for
those
pods
and
that
should
be
very
quick,
I
think
yeah
we're
pretty
much
there,
and
if
we
go
back
to
our
demo
application
we
should
see
everything
being
uppercase.
So
that's
that's
pretty
much
how
quickly
you
can
get
that
CD
pipeline
up
and
running
all
right.
Thank
you.