►
From YouTube: Building Helm Charts From the Ground Up: An Introduction to Kubernetes [I] - Amy Chen, Heptio
Description
Building Helm Charts From the Ground Up: An Introduction to Kubernetes [I] - Amy Chen, Heptio
Learn the basics of Kubernetes from the perspective of creating a Helm Chart from scratch!
The Kubernetes cluster will be launched from Rancher, an open source container management software. At the end of this workshop, you will have a functional understanding of pods, services, deployments, Helm, Rancher, and more!
Why learn Kubernetes with Helm Charts?
Much of today's beginner educational content for Kubernetes uses the Kubernetes CLI tool. This can make it hard to visualize the relationship between each command and debug your cluster. Learning how to incrementally build Helm Charts provides a bigger picture of your cluster and is more reproducible.
Why is Rancher cool?
Rancher makes it easy to configure, deploy and manage Kubernetes, on any infrastructure!
I'm in, what are we doing?
- Gain a high level understanding of key Kubernetes concepts accompanied with a lot of diagrams
- Gain an understanding of Rancher's open source container management platform
- Incrementally build a Nginx Helm Chart
- Deploy Nginx from a Kubernetes cluster managed by Rancher
About Amy Chen
Amy Chen is a systems software engineer at heptio. She is passionate about containers, orchestration tools, Go, and salsa dancing. In her free time, Amy runs a youtube channel called Amy Codes where she talks about technical and non-technical aspects of being a software engineer. (https://www.youtube.com/AmyCodes). She also founded a grassroots Facebook online community now 8.5K large called Ladies Storm Hackathons. The demographic is largely college and new grad aged people of all genders with the common aim of gender equality in the tech industry. She aims to make the container and infrastructure industry more accessible to women by evangelizing with her excitement to women's communities. You can follow her internet shenanigans here:
https://www.youtube.com/AmyCodes
https://twitter.com/TheAmyCodes
https://medium.com/@amy
https://github.com/amy
https://www.instagram.com/theamycode/
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
A
Hi
everyone,
my
name,
is
Amy
I
recently
joined,
have
to
you
on
Friday,
so
I
believe
today
is
my
fifth
day
of
work.
So
that's
pretty
awesome
and
prior
to
this,
I
actually
started
in
a
career
days
container
space
in
March
of
this
year
and
I
graduated
college
in
January
this
year.
So
it's
been
a
crazy,
crazy
whirlwind.
A
So
again,
this
is
geared
toward
beginners,
but
once
again,
if
you're
interested
in
learning
how
to
teach
others
about
kubernetes,
this
is
also
a
great
talk.
So
in
infrastructure,
your
main
goal
is
to
always
prepare
for
failure
right.
There
is
no
trust
in
the
sense
of
like
I.
Don't
really
want
to
trust
my
app
developers
and
I.
Don't
really
need
to
trust
my
app
developers
and
everything
in
the
system.
It
needs
to
be
able
to
fail
right.
A
So
the
question
is
is
like:
how
do
we
do
this?
So
kubernetes
is
one
of
those
great
tools
that
allows
this,
but
at
the
base
of
it
all
is
containers,
and
the
question
is
that
a
lot
of
web
app
developers
like
start
with,
is
how
do
you
run
your
application
in
the
cloud?
So
the
core
concept
of
the
cloud
right
is
that
everything
is
ephemeral,
everything
dies,
things
are
complicated.
Networks
goes
down
like
it's
the
whole,
just
crazy,
feel
derivative
systems
or
there's
like
tons
and
tons
of
papers
right.
A
So
what
we
want
to
be
able
to
do
is
build
trust
and
services
that
we
always
want
to
have
available
right,
like
if
you
have
a
web
app,
for
instance,
which
is
the
most
like
tangible
thing
that
I
usually
use.
As
example,
is
you
always
want
to
be
able
to
access
websites
with
low
latency,
and
you
just
want
it
to
work
right
as
application
developers
like?
A
A
So
what
is
a
container
a
lot
that
I
find
when
people
teach
this
is
like
they
start
off
with
oh,
like
a
container
is
a
Linux
thread
and
that's
like
I
feel
like
the
worst
way
to
approach
that
like
yes,
it
is,
but
you
don't
need
to
tell
people
that
at
the
beginning,
right
like
what
is
the
Linux
thread
like?
Can
people
actually
like
really
truly
explain
that
correctly
when
they're
first
beginning
so
what
I
like
to
start
off
with
is
I?
A
Can
a
container
is
a
baby
computer
inside
another
computer,
where
the
baby
computer
is
a
container
and
the
other
computer
is
a
server
right.
So
why
would
you
want
a
baby
computer
inside
another
computer?
The
idea
is
that
the
baby
computer
is
easy
to
transfer
around
there's
resource
isolation,
and
it
also
is
able
to
encompass
your
application
environment,
which
I'll
be
able
to
talk
to
you
about
next.
A
So
here
is
kind
of
like
my
studio
code,
ish
example.
That
is
another
way
to
lead
into
how
to
get
web
application
developers
like
deploying
their
applications
onto
a
container.
So
what
we
have
here
is
like,
let's
focus
on
the
image
on
the
left,
is
we
have
our
server
and
then
we
have
our
container,
and
we
have
a
bunch
of
configurations
that
we
have
on
our
docker
file
right.
So
on
our
container.
What
I
want
to
always
consistently
deploy
our
web
lab
web
application
on
is
Alpine
and
I
want
it
to
be
on
Python
version.
A
3.7
and
I
have
like
a
lot
of
setup
scripts,
and
things
like
that
and
I
want
my
web
application
to
consistently
be
in
the
same
environment
right.
The
idea
is
that
locally,
like
you,
have
a
bunch
of
configurations,
and
things
like
that
and
like
just
goes
wrong
when
you
put
it
into
production,
if
your
environment
is
not
consistent,
so
containers
provide
that
consistency
for
you
so
on.
The
right
here
is
where
we
have
our
configuration
file
and
you'll
see
that
we
have
a
Python
Alpine
image
in
the
run
line,
there's
a
bunch
of
setup
scripts.
A
What
we
do
is
we
copy
the
local
application
onto
our
container
and
it
builds
that
intern
image
and
what
we're
doing
is
then
exposing
port
80
after
that.
What
we
have
is
the
container,
but
that's
not
enough
right.
So
it's
complicated
our
container
is
going
through
an
existential
crisis,
poor
little
container.
It's
asking
questions
like
where
should
I
live,
so
this
goes
under
the
realm
of
scheduling
right.
How
do
I
talk
to
other
containers,
so
this
goes
under
the
realm
of
networking.
How
do
I
talk
to
the
world?
A
So
this
goes
under
the
realm
of
routing
and
what
happens
if
I
get
sick.
So
let's
talk
about
like
failure,
recovery
and
there's
like
a
whole
bunch
of
topics
that
this
can
expand
into
right
and
like
no
one
really
wants
to
manage
this
on
their
own.
So
what
happens?
Hey
we're
at
cube,
Con,
so
cue,
brunette
EES,
of
course,
who
would
have
thought
so
kubernetes,
obviously,
is
a
container
management
platform.
A
So
this
is
sort
of
the
basics
of
everything
I'll
try
to
like
run
through
them
super
quickly,
so
that
we
can
go
to
the
helm
demo,
since
this
is
a
kubernetes
conference,
so
hopefully,
or
not-
hopefully,
but
maybe
y'all
most
of
y'all
probably
know
about
this,
so
some
containers
are
tightly
coupled
together.
So,
therefore,
we
need
to
be
able
to
have
an
abstraction
to
be
able
to
schedule
them
on
the
same
server
together
right.
A
They
want
to
be
co-located,
so
we
need
more
ways
to
organize
containers
and
that's
where
pods
come
in,
so
pods
are
essentially
scheduling
unit
they're
the
basic
unit
of
kubernetes.
They
contain
one
or
more
containers
in
a
pod.
Each
pod
is
given
an
IP
address
within
the
cluster
to
be
reached.
Note
that
you
cannot
reach
this
IP
address
outside
of
your
cluster
pods.
A
They
can
be
confusing,
but
what
you
want
to
be
able
to
know
is
that
you
rarely
ever
have
more
than
one
container
with
a
pod
due
to
scheduling
issues.
So
if
something
happens,
you
can't
really
control
which
container
gets
killed,
and
so
that's
like
the
main
reason
why
you
don't
want
to
have
more
than
one
container
within
a
pod.
So
that's
what
we
have
our
deployments.
A
So
what
a
deployment
is
is
a
group
of
pods
and
here's
where
we
have
the
concept
of
actual
state
and
desired
state
right
so
deployments
what
they
do
is
they
help
your
pods
reach
your
desired
state.
So,
for
instance,
what
you
could
have
is
you
want?
You
can
specify
a
number
of
pods
running
in
your
cluster.
So
let's,
for
instance
de
we
want
to
have
three
of
the
same
pods
or
replicas.
We
want
to
have
three
of
the
same
pods
running
in
our
cluster,
always
right.
A
So
that's
what
we
call
replicas,
let's
say
one
dies
or
you
kill
it.
The
deployment
controller
will
make
sure
that
there's
another
pod
spun
up
to
make
sure
that
you
always
have
three
pots.
So
that's
the
idea
of
the
desired
state,
no
matter
what's
happening.
Your
deployment
controller
will
make
sure
that
we
will
always
work
towards
to
get
to
the
state
that
the
deployment
is
defined.
As
so
again,
let's
say
you
have
three
replicas.
If
you
kill
one
deployment,
controller
we'll
make
sure
it'll
spin
up
another
one
another
pod.
A
Now
we
have
another
organizational
concept
called
services.
So
what
services
refer
to
are
a
group
of
pods
or
deployments?
It
has
nothing
to
do
with
the
sired
stay.
So,
let's
like
pose
this
problem
right,
so
recall
that
each
pod
gets
an
IP
so
when
they
die
or
get
killed,
their
IP
can
change
and
it's
not
a
reliable
IP
to
always
hit.
So
let's
say
you
have
a
group
of
pods,
for
instance,
front
end
and
at
the
group
of
pods
called
back
end.
A
They
need
to
talk
to
each
other
and
be
able
to
keep
track
of
each
other,
and
you
don't
want
to
do
this
based
on
relying
upon
any
sort
of
like
single
IP
address
right
because
again,
they're,
not
dependable.
So
what
services
do
is
that
they
define
a
group
of
pods
and
a
dependable
endpoint
to
be
able
to
communicate
to
one
another.
So,
for
instance,
you
could
have
your
front
end
service
hit
up
your
back-end
service
and
they
can
transfer
information
back
and
forth
between
these
groups
of
pods
that
work
together.
A
A
What
it
does
is
it
routes,
traffic
to
internal
services
based
on
things
like
your
host
and
your
path
in
my
demo,
I'll
actually
be
binding
or
I'll,
be
routing
it
to
like
a
port
and
I
won't
have
an
endpoint,
but
I'll
have
another
diagram
to
show
you
that
so,
let's,
like
do
like
a
summary
and
run
through,
and
then
next
we'll
do
demoing
time.
So
here
what
we
have
is
the
internet,
and
what
we
want
to
try
to
reach
is
our
ingress
controller,
so
we'll
hit
IP
or
domain
or
whatever.
A
And
then
what
will
happen
is
is
let's
say
we
hit
up
endpoint
foo,
then
it'll
hit
up
service
a
and
then
be
able
to
serve
back
whatever
service
a
wants
to
give
back
to
you.
Staying
forward
like
endpoint,
bar
or
baz
it'll
hit
up
service,
B
and
C
respectively
within
our
services.
Again
we
have
what
are
called
deployments
and
pods,
and
those
are
in
charge
of
so
deployments
are
what
is
in
charge
of
making
sure
that
your
it
will
making
sure
that
it
there
is
always
a
desired
state
to
be
achieved.
A
So
the
next
thing
that
we
can
talk
about
is
how
do
we
version
control
a
deployment
right?
So
what
we
have
is
great
right.
So
what
we
want
to
be
able
to
make
sure
is
like
how
do
we
keep
track
of
each
deployment
that
we
have?
So
let's
say
we
have
a
specific
deployment
with,
let's
say,
nginx
1.12
right
and
then
the
other
thing
that
we
want
to
add
is
like
a
new
ingress
endpoint
right.
A
So
we
want
to
be
able
to
couple
these
sort
of
resources
and
changes
together,
and
so
this
is
where
helm
comes
in,
and
this
is
like
actually
a
tool
that
I
use
to
deploy
all
of
my
20
deployments
when
I
first
started,
because
I
thought
that
existing
tools
were
a
bit
confusing.
So
this
can
help
you
kind
of
like
manage
each
of
your
deployments
and
also
the
cluster
state,
so
home
yay.
A
So
this
is
a
like
kind
of
do
a
cursory
overview
of
this.
So
this
is
what
is
called
a
chart
and
so
a
chart
basically
defines
a
group
of
manifest
files,
and
so
that
is
like
sort
of
the
state
of
each
deployment
that
you
have
and
you
can
define
like
a
lot
of
metadata
there
and
it's
super
awesome,
and
this
is
how
we
structure
a
chart.
A
This
is
like
information
that
you
can
look
on
the
documentation,
but
we
have
chart
and
we
should
have
sorry
that
should
say
templates,
and
then
we
have
all
of
our
templates
under
there
with
all
of
our
manifest
files
and
then
all
I
do
is
I
can
do
how
I'm
install
and
then
I
can
show
the
different
deployments
that
I
have
out
with
home
list.
We
can
do
things
like
roll
backs,
we
can
do
linting
and
all
that
that
I
will
show
you
in
a
second.
So
this
is
our
demo
preview.
A
I
wanted
to
sort
of
show
you
a
picture
of.
What's
going
on
before
we
actually
look
at
any
ml
code,
because
I
find
that,
like
pictures
for
me,
I
need
to
be
able
to
like
I'm
a
very
visual
person.
I
need
to
be
able
to
see.
What's
going
on
so
what
our
demo?
Well?
What
I'll
do
my
demo
today
is
I?
Have
a
mini
cube,
set
up
to
set
up
my
cluster?
A
A
What
I
want
to
be
able
to
do
is
expose
port
443
and
our
ingress
controller
will
be
called
nginx
ingress
that
will
then
route
traffic
to
our
nginx
service
named
nginx
service,
pretty
imaginative
name
and
then
443
will
route
traffic
to
the
exposed
port
on
the
service
port
80
and
then
what
we'll
do
is
I'll
explain
the
selector
in
a
second
so
inside
our
service.
What
we
have
is
a
deployment
of
three
pods
right
now
and
our
container
we're
exposing
port
80
and
four
pods.
A
A
Is
it's
using
the
selector
to
select
everything
with
the
label,
App
Engine
X
to
route
traffic
to,
and
so
that's
sort
of
the
relationship
between
the
selector
and
label
in
which
the
selector
selects
things
and
the
label
label
things,
and
when
you
have
the
selector
it'll
route
traffic
to
things
that
the
label
coordinates
pretty
simple
right,
and
so
that
is
the
image
that
I
want
to
keep
in
your
mind
as
we
go
through
the
manifest
files,
so
something
that
I
felt
was.
Oh
sorry,
so
something
that
I
felt
was
interesting.
A
Was
that,
like
every
time
I
deployed
a
deployment,
I
just
used
helm,
install
and
the
reason
this
was
the
case
was
because
Cube
control
commands
were
kind
of
confusing
to
me
when
I
was
first
starting
I
just
wanted
to
like
hit
something
have
at
work,
not
have
to
worry
about
like
the
order
in
which
I
deploy
my
resources,
and
so
that
was
sort
of
the
case
there.
Let
me
go
ahead
and
mirror
my
I
need
to
go
ahead
and
mirror
my
screen
right
now.
So
one
second,
so
we
can
go
into
the
demo
mode.
A
Okay,
their
displays
cool
I,
don't
know
how
to
fix
this
part
out,
I'll,
just
kind
of
hide
it
there.
Okay,
whatever
okay,
let's
like
take
a
second
and
hope
the
demo
gods
are
with
me
today,
so
I'm
gonna
do
an
LS,
so
we
have
part
one
which
I'll
just
do
like
a
quick
helm
run-through
of
all
my
manifest
files.
So,
let's
go
into
their
part,
one,
oh
yeah,
sure
absolutely.
A
Okay,
so
here
is
sort
of
the
layout
of
what's
going
on
right,
so
at
the
very
top
under
our
part,
one
helm
directory.
We
have
our
chart,
so
let's
go
ahead
and
cat
that
Amy's
awesome
demo
description
version
control
your
clusters,
so
this
is
sort
of
the
metadata
to
describe
each
deployment
right
and
so
we're
gonna
ignore
the
values
yeah
well
for
now,
because
I'll
do
that
in
part
two.
So
let's
go
ahead
and
seed
in
templates,
and
this
is
where
all
my
manifest
files
live.
A
A
So,
let's,
like
do
a
quick
breakdown
of
this.
So
what
we
can
see
here
is
we
have
our
deployments.
So
that's
what
it
is
our
resource.
It
is
called
nginx
and
then
what
we
want
to
be
able
to
do
is
have
three
replicas.
So
that
means
we
want
to
have
three
pods
up
and
running
at
all
times
and
then
we're
labeling,
this
deployment,
App
Engine
X,
and
what
we
have
is
our
container
with
the
image
of
nginx
1.13
and
we're
exposing
port
80
on
our
nginx
container
right.
A
So
that's
like
exactly
what
I
described
before
in
the
in
the
image:
let's
do
a
cat
of
our
services,
so
this
is
the
next
layer
right.
So
we
have
our
deployment.
We
want
to
be
able
to
have
our
service
group,
these
deploy
deployments
and
pods
together
cool.
So
again
our
resource
is
called
service.
We
want
to
name
it.
Nginx
I
probably
should
have
just
called
it
nginx
service.
Sorry
about
that
that'll
happen
in
part
two
and
I.
We
have
our
selector
and
the
label
that
it
selecting
is
App
Engine
X.
A
What
we're
doing
is
we're
routing
the
traffic
to
port
80.
So
that's
our
service.
Let's
do
a
cat
of
our
ingress
cool
once
again
same
deal.
What
we
have
is
an
ingress
controller.
We're
naming
this
resource.
Ingre
nginx
I
want
to
add
ingress,
but
again,
that's
in
part
two
and
then
what
we
want
to
do
is
we
want
to
we.
So
what
we're
doing
is
routing
traffic
to
our
nginx
service
and
then
we're
routing
traffic
to
port
80
and
then
we're
exposing
a
port
443
on
our
ingress.
A
So
let's
go
ahead
and
fingers
crossed
this
will
work,
I
believe
so
helm
install
part
1
part
1,
home
yay
cool.
So
what
we
see
here
is
all
I
had
to
do
was
do
how
install
part,
1,
helm
and
part
3
I
will
kind
of
show
you
the
alternative
of
like
so
the
pains
of
how
to
do
this
manually
with
cube
control,
and
so
what
this
shows.
Let's
do.
Our
deployment
is
called
filled.
A
Apakah,
so
I
like
she's
always
see
the
names
of
the
deployment
because
they
like
randomize
it
and
sometimes
they're
like
just
really
funny
cool,
and
so
that
is
there
and
then
let
me
see
if
we
can
actually
hit
this
endpoint
I
think
I,
hopefully,
okay,
cool,
let's
do
HTTP,
so
it
doesn't
yell
at
me
and
then
port
yeah
for
3.
Something
happened:
Oh
wrong,
port
yeah
for
3
yeah,
welcome
to
end
jannettek,
so
we
were
able
to
access
this
via
the
Internet,
okay
cool.
A
Let
me
do
so
now,
like
the
other
cool
thing
I
want,
you
to
notice
is
like
just
like
kind
of
notice.
How
fast
this
all
is
right.
So
let's
do
helm,
I,
think
the
community
leet
I,
hope
and
then
it's
I'm
going
to
delete
this
deployment,
and
then
it's
gonna
tear
everything
down
for
me
in
a
second
cool
yeah.
So
let's
do
a
Q
CTL
get
pods
and
we
can
see
things
terminating.
So
you
can
see
everything
like
in
terminating
status
right
now
and
we
know
that
helm
is
working.
A
It
helped
us
terminate
all
our
pods
for
us
with.
You
know
one
command-line
tool,
so
let's
go
ahead
and
CD
into
part
two,
and
this
is
where
I
want
to
talk
to
you
about
the
values
file
and
the
values
file.
Let's
actually
cut
out
templates,
slash
deployment,
okay.
So
what
this
does
is
that
we're
able
to
have
a
lot
of
configuration
variables
right,
so
you
don't
want
to
always
like
edit
the
actual
manifest
file
itself.
A
Every
time
what
you
want
to
be
able
to
do
is
just
sort
of
plug
in
this
configuration
files-
and
this
is
really
a
simple
example
to
be
able
to
change
each
deployment
right.
So
what
we
have
here
is
whatever
the
value
for
scale
is
within
our
value
mo
file.
Let
me
highlight
that
is
going
to
be
what's
in
the
configuration
file
and
then
whatever
value
we
have
in
for
tag
in
the
value
CMO
file
will
be
placed
there.
A
So
we
can
see
that
yep
we
have
three
pallets
up
and
running
and
then
what
I
want
to
do
is
cube
CTL,
exec
and
then
our
pod
name
and
I
just
want
to
like
double
again
that
this
is
the
version
I
think
I
said
1.13
right
so
B.
So
all
of
this
is
doing
is
exacting
into
that
pod
and
like
running
that
command
cool.
A
Okay,
so
I'm
gonna
go
ahead
and
do
clear
a
little
cheat
sheet
here
in
case
I
forget
okay,
so
what
I
want
to
do
is
do
a
helm
upgrade
and
I
have
set,
and
what
I
want
to
do.
I
want
to
set
the
values
that
I
had
before
that
you
saw
so
when
I
set
scale
and
I
set
image.
So
let
me
do
set
skill
equals.
Let's
go
crazy
and
say:
nine,
okay,
and
then
what
I
want
to
do
is
tag.
A
Let's
say
one
point:
what
happened?
Okay,
tag
1.12,
like
let's
I,
don't
know,
revert
back
for
some
reason
because
of
reasons.
Actually,
let
me
do
helm
list
because
we
also
need
to
set
up
the
release
there.
Okay,
so
tag
1.12
put
in
our
release
and
then
what
we
want
to
do
is
using.
We
want
to
upgrade
with
part
two
right
so
part
two.
A
Thanks
y'all
for
the
help:
that's
awesome:
okay,
cool!
So
now,
let's
go
ahead
and
do
keep
CTL
get
pods
again.
Okay,
so
we
have
some
terming,
let's
see
which
one
is
the
youngest
one,
okay,
nine
seconds.
So
what
I
want
to
see
is
that
this
is
version
one
point,
twelve
right.
So
let's
do
cube
CTL
exact
and
then
the
pod
name.
So
this
is
the
nine-minute
once
that
means.
This
is
like
a
new
one
and
Gen
X
dash
V.
A
A
A
Yeah,
it's
like,
but
yeah,
so
now
we
see
that
we
have
upgraded
to
one
point
twelve
and
then
we
should
also
see
that
we
have
nine
pods
up
and
running
so
cube.
Ctl
get
pods
cool.
So
now
we
have
9
pods
up
and
running.
So
now,
let's
go
ahead
and
do
rollback.
So
what
I
want
to
do
is
helm
rollback
and
then
I
want
to
upgrade
to
revision
1.
A
So
let's
do
how
AM
list
again
to
see
what
deployments
that
we've
had
so
how
rollback
and
then
this
is
our
release
and
then
revision,
1
cool,
so
robach
was
a
success.
So
hopefully
now
what
we
want
to
do
is
check
to
see
that
we
are
now
back
on
version
a
1.13
with
three
pods
of
our
deployment.
So
this
is
going
to
roll
back
to
your
previous
version
cool
and,
let's
do
cube.
A
Ct
I'll
get
pods
again,
so
we
can
see
that
we
have
a
lot
of
pods
that
are
terminating,
so
this
is
again
getting
back
to
our
desired
state.
So,
let's
pull
up
this
pod
name
and
then
we're
going
to
exact
into
this
and
I'm
going
to
make
sure
this
command
is
correct
and
cool,
so
we're
back
on
113
and
then
what
we
should
have
is
again
three
pods
only
that
are
up
and
running
cool.
So
this
was
our
demo
of
helm.
A
Give
it
a
second
cool,
so,
let's
go
into
part
three
cube
CTL,
so
this
is
I
kind
of
wanted
to
show
you
the
alternative
right.
So
this
is
like,
if
we're
deploying
each
resource
on
its
own.
So
let's
do
QC
TL
apply
F
and
then
what
we
want
to
do
is
actually,
let's
do
something
out
of
order.
So,
let's
see
what
happens,
we
want
to
deploy
the
service.
We
want
to
apply
that
service
yamo
deployment
and
then
also
we
wanted
to
deploy
an
ingress
controller.
A
So
if
I
had
created
a
secret,
for
instance,
there
is
like
certain
orders
that
you
need
to
be
able
to
do
everything
in
so
you
can
see
already
that
we
have
three
commands
to
be
able
to
do
the
same
thing
that
helm
did
in
one.
The
next
thing
I
want
to
do
is
just
quickly
sort
of
like
set
the
image
to
1.13.
So
let's
see
how
to
do
this
cue
CTL
set
image
deployment,
/
nginx
deployment
and
then
nginx
equals
1.13.
A
A
Nginx
replicas
equals
nine
okay.
So
the
next
thing.
So
you
can
see
that
already
that,
let
me
scroll
up,
you
can
see
already
that
I
have
like
done.
Let's
see
one
two,
three
four
five
commands
and
the
other
thing
is
is
like
in
terms
of
versioning.
How
are
we
able
to
version
this
right?
What
we
did
is
what
we
all
we
did
is
like
release
each
resource
on
its
own
there's,
no
coupling
of
resources,
sort
of
releasing
the
deployment
together
and
that's
the
sort
of
the
value
add
and
benefit
that
helm
provides
for
you.
A
So
hopefully,
if
you're,
a
beginner
I
hope
you
learned
a
lot
in
terms
of
how
to
get
from
a
web
app
to
cluster
and
version
handling,
and
then,
if
you
are
advanced,
I
hope
this
is
a
good
way
for
you
to
sort
of
like
teach
your,
maybe
junior
engineers
or
new,
urge
people
to
your
team
about
kubernetes
helm
and
how
they
get
everything
onto
the
cloud.
So
thank
you
so
much
for
your
time.
Yeah.
A
A
A
Yeah
I'm
not
sure
that
I'm
the
best
person
to
answer
that
question
but
I
think
there's
a
lot
of
like
problems
in
solutions
being
happening
in
the
storage
world
and
I'm,
not
quite
versed
with
that,
but
definitely
I.
Think
storage.
Os
is
actually
here
and
they're
like
doing
a
lot
of
I
think
they
have
a
talk
tomorrow
as
well
about
like
a
lot
of
storage
solutions
for
kubernetes,
which
definitely
like
persistent
storage
and
things
like
that
of
like
having
state
for
your
databases,
is
like
a
huge
problem.