Introduction

For an older ACS-style Kubernetes cluster on Azure, SSH access to a node is really Azure VM access, not a special Kubernetes feature. The workflow is usually: identify the node in Kubernetes, map it to the backing Azure machine, and connect using the SSH username and key that were configured when the cluster was created.

Start by Identifying the Node

First, find the Kubernetes node you want to inspect.

kubectl get nodes -o wide

This usually gives you the node name and an internal IP. If you need more detail, inspect the node directly:

kubectl describe node k8s-agentpool1-12345678-0

The purpose of this step is to correlate the Kubernetes object with the actual Azure VM that hosts it.

SSH Access Depends on Azure Networking

Kubernetes itself does not grant or deny SSH. The ability to log in depends on the underlying Azure VM configuration:

• the VM must be reachable from your network path,
• you must know the correct SSH username,
• and you must have the private key that matches the public key installed at provisioning time.

In many environments, agent nodes do not have public IP addresses. That means direct internet SSH is not available even if the cluster is healthy. In that case, use one of these paths:

• a jump box in the same virtual network,
• Azure Bastion,
• a VPN or private corporate network route.

That is why kubectl get nodes is only the beginning. It tells you which machine you need, not how you reach it.

Find the Backing Azure VM

For a classic ACS deployment, the nodes are typically ordinary Azure virtual machines in the cluster's resource group. Azure CLI can help you inspect them:

az vm list -g my-acs-resource-group -d -o table

Look for the VM that matches the node name or internal IP from the Kubernetes output. Once you identify it, inspect its network details:

az vm show -g my-acs-resource-group -n k8s-agentpool1-12345678-0 -d -o json

If there is no public IP, that is expected in many production-style setups. You will need an internal route.

Connect With SSH

If the machine is reachable and you know the username and key, the SSH command is ordinary Linux VM access. Azure examples often use azureuser, but you must use whatever username was actually configured.

ssh -i ~/.ssh/id_rsa [email protected]

If you need a jump host, use SSH's jump option:

ssh -J [email protected] [email protected]

That tells SSH to connect through the public jump box first and then continue to the private node.

Use Node Access for Diagnosis, Not Routine Management

SSH can be useful for checking:

• kubelet logs,
• disk pressure,
• container runtime state,
• node-level network issues.

For example:

sudo systemctl status kubelet
sudo journalctl -u kubelet -n 100
df -h

Those are good reasons to log into a node. Routine application management is not. In Kubernetes, durable changes should go through manifests, images, or cluster configuration, not ad hoc node edits.

Prefer Kubernetes-Native Debugging First

Before opening an SSH session, check whether the problem can be solved from the Kubernetes layer. Many issues that feel "node-related" are actually pod scheduling, probe, or application issues.

1kubectl get pods -A -o wide
2kubectl describe pod my-pod
3kubectl logs my-pod
4kubectl get events --sort-by=.metadata.creationTimestamp

These commands are safer and often faster than dropping immediately to the host OS. SSH is best treated as a low-level troubleshooting tool, not the first step in every investigation.

Common Pitfalls

• Assuming Kubernetes provides a special SSH command for nodes. It does not; you are logging into Azure VMs.
• Looking for a public IP when the nodes were intentionally deployed on a private network.
• Using the wrong SSH username or a key that does not match the cluster provisioning settings.
• Making manual node changes and expecting them to survive node replacement or cluster maintenance.
• Skipping kubectl-level diagnostics and going straight to SSH even when the issue is higher up the stack.

Summary

• SSH to an ACS Kubernetes node is really SSH to the backing Azure VM.
• Use kubectl get nodes -o wide to identify the target node first.
• Map the node to an Azure VM and confirm whether it has a reachable network path.
• Connect with the SSH username and key configured during cluster creation, often through a jump host.
• Treat node login as a troubleshooting tool, not a normal configuration workflow.