何が起きているか
kubectl コマンドを実行すると、次のエラーが表示されます：
The connection to the server localhost:8443 was refused - did you specify the right host or port?
kubectl は localhost:8443 にある Kubernetes API サーバーへの接続を試みていますが、そこでは何もリッスンしていません。原因は主に3つです：クラスターが起動していない、kubectl に有効な kubeconfig がない、または間違ったエンドポイントを指している。ポート 8443 は Minikube のデフォルトで、kubeadm クラスターは 6443 を使用します。kubeadm 環境で localhost:8443 が表示される場合は、kubeconfig が古いか設定ミスであることがほぼ確実です。
素早い診断
何かに触れる前に原因を絞り込みましょう。以下の4つの確認で95%のケースに対応できます。
1. 現在のコンテキストを確認する
kubectl config current-context
ここでエラーが出る場合、または見覚えのないコンテキスト名が表示される場合、それ自体が問題の原因であることが多いです。設定されているすべてを一覧表示します：
kubectl config get-contexts
2. kubeconfig の存在を確認する
echo $KUBECONFIG
ls ~/.kube/config
~/.kube/config がない場合、それが答えです。kubectl は設定が見つからないと localhost:8443 にフォールバックしますが、これはほぼ間違いなく誤りです。
3. ローカルクラスター（Minikube / kind）の場合
# Minikube
minikube status
# kind
kind get clusters
クラスターが停止または削除されている場合、kubectl が接続できる API サーバーが存在しません。
4. リモートクラスター（kubeadm / クラウド）の場合
kubectl cluster-info
kubeconfig 内のサーバーアドレスと実際の API サーバーの IP を照合します：
kubectl config view --minify | grep server
シナリオ別の修正方法
シナリオ A: ローカルクラスターが停止している（Minikube / kind）
ほとんどの場合、これが原因です。再起動しましょう：
# Minikube
minikube start
# kind（削除された場合は再作成）
kind create cluster --name my-cluster
Minikube は起動時に ~/.kube/config を自動的に書き換えます。起動したら、正常に動作しているか確認します：
kubectl get nodes
シナリオ B: kubeconfig がないか空の場合
新しいマシン、または設定が誤って削除された場合は再生成します：
# Minikube — kubeconfig を自動的に再生成
minikube update-context
# kubeadm — コントロールプレーンノードから管理者設定をコピー
scp user@control-plane-node:/etc/kubernetes/admin.conf ~/.kube/config
chmod 600 ~/.kube/config
chmod 600 は省略できません。kubectl は誰でも読み取り可能なパーミッションの設定ファイルを暗黙的に拒否します。
クラウドプロバイダーにはそれぞれ専用のコマンドがあります：
# AWS EKS
aws eks update-kubeconfig --region us-east-1 --name my-cluster
# GKE
gcloud container clusters get-credentials my-cluster --zone us-central1-a
# AKS
az aks get-credentials --resource-group my-rg --name my-cluster
シナリオ C: 間違ったコンテキストが選択されている
正しいコンテキストに切り替えます：
kubectl config use-context my-correct-context
デフォルトのコンテキストを恒久的に変更したくない場合は、--context フラグで任意のクラスターに対して一時的にコマンドを実行できます：
kubectl get pods --context=production-cluster
シナリオ D: kubeadm クラスターで API サーバーがダウンしている
コントロールプレーンに SSH 接続し、API サーバーのコンテナが実際に動作しているか確認します：
sudo crictl ps | grep kube-apiserver
# ヒントを得るために kubelet のログを確認
sudo journalctl -u kubelet -n 100
# スタティックポッドのマニフェストがまだ存在するか確認
ls /etc/kubernetes/manifests/kube-apiserver.yaml
ポッドがクラッシュしている場合は、ログを直接取得します：
sudo crictl logs $(sudo crictl ps -a | grep kube-apiserver | awk '{print $1}')
API サーバーがクラッシュする原因として最も多いのは、証明書の期限切れ、etcd のダウン、またはマニフェストフラグのタイプミスです。根本原因を修正すれば、kubelet が自動的にスタティックポッドを再起動します。
シナリオ E: ファイアウォールがポートをブロックしている
サーバーは動作しているが別のマシンから到達できない場合は、設定を疑う前に接続をテストします：
# 直接接続をテスト
telnet <api-server-ip> 6443
# または
curl -k https://<api-server-ip>:6443/healthz
ブロックされている場合はポートを開放します：
# UFW（Ubuntu）
sudo ufw allow 6443/tcp
# firewalld（RHEL/CentOS）
sudo firewall-cmd --permanent --add-port=6443/tcp
sudo firewall-cmd --reload
念のため繰り返します：kubeadm はデフォルトで 6443 を使用し、8443 ではありません。kubeadm クラスターで localhost:8443 が表示される場合、問題はファイアウォールではなく kubeconfig のサーバー URL です。
シナリオ F: kubeconfig 内のサーバー URL が古い
再構築後に API サーバーが新しい IP に移動した場合は、kubeconfig の URL を直接更新します：
# サーバー URL を更新
kubectl config set-cluster my-cluster --server=https://<new-api-server-ip>:6443
# 変更が反映されたか確認
kubectl config view --minify | grep server
修正の確認
kubectl cluster-info
kubectl get nodes
kubectl get pods -A
正常なクラスターでは、kubectl cluster-info から次のような出力が返されます：
Kubernetes control plane is running at https://<server>:<port>
CoreDNS is running at https://<server>:<port>/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
今後の予防策
- Minikube ユーザー： 開発環境の起動スクリプトに
minikube startを追加しましょう。30秒の起動時間は、作業中にこのエラーを調査するよりはるかにましです。 - kubeadm クラスター：
kube-apiserverを Prometheus + Alertmanager で監視下に置きましょう。開発者が kubectl の不具合に気づく前にアラートを受け取れます。 - リモートクラスター： kubeconfig はパスワードと同様に扱いましょう。シークレットマネージャーに保存し、
aws eks update-kubeconfigやgcloud get-credentialsをオンボーディングスクリプトに組み込んで、認証情報が静かに期限切れにならないようにしましょう。 - 複数クラスター：
kubectxをインストールしましょう。kubectl config use-contextの完全なコマンドの代わりにkubectx productionでコンテキストを切り替えると2秒で完了し、「なぜ何も動かないのか」という混乱を一掃できます。