►
From YouTube: Seamless scaling of Kubernetes nodes — Marko Bevc 2.1.9
Description
If you're running your container workloads on AWS EKS orchestration platform and you are trying to dynamically provision workload resources based on the current load, you might find yourself in a position where limitations and rules of node group scaling might feel a bit too rigid.
This talk will focus on an interesting node lifecycle management solution from AWSlabs called Karpenter, which is an alternative approach to probably the most frequently used Cluster Autoscaler. Is this a better and more efficient way of allocating worker node resources? Would that get you around some of the node group constraints?
The project hasn’t reached GA stage yet and still has to solve some goals from the roadmap, but Marko thinks it has a lot of potential. We will look into what the current release has to offer and how is it dealing with this challenge of improving efficient dynamic workload provisioning.
B
B
Hopefully
everybody
can
see
that
if
you
can't
please
give
me
a
shout,
but
I
will
just
assume
that
that's
currently
visible
and
and
in
good
shape,
so
welcome
to
the
last
talk
of
the
conference
today
I
have
to
say
I
really
really
enjoyed
it
so
far.
I
really
like
the
variety
of
different
talks
that
we
have
so
all
the
way
from
you
know
deep
down
in
technology
as
josh.
B
So,
first
of
all
I
would
like
to
start
with
with
a
quote:
be
water.
My
friend-
and
this
was
actually
a
quote
from
bruce
lee,
who
was
a
martial
artist,
actor
philosopher
and
filmmaker.
It
was
actually
captured
in
the
canadian
show
in
the
70s.
It's
it
was
called
the
pierre
branson
show
so
bruce
lee
gave
up
an
interview
there
and
he
talked
about
you
know
the
mentality,
and
you
know
how
he
approaches
things
in
life
and
what
he
was
trying
to
say
with.
B
That
is
that,
in
the
kind
of
highly
hybrid
and
like
fastly
changing
environment,
you
need
to
you
know,
keep
your
mind
open
to
new
things
and
you
shouldn't
kind
of
cling
on
to
like
conventional
norms
and
that's
why
he
kind
of
talks
about
being
shapeless,
formless
like
water.
So,
for
example,
like
you
know,
if
string
goes
down
the
hill,
it
always
kind
of
tries
to
adapt
to
different
kind
of
obstacles
during
the
way
and
tries
to
go
around
it.
B
B
A
little
bit
of
disclaimer
slash
kind
of
a
heads
up
here,
even
though
we're
gonna
talk
about
the
provider
independent
solutions.
Today,
all
the
examples
and
the
demo
will
be
will
be
shown
on
aws
infrastructure.
So
hopefully
you
can
apply
that
to
different
different
different
kind
of
vendors
as
well.
B
My
background
is
mostly
ops,
so
I
I
have
an
extensive
kind
of
knowledge
with
linux
and
virtualization
from
my
past
kind
of
engagements,
I'm
also
an
open
source
contributor
and
a
supporter
and
a
big
fan
of
automation
and
simplifying
things.
If
you
can
still
remember
pre-pre
pandemic,
I
also
really
enjoyed
traveling
cycling
and
hiking,
which
was
a
little
bit
limited
lately,
but
hopefully
we're
gonna
get
there
soon.
B
So
what
I'm
going
to
cover
today
is
we're
going
to
kind
of
kick
it
off
with
you
know
some
scaly
foundations,
you
know
how
does
the
kubernetes
resource
scaling
look
like
we're
going
to
have
a
look
at
the
the
kind
of
automation
options
there
and
I'm
gonna
try
to
see
what
the
current
kind
of
limitations
or
or
drawbacks
are
using?
What
we're
currently
using
for
auto
scaling
and
kind
of
going
from
there.
We're
gonna
look
at
one
of
the
projects
that
are
is
trying
to
address
this.
B
It's
called
carpenter
he's
trying
to
kind
of
change,
change
the
idea
a
little
bit
around
and
it's
it's
it's
trying
to
do.
Groupless,
auto
scaling,
so
we're
gonna
have
a
look
at
the
architecture
of
the
project.
How
they're
you
know
approaching
those
kind
of
problems,
how
they're
doing
scheduling
how
it's
done,
bing
packing
and
also
the
the
whole
capacity
life
cycle
from
there.
I'm
gonna
go
with
the
demo.
Hopefully
the
demo
gods
are
are
really
good.
B
Okay.
So
if
we
quickly
go
through
the
through
the
scaling
kind
of
fundamentals,
so
if
we
look
at
scaling,
we
can
either
have
horizontal
scaling,
which
usually
means
adding
more
instances,
and
this
is
usually
referred
to
as
scaling
scaling
out
and
then
you
you
could
have
vertical
scaling,
which
is
usually
referred
to.
As
you
know,
scaling
up-
and
in
this
case
you
would
add
more
power
to
your
existing
instances.
B
So
in
terms
of
kubernetes
resources,
we
can
scale
either
pots
or
notes,
and
let's,
let's
first
have
a
look,
you
know
where
does?
Where
do
the
plots
come
from
actually
like,
so
we
can
actually
end
up
with
parts
by
you
know
melanie
spilling
them
up
using
cli,
or
we
can
actually
provision
workload.
Resources
such
as
deployment
replica
sets
human
sets
jobs
and
those
would
take
care
of.
You
know
provisioning
your
parts
afterwards
and
you
know
looking
from
the
from
the
from
the
kind
of
auto
scaling
perspective.
B
What
we
can
do
here
is
in
order
to
react
to
different
kind
of
environment
requirements
such
as
influx
of
requests.
We
can
use
two
links,
such
as
horizontal
plot,
autoscaler
or
vertical
quotation.
Scaler
just
bear
in
mind.
They
are
mutually
exclusive,
so
either
is
one
of
those.
There
is
a
a
different
different
autoscaler
available
in
gcp,
which
is
called
multi-dimensional
port
autoscaler,
and
it's
trying
to
kind
of
combine
both
of
both
of
those
words
together
in
order
to
kind
of
be
able
to,
you
know,
scale
up
pots
horizontally.
C
B
B
Okay,
those
are
parts,
let's
have
a
look
at
notes
now,
so
obviously
you
can
also
manually
provision
nodes
as
well,
but
you
know
from
from
from
the
automation
perspective.
Probably
the
fact
of
standard
in
the
industry
today
is
probably
cluster,
auto
scaler,
which
is
probably
most
widely
used,
and
there's
also
a
land
of
fork,
which
is
trying
to
kind
of
address
some
of
the
some
of
the
limitations
or
or
kind
of
kvl
surrounds
using
clusters
killer,
and
there
are
some
less
maintainable
projects
such
as
libro
and
escalator.
B
So
you
can
use
it
up
to
a
couple
of
thousand
nodes
with
30
parts
per
node
and
it's
using
existing
cloud
building
blocks
so,
for
example,
on
aws,
it
would
use
auto
scaling
groups
in
the
background,
but
it
also
comes
with
some
challenges
right
so
because
it's
kind
of
relying
on
the
auto
scaling
groups
in
the
background
and
the
kind
of
node
groups
which
are
kind
of
an
abstract.
You
know
kind
of
term
in
in
kubernetes
world
you're,
obviously
limited
to
specific
kind
of
concept
limitations
here.
B
So,
for
example,
if
you
want
to
span
across
multiple
acs
or
use
different
instance
types,
you
would
usually
need
to
provision
multiple
node
groups
to
kind
of
achieve
that
as
well.
So
obviously,
it
kind
of
works
on
the
parameters
that
you
know
you're
using
the
same
templates
in
the
background
and
those
would
be
applied
to
the
to
the
whole
node
group,
not
the
specific
nodes
itself,
it's
quite
complex
to
use
as
well.
So
it
has,
I
think,
like
over
70
arguments
that
you
can
use
when
you
spin
it
up.
B
B
So
what
is
carpenter?
It's
a
node
lifecycle
solution.
It's
currently
incubating
aws
labs,
also
open
source
and
vendor
neutral.
Even
though,
currently
it's
only
supporting
the
advanced
provider
for
obviously
reasons,
but
it's
vendor
neutral
and
there
is,
there-
is
a
and
a
wide
adoption
plan
for
later
on
in
the
project
and
what
it's
trying
to
do
is.
If,
if
you
look
at
the
diagram
here,
it's
it's,
you
couldn't
really
see
the
difference
from
the
auto
scaler,
but
the
logic
is
a
bit
different.
B
The
instances
that
would
kind
of
satisfy
the
the
the
resource
requests
they're,
also
generating
node
properties
on
the
fly
based
on
the
plot
scheduling
constraints.
So
everything
is
kind
of
done
on
the
fly
as
as
the
request
comes
in.
So
it's
much
more
flexible
in
this.
In
this
regard,
so
it
literally
removes
the
whole
node
group
concept
and
thus
it's
usually
kind
of
referred
to
as
groupless
node,
auto
scaling.
B
So
if
you
quickly
look
at
the
the
provisioner
crd
that
you
need
to
kind
of
use,
you
can
use
one
or
many
of
them.
There
is
no
limitation
to
it
and
there
is
a
question
of
what
use
cases.
Would
you
like
to
kind
of
address
with
it?
But
let's
have
a
look
at
the
most
kind
of
simple
crd
that
you
can
use,
which
is
kind
provisioner
from
carpenter
sh
and
in
the
specification
you
can
see
it's
not
a
lot
of
parameters
that
you
would
need
to
provide.
B
So
let's
kind
of
dive
quickly
into
the
how
the
launching
capacity
works
so
they're
launching
capacity
by
directly
executing
the
api
and
using
the
easy
to
create
fleet
api
calls
and
that
kind
of
returns.
The
the
whole
capacity
needed
under
the
hood
they're,
using
a
couple
of
controllers
to
kind
of
launch
the
capacity
and
manage
that.
So
there
is
an
allocator
controller,
which
is
a
fast
latency,
sensitive
one
and
a
free
allocator
which
is
slow
and
kind
of
cost
sensitive.
B
B
And
it's
an
complete
problem
where
you
try
to
fit
your
capacitor.
Your
kind
of
request
for
capacity
to
as
kind
of
limited
capacity
you
have
and
they're
using
the
first
fit
the
scheduling
descending
algorithm.
To
achieve
that.
So
it's
loosely
coupled
with
scheduler,
even
though
it's
kind
of
tightly
working
with
the
scheduler.
It's
not
relying
on
the
schedulers
explicitly
and
if
you
remember
the
code
before
it
definitely
sounds
like
the
triangle,
or
at
least
the
the
carpenter
trying
to
be
more
like
water.
B
B
B
They're
also
kind
of
making
sure
that
underutilized
deleted
nodes
are
coordinate
correctly
train,
so
there's
a
finalizer
as
well.
So
if
you
manually
delete
a
node,
it
will
train
the
node
before
actually
removing
it.
It's
reacting
to
spots
and
rebalance
kind
of
termination,
events,
instant,
unhealthy
events,
and
there
is
an
interesting
kind
of
a
use
case
here
as
well.
You
can
set
an
expiration
dtl
on
the
node
itself,
which
is
a
really
good
use
case
for
compliance.
B
So
what
you
can
actually
do
is
a
set,
an
expiration
date
or
an
expiration
ttr
on
a
node,
and
that
would
ensure
that
a
node
would
be
terminated
after
this
expires
and
as
you
can
imagine,
this
could
actually
keep
your
cluster
up
to
date.
Automatically
there
is
a
the
frequentation
they
want
to
implement
as
well.
It's
still
in
the
design
phase,
unfortunately,
but
the
idea
is
that
you
shouldn't
be
stuck
with
initial
provisioning.
So,
as
your
nodes
become
less
optimal
optimally
utilized,
we
should
have
a
controller.
B
So
what
we're
gonna
do
here
is,
as
I
mentioned,
before,
we're
going
to
run
the
the
adress
eks,
which
is
a
managed
kubernetes
kubernetes
cluster
in
adwords,
we're
going
to
use
fargate
profiles
and
the
reason
why
I
think
this
is
a
really
good
use
case
for
fire
profiles
is
because
obviously
there
is
a
chicken
and
neck
problem
right.
So
you
say:
okay,
I
want
to
deploy
up.
You
know
an
auto
scaling
solution,
but
obviously
you
need
to
kind
of
provision
it
somewhere.
B
So
either
you
statically
provision
a
node
and
run
it
there
or
you
can
just
use
it
as
far
gate,
which
is
a
serverless
solution,
kind
of
kind
of
nicely
nicely
kind
of
embedded
into
the
eks,
where
you
can
just
delegate
everything
to
aws
and
they
will
they
will
kind
of
provision,
the
underlying
resources
for
you
and,
I
think,
provisioning
carpenter
and
the
cube
system
main
space.
There
is
a
really
good
use
case
here.
B
So,
as
soon
as
we
add
workloads,
the
carpenter
will
take
care
of
and
provision
our
non-far
gate,
workloads
and
schedule
the
the
workload
there
cool,
let's
quickly,
switch
to
console
and
let's
see
what
we
got
here.
Hopefully
that's
big
enough
adrian,
please
shout
if
this
is
too
small.
I
can
make
it
bigger.
B
C
B
B
We
need
to
deploy
a
provisioner
like
I
said
before:
you're
gonna
use
a
provisioner
we're
going
to
connect
it
to
the
cluster,
we're
running
it
in
we're
going
to
say
dtl
seconds
after
empty
to
30,
so
it's
going
to
terminate
nodes
after
30
seconds
after
they're
being
emptied
and
we're
going
to
limit
it
to
two
zones.
Only
one!
A!
B
B
Okay,
let's
quickly
provision
the
sorry
deploy
the
provisioner,
so
the
provision
is
deployed
now
and
the
next
thing
we're
going
to
do.
We're
going
to
kind
of
run
a
really
simple
deployment,
so
what
it's
going
to
do?
It's
just
going
to
use
a
pause
container,
so
nothing
really
fancy
and
the
reason
why
we're
doing
that
is
we're
going
to
request
a
one
cpu
and
the
reason
why
we're
doing
this
is
by
by
using
cpu
requests,
we're
gonna
force
the
resource
exhaustion,
and
thus
the
carpenter
should
kick
in.
B
Okay,
so
let's
create
a
deployment,
so
we're
gonna
quickly
check
the
ports,
so
we're
not
running
anything
yet
because
deployment
is
currently
scaled
to
zero
and
what
we
want
to
do
here
as
well.
So
what
I'm
gonna
open
here
as
well
is
sorry,
I'm
gonna
open
locks
from
the
carpenter
controller
and
the
next
thing
we're
gonna.
B
C
B
We're
gonna
scale
the
deployment
up
to
one
right,
so
this
is
very
simple
scaling
up
to
one
and,
as
you
can
see
here
is
we
don't
have
any
capacity
available
yet
because
the
default
namespace
cannot
be
scheduled
on
fargate.
Thus,
the
scheduler
marks
this
spot
as
being
pending.
So
it's
currently
unscheduled.
B
B
There
was
a
set
of
instances
that
we
can
use
and
it
decided
that
the
most
appropriate
one
is
actually
c5
dot
x,
large
and
because
we're
using
constraint
it's
going
to
go
to
eus
1a,
and
if
we
look
at
the
nodes
you're
going
to
notice
that
there
is
already
a
new
node
being
spun
up.
Currently
it's
in
the
unknown
status,
because
the
node
is
still
booting.
Oh
yeah.
B
So
if
we
quickly
have
a
look
at
our
thoughts,
you
can
actually
see
the
container
has
already
been
created,
so
the
image
is
being
pulled
down
and
the
query
should
be
up
and
running
already.
Okay.
So
let's
move
forward.
So
let's
say
we
want
to
scale
it
even
further
right
so
let's
say
let's
scale
it
up
to
three
replicas
now.
B
So
if
we
look
at
the
containers
now
you're
gonna
notice,
oh
wow,
all
three
of
them
are
already
running
and
the
reason
for
that
is
because
the
instance
that
has
been
spun
up,
I
had
enough
capacity
to
kind
of
schedule.
Those
and
if
you
look
at
the
lock
there
is
nothing
in
log,
so
carpenter
didn't
actually
kind
of
clicked
in
because
the
controller
loop
didn't
detect
any
of
the
unscheduled
points.
B
Okay,
so
let's
scale
it
even
further
right.
So,
let's
scale
it
up
to
seven,
this
should
kind
of
kick
it
in
properly.
So,
as
you
can
see,
we
ran
out
of
resources,
cpu
resources
on
the
nodes,
and
we
ended
up
with
four
unscheduled
parts
and
carbon
detected.
Again.
We
have
unscheduled
parts,
it
try
to
kind
of
do
the
pin
packing
and
calculate
from
the
instances
that
we
are
limiting
it
to
which
one
could
actually
be
used
to
fit.
B
Four
additional
pots,
and
it
decided
the
c5
to
x
large
should
be
good
enough
to
kind
of
provision
it,
and
this
time
it
actually
went
with
eu
west
1c,
which
is
another
zone
that
we
kind
of
limited
to.
So
there
was
another
loop
going
through.
As
you
can
see,
the
second
loop
actually
didn't
find
any
provisional
parts,
so
it
kind
of
stopped
there,
as
we
can
see
here
again.
B
Another
node
is
coming
up
and
it's
currently
being
bootstrap
and
provisioned
and
should
get
added
to
the
cluster
in
in
a
bit.
So,
as
you
can
see,
the
instance
type
is
as
requested
and
it's
going
to
1c
zone.
So
let's
have
a
quick
look.
As
you
can
see,
the
containers
are
already
being
created
and
let's
wait
couple
more
seconds,
so
we
get
the
image
downloaded.
B
You
would
expect
quicker
response
times
from
the
cloud
providers,
but
I'm
sure
it's
going
to
be
running
soon.
So,
yes,
we
have
it
running.
So
what
we
can
do
actually
now
it's
like
I
mentioned
before
it
does
attach
a
lot
kind
of
a
life
cycle
hook
to
to
do
to
I'm
sorry
for
analyzer
to
the
node
lifecycle
hook.
So
if
we
decide
to
say
okay,
we're
gonna
terminate
one
of
the
nodes.
Let's
pick
this
one
and
say:
okay,
we're
just
gonna
delete
it
now
right.
B
We
we
don't
want
this
node
or
you
can
imagine
the
ttl
expired.
So
the
node
expired
is
just
gonna
go
away
and
what
is
gonna
happen
here?
You're
gonna
see,
as
I
said
before,
there
is
a
termination
controller
which
is
clicking
in
now
because
of
the
final
area.
It's
been
kind
of
triggered
and
it
cordoned
the
node,
so
the
node
has
been
cordoned
and
the
parts
are
currently
being
evicted
from
that
nodes
to
the
rest
of
the
capacity,
because
we
provisioned
enough
capacity
that
can
fit
all
the
other
nodes.
B
So
you
can
see
it's
kind
of
nicely,
interacting
with
manual
manual
interactions
as
well.
Okay,
let's
say:
let's,
let's
quickly,
let's
quickly
scale
that
down
to
zero
and
see
what
happens
now.
So
if
we
check
the
parts
now
you're
gonna
see
all
the
parts
are
being
terminated
at
this
point
and
as
soon
as
all
the
pods
are
terminated.
B
If
we
look
at
the
controller,
it
has
detected
the
under
youtube,
underutilized,
node
or
better
say
the
node
was
empty
and
it
added
a
ttl
to
that
specific
node
saying
the
node
is
empty,
let's
mark
it
with
the
ttl
and
if
there
is
no
workloads
going
to
be
scheduled
in
the
next
30
seconds,
it's
gonna
start
terminating
the
node.
Obviously
it's
gonna
first
cordon
it
as
usual
and
then
delete
the
node,
and
this
actually
deletes
the
node
not
just
from
the
cluster,
but
also
in
underlying
cloud
provider
as
well.
B
B
B
So
what
you're
going
to
notice
here
is
the
the
the
allocator
controller
initially
kicked
in
found.
There
is
a
pod
that
needs
to
be
provisioned,
obviously
it
wasn't
scheduled
and
it
immediately
start
provisioning,
a
new
node
and
based
on
the
on
the
original
constraints.
It
only
picked
from
on
the
the
arm
nodes
that
we
specified
in
the
provisioner
and
we
only
kind
of
limited
to
four
of
those
and
based
on
the
requirements.
B
It's
picked,
the
smaller
one
that
can
actually
fit
everything
in
and,
as
you
can
see
here,
it's
already
being
provisioned
and,
like
I
said
before,
in
around
a
minute
or
so
the
the
note
should
be
up
added
to
the
cluster
and
ready
to
take
on
the
the
workloads
that
are
currently
being
weighted
to
be
scheduled.
So
I'm
just
quickly
gonna
see
yeah.
It's
depending
if
we
switch
back
to
our
our
our
notes
so
about
a
couple
of
seconds
more
and
the
note
should
be
up
here.
B
So
just
before
we
wrap
it
up.
What
I
want
to
show
you
is
as
well
how
quickly
it
reacts
to
changes.
So
let's
say
we
want
to
scale
up
to
100
instances
right,
which
might
seem
a
bit
absurd.
But
if
we
check
you
can
see,
we
have
all
those
kind
of
pots
in
a
pending
state
and
carpenter
is
initially
kicking
in
finding
the
resources.
B
We
need
to
kind
of
satisfy
that
and
initially
and
immediately
start
kind
of
initializing
the
the
bootstrapping
on
the
of
the
of
the
nodes
and
kind
of
bounding,
the
parts
to
the
nodes
already.
So,
as
you
can
see,
it
immediately
added
additional
arm
nodes
which
are
going
to
be
provisioned
and
the
ports
are
going
to
be
as
soon
as
that
provision.
The
parts
are
going
to
be
assigned
and
kind
of
run
on
those
on
those
nodes.
B
So
I
think
I'm
kind
of
running
out
of
time
slowly,
but
I'm
just
going
to
wait
a
couple
of
seconds
just
to
kind
of
show
you
that
we
are
running
the
the
the
capacity
we
kind
of
requested.
It's
limited,
it's
that
we
wanted
to
it's
using
the
the
largest
capacity
available
from
the
list,
and
we
should
be
getting
our
our
workloads
kind
of
scheduled
immediately
after
after
the
notes
are
available.
So,
as
you
can
see,
the
container
has
already
been
created.
A
B
A
B
That
concludes
the
demo.
I'm
going
to
quickly
switch
back
to
my
slides.
There
is
one
more
left,
so
there
is
quite
a
quite
a
quite
quite
a
really
good
worldwide
available
on
on
the
github
so
quickly
what
the
plan
is,
but
for
the
rest
of
the
year.
So
for
q4,
the
plan
is
to
support,
know
all
known,
use
cases
and
vigorously
kind
of
test
for
scale
and
performance,
and
there
is
some
work
left
for
the
future
as
well.
B
So
from
my
talk,
what
I
really
want
to
kind
of
summarize
on
is
capacity
planning
is
really
hard.
It's
not
easy
and
what
we
get
by
using
a
solution
such
as
carpenter,
is
it
eliminates
the
no
group
kind
of
requirement
kind
of
breaks,
the
typical
kind
of
constraints
there?
It
directly
kind
of
requests
for
the
capacity
which
gives
us
the
flexibility
and
also
the
the
the
the
efficiency.
It
lowers
the
complexity
of
configuration,
it's
portable
by
design
and
quite
performant
as
well.
B
So
going
back
to
the
quote,
it
definitely
seems
like
water-like
scaling
so
trying
to
reduce
and
avoid
friction
with.
You
know
working
closely,
alongside
with
existing
kind
of
concepts
like
cube,
scheduler
and
efficiently,
responding
to
dynamic
requests
from
the
environment,
I'm
going
to
share
those
slides
afterwards.
So
I'm
going
to
leave
you
some
further
reading
and
please
do
keep
in
touch
and
I'm
happy
to
answer
any
of
the
questions
that
might
come
come
across
back
to
you.
Adrian.
C
Thank
you
very
much
mark.
I
think
it
was
excellent.
There's
a
lot
of
in-depth
knowledge
there
and
yeah.
I
think
it's
one
thing
it
trips
up
a
lot
of
people.
They
don't
realize
how
hard
like
scaling
is.
We
do
have
a
question
from
tim
bannister
who
asks?
Can
I
use
carpenter
to
skew
bracket
spin
pack,
my
workload
onto
the
most
cost-effective
set
of
nodes?
What
other
components
would
I
need
to
make
that
work.
B
So,
yes,
they
would
automatically
try
to
pick
the
most
cost
effect.
Effective
instance
types
that
you're
limited
to
so
you
can
already
achieve
that,
but,
like
I
mentioned
before,
unfortunately,
the
the
fragmentation
is
not
implemented
yet,
so
you
would
end
up
with
the
initial
kind
of
resources
that
would
be
provisioned
and
it
wouldn't
be
you
kind
of
optimized
for
the
for
the
workloads,
but
if
the
nodes
get
emptied,
that
would
definitely
get
kind
of
shut
down,
and
it
already
works
like
that.
B
C
A
One
more
message
for
control:
plane,
who's,
the
final
sponsor
for
the
event,
so
patrol
plane
are
a
london-based,
cloud-length
technology
company
and
they
help
to
keep
people
safe
online.
They
work
with
cloud
providers,
banks,
insurance
companies
and
governments
to
secure
the
building
blocks
of
the
internet,
with
consulting
training
and
products
related
to
cloud-native
development,
security
and
operations.