►
Description
This is an overview of Kubernetes Controllers, Operators with a focus on GitLab Kubernetes Operator which can be used to deploy GitLab to OpenShift or Kubernetes Cluster.
A
A
Well,
each
of
these
objects
and
their
spec
field
and
the
definition
of
the
object
they
have
a
definition
of
their
desired
state.
As
some
of
you
who
maybe
has
worked
with
deployments,
for
example,
in
a
deployment,
I
declare
what
are
the
replicas
number
of
ports
I
want
to
have
inside
that
deployment,
as
in
in
our
example
here
on
the
right
down
here,
you'll
see
like
okay,
I
have
three
three.
A
I
mean
three
pots
the
controller
job,
as
basically
as
a
controller
is
to
keep
on
comparing
that
object,
spec
field,
which
represents
the
desired
state
and
the
actual
state
of
that
object
inside
the
coupon.
That
is
cluster
right
and
if
there
is
like
any
inconsistency
between
the
two,
the
controller
job
is
to
change
the
current
state
to
make
it
as
close
as
possible
to
the
desired
state,
of
course,
practically
under
the
under
the
hood.
Everything
goes
through
the
other
components
like
the
keeper
that
is
api
server.
A
So
this
way
or
the
way
controllers
control.
The
objects
is
perfect
for
stateless
applications
or
stateless
objects,
because
it
is
really
as
simple
as
delete,
add
or
change
the
status
of
the
pod.
There
is
no
application
context
here
right.
It
is
just
changing
the
implementation
of
that
kubernetes
object
inside
inside
cluster.
Well,
what
if
I
wan?
I
have
stateful
applications
where
I
need
to
have
more
of
an
application
knowledge
to
operate,
to
properly
control
and
operate
that
object.
What,
if
I'm
doing
this
for
a
database?
A
How?
Well,
I
define
for
the
controller
that
please,
when
you
add
a
new
database
instance
or
port,
please
redeploy
or
redistribute
the
data
between
the
three
instances
or
keep
certain
number
of
pots
running
of
between
the
databases
and
elect
one
of
them
as
the
master
rule,
or
maybe
take
a
backup
overnight
from
that
specific
database
constructs
outside
as
as
operating
it
or
maybe
monitor
the
database,
let's
say
kpis
and
change
or
scale
horizontally
and
vertically,
as
per
the
workload
inside
the
database.
A
This
is
exactly
where
the
cuban
letters
operator
come
in
in
the
picture.
Well,
basically
think
of
the
operators.
I
really
like
this
this
picture.
Think
of
them
as
exactly
these
robots.
I
am
basically
it's
it's.
It
was
introduced
in
2016
and
basically,
it's
a
great
way
for
managing
kubernetes
applications,
especially
as
I
said,
stateful
applications-
think
of
them
as
an
automated
sra
or
site
reliability.
Engineer
for
for
the
application
it's
beyond
the
day,
zero
and
day,
one
only
tasks
for
deploying
the
application.
A
It's
all
about
all
the
other
tasks
that
sre
is
responsible
to
to
do
on
the
application
to
keep
it
running,
which
are
more
related
to
the
application
context
or
application
logic
itself,
and
that
same
applies
to
the
gitlab
kubernetes
operator.
So
in
other
words,
the
ultimate
objective
for
the
gitlab
kubernetes
operator
is
to
take
care
for
deploying
upgrading
and
the
operation
of
the
gitlab
deployed
deployed
instance
from
backup
recovery
from
monitoring
from
scalability
horizontally
or
vertically,
based
on
the
kpis
defined
as
an
object
or
as
an
application
level.
A
So
the
operator
comes
really
well
what
we
call
custom
resource
definition.
So
if
I
go
back
just
two
slides
here
this,
we
agreed
that
the
objects
in
cuban
letters
are
defined
or
every
component
in
kubernetes
is
defined
as
object.
So
deployments
are
objects
so
when
we
say
custom
resource
definitions,
think
of
them
as
an
extension
to
these
objects.
Basically,
I
am
defining
a
new
case
inside
the
cuban
letters
cluster,
but
these
are
my
own
defined
objects
or
custom
defined
objects.
That's
why
it's
called
sorry.
It
says
their
customer.
It's
custom!
A
Sorry,
it's
custom
resource
definitions,
so
the
operator
basically
do
it.
Does
two
things?
First:
it
extends
the
cuban
letters
api
by
adding
custom
resources,
so
the
api
is
used
to
the
normal
resources
deployments:
ports,
services
ingress.
These
are
normal
built-in
out-of-the-box,
available
resources,
excellent
with
the
cr
or
the
custom
resources
I
am
defining
or
using
the
crds,
the
customer
resource
definition.
I
am
defining
new
resources
through
the
api
7
say
mr
api
server.
Would
you
please
also?
A
Can
I
introduce
you
to
a
new
kit
in
your
in
your
form,
which
is
let's
say,
gitlab
github
will
become
as
an
object
similar
to
the
deployment
object
similar
to
the
ports
objects
similar
to
the
services
along
with
a
control
plan,
and
this
is
as
a
sort
of
a
controller
similar
behavior.
Let's
say
a
control
plan
component
that
monitors
and
maintains
the
resources
of
the
new
type
right.
So
this
is
the
command
and
control
the
brain
for
the
operator.
A
This
is
the
operator
itself,
which
is
which
is
this
box
here,
so
two
things:
a
new
resource
defined
using
the
custom
resource
definition.
In
our
instance,
the
new
resource
is
gitlab
and
a
new,
a
controller
for
controlling
this
resource,
which
will
cover
the
full
life
cycle
for
that
resource
which
we'll
see
in
in
a
second.
A
So
why
we
should
care
about
good
club,
kupernite's
operators?
Basically
kubernetes
operators
like
let's
say
the
key
trigger
for
them-
was
for
deploying
git
lab
to
against
openshift
right
today,
the
an
operator
already
available
and
ready
to
use
for
use
and
utilize
to
be
utilized
in
open,
open
shift
operator,
lifecycle
manager
for
gitlab
runner,
where,
basically,
I
can
deploy
gitlab
operator
and
I
can
define
gitlab
sorry.
A
So,
just
to
summarize
here,
gitlab
operators
in
general
are
components
within
it,
introduced
in
the
kubernetes
cluster
for
managing
mainly
stateful
applications
and
why
they
were
introduced.
They
were
introduced
because
we
are
trying
to
automate
the
sre
or
the
site.
Reality
engineer
daily
tasks
for
managing
applications,
so
by
adding
an
extra
layer
of
automation,
which
is
not
only
what's
what
the
controller
is
doing
under
the
hood.
A
It
is
the
next
level
where
you
are
adding
business
logic,
oriented
specif
specific
for
the
application
to
manage
the
application
how's
that
done
two
things:
defining
that
the
custom
resource
which
is
based
on
the
custom
resource
definition,
which
is
based.
You
are
introducing
a
new
object
definition
within
the
kubernetes
cluster,
along
with
the
operator
for
controlling
that
custom
resource
lifecycle.
A
First,
let
me
highlight
one
thing
here,
or
maybe
I
would
I
should
I
should
okay,
let
me
say
before
I
go
and
go
into
the
details.
The
github
runner
operators
is
already
available.
The
gitlab
operator,
which
is
today
is
beta.
It
depends
on
where
you
are
installing
it.
The
steps
I
will
I'll
show
you
in
a
second
are:
can
can
be
used
to
deploy
that
operator
on
any
kubernetes
cluster.
A
If
you
are
going
direct
against
against
openshift,
but
in
openshift
you
have
out
of
the
box
using
the
ui
using
openshift
lifecycle
cycle,
the
operator
lifecycle
manager
in
openshift.
It
can
handle
the
complete
deployment
of
the
gitlab
operator.
Basically,
you
don't
have
to
go
through,
like
the
manifest.
Why
a
way
of
manual
deployment
of
the
operator-
which
I
will
show
you
in
in
a
second
but
it's
good-
to
understand-
what's
happening
under
the
hood
and
it's
good.
It's
also.
A
You
can
use
that
to
deploy
the
operator
to
a
kubernetes
cluster
outside
outside
openshift,
at
least
for
distinct
purposes.
So,
basically,
the
steps
are
simple.
Deploy
the
operator
life
cycle
management.
It's
it's
really
optional
step
is
for
managing
the
the
operator's
life
cycle
itself,
a
component
that
can
make
the
operator
the
management
of
the
operator
operators
much
easier
in
again,
install
nginx
controller.
The
gitlab
operator
itself
comes
with
a
default
engine
export
deployment,
or
you
can
use
your
own
engine
x
controller.
A
Number
four
install
github
custom
resource
definition,
and
this
is
exactly
where
you
say,
mr
gitlab,
by
the
way
here
is
a
definition
for
the
kubernetes,
a
new
object
or
custom
resource
new
object,
which
is
in
our
case
gitlab.
So
next
time,
when
I
use
a
kind
gitlab,
you
know
what
I
mean
right
so
again:
kubernetes
already
has
definition
for
other
default
objects
like
deployments,
ingress
spots,
resource
controllers
and
other
objects.
A
A
Once
this
is
created,
then
you
will
get
all
the
objects
of
the
gitlab
deployment
and,
along
with
the
controller
manager
in
this
instance.
This
is
exactly
the
controller
we
were
talking
about,
but
it
is
responsible
for
controlling
the
objects
of
the
deployed.
Gitlab
object,
sorry,
the
pods
or
the
components
of
the
deployed.
Gitlab
gitlab
object
like
italy,
web
server,
controller
manager,
manager,
task
runner
and
register.
A
A
So,
as
I
said
earlier,
in
keeping
is
our
keepness
operator.
There
is
a
defined
operator
maturity
model
right,
which
has
five
levels
level,
one.
Basically,
I'm
using
the
operator
to
install
the
component.
It
is,
as
is
very
similar
to
what
we
do
today,
with
other
objects
deployments
or
services
or
any
other
other
objects.
Basically,
please,
mr
operator,
create
for
me
a
new
object.
It
happened
to
be
in
our
case
gitlab
in
your
object.
A
Second,
use
that
operator
to
patch
and
and
minor
version
upgrade
right
so
upgrade
for
me
and
I'll
show
you
that
in
the
demo
upgrade
for
me,
gitlab
from
virgin
like
10.34,
I'm
just
making
that
up
into
the
10.35
the
new.
The
next
version
now
from
these
two
are
supported
using
the
helm
base,
the
helm
based
operator
and
by
the
way,
as
of
today,
the
gitlab
operator
is
within
that
area.
It
is
using
helm
right,
but
it
is
moving
or
quickly
moving
beyond
that
to
climb
up
the
maturity
model
towards
liberty.
A
Three
four
five-
and
this
is
where
the
the
nice
magic
and
say
of
the
operator
comes
in
the
picture
for
life
cycle
management
right,
so
not
only
install
not
only
deploy
and
manage
upgrade,
but
also
please
operator,
be
responsible
for
backing
up
and
a
failure.
Recovery
of
my
gitlab
installed
instance
right
remember
today.
These
of
these
tasks
are
done.
You
sort
of
manually,
or
at
least
outside
the
deployment
of
the
human
axis
cluster
they
are
done.
Using
tasks
may
be
automated
by
the
sres,
I'm
bringing
that
within
that
object.
A
A
When
I
move
into
the
next
maturity,
I
not
only
I
can
pack
it
up
and
fill
it,
but
also
I
will
be
able
to
look
into
the
matrices
and
alerts
and
looks
coming
from
the
my
gitlab
server
and
be
able
to
analyze
that
and
maybe
raise
alerts
or
send
notifications
based
on
the
status.
So
it
goes
into
more
of
a
preventive
action
on
based
on
the
status
on
operation
of
my
gitlab
deployed
object.
A
A
So
deleting
kubernetes
cluster
things.
I'm
sure
this
list
will
maybe
grow
as
we
move
forward
with
the
gitlab
operator
development
in
in
gitlab.
But
it's
important
to
remember
that
deleting
the
gitlab.
These
are
the
three
steps
by
the
way
for
deleting
the
gitlab
operator,
and
I
will
show
you
in
a
second
the
repo,
where
you
will
find
all
the
instruction
for
installing
and
deleting
the
operator.
A
A
A
Okay,
once
I
get
the
answer
back,
so
I
hope
I
will
get
the
answer.
Yep
here
we
go.
I
have
a
git
lab
custom
resource
defined.
This
is
my
object.
You
see
the
command
git
lab,
get
git
lapse.
Git
labs
is
like
I'm
doing
it
as
similar
to
the
command
cube,
ctl
git
deployments
that
define
key
clouds.
As
you
would
imagine
it's
coming
from
the
defined
crd,
I
have
added
a
crd.
There
called
git
labs,
it's
it's
already
deployed
as
as
gitlab
for
my
deployment.
A
A
A
So
the
article
is
this:
the
new
gitlab
operator
for
openshift,
I
really
it
was
really
helpful
and
there
you
will
find
a
link
to
the
deployment
steps
for
deploying
gitlab
operator
and,
as
it
says
here,
github
operator
can
be
manifested
to
deploy
to
manifest
in
in
kubernetes
or
openshift.
In
my
case,
I
try
to
do
that
in
simply
in
cuban
letters.
It
works
perfectly
well
only
thing
you
may
find
is
in
this
step
here
when
it
says.
A
A
Okay,
okay,
you
know
it's
already
there
that
cool,
so
you
will
have
this
error
if
you
are
deploying
against
kubernetes,
not
openshift,
because
security
context
constraints
are
openshift,
specific
objects,
don't
worry
about
that!
One
just
continue
and
move
forward,
and
thanks
to
our
engineers
in
in
gitlab
who
helped
me
with
this
hint.
So
don't
worry
about
this
one.
If
you
are
deploying
and
in
this
step
just
go
ahead
and
and
go
to
the
next
step,
so
this
repo
will
show
you
how
to
deploy
the
crds.
A
A
You
see
this
one
kind
here
says
gitlab.
What
is
that,
as
you
would
imagine
this-
is
the
crd
defined
for
for
a
gitlab,
and
this
is
the
name
of
the
object
and
the
version
and
this
version
10
4,
10
4,
10
4-
is
the
version
of
the
helm
chart
used
for
this
deployment.
As
I
said
before
so
far,
git
lab
operator
is
using
health
chart.
So
if
I
go
back
to
my
ripple,
you
will
see
that
we
have
the
in
the
same
repo.
A
A
Yep,
so
here's
a
mapping
between
the
gitlab
helm
chart
and
the
gitlab
version,
so
in
our
in
our
deployment
here
you
see
that
I
am
using
410
for
144
and
the
github
version
on
the
right
here.
If
I
go
into
here,
removing
the
bookmarks
under
virgin
the
virgin
deployed
is
10
for
sorry
13
10
4.
So
if
I
go
here
is
and
search
for
that,
one.
A
A
A
Yep
I'll
delete
this
so
delete,
I'm
just
deleting
an
object
called
gitlab
right,
as,
as
you
may
remember,
or
recall,
from
decision,
this
will
not
delete
the
name
space
and
this
will
not
delete
the
pvcs
or
the
persistent
volume
claims
or
persistence
volumes
from
my
gitlab
namespace,
which
is
in
my
case
gitlab
system
and
then
I'll
do
like
them.
This
one
go
here
and.
A
Oh
sorry,
I
did
not
copy
properly,
okay,
so
I'll
just
copy
this
one
again
come
here.
Remove
this
one:
oh
okay,
I'll
just
type
it
for
two.
What
was
that
4.11.3
4.11.3
and
that's
it
and
then,
if
I
do
keep
in
cubicity
I'll
get
pods
sorry
get
parts
from
that.
You
see
that
all
the
thoughts
have
been
deleted,
keep
ctl
apply.
Sorry,
let
this
apply
cube.
Ctl
apply.
A
A
So
until
this
is
created,
let
me
just
rehearse
quickly
what
we
have
covered
today.
Basically
we
we
said
we
started
from
the
gitlab,
sorry
from
the
cuban
that
is
controllers
and
we
agreed
that
kubernetes
is
declarative
based.
Basically,
you
have
an
object.
The
object
has
a
field
in
the
spec
which
represents
the
desired
value
or
the
desired
version
of
that.
A
Sorry,
the
desired
status
of
that
object
and
the
controller
job
is
basically
to
continuously
compare
between
that
desired
version
of
status
and
the
current
status
of
that
object,
and
if
they
are
different,
then
the
controller
will
be
responsible
to
bring
the
current
state
of
the
object
as
close
as
possible.
If
not
the
same,
to
the
desired
state.
A
We
agreed
that
controllers
are
doing
excellent,
awesome
job
with
stateless
applications,
but
when
it
comes
to
stateful,
applications
like
databases
like
that
it
becomes
extra
tasks
would
be
required
in
order
to
manage
these
applications,
because
you
have
a
level
of
business
logic
specific
for
the
application
for
managing
these.
These
deployment
of
these
objects,
usually,
traditionally,
these
tasks
are
done
by
the
get
lab
by
the
sres
of
that
object.
A
This
is
why
gitlab
has
been
developing
a
gitlab
operators
for
operating
and
installing
git
lab
and
the
kubernetes
clusters
and
specifically
for
openshift
deployment.
Today
we
have
two
types
of
operators:
the
runner
operator
for
deploying
git
lab
runners
in
openshift.
They
are
available.
You
can
use
them.