viccuad
commented
4 years ago This should already work automatically. external-dns monitors the annotations on the stratos services, and when we delete the services by deleting stratos in make stratos-clean, external-dns removes the DNS entries on the public cloud.
Maybe the cleaning of the cluster happened so fast that external-dns was also removed before it had time to work. Or maybe it's just the dns propagation, which is difficult to fight.
In the kubecf pipeline we deploy the public cloud clusters with the DNS configured to only be accessible from inside the cluster. This makes it quite faster and secure, but also means that any services or api endpoints cannot be accessed publicly from outside the cluster external network. The outcome is that one cannot do cf login or similar from concourse workers or development machines, but smokes, cats, sits etc work.
I'm on the opinion that we should follow this approach for the DNS zones of our public clusters on cap pipelines too, for security reasons. The only downside is one cannot cf login or manually interact with the cluster from the outside network, but one can spawn a pod inside of the cluster to work within, for example with make modules-extra-terminal.
After you run
make stratos-clean, the dns entries created upon deployment remain configured. This causes problems on deployments afterwards if a test or user tries to access stratos ui via the hostname as until the change has propagated, the wrong ip gets connected. This in some cases took over 10 minutes. A proper approach would be to remove the ip addresses from the dns setup once stratos gets deleted.