はじめに
はじめまして！ 2025年度新入社員の南野です。
8月に部署に配属されてから、業務の中で 「Kubernetes（クバネティス）」 という言葉をよく耳にするようになりました。
しかし、IT初心者の私はKubernetesの読み方すら分からず、次のような印象を持っていました。
- 何をしているものなのか分からない
- 難しそうでハードルが高そう
- 用語が多くてイメージが湧かない
そこで今回は、Kubernetesの概要を整理しつつ、実際にPodを起動して操作してみた内容を、IT初心者の目線でまとめてみました。
本記事は、Kubernetesの全体像をつかむことを目的としているので、気軽に読んでいただけると嬉しいです。
私と同じように
「Kubernetesを初めて聞いた人」
「名前は聞いたことがあるけど、よく分からない人」
の参考になれば幸いです。
Kubernetesとは？
Kubernetesとは、コンテナ化されたアプリケーションを運用・管理するためのツールです。
公式サイトでは次のように説明されています。
Kubernetesは、デプロイやスケーリングを自動化したり、コンテナ化されたアプリケーションを管理したりするためのオープンソースのシステムです。
これをかみ砕くと、ポイントは次の3つです。
- コンテナを管理する
- デプロイを自動化する
- スケーリングを自動化する
簡単に言うと、コンテナを使ったシステム運用を自動でいい感じにやってくれる仕組みです。
コンテナとは？
ここで「そもそもコンテナって何？」という疑問が出てきます。
コンテナは、アプリケーションとその実行環境をひとまとめにパッケージ化したものです。
OSやライブラリの差異を気にせず、どこでも同じ環境で動かせるのが特徴です。
例えば、ローカルでは動くのに本番サーバではエラーが出る場合、OSやライブラリのバージョン違いが原因になっていることがあります。
コンテナを使えば、同じコンテナイメージから環境を作るため、どこで起動しても同じ動作を保証できます。
Kubernetesでできること
コンテナは便利ですが、数が増えてくると管理が大変です。
そこで登場するのがKubernetesです。
コンテナの管理
Kubernetesを使うと、Webサーバ用・アプリケーション用・DB用など、複数のコンテナをまとめて管理できます。また、CPUやメモリの割り当てといったリソース制御も可能です。
デプロイの自動化
Kubernetesでは、理想の構成をマニフェストファイル（YAML形式）に記述します。
- どんなコンテナを使うか
- いくつ起動するか
- どれくらいのリソースを使うか
これらを定義しておけば、マニフェストを適用するだけで書かれた内容どおりの環境を自動で構築できます。
スケーリングの自動化
負荷に応じてPodの数を自動で増減させることができます。
- 必要なときに増える
- 不要になったら減る
といった調整を自動で行ってくれるのが特徴です。
Kubernetesのアーキテクチャ概要
ここでは全体像をつかむため、アーキテクチャを簡単にまとめています。
Pod
Podは、Kubernetesにおける最小のデプロイ単位です。
1つ以上のコンテナを含むことができ、Kubernetesではコンテナを直接扱わず、Podとして管理します。
Podを管理するワークロードリソース
Kubernetesでは、Podの状態を管理するために「ワークロードリソース」を利用します。
ReplicaSet：指定した数のPodが常に動くように管理するリソースです。Podが削除された場合でも、自動で新しいPodを作成して数を維持します。
Deployment：ReplicaSetを管理するリソースです。Deploymentを使うことで、Podのスケールやアプリケーションの更新を安全に行えます。
実運用では、Deploymentを通してPodを管理することが一般的です。
Kubernetesの構成
Kubernetesは、複数台のサーバ（ノード）で構成されます。
実際のアプリケーションはPodとしてノード上で動作し、クラスタ全体の管理はコントロールプレーンが担当します。
コントロールプレーン
コントロールプレーンは、クラスタ全体の状態を管理する中枢です。
- どのPodをどのノードで動かすか
- 指定された数のPodが正しく動いているか
といったことを判断し、クラスタを常に理想の状態に保つ役割を担っています。
ノードコンポーネント
ノードは、コントロールプレーンからの指示を受けて、実際にPodを起動・管理します。 ノード内ではkubeletなどのコンポーネントが動作し、Podの作成や状態の監視を行います。
実際に触って理解してみる
ここまでで、Kubernetesの役割や全体像を簡単に整理しました。
ここからはローカル環境で実際にPodを起動し、動きを確認してみます。
環境準備
今回はローカルで手軽にKubernetesを触れるよう、以下のツールを使用しています。
本記事の手順はWindows環境を前提としています。
インストール方法は環境によって異なるため、各ツールはご自身の環境に合った手順で公式サイトから用意してください。
| ツール名 | 説明 |
|---|---|
| minikube | ローカル環境でKubernetesクラスタを簡単に立ち上げられるツール |
| kubectl | Kubernetesクラスタを操作するためのコマンドラインツール |
※ minikubeの実行には、事前にDockerなどのコンテナが実行できる環境が必要です。
minikubeでクラスタを起動する
まずは、ローカル環境にKubernetesクラスタを起動します。
minikube start --kubernetes-version=v1.30.0
Podを起動してみる（nginx）
次に、web-server という名前のPodを起動します。
動作確認用として、nginxの公式イメージを利用しました。
※kubectl run は簡易的な動作確認には便利ですが、実運用では Deploymentやマニフェスト(YAML)で管理するのが一般的です。
kubectl run web-server --image=nginx:latest pod/web-server created
Podの状態を確認してみます。
kubectl get pod NAME READY STATUS RESTARTS AGE web-server 1/1 Running 0 2m19s
STATUS が Running になっていれば、Podは正常に起動しています。 kubectl run で指定した名前が、そのままPod名として使われていることも確認できます。
namespaceの違いを確認する
Kubernetesでは、Podなどのリソースを namespace という単位で論理的に分離して管理します。 まずは、クラスタ内に存在するPodをすべて表示してみます。
kubectl get pod --all-namespaces NAMESPACE NAME READY STATUS RESTARTS AGE default web-server 1/1 Running 0 7m47s kube-system coredns-7db6d8ff4d-pq4p2 1/1 Running 5 (29m ago) 23h kube-system etcd-minikube 1/1 Running 6 (29m ago) 23h kube-system kube-apiserver-minikube 1/1 Running 6 (29m ago) 23h kube-system kube-controller-manager-minikube 1/1 Running 7 (29m ago) 23h kube-system kube-proxy-scvkm 1/1 Running 5 (29m ago) 23h kube-system kube-scheduler-minikube 1/1 Running 5 (29m ago) 23h kube-system storage-provisioner 1/1 Running 7 (29m ago) 23h
先ほど作成した web-server は、default namespaceに配置されていることが分かります。 namespaceを指定せずにリソースを作成した場合は、このdefaultが利用されます。
※ kube-system namespace は、Kubernetesの内部コンポーネントが使用する管理用の領域です。
namespaceを作成してPodを起動してみる
次に、webappという名前のnamespaceを作成します。
kubectl create namespace webapp namespace/webapp created
作成した namespace を指定して、先ほどと同じ名前のPodを起動します。
kubectl run web-server --image=nginx:latest -n webapp pod/web-server created
再度、全namespaceのPodを確認してみます。
kubectl get pod --all-namespaces NAMESPACE NAME READY STATUS RESTARTS AGE default web-server 1/1 Running 0 7m47s ... webapp web-server 1/1 Running 0 50s
※ kube-system namespace のPodは省略
default と webapp の両方に web-server というPodが存在していることが確認できます。 このように、namespaceが異なれば同じ名前のPodを作成できる という点が分かります。
Podの動作を確認する（curl）
起動したPodが正しく動作しているかを確認してみます。 まずは、webapp namespace にあるPodのIPアドレスを確認します。
kubectl -n webapp get pod web-server -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES web-server 1/1 Running 0 23m 10.244.0.10 minikube <none> <none>
IPアドレスが確認できたので、同じnamespace内に一時的なcurl用のPodを起動し、その中からリクエストを送ってみます。
kubectl -n webapp run curl-pod --restart=Never -it --rm --image=curlimages/curl:latest -- sh If you don't see a command prompt, try pressing enter. ~ $ curl http://10.244.0.10 <!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> </head> <body> <h1>Welcome to nginx!</h1> ... </body> </html> ~ $
無事レスポンスが返ってくることを確認できました！
片付け
最後に、作成したPodを削除します。
kubectl -n webapp delete pod web-server pod "web-server" deleted
kubectl get all -n webapp No resources found in webapp namespace.
No resources found と表示されていれば、後片付けは完了です。
まとめ
今回は、Kubernetesの概要とPodの基本的な扱い方について整理し、実際にPodを起動して動作を確認しました。
まだ勉強中ではありますが、今回の内容を通して、
Kubernetesの全体像や基本的な考え方をつかむことができたと感じています。
今後はDeploymentやReplicaSetにも触れながら、より実務に近い使い方を学んでいきたいと思います。
本記事が、Kubernetesをこれから学ぶ方の参考になれば幸いです。
