Public Addresses and Their Dependents

The cluster’s public addresses appear in systems we do not run: mail relays that admit us by source address, DNS records, firewall rules. None of those systems tell us they depend on an address, so a renumbering breaks them silently. This page is the one list of them.

It has two parts:

  • Address inventory: what each address is and which traffic uses it.

  • Dependency register: every outside system that names one of the addresses.

Before any address changes (in particular when the cluster grows beyond the allocated range), filter the register by the addresses affected. That list is the impact analysis.

Address inventory

The allocation is 197.189.214.88/29 (.88 to .95).

Address Role Traffic

197.189.214.90

Node idl-xnl-jhb1-k01

Outbound from pods scheduled on this node (to confirm, see below). Bastion SSH on NodePort 30022.

197.189.214.91

Node idl-xnl-jhb1-k02

As k01

197.189.214.92

Node idl-xnl-jhb1-k03

As k01

197.189.214.93

Ingress virtual IP (kube-vip, see Ingress and Client Addresses)

Inbound HTTP and HTTPS for every public hostname

.88, .89, .94, .95

Network, gateway, unused or broadcast (to confirm with Xneelo)

None known

Which address outbound traffic uses

A pod’s outbound connection leaves from the public address of the node it runs on, so a third party sees any of .90 to .92, and the address changes when a pod is rescheduled. Allowlists therefore name the range (or all three node addresses), never a single node. To confirm, run a probe from a pod on each node against an echo service.

If outbound traffic left from one fixed address (an egress gateway, or SNAT to a dedicated address), every allowlist would name one /32. Growing the cluster would then add nodes without touching any outside system. Worth deciding before the expansion.

Dependency register

One row per outside system that names a cluster address. Direction is outbound when a third party admits our traffic by source address (it breaks when our egress address changes), and inbound when something points at us (it breaks when the ingress address changes).

ID Dependent Direction Address named Configured in (owner) Fails how, and how to change

AD-01

Google Workspace SMTP relay for @wpcycling.com senders (WP Cycling WordPress, wp-wpcycling)

Outbound

197.189.214.88/29

Google Workspace admin, Apps ▸ Gmail ▸ Routing ▸ SMTP relay service (WP Cycling’s Workspace)

Relay refuses unauthenticated mail; FluentSMTP logs a relay denial. Edit the rule’s allowed addresses.

AD-02

Microsoft 365 (Entra ID / Exchange Online) inbound connector relaying for @myriadevents.co.za (EMS services, wp-tourdeworcester)

Outbound

To confirm

Exchange admin centre ▸ Mail flow ▸ Connectors (Myriad Events tenant)

Relay denial, not an authentication error. Edit the connector’s sender IP addresses.

AD-03

Microsoft 365 connector relaying for Idealogic

Outbound

To confirm

Exchange admin centre ▸ Connectors (Idealogic tenant)

As AD-02

AD-04

DNS records at Cloudflare pointing at the ingress, in zones managed by external-dns (for example myriadevents.co.za, idealogic.co.za)

Inbound

197.189.214.93

external-dns, from Ingress hosts

Follows automatically if external-dns publishes the new address; check its source setting.

AD-05

DNS records created by hand in manually managed zones: tourdeworcester.co.za (apex, www, newweb; register is an alias, see AD-06), wpcycling.com (newweb, and the apex and www after cutover; registration is an alias, see AD-06)

Inbound

197.189.214.93

Cloudflare dashboard, per zone

Hosts stop resolving to the cluster. Edit each A record.

AD-06

Address-bearing alias records. Hostnames that are CNAMEs carry no address themselves; the record they point at does.

* idl-xnl-jhb1-vip1.idealogic.co.za, target of registration.wpcycling.com * idl-xnl-jhb-rc01.myriadevents.co.za, target of register.tourdeworcester.co.za

Inbound

197.189.214.93

idealogic.co.za zone (who manages it is to confirm, outside this repository); myriadevents.co.za zone at Cloudflare

Every alias pointing at the record stops reaching the cluster. Change the target record’s A record and leave the aliases as they are. Before renumbering, list the aliases with dig +short CNAME <host> for each host in ingress.hosts.

Not dependencies (checked)

  • SPF for wpcycling.com: mail relayed through Google leaves from Google’s servers, covered by include:_spf.google.com. The cluster range belongs in SPF only if the cluster ever delivers mail directly.

  • Cloudflare-proxied hostnames: Cloudflare connects to the ingress address as origin, which is the DNS record in AD-04 or AD-05, not a separate setting.

Keeping the register true

  • Add a row whenever a new outside system is given a cluster address: a relay rule, a partner’s API allowlist, a firewall rule, a hand-made DNS record.

  • In the manifest or configuration that relies on the dependency, add a comment naming the row, for example # address-dependency: AD-01. Then grep -rn "address-dependency" argocd/ finds every consumer from the repository side.

  • Resolve the To confirm cells when the system is next touched.