►
From YouTube: Kelsey, Kubernetes, and GitOps - GitHub Universe 2020
Description
Presented by Kelsey Hightower, Principal Engineer, Google
This session will dive into Kelsey's journey into Kubernetes as a contributor and a member of the cloud native community. This session will also take a look at the current state of managing Kubernetes based infrastructure through collaboration and how GitOps fits into the big picture.
For more from GitHub Universe 2020, visit https://githubuniverse.com
As always, feel free to leave us a comment below and don't forget to subscribe: http://bit.ly/subgithub
Thanks!
Connect with us.
Facebook: http://fb.com/github
Twitter: http://twitter.com/github
LinkedIn: http://linkedin.com/company/github
About GitHub
GitHub is the best place to share code with friends, co-workers, classmates, and complete strangers. Millions of people use GitHub to build amazing things together. For more info, go to http://github.com
A
A
A
But
if
you
really
want
to
understand
kelsey,
you
kind
of
have
to
understand
the
whole
person
we
like
to
label
ourselves
technologists
and
just
like
many
others.
I've
used
many
labels
over
my
career,
but
the
first
label.
I've
ever
had
like
many
people.
I've
worked
in
fast
food,
specifically
mcdonald's,
where
you
get
the
purple
hat
and
the
shirt
to
match.
You
come
home,
smelling
like
french
fries
and
whatever
they
fight
it
in
and
a
lot
of
my
work
ethic.
A
A
lot
of
my
maturity,
this
this
nature
of
being
a
professional
started
for
me
around
the
age
of
15.
and
there's
a
long
trajectory
between
those
humble
beginnings
to
the
person.
You
speak
in
front
of
you
today
or
commit
to
your
open
source
or
your
favorite
open
source
project,
and
a
lot
of
us
try
to
figure
out.
A
What's
the
success
behind
it
and
I
don't
have
a
lot
of
answers,
but
I
know
I've
been
on
this
marathon
for
a
little
while
now
and
there's
a
big
checkpoint
in
my
career.
I
remember
getting
my
first
like
real
corporate
job.
You
know
the
one
where
they
make
you
wear
slacks
monday,
tuesday,
wednesday
thursday
and
then
on
friday.
Everything
turned
out.
A
Okay,
you'll
get
to
wear
jeans
and
it
was
a
financial
services
job,
and
I
remember
I
was
a
system
administrator,
just
learning
things
like
python
and
all
this
automation
stuff,
and
it's
really
what
I
lean
into
ops,
big
time.
This
is
when
outage's
production
really
mattered
a
ton-
and
I
remember
one
of
our
outages-
we're
sitting
in
one
of
those
war
rooms
and
for
y'all
watching
this
that
have
never
been
in
a
war
room.
A
Maybe
this
person
has
their
kids
with
them
and
they're
in
this
checkout
line
and
they're
about
to
go
next.
Now
it's
their
turn
and
all
they
have
is
this
ebt
card
and
they
go
to
swipe
it
to
pay
for
their
groceries
that
have
already
been
rung
up
neatly.
Placing
the
bags
and
the
ebt
card
doesn't
work,
and
here
we
are
sitting
around
this
room,
believing
that
we
have
all
the
time
in
the
world
to
resolve
the
issue.
A
A
A
We
always
think
we
have
all
the
time
in
the
world,
and
I
remember
a
lot
of
people
telling
me
you
know.
Success
is
measured
in
time.
I
remember
getting
award
like
top
40
under
40.,
and
I
always
thought
to
myself.
It's
like.
Why
is
there
a
time
limit
on
this
kind
of
thing
right?
Why
is
there
not
more
opportunities
for
success
to
have
nothing
to
do
with
your
time?
The
truth
is
there
is
no
time
limit,
so
I'm
going
to
do
right
now.
A
Is
I'm
going
to
share
my
screen,
and
this
is
a
very
interesting
number
if
you're
using
github,
you
may
be
fascinated
with
the
number
of
github
stars.
Apparently,
if
you
get
over
like
100
github
stars,
you
can
probably
raise
an
a
round
in
silicon
valley,
so
those
numbers
do
have
meaning,
but
this
number
on
the
screen
one
hour,
59
minutes
and
40
seconds.
A
A
He
did
it
and
we
tend
to
put
the
person
who
crosses
the
finish
line
first
in
the
foreground.
Look
at
this
picture
notice
behind
him.
All
the
other
runners
are
cheering.
That
seems
a
bit
odd.
It's
supposed
to
be
a
marathon.
That's
like
a
race
winner.
Take
all
there's
only
one
first
place
finish,
but
the
people
behind
him.
If
you
watch
this,
if
you
watch
what
happened,
the
people
behind
them
are
also
world-class
marathon
runners.
A
A
All
of
them
are
taking
turns.
So
maybe
you
run
a
few
miles
and
maybe
the
top
two
guys
switch
out
the
other
two
join
in
now,
any
of
them
any
of
the
30
who've
been
training
for
months
to
help
them
break
this
world
record
of
a
person
running
a
marathon
in
less
than
two
hours,
something
we
didn't
think
was
humanly
possible.
A
A
A
When
you
think
about
git,
it's
one
of
the
world's
best
collaboration
tools
for
writing.
Software
and
github
is
where
we
all
meet
and
collaborate,
but
it's
the
people
that
make
all
of
this
work
and
when
people
think
about
kubernetes,
they
want
to
hyper
index
and
hyper
over
my
optimize
on
containers
versus
this
other
thing,
and
you
could
do
that.
You
can
click
on
all
the
hacker
news
links
and
have
about
10
000
tabs
in
your
web
browser.
But
if
you
focus
on
the
technology,
I
don't
think
you'll
ever
get
it.
A
What
we've
been
doing
with
all
of
these
platforms
is
serializing.
The
way
we
work,
there's
been
a
lot
of
ideas
over
the
last
20
years,
and
a
lot
of
them
have
been
serializing
kubernetes,
that's
the
gist
of
it.
I
know
people
want
it
to
be
more
complicated
than
that.
There
should
be
a
series
of
best
practices
hell.
I
even
wrote
a
book
about
it,
but
the
truth
is
there's
just
practice
and
as
we
learn
we'll
contribute
to
those
things.
A
If
you
have
a
clear
goal,
if
you
know
what
you're
trying
to
do,
maybe
you
know
where
the
finish
line
is.
You
can
actually
bring
in
all
of
these
people
and
all
of
these
tools
and
they
should
be
aiding
you
to
go
faster
than
you
can
by
yourself
now
elliot
kipchoge.
He
is
a
world-class
marathon.
Runner
he's
never
ran
the
marathon
in
less
than
two
hours
he's
gotten
close,
but
he's
never
been
able
to
do
it
on
his
own
and
sometimes
because
he's
the
only
one
in
front
and
there's
no
one
there
to
push
him.
A
But
with
this
setup
it
changed
the
game
and
if
you
do
it
right
and
you
keep
these
kind
of
north
stars
clear,
then
I
think
it
makes
it
much
easier
to
understand
how
all
the
technology
comes
together
and
the
people
around
it.
You
can
wrap
that
around
you
and
then
use
it
to
push
you
forward.
That's
the
way
you
got
to
think
about
this.
A
If
you
want
to
understand,
get
ops,
you
got
to
understand
the.
Why?
Why
are
you
using
it
what's
important
about
it?
What's
the
peloton
formation
you're
trying
to
build
around
you
and
is
it
designed
to
help
you
go
faster?
Are
you
just
doing
stuff
because
people
said
it
on
twitter
so
now
we're
going
to
jump
into
kind
of
this
live
demo
about
how
all
of
this
works.
A
A
Most
people
write
software
to
put
it
in
the
hands
of
their
customers,
so
in
this
case
we're
going
to
have
a
very
simple
app,
because
what
I
want
you
to
do
is
focus
on
the
actual
workflow.
That's
what
this
whole
get
off
things
about.
What
type
of
application
can
you
deploy?
I
don't
know
what
kind
of
applications
can
you
write?
A
So
you
see
I'm
rocking
that
new
dark
thing.
Maybe
this
is
going
to
be
the
new
trend
and
I
just
have
a
simple
app:
it's
called
hello
universe
and
as
a
developer,
if
you
put
your
developer
hat
on,
you
have
some
very
specific
goals.
Your
goal
is
to
write
code
that
hopefully
works
and
then
deploy
it
to
the
proper
environments
and
then
you
should
be
able
to
hit
an
endpoint
and
get
some
results.
That's
the
goal,
I'm
going
to
show
you
what
that
goal
looks
like
when
in
practice.
A
A
Why
is
it
going
to
change
the
way
you
think
about
things
and
work?
The
honest
truth:
it
shouldn't,
if
you
think
about
the
way
you
write
code
today,
if
you're
a
developer,
there's
a
big
chance
if
you're
walking
watching
this
talk
that
you're
already
using
git
think
about
it.
When
you
write
code,
you
tend
to
make
a
few
commits,
and
then
you
push
it
up.
A
You
can
run
that
binary
locally.
If
you
really
wanted
to
I
can
I
can
do
something
like
hello
universe.
I
have
this
binary,
that's
on
my
machine.
I
can
run
it
locally
and
if
I
were
to
go
to
another
tab
and
call
curl
on
localhost,
the
thing
you
expect
to
happen
should
happen.
I
could
hit
this
on
port
8080
and
there
we
go
that's
pretty
straightforward
and
then
you
push
your
code
to
some
repository,
but
here's
the
thing.
A
If
you
really
want
to
know
how
this
works,
I
think
one
of
the
best
examples
that
I've
seen
online
is
probably
to
the
people
who
coined
the
term
weave
works.
They
call
get
ops
and
the
whole
goal
behind
git
ops.
Is
that
imagine
if
you
were
to
able
to
use
the
same
development
workflow
for
managing
infrastructure,
but
here's
a
twist
we've
been
doing
this
for
a
super
long
time.
A
lot
of
people
will
look
back
to
like
puppet
and
chef
and
ansible,
and
we
wrote
a
lot
of
code
back
thing
and
yeah.
A
A
lot
of
us
checked
into
version
control.
So
what's
new
about
this,
this
looks
like
the
same
thing
we've
been
doing
and
someone
just
came
up
with
a
better
name
for
it.
That's
probably
true,
and
they
raised
a
lot
of
cash
behind
it,
but
the
ideas
are
solid.
Why
are
they
solid?
Well,
there's
a
twist
here
given
kubernetes
and
the
way
it
works.
We
now
can
start
to
treat
infrastructure
as
data
and
a
lot
of
people
say
nope.
I
thought
it
was
infrastructure.
A
As
code
yeah,
you
can
write
a
lot
of
code,
but
code
has
some
other
issues
to
it.
One.
You
need
something
that
understands
that
programming
language
in
order
to
write
that
code,
parse,
that
code
validate
that
code
and
those
tools
exist,
don't
get
me
wrong,
but
the
idea
that
if
we
can
write
code
or
config
as
data,
maybe
we
can
simplify
this.
A
I
know
what
you're
thinking,
oh
more
yaml,
look
yaml
ain't
that
bad
stop
complaining,
it's
readable,
you
can
modify
it
and
we
can
run
things
like
static
analysis
without
having
a
compiler
or
something
that
can
parse
that
language
an
overview.
This
is
what
it
looks
like.
I
know
people
get
this
super
complicated.
I
know
a
lot
of
people
will
talk
about
cicd
and
pipelines
and
deploying
two
trillion
times
a
day,
even
though
they
don't
have
a
reason
to
deploy
2
trillion
times
a
day.
It's
something
we
brag
about
at
conferences.
Don't
worry,
it
isn't
real.
A
The
truth
is
it's
all
about
the
workflow,
how
you
encapsulate
that
workflow?
Well,
that's
going
to
be
up
to
you.
Look
at
this
diagram
as
a
developer.
On
the
left
side,
you
write
code,
it
goes
into
a
version
control
system
and
then
ideally
you're
going
to
produce
an
artifact.
So
here's
where
this
kubernetes
connection
comes
into
play
kubernetes
requires
a
container
as
the
price
of
admission.
A
Oh,
I
know
what
you're
saying.
Oh
my
god,
I
got
to
build
a
container.
This
is
the
hardest
thing
in
the
world.
Oh,
it's
going
to
take
me
7,
000
years
to
learn
how
to
build
a
container,
and
I
asked
people
like
wow.
Have
you
even
tried,
like
seriously?
Have
you
tried
to
build
a
container
before
you
start
freaking
out?
A
Think
about
what's
required
right
if
you
know
how
to
build
your
app
locally
right
like
these
are
the
same
kind
of
commands,
I
would
put
in
the
build
script
then,
in
my
case
I
keep
things
super
simple.
I
build
my
app
the
same
way.
I
normally
do
and
then
based
on
the
results
here,
this
hello
universe,
binary.
A
I
simply
copy
it
from
my
build
step
and
then
package.
It
we're
really
talking
about
glorified
tar
balls,
but
they're
really
powerful,
but
they
are
very
similar
to
using
things
like
a
ruby,
gems
or
a
war
file.
If
you
come
from
the
java
world,
you
got
to
package
software
in
something.
Why
not
pick
something?
That's
super
universal!
A
That's
the
selling
point!
If
you
don't
like
docker
files,
there
are
other
tools
that
can
build
container
images
get
over
it
once
you
do,
then,
the
world
kind
of
opens
up
to
this
other
thing
that
we're
talking
about
in
order
for
this
get
off
things
to
work,
the
way
we're
talking
about
it
with
declarative
infrastructure.
We
don't
want
to
be
dealing
with
the
differences
between
node.js
python
and
go.
We
want
to
have
a
normal,
consistent
object
or
artifact
to
deal
with.
A
Let's
go
back
to
the
diagram,
really
quickly
notice,
this
container
registry
component,
that's
the
key
to
normalizing
your
workflow
across
all
your
applications.
So
what's
the
contract
between
you
and
the
developer?
Well,
as
the
developer,
your
job
is
to
write
code
that
works.
Ideally,
it's
secure
as
well,
and
then,
if
you
do
that,
we
can
automate
the
process
of
building
those
docker
files.
So
it's
on
you
to
put
a
description
of
how
to
build
your
app
right
and
then,
when
it's
done,
you
can
actually
create
that
entry
point,
so
we
know
how
to
run
it.
A
So
how
do
we
automate
this?
Well?
Github
has
a
really
nice
feature,
so
in
github
you
can
actually
do
something
pretty
neat.
You
can
set
up
some
actions.
Basically,
so
when
I
push
this
repository
or
tag,
a
branch
in
this
repository
it'll
kick
off
a
set
of
actions
and
they
have
all
of
these
nice
little
brew
plants
that
say
hey
whenever
code
is
checked
in
here
push
to
some
repository.
A
Before
my
talk
I
was
bum.
I
was
producing
a
few
versions.
I
have
a
v1
tag
and
a
v2
tag
and
with
these
releases
just
by
doing
the
normal
git
operations
that
I
tend
to
do
when
I'm
writing
code
well,
I
can
rely
on
github
actions
to
take
over
that
commit
and
then
it
will
go
through
and
actually
build.
My
image
for
me
and
push
it
to
a
repository.
A
Does
all
this.
In
the
background
every
time
I
commit
or
or
tag
something,
and
then
once
that's
ready,
the
important
part
here
is
you
want
to
push
it
to
a
central
repository.
If
you
haven't
been
paying
attention,
github
also
has
a
new
container
repository,
so
you
can
manage
packages
for
all
your
repositories.
Look
here.
A
Now
that
we
have
repository,
let's
pop
back
over
to
that
diagram
again,
I
don't
think
this
has
to
be
as
complex
as
a
lot
of
people
make.
It
at
least
not
the
fundamentals.
So
now
we
have
this
part
of
the
loop
established
checking
in
our
code
and
making
container
images
got
it.
So
at
this
point,
we're
now
ready
to
start
releasing
our
application
to
something
like
kubernetes.
A
Now,
how
do
you
go
about
that?
Well,
you
can
do
simple
ops
and
what
ops
looks
like
is
in
this
world
of
the
declarative
world
is
ops,
is
about
writing
yaml
files
yay
one
time
for
the
yaml
files,
you'll
learn
to
love
yam.
While
I
promise
you
and
if
you
have
like
vs
code
and
any
of
those
robust
editors,
it
will
help
you
write
a
lot
more
yaml.
So
don't
worry,
yamo
is
your
friend.
What
does
that?
Yaml
stuff?
Look
like
I'm
just
going
to
show
you
one!
Here's
a
deployment
file!
Really
the
goal
here.
A
Is
you
to
articulate
what
you
want
the
system
to
do?
I
want
to
deploy
this
version
of
my
application.
I
want
this
much
memory
and
cpu.
You
get
the
idea,
but
ideally
you
can
have
tools
that
help.
You
generate
these
configs
they're
very
explicit,
but
the
whole
point
here
is
that
they're
declared
we're.
Not
writing
any
scripts,
we're
not
using
any
custom
languages
or
any
custom
tools.
We're
just
crafting
some
data.
The
nice
thing
about
this
data
is
that
we
can
push
it
to
any
kubernetes
cluster
that
we
want.
A
The
goal
is
between
the
deployment
object
and
the
service
that
allows
me
to
attach
this
to
a
load
balancer
and
a
horizontal
scaling
config.
I
have
the
three
components
that
I
need
for
dealing
with
my
infrastructure.
So
how
does
that
work?
Well,
there's
a
bunch
of
things
you
can
do
here.
Let's
go
back
to
the
diagram
in
this
diagram
notice.
One
thing
that
I
like
this
idea
of
splitting
out
the
config
repo
from
the
source
code,
repo
and
a
lot
of
people
like.
Oh
no,
you
want
to
keep
everything
together.
A
So,
if
I
were
you,
I
would
consider
following
this
pattern.
This
blueprint
keep
your
config
repo
separate.
So
what
does
that
look
like
in
the
github
world?
Well,
you
probably
know
what
this
looks
like
if
I
click
over
here
to
my
github
tab.
I
just
have
another
repository
where
I'm
storing
all
of
my
configs-
and
here
I
can
have
my
same
git
flow.
I
can
do
pull
requests.
I
can
review
them
and
all
of
my
configs
are
just
sitting
here.
A
Underneath
this
directory
called
kubernetes,
I
can
have
other
deployment
targets,
maybe
you're
using
a
serverless
platform
like
cloudrun.
In
that
case,
you
may
have
another
directory
of
declarative
configs
that
you
put
there,
but
the
goal
is:
these
are
just
all
data
artifacts
that
can
be
consumed
by
some
other
system
that
can
actually
take
your
declarative
thing
and
make
it
work.
A
If
you
have
lots
of
clusters,
one
model
may
work
better
than
the
other.
One
thing
I
like
to
do
is
give
myself
the
flexibility
to
have
different
kubernetes
clusters
have
different
versions
of
the
config,
even
at
the
same
time,
let's
see
what
that
looks
like
in
practice
really
quickly.
So
I
have
a
couple
of
live
clusters
running
in
my
infrastructure.
A
I
basically
have
something
in
us:
west,
one
u.s,
east
four
and
I
have
another
one
in
u.s
west,
one
in
the
b
zone.
Now
what
I'm
going
to
do
is
I'm
going
to
treat
this
second
cluster
in
u.s
west
as
my
canary
cluster.
Now
this
is
where
things
get
a
little
interesting,
I'm
going
to
go
with
the
pull
model,
I'm
using
a
tool
called
config
sync
and
there's
other
great
tools
out
there,
some
made
by
weaveworks
and
many
others.
The
choice
is
up
to
you.
A
They
all
have
different
feature
sets
pick
something
that
works,
but
the
fundamentals
are
roughly
the
same.
We
want
these
clusters
to
link
to
our
configuration
repository.
This
is
the
core
premise
to
what
we're
doing.
We
want
these
artifacts
to
work.
So
here's
the
other
thing
we
want
to
do.
I
want
to
leverage
multiple
branches.
That
way.
Maybe
I
want
1.0
deployed
to
all
of
the
clusters
and
when
2.0
is
ready.
Maybe
I
tell
just
one
cluster
that
it
should
be
running
the
2.0
version
of
my
configs
and
we'll
see
what
that
looks
like
all
right.
A
A
So
if
I
run
the
status
command,
it's
going
to
connect
to
my
clusters
and
tell
me
the
current
status
of
the
repositories
that
it's
been
syncing
to,
while
that's
running
what
I'm
going
to
do
now
is
run
that
curl
command
again
and
you'll
notice
that
we're
hitting
our
universal
url
and
that
universal
url
is
pointed
at
all
of
my
kubernetes
clusters.
I
have
a
load
balancer
sitting
here
and
that
load
balancer
is
pointing
to
three
different
clusters.
Hello
universe
is
pointing
to
all
of
those
zones
here
we
go
down
here
so
with
that.
A
A
If
we
look
at
our
syncing,
we'll
see
that
all
three
clusters-
u.s
west
one,
a
and
east,
all
of
them-
are
syncing
to
the
1.0
branch
of
my
hello
world,
universe,
config
and
they're,
all
in
sync
and
I'm
getting
the
right
version,
everything's
working
nicely.
So
now
I
want
to
make
that
change.
Well,
of
course
you
update
your
code
and
you
go
back
to
the
flow
that
you're
used
to
checking
your
code
and
then
what
will
happen
is
a
bill
process
will
kick
off
drop.
Something
in
your
package.
A
Repository
give
you
a
new
tag,
that's
eligible
for
deployment,
and
then
all
you
have
to
do
is
make
a
change
in
the
config
repository
now.
There's
ways
to
automate
this,
but
I
just
want
to
show
you
how
it
works
underneath
the
covers.
Your
goal
is
on
that
separate
branch
where
those
configs
live.
Well,
those
configs
I'm
going
to
show
you
the
differently
quickly.
A
A
A
I
did
a
little
bit
of
work
ahead
of
time
at
this
config
management
directory
and
if
you
look
at
them,
they're
currently
all
the
same,
but
let's
look
at
the
one
that
I've
deemed
our
canary
cluster.
So
what
I've
done
is.
I
have
a
separate
load:
balancer,
that's
sending
traffic
only
to
one
of
these
clusters
and
it's
called
hello
universe
canary.
A
Uswest
b
now
is
we'll
hit
that
endpoint
and
I'm
going
to
show
you
the
last
step
that
you
have
to
do
as
I
wrap
up
this
demo.
So
we'll
do
curl
and
this
time
we'll
throw
canary
into
the
front
of
this
so
we'll
say,
canary
dot,
hello
universe
and
we'll
get
the
version
as
expected.
We're
getting
1.0
now
I
have
those
stages
changed.
I
have
the
containers
built.
We
only
need
to
do
one
more
thing
here:
we'll
update
the
config
management
config.
A
Just
for
that
one
cluster,
so
we'll
say
usbs
west1b
and
we'll
come
over
here
and
say:
look
I
want
to
sync
instead
of
the
branch
2.1.0,
we'll
change
it
to
2.0
and
then
what
we'll
do
here
is
we'll
tell
that
cluster
that
it
should
re-prioritize
where
it's
pulling
config
and
the
way
we
do
that
is,
we
run
a
command.
So
I'm
going
to
be
talking
to
specifically
that
cluster
in
us
west1
and
I'm
going
to
tell
it
to
grab
that
new
config
we're
reaching
that
last
mile.
A
Once
this
config
is
in
place
that
kubernetes
cluster
will
go
to
that
new
branch
of
that
config
repo
and
then
try
to
update
the
state
of
the
world
based
on
those
configs.
The
nice
thing
about
this
workflow
is
that
developers
can
keep
checking
in
code
and
tagging
releases
and
then
those
will
flow
into
the
container
registry.
A
Only
when
the
config
repo
is
updated
specifically
for
a
specific
environment
will
it
go
and
pull
the
right
container
at
the
right
time.
So
for
most
people
once
you
get
this
stuff
set
up,
you
end
up
working
like
you
were
normally
working
now
you
kind
of
have
this
get
out
workflow
on
both
sides.
You
can
start
the
diff
review.
Changes,
merge
them
in
so
with
that
in
place.
A
If
I
go
over
here
and
look
at
the
cluster
output,
we'll
look
at
our
workloads
and
we
should
see
kubernetes
hard
at
work,
trying
to
replace
some
of
those
old
versions
of
my
app
one
by
one
or
how
I
direct
it.
Based
on
my
controller,
that's
doing
the
work
inside
of
the
cluster
remember
everything's,
declarative!
On
my
side
I
got
a
few
more
pods
to
go
we'll
hit
refresh
here
to
see
if
everything
is
up
to
date,.
A
And
we
have
one
more
that
we're
shutting
down,
but
so
far
it
looks
like
everything
is
green
and
we're
ready
to
test.
So,
let's
see
if
this
works
we'll
go
back
to
our
command
line
and
we'll
hit
that
canary
endpoint
again-
and
we
see
it's
on
2.0
and
just
to
be
sure
that
everything
is
working,
we'll
hit
the
global
load
balancer
and
ideally
we're
going
to
bounce
around
to
various
endpoints.
A
So
with
that,
I'm
going
to
stop
the
presentation,
and
hopefully
you
have
a
better
understanding
of
how
git
ops
works.
There's
a
lot
more!
You
can
do
here.
We
just
scratched
the
surface.
A
lot
of
people
are
looking
at
this
as
a
very
complex
thing,
but
remember
you
already
know.
Most
of
the
workloads
you've
probably
already
been
working.