charlie has a new role platform
administrator and he is tasked with
ensuring
all the infrastructure created by all of
his company's teams
are in compliance with governance
requirements
let's see how configsync makes his life
easier
charlie's team are using kubernetes for
development
one of the many benefits of kubernetes
is its declarative workflow
you can specify how many instances of an
application you want running and be sure
that kubernetes will ensure that state
for you
but sometimes the state of running
clusters itself can become out of sync
with what's on paper
when unvetted changes are applied to a
live cluster it can be difficult to know
what's actually going on
in your cluster when this happens
getting your cluster
back into a last known good state when
something goes wrong
becomes problematic that's why
charlie proposes using config sync for a
git
ops workflow config sync allows cluster
operators to manage kubernetes clusters
using files called configs
stored in git repositories config sync
watches for updates to those files
and applies changes to all relevant
clusters automatically
by locking down direct access to
kubernetes api
he can require that all cluster
configuration changes
are propagated using config sync this
way
all changes are reviewed before they are
submitted
declarative tooling like config sync
means that git will become the source of
truth
and accurately reflect what's happening
in your live cluster
for a platform administrator like
charlie this is a win
and as the entire system becomes easier
to manage debug and monitor
let's see an example of how config sync
can be used to keep a repository in sync
in this example we created a cluster
made
ourselves a clustered min and installed
the nomos command
and the convict sync operator onto the
cluster we operate on
the first step is to configure the git
repo storing the configs our cluster
will be synced from
we'll create a configuration file called
config management.yaml that will be
applied to all of our clusters this file
tells kubernetes which clusters to
operate on and it provides key
information about the git repository
including which branch and folder to
sync from
we can set up credentials for accessing
private repos here as needed
once that's applied you can see that
config sync operator
actually creates pods in the config
management namespace
these are services that run to make sure
the cluster's desired state
matches up with its actual state for
example
this repo contains instructions for
creating namespace for testing
and development among other things but
what if we were to delete one of these
namespaces manually
this would be an example of an actual
and desired state
being out of sync luckily config sync
catches that within a few seconds and
spins up a new version
of the deleted namespace keeping
everything running as it should
with config sync you can pair a git ops
approach with
git for storage and versioning and your
changes will be
automatically synced to the cluster to
ensure a consistent review process
with this approach all configuration
changes follow the consistent review
process that are validated and approved
before
being applied just like code would be
this makes it much easier for charlie to
ensure all teams follow this process
consistently so it can scale across the
company
so that's config sync make sure to check
out the description for links to more
resources on it
and like and subscribe to this channel
for more videos about google cloud
you