►
From YouTube: Keynote: Fair Share - What Shared Responsibility Means for Managed Kubernetes Cluste...Mickey Boxell
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2023 in Amsterdam, The Netherlands from April 17-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.
Keynote: Fair Share - What Shared Responsibility Means for Managed Kubernetes Clusters - Mickey Boxell, Principal Product Manager, Oracle
Managed Kubernetes offerings provide users with a simple way to automatically deploy, scale, and manage Kubernetes - generally everything you need to quickly deploy a production ready Kubernetes cluster. However, as a cluster operator, you are responsible for more than simply deploying containerized business logic. When you adopt a product with a managed life cycle you need to know what exactly to plan for: more specifically, where does your responsibility end and where does the provider’s responsibility start? When new Kubernetes versions are released, is it your responsibility as an operator to update your control plane? How about your worker nodes? The nature of Kubernetes as a tool with a control plane and a data plane further complicates things. For example, users generally are not responsible for managing and operating control plane components including kube-apiserver, kube-controller-manager, kube-scheduler, or etcd, but worker nodes generally exist in user tenancies and because nodes execute private code and store sensitive data providers’ access is limited. This talk will explain the support boundaries and shared responsibility of a managed Kubernetes service through the eyes of a cloud provider. It will advise users where to look for information about the parts of their system in need of care and feeding and those that can be comfortably trusted to a knowledgeable provider.
A
I
just
said
my
name
is
service.
Some
folks
here
may
also
know
me
from
the
kubernetes
release
team
as
well.
I
thought
a
lot
about
what
I
wanted
to
get
up
here
and
talk
about,
and
you
know
instead
of
talking
about
HPC
on
the
edge
I
wanted
to
talk
about
something
that
impacts
all
users,
which
is
the
notion
of
shared
responsibility
in
kubernetes,
so
kubernetes
itself
has
been
around
for
eightish
years
and
managed
kubernetes
services
like
Oracle
container
engine,
but
then
also
gke,
AKs
eks
have
been
around
for
about
half
a
decade.
A
Now
these
services
are
old
enough
that
if
they
were
a
human
child,
they'd
be
able
to
use
sentences
with
more
than
four
words
use
scissors
with
supervision
and
most
excitingly
stand
on
one
foot
for
a
few
seconds,
but
in
spite
of
their
maturity,
there's
still
a
lot
of
confusion
over
who
owns
what
within
an
environment
and
more
tangibly.
This
translates
to
who's
responsible
for
the
daily
toil
of
activities
like
patching
and
other
operation
and
management
tools.
A
So
the
concept
of
shared
responsibility
is
something
that
we
all
face
when
evaluating
Cloud
providers,
and
it
applies
to
every
single
provider
and
also
our
daily
operations,
simply
put
it's
understanding
what
Falls
to
you
as
the
end
user,
and
what
you
can
trust
to
some
other
group
or
organization
in
an
on-premise
data
center.
This
is
so
straightforward.
You
know
you
own.
A
The
whole
stack
you
own,
the
hardware
you
own,
the
software
and
there's
no
question
of
ownership,
but
as
you
move
to
the
cloud
some
of
these
responsibilities
transfer
over
to
your
provider,
and
these
differ
depending
on
the
service
or
services
that
you're
using
and
so
whether
you're
deploying
a
WordPress
site
or
something
more
complex.
Like
an
HPC
workload,
it's
really
important
to
understand
what
that
shared
responsibility.
Model
looks
like
now.
A
It
goes
without
saying:
kubernetes
is
not
straightforward
and
I
would
say
that
the
kubernetes,
the
complexity
of
kubernetes,
makes
this
task
both
more
tricky
and
also
more
important
to
figure
out.
There
are
a
lot
of
different
dimensions
to
consider.
So,
to
begin
with,
you
have
to
figure
out
what
kind
of
kubernetes
environment
you're
deploying.
Is
this
something
that
you've
deployed
directly
onto
a
provider's
infrastructure,
their
networking
resources,
their
compute,
their
storage?
Or
is
this
something
you've
deployed
instead
to
a
managed
service?
A
Also,
you
know
then
there's
the
action
you're
trying
to
perform.
Are
you
configuring,
identity
and
access
management,
monitoring
scaling?
You
know
what
of
these?
Are
you
trying
to
think
about
the
the
shared
responsibility
for
and
then
finally,
you
have
to
think
about
the
actual
components
of
the
cluster,
the
data
plane
and
the
control
plane
and
just
as
a
refresher
here
are
some
of
the
cluster
components
you
have
to
think
about
and
I
realize
this
is
a
bit
of
an
arc
eye
chart,
but
that's
kind
of
the
point.
A
The
left
side
is
commonly
referred
to
as
a
control
plane.
It
consists
of
the
qapi
server
cloud,
controller
manager,
Cube
controller
manager
at
CD,
Etc
and
the
right
side
is
the
data
plane.
It's
the
actual
nodes
where
your
workloads
run
and
so
different
types
of
kubernetes
services
will
offer
different
levels
of
shared
responsibility.
With
each
of
these
sections
of
your
environment.
A
A
You
know,
of
course
you
can
do
things
like
set
feature
Gates
on
the
API
server
to
test
out
new
Alpha
features,
whereas
if
you
had
the
control
plane
managed
by
a
provider,
you're
then
trading
that
flexibility
for
additional
responsibility
for
folks
using
managed
Services
the
responsibilities
for
owning
and
maintaining
the
control
plane
are
largely
completely
removed
from
you.
You
don't
have
to
think
about
the
cube
API
server,
but
it
does
come
at
the
you
know,
sort
of
drawback
of
not
having
access
to
Greater
control
over
those
flags.
A
Users
can
further
reduce
the
operational
burden
by
doing
things
like
using
virtual
nodes.
This
might
be
fargate
or
Oracle
virtual
nodes
or
gke
autopilot,
which
removes
the
need
to
you
know,
go
one
step
lower
and
manage
the
OS
level
patching
or
kubernetes
updates
or
scaling,
but
depending
on
your
provider,
this
also
comes
with
limitations.
Again.
A
You're
trading,
flexibility
for
increased
responsibility
and
the
ultimate
step
and
I
won't
talk
about
this
too
much
because,
of
course,
we
are
at
a
kubernetes
conference,
is
to
just
abstract
away
the
cluster
altogether
and
use
something
like
container
instances
or
the
AWS
elastic
container
service.
These
remove
the
kubernetes
API
from
the
picture.
They
require
you
to
do
all
of
your
own
orchestration,
but
you
also
can
be
very
agile
and
just
deploy
your
business
logic
without
having
to
think
about
the
cluster,
as
I
mentioned
before.
A
There's
also
all
these
activities,
you
have
to
consider
here's
a
non-exhaustive
list.
You
know
some
of
the
ones
up
here.
Maintaining
your
workloads,
including
application
code,
build
files,
container
images
and
data
doing
things
like
configuring,
role-based,
Access
Control.
Maybe
it's
hooking
it
into
a
provider's
identity
and
access
management
system.
Also,
monitoring
the
cluster
is
something
you
have
to
think
about
as
well.
A
Some
folks
do
a
great
job
of
having
monitoring
tools
set
up
right
out
of
the
box,
whereas
other
ones
force
you
to
do
this
yourself
and
then
also
of
course,
node
node
upgrades
and
control
plane
upgrades
both
of
the
host
image
and
also
of
kubernetes
versions.
The
reason
this
is
up
here
is
just
to
show
that
the
number
of
items
to
keep
track
of
can
feel
very
overwhelming.
A
Thankfully,
most
providers
do
a
great
job
of
documenting
these
shared
responsibilities,
and
this
applies
both
to
the
underlying
infrastructure
and
also
the
respective
managed
kubernetes
service.
Here
are
some
examples
from
Oracle,
Microsoft
and
Google.
These
are
the
official
documented
support
boundaries
of
managed
kubernetes
providers
seen
Through
The
Eyes
of
those
providers.
So
there's
no
real
guesswork
here.
There's
no,
you
know:
division
of
labor
there's
no
like
fuzzy
boundary.
A
Now,
if
there
are
things
that
are
not
covered
in
the
documentation,
for
example,
you
know
is
this
third-party
tool
supported
this
open
source?
You
know
very
esoteric
project
that
I
just
found
on
GitHub.
Well,
the
answer
often
is
that
it's
probably
not
going
to
be
in
the
documentation.
These
are,
of
course,
going
to
be
non-exhaustive
because
there's
just
so
much
that
goes
into
kubernetes
environments,
but
if
you're,
finding
yourself
in
that
situation,
I
would
recommend.
A
A
So,
to
recap
the
first
step
is
to
know
your
environment.
Then
it's
to
determine
the
components
of
the
cluster
that
you
are
are
going
to
work
on
and
the
activities
you
want
to
perform
next
up
is
checking
your
provider's
documentation.
You
know
for
folks
that
have
not
thought
about
any
of
these
things
before
that
have
not
thought
about
shared
responsibility.
This
might
be
the
time
to
do
it.
A
You
know
really
see
what
you
can
offload
on
your
provider
versus
what
you
should
pull
into
yourself,
and
also
these
are
great
tools
for
assessing
which
provider
which
service
you
want
to
use.
You
know,
maybe
container
instances
are
the
level
of
support
that
you
need
from
a
provider
and
you
don't
care
about
the
kubernetes
API
or
maybe
you
have
the
opposite
use
case,
and
you
want
to
deploy
directly
to
Providers
infrastructure
yourself.
These
are
great
questions
to
sort
of
introspect
your
workloads
and
think
about
what's
appropriate
for
you
and
your
use
case.
A
Also
again,
if
there's
any
fuzzy
boundaries,
please
feel
free
to
ask
questions.
Customer
support
it's
one
of
their
functions
and,
finally,
just
make
sure
you
know
your
shared
responsibilities,
because
these
are
things
that
are
going
to
make
your
day-to-day
toil
a
lot
better
if
you
can
remove
a
few
of
them
cool.
Thank
you.