Add best practices to getting started with GCE docs

[danielvegamyhre]

The purpose of these changes is to document some best practices when using kOps to create and administer a k8s cluster in GCP. For each best practice, I included a description of why it is considered a best practice, as well as example kops commands to utilize it.

Currently the best practices I have included are:

• Using spot instances to reduce cost for fault-tolerant workloads
• Using a multi-zonal cluster to ensure high availability in the event of an datacenter/rack/server outage

I tested these changes using make live-docs to view my changes locally.

Let me know if there are additional best practices we should add and I will be happy to do so.

[k8s-ci-robot]

Welcome @danielvegamyhre!

It looks like this is your first PR to kubernetes/kops 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes/kops has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[k8s-ci-robot]

Hi @danielvegamyhre. Thanks for your PR.

I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[hakman]

Thanks @danielvegamyhre! :)
/ok-to-test
/lgtm
/assign @justinsb

[justinsb]

Awesome, thank you @danielvegamyhre

I like the idea of guiding users a bit more as to "things they should be doing", in addition to describing all the things they can do!

/ok-to-test
/approve
/lgtm

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: justinsb

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

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [justinsb]

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

[justinsb]

/retest

[justinsb]

I'll have a look at why these tests are suddenly failing, it's surprising and I can't see how it could relate to a docs PR :-)

[justinsb]

/retest

[k8s-triage-robot]

The Kubernetes project has merge-blocking tests that are currently too flaky to consistently pass.

This bot retests PRs for certain kubernetes repos according to the following rules:

• The PR does have any do-not-merge/* labels
• The PR does not have the needs-ok-to-test label
• The PR is mergeable (does not have a needs-rebase label)
• The PR is approved (has cncf-cla: yes, lgtm, approved labels)
• The PR is failing tests required for merge

You can:

• Review the full test history for this PR
• Prevent this bot from retesting with /lgtm cancel or /hold
• Help make our tests less flaky by following our Flaky Tests Guide

/retest

[hakman]

@justinsb We noticed something similar on other PRs. Somehow it seems like rebase doesn't work well. Manual rebase helped, but didn't have time look deeper to see why it happens.

[k8s-ci-robot]

@danielvegamyhre: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
pull-kops-e2e-k8s-aws-calico	84a7c3a	link	true	/test pull-kops-e2e-k8s-aws-calico
pull-kops-e2e-k8s-gce-cilium	84a7c3a	link	true	/test pull-kops-e2e-k8s-gce-cilium

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

[justinsb]

The problem looks to be this from kubelet:

E1122 01:21:31.667344    3391 run.go:74] "command failed" err="failed to run Kubelet: failed to initialize kubelet client: host must be a URL or a host:port pair: \"https://\""

I think the issue is that we build from source, but then when we upload we might not run with the matching nodeup, because we don't always upload it:

From https://storage.googleapis.com/kubernetes-jenkins/pr-logs/pull/kops/14569/pull-kops-e2e-k8s-aws-calico/1594860036918611968/build-log.txt

...
== Uploading kops ==
gsutil -h "Cache-Control:private, max-age=0, no-transform" -m cp -n -r /home/prow/go/src/k8s.io/kops/.build/upload/kops/* gs://kops-ci/pulls/pull-kops-e2e-k8s-aws-calico/pull-84a7c3abb9d71cacca2159b3e43d6a3f4b18fceb
Skipping existing item: gs://kops-ci/pulls/pull-kops-e2e-k8s-aws-calico/pull-84a7c3abb9d71cacca2159b3e43d6a3f4b18fceb/1.26.0-alpha.2+v1.26.0-alpha.1-417-g60386cc0de/linux/amd64/protokube
Skipping existing item: gs://kops-ci/pulls/pull-kops-e2e-k8s-aws-calico/pull-84a7c3abb9d71cacca2159b3e43d6a3f4b18fceb/1.26.0-alpha.2+v1.26.0-alpha.1-417-g60386cc0de/linux/amd64/channels
Skipping existing item: gs://kops-ci/pulls/pull-kops-e2e-k8s-aws-calico/pull-84a7c3abb9d71cacca2159b3e43d6a3f4b18fceb/1.26.0-alpha.2+v1.26.0-alpha.1-417-g60386cc0de/linux/amd64/kops.sha256
Skipping existing item: gs://kops-ci/pulls/pull-kops-e2e-k8s-aws-calico/pull-84a7c3abb9d71cacca2159b3e43d6a3f4b18fceb/1.26.0-alpha.2+v1.26.0-alpha.1-417-g60386cc0de/linux/amd64/kops
...

We should fix this, but probably not in this PR. I'm going to merge this one manually.

[hakman]

The problem looks to be this from kubelet:

The kubeconfig has an empty server. Using a locally built nodeup binary, I don't see this issue. Rebasing a PR would also fix the issue.
See comments from #14596 for reference.