[WIP] Documentation for custom pod DNS alpha feature

[MrHohn]

Need to document:

• Custom pod DNS concept.
• New DNSPolicy None for pod.
• New DNSConfig field for pod.

---

This change is 

[MrHohn]

Ref feature issue: kubernetes/enhancements#504

[k8sio-netlify-preview-bot]

Deploy preview ready!

Built with commit b9866aa

https://deploy-preview-6408--kubernetes-io-vnext-staging.netlify.com

[tengqm]

@MrHohn Please help pcheck if #6441 already covers the change you wanted.

[MrHohn]

@tengqm Thanks for the works, your PR looks great. Just that it is targeting master branch instead of release-1.9 branch. Would you mind changing it (or opening a new one) to target release-1.9 and I will close this one?

[tengqm]

@MrHohn Thanks for the comments. My intent when drafting #6441 was to make it general. It highlights v1.9 when appropriate so it won't cause confusion. I'm looking forward it to be merged into master and then picked into release-1.9. I tried proposing directly to release-1.9 branch previously, there were some conflicts to solve. @zacharysarah WDYT?

[zacharysarah]

@tengqm 👋 If #6441 supersedes this PR by effectively documenting a feature slated for 1.9 release, then #6441 really does need to base from release-1.9. I'm happy to help resolve any merge conflicts that arise. (What conflicts were you seeing, btw?)

[tengqm]

@zacharysarah I'm a bit confused about the work flow. My previous understanding is that all PRs are supposed to be part of the master branch. If a PR is specifically about a release, it will be cherry-picked into that branch. However, you are suggesting that we propose a PR to release-1.9 directly. Does that mean the release-1.9 contents will be merged back to master again at some time?

[tengqm]

@zacharysarah I have just committed #6479, although I'm still confused.

[zacharysarah]

@tengqm Thanks. 🙇

My previous understanding is that all PRs are supposed to be part of the master branch. If a PR is specifically about a release, it will be cherry-picked into that branch. However, you are suggesting that we propose a PR to release-1.9 directly.

I think the confusion may arise from the fact that kubernetes/website uses master and release-X.x branches differently than other K8s dev repositories.

In other dev repos, commits to master:

1. Don't immediately go live
2. Are cherry-picked into a release branch that's released to production

In kubernetes/website, changes to master:

1. Immediately go live on https://k8s.io

Commits to a new release branch are deployed on k8s.io with a version selector when a new version of Kubernetes goes live.

The reason why I'm asking you to base PRs containing information about 1.9 to release-1.9 instead of master is because in kubernetes/website, if you merge that PR to master, those changes will go live immediately.

Does that mean the release-1.9 contents will be merged back to master again at some time?

No; release-1.9 will exist as a snapshot in time, much as release branches in other repos do. We merge master into a release branch until it's released, make it accessible from k8s.io with a version selector, then cease to maintain it. Again, in kubernetes/website, master represents the most current version of k8s.io, and changes pushed to master immediately go live on the website.

Does that help?

[MrHohn]

Thanks all, I'm closing this in favor of #6479.

[tengqm]

Ah ... finally, I get it! A big thank you, @zacharysarah.