After PR #157 removed ingress-nginx from the cluster, three Ingress resources remain orphaned. They reference an IngressClass (`nginx`) that no longer exists and DNS doesn't route to them anyway — but they should be cleaned up at source so `kubectl get ingress -A` is honest.
Orphaned Ingresses
| Namespace |
Name |
Hostname |
Owner |
| `code-for-philly` |
`latest` |
latest.codeforphilly.sandbox.k8s.phl.io |
laddr preview-deploy CI (emergence-site chart) |
| `laddr` |
`latest` |
latest.laddr.sandbox.k8s.phl.io |
laddr preview-deploy CI (emergence-site chart) |
| `codeforphilly-rewrite-sandbox` |
`codeforphilly` |
codeforphilly-rewrite.codeforphilly.sandbox.k8s.phl.io |
codeforphilly-rewrite project's own CI |
All three are functionally inert:
- Their referenced IngressClass `nginx` no longer exists
- The LoadBalancer IP they advertise (45.79.246.168) is gone
- DNS for these hostnames resolves to the Envoy Gateway LB at 139.144.241.4
- Traffic is served by their `_gateways/.yaml` Gateway + HTTPRoute pairs
What needs to happen
For each one, the upstream CI/chart that creates the Ingress needs to stop creating it. Options:
- laddr (covers code-for-philly + laddr namespaces) — update the emergence-site Helm chart or laddr's preview-deploy workflow values to set `ingress.enabled: false` (or remove the Ingress template entirely)
- codeforphilly-rewrite-sandbox — update the rewrite project's deploy CI to stop applying the Ingress manifest
After each source is updated, the orphan Ingress can be `kubectl delete`d. Once deleted, they won't come back.
Interim option
If we want them gone immediately without waiting for source updates, just `kubectl delete` them. They'll come back on the next deploy from their respective CIs, but the cycle becomes "delete, redeploy, delete, redeploy" until the CI is fixed.
Old Ingress-managed certs
While we're at it, there are leftover `-tls` Secrets that were associated with the deleted Ingresses (these are different from the new `-gw-tls` Secrets for Gateway-managed certs). They're not actively referenced anymore. Worth a sweep:
```bash
KUBECONFIG=~/.kube/cfp-sandbox-cluster-kubeconfig.yaml kubectl get cert -A | grep -v gw-tls
```
Most can be deleted alongside the corresponding Ingress source cleanup.
After PR #157 removed ingress-nginx from the cluster, three Ingress resources remain orphaned. They reference an IngressClass (`nginx`) that no longer exists and DNS doesn't route to them anyway — but they should be cleaned up at source so `kubectl get ingress -A` is honest.
Orphaned Ingresses
All three are functionally inert:
What needs to happen
For each one, the upstream CI/chart that creates the Ingress needs to stop creating it. Options:
After each source is updated, the orphan Ingress can be `kubectl delete`d. Once deleted, they won't come back.
Interim option
If we want them gone immediately without waiting for source updates, just `kubectl delete` them. They'll come back on the next deploy from their respective CIs, but the cycle becomes "delete, redeploy, delete, redeploy" until the CI is fixed.
Old Ingress-managed certs
While we're at it, there are leftover `-tls` Secrets that were associated with the deleted Ingresses (these are different from the new `-gw-tls` Secrets for Gateway-managed certs). They're not actively referenced anymore. Worth a sweep:
```bash
KUBECONFIG=~/.kube/cfp-sandbox-cluster-kubeconfig.yaml kubectl get cert -A | grep -v gw-tls
```
Most can be deleted alongside the corresponding Ingress source cleanup.