►
Description
Keynote: What is Kubernetes? - Brian Grant, Principal Engineer, Google
Kubernetes has been described many different ways. How should one think about the platform? It partly depends on the problems you are trying to solve with it. I will discuss 10 ways to view Kubernetes based on use cases, how those uses relate to its features and architecture, how Kubernetes supports the features, and how the architecture is evolving to support them better.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 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.
A
A
Kelsey
mentioned
my
experience
on
borg
been
doing
this
for
a
while
I've,
been
in
Google
more
than
10
years,
where
I'm
need
of
a
co-lead
of
Google,
kubernetes,
engine
and
I
have
to
say
I've
been
at
Google
a
long
time.
A
lot
of
great
projects.
Borg
was
a
great
project,
but
kubernetes
has
definitely
been
my
the
most
fun
out
of
all.
A
The
projects
have
done
at
Google
now:
I
co-lead,
the
architecture
special
interest
group,
which
is
trying
to
document
and
communicate
the
design
of
communities
to
all
the
contributors
and
a
member
of
the
kubernetes
steering
committee
I'm,
also
on
the
technical
oversight
committee
of
the
scenes,
yes,
and
actually
we're
looking
at
a
number
of
the
projects
that
Clayton
mentioned.
That
would
complement
kubernetes
like
open
policy
agent,
for
example,
and
I'm
gonna,
be
talking
to
you
a
little
bit
about
a
simple
topic
here.
A
A
A
Sara
talked
about
our
social
experiment,
acts
aspect
of
the
kubernetes
project,
but
I'm
gonna
focus
on
the
more
technical
ones,
I'm,
also
going
to
mention
a
few
cases
where
lessons
we
learned
from
borg
motivated
different
design
decisions
in
kubernetes,
and
hopefully
this
will
give
you
some
idea
about
why
communities
is
the
way
it
is
and
where
it's
headed
in
the
future.
I
actually
agree
with
most
of
Clayton's
talk
about
things
that
are
gonna,
be
super
important
in
2018,
bringing
all
the
cloud
native
technologies
together
in
a
seamless
way.
A
So
these
are
10.
10
was
a
nice
round
number,
so
I
could
just
pick
10
ways
of
thinking
about
communities
that
are
relevant
to
its
design.
A
recurring
theme
is
that
kubernetes
can
do
a
lot,
but
it
was
always
intended
to
be
a
platform
that
can
be
built
upon
and
extended
and
even
as
a
toolkit
that
can
be
used
by
other
systems
such
as
service
meshes
in
machine
learning,
platforms.
A
So
the
first
way
most
people
think
about
communities
is
this
container
platform.
That's
pretty
straightforward,
that's
more
or
less
how
it
started
the
kubernetes
node
agent,
the
qiblah,
executes
and
manages
groups
of
containers.
The
this
functionality
is
exposed
through
the
kubernetes
api
server,
with
the
pod
and
node
api's.
By
the
way,
there's
a
lot
of
detail
on
these
slides,
it's
kind
of
a
cig
style
presentation
to
kind
of
just
keep
it
real.
I'm
gonna
unlock
these
slides.
A
After
the
talk,
I
posted
a
link
on
Twitter
sleep,
don't
have
to
read
the
details
that
is
kind
of
an
eye
chart,
but
the
container
execution
functionality
it's
a
lowest
level
of
the
kubernetes
domain
model.
It's
the
bedrock
of
kubernetes
I,
call
that
layer
the
nucleus
and
you
can
see
that
I
left
a
lot
of
space
for
other
api's.
A
We
knew
from
our
experience
with
borg
that
users
would
need
a
platform
that
could
do
a
lot
more
than
just
run
containers
in
board
most
the
other
functions
that
users
need
are
actually
implemented
as
completely
independent
systems,
with
very
different
API
configuration
mechanisms,
and
then
all
those
things
need
to
be
glued
together.
In
kubernetes,
we
wanted
to
provide
a
platform
that
can
be
expanded
to
meet
the
needs
of
users
so
as
I
introduce
additional
functionality,
I'll
show
how
plugs
into
the
kubernetes
components
and
also
so,
where
falls
into
this
logical,
architectural
layer
cake.
A
This
layering
is
going
to
be
important
to
contributors
and
I
know
hope.
We
still
have
a
number
of
contributors
here
in
order
to
reinforce
the
structure
of
the
system
as
it
grows,
continues
to
grow
and
evolve.
I
always
say
we
have
about
10
years
of
work
left
to
do
on
this
on
the
system.
So
you
know
having
a
vision
of
how
it
should
be
organized.
A
It's
going
to
be
really
important
as
the
community
grows,
and
it's
also
important
to
ecosystem
developers
to
make
sure
that
we
don't
introduce
accidental
coupling,
and
we
can
preserve
the
flexibility
that
the
ecosystem
developers
need
to
use
the
pieces
that
they
need
our
card,
and
it's
going
to
be
important
to
users
as
well.
To
make
it
clear
what
parts
you
can
depend
on
on
kubernetes
everywhere,
as
the
system
becomes
more
and
more
customizable.
A
So
the
other
part
of
the
bedrock
of
kubernetes,
which
is
really
one
of
the
things
that
distinguishes
it
from
most
other
systems,
is
the
control
plane
at
the
center
of
the
control
plane
is
the
API
server
that
implements
the
common
functionality
for
all
the
systems.
Api's
users
interact
with
kubernetes
just
through
the
API
server,
either
through
queue,
control
or,
and
that's
the
canonical
pronunciation.
By
the
way
I
came
up
with
the
name,
so
I
get
to
say.
A
A
A
Borg
used
a
different
model
board
had
a
state
machine
that
is
hard
to
change
and
extend
new
States
cannot
be
added
and
even
changing.
Introducing
new
reasons
why
objects
could
remain
an
existing
state
broke
client
assumptions.
So
so
we
really
wanted
a
design
that
was
resilient
and
composable
to
make
it
easy
to
add
new
automated
processes,
whether
implemented
as
part
of
the
system
or
even
by
users.
A
This
control,
plane
infrastructure
is
also
part
of
the
nucleus
that
the
rest
of
communities
is
built
on
way.
Number
three
kubernetes
can
be
thought
of
as
a
configuration
distribution
system.
It
shares
some
common
features,
with
key
value
stores
like
zookeeper
at
CD,
the
store
where
kubernetes
keeps
its
date.
You
know
it's
also
been
compared
to
ansible
chef
and
puppet
configuration
management
systems,
because
the
combination
of
state
distribution
and
the
ability
to
execute
programs
across
multiple
nodes
is
at
the
core
of
many
automation.
A
Systems
about
30%
of
board
configuration
is
application
configuration
even
though
other
systems
exist
for
distributing
application
configuration.
That's
because
many
users
want
to
use
the
same
configuration
mechanism
and
tools
to
configure
their
applications
as
they
do
to
deploy
and
upgrade
them.
Kubernetes
config
map
and
secret
api's
deliver
configuration
information
to
containers
as
environment
variables
or
as
files
facilitating
the
configuration
of
12
factor
and
on
12
factor
applications
and
even
kubernetes
components.
A
They
have
something
called
component
config
where
we're
using
can
consuming
config
maps
to
dynamically
configure
to
entities
itself
and
with
new
custom
resource
definition
and
API
aggregation
features
of
kubernetes.
Other
automation
systems
can
be
dynamically
configured
using
the
same
patterns
and
libraries
and
tools
as
built
in
kubernetes
api
is.
This
is
the
Prometheus
operator
which
enablings
monitoring
targets
to
be
specified
similar
to
how
service
endpoints
are
selected.
A
These
mechanisms
further
expand
the
set
of
API
and
execution
primitives
in
the
nucleus
later
way.
Number
for
container
infrastructure
as
a
service
is
a
term.
That's
been
used
to
distinguish
kubernetes
from
simpler
container
platforms,
distributed.
Applications
are
comprised
of
multiple
containers
that
need
to
be
discovered
and
load
balanced
across.
This
is
why
communities
from
the
beginning
has
supported
primitives,
similar
to
infrastructures
and
service
platforms
such
as
instance,
groups,
load,
balancers,
and
shortly
after
the
initial
version,
storage
volumes,
but
in
terms
of
container
and
service-oriented
abstractions.
A
A
These
primitives
are
exposed
as
API
is
in
the
API
server
like
the
other
api's
and
implemented
it
as
controllers
and
new
additional
components
such
as
the
scheduler
key
proxy
cube,
DNS
and
ingress
controllers.
Most,
these
components
even
just
run
on
kubernetes
themselves,
and
all
of
them
are
pluggable
and
can
be
swapped
out
as
long
as
the
controllers
implement
the
API
we
Clayton
just
mentioned.
The
cube
router,
for
example,
which
is
a
replacement
for
key
proxy
core
DNS,
has
been
used
to
replace
cube
DNS.
A
A
Wait
number
five
I
have
described
kubernetes
as
a
platform
designed
to
automate
deployment,
scaling
and
management
of
containerized
applications.
That's
what
it
says
on
that.
What
is
kubernetes
page,
what?
Let's
not
say,
it's
a
general-purpose
of
interim,
an
automation
system
framework
or
generic
policy
engine,
but
it's
api's.
Do
you
facilitate
building
higher-level
automation
such
as
auto
scaling
and
kubernetes
support,
scoped
enforcement
of
configurable
policies
such
as
resource
pota?
A
These
mechanisms
are
configured
using
two
Pranay
T's
API
is
at
the
highest
logical
layer
of
the
kubernetes
architectural
layer
cake.
Similar
mechanisms
could
have
been
built
entirely
outside
of
kubernetes
and
we're
working
to
make
that
easier.
With
mechanisms
like
admission
control
extension
when
we
build
in
these
features
because
we
felt
they
they
would
address
a
lot
of
common
operational
concerns
of
applications
running
on
kubernetes
and
we're
saying
services
as
a
platform.
A
Easy
consumption
of
a
wide
variety
of
services
and
there's
important
wait
cloud
platforms,
improved
developer
productivity,
community
Service,
Catalog
api's
make
it
easier
to
consistently
consume
a
wide
variety
of
services
through
the
open
service
broker,
in
addition
to
simplifying
service
discovery,
authentication
and
configuration
binding
to
services
through
the
service.
Catalog
makes
it
easier
to
use
different
implementations
in
different
environments.
For
example,
an
application
can
use
my
C
folder
during
local
development
and
a
hosted
sequel
database
service
on
a
public
cloud.
A
Portability
was
always
a
goal
and
we're
making
kubernetes
even
more
portable,
with
new
plug-in
mechanisms
such
as
the
container
runtime
interface
windows
support
and
the
key
Batman
portable
bootstrapping
tool.
We
introduced
a
test
based
certification
program,
so
users
can
be
confident
that
the
distribution
of
kubernetes
they
use
behaves
as
they
expect
and
we're
making
applications
more
portable
to
with
mechanisms
like
the
service
catalog
and
also
by
making
more
kinds
of
workloads
run
better
on
kubernetes,
including
stateful
applications
and
data
processing
applications.
A
Like
spark
users
tell
us
that
they
value
the
control,
observability
and
consistency
that
comes
with
managing
all
their
trubin
applications
on
kubernetes.
We
found
that
boards
one
size
fits
all
job.
Api
made
it
harder
to
specialize
the
behavior
of
the
system
for
different
types
of
workloads,
so
kubernetes
has
different
api's
for
different
classes
of
workloads.
The
ApS
used
to
run
those
workloads,
deployment,
stateful,
setting
and
demon
set
achieve
stable
v1
status.
As
of
the
1.9
release.
I
just
want
to
call
out
to
everybody
who
helped
make
that
happen.
A
The
the
base
certification
profile
will
cover
the
stable
api's
at
the
lower
two
layers
of
this
stack
and
other
profiles.
We'll
cover
cover
other
api's
and
features
those
at
those
API
is
at
the
bottom.
Two
layers
of
the
stack
are
important
because
those
api
is
used
to
deploy,
configure
and
monitor
your
applications.
A
So
obviously
kubernetes
has
grown
a
lot
from
just
four
api's
to
more
than
50.
It's
also
grown
from
one
github
repository
to
more
than
90.
These
new
sub
projects
ban
many
areas,
such
as
our
documentation.
The
dashboard
UI
mini
cube
that
container
runtimes
and
lots
more
3/4
of
kubernetes
development
is
now
in
these
new
repositories
and
we're
working
on
moving
more
code
out
of
the
original
repository
so
further
in
peace
philosophy.
A
Some
of
those
needs
can
be
satisfied
by
building
on
top
of
kubernetes
as
a
platform
to
facilitate
the
integration
of
other
tools
and
services.
We
developed
client
libraries
for
seven
languages
in
2017.
We
also
added
several
new
mechanisms
to
enable
extension
of
kubernetes
such
as
the
Mission
Control
web,
hooks,
API,
aggregation
and
custom
resource
definitions.
A
kubernetes
is
open
source,
so
we
expect
to
be
used
as
parts
as
well
as
and
whole.
A
You
may
have
seen
Kelsey
standalone
cubelet
tutorial
that
enables
you
to
use
culet
without
the
rest
of
kubernetes.
If
you
just
want
to
manage
containers
on
individual
VMs
and
also
SDKs
for
kubernetes
style
api's
are
under
development,
such
as
the
api
server
builder
mentioned
during
Finn's
talk
already.
Dozens
of
projects
such
as
the
qiblah
service
platform
in
the
root
storage
Orchestrator
expressed
their
own
api
using
kubernetes
api
extensions,
and
that
enables
you
to
manage
all
your
applications
using
the
same
tools.
A
So
with
kubernetes.
You
aren't
limited
by
what
the
project
itself
can
deliver.
You
can
also
take
advantage
of
the
use
code
system
built
around
it.
Hundreds
of
products
and
projects
have
official
tutor,
Nettie's
support
or
have
been
integrated
by
the
open
source
community.
The
more
than
10,000
github
repositories
mentioned
kubernetes,
so
kubernetes
can
be
hard
to
describe
because
it's
all
these
things
and
more.
How
I
think
about
communities?
Is
it
a
portable
extensible
open-source
platform
for
managing
both
containerized
applications
and
services
that
facilitates
both
declarative
configuration
and
automation
and
has
a
large,
rapidly
growing
ecosystem?
A
But
one
great
thing
about
the
conference
is
I.
Have
the
opportunity
to
talk
to
other
people
find
out
what
you're
interested
in
using
kubernetes
for
already
using
cooper
days
it
for
so
reach
out
to
me
on
twitter?
I'm
be
grant
zero,
six
zero,
seven
on
twitter
and
github,
and,
let
me
know
hi,
you
think
about
kubernetes.