Add documentation for VPA and sig-autoscaling

[adrianmoisey]

What type of PR is this?

/kind documentation

What this PR does / why we need it:

Use mkdocs to improve the look and feel of the VPA's documentation
Also add a sig-autoscaling site that redirects users to the location of the docs for each component

Which issue(s) this PR fixes:

Fixes #

Special notes for your reviewer:

• I still need to ask sig-docs if this is the right direction to go in
• A preview is available here: http://adrianmoisey.github.io/autoscaler/
• The chart index.yaml file is handled when deploying the docs, but, I don't know if the workflow that deploys the index.yaml will handle the docs existing
• I still want to write a small readme on how to work on these docs
• Having a "root" site and a "VPA" site is a little strange, but I think it allows for more flexibility in each component, which should be a good thing long term
• Both root and VPA sites are bare bones at the moment, and will need to be worked on, but for now I feel that they're good enough

A note on local development:

1. Make a Python virtualenv: python3 -m venv venv
2. Activate virtualenv: . ./venv/bin/activate
3. Install requirements: pip install -r docs/requirements.txt
4. Run mkdocs: mkdocs build --config-file "docs/mkdocs-root.yml", mkdocs build --config-file "docs/mkdocs-vertical-pod-autoscaler" (or replace build with serve)

Does this PR introduce a user-facing change?

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: adrianmoisey
Once this PR has been reviewed and has the lgtm label, please assign mwielgus for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[adrianmoisey]

/hold

Holding this for now. There is discussion about adding the docs to k/website.
The plan moving forward is to create docs, but not publish them, in this repo.

Once we have actual useful docs, we can then speak to sig-docs about how to get them into k/website.

[elmiko]

i don't know the VPA that well, so i'm not the best person for the content of the docs but i have a comments so far:

• depending on what we want to do with this PR, we might want to drop the github action just to make our intentions clearer. we want to get the docs in order, then figure out how to work with sig-docs to get them in the core.
• we might want to leave the README.md file in the root of the VPA directory so that we can direct users to the new documentation location. i'm guessing that vpa users might be aware of the readme already, so we don't want to create a situation where it's gone all of sudden.

[elmiko]

also, i was thinking about how we might want to document the cluster-autoscaler stuff and i think it will be challenging to solve this problem due to the providers. i think it's possible we could migrate the core CA docs, but we would want to have links for the provider specific pieces since those docs are owned by the various providers.

[adrianmoisey]

Oh, @elmiko, is it possible that you reviewed the wrong PR?

This PR is the one that I first made, to try add rendered docs to the VPA.

It started the conversation about where docs should live.

Then I made #7548 as a test of "what would it look like if all the .md files lived in a single directory", hoping that the layout would allow for more fluid documentation creation.

I'll close this one to avoid confusion.

[elmiko]

lol, my bad @adrianmoisey , i had this window open. i will review the /other/ one, thanks!