►
Description
Keynote: Kubernetes: Simple to Manage Anywhere - Brandon Philips, CTO, CoreOS
Managing a distributed system is hard; but Kubernetes is there to help. But, what manages Kubernetes itself? Learn what has been happening in the community to not only make Kubernetes easy to adopt but also simple to manage.
About Brandon Philips
Brandon Philips is helping to build modern Linux server infrastructure at CoreOS as CTO. Prior to CoreOS, he worked at Rackspace hacking on cloud monitoring and was a Linux kernel developer at SUSE. As a graduate of Oregon State's Open Source Lab he is passionate about open source technologies.
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
All
right,
how's
everybody
feeling
about
today
tonight
everything
good
all
right.
So,
if
you're
not
familiar
with
what
core
OS
does
and
build
a
lot
of
open
source
technologies
introduced
at
CD,
the
primary
key
value
store
of
kubernetes,
a
bunch
of
other
things
like
core
OS
linux,
etc
over
the
last
few
years,
you
also
have
may
have
seen
this
from
one
of
my
other
three
talks
today.
So
this
seems
familiar.
It's
not
deja
vu
you're,
not
tired
of
the
election
cycle.
A
It's
actually
because
this
has
happened
before
and
then
we
also
have
a
number
of
products
like
tech
tonic,
which
uses
pure
upstream
kubernetes
and
builds
a
bunch
of
enterprise
integrations
around
around
that
core
component
and
in
quei,
which
is
a
hosted
service
for
building
containers
and
and
hosting
containers.
It
also
can
be
ran
behind
the
firewall.
A
So
that's
what
core
OS
does
I'm
the
CTO
co-founder,
but
let's
dive
into
what
I
want
to
talk
about
today,
which
is
the
state
of
automatic
updates
and
the
state
of
bringing
kubernetes
and
managing
kubernetes
across
any
sort
of
infrastructure.
So
the
story
begins
that
we're
gonna
be
talking
about
with
two
vulnerabilities
that
were
released
on
October
20th,
so
just
a
few
weeks
ago,
the
first
is
dirty
Cal.
All
of
our
vulnerabilities
today
have
to
have
a
logo
has
to
be
really
cool
kind
of
a
catchy
name.
A
It's
just
the
rules
of
the
game
and
security
today,
and
so
with
dirty
Cal.
What
had
happened
was
security
vulnerability
came
out,
it
was
disclosed
really
bad
one.
Essentially,
it
allows
you
given
local
root
local
file
system
access
to
gain
root,
bypassing
essentially
all
of
the
security
and
all
the
security
properties
of
the
Linux
kernel
is
supposed
to
enforce
for
you
now.
The
unique
thing
here
is
that
within
24
hours,
the
majority
of
the
hosts
running
a
core
OS
Linux,
which
is
a
piece
of
software,
that
we
release
is
open
source.
A
That
a
lot
of
people
use
is
the
underlying
operating
system
for
their
QB
Nettie's
clusters,
etc.
We
were
able
to
patch
a
majority
of
those
systems
within
24
hours
and
it's
because
of
the
mechanisms
and
there
the
automated
updates
that
we
have
now
on
that
same
day,
a
vulnerability
was
disclosed
publicly
about
kubernetes
clients
or
validation
failure,
and
this
vulnerability
was
pretty
bad
and
it
we
kind
of
didn't,
handle
the
security
disclosure
process
perfectly,
but
we're
learning
we're
a
younger
community
and
we'll
work
it
out.
A
We
have
a
lot
of
really
smart
folks
that
are
gonna
nail
that
down
the
really
disappointing
thing,
though,
was
we
were
sort
of
powerless
to
actually
do
anything
about
it.
The
issue
came
out.
There
was
a
patch
available,
but
then
all
of
us
had
to
essentially
manually
figure
out
what
to
do.
Next.
Some
of
us
have
deployed
kubernetes
in
one
way
or
another.
We
laid
it
down
with
configuration
management.
You
use
this
tool
that
we
found
on
github
one
day
because
it
seemed
out
a
lot
of
stars.
A
Then
there's
just
a
lot
of
different
ways
that
we're
doing
it,
and
so
it
was
a
manual
upgrade
and
I
think
we
can
do
better
and
of
course,
kubernetes
is
a
young
community,
and
so
we
don't
have
all
the
panache
and
branding
of
all
these
vulnerabilities,
so
I'm
going
to
label
this
one.
It's
going
to
be
called
mask.
Okay,
just
for
the
purposes
of
this
talk,
we
love
Kay's
so
upper
case
that
so
it's
maskel
that
cool
big
Kay,
but
there's
an
opportunity
here,
there's
no
opportunity
for
automation,
so
with
Corollas
Linux.
A
How
did
we
actually
get
to
upgrading
these
things?
A
majority
of
a
host
in
24
hours?
It's
because
core
Ellis
takes
inspiration
from
a
lot
of
the
things
that
we
know
to
be
correct.
We
know
that
you
want
to
do
rolling
upgrades.
We
know
that
you
want
to
have
atomic
upgrades,
so
you
can
roll
back
from
so
Korres
Linux
builds
that
into
the
Corp,
so
we're
able
to
apply
an
update
from
a
running
system.
We
have
an
a
copy
of
the
operating
system,
a
B
copy.
A
We
apply
an
update,
we
reboot
the
system
and
it
moves
forward.
This
whole
feels
very
familiar
to
us
in
the
communities
community
with
deployments,
so
you
have
a
copy
of
your
application.
That's
running
today,
it's
behind
your
load,
balancer!
You
get
a
new
version
of
your
application.
You
want
to
roll
that
you
up
could
update
the
deployment
and
boom.
Everything
is
moved
forward.
Perhaps
you
out
of
ulnar
ability
and
your
software
that
you're
patching
now.
This
brings
us
to
the
concept
of
self
host
thing.
A
So
what
if
we
were
able
to
take
all
those
primitives
that
we
had
inside
of
kubernetes
to
manage
our
applications
in
this
very
reasonable
way
that
we
know
to
be
a
very
resilient
wave
of
deploying
managing
apps?
Well,
what
if
we
brought
that
to
kubernetes
itself?
So
if
you're
not
familiar
with
this
idea
of
self
hosting,
it's
pretty
straightforward,
so
compiler
writers,
compiler
writers,
want
to
use
the
language
that
they're
building
in
order
to
write
their
compiler.
So
in
the
case
of
GCC,
you
input
C
source
code
out
pops.
A
A
new
copy
of
GCC
goes
go
the
language
the
kubernetes
uses
recently
became
self
hosted,
so
you
input
go
code
into
a
go
compiler
and
out
pops.
A
new
version
of
go:
this
gets
a
little
bit
noodley
when
you
start
to
think
about
actual
things
running
processes.
So
let's
go
a
practical
example:
here's
young
leanest
Torvalds
is
any
adorable.
A
Young
leanness
didn't
have
Linux
yet,
so
how
is
he
going
to
do
his
development?
He
was
using
an
operating
system
called
MINIX.
He
built
the
Linux
source
and
out
popped
a
cute
little
penguin
called
text.
The
Linux
kernel
one
when
compiling
that
and
then
a
few
months
later,
but
I'll
use
a
much
older
photo.
A
few
months
later,
leanness
has
learned
his
lessons.
He
finally
has
figured
out
how
you
get
this
kernel
booted.
A
One
of
the
cofounders
of
the
project
said
that
running
all
of
our
components:
inside
of
pods,
all
the
components
being
the
scheduler
and
the
API
cetera,
would
help
us
avoid
implementing
more
brittle
and
less
portable
solutions,
so
eventual
eventually
we'll
get
around
to
self
hosting.
This
was
about
20
months
ago,
when
this
comment
was
made
on
one
of
the
public
didn't
have
issues
I'm
sure
Brian
has
the
github
number
memorized.
A
If
any
of
you
talk
to
Brian,
he
like
memorizes
the
github
numbers,
it's
amazing
human
indexing,
so
yeah.
The
idea
here
is
that
we
take
kubernetes.
We
take
a
deployment.
We
have
a
new
API
server,
maybe
IA
p.I
server
that
lacks
the
Baskerville
nura
bility.
We're
able
to
tell
kubernetes
deploy
me
a
new
copy
of
the
kubernetes
api
server
and
we
roll
forward.
Now
today's
world
looks
a
lot
different
than
that,
so
we're
not
using
self-hosted
everywhere.
A
A
We
put
manifests
in
different
places,
we
write
out
the
Kubla
init
system
differently,
and
so
every
single
one
of
these
tools
needs
to
write
a
different
operational
manual,
and
so
you
use
that
exact
same
tool
when
you
need
to
move
between
versions
and
here's
the
better
way
that
we're
proposing
with
self-hosted
and
that
signal
cluster
lifecycle
has
been
working
really
hard
towards.
You
use
the
infrastructure
tools
to
deploy
infrastructure.
So
when
you
need
compute
network
or
storage,
you
go
to
your
infrastructure
tool.
A
It
knows
how
to
talk
to
your
cloud
provider
and
then
use
kubernetes
to
deploy
kubernetes.
You
use
coop
cuddle
to
update
the
deployment
of
API
server,
and
the
advantage
that
we
have
here
is
that
the
exact
same
abstractions,
the
exact
same,
run
books.
The
exact
same
documentation
works
whether
you're
running
on
AWS,
whether
you're
running
on
Azure,
whether
you're,
maybe
bringing
this
on
to
bare
metal,
and
you
want
to
move
from
a
copy
of
kubernetes
that
is
vulnerable
or
has
a
bug
that
you
want
to
have
fix
to
copy
of
kubernetes.
That
is
fixed.
A
So
the
goals
create
a
foundation
to
odd
automatic
cluster
upgrades,
or
at
least
automate
them
use
the
kubernetes
compute
network
and
storage
abstractions
and
let
the
infrastructure
tools
focus
on
the
infrastructure.
So
what
I
want
to
show
you
today
is
what
we've
been
kind
of
calling
self-driving
kubernetes
and
it's
a
technical
preview.
This
is
all
live.
Hopefully,
we've
had
three
demos
go
well,
so
the
odds
are
not
in
my
favor,
but
what
we'll
be
doing
is
we'll
be
going
into
a
kubernetes
cluster
that
is
selfhood
and
doing
automated
update.
A
So
what
I've
done
is
I've
used.
I've
used
the
tectonic
installer
tool,
which
is
built
on
top
of
the
kubernetes
incubator
project
called
buku
buku
is
a
temporary
API
control
plane,
so
what
it
does
is.
It
includes
in
a
single
binary,
sed
the
API
server
of
the
scheduler,
the
controller
manager.
This
is
essentially
the
little
seed
that
you
plant
inside
of
the
cluster
in
order
to
bring
up
a
full
self
hosted
cluster,
it's
the
MINIX
in
our
analogy
with
leanness.
A
So
once
you
deploy
this,
you
get
a
working
kubernetes
cluster
and
if
we
look
through
the
actual
look
through
the
dashboard,
what
we
can
see
if
we
start
to
search
around
for
kubernetes
kubernetes
components
that
we're
familiar
with.
We
see
that
there's
a
kubernetes
scheduler
in
here.
We
can
see
that
I've
done
the
correct
thing
and
I've
scaled
up
to
two
pods.
You
know
maybe
I
want
to
scale
that
up
to
three
pods,
because
I
want
to
have
a
more
highly
available
API
service.
A
These
are
the
sorts
of
functionality
that
we
enable
when
we
use
the
kubernetes
api,
so
we
can
easily
create
a
che
and
scalable
structures
that
are
able
to
recover,
and
similarly,
we
can
come
in
and
see
that
there's
a
API
server,
that's
running
as
a
daemon
set,
and
this
is
technical
details
around
how
networking
works
inside
of
kubernetes.
The
reason
why
it's
not
a
deployment
which
I
won't
go
into
here,
but
the
big
thing
is
you
dig
through
these
components
and
we
see
that
they're
running
version
143.
A
Let's
pretend
for
a
second
that
it's
actually
one
for
two
with
the
mask
vulnerability
and
what
we
want
to
do
is
upgrade
to
the
latest
release
of
kubernetes,
which
is
kubernetes
with
one
four
five
and,
of
course,
as
any
any
good
kubernetes
demo.
What
I've
done
is
I
have
a
very
sophisticated
engine,
X
default
page
running
on
this
cluster
I'm
just
kidding,
so
we
have
a
default
page
that
we're
going
to
use
those
our
example
application
and
this
example.
A
Application
will
continue
to
stay
up
and
we'll
be
using
AWS
cloud
watch
to
show
that
the
application
isn't
losing
availability.
While
we
do
this
upgrade
all
right,
so
I'll
show
you
the
UX
for
all
this.
To
do
the
update
it's
really
sophisticated.
What
you
want
to
do
is
come
in
here
and
click
this
button.
A
What
that
will
do
is
in
the
background
we
have
a
piece
of
software
that
is
looking
at
the
third-party
resources
where
we
now
describe
I
want
to
move
this
cluster
from
version
1,
4,
3,
2,
1,
4
5,
and
it
will
begin
the
process
of
rolling
through
and
update
updating
all
these
different
components.
So
we
can
start
to
test
that
out
by
coming
in,
we
can
sort
start
to
test
this
out
by
coming
in
and
looking
through
the
different,
of
course,
perfect
luck
of
the
draw
right.
A
All
right
so
we'll
try
this
one
more
time
so
we'll
come
in
and
we'll
actually
start
to
upgrade
the
the
cluster,
and
so
these
third-party
resources
will
describe
and
there's
an
active
component
living
inside
the
cluster
that
is
going
to
be
actually
going
through
and
doing
the
deployment
on
our
behalf.
So
if
we
come
in
and
look
at
something
like
say,
the
daemon
sets.
A
What
you'll
see
is
that
the
daemon
set
that
is
running
the
API
server
will
be
terminating
and
then
in
a
few
moments
after
it
finishes
terminating
a
new
version
of
the
API
server
will
come
up
replacing
the
previous
one
great.
So
my
original
cluster
decided
to
come
back
for
a
second,
and
so
what
will
happen
over
this
entire
process?
A
What
we
should
notice
is
that,
even
though,
for
a
second,
there
I
lost
my
console,
probably
because
the
yell
B
lost
health
checking
on
the
console.
The
actual
thing
that
we
care
about
is
our
application.
The
application
never
went
down,
and
similarly,
we,
the
nice
thing
about
having
the
ability
to
use
kubernetes
api
x',
is
that
worse,
we
could
have
logged
into
the
systems
that
have
been
running
those
daemon,
that's
even
though
they
weren't
at
the
lbs
and
started
to
debug
the
system
figured
out.
Well.
What
is
that
the
scheduler
that
went
down?
A
Okay.
So
how
is
this
all
working
so,
like
I,
said,
there's
this
third-party
resource
that
when
I
click
that
button,
it
essentially
describes
between
the
current
version
of
kubernetes
and
the
desired
version,
and
the
this
piece
of
software
talking
to
the
kubernetes
api
is
not
doing
any
configuration
management,
not
as
the
staging
into
the
hosts.
Not
touching.
These
files
on
disk
will
actually
update
all
those
components
and
there's
a
few
parts
to
make
this
happen.
A
There
is
a
part
where
we
look
at
the
desired
state
the
user
is
described
and
in
the
current
state
we
analyze
that
difference,
and
we
figure
out.
Should
the
API
server
be
upgraded,
should
the
controller
manager
be
upgraded
and
we
essentially
create
a
plan
to
go
through
and
upgrade
the
system
and
then,
at
the
very
end,
we'll
actually
notify
the
user
hey.
We
got
to
a
fully
upgraded
kubernetes
cluster
and
we
we
tell
them
you're
now
running
the
latest
greatest
kubernetes,
and
this
is
all
done
via
kubernetes
api
x'.
A
So
next
steps
fukube
the
underlying
tool
that
deployed
this
onto
AWS
works
on
GCP
and
on
bare
metal.
Please
use
blue
cube,
it's
a
cubic
kubernetes
incubator
project
and
a
lot
of
the
innovation
that
actually
makes
this
type
of
infrastructure
possible.
This
type
of
self
hosted
infrastructure
possible
is
in
there.
You
can
find
a
lot
of
docs
and
deployment
guides
tomorrow
and
levy
from
our
team
at
core.
A
Os
is
going
to
be
giving
a
talk,
called
coop
ception,
going
into
more
detail
about
how
this
is
all
possible
and
some
of
the
lessons
learned
from
making
making
the
system
work
in
the
way
that
it
does
and
then
finally,
I
have
to
thank
everyone
inside
of
seed
cluster
lifecycle
who,
over
the
last
few
months,
have
really
helped
us.
Take
this
concept
that
we've
all
kind
of
talked
about
in
the
communities
community
for
a
long
time,
from
concept
to
prototype,
to
really
a
implementation.