CTS-KB
インフラ📚 シリーズ 1/15

Google Cloud CLI・kubectl入門：GKEを安全に操作する最初の一歩

⏱ 約 4 分で読めます
#Kubernetes#GKE#Google Cloud#gcloud#kubectl
Dockerfile・Docker Compose・Kubernetes：単独イメージから外部運用へ

Kubernetes を始めると、gcloud と kubectl という2つのCLIが登場します。最初にここを曖昧にすると、「どのプロジェクトの、どのクラスタを操作しているのか」が分からないままコマンドを実行しかねません。

本シリーズは 手作業による構築・確認を前提にします。CI/CDは扱いません。コマンド中の YOUR_PROJECT_ID などはすべて説明用の標準プレースホルダーです。実際のプロジェクトID、メールアドレス、トークンを記事やリポジトリへ記録しないでください。

gcloudとkubectlの役割

CLI操作対象代表的な用途
gcloudGoogle Cloudログイン、プロジェクト選択、GKEクラスタの作成・認証情報取得
kubectlKubernetes APIDeployment、Service、Podなどクラスタ内リソースの作成・確認

gcloud でGKEへの入口を準備し、kubectl でクラスタ内を操作する、と捉えると分かりやすい構造です。

1. CLIを準備する

Google Cloud CLIは公式のインストール手順に従います。kubectl とGKE認証プラグインも必要です。Google Cloud CLIのコンポーネントマネージャーを使える環境では、次のように導入できます。

gcloud components install kubectl gke-gcloud-auth-plugin
gcloud version
kubectl version --client
gke-gcloud-auth-plugin --version

OSのパッケージ管理でGoogle Cloud CLIを入れた場合は、同じパッケージ管理方式で kubectl と認証プラグインを追加します。

2. Google Cloudへログインする

人が手元から操作する入門段階では、ユーザー認証を使います。

gcloud auth login
gcloud auth list

アプリケーション既定の認証情報も必要なツールを併用する場合だけ、次を別途実行します。

gcloud auth application-default login

サービスアカウントのJSONキーをダウンロードして使い回す運用は避けます。GKE上のアプリケーション認証は第10回で Workload Identity Federation for GKE を扱います。

3. 対象プロジェクトとリージョンを固定する

gcloud config set project YOUR_PROJECT_ID
gcloud config set compute/region YOUR_REGION
gcloud config list

複数環境を扱う場合は、設定を名前付きで分離すると誤操作を減らせます。

gcloud config configurations create YOUR_CONFIGURATION_NAME
gcloud config set project YOUR_PROJECT_ID
gcloud config configurations list

コマンドの前後で gcloud config get-value project を確認する癖を付けます。本番と検証を同じ設定で行き来しないことが重要です。

4. GKEクラスタへ接続する

既存クラスタを一覧し、認証情報をkubeconfigへ追加します。

gcloud container clusters list --project YOUR_PROJECT_ID

gcloud container clusters get-credentials YOUR_CLUSTER_NAME \
  --region YOUR_REGION \
  --project YOUR_PROJECT_ID

ゾーンクラスタの場合は --region の代わりに --zone YOUR_ZONE を使います。get-credentials はクラスタを作るコマンドではなく、接続先と認証方法をローカルのkubeconfigへ登録するコマンドです。

5. contextとNamespaceを確認する

context は「クラスタ・認証ユーザー・既定Namespace」の組み合わせです。操作前に現在地を確認します。

kubectl config current-context
kubectl config get-contexts
kubectl config view --minify
kubectl cluster-info

Namespaceは同じクラスタ内の論理的な区画です。学習用Namespaceを作り、以降のコマンドで明示します。

kubectl create namespace YOUR_NAMESPACE
kubectl get namespaces
kubectl config set-context --current --namespace=YOUR_NAMESPACE

本番では default Namespaceへ何でも置かず、サービスや環境ごとに分離します。コマンド例でも -n YOUR_NAMESPACE を省略しすぎない方が安全です。

6. 最初に覚える調査コマンド

# 一覧
kubectl get pods -n YOUR_NAMESPACE
kubectl get deployments,services -n YOUR_NAMESPACE

# 詳細とイベント
kubectl describe pod YOUR_POD_NAME -n YOUR_NAMESPACE
kubectl get events -n YOUR_NAMESPACE --sort-by=.metadata.creationTimestamp

# ログ
kubectl logs YOUR_POD_NAME -n YOUR_NAMESPACE
kubectl logs YOUR_POD_NAME -n YOUR_NAMESPACE --previous

# コンテナ内でコマンド実行
kubectl exec -it YOUR_POD_NAME -n YOUR_NAMESPACE -- /bin/sh

get は現在状態の一覧、describe は設定・状態・イベント、logs はアプリケーション出力を見るコマンドです。障害対応ではこの順番が基本になります。

補助ツールは後から加える

kubectx や kubens、シェル補完、alias k=kubectl は便利ですが、最初は生のコマンドとcontextの意味を理解することを優先します。補助ツールは誤ったクラスタを安全にしてくれるものではありません。

確認チェック

  • gcloud config get-value project が対象プロジェクトか
  • kubectl config current-context が対象クラスタか
  • kubectl config view --minify のNamespaceが想定どおりか
  • コマンドに実在する秘密値を貼っていないか
  • 変更前に get と describe で現在状態を確認したか

次回

次は、Dockerfile・Docker Compose・Kubernetesの役割を整理し、「作った同じイメージをローカルから外部運用へ持っていく」流れをつなぎます。

参考資料