はじめに
本記事では、前回の EKS ハンズオン（eksctl でクラスタを作り、Nginx・ECRイメージをデプロイ）を踏まえて、
「Kubernetesとは何か？」「どんな概念を押さえるべきか？」「ハンズオンで何をやったのか？」を振り返ってみます。
前回の記事↓↓
https://qiita.com/pommny_dev/items/d3b847f4af9ec7e2bc20
※ 本記事は、k8s初心者が調べながら手を動かしながら書いているため、
記事内容の信ぴょう性は保障いたしかねます。
（誤り等あれば指摘いただけますと幸いです。）
1. そもそも Kubernetes（k8s）って何？
Kubernetes（通称 k8s）は、コンテナ化されたアプリケーションを自動で管理・運用するための仕組みです。
Dockerなどでアプリをコンテナ化しても、
「どこで動かす？」「壊れたら？」「複数台で負荷分散は？」といった課題が残る。
→ これを全部いい感じにやってくれるのが Kubernetes。
アプリの「理想の状態（YAMLで宣言）」を書くだけで、
クラスタが自動的に 配置・復旧・スケール・公開 を行ってくれる。
2. Kubernetesの押さえておくべき基本概念
ハンズオンで出てきた単語を中心に、k8sの基本的な概念のイメージをまずは押さえます。
| 用語 | 役割・イメージ | 一言で言うと |
|---|---|---|
| Pod | コンテナを1つ以上まとめた最小実行単位。Kubernetesが直接管理する。アプリケーションの実行主体。 | コンテナの“入れ物” |
| Deployment | Podを指定数動かし続けるための管理者。自動復旧や更新も担当。「なにを、どのように動かすのか」を定義。 | アプリの運営管理担当 |
| Service | 変動するPodの前に固定の入口（IP/DNS）を作る。k8sの機能でロードバランサを作成したりする | アプリの入口 |
| Namespace | クラスタ内の論理的な区画。環境やチームごとに分離できる。 | 部屋・箱 |
| Node | 実際にPodが動くサーバ（EC2など）。Kubernetesが自動でスケジュール。 | 実行ホスト |
| Cluster | Kubernetes全体の集合体。複数のNodeで構成。 | 管理対象全体 |
| LoadBalancer | EKSの場合、Service type=LoadBalancer を作るとAWSのLBを自動生成。 |
外部公開の入口 |
図に起こすと、以下の様なイメージになる（と理解）
Kubernetes主要コンポーネントの関係図
3. ハンズオンで何をやったのか振り返る
Nginx を外部公開してみる
ここでは、kubectl コマンドを使って Deployment を作成 → Service を外部公開 → 実際にアクセス という一連の流れを理解していきます。
Step1. Nginx の Deployment を作成する
まず以下コマンドでnginx という Deployment を作成します。
kubectl create deployment nginx --image=nginx
--image=nginx によって、公式の Nginx コンテナイメージを使用した Pod が起動します。
今回は Deployment の設定（replicas や port 等）を指定していないため、Kubernetes がデフォルト値で自動生成します。
📄 Deployment の設定ファイル（YAML）が欲しい場合
実際にクラスタに作られている Deployment の内容は、以下のコマンドで確認・出力できます。
kubectl get deployment nginx -o yaml
Step2. Deployment を外部公開する（Service を作成）
続いて、以下コマンドでServiceを作成していきます。
kubectl expose deployment nginx --type=LoadBalancer --port=80 --target-port=80
🔍 kubectl expose は何をするコマンド？
kubectl expose は、Deployment や Pod に対して Service を作成し、通信の入口を作るコマンド。
これによって以下が実現します。
-
Pod の前に 安定した入口（仮想IP / DNS）ができる
-
Pod の IP が変わっても Service が自動ルーティング
-
type=LoadBalancer の場合、EKS が AWS のロードバランサ（ELB/NLB）を自動作成する
🔸 --type=LoadBalancer の意味（Service の種類）
| TYPE | 説明 | 主な用途 |
|---|---|---|
| ClusterIP（既定） | クラスタ内専用の入口 | 内部通信（フロント→バック） |
| NodePort | ノードの固定ポートを外部に開ける | Nodeに直接アクセス？？ |
| LoadBalancer | クラウドLBを自動作成し外部公開 | 今回のシナリオ |
| ExternalName | 外部のドメインを CNAME で返すだけ | 外部DBやSaaSへの名前解決?? |
今回は LoadBalancer を指定したため、
AWS 上で自動的にロードバランサが作成され、インターネットからアクセス可能になります。
🔸 --port と --target-port の違い
オプション 意味
| オプション | 意味 |
|---|---|
| --port=80 | Service（ロードバランサ）の受け口。外部からのリクエストはここに届く。 |
| --target-port=80 | 実際に Pod（コンテナ）が待ち受けるポート。Service→Pod の転送先。 |
今回は nginx が 80 番ポートで待ち受けているため、両方 80 を指定しています。
作成した Service の状態を確認してみます。
kubectl get svc nginx
出力例
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.100.0.1 <none> 443/TCP 22h
nginx LoadBalancer 10.100.72.213 xxxxxxxxxxx.ap-northeast-1.elb.amazonaws.com 80:31170/TCP 16s
EXTERNAL-IP = xxxxxxxxxxxx.elb.ap-northeast-1.amazonaws.com
→ ここがロードバランサの DNS 名。
この DNS へアクセスすると Pod（nginx）に到達してアプリケーションにアクセス出来ます。
4. まとめ
-
kubectl create deployment で nginx の Deployment を作成
-
kubectl expose --type=LoadBalancer で外部公開用の Service を作成
-
EKS が AWS のロードバランサを自動作成する
-
kubectl get svc の EXTERNAL-IP にアクセスすれば、インターネットから到達可能
次の記事では、ECRイメージをデプロイする手順を振り返りながら、これらの背後で動く Kubernetes の仕組みをもう少し深掘りしていきます。