External-services
The
external-services
Helm chart creates Kubernetes
Service
and
Endpoints
objects that represent systems running outside of Kubernetes (bare-metal hosts, legacy infrastructure, etc.). This allows in-cluster workloads to reference external systems by a stable DNS name and enables
Calico
NetworkPolicy
egress rules to target those systems by service name rather than hardcoded IPs.
When an external IP changes, only the
external-services
chart needs updating.
Services are created as headless (
clusterIP: None
) with manually managed
Endpoints
(no pod selector), in the
external-services
namespace.
How services are defined
The actual service definitions (IPs and ports) are
not stored in deployment-charts
. They are dynamically generated by
Puppet
on the
deployment servers
via
profile::kubernetes::deployment_server::global_config
and written to
/etc/helmfile-defaults/general-<cluster>.yaml
, which helmfile picks up as global values at deploy time.
External services examples
- kafka
- zookeeper
- redis
Usage
Individual service charts declare which external services they need via the
external_services
key in their values, for example:
external_services:
redis-6380: [misc]
This causes the
base.networkpolicy.egress.external-services
template (from the
modules/base
module) to generate a Calico
NetworkPolicy
allowing egress from that service to the
redis-6380-misc
Service in the
external-services
namespace.
Deploying changes
After the Puppet-generated values have been updated, deploy the changes from the deployment server. First, review the diff to confirm what will change and then sync:
cd /srv/deployment-charts/helmfile.d/admin_ng
helmfile -e eqiad -lname=external-services diff
helmfile -e eqiad -lname=external-services sync
The final
diff
should return no changes. Replace
eqiad
with
codfw
(or the appropriate cluster) when deploying to other datacentres.
Check Kubernetes/Clusters for the rest of the clusters you need to sync