►
From YouTube: Kubernetes in Your 4x4 – Continuous Deployment Directly to the Car - Rafal Kowalski, Grape Up
Description
Join us for Kubernetes Forums Seoul, Sydney, 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
Kubernetes in Your 4x4 – Continuous Deployment Directly to the Car - Rafal Kowalski, Grape Up
Automotive industry is getting more and more digitalized. Vehicles are not only a mean of transportation, but they pursue to be the drivers' control center with multiple software components onboard. To keep pace with evolving customer expectations and the newest technological solutions, vehicle's software requires frequent updates. However, the delivery process in a scaled up environment is not straightforward. Developers and operators have to face challenges, which are unusual in the typical Cloud Native world. Even basic service deployment may be complicated due to network performance or geographical considerations. During this talk, Rafał will show how to use Kubernetes, KubeEdge, k3s, Jenkins and RSocket for building continuous deployment pipelines, which ship software directly to the car, deals with rollbacks and connectivity issues.
https://sched.co/UaaU
A
B
Yes,
so
today,
I
would
like
to
say
a
few
words
about
delivering
software
and
to
the
car
I
was
introduced
by
the
house.
My
name
is
Rafa
kowalska
I
work
as
a
cloud
solution
architect
at
great
up
beside
of
that
I'm
doing
some
scientific
work
at
polish
Academy
of
Sciences
I.
You
can
find
me
on
Twitter
and
on
github
on
github.
I
will
push
the
code
related
to
this
talk.
B
Okay,
so
this
presentation
is
related
to
the
PLC
project
we
executed
in
wrap-up,
as
we
cooperate
a
lot
with
companies
from
automotive
industry.
We
noticed
that
these
companies
I
knows
how
to
build
the
cloud
native
software,
but
they're
struggling
in
delivering
this
software
to
the
car
to
make
it
available
for
their
customers.
So
we
decided
that
we're
gonna
dig
a
bit
deeper
into
this
concept
and
use
of
knowledge
in
cloud
area
to
apply
to
embedded
software.
B
Ok,
so
first
things
first
I.
Probably
most
of
you
are
familiar
with
this
diagram
or
any
kind
of
variation
of
this
diagram.
It's
just
describe
how
we
do
that.
I
continues
delivery.
We
have
some
CI
engine
in
the
center
of
this
process.
When
you
push
your
cloud,
Jenkins
or
other
CI
engine
grab,
this
code
I
build
it
for
you
test
it
for
you,
I
had
then
deploy
it
to
some
staging
environment,
and
then
you
promote
your
artifact
to
Qi
QA
environment
and
at
the
end,
and
you
deploy
it
to
production.
B
This
process
is,
let's
say:
Sammy
semi-automated
I
mean
until
you
reach
the
stage
environment
all
happens
automatically,
but
then,
when
you
would
like
to
promote
your
artifact
to
QA
environment
or
to
production,
usually
it
looks
like
your
manager
approached
you
and
just
asked.
Okay,
we
are
fine
with
this
version
of
of
the
software.
Please
release
it
to
production,
you
push
the
push.
The
button
run
your
pipeline
and
deploy
it
to
production.
When
your
organization
gets
comfortable
with
this
process,
your
business
get
comfortable
with
this
process.
B
You
can
even
I
push
this
idea
further
and
do
continuous
deployment,
which
means
that
no
human,
no
manual
intervention
is
required.
All
the
stuff
happens
automatically
and
in
terms
of
deployment
when
we
deploy
it
to
production
or
any
other
environment
in
cloud
native
world.
We
we
usually
have
this
case
that
we
have
an
artifact
which
may
be
an
app
written
in
Java
or
whatever,
whatever
it
is,
or
just
a
container,
and
then
we
combine
it
with
kind
of
a
manifest
file
deployment
file
which
describe
how
this
particular
artifact
should
be
deployed
in
the
cloud.
B
How
many
instances
I
would
like
to
have?
What
kind
of
routing
I
would
like
to
have
then
Jenkins
orchestrate
this
process
for
us
and
deploy
it
to
pass
solution
of
our
choice?
We
can
use
kubernetes,
we
can
use
Cloud
Foundry
Herat,
whatever
is
there
what
we
are
using
and
usually
this
path
layer
sits
on
top
of
is
provider
of
our
choice?
Maybe
we
are
using
some
hybrid
solution.
It
all
depends
on
your
business
requirements
and
the
main
goal
of
our
POC
was
this
process
is
well-defined.
We
know
how
to
do
it.
B
We
have
a
lot
of
tools
to
help
us
in
performing
such
deployment.
So
our
idea
was
okay.
We
would
like
to
apply
the
same
approach
to
deliver
software
to
the
car.
So,
from
the
our
perspective,
it
should
be
transparent,
I,
don't
care
if
I
deploy
to
the
cloud
or
I
deploy
to
the
car
I
would
like
to
do
it
exactly
the
same
way
and
before
we
even
start
thinking
about
deployment
to
the
car,
we
have
to
dive
a
deep,
a
bit
deeper
inside
the
car
architecture.
B
So,
as
you
probably
noticed
nowadays,
a
car
is
a
it's
not
only
mean
of
transportation.
This
kind
of
drivers,
life
control
center
with
a
lot
of
different
services
deployed
onboard
and
beside
of
having
these
all
these
services
infotainment
system,
we
have
a
tons
of
different
sensors
different
devices.
We
have
cameras,
radar,
gesture
sensor
or
an
arranger,
so
these
sensors,
these
devices
are
controlled
by
electronic
control
units.
You
can
think
of
electronic
control
unit
as
a
piece
of
but
civil
custom
hardware,
which
hosts
very
custom
software.
B
So
in
such
a
scenario,
it's
really
hard
to
manage,
maintain
all
this
all
this
software
deployed
in
the
car.
So
usually
when
you
want
to
upgrade
any
component
in
your
car.
What
you
do
is
you
go
to
the
rest.
There
is
a
guy
who
plug
in
his
desktop
to
your
to
your
car,
using
some
sophisticated
desktop
software
upgrades
particular
component
in
your
car.
B
So,
as
you
see,
we
don't
even
think
about
any
continuous
delivery
when
we
have
such
architecture
and
automotive
companies
know
that
so
they
they
made
some
steps
to
make
it
easier
to
maintain
the
software
and
delivered
the
software
to
the
car.
First
of
all,
what
they
did
is
consolidation
of
electronic
control
units,
so
we
have
a
bigger,
more
performant
electronic
electronic
control
units
called
high
performance
issue.
B
This
control
units
are
more
generic
and
host
different
types
of
software.
Another
step,
which
is
quite
significant
in
terms
of
delivering
the
software,
is
a
4G
revolution.
Nowadays,
almost
every
single
car
new
car,
you
will
buy,
will
have
a
faulty
module
with
a
SIM
card
and
you
will
have
a
connection
to
the
cloud.
So
we
have
a
concept
of
connected
car
this
connection,
it's
not
very
easy,
reliable,
but
that's
something
we
can
use
I
had
to
deliver
software
to
the
car.
B
Of
course,
the
living
software
to
the
car
is
one
thing,
and
another
thing
is
still.
We
have
a
lot
of
different
components
deployed
in
the
car
and
we
have
to
somehow
manage
the
life
cycle
of
these
components.
So
we
have
a
similar
situation,
the
cloud
right,
so
all
right
deals
with.
Maybe
we
can
use
kubernetes
to
do
this
lifecycle
management
for
us
and
help
us
to
to
deliver
this,
this
software
faster
and
easier.
But
there
is
a
main
issue
related
to
that
community
was
not
designed
for
embedded
software.
B
It
can
consume
quite
significant
amount
of
resources.
Of
course,
when
we
are
talking
about
cloud,
it's
it's
nothing.
We
can
just
spin
another
VM
and
it's
fine,
but
in
the
car
we
operate
in
kind
of
constrained
environment
in
terms
of
resources
we
can
just
spin
another
VM
to
handle
that
at
the
workloads
and
most
of
the
kubernetes
distributions
does
not
turn
support
the
arraign
architecture.
B
B
It
has
amputee
based
communication
when
we
collecting
the
data
from
devices
it
uses
their
ng
D
protocol,
which
in
most
cases
you
fits
very
well
I,
will
dive
a
bit
deeper
into
this
concept
in
a
minute
in
terms
of
architecture,
it
looks
like
following
it's
divided
into
two
parts.
We
have
this
cloud
part
with
three
major
components:
edge,
control,
device,
controller
and
cloud
hub,
so
each
controller
of
course,
is
responsible
for
manage
their
edge
components.
B
We
we
deployed
on
the
edge
we
have
device
controller
which
manages
the
device
is
connected
to
particular
edge,
and
we
have
a
cloud
hub
which
is
responsible
for
communication
between
cloud
part
and
edge
part
on
the
edge
part.
We
have
a
edge
hub,
which
is
kind
of
new
role
of
the
calc
hub.
It's
this
company
is
responsible
for
communicating
with
the
cloud
we
have
a
meta
Manager,
which
maintains
all
the
metadata
related
to
our
deployment.
Then
we
have
a
device
twin
device
between
is
a
just
digital
representation
of
the
state
of
the
devices.
B
So
when
the
devices
report
the
state,
this
state
is
on
my
head
saved
on
the
edge
and
then
synchronized
with
the
state
which
is
stored
on
the
cloud
side,
and
then
we
have
an
event
bus
which
provides
the
communication
with
the
devices
like
I
said
it
use.
It
uses
mqtt
protocol
to
grab
this
data
from
the
devices
and
last
bubble
piece
we
have
edged
which
manage
the
lifecycle
of
the
containers
you
deployed
on
the
edge
so
applying
this
solution.
B
In
times
of
deploying
to
such
solution,
it's
almost
perfect
for
us,
because
it's
transparent,
I
delegate
all
the
stuff
related
to
deployment
to
cube
edge.
So
from
our
perspective,
it
doesn't
matter
if
I
deploy
to
the
cloud
or
I
deployed
to
the
edge
I,
just
push
it
to
cloud
part
of
the
of
the
cube
edge,
and
it
does
rest
of
work
for
me.
But
we
noticed
that
does
some
issues
related
to
this
solution.
The
first
one,
which
was
quite
important
for
us,
is
stability
of
this
connection
between
cloud
part
and
and
the
edge.
B
The
second
thing
we
found
a
bit
difficult
is
selective
deployments,
so
I
would
like
to
dynamically
find
a
bunch
of
cars
which
should
be
upgraded
well,
which
components
in
particular
cars
should
be
updated,
and
in
this
scenario
we
can
use
some
mechanism
provided
by
a
kubernetes
like
I,
don't
know
labeling
of
the
nodes
and
using
this
solution
we
can
deploy
particular
software
to
particular
edge,
but
still
it's
not
very
dynamical.
So,
of
course,
cube.
Edge,
provides
a
lot
of
features
related
to
security,
to
certificate
management,
all
this
stuff,
which
is
really
nice
and
cool.
B
But
we
decided
to
make
a
step
back
and
use
something
simpler,
which
gives
us
more
flexibility,
and
we
pick
up
key
3s,
which
is
certain
certified
kubernetes
distribution.
It's
a
lightweight
version
of
the
kubernetes.
It
feeds
resource-constrained
environment
and
has
support
for
online
offline
operations,
which
is
very
important
for
us.
It
removes
some
non
default
features
with
cloud
providers,
storage
and
other
stuff.
It
replaces
the
80
CD
we've
secured
light
just
to
make
it
to
reduce
the
memory
footprint
in
terms
of
architecture.
B
So
in
this
scenario,
every
single
path
is
a
separate
standalone,
kubernetes
cluster
and
the
ECU's
works.
As
a
as
a
workers
in
terms
of
deployment,
we
took
very
naive,
naive
approach.
Assuming
the
first
place,
we
decided.
Okay,
let's
use
Jenkins
to
do
this
job
for
us
on
one
hand,
we
pushed
the
docker
image
to
docker
registry
and
then
we
pushed
manifest
deployment
file
to
the
to
the
car
and
there
is
kts
server
which
does
the
rest
work
of
for
us
yeah.
B
But
at
some
point
we
realize
it's
not
very
flexible
solution
and
Jenkins
shouldn't
be
doing
that
much
for
us,
so
we
created
a
very
simple
our
component.
We
call
it
just
car
controller
is
a
kind
of
implementation
of
digital
twin
pattern
which
tracks
the
state
of
the
car
was
deployed
in
the
particular
car.
So
we
have
this
representation
on
the
cloud
side.
We
can
easily
query
and
see
what
what
is
deployed
out
there
without
it
support
the
office
scenario.
So
we
don't
need
to
query
each
card
to
know
what's
deployed
inside.
B
We
can
use
this
information
we
have
on
the
cloud
side.
However,
we
still
have
this
issue
that
this
connection
between
docker
registry
and
car
and
between
color
controller
is
unstable.
So,
as
we
are
playing
with
a
lot
of
different
technologies,
we
decide
to
give
a
chance
to
air
socket,
which
is
a
binary
framed
protocol.
It
works
on
top
of
TCP,
but
can
work
on
the
on
top
of
WebSocket
or
Iran.
B
What's
important,
it
has
very
rich
and
clean
interaction
model.
We
have
four
default
operations
like
fire
and
forget
a
request
response
request
stream
and
channel,
so
we
can
use
it
not
only
to
transfer
that
the
images
but
for
whole
communication
can
just
unify
this
communication
because
we
have
all
common
interaction
model
implemented
here.
What's
also
important
for
us
and
socket
has
resumed
mechanism
with
comes
out
of
the
box.
B
So
let's
imagine
such
situation
that
I'm
transferring
that
the
image
from
the
cloud
to
the
edge
I
would
like
to
deploy
it
and
then
suddenly,
my
connection
is
broken.
What
will
happen
then?
Our
socket
will
automatically
put
all
the
frames
because
it's
frame
protocol
it
puts
all
the
frames
into
the
cache
and
when
I
get
my
connection
back,
it
will
automatically
identify
the
point
where
I
finished,
processing
the
stream
of
data
and
resume
from
this
particular
point.
B
Okay,
so
we
replace
this
connection
between
car
controller
and
K
and
the
car,
but
we
still
have
this
connection
between
Daka
and
and
and
the
car
doctor
registry
and
the
car.
So
at
this
point
we
decide
that
we're
gonna
create
kind
of
cache
inside
the
car
controller.
So,
from
the
car
perspective
you
communicate
only
with
the
car
controller.
You
don't
communicate
with
docker
registry
and
then
to
transfer
the
images
we
can
use
a
socket.
We
can
do
it
layer
by
layer
in
details.
B
It
works
like
show
shown
on
this
diagram
and
so
on
the
cloud
site.
We
have
a
MongoDB
to
just
store
the
state,
simple
document
database
and
we
have
Genki
to
orchestrate
this
deployment
process
and
we
have
a
registry
where
we
store
where
we
originally
stored,
the
docker
images,
and
then
we
have
a
car
controller
which
is
responsible
for
transferring
this
data
from
the
cloud
to
to
the
car.
On
the
car
side,
we
have
a
car
agent
which
is
responsible
for
gathering
this
binary
data
and
put
it
into
an
docker
image.
B
We
have
to
do
with
manually
label
layer,
then
this
image
is
pushed
to
local
docker
registry,
which
deploy
which
exists
in
that
on
the
car
side,
and
from
this
point
it
can
be
easily
deployed
to
k3s.
This
abstraction
layer
was
introduced
because
we
would
like
to
be
able
to
deploy
not
not
only
the
docker
images.
We
have
to
keep
in
mind
that
car
is
not
a
cloud
native
platform.
There
will
be
always
a
PI
kind
of
software.
You
are
not
able
to
containerize
and
deploy
it
in
the
container
on
k2s.
B
So
for
such
scenarios,
we
still
with
car
agent.
We
are
still
able
to
deploy
very
custom
software
on
particular
ECU,
because
we
have
this
abstraction
layer
and,
from
my
point
as
a
developer,
I,
don't
really
care
I,
just
delegate
the
work
to
the
car
agent
and
we
just
tag
this
deployment
should
be
deployed
as
a
standalone
application
or
driver
or
whatever
it
is
on
particular
electronic
control
unit.
B
How
does
it
affect
all
pipeline?
So
the
main
benefit
of
using
such
architecture,
whatever
it
will
be
a
K
2
years
or
cube
flow-
is
that
you
have
parity
between
development
environments
and
production.
Of
course,
it's
not
one-to-one,
but
still
you
are
really
closing
this
with
these
environments
in
terms
of
staging
we
can
deploy
just
to
the
cloud
Mach
the
devices
we
are
using
and
we
are
very
quickly
able
to
execute
some
tests
to
verify
that
the
old
artifact
is
ok
and
then,
in
terms
of
human
environment.
B
B
The
architecture
we
applied
has
another
benefit
which
I
already
mentioned
a
bit
its
ability
to
do
as
selective
deployments.
So,
let's
imagine
such
situation
from
the
business
perspective.
That
I
would
like
to
upgrade
infotainment
system
in
all
Ferraris
in
15
miles
from
San
Diego,
without
with
digital
representation
of
the
car
in
the
cloud,
I
can
easily
do
that.
I
can
easily
select
which
cars
should
receive
this
upgrade.
Moreover,
we
can
implement
more
sophisticated
scenarios
like
I
would
like
to
update
component
the
car,
but
this
object
has
to
happen
this
week,
otherwise
just
skip
it.
B
B
Last
but
not
least,
is
gives
the
architect
sleepless.
Nights
is
a
rollback.
It
will
always
happen
that
at
some
point
you
will
make
mistake.
You
deploy
some
component,
which
should
be
rollback
because
of
business
issues
because
of
bags
or
whatever
it
is.
You
need
to
roll
back
this
component
and
with
such
solution.
B
Okay,
just
to
sum
up
from
our
piece
here
from
our
investigation,
we
see
that
micro
pass
solution
out
as
enable
us
to
run,
say
the
cloud
or
cloud
environment
on
the
edge.
It
can
be
applied
to
most
every
kind
of
IOT
products,
but
we
see
it
more
most
valuable
in
case
of
some
complex
system
like
a
car,
for
example,
then
we
noticed
that
the
connectivity
and
number
of
devices
we
hand
we
have
to
handle
in
this
industry.
I
can
be
easily
addressed
with
with
implementation
of
digital
twin
pattern.
B
This
one
I
showed
you
with,
for
example,
selective
deployment
representation
of
the
car
in
the
cloud
what's
deployed
in
the
particular
car.
So,
with
this
implementation
of
this
pattern,
we
we
can
easily
relatively
easily
handle
all
these
scenarios
and,
last
but
not
least,
is
that
the
micro
pass
and
an
air
socket
helped
us
to
unify
the
runtime
environment.
B
So
we
have
almost
the
same
environment,
runtime
environment
in
the
cloud
and
on
the
edge,
and
it
helps
us
to
unified
and
the
communication
protocols
we
are
using
because
I
can
easily
use
a
socket
to
communicate
my
components
in
the
cloud.
I
can
use
a
socket
to
communicate
from
cloud
to
the
edge
and
I
can
also
use
also
to
communicate
between
different
cars.
So
I,
you
know
fie
the
runtimes,
a
unified,
the
communication
patterns
and
based
on
that
it
helps
eventually
it
will
help
me
to
maintain
all
this
stuff.
It
will
be
just
easier.
B
A
C
D
C
B
Another
topic
so
yeah
we
had,
we
keep
it
in
mind,
but
we
don't
have
any
hive
ability
mechanism
on
the
car
agent
and
we
don't
have
any
procedure
of
updating
car
agent.
Yet
I
mean
that
was
the
POC.
We
know
that
this
should
be
done,
but
at
this
point
we
didn't
implement
it.
We
have
few
ideas
to
do
that.
It's
not
it's
not
yet.
D
B
B
B
F
On
here,
I
noticed
that
was
Koopa.
You
actually
download
the
app
through
from
the
cloud
right,
but
the
second
approach
you
have
everything
packed
in
the
card.
Do
you
not
need
that
anymore?
You
just
use
a
USB
and
plugging
like
I
assume
you
were.
You
were
downloading
some
container
big
containers
from
the
cloud
into
that
your
car
right,
it
was.
The
second
approach
was
Kayseri.
Yes,
you
have
everything's
sitting
in
the
car
or
the
words
they
have
coming
from.
Yes,.
B
So
it
comes
from
the
cloud,
but
in
the
first
approach,
when
we
apply
the
cube
ad,
you
have
a
part
of
this.
Let's
see
platform
in
the
cloud
and
then
you
have
the
add
components
in
the
car.
So
it's
kind
of
one
entity.
But
in
the
second
scenario
we
put
all
this
stuff
inside
the
car.
So
in
the
car
you
have
a
standalone,
kubernetes
caster
and
it's
on
it's
on
YouTube
move
the
docker
image
to
the
car.
F
G
B
B
A
B
I
B
So
when
you
have
a
docker
image
and
you
store
it
in
docker
registry-
it's
of
course
splitted
into
layers.
When
you
would
like
to
manually
download
this,
you
can
I,
don't
know
using
the
just
cool
I'll,
see
you
around,
you
can
download
it.
You
will
get
the
different
archives
with
different
layers
and
if
you
would
like
to
just
upload
these
layers
to
another
document
history,
you
have
to
put
all
these
pieces
together
into
docker
image
and
then
push
it.
So
that
was
the
issue.
B
H
C
B
So,
for
example,
that
might
be
applied
for
infotainment
systems
when
of
course,
if
you
deploy
the
let's
say
buggy
software,
and
you
notice
that
at
some
point
we
you
can
even
in
office.
So
now
you
do
that
the
rollback.
So
we
started
building
this
POC
around
the
infotainment
system,
because
this
system
is
the
most
cloudy.
Let's
say
it's
just
a
simple
app:
you
can
have
on
different
systems
and
then
we
just
started
extending
it
for
all
the
types
of
of
the
devices
that
needs
to
be
handled
in
the
car.