Introduction

Installing a specific Kubernetes version means pinning the versions of the components you actually run, usually kubeadm, kubelet, and kubectl. The exact commands depend on your package manager and operating system, but the operational rule is stable: install the desired version explicitly and stop the package manager from silently upgrading it later.

Decide Which Components Need the Exact Version

For a kubeadm-managed setup, the main components are:

• 'kubeadm'
• 'kubelet'
• 'kubectl'

Those should usually be version-aligned according to the Kubernetes version-skew rules. If your goal is reproducible cluster bootstrap, pinning only one binary is usually not enough.

Install a Pinned Version with the Package Manager

On Debian-based systems, the pattern is to install the versioned packages explicitly.

sudo apt-get update
sudo apt-get install -y kubelet=1.30.0-1.1 kubeadm=1.30.0-1.1 kubectl=1.30.0-1.1

The exact package suffix can differ by repository and packaging scheme, so the first step is always to inspect which versions your configured repository actually offers.

Hold the Packages After Installation

After installing the target version, hold the packages so a later system upgrade does not move them unexpectedly.

sudo apt-mark hold kubelet kubeadm kubectl

This matters because Kubernetes version control is not just about the first install; it is about keeping the node in the intended state.

Managed Kubernetes Is Different

If you are using a managed service such as GKE, EKS, or AKS, “install a version” usually means selecting a cluster version through the provider rather than installing packages directly on the control plane.

That is a different operational model from self-managed nodes. Be clear whether you are pinning a local installation or selecting a provider-managed cluster release.

Verify the Installed Version Explicitly

After installation, check what the binaries actually report.

kubeadm version
kubectl version --client
kubelet --version

If those versions are not what you intended, fix the package selection before moving on to cluster initialization.

Common Pitfalls

• Pinning one Kubernetes component while letting the others drift to another version.
• Installing the desired version but forgetting to hold the packages afterward.
• Copying an old package command without checking which versions the configured repository currently exposes.
• Confusing self-managed package installation with managed-cluster version selection.
• Ignoring Kubernetes version-skew guidance when mixing components.

Summary

• Install the exact versions of kubeadm, kubelet, and kubectl you intend to use.
• Use your package manager’s versioned install syntax rather than hoping the latest package matches your target.
• Hold the packages so they do not upgrade unexpectedly.
• Verify the installed versions before bootstrapping the cluster.
• Managed Kubernetes version selection is a different workflow from self-managed installation.