►
From YouTube: Sponsored Keynote: Free Range Kubernetes: Feeding, Watering & Herding - Brian Goodman-Jones
Description
Join us for Kubernetes Forums Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Sponsored Keynote: Free Range Kubernetes: Feeding, Watering & Herding - Brian Goodman-Jones, Director, Rancher
We can all grasp the concepts & benefits of “free-range” when it comes to farming, think open paddocks, green grass, colorful healthy fields. This talk will look at “free range” farming principles and how they might apply to best practices for getting the most out of Kubernetes at scale - across the data centre, the cloud and the edge. What principles could we adapt & apply, and what would the outcomes look like. E.g. alignment to upstream, open standards, CNCF, multi-cluster, multi-cloud.
A
So
my
name's
Brian
I
work
for
Rancher
I'm,
based
here
in
Sydney,
Australia,
I'm
John
on
stage
with
Gareth,
who
is
also
based
in
Australia,
and
today
we
just
want
to
spend
just
a
few
minutes
just
to
provide
some
insight
into
I.
Guess
what
we're
seeing
in
industry
with
kubernetes
and
where
it's
going,
because
I
think
I
know
Cuba
needs
adoption.
We
all
know
it's
there.
We
all
know
it's
growing,
it's
its
massive
adoption
of
kubernetes
and
where
we're
at
now
is
multiple
clusters,
multiple
clouds,
and
so
what
are
the
challenges?
A
What
are
people
seeing
and-
and
you
know,
what's
some
advice-
is
pretty
much
what
we're
going
to
talk
about.
So
we
did
a
survey,
an
industry
survey.
Last
month
we
released
the
last
month,
it's
about
1,100,
mid
to
large
organizations,
and
you
can
get
it
from
our
website
and
I.
Think
the
point
about
this
slide
is
really
you
know.
Everybody
is
doing
multiple
clusters
right.
We
sort
of
moved
on,
as
I
said
from
from
single
cluster
environments,
to
to
multiple
clusters
right
so
91%.
The
other
thing
we're
seen
is
multiple
clouds
right.
A
So
if
you
see
there,
71%
of
organizations
are
running
kubernetes,
on-premise
67
are
running
on
a
public
cloud,
and
so
you
have
this
overlap
right.
You
give
this
hybrid
or
multi
cloud
overlap,
that's
going
on
so
yeah.
If
we
think
about
complexity
and
the
new
world
of
kubernetes,
multiple
clusters,
multiple
clouds
and
now
we're
also
seeing
you
know
this-
this
evolution
of
committees
to
the
edge
right.
A
So
things
like
k3s,
you
know
I've
been
out
around
Cuba
knees
on
unarmed
devices
and
low
memory
footprint
devices,
so
the
challenges
then
I
think
are
moving
from
you
know
just
spinning
up,
kubernetes
and
deploying
communities
to
managing
the
complexities
of
different
communities.
Environments
across
you
know
like
large
development
teams
across
multiple
cloud
environments.
You
know
I
think
about
our
back.
How
do
you?
A
How
do
you
do
our
back
across
these
sorts
of
things
so
Gareth
before
he
joined
Rancher
was
actually
a
very
large
financial
services
organization
in
Australia,
New
Zealand
and
he
was
sort
of
lead
of
the
DevOps
team
there
and
so
I
thought
rather
me.
Talk
it'd
be
great
to
get
girls
insight
into
maybe
three
of
the
key
takeaways
that
he
experienced.
As
you
know,
a
multi-year
journey
moving
to
containers
moving
to
kubernetes.
You
know
they
now
have
10,000
containers
in
production
across
multiple
clouds
etc.
B
Definitely
I'd
love
to
talk
about.
You
know
some
of
the
challenges
we
face.
These
are
not
all
the
challenges.
Just
a
top
three
I
thought
you
know,
might
sort
of
resonate
with
a
lot
of
the
audience
here.
So
the
first
one
was
multi
cluster
multi
gates
right.
So,
rather
than
going
with
a
bog
like
approach,
we
thought
you
know
we'll
go
with
multiple
kubernetes
cluster
is
across
multiple
cloud
providers
and
the
entire
reason
for
doing
this
project
was
the
basic
problem
that
most
developers
have.
B
It
worked
in
dev,
I'm
sure
you
know
if
some
of
you
have
had
the
same
issue,
so
we
went
down
this
approach.
You
know
of
writing
automation
to
build
kubernetes
clusters,
and
you
know
we
could
effectively
pretty
good
at
it.
So
we
were
eventually
running.
You
know
like
lots
of
clusters
across
multiple
cloud
providers
and
that
allowed
our
developers.
You
know
lots
of
you
know,
paths
through
production.
The
idea
was,
they
could
you
know,
use
one
environment
if
they
wanted
to
test
against.
B
One
sort
of
you
know
back
in
integration,
and
you
know
move
it
to
another
in
what
kubernetes
environment
if
they
wanted
to
test
against
another
integrated
environment.
So
you
know
we
realized
by
doing
this,
that
we
were
so
good
at
spinning
up
clusters
that
we
thought
you
know,
let's
just
apply,
to
run
multiple
production
sites.
This
way
you
know
we
can
just
do
immutable
infrastructure
all
the
time.
So,
every
eight
to
ten
weeks
when
we
want
to
roll
out
security
patches
or
do
any
info
updates,
you
know
we
wouldn't
do
it
in
place.
B
We'd
just
blow
a
full
cluster
and
build
it
all
back
and
that
sort
of
really
helped
us
with
our
security
posture.
In
terms
of
you
know,
not
being
you
know,
in
being
able
to
respond
to
security,
even
you
know
pretty
quickly.
The
next
big
problem
was
our
back
inconsistency
right.
The
original
set
of
communities
and
container
clusters
that
we
built
was
initially
written
for,
let's
say
one
dev
team,
and
now
suddenly
you
know
there
was
like
a
pent-up
demand
that
other
dev
teams
want
to
use
the
service
as
well.
B
So
we
sort
of
you
know,
thought
we
have
to
operate
at
scale
and
the
biggest
problem
in
a
multi-tenant
ed
when
a
DS
environment
is
our
back
and
consistency.
So
we
ended
up
writing
our
own
CLI
wrapper,
similar
to
cube
control.
To
sort
of
you
know,
issue
of
our
back
to
developers
based
on
you
know
their
identity
management,
integration
and
what
it
meant
was.
You
know
they
could
consistently
access
the
clusters
and
deploy
stuff,
but
the
workloads
weren't
consistent,
which
leads
to
my
favorite
example.
The
3:00
a.m.
B
call
which
some
of
you
over
here
might
have
had.
You
know
that
something's
broken.
Can
you
fix
it
for
me?
Please,
and
that
was
my
3:00
a.m.
call.
You
know
one
of
the
pods
had
died
for
a
service
and
obviously
now
you
know
there
was
no
health
checks.
So
you
know
some
requests
were
failing
and
I
told
the
Dave
just
go,
delete
it,
and
you
know
the
scheduler
will
spit
out
a
new
one,
but
he
was
you
know,
sort
of
scared
that
this
is
fraud.
B
I
don't
want
to
do
it
in
fraud
and
I
was
like
dude.
Whatever
you
do
is
just
not
gonna
make
it
worse,
just
delete
it
and
move
on
with
your
life,
but
you
know
he
insisted
no.
No!
No!
This
is
fraud,
you
better
do
it
for
me,
so
I
had
to
log
in
at
3
in
the
morning
delete
that
part
and
go
back
to
bed
and
Monday
I
showed
up
at
work.
B
Some
of
the
people
who
I
used
to
work
with
are
still
here
and
they
know
how
grumpy
I
was
that
this
guy
just
wouldn't
really
hit
his
stuff.
So
we
had
this
problem
with
consistency,
so
we
had
to
see
a
lie
right,
so
we
forced
it
to.
We
thought,
let's
just
expand
it
to
sort
of.
You
know,
info
standards
on
the
deployment
specifications
that
were
being
sort
of
you
know
sent
to
the
scheduler,
so
we
would
parse
the
entire
manifest
or
kubernetes
manifest
to
make
sure
some
best
practices
we
were
being
followed.
B
B
We
cannot
do
container
scanning
in
the
CI
phase
and
you
know
that
would
sort
of
you
know
make
people
aware
that
security
is
everyone's
responsibility
and
that
allowed
us
to
sort
of
enforce
consistency
at
scale
through
automation,
which
meant
you
know,
I
could
chill
back
relax
and
never
get
another
3:00
a.m.
call.
B
B
But
on
a
more
serious
note
when,
when
I
implemented,
the
OODA
loop
to
sort
of
you
know
enforce
container
scanning
as
part
of
the
CI
pipeline,
devs
are
upset
because
now
they
couldn't
push
the
container
images
to
the
rigid
image
registry
because
they
had
vulnerabilities
and
which
meant
they
couldn't
test
their
code,
and
they
were
upset
that
you
know
all.
I
care
is
testing
my
code.
Why
I
mean
being
forced
to
you
know
worry
about
stuff
like
scanning,
or
you
know,
security
of
my
workload.
B
So
you
know,
I
had
to
you
know,
write
sort
of
a
flag
in
the
CLI
to
bypass
vulnerability
scanning
and
still
push
the
image
to
the
registry
and
sure
enough.
Everyone
was
using
the
same
flag
in
a
few
months
and
no
one
was
scanning
anything
so
I
implemented
the
scheme
scanning
in
the
deployment
pipeline
and
that
started
breaking
deployments
and
people
like.
Oh,
we
didn't
get
notified
about
the
vulnerabilities
at
the
build
phase
and
I
sort
of
pointed
them
to
the
log.
It's
right
there
have
a
look.
Can
you
make
the
font
bigger?