search

kelseyhightower / kubernetes-the-hard-way

Bootstrap Kubernetes the hard way. No scripts.
Apache License 2.0
39.9k stars 13.7k forks source link

Make this guide platform agnostic. #706

Closed dwbfox closed 1 year ago

dwbfox commented 2 years ago

While this is a great guide for a lot of people interested in deploying k8s, I think it's misleading by the fact that it is heavily geared towards configuring it on Google Cloud Platform. It makes an honorable mention of this guide being applicable for "other platforms", but making it GCP-specific adds unnecessary noise in what is otherwise an attempt at allowing people to learn the internals of the deployment. Perhaps renaming it to "Kubernetes The Hard Way on Google Cloud Platform" would be more apt.

The solution should be the other way around. Instead of example snippets like these:

EXTERNAL_IP=$(gcloud compute instances describe ${instance} \
  --format 'value(networkInterfaces[0].accessConfigs[0].natIP)')

Users should be able to run native, agnostic Linux commands to fetch this kind of data and then, if they so choose, retroactively rework the command into the platform of their choice (AWS, Azure, GCP, etc.)

inductor commented 2 years ago

There are several editions for other platforms. As he currently belongs to GCP, I don't think he'd make this type of change.

dwbfox commented 2 years ago

There are several editions for other platforms. As he currently belongs to GCP, I don't think he'd make this type of change.

At the very least, this being made for Google Cloud should be part of the title of the course then if the intent is to upsell the product. A lot of people search and hit this tutorial and turn away when they realize they have to sign up for GCP, get free tier access, set up the gcp CLI tools as prerequisite to running the embedded commands.

inductor commented 2 years ago

I mean this is open source so you can create one by yourself and that is why other editions were made by others.

jamesgeddes commented 2 years ago

As @inductor has mentioned, other providers are available. For example,

I don't think a generic guide would be too helpful - the whole point is that this is mega detailed. Furthermore, K8s is originally a Google product so makes sense that a Googler is sharing how to use it on Google infra.

dewan-ahmed commented 1 year ago

There are several editions for other platforms. As he currently belongs to GCP, I don't think he'd make this type of change.

At the very least, this being made for Google Cloud should be part of the title of the course then if the intent is to upsell the product. A lot of people search and hit this tutorial and turn away when they realize they have to sign up for GCP, get free tier access, set up the gcp CLI tools as prerequisite to running the embedded commands.

These type of comments make me sad. Read this article which explains the difference between a gift and a product. This guide is a gift from the author to the community. The number of forks and stars indicate how the community has benefitted from this gift. For most folks starting in their K8s journey, a cloud-specific detailed set of instructions help in a better way rather than another abstraction (non-cloud generic version).

When we speak and demo at conferences, we talk about open-source technologies but our demo shows the product. This is a healthy and perfectly acceptable balance of project (i.e. open-source project) and product (i.e. paid product). Treat this guide that way. Accept that it's a gift and please appreciate the gift. Kindness works everywhere; even on GitHub issues.

dwbfox commented 1 year ago

@dewan-ahmed I categorically reject your premise here. First, part of participating in an open source community is also having open discourse. I created this issue as an open-ended constructive feedback, with suggestions on how to better constrain the scope of this article. I did so with an expectation and understanding that such feedback could/would be criticized or rejected outright. It was feedback. Not a demand.

Second, if the point you're making here is that open source projects are charity, therefore immune to feedback or discussions, then by all means, the maintainers can disable the issue tracker or auto-close all issues. But I don't think that's in the spirit of open source.

I've published my own share of open source projects and sometimes receive criticisms or requests to change the software. What I never do is question the motives of the contributors. If it can be implemented, I'll implement it. If I can't or don't feel like it, I'll inform them of this fact and mark the issue closed.

Now before we slide further into off topic discussions, I'll mark this issue resolved per comment https://github.com/kelseyhightower/kubernetes-the-hard-way/issues/706#issuecomment-1151310342 as it looks like this is unlikely to be changed, thus this discussion has already been put to rest.