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.

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

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.

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-eeqiad-lname=external-servicesdiff
helmfile-eeqiad-lname=external-servicessync

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

• Kubernetes