►
Description
Kubernetes promises to run containerised workloads efficiently and at scale. It also provides auto-scaling features where the workloads can scale to meet the demands of the traffic. None of this is available by default and work needs to be done to reach the Kubernetes promised land. This talk will focus on how to architect Kubernetes clusters for high traffic websites or workloads. Attendees will learn how to configure ingress controller to securely expose workloads to external traffic. A demo will be presented which will show how Prometheus can be used to collect metrics from workloads. These metrics will then be fed to Kubernetes Pod Autoscaler using KEDA (Kubernetes Event-driven Autoscaling) to automatically scale the pods to meet the demand.
A
B
Okay,
welcome
everybody
good
morning
Amsterdam.
How
are
we
all
doing
yay?
This
is
the
last
session
before
lunch,
so
try
and
keep
it
light
right.
Imagine
you
have
a
website
could
be
any
website
and
there's
some
traffic
coming
to
it
and
it's
working
fine.
But
at
some
point
you
launch
a
new
product,
I,
don't
know
iPhone
or
whatever,
and
there's
a
lot
of
people
coming
to
your
website
now
and
there's
not
enough
traffic
being
served
and
people
are
not
happy.
B
What
should
happen
is
that
we
should
use
what
kubernetes
been
promising
us
right,
the
auto
scaler
you
can
Auto
scale
it,
but
it
doesn't
do
everything
by
default.
There's
some
work
that
we
have
to
do
in
order
to
do
that,
and
that's
what
we're
going
to
look
at
today.
How
do
we
Auto
Scale,
based
on
some
events
and
basically
scale
out
the
website,
and
let
people
do
what
they
need
to
do,
but
before
we
start
because
you've
all
come
here,
I
thought
we
should
reward
you
with
something.
B
Everybody
know
this
talks
right:
the
Linux
talks,
it's
a
Lego
I.
Have
this
Lego
right
here
we
like
like
who
likes
Lego
yeah,
but
everybody's,
not
going
to
get
like
that.
You
know:
there'll
be
a
bit
of
a
quiz.
Just
one
question
shout
out
the
number
people
know
about
the
landscape:
cncf
landscape,
the
cncf
landscape.
B
No,
not
that
one,
this
one
right!
So
this
this
landscape!
This
shows,
you
know
we
were
talking
about.
Sarah
was
talking
about
this
morning
about
choices
and
how
many
choices
we
have
there's
a
lot
of
projects
on
there
or
cards.
So
here's
a
simple
question:
the
question
is
how
many
cards
are
on
the
cncf
landscape.
Some
of
you
might
already
know
this,
but
I'm
not
unreasonable,
so
I'm
going
to
give
you
a
bit
of
a
hint.
B
B
Was
that
one
thousand
keep
going
1200
I
think
yeah?
Let's,
let's
stop
here,
one
one
Central,
that's
very
good!
A
rhino
flows
to
that
gentleman
there
can
you
just
pass
it
on
1174,
enjoy
the
Lego
I,
don't
know
how
long
it
takes
to
make
it,
but
apparently
the
instructions
are
as
good
as
what
we
see.
So
just
a
few
more
things,
that's
one
one.
Seven
four
projects
on
there,
I
I,
just
put
out
some
more
stats
on
here.
B
It's
from
it
says
of
last
night,
three,
six,
the
3.6
million
stars,
but,
more
importantly,
like
countless
of
community
Stars
right
people
who
are
working
on
these
projects
in
their
own
time,
so
great
and
some
some
of
the
other
stuff
there.
So
this
was
as
of
last
night
1174,
but
when
I
woke
up
this
morning,
it's
it
looks
a
bit
like
this.
It
keeps
increasing
every
day
right
so,
but
I
know
you're
a
bit
disappointed
that
you
didn't.
B
You
didn't
win,
maybe
that
Lego,
but
don't
worry,
I
work
for
app
beer
and
we
have
boots
downstairs.
If
you'd
like
to
win
some
of
this
stuff,
we
have
some
cool
stuff.
So
just
come
through,
we
are
downstairs
the
mark,
Lucy
and
auroria
down
there
and
I'm
gonna
read
myself
there.
So
if
you
want
to
come
and
have
a
chat,
I
work
for
a
company
called
Appiah
as
an
mlops
engineer,
and
we
are
a
startup
we're
a
consultancy.
B
We
have
a
product
that
helps
you
deploy
stuff
to
Cloud
easier
and
also
work
as
a
kubernetes
instructor
for
learnkates
check
out
our
website
learncase.io,
and
we
have.
We
have
a
bunch
of
blogs.
You
can
find
me
on
Twitter
at
soulmatebar.
I
also
have
a
bit
of
a
YouTube
channel.
You
can
check
that
out.
So
romantic
ball.
So
that's
Appiah,
appia.io
check
us
out
I
have
to
make
sure
I
put
that
there,
because
I
need
to
get
paid,
so
we're
done
with
that,
but
yeah.
B
B
Thank
you.
Thank
you.
So
much
so
and
also
I
want
to
thank
my
friend,
Daniella
palencies
from
learnkates,
who
helped
me
put
together
this
this
presentation.
So
thanks
to
Danielle.
So
here's
what
we're
going
to
do.
Brief,
look
at
services
and
a
quick
look
at
ingresses,
I'm
sure
you're,
already
aware
of
what
those
are,
but
just
to
make
sure
we're
all
on
the
same
page
and
then
we'll
look
at
cada.
B
B
This
is
imagine
a
deploy,
a
website
and
it's
just
a
static
page,
and
if
you
want
to
deploy
this
in
kubernetes,
usually
you
deploy
the
website
and
you
have
to
stick
in
a
load
balancer,
because
you
need
to
make
sure
the
traffic
is
distributed
evenly
and
you
can
have
multiple
load
balances
because
you
might
be
running
multiple
applications
inside
and
then,
if
you're
running,
multiple
applications.
You
want
to
make
sure
you
route
the
request,
based
on
the
request
that
they've
sent
to
so
in
kubernetes.
B
As
we
all
know,
the
internal
load
balances
are
Services,
they
pick
the
right
pot
to
send
and
then
the
the
the
the
the
top
layer
load
balancer
is
called
in
Ingress.
So
this
is
sending
requests
from
outside
the
cluster
to
inside
the
cluster,
and
then
we
have
pods
I'm
sure
we'll.
We
all
know
this,
so
this
is
so.
This
is
what
it
is.
B
We're
going
to
focus
on
on
Ingress
today,
but
before
I
can
talk
about
Ingress,
it's
important
to
just
point
out
really
quickly
what
services
are
and
or
the
limitations
of
services
in
in
the
context
of
running
websites,
and
why
do
we
need
Ingress?
So
every
time
you
deploy
an
application
inside
a
pod,
a
container
or
multiple
containers
gets
an
IP
address,
and
then
we
use
Service
as
an
abstraction
layer,
because
it's
convenient
to
to
have
an
abstraction
layer.
We've
sent
a
request
from
another
pod
or
from
outside
somewhere.
B
The
service
knows
how
many
pods
live
underneath
it
and
it
can.
Basically,
you
request,
you
send
a
request
to
the
service
and
it's
it's
an
abstraction,
so
that
makes
a
request,
and
only
the
service
knows
how
many
pods
are
running.
So
you
could
have
two
and
if,
if
a
pod
dies
or
comes
back
up,
it
doesn't
matter,
it
will
keep
track
of
it.
It'll
pick
it
and
all.
If
it
goes
up
to
10,
pods
up
or
down
doesn't
matter
the
Pod
that
is
sending
a
requests
doesn't
need
to
know
anything.
B
It's
the
service
that
needs
denied.
So
that's
very
high
level
service
definition.
If
you
would
ask
chat,
GPS
I,
guess
that's
where
it
would
give
you
but
there's
different
kind
of
services.
We
have
a
headless
service,
that's
a
building
block
and
the
most
basic
service.
It's
basically
like
all.
It
is
just
an
endpoint.
The
IP
address
it's
not
very
good,
with
load
balancing.
So
what
what
kubernetes
also
provides
is
a
is
the
default
service.
B
So
if
you
create
a
service
in
kubernetes,
cluster
IP
extends
headlets
kind
of
like
a
load
balancer,
so
it
does
a
better
job
than
headless
for
load
balancing.
Then
we
have
so
the
two
services
so
far,
they're
all
internal
Services.
You
can't
expose
it
to
the
outside
cluster
outside
of
the
cluster.
So
then
we
have
this
thing
called
node
Port,
this
external
service,
you.
It
basically
opens
a
port
on
each
node,
but
you
might
have
multiple
nodes
running.
B
So
what
kubernetes
provides
is
another
kind
of
service
called
the
load
balancer
service
and
it
it
just
has
a
node
port
and
if
you're
in
a
cloud
provider
it
Provisions
an
actual,
a
load
balancer
and
attaches
it
to
the
nodes.
If
you're
doing
this
on
premises
that
you've
used
a
service
type
load
balancer,
you
have
to
have
some
kind
of
a
project
like
metal
lb.
That
allows
you
to
do
that,
but
it's
kind
of
useful.
If
you're
doing
with
the
cloud
provider
there's
a
couple
of
things
there
there's
a
few
gotchas
with
services.
B
The
good
thing
is
that
automatically
Provisions
the
the
load
balancer.
So
we're
talking
about
external
Services,
because
we
want
to
make
sure
we
can
access
the
website
from
outside
of
the
cluster.
It's
automatic
provisioning,
it
Provisions
the
nodes
on
the
ports
and
attaches
it
to
the
load
balancer.
But,
as
I
said,
it's
cloud
provider
specific
and
if
you're
doing
on-premises,
yet
there's
extra
work,
you
need
to
do
and
I
don't
know
if
you
have
done
this
like
I'm,
pretty
sure
you're
aware
Cloud
providers
are
not
cheap
in
the
club.
B
In
sorry,
load
balances
are
not
cheap
in
the
cloud
provider.
Imagine
if
everybody's
spinning
up
a
load
balancer
for
their
application
could
be,
could
cost
a
lot
of
money
and
the
limitation
is
it's
basically
just
layer.
Four,
if
you
wish
to
expose
services
that
use
TCP
or
UDP
services
are
good.
Your
application
is
good.
So
this
is
where
we
need
something
like
this:
an
Ingress,
something
that
can
understand
HTTP
requests
and
can
deal
with
it
and
send
the
request
to
a
service,
and
that's
why
we
have
the
service.
B
We
have
this
Ingress
that
sits
on
top
of
service.
I'm
sure
you
will
know,
but
that
is
what
it
is.
What
we
can
do
with
an
Ingress
is
we
can
root
traffic
based
on
the
requests
that
we
make,
for
example,
in
this
I
have
this
cluster
with
multiple
applications,
the
red,
the
green
and
the
yellow,
and
you
can
do
part
based
routing.
So
if
somebody
says
example.com
forward,
slash
account
send
them
to
the
the
Reds,
the
red
pods.
B
If
somebody
says
forward,
slash
checkout
send
them
to
the
yellow
pod,
and
so
this
is
where
Ingress
comes
in
quite
handy
or
also
you
can
do
subdomains
like
if
you
need
to
do
domain-based
routing.
You
can
do
all
of
this.
So
that's
what
an
Ingress
is
right.
So
that's
the
Ingress,
the
point
of
in
English
everybody
happy
so
far
are
we?
Are
we
all
good,
okay,
cool?
So
so
far,
I've
shown
you
Ingress
as
just
a
black
bar.
That's
all
it
is
and
I'm
sure
you
already
know
this.
B
It
turns
out
that
an
Ingress
is
just
a
deployment,
a
regular
deployment
of,
depending
on
the
type
of
Ingress
controller.
You
pick
there's
different
Ingress
controllers
and
a
service
usually
load,
balancer
or
notebook,
because
you
know
it's
like
external
service,
so
you
can
expose
it
and
in
this
diagram
you
can
see
that
the
black
bar
has
been
disappeared,
has
disappeared,
and
now
we
have
this
service
load
balancer
type
and
we
have
an
Ingress
pod.
In
this
case
we
have
nginx.
B
B
So
it's
basically
a
regular
deployment
and
Ingress
comes
in
two
parts.
You
have
this
thing
called
the
Ingress
controller.
Basically,
the
pod.
That's
running
that
understands
what
to
do
with
the
rules
that
you
write
and
the
rules
are.
Those
Ingress
manifests
that
you
write
these
yaml
files
right.
So
these
yaml
people
written
the
singular
saml
file
before
right.
Yeah
have
people
written
it.
One
person
has
in
this
room,
I'm
sure
there's
more
than
one.
Oh
good.
Good.
Excellent
people
have
written
this
right.
B
So
this
is
this
in
Ingress.
Is
writing
the
rules
of
defining
what
should
happen
to
the
request?
Where
should
it
go
to
which
service
should
the
request
go
to
so
we
write
this
yaml
file
and
we
submit
that
to
the
kubernetes
cluster.
The
cluster
takes
that
request
and
it
stores
the
information
inside
a
net
CD
database
and
we
have
a
couple
of
components,
and
here
we
have
a
scheduler
of
a
controller
manager,
but
that
information
goes
in
and
goes
and
goes
ahead
and
gets
stored
in
the
hcd
database.
B
That's
why
we
store
the
state,
the
desired
State
and
the
current
state
and
the
controllers
do
the
magic
and
make
sure
the
the
state
the
desired
state.
The
current
state
always
goes
closer
to
the
desired
state.
So
that's
what
it
does.
But
when
you
deploy
this
rule,
the
Ingress
yaml
file,
the
cluster
itself,
will
the
the
Ingress
pod
the
controller
will
spin
up.
It
will
get
the
information
from
the
Ingress
because
hcd
and
it
will
configure
the
rules
so
nginx
config.
B
If
you
use
nginx,
it
will
configure
the
rules
in
nginx
config
to
say
if
this
is
the
the
Pod,
you
need
to
send
the
request
to
this
service.
That's
all
it
does
right
and
then
it
will
just
write
or
if
you
write
another
another
Ingress
we'll
take
that
rule.
It
will
update
its
config
and
it
will
understand
this.
B
So
here's
the
thing
if
you're
running
a
website,
so
that's
Ingress
and
service
and
that's
our
backstory.
But
if
you
run
a
website
now
we
understand
the
request
has
to
come
from
outside
of
the
cluster,
so
it
has
to
go
via
the
Ingress
pod.
In
this
case
it's
nginx.
If
it
goes
by
the
engine
export
and
if
a
lot
of
traffic
comes
in,
you
might
end
up
with
a
bottleneck.
If
you
have
just
one
replica
running,
you
might
say
hey.
B
What
should
happen
is
that
if,
if
a
ton
of
traffic
comes
in,
we
should
scale
out,
you
might
say:
oh,
maybe
I
can
just
start
with
the
10
Ingress
pods
running
at
all
times,
which
is
fine.
You
can
do
that,
but
of
course
it's
going
to
cost
you
money.
So
if
you
want
to
save
some
money
in
these
times,
especially
in
the
UK,
because
the
pound
is
very
down,
we
need
to
make
sure
that
we
can
scale
down
when
we
need
to
so
what
you
can
do.
B
As
I
said
in
Ingress,
the
deployment
is
a
normal
deployment.
You
can
configure
this
if
you
deploy
a
new
cluster
as
a
Helm
chart
or
whatever
it
is,
you
can
configure
these
settings.
You
can
change
these
settings,
you
can
say,
there's
there's
a
file
in
here.
There's
a
line
in
here
called
replicas
I
can
open
the
file,
change
it
to
three
replicas
and
submit
it
to
the
cluster
and
I'll
have
three
replicas,
but
it's
not
very
scalable.
It's
not
very
you
know
you
have
to.
B
Maybe
you
have
to
wake
up
at
2
am
in
the
morning
we
need.
We
need
something
good
right.
We
we
don't
want
to
wake
up
to
him
in
the
morning.
We
want
it
to
happen
automatically,
so
this
is
enter
our
helper,
the
horizontal
pod
Auto
scaler,
it's
a
resource
in
kubernetes
that
scales
out
the
pods.
The
vertical
pod
Auto
scaler
is
different.
It
changes
the
CPU
and
memory,
so
it
can
increase
more
CPU
and
memory
for
horizontal
portal
to
scalar
spins
up
more
pods.
B
B
What
horizontal
pod
Auto
scale
can
do
is
it
can
query
some
Metric,
let's
say
number
of
active
connections
inside
each
pod
right.
That
sounds
like
a
reasonable,
reasonable
metric.
Let's
say
you
can
query
that
metric
and
we
can
write
a
rule.
We
can
say
hey.
If
each
part
is
has
got
more
than
100
connections.
We
need
to
scale
up
reasonable
request.
Let's
say,
then:
what
should
what
horizontal
plot
autoscaler
do
it
does?
B
Is
it
will
do
its
calculation
and
if
you
breach
the
threshold
it
will
automatically
adjust
the
deployment
and
it
can,
you
can
scale
up,
add
another
pod
and
scale
back
down
and
remove
all
the
pods
that
we
that
we
don't
need.
So
what
we
want
to
do
is
Scale
based
on
incoming
traffic
with
me.
So
far,
everybody
good.
B
I
know
it's
15
minutes
to
lunch,
so
we're
we're
on
track.
Don't
worry
we're
on
track,
so
what
we
want
to
do
is
we
basically
want
to
scale
on
HTTP
requests
coming
in?
Basically,
the
request
is
coming
in,
but
you
can
do
it
on
any
metric.
You
prefer
in
our
case,
we'll
just
do
it
on,
let's
say
active
connections,
so
we
first
of
all
we
need
to
have
metrics
available
and
we
need
to
expose
it.
So
the
horizontal
part
autoscaler
can
take
those
metrics
and
do
something
with
it.
B
So
usually
you
would
write
in
in
your
application.
You
do
forward
slash
metrics
and
you
can
write
key
value
pairs
in
there
and
just
in
your
application,
make
it
available.
So
something
like
Prometheus
can
can
scrape
it,
but
we
take
that
metrics.
We
need
to
store
those
metrics,
because
you
know
the
requests
have
to
come
over
time.
We
need
to
store,
it
just
run
our
calculation
and
then
once
we
store
it
so
collect
and
store
it
and
then
we're
going
to
do
auto
scaling.
B
We
have
based
on
those
metrics,
we'll
write
some
rules
and
we'll
Auto
scale,
and
this
is
what
you
see
in
the
demo
as
well.
So
what
we
have
is
luckily
for
me,
it
makes
the
demo
easier.
Nginx
provides
already
some
metrics.
That's
so
I
don't
have
to
write
anything
from
scratch.
Engine
export
has
forward
slash
metrics.
It
provides
these
metrics
in
here
we
can
take
this
metric.
Nginx
connections
active.
So
this
is
all
the
actual
connections
coming
in.
That's
what
we're
going
to
take
they're
available,
but
we
need
to
scrape
the
metrics.
B
So
what
we
can
do
is
we
can
use
Prometheus
people
like
Prometheus
here.
Anybody
like
Prometheus
yeah
we've
got
it's
a
great
project
right,
so
we
basically
what
it
does
is
it
helps
us.
You
have
something
called
a
metrics
server
in
kubernetes
that
that
can
that
can
be
that
can
be
used
to
pull
out
the
metrics
from
whatever
resource
that
we
want
to
pull
out
from
you,
take
that
off
from
cubelet
and
provides
it
to
other
resources
like
horizontal
pod,
Auto
scalar-
and
this
is
where
we
can
use
Prometheus
Prometheus-
allows
us
in
Prometheus.
B
We
can
scrape
the
metric
and
then
store
it
whatever
we
like
in
this
case
we're
going
to
store
it
in
something
else.
But
what
we're
going
to
use
is
Prometheus.
You
don't
have
to
use
Prometheus,
but
in
this
in
this
one
we're
going
to
use
premises
and
I
have
a
cluster
that's
running
locally,
which
has
parameters
already
installed
and
then
we're
going
to
use
this
project
called
cada
or
Kita
kubernetes
event.
Driven
Auto
skating
have
people
heard
or
use
this
project.
Oh
yeah
excellent.
B
We
have
quite
a
few
people,
so
if
you
get
stuck,
you
can
come
up
and
you
know
give
me
a
hand
if
the
demo
doesn't
work,
but
it
should
be
good.
So
here's
the
thing
we
need
to
expose
the
metrics.
We
need
to
store
them,
so
we
can
scrape
it
using
Prometheus.
We
need
to
store
the
metrics
and
then
we
basically
needed
some
kind
of
an
adapter
that
can
take
the
information
and
feed
it
to
the
resource
metrics.
So
we
can.
B
You
can
scale
on
that.
So
there's
a
bunch
of
scalers
that
KDA
already
provides
that
we
can
plug
into
even
stuff
like
SQL
queries,
run
SQL
query.
If
the
result
is
above,
some
number
do
something
with
it.
So
that's
where
we're
going
to
use
cater.
What
we
can
do
is
quite
flexible,
it's
open
source
and
it
drives
the
horizontal
pod
or
the
scalar.
Something
needs
to
feed
all
this
information
to
the
horizontal
pod,
Auto
scaler,
to
be
able
to
scale
it
and
and
that's
what
we're
going
to
use
Cada.
B
What
is
it
so?
We
have
the
metric
server,
as
I
talked
about
before.
Just
briefly
is
used
to
collect
metrics
from
cubelet,
so
the
cubelet
that's
running
on
each
node.
It
collects
metrics
from
there
and
exposes
it
to
the
kubernetes
API
and
it
plugs
into
the
aggregator
API.
But
what
we
have
is
this
metric
server.
B
It's
not
enabled
by
default,
so
you
have
to
enable
it.
But
when
you
install
with
the
in
Kate
on
the
cluster,
it
will
be
enabled,
and
then
we
need
an
adapter
it
would
you
know
Prometheus
adapter
same
Cade
also
provides
one
it
can
collect
and
serve
custom
metrics
to
an
external
metrics
to
the
horizontal
portal
to
scaler
Kayla.
Has
it
and
a
controller
that
sits
in
the
cluster
and
acts
upon
the
events?
B
So
that's
that's
what
we
need.
So
if
the
controller
is
there
we're
going
to
have
a
bunch
of
custom
resource
definitions,
so
things
that,
with
things
that
cater
defines
and
I'll
show
you
an
example
of
that
and
controller
is
something
that
extends
kubernetes
and
does
a
functionality.
And
then
we
have
what
are
called
scalers.
We're
not
going
to
talk
about
them
today,
but
this
is
I
briefly
mentioned
it.
You
know,
if
you,
for
example,
you
can
based
on
you,
can
Define
some
rules
based
on
requests
coming
in
from
rabbitmq.
B
You
can
scale
out
your
application
or
there's
a
lot
of
cloud
watch.
Events
like
AWS
cloudwatch,
anything
in
Pub
sub
in
the
cloud
provider.
It's
very
neat
and
it's
quite
easy
to
set
up,
and
so
this
is
where
cada
is
cada
comes
in
handy
and
that's
what
we're
going
to
do
a
demo
on.
So
we
have
10
minutes.
So
a
lot
can
go
wrong
in
10
minutes,
but
so
there's
the
demo
we're
going
to
do
live.
If
it
fails.
B
I
have
a
video
as
well,
but
we'll
Pretender
was
live
if
it
if
it
failed,
but
I'm
sure
it'll
work.
So
you
can.
If
you
want
to
check
out
Danny
Elliot
wrote
the
blog
for
this
bit.ly
forward,
slash
kcd
scaling
and
it
runs
on
minicube.
You
can
run
it
yourself
or
you
can
run
in
any
cluster
you
like,
so
that's
that's
where
that's
where
explanation
and
and
the
code
and
everything
is
there,
so
definitely
check
that
out.
So
what
what
I
got,
which
I'll
show
you
in
a
minute
is
a
mini.
B
Cube
cluster
is
running
I've
installed,
Ingress
nginx
Ingress
on
it
already,
because
I
do
not
trust
the
internet
during
demos.
So
it's
already
running
and
I've
also
installed.
Prometheus
and
cada
I've
used
hum
for
it,
but
you
can
install.
However,
you
like
it's
just
one
command
line.
Spins
up
the
pods
I'll
show
you
the
pods
in
a
second
and
then
what
we
need
to
do
is
we
need
to
have
a
way
of
generating
some
load
right
because
otherwise
you'll
think
I'm
making
it
up.
So
we're
going
to
use
a
locust.
B
B
We'll
give
it
a
second
for
it
to
pop
up
all
right,
we're
cool
here,
so
here's
a
few
things
that
we
got,
which
I'll
put
actually
put
in
around
so
this
is
all
real.
There
is
a
deployment
file,
I've
deployed,
Stefan's
pod
info
pod,
I'm
sure
you've
seen
this
it's
running
and
everything
is
running
locally
at
I
trust,
internet,
but
not
during
demos.
So
everything
is
running
locally.
So
that's
the
pod,
that's
running!
B
It
has
a
service,
of
course,
as
well
support
and
a
service
I,
don't
know
if
it's
big
enough,
but
let
me
is
that
is
that
good,
reasonable
size
cool,
so
we
have
service
and
a
pod
that's
already
deployed
and
we
have
an
Ingress
and
in
Ingress
you
can
see,
there's
a
there's
a
bit
of
a
the
rule
here.
Example.
That
goes
to
example.
B
If,
if
the
request
is
for
example.com,
send
it
to
the
Pod
info
service,
so
I'm
not
making
any
of
this
up,
because
if
I
can
do
a
clear
k,
get
pods,
you
can
see
in
a
second
there's
some
some
stuff
running.
So
we
have.
We
have
our
deployment
here,
the
podium
for
deployment.
We
have
kader
I've
also
installed
K
down
here.
The
operator
is
running
and
we
got
a
bunch
of
crds
to
go
with
it
and
we
have
pod
info
sorry.
We
have
nginx
Ingress
running
and
we've
got
some
of
the
Prometheus
stuff.
B
I
know
no
kubernetes
demo
is
complete
without
running
Cube
CT
or
get
pods,
so
I
just
want
to
get
that
out
of
the
way.
So
that's
done
now
we
can.
We
don't
have
to
look
at
this
instead
of
me
showing
you
lines.
We
have
a
dashboard
here
right.
So
these
are
all
the
pods
that
running
in
the
cluster.
Let
me
see
if
I
can
zoom
in
these
are
all
the
pauses
running
in
a
cluster.
It's
not
it's
not
a
photo,
it's
an
actual
like
dashboard,
and
we
have
one
nginx
pod
running.
B
So
that's
all
good
I'm
going
to
put
that
to
the
side
and
we're
gonna
step
onto
here
and
Prometheus
is
also
running.
We've
got
five
minutes
which
is
good,
but
that's
all
we
need
and
let
me
just
quickly
zoom
out
for
a
sec
if
I
execute
this,
this
is
nginx
ingress,
active
connections.
Basically,
what
we're
talking
about
you
can't
see.
This
is
quite
small,
but
there's
only
one
request,
because
there's
only
one
request
that
that
was
running
and
then
what
I've
also
deployed
is
Locust
and
Locust
is
an
open
source
project.
B
Let's
just
open
this,
and
all
it
has
got
is
got
its
own
deployment,
but
in
here
you
can
define
a
config
map
and
a
config
map,
we're
defining
you
have
this
Locust
file,
dot
py,
that's
written
in
Python,
but
you
can
give
it
a
task,
and
all
this
is
doing
is
allowing
me
to
send
requests
to
example.com.
That's
all
it's
doing,
I
want
to
send
request
to
example.com
and
because
it's
Locust
I
can
do
a
bunch
of
things.
B
I
can
give
the
host
I
need
to
send
the
request
to
how
many
users
I
want
to
send
per
second,
and
what's
the
what's
the
so,
what
we
can
do
is
we
can
start
swarming
The
Host.
We
can
start
sending
requests,
let's
hit
on
the
chart.
I,
don't
know
if
it's
let's
just
do
this
is
this:
is
that
stuff
there's
some
something's
about
to
go
wrong
bound
to
go
wrong?
But
let's
go
there,
you
go
charts.
B
B
That's
the
name,
and
the
query
is
this:
all
we're
saying
is:
if
the
nginx
Ingress
connections
active
is
more
than
100.
So
that's
the
threshold.
Do
your
scaling?
Do
your
thing.
So,
let's
just
see,
if
I
can
execute
this,
you
can
see
in
here
it's
a
very
faint
line
on
on
the
edge
there,
but
there's
there's
a
number
of
requests
there
going
in
there's
only
one
now
we're
going
to
focus
on
this
part
here.
B
What
we'll
do
is
deploy
the
scaled
object
and
we
should
see
a
number
of
nginx
PODS
increase
if
it
does
go
wild
if
it
doesn't
still
go
wild
Let's.
Let's,
let's
do
this
we're
gonna.
Do
a
minus
F4,
we'll
apply
the
scaled
object
and
what
this
will
do
is
okay,
that's
created,
and
what
this
will
do
is
we'll
you
look
at
the
metrics
and
it
will
start
increasing
okay
get
deployed.
Let's
just
do
that.
It
should
eventually
start
increasing
the
number
of
pods.
B
B
You
can
do
this
for
any
any
workload
that
you
might
need
so
I'm
just
going
to
do
one
last
thing,
if
you,
if
you
want
to
let's
just
hop
back
on
this
okay
where's
my
point:
let's
go
in
here
all
right:
let's
go
so
that's
what
you
saw.
You
saw
us
gather
some
metrics
and
we
just
talked
about
Services
ingresses.
Then
we
expose
some
metrics
and
we
gather
them.
We
kubernetes
doesn't
do
this
by
default.
There's
a
lot
of
work.
B
We
have
to
do
to
get
all
of
this
running
and
you
saw
that
if
you
want
to
try
it
try
it
out.
As
I
said
it
already
is
a
Blog
for
this
bit.ly
forward,
slash
kcd
scaling
check
out
learnkates.io.
We
do.
We
have
some
awesome
blogs
in
kubernetes
and
we
do
some
training
as
well
to
check
that
out.
Also
check
out
appear.io
if
you
have
any
questions
or
anything
like
that,
I
am
downstairs
all
day.
This
is
our
booth
in
one
of
the
areas
come
and
grab
me.
B
A
Thank
you,
Salman.
That
was
pretty
pretty
intense,
very
good.
The
demo
guards
have
been
listening
to
you
while
I
was
watching
Salman,
I,
I
started.
Thinking
of
an
experience
I
had
excuse
me
excuse
me
people
that
are
leaving
the
room.
One
thing
there
is
a
workshop
going
on
please
go
outside
through
and
to
left
to
the
sponsor
area.
Lunch
is
going
to
be
in
the
sponsor
area,
served
and
lightning
talks
in
the
workshop
area.
So
back
to
us
what
I
was
what
I
was
thinking
is
I
always
thought.
A
A
Too,
so
that's
what
I
thought
I
thought:
why
shouldn't
it
be
an
online
tool,
so
I
went
the
stupid
way.
That's
when
I
realized
that
I'm
I'm,
not
above
average,
quite
below
and
I,
wrote
my
old,
my
my
very
own
tool
to
Marshall
two
days
later.
The
color
mindset
but
I
use
this
one
online
tool
and
yeah
you're,
not
very
kind
so
anyway.
Thank
you
very
much.
It
was
very
good.
A
Thank
you
and
what
I
would
like
to
invite
you
again
guys,
please
let
the
workshop
guys
go
on
go
through
the
smoking
area
outside
grab
a
smoke.
If
you
like
or
don't,
and
then
you
go
through
the
sponsor
area
there
you
can
grab
your
lunch
is
going
to
be
served,
we're
going
to
be
having
the
lightning
talks
in
the
workshop
area
and
I'm
gonna
see
you
here
at
quarter
to
two
at
1
45
with
Robin
sickman
from
ING.
Thank
you
very
much.