Change:
RELEASE="$(curl -sSL https://dl.k8s.io/release/stable.txt)" ARCH="amd64" cd $DOWNLOAD_DIR <del> sudo curl -L --remote-name-all https://storage.googleapis.com/kubernetes-release/release/${RELEASE}/bin/linux/${ARCH}/{kubeadm,kubelet,kubectl} sudo chmod +x {kubeadm,kubelet,kubectl} </del> <ins> sudo curl -L --remote-name-all https://dl.k8s.io/release/${RELEASE}/bin/linux/${ARCH}/{kubeadm,kubelet} sudo chmod +x {kubeadm,kubelet} </ins> RELEASE_VERSION="v0.4.0" curl -sSL "https://raw.githubusercontent.com/kubernetes/release/${RELEASE_VERSION}/cmd/kubepkg/templates/latest/deb/kubelet/lib/systemd/system/kubelet.service" | sed "s:/usr/bin:${DOWNLOAD_DIR}:g" | sudo tee /etc/systemd/system/kubelet.service

Discussion:
This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: The “without a package manager” section of suggests that people download components from within However, recommends downloading from To me, the URLs seem more official and also make it easier for us to bolt in a CDN or whatever if we want to serve content from not-Google. Proposed Solution: Revise the “without a package manager” tab in to recommend downloading and from If possible, avoid fetching the latest release version via HTTP. This website repo already has the release information available so we can cut out a step (and make the docs more accurate when people are reading docs for previous Kubernetes versions). For the download, refer readers to Continue to recommend downloading from GitHub Continue to recommend downloading CNI tooling from GitHub Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: The same page also recommends downloading packages (RPM, ) from Google. This issue doesn't cover the packaged downloads, just the direct downloads of the files. This issue also doesn't cover a change to how people download and install that tool. This issue also doesn't cover a change to how people download CNI tooling. /sig release /sig cluster-lifecycle /language en
If we remove the RELEASE version fetch step, we'd need a step to choose a Kubernetes version right? So something like "Choose the Kubernetes version you want to install from the Releases page." And then another line in the actual command that downloads kubeadm and the rest that says "Replace $RELEASE with the Kubernetes version that you selected". Am I off track here? also /triage accepted
You can already choose which Kubernetes version you're reading the docs for, so it ought to be enough to signpost readers to the choice. To help readers, we can also link from to the same doc in each of the supported docs versions - I think that'd need a shortcode, but it could be done.
For example, https://v1- could explain how to install v1.21.x (whatever is latest for v1.21).
/priority important-longterm
/assign
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]: