►
From YouTube: Your own Kubernetes castle: Building the production ready Kubernetes cluster with open source bricks
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
A
So,
let's
think
about
the
topic
I
put
there
why
a
castle,
so
I
imagine
that
the
production
cluster
is
very
similar
in
properties
with
medieval
castle,
and
why
is
that?
I
think
they
shared
the
common
requirements.
When
someone
was
building
a
castle,
it
was
built
for
years.
It
wasn't
just
a
temporary
project
which
was
meant
to
work
only
a
few
weeks
or
a
few
months
and
then
be
destroyed.
A
A
A
You
need
to
install
the
supporting
components
which
help
with
the
topics
that
are
not
handled
directly
by
the
kubernetes
like
storing
and
displaying
clocks,
storing
and
displaying
metrics
or,
for
example,
just
the
automation
for
cicd
and
the
last
topic,
which
is
rather
important
and
also
shared
between
the
castle
and
kubernetes
production
cluster.
Is
that
accents.
The
access
to
the
castle
depended
in
the
medieval
era
on
your
role
in
the
society.
A
Is
the
dependency
which
says
what
you
can
do
in
the
cluster?
So
if
you,
if
you
are
an
admin,
you
can
create
any
kind
of
resources
like
you
can
can
do
anything
in
the
castle.
But
if
you
are
just
a
developer,
maybe
you
are
not
able
to
configure,
for
example,
ingresses
or
storage
classes,
so
it
really
depends
on
your
group
or
your
role.
A
So
that's
first
part
of
the
topic,
but
there
is
also
a
second
part
why
the
open
source
and
why
the
open
source
components,
so
the
open
source
is
a
rather
broad
term.
It
may
refer
to
the
distribution
model,
to
the
license
or
just
the
open
source
movement
and
to
describe
why
open
source
I
will
use
the
definition,
which
is
the
open
source
model,
is
decentralized
and
focused
on
open
collaboration,
because
this
is
why
I
picked
the
open
source
when
you
use
the
open
source
components.
A
It's
based
on
the
open
collaboration.
Anyone
can
make
a
change.
Anyone
can
propose
the
change,
create
a
pull
request.
Not
all
of
the
pull
requests
are
accepted,
but
this
is
not
just
the
end
of
the
word.
You
always
can
create
a
fork
either
for
your
own
use
or
share
it
with
the
community
and
use
that
solution
in
your
product.
So
it's
not
closed
source.
You
can
anytime
make
any
change
and
just
alter
it
for
your
needs.
A
There
is
a
community
collaboration.
People
are
trying
to
solve
the
issues.
It's
not
just
a
single
person
trying
to
to
make
it
all
work.
There
are
even
companies
sharing
the
source
code
and
helping
with
the
development
of
open
source
tools
and
the
affordable
pricing.
It
sounds
a
little
bit
funny
because
in
most
cases
we
think
about
the
open
source
as
a
free
tool
and
in
most
cases
it
is
free.
A
A
A
A
So
in
this
presentation
I
will
show
you
a
multiple
different,
open
source
tools
and
components
which
I
would
recommend
for
using
in
your
kubernetes
production
environments.
But
how
did
I
select
them?
So
all
of
them
were
tested
by
greypop
and
by
me
in
our
projects,
and
they
are
proven
to
work
great
in
the
production
clusters.
A
A
Okay,
so
let's
start
with
the
first
topic,
observability
and
what
I
mean
by
observability,
so
observability
is
an
ability
to
make
sure
what
happens
inside
your
cluster.
So
the
core
components
for
that
which
we
will
go
through
later
are
locks
matrix
and
the
network,
which
was
which
is
observable
through
the
service
mesh,
for
example.
A
So
those
are
three
important
aspects
of
observability
and
why
do
you
need
observability?
Obviously,
you
need
to
always
know
what
happens
in
your
cluster
when
it's
in
production,
you
need
to
make
sure
that
it's
operating
correctly,
you
need
to
make
sure
you're
getting
alerts
when
something
might
get
wrong
in
the
nearby
future
or
just
happened
wrong
a
moment
ago.
A
So
the
first
one
will
be
logs
and
for
locks.
I
put
or
selected
two
components.
Two
systems
one
is
elk,
which
is
elastic,
search
log
station
kibana
and
the
name
may
be
also
the
often
used
name
is
also
efk,
which
is
elasticsearch
fluently
kibana,
and
this
is
a
widely
used
tool,
very
common,
very
popular,
very
capable
of
handling
extremely
large
amounts
of
logs
and
and
storage,
but
also
quite
complicated
with
the
configuration,
especially
if
the
configuration
has
to
be
so
highly
available,
and
you
store
a
lot
of
locks.
A
It
might
be
rather
complicated
to
configure
elk
if
you
have
no
experience.
The
huge
advantage
of
it
is
the
query
language
which
provides
an
ability
for
the
full
text
search,
which
is
not
that
common.
This
is
something
which
elk
is
great
with,
and
this
makes
searching
clocks
much
easier
than
some
of
the
other
tools,
the
disadvantage
of
the
elk
itself.
Maybe
it's
not
a
huge
disadvantage.
A
It's
just
the
small
limitation
that
the
security
is
not
part
of
the
open
source
part,
but
there
is
a
workaround
for
that
which
is
called
the
open
disk
show.
It
was
created,
I
think,
by
amazon,
and
this
is
a
version
which
extends
the
the
basic
tool
set
with
the
security
and
other
important
tools
which
are
not
present
in
the
basic
installation.
A
It's
very
easy
to
install
too
the
disadvantage
of
it
is
it's
much
simpler.
It
doesn't
have
the
visualization
that
kibana
has
for
the
matrix
and
the
query.
Language
is
very
similar
to
the
prometus
query
language,
and
this
means
it's
limited.
It's
not
the
full
text
search,
it's
just
it's
more
like
regex,
so
it
is
limited
in
this
in
this
case,
and
it
might
be
harder
to
find
the
lock
you
are
looking
for,
but
both
are
great.
A
The
prometus
is
a
tool
which
gathers
and
stores
the
metrics,
so
this
is
like
a
pull
or
push
model
depending
on
the
configuration
and
the
metrics
are
stored
in
the
tsdb,
which
is
a
database
holding
the
metrics
sorted
by
a
timestamp,
so
time
series
db
and
to
see
the
matrix
to
see
the
dashboards
and
display
them
for
the
user.
There
is
a
grafana
which
is
very
nice
tool,
highly
configurable
for
creating
dashboards,
and
it
reads
directly
from
prometus,
so
it
doesn't
really
require
a
lot
of
storage
and
a
lot
of
database.
A
A
A
A
A
So
for
the
thanos
there
are
more
primitives
instances,
but
smaller
ones.
Cortex
is
a
single
big
one
and
the
this
is
also
different
from
the
query
perspective
and
the
storage
perspective,
because
thanos
has
to
query
all
the
promote
uses
and
then
gather
the
results
which
it
has
a
great
great
code
for
for
making
queries
and
the
final
system,
which
makes
it
very
very
fast
when
the
cortex
has
a
centralized
storage.
A
A
A
I
think
it's
the
most
popular
service
merch
right
now,
and
it
has
a
lot
of
examples
and
code
snippets
and
a
lot
of
stuff
already
built
in
especially
in
terms
of
documentation
and
the
articles,
and
it
has
a
multi-cluster
support,
but
compared
to
linker
d,
is
slightly
less
performance
than
istio
that
it's
slightly
less
performant
than
linkardi
when
the
traffic
is
high.
So
there
are
high
loads
of
large
amounts
of
data
being
transferred.
A
So
the
next
topic
is
automation
or
continuous
integration,
delivery
and
each
cloud
native
solution.
Each
production
cluster
has
to
consider
this.
This
aspect
of
deploying
and
developing
applications
so
making
sure
the
builds
are
reportable
and
observable,
and
also
proper
version
control
and
for
production
clusters,
mainly
the
application
delivery
system,
which
is
also
reliable.
A
A
So
in
theory
this
is
rather
easy
concept,
but
there
are
caveats
that
are
very
hard
to
solve,
like,
for
example,
the
secrets.
The
secrets
are
not
really
safe.
In
kubernetes,
if
you
store
them
as
a
secret
because
they
are
not
encrypted
by
default,
and
so
the
githubs
has
to
read
this
secret
somewhere
and
you
shouldn't
put
it
them,
obviously
in
each
repository.
A
A
A
So
so
the
argo
technically
supports
the
the
multi-cluster
design,
while
the
flux
is
able
to
only
read
one
remote
repository
and
one
target
cluster.
So
that's
a
limitation,
but
not
a
big
one,
because
in
most
cases
you
can
live
with
just
having
one
with
flux
in
the
in
your
cluster
and
also
it's
not.
It
doesn't
have
an
ui,
but
it
has
a
nice
cli
for
management.
A
So
for
the
continuous
integration
I
picked
two
tools,
it's
jenkins
and
the
conkers,
and
both
of
them
are
great.
The
jenkins
is
widely
used.
It
has
a
huge
adoption.
I
think
almost
every
company
or
every
developer
have
used
the
jenkins
at
some
point
of
their
of
their
journey
and
it
has
tons
of
plugins
available.
A
The
next
important
topic
for
your
cluster
is
the
ingress
controller
and
what
is
ingress
controller?
Let's
start
with
that.
Ingest
controller
is
a
combination
of
load
balancer
and
a
proxy
which
is
responsible
for
reading
the
kubernetes,
ingress
resource
or
object
and
based
on
those
objects.
It
draws
the
traffic
incoming
traffic
for
your
cluster
to
a
specific
service
or
set
of
or
set
of
services.
A
A
A
A
A
Additionally,
the
authentication
part
like
basic
authentication
can
be
configured
using
the
the
kubernetes
ingress
controller
and
the
two
alternatives.
I
picked.
The
traffic,
which
has
now
version
two
and
he
proxy
and
the
traffic
advantage
is
it.
It
has
a
very
nice
user
interface,
so
if
you
need
to
quickly
look
at
what's
wrong,
what's
going
on
in
in
in
the
ingress
controller,
the
traffic
is
great.
For
that
you
have
an
e
easy
to
use
user
interface.
A
So
when
it
was
switched
from
version
one
to
version
two
is
it
lost
support
for
some
of
the
features?
I
think
they
might
just
add
them
later
on
in
the
in
the
development,
and
it
supports
the
native
resources
native
ingress
resource,
but
it
also
uses
its
own
crds,
which
is
slightly
confusing
when
you
just
start
from
there
and
the
hd
proxy
alternative.
A
I
put
it
here
because
it's
very
performant
compared
to
any
other
ingress
controller
from
some
of
the
tests
and
some
of
the
comparisons
it
may
be,
even
the
most
performant
load
balancer.
It
has
a
lot
of
configuration.
You
can
configure
a
lot
of
things,
but
it
doesn't
have
a
user
interface
and
the
configuration
may
be
slightly
harder
than
the
kubernetes
and
traffic
ones,
because
there
is
less
less
resources
available
for
that.
A
A
A
So
first
important
topic
is
open,
id
or
oidc
open
id
connect
provider
and
those
providers
are
just
identity,
layer
for
verifying
end
users,
authentication
by
using
external
authorization,
provider
or
third
party,
and
both
of
them
are
very
easy
to
use-
and
it's
just
nice
to
have
the
open
id
or
oidc
provider
inside
your
cluster,
because
you
can
easily
change
the
third
party
which
is
used
for
authorization
and
verifying
the
identity
of
the
user.
So
that's
great-
and
here
I
picked
two
of
them
and
they're
also
very
similar.
A
The
dex
is
just
a
simpler
tool
than
the
key
cloak.
It's
easy
to
use.
It's
simple:
it's
just
the
oidc
proxy,
so
it
processes
your
authorization,
authentication
requests
to
the
other
other
provider,
but
it
has
a
slightly
limited
capabilities
compared
to
kick
lock
and
it's
just
a
proxy.
No
automation,
no
custom
claims
nothing
like
that.
It
just
process
your
requests,
but
if
you
need
more
than
dex
provides,
you
can
use
the
key
clock
which
is
very
extensible
and
advanced
in
configuration,
and
it
has
an
ui.
A
A
So
as
long
as
the
backup
works
it's
tested
once
initially
or
even
not
that-
and
this
is
all-
and
the
backup
and
restore
toolkit
is
probably
the
most
important
part
of
your
production
ready
deployment,
because
you
cannot
rely
on
the
fact
that
what
you
created
is
so
great
it's.
It
will
survive
any
kind
of
disaster,
the
underlying
infrastructure,
like
aws
cloud
or
or
azure
cloud,
it's
so
resilient.
A
It
doesn't
fail
that
often,
but
there
is
a
very
small
chance
that
it
may
fail
and
if
the
underlying
infrastructure
fails-
and
you
have
no
backup-
you
have
a
very-
you-
have
to
have
a
very
great
disaster
recovery
plan
to
recover
from
that.
And
you,
if
you
have
a
backup,
it's
just
as
easy
as
restoring
the
backup.
A
The
bigger
problem
is
that
how
to
configure
the
backup
and
restore
correctly,
especially
if
you're,
using
either
on-premises
kubernetes
deployment
or
it's
using
the
not
so
widely
used
and
supported
cloud
because,
for
example,
some
of
the
clouds
like
eks
they
they
use
for
the
persistent
volumes.
The
this
storage
did
the
volumes
from
the
cloud
provider
which
are
which
can
be
configured
to
be
backed
up
automatically
but
by
the
by
the
provider.
A
But
then
you
might
need
to
copy
the
data
somewhere
else.
In
case
something
happens
with
that
provider
and
the
valero
is
a
solution
which
is
in
most
cases
independent
on
the
provider,
because
it
has
a
support
for
all
common
clouds.
Like
aws
azure,
google
cloud.
You
can
think
of
anything
like
that,
but
it
also
has
a
tool
built
in
which
is
called
rustic,
which
allows
to
make
an
image
of
the
persistent
volume
which
is
not
supported
directly
by
the
valero.
A
The
disadvantage
is
that
it
doesn't
have
an
user
interface,
it's
probably
not
the
biggest
disadvantage
in
the
world
and
the
backup
metadata
is
start
without
versioning.
So
sometimes
you
might.
You
may
be
able
to
break
the
mechanism
by
just
removing
the
file
by
mistake
or
altering
the
file.
So
it's
not
really
recommended,
but
just
make
a
backup
of
your
backup
tool,
let's
say,
but
there
is
also
an
alternative
which
is
not
an
external
tool
but
a
part
of
kubernetes
itself.
A
A
But
if
you
are
able
to
run
the
volume
snapshots,
it's
a
great
solution,
because
it's
native
it's
supported
by
natively
by
kubernetes,
it's
easy
to
configure.
You
can
configure
the
backups
as
a
part
of
your
cluster
configuration
and
it's
natively
supported
by
the
csi
driver.
So
there
is
no
external
tool
for
monitoring
like
valero
to
make
sure
it
works.
So
if
it
works,
it's
controlled
by
the
kubernetes.
A
What
is
open
policy
agent?
It
is
a
tool
which
supports
the
maybe,
let's
say
the
different
way.
Open
policy
agent
is
a
tool
which
extends
the
role-based
access
control
abilities
with
role-based
access
control.
You
are
able
to
configure
for
specific
user
or
group
of
user.
What
they
can
do
and
anything
you
don't
configure
is
just
denied.
A
So
this
is
only
it's
kind
of
a
white
listing
way
of
configuring,
the
security
and
only
based
on
raw
resources
of
kubernetes.
So
you
can
say
the
user
is
able
to
create
a
deployment.
The
user
is
able
to
create
a
pod.
The
user
is
able
to
delete
or
update
the
ingress,
but
you
are
not
able
to
say
user
is
able
to
create
a
deployment
which
only
contains
a
single
pot.
A
So
this
is
not
possible
we've
with
airbag,
but
this
is
possible
with
the
open
policy
agent
and
the
gatekeeper
tool
which
is
used
by
it
and
what
the
open
policy,
agent
or
opa
does
it
provides
and
system
a
component
which
can
verify
the
policies
written
in
the
regal
language
versus
the
json
documents,
and
this
tool
is
configured
through
web.
You
can
configure
the
open
policy
agent
or
gatekeeper
as
an
admission
webhook
in
kubernetes,
and
then
each
change
to
the
cluster
is
sent
to
opa
and
to
be
verified
if
it
should
be
accepted
or
denied.
A
A
So
that's
into
that!
That's
all
for
that
topic.
I
hope
you.
You
have
learned
something
about
those
tools
and
you
have
seen
that
the
open
source
may
not
seem
initially
as
a
greatest
solution,
but
it
contains
everything
you
need
to
create
a
working,
reliable
and
secure
kubernetes
production
ready
cluster.