►
From YouTube: Beaming Ortelius Podcast - April 2022 with Viktor Farcic
Description
Join Viktor Farcic and Saim Safder as they discuss what GitOps is, why it's cool and how you can get started on a GitOps journey.
A
Thank
you,
everyone
for
joining
us
on
ortillius,
beaming,
hoteliers,
podcast,
and
let
me
fix,
introduce
you
what
hoteliers
is
ortelius
is.
This
is
helping
you
build
some
of
the
microservices
by
providing
you
a
central
catalog
for
services
with
their
deployment,
specs
applications
teams
can
easily
consume
and
deploy
services
across
cluster
hoteliers,
track
application
version
based
on
service
updates
and
map,
their
service
dependency,
eliminating
confusion
and
guess
work.
So
some
small
intro
of
the
ateliers,
and
now
we
are
talking
about
on
this
episode,
get
offs
and
we
have
not
a
better
guess
than
victor
farsek.
A
Victory
advocated
at
about,
and
he
has
a
wonderful
youtube
channel,
always
trying
to
share
his
wonderful
work
with
the
community
and
a
great
human
being,
and
I
I
just
ask
him:
I
want
to
have
some
show
with
you
and
he's
absolutely
ready
to
do
it.
So
today's
our
agenda
is
get
offs
and
people
who
had
never
heard
about
get
offs.
Let
us
let
people
know
what
it
is
and
why
we
are
so
crazy
about
skatops.
B
So
so
there
are
two
different
things
that
I
I
believe
that
might
need.
Explanation,
first,
is
what
it
really
is,
and
then
there
are
principles
which
are,
I
think,
very
important,
because
if
you
just
talk
about
what
it
is,
then
you
might
think
that
many
tools
are
doing
githubs,
even
if
they're
not
right.
So
what
did
this
is
relatively
easy
to
explain
and
that's
that
we
have
two
states
desired
state.
B
That's
what
I
want
as
a
human
being
as
victor
kind
of
like
that's
what
that's
the
expression
of
my
desire
and
we
have
the
actual
state.
That's
what
something
really
is
right,
so
it's
what
it
should
be
and
what
it
is
and
what
it
should
be
is
defined
one
way
or
another
as
something
that
is
readable
by
machines
starting
it.
That's
where
we
store
things
doesn't
have
to
be
git.
B
B
What
I
just
said
and
that's
why
the
principles
are
extremely
important
right
and
there
are
four
principles
that
any
tool
needs
to
implement
in
order
to
be
called
gitos
right
and
by
the
way
I
didn't
mention
before,
but
there
are
tools
in
between
the
actual
and
desired
state
that
are
making
this
happen.
It's
not
little
people
sitting
around
and
waiting
doing
our
biddings,
so
four
principles
right
needs
to
be
declarative,
meaning
that
the
desired
state
needs
to
be
expressed.
Declaratively
now
just
to
clarify
before
I
continue.
B
What
I'm
saying
does
not
necessarily
mean
that
that's
the
best
way
to
do
stuff,
I'm
just
saying
that
that's
how
something
should
be
done
to
be
called
githubs.
That
does
not
mean
that
you
need
to
define
declarativity,
you
don't
have
to
use
githubs
right,
so
declarative
definition
of
the
desired
state.
B
It
needs
to
be
versioned
and
immutable,
so
you
cannot
just
keep
it
on
this
drive
right.
That's
why
I
said
git
git
is
the
most
common
way,
how
we
version
things
and
how
we
make
something
immutable,
meaning
you
cannot
really
edit
the
comment
you
can
create
a
new
comment.
You
cannot
edit
it
and
now
comes
the
important
thing
that
distinguishes
github's
tools
from
pipelines.
It
needs
to
be
pulled
automatically.
B
And
that
means
that
you
cannot
have
hey,
I
push
something
to
git,
and
then
I
run
gitlab
ci.
I
because
git
github
is
going
to
notify
it.
That's
push
mechanism
right,
it
needs
to
be
pulled,
so
I
have,
I
must
have
a
process
somewhere
that
is
constantly
monitoring
my
git
repository
and
whenever
there
is
a
change
in
between
what
it
is
and
what
it
should
be
does
whatever
needs
to
be
done
so
pull
the
automatically
third
and
the
fourth
one
continuously
reconciled,
and
this
is
now
important,
even
if
ignore
pulled
automatically.
B
It's
not
good
enough
to
say
hey
whenever
I
change
something
in
git,
I
will
run
some
process
and
that
process
will
do
whatever
needs
to
be
done.
No,
because
that
actual
state
might
change,
because
a
server
might
go
down
for
random
reasons
right
so
and
then,
if
it
goes
down,
it
will
stay
down
forever.
B
Until
I
make
a
change
to
get
that's
why
it
needs
to
be
continuously
reconciled,
we
need
to
have
a
process
that
is
all
the
time
watching
for
the
differences,
not
only
when
I
push
something
to
get,
but
all
the
time
monitoring
and
saying
is
it
is
that
is
this
the
same
as
this?
Yes,
is
this
the
same
as
this?
Yes,
is
this
the
same
as
this?
No,
oh,
okay,
stop!
I
need
to
do
something
right,
so
declarative
version.
Then
immutable
pulled
automatically
continuously
reconciled.
If
you
do
those
four
things:
you're
doing
githubs.
A
Yes,
absolutely
absolutely
that's
a
great
way
of
thinking
about
get
out,
because
it's
look
really
complicated
at
it.
At
the
first
go,
but,
incidentally,
is
like
you
have
yaml
files
that
you
have
in
your
machine
and
kubernetes
is
all
about
yaml.
You
have
ingress
for
the
ammo,
you
have
services
for
yammer,
you
have
deployments
replica,
everything
is
yaml
based
and
when
you
put
this
yaml
into
the
github
repository,
if
their
job
is
actually
to
make
this
make
the
system
to
the
desired
state.
You
want
to
rapidly
guys
you
want.
A
B
I'll
ask
those
questions,
but
before
I
do
that
a
small
correction
of
what
you
said,
I
intentionally
did
not
say
kubernetes
you
did
and
I'm
intentionally
avoiding
to
say
kubernetes,
because
nothing
says
that
we
should
apply
github's
principles
only
for
applications
running
kubernetes.
It
could
be
for
anything
okay.
So
now
I
already
forgot
to
your
questions.
What
was
a
what
is
reconcile,
because
what
does
it
mean
being
reconciled
right?
B
B
No,
I'm
going
to
actually
use
kubernetes
example
right
when
you
deploy
a
deployment
in
kubernetes
you're
telling
kubernetes.
I
want
this
deployment
and,
as
a
result
of-
and
you
say
I
want
this
deployment
and
I
want
to
have
two
replicas
of
my
application
right,
I'm
not
talking
about
github
for
now
right.
B
What
kubernetes
does
is
two
things.
First,
it
will
create
two
pods
so
that
you
have
two
replicas
of
your
application,
but-
and
this
is
now
kind
of
where
reconciliation
comes
into-
it
does
not
only
create
those
two
pods.
First,
it
checks
how
many
positive
you
have
zero
one.
Three
right,
it
might
create
two,
it
might
create
one
it
might
create,
it
might
destroy
a
pod
right
and
it
is
continuously
watching
the
status.
B
It's
not
only
doing
something
once
it
is
you're
making
a
contract
like
with
a
signature
kind
of
saying
I
told
you
two
pods,
I
told
you
two
replicas
and
I
want
you
to
ensure
that
it's
always
too
replicas,
no
matter
what
happens
right
and
that's
reconciliation,
I
mean
not
directly,
but
basically,
reconciliation
is
about.
Looking
for
drifts.
A
Yes,
absolutely
absolutely
and
that
that
is
actually
based
on
that
reconciliation.
We
talked
about
a
lot
in
kubernetes
world
declaratively
and
for
the
people
who
are
really
new
to
this
world.
What
does
you
mean?
Because
we
have
two
way
of
doing
things
in
id
in
in
general,
like
one
is
imperatively
and
one
is
declaratively,
and
I
want
you
to
people
know
what
that
two
different
mean,
and
that
is
based
on
the
consideration
we
have
like
reconciliation
and
drift
detection.
B
Yes,
so
for
kubernetes
to
know
for
kubernetes
or
github
tools
or
many
other
types
of
tools
to
know
easily
what
you
want.
It's
actually
not
to
know
it's
much
easier
for
them
to
know
what
you
want.
If
you
declared
every
single
piece
of
what
that
is
right,
it's
much
easier
for
kubernetes
to
understand
what
you
want
when
you
say.
I
want
three
replicas
and
I
want
this
host
and
I
want
this
and
I
want
that
right
in
the
declaring
each
parameter
of
something
in
each
component
separately.
Right
imperative
would
be.
B
B
So
impressive
is
more
about
creating
the
logic
of
something
and
declarative
is
about
exactly
specifying
what
you
want
and
that's
very
important,
because
that's
that
makes
job
of
kubernetes
easy
right
now.
You
can
have
both
to
clarify,
so
you
can
use
something
like
templating.
Some
people
say
that
helm
is
declarative.
I
I
I
beg
to
differ.
I
say
that
helm
is
actually
imperative,
but
or
python
code
or
go
code.
You
don't
have
to
do
it
decoratively.
B
However,
you
can
specify
any
way
you
want,
but
between
you
doing
something
and
that
reaching
kubernetes
or
github
stools
it
needs
to
be
transformed
into
declarative
right.
So
you
have
two
options:
either
you
write
directly
yaml
or
json
or
xml,
or
any
of
the
declarative
base
to
define
things
directly
or
you
can
use
some
other
tools.
You
can
use
like,
let's
say
polumi,
but
for
pollumi
to
do
what
needs
to
be
done.
B
A
Yes,
absolutely
absolutely
like.
I
think
that
the
one
way
you
do
manually
some
of
the
stuff-
and
you
tell
the
system
that
I
want
my
system
to
have
in
that
stage
that
I
have
defined
in
yaml.
I
don't
know
how
you
do
it.
Let's
do
it.
You
know
how
to
do
it.
So
that's
you.
That's
the
way
to
do
it
and
apparently
you're
telling
each
step
like
you've
done
this
script.
You've
done
this
and
load
balancer
you've
done
this
thing,
so
I
think
that's
something
a
great
explanation
to
this.
A
B
B
A
Yes,
absolutely
absolutely,
and
also,
I
think,
for
those
of
people
might
be
some
of
the
people
that
joined
it
or
listening
to
us.
It
hasn't
been
devops
background,
like
they
spend
most
of
the
career
in
the
devops,
and
they
heard
the
coin
in
the
new
term
called
get
offs
and
they're
wondering.
Is
it
a
subset
of
devops?
What
is
a
completely
new
field,
or
how
do
I
map
my
existing
knowledge
of
devops
into
the
githubs.
C
B
Is
everything
whatever
you
ask?
Somebody
is
this
devops?
Yes,
absolutely
everything
right
so
devops
is
about
is
a
maybe
a
process.
It's
a
cultural
change
and
stuff
like
that
right.
Well,
it's
something
very
fluid
hard
to
define.
Gitops
is
a
technical
practice
right,
so
devops
is
not
a
technical
practice.
It's
not
kind
of
like
you
do
this
and
then
your
devops,
no
kind
of
like
developers
and
operations
work
together,
blah
blah
blah
like
agile
conceptually,
it's
not
the
same
thing,
but
it
goes
into
the
same
category.
B
As
you
say,
agile,
agile
is
not
a
technical
practice.
Right.
Xp
is
the
same
thing
with
github.
Githubs
is
a
technical
practice.
This
is
what
needs
to
be
done.
This
is
how
that
something
is
done,
and
those
are
the
tools
that
fulfill
the
requirements
to
do
things
in
a
very,
very
specific
way
right.
So
technical
devops
is,
I
still
don't
know
what
it
is,
but
it's
not
the
technical
term
for
sure.
A
C
A
Actually,
a
technical
term-
and
this
is
a
this-
is
your
problem
you
have,
and
this
is
how
you
technically
solve
that
problem
and
now
we're
talking
about
the
github.
So
people
are
listening
to
us
and
new.
Tell
us
about
the
workflow,
because
that's
really
important
for
people
to
understand
from
the
vectors
vector-wise
like
what
the
workflow
it
is
like
when
we
develop
code
and
when
you
commit
the
first
repository,
if
first
say
to
commit
to
the
repository
what
happened
next
in
the
github's
pipeline,
how
should
you
build
it
and
what
the
process
look
like.
B
So
I
will
actually
give
you
two
answers
to
that.
Well,
actually
only
one
answer
to
what
you
ask
but
then
say
that
you
asked
the
wrong
question
so
get
those
processes
very
easy.
You
push
some
change
to
git
that
defines
that
modifies
the
desired
state.
There
is
a
process
running
somewhere
that
detects
that
and
makes
the
changes
to
the
system
and
continues
monitoring
the
system.
B
There
is
not
much
more
to
it
or,
to
put
it
in
other
words,
you
change,
yaml
or
json
or
whatever
file
you
push
it
to
git
and
that's
the
whole
process
that
there
is
nothing
else
to
it.
Right
I
mean
from
the
human
perspective
from
process
perspective
we
have
some
operator
kind
of
that
is
monitoring
it
sees.
Oh
victor
wants
a
new
change,
the
desired
state.
I
should
do
something
now.
What
is
a
more
interesting
question
which
you
didn't
ask
from
my
perspective
is
what
is
the?
B
How
does
github
fix
fit
into
continuous
delivery
or
continuous
integration
or
continuous
deployment
process?
Right
to
me,
that's
a
more
interesting
question
now,
if
you
look
at
forget
about
githubs,
imagine
that
it
doesn't
exist
kind
of
how
we
did
in
the
past.
So
if
you
talk
about
cicd
every,
let's
say
a
cd,
continuous
delivery
right.
Continuous
delivery
is
a
full
automation
of
the
life
cycle
of
an
application,
and
what
that
really
means
is
that
it
starts
with
git.
I
push
some
change
to
git
and
now
bear
in
mind.
B
B
I
typic
typically
run
a
pipeline
that
would
build
test,
deploy
and
so
on
and
so
forth.
What
it
does
depends
from
one
case
to
another,
but
let's
say
in
simple
way:
build
test,
deploy
right
now
in
that
world
the
deployment
build
would
be
okay,
I
execute
like
from
inside
pipeline,
not
me
right
in
a
pipeline.
I
would
execute
something
similar
to
docker
docker
image
build
test.
I
would
execute
some
maven
tests
or
whatever
you're
using
and
deployment
would
be
cube.
Cuttle
apply
right
or
help
install
or
ssh
over
there
and
copy
the
file.
B
Whatever
the
deployment
process
is
now,
if
you
put
githubs
into
the
mix,
the
situation
changes
a
bit
and
it
changes.
If,
if
I
still
continue
with
those
three
steps
right,
I
build
stays
the
same.
I
test
stays
the
same
and
then
when
it
comes
to
deployment
instead
of
deploying
directly
from
the
pipeline,
I'm
actually
that
pipeline
is
not
going
to
deploy
anything.
That
pipeline
is
going
to
get
the
contents
of
the
repository
that
contains
my
manifest
modify,
something
let's
say:
change
the
tag
of
the
image
of
the
application
and
push
it
back
to
git.
B
So
my
pipelines,
all
of
a
sudden,
do
not
deploy
anything.
They
are
modifying
git
repositories,
it
doesn't
have
to
be
pipeline.
We
have
other
ways
to
do
that,
but,
let's
say
pipeline
for
the
argument
right
and
then
pipeline
from
from
pipeline
perspective.
It's
finished,
but
the
process
perspective
is
not
finished
right
after
my
pipeline
is
finished,
then
we
have
like
flux
or
argo
cd
that
will
detect
that
change,
apply
it
to
the
cluster
or
aws
or
wherever
you're
running
right.
B
So
the
from
the
high
level
perspective
is
still
the
same.
We
build
the
test
will
deploy,
but
the
way
how
we
deploy
is
different.
We
do
not
deploy
directly,
we
make
changes
to
get
and
the
reasons
why
we
want
to
do
that.
Actually,
the
more
I
forgot
about
the
most
important
thing
to
say
right:
why
do
we
want
githubs
in
the
first
place,
and
the
reason
is
that
I
want
to
be
able
to
have
information
at
any
given
moment?
A
And
you
already
answered
that
that's
awesome.
So
now
we
kick
start
the
moving
forward,
because
we
already
we
as
you
talk
about
like
argo,
cd
and
flux.
You
talk
during
the
conversation
and
for
the
people
we
talk
about
get
offs.
We
know
what
it
is
and
how
it's
detected
drift
detection
and
how
it's
different
for
the
current
ci
cd
pipeline,
but
now
the
current
implementation
we
have
like
in
orgo,
cd
and
flux,
so
tell
us
people
how
what
these
tools
are
doing
and
how
they.
Actually
you
get
started
with
these
dualism
as
well.
B
So
what
they're
doing
is
relatively
easy
to
explain:
it's,
not
necessarily
that
what
they're
doing
is
easy,
it's
not,
but
to
explain
it
is
relatively
easy.
You
have
a
process
running
somewhere
in
kubernetes
cluster
right.
It
doesn't
have
to
be
in
kubernetes
cluster,
but
all
the
tools
happen
to
be
in
kubernetes,
because
most
of
the
innovation
is
happening
kubernetes.
So
we
have
a
process
running
in
kubernetes
and
all
we're
doing
is
telling
fluxopargo
cd,
hey
here's
an
application,
and
by
application
I
do
not
mean
necessarily
the
same
thing
as
application
application.
B
I
mean
here's
a
entity,
let's
say
entity,
here's
an
entity
that
I
want
you
to
manage
and
that
entity
or
entities
in
plural
are
defined
in
this
repository.
So
we
are
feeding
argosidior
flux
within
with
with
information
two
types
of
information.
First,
these
are
the
repositories
you
should
watch
and
the
second
thing
is
those
are
the
destinations
where
that
something
should
be
happening.
Right
kind
of
hey
inside
of
whatever
is
defining
that
repository
should
run
inside
of
this
cluster,
or
it
doesn't
have
to
be
application
right.
B
A
B
B
A
It's
now
the
life
is
really
easy.
Explanation
is
really
easy,
but
how
these
system,
like
argo
cd
flux,
because
in
the
kubernetes
landscape
there
is
always
debates
about
what
should
we
do,
because
there
is
so
many
so
many
options
you
have
and
I
think,
with
the
github's
words
there
are
so
many
might
be.
There
are
a
few
many,
but
we
have
I'll
talk
about
a
lot:
argo,
cd
and
flux.
B
B
B
B
A
Yes,
absolutely
absolutely,
and
also
if
you
are
still
new
and
don't
know
where
what
which
one
to
use
the
victor
has
a
wonderful
youtube
channel
and
I
think
ton
of
videos
on
the
githubs
and
flux
will
tell
you
in
which
scenario
you
should
use
that
go
check
that
out
as
well.
I
think,
if
you're
not
subscribing
to
the
victor
channel,
I
think
you're,
not
in
the
cloud
native
word.
You
sure
you
should
be.
Is
this?
It's
been
a
wonderful
youtube.
C
A
I
always
always
even
see
very
new
terminologies
new
concepts,
new
tools,
I
the
only
channel
I
have
where
I
can
see
all
the
new
details
around
the
things
I
never
heard
about
it
and
explains
victor's
playing
wonderfully
well
in
a
very
short
format
in
this
app,
and
we
talk
about
like
talk
about
flux,
argo
cd.
Now,
as
you
turn
the
coin
like
when
you
start
another
conversation,
but
before
we
moving
to
that
talk
about
some
ratchet
fleet,
because
it's
had,
I
think
it's
it's
it's
it's
been
in
in
this
stage.
B
B
Yeah,
so
what
makes
rancher
fleets
special
is
that
it
was
designed
to
run
at
scale
or
not
to
run
a
scale.
Sorry,
that's
not
correct.
It
was
designed
to
manage
your
state
at
scale
right
so
from
design
perspective,
it
was
made
from
get
go
to
effectively
manage
applications
running
in
dozens
or
hundreds
of
clusters
right
and
hundreds
of
or
thousands
of
applications
stuff
like
so
it's
at
scale.
B
B
So
I
would
consider
rancher
fleet
if
you
want
to
run
your
stuff
at
scale,
big
one
right,
but
only
consider
it
do
not
use.
It
is
still
young
a
lot
of
problems
and
a
lot
of
issues
there,
which
is
normal
because
you
know
we
are
talking
about
the
project
that
is
infancy,
but
I
think
it's
a
project
that
is
very
interesting
to
watch
not
necessarily
to
recommend
yet
but
to
watch.
A
Absolutely
I
think
you
have
to
reconcile
with
the
rancher
fleet
what
they
are
doing
in
their
repository
might
be
some
interest
for
you.
I
think
you
go
check
that
out
check
out
as
well.
I
think
the
rancher
is
really
a
wonderful
team
because
they
spun
up
very
good
projects
like
k3s,
like
I
think,
and
also
rancher
fleet
rancher
desktop,
is
also
coming
up.
There
are
storage
solutions,
so
I
think
we
can.
You
can
expect
great
things
from
that
team
because
they
are
already
knowing.
B
A
Presence
felt
in
the
industry,
so
we
can
expect
some
good
things.
Good
innovation
happening
in
the
in
that
space,
as
well,
so
before,
jumping
out
into
the
theory
where
we
talk
about
like
in
your
youtube
videos
you
talk
about
on
the
first.
This
is
how
you
should
do
it
just
talk
about
their
pros.
You
talk
about
it,
how
to
implement
it,
and
the
last
part
is
actually
a
wonderful
comparison,
so
we
will
start
that
comparison,
but
later
what
the
gate
of
what
thing
you
should
not
do
in
the
githubs
as
well.
A
So
talk
about
talk
is
about
some
cloud
scenarios
and
also
the
scenarios
where
kubernetes
is
not
there
and
people
think
because
it
is
a
really
like
you
are.
When
you
talk
about
get
offs,
I
think
most
of
the
audience
is
just
for
the
kubernetes,
but
you
always
telling
people
it's
not
just
for
kubernetes.
You
can
do
things
outside
kubernetes
equally.
Well,
so
talk
us
about
your
thoughts
on
this.
B
So
let
me
start
by
saying
that-
and
this
is
not
most
people-
do
not
think
this
way.
So
I'm
I
think
that
I'm
still
in
minority,
but
I
do
not
see
primarily
kubernetes
primary
function
being
hey.
I
can
run
your
applications
as
containers
in
on
some
servers
right
to
me.
That's
not
the
first
thing
that
I
think
of
today,
when
I
think
of
kubernetes,
I
think
about
api.
B
I
think
about
it
being
extensible
through
custom
resource
definition.
I
think
about
the
ability
to
detect
drifts
and
reconcile
right
so
and
then
it
hit
maybe
some
of
the
things.
It
will
also
run
its
kubernetes
directly
like
containers,
some
things
it
might
not
right,
but
the
important
part
here
is
extensibility
right.
B
Kubernetes
is
not
supposed
to
be
something
that
you
take
and
you
use
that's,
not
the
purpose
of
kubernetes
kubernetes.
It's
just
a
set
of
building
blocks
that
other
vendors
should
use
to
assemble
a
platform
or
you
can
use
to
assemble
a
platform.
You
take
different
pieces
and
you
have
a
platform
right
now,
if
you
think
of
kubernetes,
not
just
something
that
runs
your
containers,
but
there's
a
way
to
create
a
platform
that
has
certain
capabilities
like
extensible,
api
custom,
resource
definitions,
reconciliation
so
on
and
so
forth.
B
Then
I
will
confidently
say
that
almost
everybody
will
at
one
moment
be
using
kubernetes,
even
though
not
everybody
will
be
running
their
applications
in
kubernetes
right,
which
is
probably
not
what
most
people
think
about
when
they
sit
in
kubernetes
and
the
reason
I'm
saying
that
is,
let's
say
githubs
and
I
have
many
other
examples
we
can.
We
can
talk
about
right.
B
So
for
me
to
run
github's
process,
I
need
to
run
it
in
kubernetes
simply
because
all
the
tools
for
githubs
are
designed
to
run
in
kubernetes
right,
but
that
does
not
mean
that
and
and
for
github
to
run
for
that
getos
process
to
work.
It
needs
to
get
those
manifests
that
are
defined
as
kubernetes
resources
from
git
and
then
apply
it
to
cluster,
and
here
comes
the
important
part
that
manifests
that
you're
starting
it
might
be,
describing
a
database
running
somewhere
else
right.
B
It
could
be
rds
database
in
aws,
it
could
be
whatever
in
google.
It
could
be
elastic
right.
So
what
those
tools
do
is
hey.
This
is
what
is
in
git,
I'm
going
to
tell
kubernetes
to
apply
it
and
then
kubernetes
uses
something
called
controllers.
That
say
hey
for
something
called
victor
I'm
inventing.
Now
there
is
a
con
associated
controller
and
that
controller
does
something
and
that
something
can
be.
I
run
a
container
or
I
run
a
database
outside
of
the
cluster
or
I
create
a
cluster
or
I
create
a
server.
It
can
be.
B
Anything
controllers
can
be
literally
anything
and
that's
where
we
are
going
we're
going
towards
the
world
in
which
kubernetes
orchestrates
everything
not
only
containers
running
so
think
of
kubernetes,
like
orchestrator,
like
an
orchestra
right
thunder
and
you
go
there,
you
go
there.
You
go
do
this,
you
do
that
right.
It's
orchestrator
of
everything,
not
only
applications,
running
kubernetes,
right
and
kind
of
that
happens
to
be
the
project
where
I
work
on
work
with
crossplane,
but
that
would
be
a
separate
subject.
I
guess.
A
Yes,
absolutely
absolutely.
We
definitely
covered
that
in
the
future.
Episode
as
well,
that's
a
very
good
topic
to
discuss,
but
I
think
it's
really
difficult
to
understand
the
what
the
victory
is
telling
at
this
moment
of
time
with
the
beginners
like
me,
but
I
will
accept
the
all
the
things
that
victor
said,
because
his
history
of
telling
these
stories
is
actually
popping
up.
So
you
can
see
you
might
see.
Githubs
are
outside
kubernetes
with
near
future
as
well,
because,
as
you
mentioned
to
the
conversation,
there
are
controllers
in
kubernetes.
A
Some
functionality
is
missing
in
kubernetes,
but
you
can
implement
those
functionality
in
kubernetes
using
those
controllers
and
these
controller.
Previously
you
just
build
your
own
one,
but
now
we
have
tools
available
for
us.
They
can
have
some
controllers
and
they
can
give
give
you
all
these
kind
of
flexibilities.
C
B
Yeah,
so
so
what
ingress
does
I
mean
that's
few
things,
but
the
primary
function
is
to
create
an
external
load
balancer
outside
of
the
cluster,
so
think
about
it
for
a
second
right.
Yes,
nothing
to
do
with
what
is
happening
in
your
cluster.
I
mean
it
has
something
to
do
with
your
cluster,
but
very
little.
B
What
ingress
does
and
kind
of
people
have
been
using
is
actually
managing
resource
outside
of
the
cluster
or
when
you
create
a
persistent
volume
right.
What
does
persistent
volume
that
do
in
your
cluster?
Not
much
the
primary
function
of
persistent
volume
is
to
get
the
disk
from
outside
of
the
cluster
and
attach
it
to
your
containers
right,
so
we
already
saw
for
since
the
very
beginning
of
kubernetes.
B
We
saw
examples
of
kubernetes
doing
things
that
are
not
really
containers
directly
related
but
outside
of
the
cluster
who
external
load
balancer.
Oh
disk,
like
storage
somewhere
else,
it's
just
that
at
the
very
beginning
that
was
kind
of
limited
to
a
few
things,
but
now
that
kind
of,
like
we
are
kind
of
all
settled
into
kubernetes,
now
kind
of
it's
increasing
right
more
more!
B
A
Yes,
absolutely
great
way
to
think
about
it.
I
think
that's
a
great
explanation
for
everyone
really
new
to
this
concept
like
kubernetes
could,
as
the
as
is
doing
some
of
the
stuff
that
it's
not
supposed
to
do,
but
it's
actually
doing
like
csi
or
storage
interfaces.
Like
you
to
talk
about
the
network
interfaces,
then
we
have
a
runtime
interfaces,
so
they
have
some
kind
of
the
best
practices
built
in
it's
up
to
us
to
use
those
best
practices
and
can
do
like
the
black
hole
stuff.
Do
everything
with
kubernetes
it's
up
to
us.
A
If
we
think
about,
we
can
do
everything
with
kubernetes,
we
can
do
it
and
if
you
think
we
not
do
it
that's
another
story,
but
we
can
do
it
a
lot,
a
lot
of
the
stuff
that
as
well
so
the
last
question
before
we
go
to
the
pros
and
cons
of
the
get
offs,
so
people
are
still
deploying
some
of
the
stuff
in
the
azure
aws
gcp
they're.
All
infrastructure
is
all
already
in
there
and
they're
using
most
part
of
the
aks
or
ets
or
gke.
A
That
is
the
most.
I
think
the
audience
is
already
there.
So
how
those
people
you
tell
the
story
like
in
the
githubs,
you
have
the
application
running
in
the
github,
repo
github
repositories
and
your
infrastructure
might
be
living
in
the
aks
or
eks
or
g
key.
So
for
the
people
who
want
to
use
a
git
ops
in
the
cloud
is
there
are
some
challenging?
A
B
No,
there
is
nothing
really
the
only
negative
thing
or
complication.
Let's
say
not
negative
complication
is
how
to
connect
githubs
for
with
the
processes
coming
after
afterwards
right.
So
let's
go
back
to
the
example.
I
said
about
cd
right:
let's
I
said
we
built
we
test
and
then
we
deploy
and
deployment
is
actually
modifying,
git
repository
and
then
the
pipeline
is
finished
and
argos
editor
flux
will
synchronize
stuff
right
now.
Let
me
change
that
scenario
for
a
bit.
Let's
say
that
we
build
and
then
deploy
and
test
afterwards
right.
B
So
our
building
and
testing
is
happening
with
pipelines,
but
deployment
in
a
middle
is
happening
with
different
tools
right
and
and
that's
all
asynchronous,
meaning
that
my
pipeline
does
not
know.
When
argo
cd
will
synchronize
it
might
happen
immediately.
It
might
happen
a
minute
later
right.
So
how
do
I
bridge
that
gap?
That's
the
question
or
a
big
problem,
not
problem,
but
challenge
that
we
have
today.
If
I
build
something
and
then
I
make
changes
to
git-
and
I
don't
know
when
git
will,
argo
cd
will
do
the
stuff.
B
How
do
I
know
two
things?
First,
when
to
run
tests
or
whatever
I
do
after
deployments,
so
when
do
I
do
that
and
second,
a
second
question
is:
how
do
I
do
it,
because
I
cannot
use
the
same
pipeline
build
because
there
is
a
gap.
There
is
a
hole
in
between
right
and
the
answer
to
that
which
is
not
yet
answered
by
industry.
I
believe,
but
we're
getting.
There
is
in
abandoning
the
idea
of
monolithic
approach
to
our
processes,
including
pipelines.
B
So,
instead
of
thinking
you
know,
I
don't
know,
have
you
used
jankies,
for
example,
or
any
of
okay
junkies
right
when
we
use
jenkins-
and
that
applies
to
all
the
tools,
all
the
pipelines
right
or
almost
all
the
way
how
we
do
it
is
that
we
define
a
pipeline.
Now
you
do
this
now
you
do
that,
like
build
test,
deploy
blah
blah
blah
blah
where
we
sh
will
be
going,
is
breaking
that
into
tiny
things,
actions
that
are
executed
as
a
result
of
events
right.
B
We
need
to
think
about
when
this
happens.
I
do
this
and
when
that
happens,
I
do
that
and
when
this
happens,
I
do
something
else.
So
let
me
explain
with
the
example.
Let
me
break
that
simple
pipeline
into
whenever
I
push
something
to
git,
that's
an
event
that
results
in
notifying
something
to
build,
let's
say
container
image,
and
then
I'm
finished
right
and
then
some
other.
B
Instead
of
me
continuing
with
the
pipeline,
then
I
have
a
different
process
that
is
monitoring
my
registry
contender
image
registry
and
saying:
oh,
whenever
somebody
pushes
something
there,
I
should
update
my
git
repository
manifest
and
then
it
stops.
And
then
you
have
a
third
process
that
says
hey
whenever
somebody
updates
the
manifest.
A
A
Misconception
clear,
so
I
will
tell
you,
because
this
up
part
is
also
is
for
the
listener
only
mode
as
well
so
dev
ops
toolkit
you
should
subscribe.
I
think
you
will
land
into
the
victory
channel
as
well.
So
I
think
if,
if
that's
missing,
because
what
you
tell,
I
think,
that's
really
makes
sense
for
me
because
argo
has
argo,
roll
roll
outs,
roll
backs,
argo
heads,
argo,
workflows,
argo
events,
so
argus
all
those
things
it's
up
to
us
to
use
those
things
and
solve
new
challenges.
B
I
like
that,
you
mentioned
the
argo
rollouts,
because
I
think
that
that
would
that
might
better
explain
the
challenge
right.
So,
if
you
think
about
the
process
in
terms
of
I'd
a,
I
do
a
b
c
d
then
park
that
for
a
second
and
now,
let's
talk
about
country
deployments
right
deployment
is
not
just
I
put
this
here.
B
Deployment
is
a
process
that
says
I
will
send
a
bit
of
traffic
to
the
new
release
majority
of
traffic
to
the
old
release,
and
then
I'm
going
to
monitor
how
people
react
and
if
they
like
it.
If
there
are
no
errors,
I
will
increase
the
reach
of
the
new
release
gradually
and
decrease
the
number
of
requests
going
to
the
old
release.
Now.
B
You
have
just
different
events
that
are
happening
at
some
moment
in
the
future.
Argo
rollouts
will
say
finish
successfully
or
at
some
time
in
the
future.
Under
future,
it
will
say
I
rolled
back
or
it
will
say
you
know
what
I'm
hanging
in
the
middle
of
the
process,
for
whatever
reason
right.
So
you
cannot
predict
what
will
happen,
but
what
you
can
do
is
to
have
be
prepared
to
react
to
different
situations,
hey
whenever
argo
rollout
tells
me
that
it
did
x.
B
B
B
A
Yes-
and
I
think
I
think
that
that's
a
wonderful
conversation
like
you,
don't
know
what
actually
is
happening,
but
you
can
prepare
yourself
for
if
something
happened,
you
can
do
this
thing
that
is
actually
viable
for
all
of
the
scenarios,
and
all
of
that
I
think
the
cloud
native.
If
you
look
at
the
cloud
native
landscape,
there
are
some
tools
or
because
this
analogy
is
getting
a
lot
of
attraction
like
two
like
dapper,
k,
native
or
other
tools.
A
They
are
always
based
on
the
eventing
model,
so
I
think
we
see
a
lot
of
the
attraction
going
on
on
on
this
landscape.
So
we
approaching
a
closer
love
talking
to
you,
because
I
don't
want
to
finish
these
this
this
conversation,
because
I
love
talking
to
you,
but
we
are
approaching
an
hour.
So
one
of
the
final
question
before
we
get
the
pros
and
cons
is
we
see
a
lot
of
the
githubs
as
a
service
like
we
see
some
of
the
people
tell
give
you
some
of
the
things
like
this
is
a
sas
platform.
A
B
Well,
all
everybody
else
can
focus
on
whatever
is
their
business
right.
That's
why
I
like
cloud,
that's
like
by
light
services,
because
it
allows
me
to
offload
things
that
I
was
about
to
say,
do
not
matter.
They
matter
but
they're,
not
my
core
business
right.
You
have
no
business
benefit
from
managing
argo
cd
right,
absolutely
it's
necessary.
B
We
need
it
because
it
enables
some
other
things
that
we
do,
but
itself
is
the
same
like
it's
servers,
kind
of
like
nobody
earns
money,
I
mean
some
people
do
earn
money
from
running
servers,
but
majority
of
us,
our
customers,
are
not
paying
us
to
run
service
they're,
paying
us
to
give
them
certain
service
certain,
whatever
we're
giving
them.
So
everything
that
is
not
my
core
business
is
us.
A
A
But
you
are
missing
conversation
about
what
the
core
business
you
look
like
and
when
you
have
tools
available,
you
should
use
that,
like
you
can't
use
kubernetes
by
yourself,
you
use
aks
eks
gk,
that's
probably
fine,
because
in
that
way
you
lift
off
the
burden
of
understanding
the
kubernetes
and
you
will
underst
you
use
inverse
more
time
and
energy.
What
is
running
in
on
top
of
the
kubernetes,
because
that's
important
to
you
and
that
is
actually
your
domain
and
you
need
to
invest
time
on
that.
A
I
absolutely
agree
with
you
on
this
note
as
well,
and
I
hope
what
people
are
listening
to
us
talk
about
this
and
before,
as
we
are
also
the
or
in
the
autelius
project.
We
are
investing
a
lot
of
the
time
in
the
orgo
city
tooling,
or
the
get
off
stooling
and
we
have
the
open
source
community
people
are
watching
watching
this
podcast
or
listening
to
us
join
us
in
the
hoteliers
dot
io.
A
You
see
the
discord
channel
available
for
us
who
can
hang
out
and
ask
them
questions
and
we
hope
to
see
some
videos
on
the
hotelier
side
and
the
victor's
channel
as
well.
I
I
hope
victor
can
look
at
the
repository
afterwards
in
the
hotelious
dash
authilius
and
check
what
we
are
things
things
doing
in
the
in
the
microservices
world
and
tell
us
about
what
we
think
we
what
we
go
wrong
in
there
and
we
need
to
rectify
those
things
as
well.
A
A
We
have
folks
from
the
or
chile,
south
africa,
pakistan,
india,
australia,
new
zealand
and
I
think,
some
from
from
various
other
countries,
a
diverse
open
source
community.
As
of
I
know,
so
I
think
you
should
go
explore
these
of
the
ordinance
content
as
well
and
before
I
let
you
go,
we
have
two
or
three
minutes
more
available
for
us
to
hang
out,
and
this
is
up
to
the
victor.
Tell
us
what
good
and
what
bad
in
the
gators.
B
We
measured
country
deployments
right
if
you
use
flagger
or
argo
rollouts,
and
then
both
of
them
are
coming
from
the
family
of
projects
that
include
githubs
right,
they're,
not
github
stores,
but
when
they
roll
back
they're,
not
running
back
in
a
github
friendly
way
right,
they
just
roll
back
instead
of
pushing
stuff
to
git
and
then
letting
argos
see
their
flags.
Do
it
so
and-
and
that's
only
due
to
time
required
for
us
to
adopt
the
system
there.
A
Absolutely
absolutely
thank
you
very
much
victor
for
being
on
the
show
as
well.
I
always
learned
a
lot
because
I
think
we
have
I've
done
this
very
episode
previously
on
my
channel
cloud
native
fam
today
we're
doing
the
beaming
hoteliers
podcast,
so
everybody
will
watch
listening
to
us.
We
have
a
website,
you
can
listen
or
download
the
podcast
is
available.
A
I
I
hope
you
checked
out
as
well,
and
there
was
one
of
the
very
I've
talked
to
40
plus
guests,
for
the
for
for
a
year
for
doing
the
podcast,
and
talking
to
victor
is
always
feel
I
don't
want
to
end
the
conversation.
I
want
to
talk
about
all
day
all
night
days,
because
because
I
learned
so
many
new
stuff
with
it
and
go
check
that
out,
if
you
are
not,
we
are
not
the
friend
anymore,
because
devops
toolkit
is
a
wonderful
channel.
24K
subscribers.
This
tell
you.
A
The
people
are
going
to
this
channel
and
learning
about
new
things
from
victor
farsik.
It's
been
a
wonderful
way
explaining
this
concept
and,
if
you're
listening
to
us,
not
watching
us
so
dev,
ops,
d,
e
v,
o
p
s
t
double
o
l
k.
I
t
this
is
a
victor
youtube
channel
and
you
should
join
in,
and
these
are
all
the
details
that
we
covered
in
this
podcast
is
all
very
available
as
a
hands-on
material.
A
For
you
go
check
that
out,
it's
been
a
wonderful
stated,
wonderful
show
for
everyone
and
we
hope
to
see
again
victor
with.
There
are
some
various
other
topics.
Victor
can
talk
about
it,
but
we
can.
We
hope,
to
see
another
episode
with
the
victory
as
well
and
also
join
us
here,
enthusiastic
about
contributing
to
the
open
source
contributing
to
the
microservices
or
you
wanted
to
get
your
hand
dirty
or
you
wanted
to
be
a
part
of
the
community
or
driving
effort
into
that
on
the
microsoft
microservices.
So
italians
is
one
that
community.
A
We
have
a
very
good
folks
from
the
different
part
of
the
world
and
you
should
explore
that
github
dot
com,
slash
hoteliers,
ortillas
in
our
repository
and
if
you
want
to
contribute,
want
to
get
started
with
it,
join
the
discord
server
and
we
will
be
there
to
help
you
on
board
with
the
process.
So
thank
you
very
much
victor
hope
to
see
you
again
in
the
future
and
hopefully.
A
It's
going
to
kubecon,
I
think
you
should
should
meet
victors,
I'm
a
wonderful
human
being
always
talking
to
you
in
a
very
good
manner.
You
always
try
enjoy
the
talk
with
him.
Thanks
victor.
What
spent
most
time
with
you
was
your
busy
person
done
very
hard
work
for
the
youtube
and
also
on
the
job
site
as
well,
so
hope
to
see
you
again
in
the
future.
Stay
safe,
stay,
healthy,
bye,
bye,
everyone.