Closed JerrinAndrei closed 2 months ago
@JerrinAndrei thanks for opening this PR and the GitHub issue! After thinking about this and the IPV6 fix (#2013) more, I think the existing sed
approach isn't flexible enough to accommodate additional use cases. If/when more one-off changes need to be made, it will require additional changes and cloud releases.
The ideal the solution would make it possible to facilitate additional nginx configuration tweaks should another use case arise. After discussing this with the team today, we believe #2018 will serve both of these use cases and future ones well. Would appreciate any feedback you have on that approach and we can proceed with that instead of my earlier IPv6 PR and this one.
Thanks for raising this issue @JerrinAndrei. Since I didn't hear back on my earlier comment, I decided to proceed with #2018. Please let me know if you have any trouble using that and I'm happy to help.
This looks good to me @ddelnano . Most of the components in nginx conf would vary from cluster to cluster, so moving this to a configmap would give the entire configuration control to the user. Eagerly awaiting for the release this week. :)
Currently the nginx.conf expects the a kubernetes dns service named kube-dns.kube-system.svc.cluster.local to be existing in the cluster. If this dns service does not exist the cloud-proxy pod gets terminated on startup. This issue has been addressed in this PR. Here, we are moving the kubeernetes dns service name to a config and updating the nginx conf with this name at startup. This will prevent the container failing to be up on clusters that do not have a standard naming convention for the dns service.