►
From YouTube: Fidelity’s Move to “Finance Grade” Kubernetes with... Alexis Richardson & Rajarajan Pudupatti SJ
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
Fidelity’s Move to “Finance Grade” Kubernetes with GitOps - Alexis Richardson, Weaveworks & Rajarajan Pudupatti SJ, Fidelity Investments
Fidelity Investments is one of the largest financial asset managers in the world. Every application must meet a unique mix of regulatory, security and governance requirements to protect customers. When Fidelity adopted Kubernetes for cloud application delivery, they teamed up with AWS and Weaveworks to use GitOps as a tool to analyse and implement a compliant platform. In this session, Rajan Pudupatti, Cloud Platforms Architect at Fidelity Investments and Alexis Richardson, CEO of Weaveworks, will present the story. We’ll include: when to automate, securing your CD pipeline, adding deployment policy for clusters and applications, connecting enterprise development tools to cloud automation services. The session covers challenges and lessons learned implementing the Fidelity Kubernetes platform with GitOps best practices, to operate efficiently and securely at scale.
https://sched.co/UaYS
A
A
So
if
we
falter
in
our
presentation,
please
be
a
little
generous
first
time,
we'll
take
turns
to
speak,
so
we're
going
to
talk
about
the
adoption
kubernetes
in
a
large
financial
organization.
What
are
the
practical
questions
that
creates?
What
are
the
challenges?
How
are
they
overcome?
I
all
talk
about
the
challenges.
Rajyam
will
tell
you
how
you
fix
them
all.
A
So
what
is
the
principle
challenge?
There's
a
conflict
between
two
opposing
goals:
on
the
one
hand,
people
are
adopting
kubernetes
for
flexibility
to
go
faster,
to
be
able
to
choose
where
to
run
things,
what
kinds
of
app
types
to
run.
Many
many
many
benefits
like
that.
On
the
other
hand,
fidelity
is
a
highly
regulated
organisation
in
the
financial
services
business.
It
looks
after
people's
money,
it
needs
to
know
who
can
access
its
data.
It
needs
to
be
very
careful
about
that
sort
of
thing.
A
I've
seen
it
again
and
again,
people
who've
been
used
to
say
doing:
digital
apps,
Silicon,
Valley
style,
many
changes
a
day
come
in
and
suddenly
somebody's
telling
them.
No,
you
can't
do
this.
No,
you
can't
do
that.
Also,
quite
often
someone
will
say
what
can't
we
use
the
elastic
container
registry,
what
allowed
use
that
we
have
to
use
X
Y,
we
using
X,
we've
been
using
it
since
2003
and
so
on.
Your
favorite
tools
that
you
were
used
to
using
on
that
cool
last
project.
A
Now,
what's
next
we're
gonna
run
apps
we're
not
gonna,
run
them
directly
on
cue
Bonelli's,
we're
gonna
run
them
on
application
platform,
which
includes
extra
things
like
AWS
services,
but
also
the
fidelity
bits,
because
you
might
have
the
special
secret
stuff
that
makes
the
apps
safe
to
use.
When
we've
got
that,
we
can
start
thinking
about
different
use
cases.
This
is
what
I
personally
like
to
call
multi
powers.
A
Different
platforms,
when
you
haven't,
might
have
machine
learning
platform
for
machine
learning,
apps
or
a
mobile
platform
for
mobile
backend,
or
maybe
a
financial
one,
so
that
creates
a
problem.
It's
pretty
easy
nowadays
to
get
a
cluster
up,
whether
you're
using
open
source,
cuba,
DM
or
eks,
for
example,
gke,
but
actually
you're
gonna
run
an
application
on
a
specific
set
curated
set
of
tools.
You
want
to
be
given
a
machine,
learning
stack
or
a
finance
stack
and
that
will
needs
to
be
manageable,
oops,
sorry,
so
think
about
that
before
Rajon
does
a
bit.
A
If
I
shoot
write-ins
cluster,
yes
to
restart
it,
can
he
restart
it
in
exactly
the
right
state
that
it
should
have
been
in
and
can
you
do
upgrades
on
all
of
this
really
important?
If
you
don't
at
the
answer,
these
questions
pay
close
attention
and
talk
to
us
afterwards.
The
underlying
reason
for
this
is
ultimately
everyone
out.
There
is
doing
this
sequence
of
things
in
a
different
way.
They
want
a
machine
learnings
fact.
They
need
to
figure
out
what
a
map
is.
What
are
the
platform
atoms
to
have?
A
B
A
A
B
Before
I
begin,
I
want
to
thank
everyone
for
coming
here.
Thank
you.
So
much
I'm
Rajan
have
a
lengthy
name,
I'm
very
famous
for
that
I'm
part
of
an
organization,
awesome
organization
with
infertility
that
is
responsible
for
enabling
cloud
and
within
that
I
focus
on
the
platform's
aspect
of
it.
So
in
the
upcoming
slides,
what
we're
going
to
see
is
few
things
right.
B
So
what
is
this
cloud
native
platform
for
the
ladies
cloud
native
platform
is
about
what
all
the
problems
it
solves
for
us
and
then
what
is
guitars
and
how
we
use
guitars
to
manage
the
delivery
of
the
platform.
So,
let's
begin
with
this
in
general
right,
any
platform
is
helpful
because
it
tries
to
abstract
away
the
complexities
right.
It
helps
user
to
focus
on
what
he's
supposed
to
do.
B
So
then,
you
put
something
like
that
in
the
context
of
a
company
like
fidelity,
where
there
is
a
constant
push
for
innovation,
where
developers
trying
to
come
up
with
innovative
solutions
all
the
time
and
then
move
in
a
very
fast
pace,
it
becomes
even
more
valuable.
The
reason
I
say
that
is,
let's
take
an
example
right.
B
So
in
fidelity,
if
you
have
to
take
an
application
to
production,
you
have
to
pass
certain
security
gates
right
and
in
order
for
you
to
do
that,
you
have
to
navigate
certain
complex
workflows
like
security
workflows,
it
could
be
manual,
it
could
be
automated,
doesn't
matter.
Usually
what
we
have
seen
from
our
experience
is
the
development
teams
are
okay
with
it
as
long
as
it's
one
time,
but
that's
never
the
case
right.
So
imagine
you
have
a
complex
workflow
that
you
go
through
and
then
you
want
to
make
an
update
to
that
process
right.
B
You
have
thousands
of
developers
working
and
then
rolling
out
an
update
to
an
existing
process
very
very
difficult,
so
that
is
where
packaging,
the
frenetic
context
in
the
name
of
a
platform
and
then
rolling
it
out
of
users,
creates
immense
value
for
us.
I
take
another
example.
This
there's
a
real
example
that
we
have
so
in
production.
Every
part
needs
to
handle
secret
management
in
a
standard
way
for
us.
So,
for
example,
any
application
that
comes
in
we
sort
of
inject
a
security
context
within
the
part.
B
For
example,
it's
a
combination
of
in
a
container
and
sidecar
that
bootstraps
the
security
aspect
of
it
and
then
allows
the
application
to
start
so
when,
typically,
when
the
applications
bootstrap,
when
they
start,
they
just
pick
up
a
token
which
is
already
scoped
down
to
what
the
token
can
do
and
then
it
runs
from
there.
So
this
is
where
the
cloud
native
platform
that
we
have
will
becomes
very
important
for
us.
B
So
typically,
what
what
we
do
here
is
you
take
a
couple
native
kubernetes
cluster,
and
then
you
apply
certain
core
capabilities
on
top
of
that,
so
these
core
capabilities
are
delivered
by
one
or
more
add-ons.
It
really
depends
on
the
depends
on
the
capability,
for
example
tenancy
management.
Right.
So
let's
say
there
is
an
end
user
for
us,
the
internal
clients
for
us
are
the
business
units.
B
So
if
they
come
to
us
and
say
that
we
need
like
a
platform
and
AWS
and
the
same
platform
needs
to
be
in
a
zoo
right,
so
the
tenancy
management
should
remain
same.
What
I
mean
by
that
is
how
close
to
the
administrator
slices
the
cluster
and
gives
it
to
the
tenants.
The
experience
should
remain
same
irrespective
of
the
environments,
so
that
is
where
the
core
capabilities
comes
into
picture.
So
the
rollout
of
the
updates
actually
happened
by
a
gate
up
Kitab
we
have
a
central
depot
where
the
entire
fede
case
version
is
maintained.
B
B
So
if,
let's
say,
there's
a
business
unit
that
actually
consumes
our
platform,
they
can
sort
of
take
that
take
the
validity
platform
and
apply
the
business
unit
specific
context
on
top
of
it
and
then
give
it
to
our
give
it
to
the
developers.
So
that's
an
added
advantage.
So
in
a
nutshell,
right
as
of
today,
this
is
how
the
platform
looks
like
you
have
the
infrastructure
layer
right
and
you
have
kubernetes.
On
top,
we
use
managed
control
plane
when
it
comes
to
AWS
and
Azure.
We
are
actually
running
eks
in
production.
B
Now
the
bits
that
you
see
on
top
of
kubernetes
is
the
core
capabilities.
That
I
was
referring
to,
for
example,
tenancy
management,
cluster
management.
How
do
you
bring
the
clusters?
Are
we
create
the
clusters?
How
do
you
bring
it
to
its
the
state
state,
all
those
sort
of
things,
ingress
management,
integrated
security
model?
B
All
those
things
are
part
of
this
core
capabilities
later,
the
one
that
you
see
on
the
top
I've
actually
given
a
star,
because
that's
a
work
in
progress
for
us,
but
that
is
where
we
want
to
be
so
imagine
you
take
a
kubernetes
cluster.
You
apply
a
layer
on
top
of
it,
that
is
the
core
capabilities
layer,
and
then
it
becomes
like
a
general
purpose
platform
right.
You
want
to
take
it
a
bit
further
and
apply
another
layer
on
top
of
it
saying
that
hey
this
is
the
ml
layer.
B
Now,
when
you
do
that,
you
get
like
an
ml
platform,
so
the
end-user
experience
that
we
want
to
provide
is
someone
coming
to
us
and
say
that
I
need
like
an
a
machine
learning
platform
and
AWS.
We
say
sure
you
got
it
and
then
they
say
that
we
want
to
move
to
Azure
and
this
we
need
the
same
ml
platform
manager.
When
you
have
a
model
like
this,
we
can
actually
make
sure
that
the
experience
remains
same
right
in
general.
B
Kubernetes
helps
you
with
the
cloud
providing
the
true
cloud
native
experience,
irrespective
of
whether
your
AWS
raju
right
by
adding
the
capability
layer
and
the
domain-specific
layer.
We
take
the
cloud
native
experience,
a
step
further
for
our
clients,
saying
that
not
just
cumin
rattles,
but
even
the
fertility
context
remains
same
irrespective
of
the
environment.
For
example,
dependency
management
remains
same
before
we
move
on
to
the
next
slide.
There
is
one
important
aspect
of
it:
I
want
to
cover
so
the
platform
itself.
If
you
look
at
it,
it's
it's
composable.
B
This
is
a
very,
very,
very
important
aspect
for
us.
What
I
mean
by
composable
is
at
any
point
in
time
right.
We
should
be
able
to
take
a
piece
out
of
that
and
then
replace
it
with
something
else.
I
don't
want
to
oversimplify
this,
because
sometimes
it's
very
difficult
to
so
to
do
something
like
this,
for
example,
the
tenancy
management
piece
right,
as
have
to
be
the
tenancy
management
component
that
we
run
inside
our
platform.
It
does
not
of
fidelity
specific
stuff.
It's
fully
automated.
B
It
goes
from
working
with
80
to
automation,
setting
up
tiller
and
a
lot
of
you
know
small
small
bits
so
as
of
today,
it
works
for
that
sorry,
as
of
today,
it
works
for
us,
but
what,
if
towards
somewhere
in
the
future
community,
actually
takes
a
different
approach
towards
multi-tenancy,
and
then
we
want
to
pivot
right.
So
that
is
where
the
calm
possible.
Nature
of
the
platform
is
extremely
important
for
us
because
that
helps
us
to
pivot,
at
any
point
view
one.
So,
let's,
okay,
let's
let's,
let's
talk
about
gate,
obviously,.
A
Thanks
I'm,
just
gonna
go
back
to
this
just
for
a
quick
second,
so
I
think
it
illustrates
to
recap.
So
we
stay
on
track
mode.
Know
where
we
are.
You
can
see
here
the
key
principles
they're
moving
to
the
cloud,
that's
the
bottom
layer,
but
they
want
to
choose
between
different
options.
You
can
see
three
options
on
the
second
layer
up
where
it
says
Cuba
Nettie's,
then
they
have
a
platform.
A
That's
all
the
light
blue
stuff,
including
some
of
their
own
things,
fidelity
bits,
and
then
they
have
the
individual
domain
specific
roles,
another
layer
on
top,
which
is
what
the
end
user
is
going
to
set
up
and
that's
the
applications.
So
we've
got
a
long
way
to
get
to
Nirvana.
Here
we're
going
to
manage
all
of
this
in
one
simple
way.
A
All
of
that
can
be
a
single
atomic
change,
one
transaction
in
your
config,
which
is
then
updated
by
kubernetes
itself
in
the
runtime,
which
means
that
you're
always
converging
to
the
correct
cluster.
Based
on
your
description,
which
gets
us
that
objective
oops,
pull
it
out
completely
and
then
put
it
back.
Yeah.
A
And
I'd
like
to
view
this
as
a
figure
of
eight
showing
you
in
the
middle
of
what
we
call
the
immutability
firewall,
which
is
to
get
repose
and
imagery
pose
the
human
beings
who
are
doing
dev
on
the
left
hand,
cycle,
build
tests,
etc.
Don't
touch
the
production
things
in
the
right
hand,
cycle
and
the
whole
thing
is
driven
by
observing
a
difference:
a
diff
between
the
desired
state
which
is
written
down
in
the
config
and
the
running
state.
A
If
you
can
do
that,
and
you
can
tell
Cuba
Nettie's
using
tools,
hey,
you
need
to
change,
you
need
to
update
yourself.
We
can
do
management
this
way.
We
can
do
upgrades
this
way.
We
can
do
dr.
We
can
do
rollback,
we
can
even
take
our
model
and
project
it
onto
different
clouds
and
different
tributaries
instances.
A
And
so
the
fundamental
thing
we're
doing
here,
it's
deployments.
Here's
a
little
flowchart
diagram
showing
you
we
flux,
now
see
ncf
flux,
interacting
with
helm,
to
do,
updates
and
flux
is
an
agent
that
lives
inside
your
running
kubernetes
and
pulls
changes
in
from
the
image
repos
and
the
configure
repos
when
it
is
noticed
when
it's
notified
of
a
change.
So
if
you
make
a
change
to
your
app
flux,
will
deploy
that
change.
For
you
by
telling
humanities
I've
seen
there
is
a
change
in
config.
I
must
now
get
the
things.
I
need
to
upgrade
myself.
A
Hey
kubernetes
now
get
into
the
correct
state,
so
you
don't
need
to
do
it
from
outside.
You
don't
use
manual
processes,
you
don't
use
scripts,
you
don't
use
Jenkins
to
do
deployment
or
any
other
CI
tool.
You
don't
use
spinnaker,
you
don't
use
harness.
You
don't
use
armor,
even
any
of
those
things,
because
all
of
those
wonderful
tools
as
they
are
sit
outside
the
cluster
and
they
can
do
other
things
they're
very
important,
but
inside
the
cluster
it
upgrades
itself
and
it
pulls
the
changes
in
instead
of
pushing
them
in
from
the
outside.
A
And
this
also
lets
us
manage
clusters,
not
just
apps
but
clusters
themselves,
so
we
can
do
reproducible
clusters.
In
this
case
we
integrated
flux
with
you
care
control,
which
is
an
open
source
tool
for
managing
ups.
Your
chaos
control
is
now
at
guitars.
Controller
for
cluster
management
of
eks
gives
you
single
commands
managing
fu
chaos
clusters,
and
it
makes
it
possible
for
you
to
manage
the
EAS
clusters
by
making
changes
in
config.
A
B
Let's
look
at
how
the
delivery
of
the
platform
is
managed
right.
So,
let's,
let's
start
with
the
versioning
of
the
platforms,
what
you're
actually
seeing
is
a
snapshot
of
the
platform
version,
so
we
have
a
platform
global
repo
right
and
every
tag
on
the
master
branch
represents
one
platform
version
for
us.
So
typically,
what
you
saw
was
like
one
of
the
release:
let's
say
it's
1
or
3.0.
B
Typically,
if
you
open
a
particular
platform
ocean,
what
you
actually
see
is
a
collection
of
add-ons
and
if
you
see
that
there
is
a
version
attached
to
each
add-ons,
so
the
add-ons
themself,
the
life
cycle
of
the
add-ons
is
managed
separately.
Let's
say:
I'm
a
developer
responsible
for
the
add-on.
I
have
my
own
pipe,
oh,
see
a
process,
testing
processes
and
everything.
What
is
part
of
this
particular
repo
is
just
a
definite
of
a
particular
version
of
the
add-on.
That's
it
I
want
to
take
an
example
here.
B
This
is
a
real
example
that
we
are
working
on
you're
going
to
work
in
the
upcoming
splints.
So
let's
say
you
want
to
add
a
new
capability
ape
ability
to
this
platform,
which
is
like
a
cost
driver
right.
So
we
want
to
give
the
ability
for
our
for
our
platform
admins
to
look
at
costs
from
you
know,
namespace
level
or
namespace
group
level
and
stuff
like
that,
and,
for
example,
anybody
in
cost
quota
within
the
system
and
stuff
like
that.
B
So
if
I
have
to
do
something
like
that,
I
developed
that
independently
and
once
that
is
ready,
I
submit
a
PR
into
this
repo,
which
is
basically
by
doing
a
addon
definition
and
once
that
is
plugged
into
this
repo.
The
next
version,
for
example,
1.3.1,
basically
pushes
that
cost
driver
into
production
across
the
clusters.
So
another
example
would
be
lets
say
there
is
a
security
badge
and
we
have
like
hundred
clusters,
for
example,
thousand
nodes.
If
you
want
to
change
the
default
mi
for
all
the
ec2
instance,
it's
a
PR
to
this
repo.
B
Obviously
it's
tested
out
seven
stuff
like
that,
but
asking
us
the
release
goes
out.
Let's
say
1
or
3.2
goes
out.
All
the
clusters
have
their
Easter
instances
refreshed.
So
we
talked
more
about
that.
So,
let's,
let's
move
forward
right,
we
talked
about
what
is
there.
We
talked
about
the
platform
definition
now,
let's
look
at
it
from
a
cluster
understand
point
so,
let's
say
I
have
a
cluster
right.
B
So
in
our
case
each
cluster
has
a
repo
and
within
that
report
there
are
this
two
files
and
at
any
point
in
time,
the
combination
on
these
two
files
within
that
git
repo
represents
the
share
of
the
cluster.
The
first
one
is
what
I
call
as
a
pointer.
Fine,
it's
a
very
straightforward
file
which
says
this
cluster
is
pointing
to
a
specific
platform
version.
It's
just
a
text
file
with
the
version.
Nothing
else.
The
second
one
is
the
config
options
file.
So
the
config
options
is
basically
what
the
platform
exposes
to
the
users.
B
Let's
take
this
forward
right,
let's
say:
I'm
across
Rodman
I
have
a
repo
and
have
this
particular
cluster
right.
Let's
say
I
want
to
upgrade
from
version
one
to
version
two,
let's
see
what
happens?
Let's
zoom
in
a
little
bit
right,
so
everything
starts
with
the
git
push
right.
There
is
a
good
push
and
then
I
update
the
pointer
to
say
that
we
have
to
move
from
version
one
to
version
2,
for
example,
1
or
3.0
200
unit
1,
for
example.
B
So
there
is
a
PR
and
that
gets
march,
and
there
is
a
comment
right
now
from
a
user
standpoint.
He
just
watches
the
commentary
and
as
soon
as
the
commit
turns
green,
then
the
platform
is
upgraded.
That's
the
experience
we
provide
the
use
bitbucket
and
the
bitbucket
status
plug-in
helps
this
a
lot
here
so
flow.
Something
like
this.
So
the
commit
happens,
and
then
this
Jenkins
my
plane
gets
triggered.
B
The
Jenkins
pipeline
actually
does
few
processes
to
prepare
something
called
a
cluster
state
and
then
it
sends
it
to
a
repository
manager.
We
have
some
strict
security
reasons
why
they
used
report
manager.
Any
deployment
that
goes
into
production
has
to
go
through
that
repository
manager.
If
it's
a
binary.
B
B
So
from
a
user
experience
standpoint
there
was
a
good
push,
there
was
a
PR
and
then
he
just
waits
for
the
commit
to
turn
green,
let's
zoom
in
further
so
eks
manager,
ETS
cutter
right,
eks
cuttle
is
our
main
execution
driver.
If
I
have
to
explain
it,
explain
the
relationship.
A
case
manager
is
high-level,
orchestrated
the
that
actually
orchestrate
a
few
things
and
then
eks
cuttle
is
the
main
execution
driver
on
some
levels.
You
can
say
similar
to
the
relationship
between
continuity
and
ransom
on
some
lemons.
B
So
we
have
this
cluster
state
cluster
state
is
there
in
artifactory
or
repo
manager,
and
then
eks
manager
actually
watches
for
that
right
and
in
a
nutshell
it.
Actually.
This
is
a
certified
version,
but
this
is
what
happens
in
a
nutshell.
So
first
thing
is
triggers
a
flow.
It
triggers
the
floor
to
basically
manage
the
cluster
dependencies
right.
B
For
example,
if
you
are
running
any
case
cluster
you
have
to
you,
have
a
double
specific
dependencies:
radial,
V,
pcs,
transit
gateways,
transit
gateway,
attachments
and
all
those
things
all
those
things
are
done,
and
then
it
kicks
off.
Eks
cattle,
ETF
cattle
basically
handles
two
states
right,
so
both
the
control
plane
state,
as
well
as
the
node
group
state,
is
handled
by
ETA
schedule
for
us.
So
what
I
mean
by
control?
B
Penn
state
is
let's
say
to
what
level
of
audit
you
need,
what
all
components
needs
logging
enable
and
stuff
limit
like
what
kubernetes
version
everything
and
when
it
comes
to
node
group
state
anything
that
you
can
think
of
with
respect
to
an
ISA,
Domitian
configuration
or
scaling
group,
anything
that
you
can
think
of
that's
handled
by
a
key
schedule.
So,
typically,
what
happens
is
in
terms
of
an
upgrade
even
an
AMA
refresh
we
sort
of
create
a
new
node
group
cordon
off
the
old
one
playing
the
parts
and
then
delete
the
old
one.
B
Ek,
scuttle
is
extremely
official
in
this
and
then
the
add
ons
comes
into
picture,
so
ETS
manager
deploys
the
add
ons
we'll
talk
about
hello
operator
in
detail,
so
in
generally
case
manager
waits
until
all
the
add-ons
are
successfully
run.
Even
if
one
of
the
add-ons
actually
crash
the
entire
process
is
about
it
and
then
the
cluster
this
is
it
complete
the
upgrade,
basically
so,
let's
zoom
in
one
more
time,
so
the
add-on
management
framework
right.
So
you
have
some
components
that
collectively
enable
this
management
framework
and
hello
operator.
Flux.
B
Hello
operator
is
the
core
component
in
that
it's
very
efficient
in
terms
of
managing
your
add-on
lifecycle.
So
the
way
we
do
that
is,
we
have
this
platform
Washington
PO
and
within
that
repo,
you
have
this
add-on
definitions
in
terms
of
helm
release.
So
there's
a
CID
anytime,
you
represent
an
add-on
in
terms
of
helm.
Release
hello
operator
will
actually
process
it
for
you,
so
it
has
details
of
where,
to
pick
up
the
hand
chart
from
the
values
and
everything
so
in
general,
using
fiddy
case
right.
B
So
this
basically
a
version
control
collection
of
add-ons
that
delivers
that
core
capabilities
that
I
was
talking
about.
I
know
we
zoomed
in
like
two
three
times,
but
if
you
take
a
step
back
and
look
at
it,
the
gate
push
that
the
user
did
to
go
from
platform
ocean,
one
to
version
two
that
basically
trigger
the
entire
flow
from
a
user
standpoint.
He
just
did
a
good
push,
so
that's
how
powerful
get
pushes
in
our
case,
I
think
I
have
just
enough
minutes.
B
B
And
from
a
user
standpoint,
let's
say:
I'm
a
developer
working
in
like
multiple
projects
right
at
any
point
in
time
all
I
have
is
my
identity,
which
is
the
ID
credentials.
How
can
I
discover
the
clusters
dynamically
using
the
ID
credentials,
so
I'll
tell
you
why
that
is
important.
So,
the
way
we
manage
tenancy
management
as
trace
using
custom
resources,
so
we
have
something
called
NS,
Group,
C
Rd,
so,
irrespective
of
the
environment,
you
are
in
whether
it
is
alw
as
module.
This
NS
group
helps
across
Redmond
to
manage
the
multi-tenancy.
B
So,
typically,
what
you
do
is
you
have
a
tenant.
The
tenant
could
be
like
a
tech
lead,
the
collection
of
developers
doesn't
matter
right
so
and
they
might
need
a
collection
of
namespaces.
So
we
sort
of
grouped
the
namespaces
under
this
namespace
group
and
then
attached
owner
to
it,
which
is
the
tenant
and
then,
as
soon
as
this
custom
resources
deployed
into
the
cluster,
a
namespace
operator,
which
we
have
it
actually
processes
the
entire
flow.
It's
fully
automated
it
creates
from
ad
groups,
and
it
takes
care
of
the
environment,
specific
abstractions,
for
example.
B
The
cluster
admin
should
not
worry
about,
for
example,
a
table
is
I,
am
or
sure
I
am.
Those
are
the
implementation
details?
Sorry.
So
all
those
things
are
actually
taken
care
by
this
operator.
So
from
trashed
admin
standpoints.
He
just
creates
an
NS
group
and
then
deploys
because
it's
a
CID.
It
opens
up
a
new
flow
right.
So
this
is
one
of
the
flows
we
have.
So
if
I'm,
a
class
Redmond
I
can
actually
say
that
the
developers
can
actually
create
a
PR
defining
what
they
need
in.
B
So
if,
let's
say
I'm
a
tech
lead
I
have
like
ten
namespaces
group,
let's
say
I
want
to
add
another
namespace
to
it
and
then
increase
my
resource
code
and
cost
Kota
I
just
make
the
changes
to
that
n
has
no
customer
resource
and
then
submit
a
pull
request,
so
the
class
fragment
comes
in
and
approves
it
as
soon
as
the
approval
happens,
the
NS
group
gets
submitted
into
the
cluster
and
then
the
processing
happens,
so
they
still
would
have
inversion.
So
you
have
to
deal
with
chiller
security.
I.
Tell
you!
B
Why
that's
why
that's
here
so
the
way
we
handled
that
as
the
tenancy
management
automatically
takes
care
of
setting
up
the
tiller
and
securely
bootstrapping
it.
It
creates
a
certificate
at
places.
There
are
places
that
certificates
in
a
cigarette,
but
the
moment
you
do
that
the
users
have
to
sort
of
you
know,
discover
the
secrets,
fetch
the
certificates
and
connect
using
helm
and
all
those
things.
But
obviously
we
don't
want
to
give
that
experience
to
the
user.
We
want
to
abstract
away
tiller
at
all
right,
so
that
is
where
EKF
can
it
comes
into
picture?
B
So
typically
the
client
user
experiences
this
didn't
they
don't
worry
about
coop
config.
They
don't
worry
about
till
you
write,
let's
say:
I'm
a
developer
I'm
connecting
to
or
connecting
to
a
class
I
want
to
deploy.
Something
were
clustered
so
you
have
something
called
we
have
something
called
ek
is
connect,
you
just
say
cluster
and
then
you
plug
in
your
ad
credentials.
B
What
it
does
is
automatically
it
tries
to
figure
out
hey
this.
Is
this
identity,
this
user?
What
Allah
says
he
has
access
to?
Then
it
gives
the
list
of
trust
rest
yes
access
to,
and
then
you
can
point
to
a
cluster
and
then
it
will
connect.
It
will
automatically
generate
coop
config
for
you
and
the
namespace
is
a
bit
more
interesting
so
moment
you
say
the
namespace
right,
so
it
automatically
connect
to
the
namespace
fetches,
the
tiller
certificates
and
then
sets
of
the
helm
wiring
locally.
B
So
tiller
is
like
totally
abstracted
out
so
I
think
that's
sort
of
completes
the
entire
cycle
before
I
handle.
Would
the
Alexis
I
just
want
to
say
that
my
our
team
is
here
whatever
you
saw
is
basically
part
of
efforts
of
a
brilliant
team,
I'm
very
happy
to
represent
the
team
here
if
you'd
like
to
join
us,
we
have
a
booth,
please
to
visit
us
in
nine.
Thank
you
so
much.
A
So,
just
to
finish
up,
she's
got
a
couple
of
minutes:
left,
Thank,
You.
Roger
summary.
We
had
this
problem
of
wanting
to
go
faster
across
multiple
cloud
season,
given
eTI's,
but
we
wanted
to
be
safe.
We
wanted
to
control
how
he
deployed
things.
We
wanted
to
choose
the
components
of
our
platform.
We
wanted
to
protect
them
from
being
changed
by
other
people
and
we
wanted
to
record
what
happened
in
this
case
he's
in
get
as
an
audit
trail.
Whoops.