►
Description
Now that cloud providers are offering a managed Kubernetes service it sounds like setting up a new Kubernetes cluster and start deploying applications to, should be easy...but reality is more brutal than that. Even though Kubernetes Service can be offered as a partially managed offering it doesn't mean that cloud provider takes responsibility for everything. It's extremely important to be aware of what you will be responsible for in terms of operating, securing and maintaining managed Kubernetes clusters - and how these changes will affect the rest of your organization. In this session we'll take a look at what you should consider and include in the planning and designing phase (Day Zero) BEFORE going all-in with managed Kubernetes Service. By looking at some real-life examples we'll see what the consequences may be if some of the areas are not planned for or are down-prioritized.
B
Thank
you.
Good
luck.
Thank
you
all
right,
all
right,
hello,
everyone
cool
to
see
that
you
found
the
time
and
to
join
me
today
on
day,
one
of
kubernetes
Community,
Days,
Amsterdam,
I'm
gonna
talk
about
Day
Zero
of
adopting
a
manuscript
at
the
service
and
for
those
who
may
not
know
what
to
manage
kubernetes
service
is.
B
This
is
basically
a
offering
of
creating
kubernetes
clusters
in
Cloud,
for
example,
in
gcp
or
Azure
or
AWS,
and
what
considerations
you
may
need
to
take
when
you
decide
to
adopt
such
a
managed
kubernetes
service,
offering
a
few
words
about
me.
So,
as
I
was
nicely
presented,
my
name
is
Christina
devochko
I'm
based
in
Oslo
Norway
and
I'm
working
as
a
software
architect
and
have
been
working
with
kubernetes
for
more
than
four
years
now.
I
am
also
a
Microsoft
Azure
MVP
and
depart
from
my
full-time
job.
B
I
find
it
really
giving
and
fun
to
contribute
back
to
the
Tech
Community.
That's
why
I'm
here
today,
but
if
we
get
back
to
why
we
are
here,
this
session
came
to
life
because
I
have
been
working
in
the
projects
where
we
have
been
adopting
a
managed,
kubernetes
service
and
one
of
the
projects
where
I
was
involved.
B
We
actually
at
some
point
I,
had
to
postpone
the
production
roll
out
of
our
workloads
hosted
on
manage
to
burn
at
the
service,
and
in
that
case
that
was
AKs,
which
is
azure
kubernetes
service
and
offering
from
Microsoft,
and
we
had
to
get
back
to
the
table
and
do
adjustments
in
order
to
make
that
production
roll
out
really
of
high
quality
and
efficient,
and
this
was
also
based
on
discussions
with
other
teams
and
other
organizations
that
we've
had
and
the
things
they
wish.
They
knew
during
the
initial
phase.
B
The
adoption
phase
of
manage
kubernetes
service,
which
made
this
session,
came
to
life
to
raise
a
bit
more
awareness
about
it,
and
you
can
see
some
of
the
questions
here
that
many
organizations
and
teams
may
be
having
that
could
also
be
related
to
the
existing
misconceptions
and
expectations
that
we
may
have
to
cloud
service
providers.
And
you
may
think
that
if
a
kubernetes
service
offering
is
managed,
then
a
lot
may
be
pre-configured
and
hardened
and
secured
in
a
good
way.
B
B
You
will
need
to
do
quite
some
effort
in
order
to
ensure
that
the
managed
service,
the
managed
kubernetes
service,
is
actually
of
Enterprise
scale
and
production
ready
when
you
deploy
your
workloads
on
it
and
to
set
the
scene
I
guess.
The
most
important
misconception
that
is
important
to
clarify
is
if
Manish
kubernetes
service
is
a
platform
as
a
service
offering,
and
the
fact
is
that
it
isn't.
B
But
I
do
believe
that
it's
equally
important
to
raise
awareness
about
Day
Zero
phase,
which
is
the
design,
the
architecture
and
planning
phase
of
adopting
kubernetes
and
manage
kubernetes
Service
as
well.
And
there
is
a
saying
that
Rome
was
not
built
in
a
day,
but
they
were
laying
brick
by
break
every
hour.
I
guess
that's
more
or
less
the
quote,
and
that
is
applicable
in
case
of
adopting
kubernetes
as
well.
B
You
cannot
Implement
Everything
at
Once
In
A
day,
and
the
approach
will
be
layered
where
you
work
Break
by
break
and
build
that
mature
technical
platform
based
on
kubernetes,
which
will
be
which
will
be
production
ready.
But
if
we
get
more
concrete,
I
have
only
half
an
hour.
Normally
I
do
have
at
least
an
hour
to
go
more
in
depth
and
maybe
even
show
some
demos,
but
it
will
be
highlights
of
the
highlights.
So
what
should
you
think
about
before
going
all
in
with
a
manuscript
kubernetes
service
and
I
want
to
start
with?
B
B
But
if
we
deep
dig
down
a
bit
into
those
success
stories,
we
get
to
see
that
they
were
able
to
succeed
because
they
are
systems,
their
legacy.
Applications
were
already
relatively
distributed
and
they
had
a
collection
of
lightweight
micro
Services,
which
from
before,
had
all
the
necessary
prerequisites
to
be
able
to
just
migrate
them
to
kubernetes
and
get
that
quick
and
fast
scaling
fast
time
to
Market,
more
or
less
out
of
the
box.
B
But
if
you
have
a
legacy
application
that
is
heavier
that
is
potentially
more
monolithic
that
takes
some
time
to
warm
up
than
lifting
and
Shifting.
The
kubernetes
may
not
resolve
those
challenges.
For
you,
and
here
is
an
example,
if
you
think
about
the
image
size,
if
you
decide
to
containerize
your
application,
you
need
to
think
about
the
container
image
size
in
the
end,
it
would
contain.
Okay
include
the
base
image,
the
security
patches
and
updates
that
the
owner
of
the
base
image
pushes
out
continuously
and
the
size
of
the
application
code
itself.
B
On
top
of
that,
so
you
may
end
up
in
a
container
image
of
size,
10
to
11
gigs,
and
if
you
put
warm-up
time
on
top
of
that,
and
then
you
put
that
in
a
kubernetes
cluster
and
try
to
scale,
you
can
imagine
that
you
will
definitely
not
be
able
to
to
get
that
in
an
efficient
manner.
So
you
would
need,
during
the
planning
stage,
evaluate
how
your
current
application
architecture
is.
B
Can
you
move
things
out
and
if
there
is
any
refactoring
that
needs
to
be
done,
and
another
important
point
is
the
technology
strategy
that
you
have
long
term?
Are
you
going
to
be
working
with
a
single
Cloud?
Will
you
have
multi-cloud
approach,
or
will
you
have
a
hybrid
Cloud,
where
you
have
also
parts
of
your
workloads
running
on
premises,
and
this
will
also
Define,
which
kind
of
tools
you
will
be
choosing
going
forward?
B
That
may
need
to
be
Cloud
agnostic,
for
instance,
and
kubernetes
may
not
always
be
the
answer
for
you,
or
at
least
the
managed
kubernetes
service.
So
if
you
have
a
single
instance
of
a
monolithic
application,
for
example,
kubernetes
will
definitely
be
an
Overkill
so
or
if
you
have
just
a
small
amount
of
microservices
one
or
two
just
maintaining
and
operating
those
clusters.
Those
worker
nodes
would
be
an
Overkill,
so
you
could
consider
something
like
serverless
kubernetes,
offering
where
Cloud
providers
do
also
manage
the
worker
nodes.
B
For
you,
it
is
more
of
a
black
box
solution
and
you
may
have
limitations
like
you.
Don't
get
access
to
a
kubernetes,
API
server
direct
access
to
it,
but
this
may
be
enough
for
your
case.
What
the
serverless
kubernetes
offering
can
can
get
you.
So
this
is
important
to
look
into
and
see
what
would
be
the
most
the
most
optimal
choice
for
your
for
your
use
case
and
how
much
time
you
may
need
to
prepare
your
applications
before
eventually
migrating,
to
a
managed
kubernetes
service
and
from
application
Readiness.
B
We
move
more
to
a
people
question
we
move
more
to
an
alignment
in
the
organization
and
another
important,
equally
important
consideration.
You
need
to
work
on,
is
organization,
readiness
and
see
my
awesome
design
skills
I
made
this
animation
just
for
you
today.
The
quote
that
some
organizations,
maybe
the
leadership,
can
often
fall
into-
is
that
we
should
do
kubernetes
because
Spotify
does
it
or
because
so
many
other
organizations
do
it
and
succeed
with
it
and
because
this
is
hot.
B
This
is
what
everyone
is
talking
about,
but
using
that,
as
the
guidance
is
the
wrong
reasoning
for
why
you
should
be
adopting
that-
and
this
is
important
to
talk
about
and
the
line
and
I
think
that
kubermatic
has
a
really
good
quote
about
it.
That
kubernetes
management
requires
making
cultural
shifts
on
steroids,
and
that
is
true,
because
this
is
not
only
you
who
will
who
may
need
to
work
with
those
kubernetes
clusters
and
maintain
them
in
in
the
long
term.
B
B
What
we
have
seen
in
one
of
the
projects
is
that
we
had
applications
that
were
offered
both
in
cloud
and
for
our
on-premises
customers,
and
when
we
decided
to
adopt
manage
kubernetes
service,
we
had
to
do
changes
in
the
application
and
the
way
we
deploy
which
affected
on-premises
customers
directly,
and
we
assumed
that
the
changes
are
of
no
significance.
I
mean
they
can
just
fix
it.
B
They
can
set
up
what's
needed
in
the
infrastructure
to
adopt
for
those
changes,
but
when
our
customer
success,
teams
and
sales
teams
came
into
picture,
we
realized
that
alignment
was
missing
there
and
we
used
much
more
time
to
ensure
that
those
customers
are
properly
prepared
and
negotiated
with
them
in
order
to
ensure
that
they
were
also
okay
with
these
changes.
If
we
did
it
from
the
start,
if
we
ensured
that
the
sales
and
customer
success
teams
also
understood
how
these
changes,
technical
changes
will
affect
them,
we
would
have
used
much
less
time.
B
This
is
what
happens.
It
is
blurred,
but
it
does
not
matter
here.
So
what
you
can
see
here
are
two
applications,
two
microservices
that
did
not
have
any
resource
and
request
limits
set
at
all
and
they
sneaked
their
way
in
into
the
cluster.
Fortunately,
this
cluster
was
not
a
production
cluster,
but
what
you
can
see
here
are
lots
of
pods
in
the
evicted
terminating
crash
loopback
of
State.
This
caused
quite
some
chaos
and
almost
a
cardiac
arrest
for
some
of
our
operations
resources,
and
this
is
not
the
developer's
fault
they
met.
B
So,
during
the
planning
phase,
it
is
worth
looking
into
how
you
can
abstract
that
complexity
away
from
the
developers,
and
we
have
seen
also
that
just
providing
the
links
to
the
documentation
or
to
tutorials
was
not
enough,
but
when
we
had
those
Hands-On
workshops
with
concrete
scenarios.
Okay,
we're
gonna
containerize
this
application.
Now,
let's
do
it
together
and
you
are
doing
it
live
together
with
them.
B
And
lastly,
we
do
hear
a
lot
about
githubs
these
days.
This
is
kind
of
the
golden
standard
of
deployment
to
kubernetes,
where
you
have
your
Source
repository
as
a
single
source
of
truth,
and
you
have
that
model
where
the
cluster
pulls
changes.
Every
time
the
Rainy
change
has
been
merged,
but
I
think
it's
also
important,
like
Shakespeare
potentially
said,
to
beat
ups
or
not
to
githubs.
That
is
the
question.
It's
important
to
say
that
githubs
will
not
resolve
the
bottlenecks
you
may
have
in
the
organization
currently.
B
So
if
you
don't
have
in
a
high
enough
level
of
automation
to
ensure
that
you
have
the
automated
tests,
the
automated
Security
checks
and
gates
in
place
from
before
that,
githubs
will
not
help
you
resolve
it.
It
may
create
more
more
challenges.
So
the
point
is
that
you
should
know
that
you
can
always
start
without
githubs
from
the
start,
with
the
starting,
with
the
bear
minimum
and
building
that
maturity
over
time
as
you
evolve
and
get
more
skills
with
operating
kubernetes.
B
We
might
not
start
doing
the
remediation
and
we
may
have
ended
up
in
going
long
over
the
budget
and
having
that
budget
limit.
That
also
alerts
you,
if
you
keep
doing
like
this,
you
will
end
up
so
so
much
over
budget
having
that
could
really
help
you
and
make
your
leadership
happy
as
well,
because
savings
is
always
good,
and
here
is
also
one
of
the
examples
that
I
took
from
Azure.
That
is
also
worth
keeping
in
the
back
of
your
head.
Here.
B
B
Another
example
is
the
region
here
is
a
comparison
of
North
Europe
versus
West
Europe
and
versus
Norway
East,
and
these
are
Norwegian
Chronos,
but
if
we
convert
it
to
two
Euros,
if
you
choose
a
b2s
which
I
highlighted
there,
which
is
also
a
virtual
machine,
you
if
you
choose
North
Europe,
would
need
to
pay
280
the
kroners
versus
300
or
339
for
Norway
East.
If
you
can
use
a
region
that
is
potentially
cheaper,
not
violating
any
laws,
privacy
laws
and
compliance
Frameworks,
that's
worth
considering
and
now
getting
trying
to
cover
it
quickly.
B
B
Oh,
you
are
right
on
top
there.
This
is
the
amount
of
exposed
kubernetes
clusters
worldwide,
that,
as
you
can
see,
in
June
2022,
cyber
research
lab
did
a
scanning
worldwide
on
the
most
known
endpoints
that
can
kubernetes
clusters
Expose,
and
this
is
not
that
far
from
a
million
clusters
worldwide.
This
is
insane
and
in
some
cases,
if
you
think
again
as
I've
been
mainly
working
with
AKs,
so
I
know
most
about
it
by
default,
its
API
server
is
searchable
by
default.
So
you
can
you
can
reach
it.
B
You
get
an
unauthenticated
response
back,
but
you
still
have
that
attack
surface.
That
attackers
can
check
and
work
towards.
So
having
that
in
mind,
starting
with
these
most
crucial
steps
like
limiting
access
to
your
cluster
following
the
least
privilege
principle,
ensuring
that
you
have
our
role-based
Access
Control
in
place
is
important
and
also
running
containers
as
root.
We
know
that
this
is
a
No-No,
but
it
is
not
always
easy.
Here
is
an
example
of
a.net
core
asp.net
core
based
image
that
actually
does
not
provide
a
possibility
to
run
with
as
non-root
by
default.
B
So
you
would
need
to
make
some
changes
in
order
to
accommodate,
for
that
and
implementing
Security
checks
should
happen
continuously
during
the
whole
development
life
cycle
process.
Unfortunately,
some
Frameworks
out
there
could
help
us
achieve
that,
and
it's
worth
looking
into
those
Frameworks
from
the
start,
because
customers
will
keep
running
and
some
of
them
are
really
curious
and
they
would
need
proof
that
your
new
solution
is
compliant
with
those
Frameworks.
Now
what
is
good
is
that
some
of
them
do
provide
concrete
examples
on
how
you
can
mitigate
and
implement
this
and
that
security
control.
B
Lastly,
quickly
quickly
in
two
minutes,
I'll
I'll
do
that
I'll
still
try
to
sneak
in
a
day
two
operations
here
and
the
fact
that
things
will
fail-
and
this
is
also
something
that
is
worth
thinking
about
and
planning
for
from
the
start.
This
is
an
example
of
an
outage
in
one
of
the
regions
of
AWS
that
happened
both
in
December
2021
and
July
2022,
where
multiple
big
Services
were
experience
downtime.
B
This
is
an
example
of
a
faulty
update
that
Azure
has
rolled
out
to
their
Linux
virtual
machines.
That
also
caused
quite
a
few
outages
and
especially
AKs
being
affected
a
lot
by
that.
So
having
that
disaster
recovery
and
important
things
like
observability
multi-region
deployment,
even
chaos,
engineering
which
could
help
you
simulate,
these
situations
would
really
help
and
don't
rely
on
cloud
vendors
and
having
operations
team
that
will
take
that
responsibility.
B
B
Do
the
change
for
the
right
reasons,
do
adopt
kubernetes
and
manage
kubernetes
service
if
it
brings
value
to
you
and
your
customers
do
not
underestimate
the
day,
Zero
the
planning
stage,
to
ensure
that
you
don't
need
to
get
back
and
do
a
lot
of
rework
afterwards.
Do
you
invest
time
in
that
start
small
and
expand
building
Brick
by
Brick
with
everyone
who
needs
to
be
involved
by
to
build
that
mature
platform?
B
Have
that
common
ownership
so
that
you
will
not
be
the
only
one
operating
kubernetes,
because
then
you
can't
be
sick
or
go
on
vacation.
You
would
need
to
have
others
understand.
Kubernetes
understand
how
everything
works
in
that
ecosystem,
so
that
they
can
step
in
shift
left
not
only
on
security
on
everything
and
prepare
for
the
things
will
fail
and
my
hearty
recommendation
to
not
forget
the
resource
and
request
limits.
B
If
you
don't
want,
if
you
want
to
take
care
about
your
kubernetes
administrators
and
once
you
have
done
all
that,
you
are
good
to
go,
you
have
a
full
operational
kubernetes
clusters
running
in
cloud
or
elsewhere.
You
get
all
the
resources
in
this
GitHub
repo.
If
you
want
to
find
more
about
it
and
do
reach
out
to
me,
and
if
you
have
any
questions,
I'll
be
happy
to
help
you
out
either
here
or
after
afterwards.
So
thank
you.