►
From YouTube: From Containerized Application to Secure and Scaling W/ Kubernetes - Shikha Srivastava & Erica Brown
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
From Containerized Application to Secure and Scaling With Kubernetes - Shikha Srivastava & Erica Brown, IBM
What does it really take to make sure your application is production ready? With new privacy regulations being added, many aspects need to be taken into account when deciding when to deliver your final application is ready for production. Can your application handle multiple users with different levels of access? Can you extend your application to use existing authentication and authorization platforms? Have you invested in using Mutual TLS for communication between components? How do you manage the certificates and passwords used within your product? Is CICD your friend or your enemy when it comes to delivering your product? Have you considered the availability and scalability of the application? Shikha and Erica will cover all aspects from start to finish on how to deliver production-ready code.
To learn more click here: https://sched.co/FuKq
A
A
So
what
we
are
going
to
talk
about
today
is
getting
to
a
production
environment
and
what
it
takes
to
get
there.
We
have
seen
a
lot
of
talks
on
creating
containers
setting
up
kubernetes,
but
what
we
two
decided
to
work
on
was
to
figure
out
what
are
the
key
capabilities
are
needed,
both
in
the
container
crate
during
the
time
of
container
creation
and
during
the
time
of
setting
up
the
kubernetes,
to
really
help
your
application
be
production
grade.
A
Resiliency
high
availability,
24
by
7
repeated
deployments,
your
updates
that
needs
to
be
done
without
any
downtime,
so
those
are
the
things
and
the
last
nut
with
the
lead
there,
sorry
agility.
So
now
now
it's
not
like
your
application
is
running
for
six
month
a
year
before
you
get
the
update,
it's
like
weekly
updates.
Are
it
needed
to?
So
that's
that's
what
comes
to
mind
when
you
think
about
the
production,
application
and
except
the
younger
folks,
I'm
sure
some
of
us
can
relate
to
this
slide,
which
is
when
we
does.
A
It
have
a
ok
which
is
when
you
have
a
production
environment
and
a
failover
environment.
So
if
this
goes
down,
then
there's
something
to
back
up.
This
is
the
copies
of
your
application
running
on
systems,
and
the
painful
part
was
to
make
sure
that
the
data
and
the
transactions
are
all
replicated
across.
So
I
have
lived
through
this.
A
That's
where,
when
the
kubernetes
came
out,
it's
so
much
more
relaxing
and
more
fun
and
really
easy
to
manage
so
going
to
the
next
slide
as
a
developed
developer.
We
would
really
appreciate
if
we
were
just
left
to
do
our
coding
and
really
get
to
this
model
right
here.
I
can
design,
develop,
test
and
release
and
not
release
pearl
OS
or
not
release
pearl,
staging
dev
or
production
environment,
so
just
release
and
be
agile,
so
agility
is
added
now,
which
is
could
be
weeks,
maybe
months
sometimes,
but
it's
usually
weeks.
A
That's
what
we
think
of
when
we
come
to
agile
coding,
so
bill
ship
and
run
anywhere,
and
that's
what
the
containers
promise
us
then
the
next
one
is
for
me.
It's
really
helpful.
If
I
can
offload
the
deployment,
HHA
resiliency
upgrade
strategy
to
somebody
else
and
not
worry
about
it.
That's
another
dream
and
that's
where
containers
kubernetes
and
cloud
sale
comes
to
mind
for
production
use
case.
A
So
what
does
really
mean
for
my
applications?
The
applications
now
if
they
are
not
monoliths
anymore,
I'm,
learning
to
use
this
okay
they're,
not
monoliths
anymore?
They
need
to
be
broken
down.
Microservices
and
that's
a
good
thing,
because
I
might
be
just
good
at
the
UI
development.
I
might
be
just
good
at
back-end
development
just
doing
the
transactions.
That's
we're
broke
breaking
down
into
micro
services
is
a
really
good
thing
and
that's
where
containers
come
in.
You
can
break
the
micro
services
down
and
follow
the
continuous
delivery
and
continuous
integration
model.
A
But
with
that,
some
challenges
comes
as
well,
because
you
need
to
make
sure
your
containers
are
running
together.
Well,
and
so
then
you
need
to
offload
your
management
of
the
containers
to
somebody
else
and
that's
where
kubernetes
comes
into
play
and
that's
why
we
are
all
here
last
but
not
the
least
the
security
comes
in
at
each
step.
It
doesn't
come
in
at
the
very
end.
A
Now
the
rest
of
the
slides,
what
we
thought
of
was
to
go
through
what
are
the
key
best
practices
we
found
why
creating
these
containers
for
shipping
our
product
plus?
What
does
it
mean
when
you're
running
in
the
kubernetes
environment
and
where
did
we
land
up?
So
those
are
the
things
that
we're
going
to
cover
for
building
containers.
A
A
There
should
be
a
private
trusted
repo
for
the
organization
where
you
can
run
security
checks
and
all
that's
a
must-have
for
the
production
setup,
remove
any
more
vulnerabilities,
so
not
only
at
the
time
of
when
you
take
the
base
image
or
when
you
create
your
image,
but
repeatedly
as
you
as
you
ship.
Oh
sorry,
go
back
one
more
okay,
sensitive
data,
no
passwords
in
your
docker
files
should
be
self-contained.
Now
we
say
that,
but
as
a
developer,
we
know
that
that's
not
always
possible,
but
it
should
be
mostly
self-contained.
A
A
You
should
have
the
same
image
for
the
for
all
your
environment
as
I
say
that
I
know
there
are
some
some
places
where
it's
compromised.
It's
not
same
container
image
in
your
production
dev,
but
that's
that's
the
key
here
to
make
your
container
image
immutable
and
single
process
per
container
I.
Think
we're
all
agree
to
that.
One.
A
The
other
one
is
a
what's
running:
how
you're
creating
how
you're
coding
your
image
to
create
the
containers.
Non-Root
run
your
containers
as
non-root.
We
have
docker
files
to
show
at
the
end
as
well,
but
anytime,
a
user
gets
access
to
your
container
and
your
container
is
running
as
root
pretty
much,
that
user
has
access
to
the
host
system
and
that's
a
no-no
for
production
environment.
A
No
ownership
of
this
supporting
subsystem
like
storage,
your
database,
etc.
No
direct
dependencies
you
should
have
what
we'll
go
through
later
is
liveliness
for
probes
and
readiness
probes.
You
should
never
have
direct
dependencies
and
wait
for
the
system
to
come
up
configurations
in
the
config
map
and
secrets
and
sensitive
info
in
the
secrets.
A
That's
a
really
good
thing
that
we
get
from
the
kubernetes.
Where
you
can.
You
can
use
those
variables
long
lasting
data,
as
we
know
that
containers
are
transient,
they'll
go
up
and
come
down
and
we
we
might
have
done
some
these
mistakes
earlier,
but
all
the
long-lasting
data
should
be
in
database
run
with
minimal
privilege
privileges.
A
There
is.
There
is
a
concept
in
kubernetes
called
PSP
spot
security
policies.
We
actually
enabled
them
that
in
IBM
cloud,
private
and
I
will
take
you
through
the
demo
a
little
bit
where
you
can
define
very
many
privileges,
only
what's
needed
for
your
pod.
For
example,
if
you
just
need
the
fat
access
to
the
host
files,
you
can
specify
that
there
are
at
least
twelve
or
fourteen
different
access
that
you
can
restrict
using
the
PSP
disposable
yep.
C
A
A
A
Everybody
know
it's,
okay!
Thank
you.
Thanks
for
the
response,
ok
going
to
the
scaling.
First,
that's
the
I
need
to
learn
the
clicker
here.
First,
okay,
what
we
did
in
our
demo
sample
is
to
create
the
deployments
and
there's
a
reason
here.
The
deployments
really
manages
the
replicas
and
replicas
are
great
for
having
your
high
availability
concept
in
place
and
replicas
actually
helps
manage
something
that
I
have
in
the
next
slide
rolling
updates.
Those
are
really
important
ones
to
keep
in
mind
when
you
are
setting
up
your
kubernetes
and
you're
running
your
pods
or
configuring.
A
Deployment
instructs
the
clusters
how
to
create
and
scale
apps.
So
here
is
the
deployment
you
can
see.
Deployment
manages
the
reflect
replica
sets
and
replicas
set.
Has
the
templates
how
to
create
your
containers
and
also
tells
tells
kubernetes
how
many
to
run
at
a
time,
so
you
can
have
two
and
during
during
the
time
it's
running
when
your
production
environment
is
up,
you
can
change
the
number
of
replica
sets.
You
can
change.
The
number
of
replica
sets.
That's
really
great
once
you
figure
out,
if
you
need
more
of
your
containers,
running.
A
And
then
addition-
and
this
is
a
service-
I-
didn't
go
through
the
basics,
but
this
is
your
service
that
actually
is
talking
to
these
two
parts
together,
auto-scaling,
that's
the
new
concept
that
came
out.
There
has
been
several
talks
yesterday
on
it.
There
is
really
two
HP
a
horizontal
pod,
auto
scaling
and
the
other
one
is
vertical:
pods
hot,
auto
scaling,
HP
a
is
GA,
and
it's
really
great
to
use
it
just
works
on
the
CPU
usage,
so
you
can
define
the
resource
metric.
A
You
can
define
the
usage
as
of
now
kubernetes
supports
CPU
based
on
CPU.
You
said
you
can
put
the
HP
a
policy
in
place
to
drive
how
many
replica
sets
to
be
added,
which
is
really
good,
and
there
is
VP
a
as
well
vertical
pod
autoscaler,
which
works
vertically.
It's
in
still
in
beta,
it's
not
GA,
and
there
is
also
cluster
autoscaler.
I
have
not
gone
and
looked
at
this,
but
I
heard
ca
is
GA
as
well,
so
might
be
good
to
look
at,
but
back
to
their
HP
a
it.
A
A
A
Deployments
allows
for
rolling
out
updates
for
cases
where
really
backwards
compatibility
is
there.
There
are
always
some
security
updates
needed.
That's
where
this
comes
out
very
handy
right
here
is
the
snippet,
so
minimum
ready
seconds
it.
It
is
the
time
your
application
boots
up
so
by
default.
Kubernetes
will
think
that
your
application
is
ready
as
soon
as
you
as
soon
as
pod
comes
up,
but
with
this
it
tells
you
tell
the
kubernetes
that
how
much
time
it
takes
for
your
app
to
come
up
and
I'll
wait
for
this
many
seconds.
A
Maximum
search
is
the
number
of
pods
in
addition
to
the
desired
ones.
So,
if
you
have,
if
you
want
during
your
rolling
up
ray
upgrades,
you
want
an
additional
part
to
be
up
and
running
before
the
pod
goes
down.
You
may
want
to
send
this
up,
and
maximum
unavailable
parts
is
the
number
of
parts
that
can
be
unable
unavailable
at
the
time.
You
are
doing
it's
doing.
The
rolling
upgrades
by
default
I
need
to
go,
look
but
I
think
by
default.
A
A
C
A
Lively
nose,
liveliness
probe,
tells
indicates
when
the
application
is
running,
ready,
Israeli
and
running
readiness
probe
tells
readiness
probe
tells
kubernetes
when
the
application
is
ready
to
take
traffic.
So
if
you're
lazy
and
if
you're
not
implementing,
if
you
planning
to
implement
one
of
these
to
make
sure
you
do
the
readiness
probe
for
sure,
because
this
tells
when
your
application
is
ready
to
take
traffic,
otherwise
your
application
will
be
your
traffic
will
go
nowhere.
There
are
really
three
types:
HTTP
one
is
the
example
here
and
then
you
can
also
add
command
or
TCP.
A
Requests
and
limit
and
resource
code
up
I
was
at
the
talk
yesterday
and
it's
really
great
to
see
when,
when
similar
concepts
are
getting
taught
in
other
talks,
that
really
means
then,
when
two
people
or
three
people
are
sitting
and
creating
the
chart
they're.
Thinking
of
the
same
thing,
that's
that
tells
you
that
you
know
these
are
important
and
valid
points
and
good
thinking
there.
So
I
I
saw
a
similar
discussion
yesterday
in
one
of
the
talks.
It
was
from
an
elastic
search.
A
I
am
embarrassed,
I,
don't
remember
the
name
of
the
person,
but
he
was
talking
about
similar
production
environments,
and
we
talk
later
about
this
as
well,
where
we
definitely
need
to
make
sure
that
our
our
containers
are
running
with
the
requests
limit
requests
and
the
limit
set
of
requests
tells
the
customer
requests
guarantees
that
kubernetes
will
definitely
provide
the
memory
and
CPU
that
you
asked
for
limit.
Tells
you
that
this
is
the
one
that
you
can.
It
can
go
further.
Add
for
you.
A
So
that's
a
really
good
thing
to
do
and
I'll
tell
you
why.
If
you
are,
if
you're
running
your
containers-
and
somebody
else
starts
adding
more
containers,
then-
and
if
you
haven't
specified
this,
you
might
be,
you
might
be
really
fighting
for
the
resources
for
the
containers
that
have
been
running
so
good
and
your
applications
are
up
and
running
fine
and
all
of
a
sudden,
you
figure
out
that
your
applications
are
not
doing
good.
A
So
it's
a
really
good
idea
to
set
this
up
resource
code
up
when
you're
setting
up
your
kubernetes,
you
can
organize
kubernetes
into
namespaces,
and
resource
quota
really
helps
its
prize,
the
constraint
towards
aggregate
resource
consumption
by
her
namespace.
So
if
you
can
think
about,
if
you're
setting
up
your
cluster,
maybe
with
a
dev
namespace
and
a
production,
namespace
is
a
good
idea
to
limit
the
dev
namespace
with
a
certain
number
of
computer
resource.
A
So
right
here
is
the
example
of
resource
kora.
You,
you
can
specify
I,
see
a
typo
here
for
my
for
myself
request
that
memory
request
our
CPU
is
this.
Is
this:
is
the
value
specified
there
and
it
really
tells
kubernetes
the
maximum
combined
CPU
request
or
the
computer
request
in
in
the
unit?
For
all
containers
in
the
namespace,
so
it
really
sets
the
quota
up.
A
I'll
touch
on
one
more
point
here
when
you're
setting
up
in
your
in
your
environment.
When
you
are
the
cloud
provider,
you
want
to
charge
your
your
departments
that
are
that
is
using
your
cloud
and
that's
where
this
comes
really
handy,
because
you're
setting
this
environment
up,
you
know
exactly
how
they
are
charged
exactly
what
they're
using
and
that's
how
you
can
make
sure
you
can
charge
them
well
accurately.
A
So
now
little
bit
about
security
as
we
went
through
setting
up
the
environment,
these
are
the
important
things
that
that
we
had
to
make
sure
that
we
are
definitely
doing
no
components
talks
to
each
other
without
search.
There
should
be
search
enabled
and
it
should
be
through
secrets.
You
cannot
it's
not
a
well-known
sort.
It
should
be
as
well-defined,
secure,
certs
TLS
enablement,
all
communication
over
TLS
disable
any
and
every
anonymous
login
an
important
one.
There
should
be
an
audit
trail
for
any
crud
operation.
A
A
It
really
defines
how
your
pods
are
running,
so
you
can
make
your
pods
run
as
restrictive
as
you
can,
or
allow
it
to
run,
get
any
privileges
and
do
in
between.
So
it's
really
good
to
define
pod,
secure
security
policy
and
make
sure
your
pod
adheres
to
certain
part
security
policies
and
know
that
which
ones
are
running
privileged
under
privileged
conditions
touched
on
that
one.
A
A
A
So
this
is
some
kind
of
a
summary
chart,
and
the
point
emphasize
here
is
that
production
thinking
doesn't
and
anywhere
or
doesn't
start
at
any
place.
It
starts
and
ends
from
end
to
end
when
you
start
building
your
containers
or
building
your
images
when
you
ready
to
ship
it
when
you're
a
deployed
when
you
run
run
it
taking
advantage
of
the
features
that
contain
nurse,
provide
you
and
kubernetes
provides
you
it's
really.
A
A
All
this
all
the
talks
that
all
the
points
that
I
touched
on
are
covered
with
the
cloud
provider
or
the
cloud
that
we
are
building
cloud
private
and
it's
based
on
coop,
open
source,
kubernetes
and
talker.
We
add
core
operational
services
on
top
log
management,
which
is
open,
source,
elq,
monitoring,
primitives,
refined
amazed.
There's
metering
metering
tells
you
exactly
how
your
how
people
are
using
the
cloud
security
is
enabled
end
to
end
I
touched
on
a
slide
where
I
called
out
certs
enabling
certs
enabling
TLS
are
back.
A
That's
all
covered
through
the
model
that
we
provide
in
the
cloud
private,
alerting,
Prometheus
based
alerts,
deployment.
We
use
helm
for
our
deployment.
We
actually
have
added
features
or
features
in
the
deployment
to
make
sure
that
we
have
security
from
end
to
end.
So
we
have
implemented
impersonation
in
the
in
the
tiller
to
make
sure
that
whoever
starts
the
deployment
is
the
one
who
is
deploying
the
charts.
A
A
I
want
to
make
sure
we
have
time
for
the
demo.
This
is
kind
of
repetition,
repetition
on
the
chart
and
that's
the
digital
asset.
It's
I've
uploaded
the
slides
we
do
have.
We
do
have
a
community
edition
version
of
IBM
cloud,
private,
build
on
kubernetes
and
and
dharak
docker
containers.
That's
honor
were
on
the
docker
hub,
that's
easy
to
download
and
use
and
free,
and
there
are
other
garage
methods
and
other
digital
technical
engagements
that
you
can
use
alright.
So,
let's
get
to
the
demo.
A
B
Ok,
so
we're
gonna
start
with
looking
at
the
different
pot
security
policies
that
we
have
in
place
inside
of
the
actual
namespace.
Basically,
we
created
an
app
a
production
level
app
that
is
supposed
to
kind
of
demonstrate.
You
know
how
we're
supposed
to
go
through
the
flow
of
you
know,
creating
your
production
level
app.
So
what
we
did
was
we
created
a
new
new
namespace
and
we
have
a
specific
high
security
policy
here
by
default.
B
B
So
now
we
have
the
the
helm
chart
deployed
and
it
has
a
few
resources
that
are
attached
to
it.
But
right
now
we're
just
looking
at
the
deployments
and
you'll
see
that
you
know
there's
currently
a
couple
of
one-pot
available,
even
though
we
want
we
specified
that
we
wanted
three
replicas
sets
so
inside
of
here
you
can
see
once
all
the
pods
are
actually
ready.
You
can
drill
down
a
little
bit
further
to
see
that
whether
or
not
you
know
it
really
is
healthy.
So
on
this
page
you
would
actually
see
if
it's
not
healthy.
B
So
here's
a
screen
shot
that
I
have
basically
in
this
screen
shot
you'll
see
that
my
pot
didn't
come
up
because
the
live
limit.
Excuse
me,
the
readiness
probe
basically
said
that
it
wasn't
ready,
and
so
basically
it
killed
it
because
something
happened
and
we
didn't
configure
it
properly,
but
because
we
added
that
we
at
least
knew
okay
something's,
not
right,
so
we
need
to
go
back
and
look
at
it
right.
B
So
going
back
to
the
demo
and
again,
this
is
where
you
would
see
you
know
everything
is
ready
and
you're
pots
are
healthy
due
to
the
the
liveliness,
the
readiness
probe
being
okay
and
the
liveliness
probe
being
okay
and
then
that's
the
container.
You
know
that
actually
has
the
app
code
on
it
and
so
from
here,
let's
see
what
we're
gonna
be
looking
at,
so
we
have
yeah.
So
let's
look
at
we're,
gonna
be
looking
at
the
docker
file
because
we
actually
talked
about
how
you
shouldn't
store.
B
You
know
privileged
information
inside
your
docker
file,
so
this
is
just
an
example.
Docker
file
that
we
will
use
you
know
typically,
because
we
are
deploying
our
app
in
multiple.
You
know
for
multiple
operating
systems.
We
would
have
either
a
docker
file
that
is
updated
to
use.
You
know
the
different
type
of
operating
systems
like
some
type
of
rail
docker
files,
some
type
of
power
based
docker
file,
but
we
would
ship
all
of
our
applications.
B
On
top
of
you
know
different
platforms,
but
in
here
you
know
it's
a
single
note
process
you'll
see
that
we're
only
running
this
as
the
nobody
user.
For
this
specific,
you
know
version
well
this
specific
docker
file.
So
when,
if
somebody
you
know
actually
exact
into
the
pot
or
SSH
into
the
into
the
pot,
then
basically
they
wouldn't
have
root
access.
They
would
only
have
the
nobody
access,
which
means
they
can't
really
edit
anything.
They
can't
do
anything.
B
So
you
don't
really
see
it
right,
so
we're
storing
all
of
our
secure
data
in
a
secret,
and
let's
see
here
and
from
here.
Basically,
you
can
see
that
you
can
scale
this
deployment
up
or
you
can
scale
it
down
and
you'll
see
right
here
that
the
number
of
pods
is
about
to
go
up.
Even
though
right
now
it's
only
three
and
then
we
come
back
in
here
and
you'll
see.
B
You
know
we
got
more
pods
right
and
then
basically,
this
is
just
showing
you
that
you
know
we
have
different
users
that
have
different
levels
and
authorization
and
authentication.
But
that
was
just
another
thing
that
we
kind
of
touched
on
inside
of
the
inside
of
the
talk
and
I
think
that's
it
for
the
demo.
Do
we
want
to
pause.
A
D
A
A
Well,
hopefully,
your
production
namespace
won't
get
deleted,
but
that's
why
we
do
recommend.
Have
the
cluster
failover
as
well,
so
that
you
know
if
there
are
accidentals
stuff
as
deleting
the
namespace,
then
you
have
a
cluster
failover.
You
do
set
up
a
cluster
failover
in
case
of
your
production,
environment,
yep,
but
but
to
think
about
it
when
you,
when
you're,
creating
the
namespace
and
in
deploying
containers
in
it,
you
are
you're,
not
storing
any
persistent
data
inside
it.
A
A
B
If
you,
if
one
of
them
actually
got
deleted,
then
you
know
because
it
replicated
over
to
a
different
one
right.
You
would
actually
have
all
that
data
replicated
to
the
other
share
shared
persistent
storages
and
that's
why,
on
one
of
the
slides
that
she
presented
either
you're
gonna
use
a
database.
Hopefully-
and
you
have
you
know
some
type
of
H,
a
or
replication
in
those
databases
set
up
or
you
use
a
shared
persistent
storage,
and
if
you
have
multiple
replicas
of
that,
which
is
the
best
practice
right.
A
A
D
So
so
in
a
large
organization
in
order
to
produce
a
production-ready
application
and
as
you
said,
it
will
go
to
a
long
pipeline
and
there
will
be
a
lot
of
people.
Roles
and
parties
involved.
For
example,
like
a
developer
may
be
focused
on
just
business
logic,
and
they
may
not
know
about
security
about
how
to
update
applications.
D
Security
like
an
optimization
of
resources
etc,
and
they
may
not
even
know,
containers
or
kubernetes
at
all,
so
I
think.
If
the
the
pipeline
is
not
working
organically,
then
this
process
may
be
very
inefficient.
So
I
wonder
like
how
a
large
organization
can
solve
this
problem.
For
example
like
how
IBM
have
been
dealing
with
this.
A
And
I'll
give
you
an
example:
we
we
do
create
images
and
we
had
the
all.
The
squads
run
the
vulnerability
advisor
on
their
own
or
pen
test,
or
you
know,
zap
test
on
their
own,
but
per
squad,
but
what
we
are
doing
right
now
is
it's
a
cultural
change.
It's
not
something
that
happens
over
time.
What
we
are
doing
is
integrating
the
all
the
test,
automating
it
in
the
pipeline
itself.
So
when
you
are
pushing
the
image
there
is
the
vulnerability
advisor
getting
run
on
your
images.
There
is
the
pen
test.
There's
other
tests.
A
That's
gets
done,
so
it's
as
much
automation
as
possible
is
really
good.
Cic
d-squad.
We
have
a
separate
CIC
d-squad
that
actually
works
on
this
specific
problem
day
and
night,
so
that
other
squads
don't
have
to
worry
about
it
too
much.
They
get.
They
get
the
issue
to
resolve
when
there
is
a
vulnerability
found
in
their
images,
but
they're
not
they're,
not
the
people
to
worry
about
Oh
what
all
I
have
to
run
on
my
on
my
images
or
in
the
environment.
So
these
are.
A
This
is
something
CIC
D
pipeline,
CIC
D
squad
that
things
about
it
and
gets
it
integrated
in
there
in
the
pipeline
itself,
so
that
that's
how
we
are
doing
in
IBM
to
make
sure
that
we
don't
miss
on
these.
We
don't
put
the
burden
on
each
of
the
squad.
We
don't
have
to
go.
We
definitely
have
to
educate
all
the
squads,
but
we
don't
have
to
put
the
burden
of
doing
all
the
tests
and
making
sure
nothing
gets
left
out.
It's
automated
in
the
pipeline
itself
as
much
as
possible.
I
agree.
Not
not.
B
C
B
We
actually
do
have
a
very
a
very.
We
have
basically
a
very
detailed
CI
CV
process.
So
basically
we
go
to
our
integration
phase
and
then
we
do
some
testing
on
the
on
the
on
the
integration
in
all
of
the
integration
images.
Before
we
actually
do
the
promotion
and
then
from
there
there
are
just
different,
deeper
tests
that
we
do
on
those
level
of
images
once
they
actually
pass
before.
B
We
actually
do
the
promotion
for
each
stage
so
and
then,
once
we
get
to
a
certain
stage
in
our
release
cycle,
then
we
actually
have
a
point
where,
instead
of
actually
automatically
doing
you
know
like
the
promotion,
we
start
cherry-picking
images
so
that
we
don't
let
any
other
changes
come
in.
That
don't
need
to
be
added.
So.
B
A
Could
do
it
in
by
namespace
as
well
as
you
know,
namespace
helps
you
create
virtual
cluster
within
the
cluster,
so
you
could
do
it
it.
That
really
depends
on
the
size
of
the
organization,
but
I
touch
on
it.
Automation
is
the
friend
we
we
go
through
whenever
we
create
new
features.
The
first
thing
is
the
test:
automation
should
be
done
and
that
in
gets
integrated
in
the
pipeline.
So
you
know
when
you're
running
you're,
when
you're,
adding
more
OSS
or
when
you
are
doing
other
feature
development.
The
odd
you
can
do
the
regression
tests
easily.
B
We
do
some
automated
tests
in
the
pipeline,
but
there's
also
manual
tests,
some
for
the
the
deeper
level
testing
that
we
do
before.
We
actually
promote
it.
So
like
a
release,
level
or
a
stable
level.
So
we
do
both.
We
do
automate
it
and
we
do
manual
before
we
do.
The
promotion
of
those
specific
images
between
the
stages
of
our
pipeline.
A
A
there's
a
process
there's
a
separation
of
duty
involved
at
there
as
well,
so
the
debugging
process.
The
way
it
happens
is
it's.
We
have
the
elk
environment
set
up,
so
we
have
the
logs.
We
have
audit
trail
set
up,
so
we
know
you
know
what
who
caused
it
say
it
in
terms
of
if
it's
really
the
auditing
problem.
We
have
audit
trail
setup.
It
is.
It
goes
to
the
Siem
database
as
well
like
a
curator,
so
you
can
find
out
exactly
who
did
it?
How
did
it
date
and
time
tracked?
A
We
have
a
monitoring,
setup,
Prometheus
Angra
fauna,
so
you
can
see
the
events
coming
in
and
there's
out-of-the-box
alerts
setup
as
well,
so
you
can
get
alerted
if
that's
caught
and
then
for
logging
side.
Once
you
figure
out
where
the
when
the
event
happened,
you
can
go
to
the
logging,
which
is
elk
and
Cabana
bass
with
the
log
stash
to
buffer
the
data
and
send
the
data
over
to
elastic
search.
So
you
can
look
at
the
logs.
We
do
collect
standard
out
standard
error
for
all
the
containers.
A
If,
if
we,
since
it's
a
cloud,
you
can
bring
your
own
images,
you
can
set
up
five
beat
as
citecar
to
send
your
own
data
over
to
the
elastic,
so
it
is
all
about
setting
it
up
right
and
then
be
able
to
see
the
log.
So,
yes,
we
do
have
access
to
the
logs
to
see
what's
going
on
going
wrong
with
it
all
right,
like
we're
done.
Thank
you.
Everybody.