Everything I know about Kubernetes I learned from a cluster of Raspberry Pis

- [Jeff] As I told everybody
in here, I always forget that

so it's good that my track
record is very consistent.

So next time, I'm gonna
forget to hit the button, too.

But anyway, hopefully you're
here for this presentation.

If not, you can go and
find another good one.

This is me.

I am a technical architect at Acquia.

I work in a lot of infrastructure stuff

but kind of, if you know Acquia,

we do a lot of different things.

I'm in a partly obscure team
that doesn't actually do

a lot of whole lot of Drupal work but I do

some Drupal work in my day-to-day.

But this project is more of

a passionate side project for me,

not something that we do much at Acquia.

Don't worry, we're not running

enterprise websites on Raspberry Pis.

(audience jeers)

This picture here, yeah,
after this presentation.

I'm sorry for putting a
very succulent picture

of raspberry pie on the screen.

This is not what we're talking about.

If you came here for a cooking class

on how to make some Kubernete-ful
raspberry pies to eat,

that is not what we're gonna go over.

We're gonna talk over
the Raspberry Pi computer

and I heard a couple people say this

before the presentation
but the one question

that pretty much everyone universally asks

after they get a Raspberry Pi is

what can I actually do with this thing?

And they're cheap enough that
a lot of us just buy them

because we're techies, we're nerds,

we like computing things
and they're really cool

and we might have seen a blog post

of somebody doing something cool so like

if I buy a Raspberry Pi,
I'll do something cool, too.

But that doesn't always follow.

How many people here
have the Raspberry Pi?

How many people here have
it sitting in their drawer

or shelf or somewhere?

(audience laughs)

Okay, so it's pretty true,
it's pretty universally true.

So I'm a little crazy and
we're running Kubernetes

at Acquia on a few different projects

and we're building very massive things

using these big, hulking servers.

But I wanted to see like on
the very, very opposite end

of that spectrum, on the
lowest class of machine,

how well can I actually run Kubernetes

which is like a cloud scale

massive deployments type of thing,

how well can it run on a
cluster of Raspberry Pis?

I've been toying around
with these clusters

for about five years
now with Raspberry Pis

with a lot of different
little projects that I do

and Kubernetes kind of
caught my ear in 2016, 2017

when it started getting all
the hot VC capital funding

and things like that 'cause
anytime there's something

new and cool looking in
the infrastructure world,

lots of dollars follow very quickly.

I didn't do it for the
money but, you know,

if anybody here wants to throw
a few million dollars my way

to build the next Raspberry
Pi hosted Kubernetes

cluster service, I'm available to talk.

So anyway, I wanted to
go a little bit crazier

and deeper than that, though.

Not only do I want to run
Kubernetes on these things,

I want to run a heavyweight
CMS that can run

ambitious digital experiences
on these Raspberry Pis.

I have kind of insane requirements here

and before I get into
that part of it though,

there's a lot of people here who might not

be that familiar with Kubernetes.

Kubernetes is a very large ecosystem.

It has a lot of different moving parts

but I want to distill it down to something

that I can fit into a

which only has 28 minutes left.

So at a very basic level,
let's take a typical,

mid to upper tier Drupal site.

You're going to have a
lot of different things

we're gonna run.

You have to run Drupal
which is like Drupal,

it might use PHP and Engine X

or it might use Apache with PHP built in.

But something has to run Drupal itself.

You also have to have a database

so MySQL or Postgres or
some other database running.

You might have Apache Solar for search

to make your searches faster and better.

You might have elastic search.

You might have a chat integration

that runs with a node JS app.

You might have some sort of
more advanced Cron system

so an external Cron schedule or something.

If you have all these
different things running,

you might have a centralized
logging dashboard

that has to run for it.

You might also have
caching so Redis or unCache

or something running.

So a Drupal site requires a lot of things

if you're gonna run it at scale

or if you want to run it
with high availability

and the ability to not have downtime.

And every application
has varying requirements

but a lot of things require at least like

the database and your
application or something else.

And you also have lots
of servers nowadays.

So most projects that I've been working on

in the past five or 10
years have some level

of either service level agreement

or high availability that they expect

and you can't get that
with one server somewhere.

There's a lot of projects
that can run on one server

but for a lot of these other projects,

we need more than one server because

if you run on one server
and that server goes down

which happens very much,
even fancy cloud environments

where servers are virtual

and they can pop from host to host,

your servers will go down
and when they go down,

what happens?

So nowadays we have lots of
servers and traditionally,

you would have some sort of system,

maybe you use configuration management

or some bash scripts where
you cross your fingers

and run a bunch of manual
commands on servers

and you get those things
running on those servers

but it's not super efficient

and when one of those servers goes down,

you still have to do
something and intervene

to get the services that were
running on it somewhere else.

So at a very basic level, now this is not

a technical definition of
all that Kubernetes does

but on a very basic level,
it puts your stuff on servers

so you have servers, you have stuff,

you get your stuff on the servers,

and then it also makes
sure that they keep running

the way that you want them to run.

So I'll show you a little bit
more about that in a minute.

You might be a little
skeptical at this point.

You might be wondering
so you're building this

Kubernetes cluster.

Kubernetes sounds kind of complicated

if it's doing scheduling stuff,

scheduling's always hard no
matter what you're doing.

You're running Drupal which
is kind of a heavyweight CMS.

It requires a lot of
RAM and all this stuff.

You must be building some sort
of large community website

or some big ambitious,
digital experience, right?

Well, no, I'm actually running pretty much

a static HTML website inside of Drupal

and you might now be thinking OMGWTFBBQ.

Isn't it something like this?

And this is a picture I
found, I found it on Twitter

while I was working on this presentation.

If you can't see it very well,

it's a large flat bed 18-wheeler truck

and there's basically a brick tied down

in the middle of it.

A lot of times, we infrastructure-y people

and software developers, are
what I call architecture-nauts.

We want to build the fanciest,
most exotic limousine

to host a little, teeny tiny thing

that is almost insignificant.

However, it is a good
learning opportunity and so

the point I want to make about all that is

it doesn't always have to make sense.

For me, it's more of a fun
passionate side project

and really, what I have
gotten out of it a few times

in the past is you find things,

when you operate on the very small scale,

when I have four nodes
and they're physical Pis

and they're using NFS and
they use the same software

but they're running on very slow hardware

with slow networking and slow disc cable,

you run into some of the
limitations very quickly

and you learn how to solve
them on a small scale

and then when you get hit
by the same kind of a bug

on a larger scale, you
can kind of know how that

is gonna impact you, you can plan for it,

you can already have ways to mitigate it.

So I have learned a few things.

At least that's what I keep telling myself

to justify buying four or five
new Raspberry Pis every year.

And on that topic, so a couple
years ago I was like hey,

the Raspberry Pi 0 is so
cool it's even smaller

and it was cool.

I had an idea that I would
have this cluster using WiFi.

The newest ones actually have
WiFi chips built into them

so you didn't even have to
have a little dongle like that

but I would have WiFi

and I would have a little battery pack.

I could have that cluster in my pocket

and during the presentation,

I could whip it out and be like look,

this is running this whole thing.

The problem is the Raspberry
Pi 0 has the slowest processor

ever made, well, ever made
in the past 15 or 20 years

of all the Raspberry Pis I should say

and it's still a lot faster than the thing

that put us on the moon but it's very slow

and it only has half the
memory that the Raspberry Pi

actually install Kubernetes on it.

So that was very short-lived.

It also got very hot so I was fearful that

before the presentation
started, I might be on fire.

(audience laughs)

So I ran with another cluster
that had five Raspberry Pi 2s

and you might notice that this new model

that's in front of you
today does not have five,

it only has four.

The maximum of course of that flat truck

is that more is always better.

The problem here is that more is better.

When you hit the fifth Pi though,

you start to buy large power switches

and more device things to go with it

so the scale, there's kind
of a wall I hit at four

with this new 2019 version.

If you're wondering, the parts that I use,

any of that kind of stuff,

there's a website, pidramble.com.

It's actually running on a Raspberry Pi,

a single Pi in this
case, on my desk at home.

Please don't hack into it.

If you do, don't do anything too bad

because I'm not home so I can't fix

any problems that you cause.

Anyways, it's running on one Pi at home

and it's been up since

four and a half years with 99.6% uptime.

I'm pretty proud of that
because almost all of that

downtime was due to my
wonderful ISP spectrum

having very poor service sometimes.

Anyways, so this is the
new version of the cluster

and one thing that some
people wonder a lot is like

what is the best way to put
Kubernetes on a Raspberry Pi?

Some people wonder wait,

you can put Kubernetes on a Raspberry Pi?

There's a really cool thing,
I forget the guy's name,

but I think he's in college
now or something like that.

There was a guy who was like I want to get

Kubernetes on this Pi and
he spent a lot of time

working in the Kubernetes community

to make sure that all the
things that they built

were armed and compatible.

Raspberry Pis use a different
type of processor architecture

than most other computers,
the Intel and D64 chip.

So he spent a lot of time making sure

that all the binaries
and everything was built

to run correctly on the
Raspberry Pi and since about

I think it was Kubernetes

it actually works pretty
darn well on a Raspberry Pi

so that's cool.

If you search online for how do I install

Kubernetes on a Pi, you're
gonna end up on like medium.com

and there's these blog posts
that are 3,000, 4,000 words,

hundreds of instructions,
all kinds of stuff to do

and the problem is, you
kind of start getting tired.

If you do that once and then
you have to do it again,

you start getting tired of
having to do that over again

and then you start kind
of burning out on it.

Luckily for you, everything
that I've done here

is open-source and is in code

and I've chosen to use
Ansible to do it all

because Ansible is what I
call configuration management

for humans and cows.

That little cow down there,

that is from the Cowsay
command line utility.

Ansible has an Easter egg
that if you install Cowsay

on your computer, it'll
wrap every command output

in Ansible in a little
cow and you can customize

the cow that you get and
all that kind of stuff.

But anyway, a cool thing
about Ansible is it uses YAML

as its language or as its syntax.

A cool thing about that
is Kubernetes uses YAML

for its syntax.

Drupal uses YAML for its
configuration syntax.

A lot of different tools are standardizing

on using YAML for kind
of a human readable way

of configuring things and once
you know the basics of YAML

and start getting into how
to do things a little deeper,

you can start seeing, it's
kind of like if you know

English or well English
is a very bad language

to compare with but like Spanish
or French or what are they,

romance languages or whatever
that type of language is,

if you know one of them, you
start seeing the patterns

in the other ones so that's
a cool thing about Ansible,

Kubernetes, Drupal, a
lot of different software

symphony is using a
lot of YAML everywhere.

Anyway, so that's how I did it on there.

Like I said, pidramble.com,
I have a link to

literally everything about this thing

and I want to get into a little demo.

Lucky for you, this
presentation is the first one

where I am bringing my little camera.

I just thought of like people
can never see the thing.

In the back over there, can
you see everything up here?

Probably not.

You can kind of see a blob
of green but on the screen,

you can kind of see it.

The other cool thing is
I can actually say hello

to the people on the web.

Hello people on the web who are
viewing this on another day.

(audience laughs)

I had never been able to do that before.

Kevin is awesome and
gets all the recordings

but he doesn't have a
full video production crew

so here is my video production crew.

Glad to have them with me.

So anyway, I have this picture up here.

Let me see how I'm doing on time.

Pretty good, pretty good.

So I am going to, you're
not supposed to see this,

I'm supposed to act like
I don't have a script

and I just memorize all
this stuff completely

and just dump it out of my
hands but that's not how I am.

I end up Googling my own blog
post about three times a day.

(audience laughs)

Hide that.

I am going to first use Ansible

just to give you a really brief overview

of how Ansible can interact
with multiple servers

and a lot of people also ask like

why are you using Ansible?

You're using Kubernetes.

Kubernetes does all the hard work.

Well, have you ever had
to upgrade your servers?

Have you ever had to
configure your servers?

Have you ever needed to set up firewalls?

Have you ever needed to
integrate your servers

with other things or have
you ever had to integrate

two services with each other?

On top of that, how did
you install Kubernetes?

How do you update Kubernetes?

How do you manage the
Kubernetes configuration files?

There's 101 different ways to
do that kind of thing nowadays

but there's not a lot of
ways that are as mature

or as flexible as Ansible and so that's

kind of why I still stick with it

for a lot of the different things I do.

On top of that, Kubernetes
is a container first solution

whether it's Docker or some
other container technology.

How are you fielding your images?

How are you scanning your
images for vulnerabilities?

How are you distributing your images?

Are you managing an image repository?

All these different things
still have to be automated

and configured so even if
you're using cloud services,

how are you integrating all that together

and do you have one code base

where you can literally set everything up?

If you use Ansible, you can
actually say the answer is yes,

I have a code base where I run
a few commands and literally,

everything comes from nothing.

It's pretty cool, playing God like that.

Anyway, here's Ansible, I'm in a folder,

this is the Raspberry Pi Dramble project.

Like I said, it's on GitHub.

You can clone this and build
your own little cluster

if you want.

You can even build it
locally on your computer

if you don't have the Pis and
even if you only have one Pi,

you can run Drupal on it.

I have another project called Drupal Pi

and I'll talk a tiny bit
more about that later

but I'm going to use
the Ansible command line

and there's a lot of different
ways you can use Ansible.

This is one of them to just

remote control a bunch of servers.

Inventory, the inventory
file tells Ansible about

the servers so in this case, I
just gave it the IP addresses

of all the servers and then I say

I'm gonna operate on all the Pis

and I'm gonna use Ansible's service module

which let's me control
things running on the Pi

and I'm gonna give it some arguments.

I'm gonna say for the service,

Dramble node monitor, I want
to put into a state of stopped.

That means basically stop the service.

Right now, you'll notice that

all the lights on here are green.

That's because I have a
service running on the Pi

so it's constantly monitoring the health

of each of the Kubernetes nodes

and if one of them goes
bad, it'll turn red.

If it comes back, it'll turn green again.

So I'm gonna stop that for now because

I want to show you how Ansible

can remote control everything.

When I stop it, it'll
connect to all the Pis

and they should all shut off.

There they go and then I can show you,

if I say Ansible -i inventory all -a,

if you don't provide a
module on the command line,

it just uses the command
module which literally

runs the command that
you give it on the Pis

so I'm gonna say blink stick.

These little LED boards
are called blink sticks,

by the way, cool little
project from a guy in the UK.

He has a lot of different
remote control LED boards

for maker type computers.

So blink stick blue and the dash b flag

means run it as pseudo.

You have to have super
user route privileges

to control the USB hardware on the Pi

so that's why I have to do that.

So you can see how quick
it is to make changes.

Let's turn them green.

It takes maybe a second
or two but with Ansible,

you can also have also have
a lot more control over

how the rollout happens so a lot of times,

like if you're upgrading Kubernetes

or if you're upgrading
the Drupal container

or something like that
on multiple servers,

you don't want to do them all at once

and then they all fail right away.

You want to like do one,
if it worked, do the next,

that kind of thing so you
can control all this stuff.

Let me go back at screen
so I want to go to blue.

You can control stuff with forks

or Ansible also calls it serial.

You can do it serially
in like groups of one,

two, three, or however
many you want at a time.

So I'm going to do forks equals one

and you'll see now it's doing
it one, two, three, four

like that and let's turn
it back to red this time.

If you're color blind, can you
see blue/green differences?

Okay, alright good.

So you can see red, too, hopefully.

So they're all turning red and stuff.

So that's just a quick overview
of what Ansible can do.

When you're installing Kubernetes,

there's a few orchestration pieces

like you have to get a
token from the master server

and then you use it on the
other servers, things like that,

that make it helpful to be
able to run a command one place

and then use the data from
it to go to other places,

that kind of thing, and the
playbook I have does all that

for you but if you want
to find out how it's done,

just go into the source
code and take a look.

So I'm gonna turn back
on that node monitor

so I'm just gonna change this service

from stopped to started and
it should switch them all

back to green if they're
healthy, of course, and they are.

So the next thing I'm
gonna do is demonstrate

one of Kubernetes's coolest features.

It's the ability to self-heal.

Basically it sees there's
a failure somewhere

and then it just kind of is like okay,

I'm gonna react and I'm
gonna move things around

and that way I don't have to wake up Jeff

in the middle of the night.

So I'm going to check really quick.

Kubernetes has a command line
utility called cube controller

or cube CTL that lets you
interact with your clusters

so I'm gonna say cube control get pods.

Now I'm gonna mention this later.

You need a dictionary when
you're working with Kubernetes.

Pods are containers.

That's not a technical definition

and don't memorize that
but for the purposes

of this presentation, a pod is a container

or an application running on Pi.

So I'm gonna say tell me about
all the pods that are running

on all namespaces.

I'm not gonna get into namespaces.

Unfortunately, we only have 10 minutes so

I'm gonna get all the pods that
are running on the cluster.

So you can see there are some Drupal pods,

there's a database in Drupal,

there's some networking
pods, there's a proxy,

there's a thing that's a
load balancer, Traefik,

it's kind of like Engine X or HA Proxy

but it's a little more
cloud native-y or whatever

but it runs really well on the Pi.

That's why I chose it.

And you can see that they're all running.

So I'm gonna say get pods

and I'm just gonna look at
the Drupal ones for now.

And then I'm also gonna say oh wide.

That lets me see what node
that they're running on.

So I can see Drupal is running on cube two

and MySQL is running on cube three

and so I'm gonna take
down cube two really quick

and see what happens.

First of all, here's the
site that it's serving.

I'm not connected to the internet.

This is running locally
and the Pi is connected

by a network cable to my computer

so I'm loading these all off the Pi.

And if I say SSH Pi at
what is it, 10.0.100.62,

and then I'm gonna say I
could do this with Ansible but

for the purpose of this presentation,

I'm just doing this by hand.

What is it, system controls dot kublet.

Kublet is the service that
manages Kubernetes stuff per node

so I'm gonna stop that and you should see

that was pretty quick.

It turns it red because
the node is unhealthy.

If I go over here, I can
say cube control get nodes

and that's gonna tell me about
the nodes in the cluster.

So you can see it still
thinks they're ready.

That's 'cause Kubernetes has timeouts.

It always kind of has like grace periods

and it has back off and things like that

so you don't end up killing yourself

by flipping something on and off a lot.

So it should realize
within 30 to 40 seconds

that that node is actually not healthy

and it's gonna switch it
from ready to not ready.

And meanwhile, that pod is
still running on that node

and if you were still
connected to that node,

you would still be getting
requests and things

but a lot of times, like
in Amazon or in Azure

or in whatever cloud that you operate in,

even if it's a private data center,

networking routes just go bad.

You can see that it
just marked it not ready

so at this point, too, if I look here,

it'll say that it's still running

and it thinks it's on cube two
but I'm gonna watch this now.

So we can see it live update
and within a few seconds,

it's gonna say hey, cube two is unhealthy.

I need to get a new pod running
on a better node somewhere.

Usually that happens 30 to 40 seconds,

you can actually configure
all these timeouts

but you can see now it
marked that one to terminate.

It says I don't know
if that node is even up

so I'm gonna kill that container.

It can't actually terminate it
until that node comes back up

but it marks it as I'm
going to terminate this

but it already popped a
new Drupal on cube four

so I'm going to go over here
and it's still loading fine.

So Kubernetes just saved
me a pager in the middle

of the night because one
of the servers went down

and just kind of moved the stuff off of it

that it needed to move.

So I'm gonna bring that node back up.

And the light should turn green on here

which it did pretty
quick and at this point,

Kubernetes should also
mark that node as ready.

It's a lot quicker about
marking it as ready

than it is not ready.

I guess it wants to be
safer, not like killing off

your applications that are running.

So let's see, I still have a few minutes.

So I have time to go through

my favorite part of this presentation.

The next thing I want to
show is how you can also

scale up very easily,
scale out I should say.

So Drupal is an application
that if you have

a lot of logged in users or
you have a lot of traffic

that you can't cache like an Engine X

or Varnish or something,
it needs a lot of CPU.

So a lot of times what happens is

your servers get overloaded with CPU

and you need to scale but
like with Amazon auto-scaling,

it can take minutes or
lots of minutes to scale up

and there's different container engines

that can all do different things.

With Kubernetes, it's really easy.

You can figure something called HPA

and so I'm gonna say watch
cube control get HPA.

Cube control is also pretty consistent.

You get resources.

You can ascribe them to get
like all the data about them

and you can add them, delete them,

all that stuff through the command line

and Ansible also has ways to interact

with all these different commands, too.

The API is very thorough and robust

so I'm going to do this, dash n Drupal

and this is going to show me,

I already configured this HPA,
horizontal pod auto-scaling.

It basically says I have
a target of 50% CPU.

You can configure based on
CPU, memory, HTTP requests,

like whatever metric you want,

you can say when it hits this, scale up

and you can give it limits
of how big it can scale

and how quickly it scales down.

So right now, it's not doing much

because I'm just sitting
here refreshing this page

every now and then.

That's not a lot of work for Drupal to do

but we're gonna make Drupal,

we're gonna give Drupal
a little workout here.

There's no caching turned on

so this is gonna hit Drupal pretty hard.

Let's see.

I'm gonna use WRK which
is like Apache Bench

but a little easier to use for me.

Dash c five so five connections.

We're gonna run this test for 120 seconds

with five threads and I'm gonna call

the front page of this site.

So I'm gonna start that running.

Basically, what that's doing
is it's using five threads

on my Mac just to hit
the site, hit the site

as fast as it can and
Drupal's gonna be serving

as fast as it can, too.

So you can see it already
reacted to my earlier,

when I was just refreshing the page.

That brought the CPU up to 2%.

Pretty soon, this is
gonna start going up more

and this is just, Kubernetes will see that

there's a lot of CPU
being consumed by Drupal

and once it does that,
it will start scaling up

and you'll see that this
replica count will go up.

So we'll give it another 30 seconds or so

and it should start seeing
that target percentage go up.

Again, with all these
numbers, you can kind of set

it to be more aggressive or more passive.

I haven't seen if I can set
it to be passive aggressive

but the servers themselves
do that to me plenty.

So you can see it just
went up to 279 over 50.

That's not a very healthy
way for a container to be

so what it's doing now in the background,

I could be showing you the other things

showing like container creating

but it just created two
more Drupal replicas

and it's gonna spread
them out on the loads

as much as it can so that it can get

the requests distributed amongst the Pis.

So if I show you get all the pods,

you'll see that now
there's three Drupal pods.

There's one on cube two, one
on cube three, one on cube four

so it automatically knows like
I need to spread these out,

I need a lot because I'm
getting a lot of traffic.

That is the live demo portion.

Thank you for actually working, camera,

and good bye people on the web.

(audience laughs)

Let me pop back over here.

And so, yeah?

Okay.

So how was it?

You can see here that it's not

the fastest thing in the world.

It's not the slowest thing
in the world, either.

There are plenty of production servers

that I have seen that cannot serve as much

authenticated traffic
as this Pi cluster can

and if you scale up, the
cool thing about this is

for some parts of it at least

and for some Drupal use
cases, as you scale up,

the numbers just keep going up.

One thing that I have
not solved very well yet

is databases in Kubernetes.

I'll mention that in a
few minutes but if you

have a site that's cache-able

like a lot of anonymous traffic

and you use Engine X or Varnish
or Cloud Flair or something,

you can handle thousands
of requests per second,

no sweat at all, and I
actually have a configuration

on that Drupal Pi project.

You can use it as a load balancer

in front of the Raspberry Pis with caching

and that's what I do at home
when I have this at home.

I have the little Raspberry Pi as my cache

and these Raspberry Pis
do the traffic surfing.

Although I've not used them quite as much

since I have fans on them because

the fans get a little annoying sometimes.

A few caveats to doing what I do,

if you want to run your own
little data center at your

house, you're going to have
to deal with these things.

I've not met many people
who have three or four

redundant power supplies,
backup generators,

and whole house UPSs.

There are a few people
that do that kind of thing

but most people don't.

You have to deal with networks.

How many of you have three or four ISPs

and all of them are giving
you like 10 gigabits

or more bandwidth?

Probably not many.

Also, physical security.

I don't know anybody that has a house

where you have five or six
layers of biometric security

to get into your house.

There are some people
that do that but not many.

You have to maintain the Pis,
you have to upgrade them,

what happens if you get a lot of traffic.

At my house, when I get a lot of traffic,

it actually makes my internet slow because

I only have 10 megabits
of upload bandwidth

so when you're downloading
stuff from my Dramble site,

that's my upload bandwidth going away.

That makes everything slow.

Kubernetes itself.

I didn't get super deep into it,

I just wanted to give you a little bit of

dip your toes in the waters here

but there's a lot of things
that you have to consider

if you're ever considering
using Kubernetes

or building on top of a service
that's built on Kubernetes.

There's a lot of things that are easy to

shoot yourself in the foot over.

It makes some things way easier

and it makes some things way better

but it's also still maturing
and it's still becoming

kind of a new standard type thing

so a lot of the things you find online

will quickly give you big security holes.

You're gonna need a dictionary

so I imagine pods, cube control, RBAC,

role-based access control,
HPA, all these new terms,

you have to learn what
they mean, what they do,

how to use them, and basically done well,

you can do really cool things.

The projects I'm working on at Acquia,

this little Raspberry Pi cluster,

there's a lot of cool stuff
you can do with Kubernetes

but if you do it the wrong way,

I call it failure at web scale

because you're tempted to throw
everything into Kubernetes

and if you have a major security hole,

all of a sudden, everything's exposed

instead of just one thing.

Be careful, be smart about where

you might consider using it.

So in the end, the big question,

how well does Drupal 8 run on Kubernetes

on a cluster of Raspberry Pis?

Pretty well.

I mean, this demo didn't fail.

Two demos ago that I gave of this cluster

in an earlier version,
my computer actually died

but the Pi cluster was fine,

I just didn't have a way to shut it down

because my computer died.

(audience laughs)

But it runs pretty well.

I'll have these slides online

so you can get to these things
but the different things

I mentioned.

I know you mentioned,
Benji, that I have a book.

Actually, I'm terrible at marketing,

so at the end of my
presentation, here you go.

I have little cards.

This has a 25% discount
on Ansible for DevOps,

the book that I wrote,

and it actually has a
chapter on Kubernetes

and it has a chapter on Docker,

both of which are very handy if you're

going to be building this cluster.

And I'm working on a new
book, Ansible for Kubernetes.

I figured that Ansible
for is a good theme there

and last couple of slides.

Please give feedback on this session.

So I'm almost exactly on time.

Last night, I was one minute over.

Let's see if I can hit that again.

And then also Contribution
Day is coming up.

Thank you.

(audience applauds)
 

Captions made possible by ClarityPartners.com. Chicago area Drupal consultants