Go to Qiita Advent Calendar Top
LoginSignup
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@Tamago_Koppepan

1からのWEBサーバ作り Kubernetesを使ったコンテナ管理

Posted at

1からのWEBサーバ作り Kubernetesを使ったコンテナ管理

はじめに

この記事ではKubernetesを使ってコンテナの管理を行います。

前回はApacheをDocker上で動作させました。

前回の記事はこちらです。

この記事はシリーズの第7回です。シリーズ全体の目次は以下からご覧ください。
シリーズ目次: 1からのWEBサーバ作り - 完全ガイドシリーズ

1. 目的と完成条件の定義

1.1 目的

Kubernetesは自動化による運用の効率化、スケーリングの自動化、リソースの最適配置などの役割があります。かつては、サーバー1台ごとにエンジニアが手作業で設定や監視を行っていました。しかし、現代のWEBサービスは規模が巨大で、更新頻度も高いため、手作業では追いつきません。「インフラ管理の複雑さを解消し、エンジニアが『サービス開発』そのものに集中できるようにする」ことがKubernetesの目的です。

1.2 完成条件

以下の条件をすべて満たすこと:

No 検証項目 合格条件
1 基本動作(Deployment & Service) マニフェスト(apply)適用後、ServiceのIP（またはlocalhost）へアクセスし、トップページが正常に表示される
2 自動復旧(Self-Healing) kubectl delete podコマンドで稼働中のPodを強制削除した後、即座に新しいPodが自動生成され、Running状態になる
3 スケーリング(Scaling) replicas（レプリカ数）を「3」に変更した際、Podが3つに増え、ロードバランサーが通信を適切に振り分ける
4 無停止更新(Rolling Update) コンテナイメージのバージョンを更新（例: v1→v2）した際、サービスが中断することなく新しいバージョンへ切り替わる
5 設定の分離(ConfigMap) コンテナを作り直すことなく、ConfigMap（設定情報）を書き換えてPodを再起動するだけで、Webサイトの文言や設定が反映される

2. 前提条件

2.1 環境情報

  • 対象OS: Ubuntu 24.04.3 LTS
  • CPU: AMD RYZEN 7 7840HS
  • 実行環境: ローカルマシン(物理サーバ)
  • ネットワーク: ローカルネットワーク(192.168.x.x)

2.2 必要なマシン構成

  • サーバマシン: Ubuntu 24.04.3 LTS がインストール済み
  • メモリ: 最低2GB以上推奨（Kubernetes実行には4GB以上推奨）
  • ディスク: 20GB以上の空き容量

2.3 必要なソフトウェア

  • Docker: 第5回の記事でインストール済み
  • Docker Compose: docker composeコマンドが使用可能であること
  • kubectl: Kubernetesのコマンドラインツール（本記事でインストール）
  • Minikube: ローカルKubernetes環境（本記事でインストール）

3. Kubernetesの基本概念

Kubernetesを理解するために、主要な概念を押さえておきましょう。

3.1 主要コンポーネント

コンポーネント 説明
Pod コンテナを実行する最小単位。1つ以上のコンテナで構成される
Deployment Podの複製を管理し、宣言的な更新を提供する
Service Podへの安定したネットワークアクセスを提供する
ConfigMap 設定情報をPodから分離して管理する
Node Podが実行される物理マシンまたは仮想マシン
Cluster 複数のNodeで構成されるKubernetes環境全体

Dockerとの違い
Dockerは単一のコンテナを管理するのに対し、Kubernetesは複数のコンテナを複数のサーバにまたがって管理します。Dockerが「家」なら、Kubernetesは「マンション管理システム」です。

3.2 宣言的管理

Kubernetesでは「あるべき状態」をYAMLファイル（マニフェスト）で宣言し、Kubernetesがその状態を維持します。

# 例: 「Apacheコンテナを3つ常に動かす」と宣言
replicas: 3

これにより、1つのPodが停止しても、Kubernetesが自動的に新しいPodを起動します。

4. 事前準備

4.1 Dockerのバージョン確認

まず、Dockerが正しくインストールされているか確認します。

docker --version

期待される出力例:

Docker version 24.0.7, build afdd53b

4.2 作業ディレクトリの作成

プロジェクト用のディレクトリを作成します。

mkdir -p ~/kubernetes-apache
cd ~/kubernetes-apache

4.3 SWP領域の削除

SWP(仮想メモリ)をオフにします。

sudo swapoff -a

4.4 kubectlのインストール

kubectlは、Kubernetesクラスタを操作するためのコマンドラインツールです。

# 最新版のkubectlをダウンロード
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"

# 実行権限を付与
chmod +x kubectl

# システムパスに移動
sudo mv kubectl /usr/local/bin/

# バージョン確認
kubectl version --client

期待される出力例:

Client Version: v1.31.0

エラーが出た場合、aptの管理下でインストールしたい場合
curl: command not foundと表示された場合は、以下のコマンドでcurlをインストールしてください。

# Kubernetes公式リポジトリを追加（Ubuntu 24.04）
sudo apt update
sudo apt install -y apt-transport-https ca-certificates curl gpg

curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.29/deb/Release.key | \
  sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg

echo "deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] \
  https://pkgs.k8s.io/core:/stable:/v1.29/deb/ /" | \
  sudo tee /etc/apt/sources.list.d/kubernetes.list

#kubectl をインストール
sudo apt update
sudo apt install -y kubectl

#(推奨)aptが自動でバージョンアップしないようにする
sudo apt-mark hold kubectl

エラーなく終わったら、以下のコマンドでバージョンを確認し、正しくインストールできたか確認してください。

kubectl version --client

4.4 Minikubeのインストール

Minikubeは、ローカル環境で単一ノードのKubernetesクラスタを簡単に構築できるツールです。

# Minikubeのダウンロード
curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64

# インストール
sudo install minikube-linux-amd64 /usr/local/bin/minikube

# バージョン確認
minikube version

期待される出力例:

minikube version: v1.33.1
commit: 5883c09216182566a63dff4c326a6fc9ed2982ff

5. Minikubeクラスタの起動

5.1 Minikubeの起動

# Minikubeクラスタを起動
minikube start --driver=docker

--driver=dockerオプション
このオプションは、MinikubeがDockerをバックエンドとして使用することを指定します。他にもvirtualboxやkvm2などのドライバを選択できますが、今回はDockerを使用します。

期待される出力例:

😄  minikube v1.33.1 on Ubuntu 24.04
✨  Using the docker driver based on user configuration
👍  Starting control plane node minikube in cluster minikube
🚜  Pulling base image ...
🔥  Creating docker container (CPUs=2, Memory=2200MB) ...
🐳  Preparing Kubernetes v1.30.0 on Docker 26.0.1 ...
🔗  Configuring bridge CNI (Container Networking Interface) ...
🔎  Verifying Kubernetes components...
🌟  Enabled addons: storage-provisioner, default-storageclass
🏄  Done! kubectl is now configured to use "minikube" cluster and "default" namespace by default

メモリ不足エラーが出た場合
メモリが不足している場合、以下のコマンドでメモリ割り当てを調整してください。

minikube start --driver=docker --memory=4096 --cpus=2

5.2 クラスタの状態確認

# クラスタの状態を確認
minikube status

期待される出力例:

minikube
type: Control Plane
host: Running
kubelet: Running
apiserver: Running
kubeconfig: Configured

# Nodeの状態を確認
kubectl get nodes

期待される出力例:

NAME       STATUS   ROLES           AGE   VERSION
minikube   Ready    control-plane   1m    v1.30.0

6. カスタムApacheイメージの作成

Kubernetesで使用するために、カスタムHTMLを含むApacheイメージを作成します。

6.1 HTMLファイルの作成

cd ~/kubernetes-apache
mkdir -p public-html

cat > public-html/index.html << 'EOF'
<!DOCTYPE html>
<html lang="ja">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>K8s Apache v1</title>
    <style>
        body {
            font-family: system-ui, sans-serif;
            display: grid;
            place-content: center;
            height: 100vh;
            margin: 0;
            background: #f0f4f8;
            color: #333;
            text-align: center;
        }
        h1 { margin: 0; color: #007bff; }
        p { color: #666; margin-top: 0.5rem; }
    </style>
</head>
<body>
    <div>
        <h1>Version 1.0</h1>
        <p>Apache on Kubernetes works!</p>
    </div>
</body>
</html>
EOF

6.2 Dockerfileの作成

cat > Dockerfile << 'EOF'
FROM httpd:2.4

# メンテナ情報
LABEL maintainer="your-email@example.com"
LABEL version="1.0"

# カスタムHTMLをコピー
COPY ./public-html/ /usr/local/apache2/htdocs/

# ポート80を公開
EXPOSE 80

# ヘルスチェック
HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \
  CMD wget --quiet --tries=1 --spider http://localhost/ || exit 1

# デフォルトコマンド
CMD ["httpd-foreground"]
EOF

6.3 イメージのビルドとMinikubeへの登録

Minikubeは独自のDockerデーモンを持っているため、イメージをMinikube内でビルドする必要があります。

# MinikubeのDockerデーモンを使用する設定
eval $(minikube docker-env)

# イメージをビルド
docker build -t my-apache:v1 .

# イメージが作成されたか確認
docker images | grep my-apache

期待される出力例:

my-apache    v1    abc123def456   1 minute ago   145MB

eval $(minikube docker-env)の意味
このコマンドは、現在のシェルでMinikube内のDockerデーモンを使用するように環境変数を設定します。これにより、ローカルでビルドしたイメージがMinikube内で直接利用可能になります。

7. Kubernetesマニフェストの作成

7.1 Deploymentマニフェストの作成

Deploymentは、Podの複製を管理し、宣言的な更新を提供します。

cat > deployment.yaml << 'EOF'
apiVersion: apps/v1
kind: Deployment
metadata:
  name: apache-deployment
  labels:
    app: apache
spec:
  replicas: 1
  selector:
    matchLabels:
      app: apache
  template:
    metadata:
      labels:
        app: apache
    spec:
      containers:
      - name: apache
        image: my-apache:v1
        imagePullPolicy: Never  # ローカルイメージを使用
        ports:
        - containerPort: 80
        resources:
          requests:
            memory: "128Mi"
            cpu: "100m"
          limits:
            memory: "256Mi"
            cpu: "200m"
        livenessProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 10
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 5
          periodSeconds: 5
EOF

主要な設定項目の説明

項目 説明
replicas: 1 Podを1つ起動する
imagePullPolicy: Never ローカルイメージを使用（Dockerレジストリから取得しない）
resources CPU・メモリの制限
livenessProbe Podが正常に動作しているかチェック
readinessProbe Podがトラフィックを受け入れる準備ができているかチェック

7.2 Serviceマニフェストの作成

ServiceはPodへの安定したネットワークアクセスを提供します。

cat > service.yaml << 'EOF'
apiVersion: v1
kind: Service
metadata:
  name: apache-service
spec:
  type: NodePort
  selector:
    app: apache
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
      nodePort: 30080
EOF

Serviceのタイプ

タイプ 説明
ClusterIP クラスタ内部からのみアクセス可能（デフォルト）
NodePort 各NodeのIPアドレスとポート経由でアクセス可能
LoadBalancer クラウドプロバイダのロードバランサーを使用

8. Kubernetesへのデプロイ

8.1 マニフェストの適用

# Deploymentを適用
kubectl apply -f deployment.yaml

# Serviceを適用
kubectl apply -f service.yaml

期待される出力例:

deployment.apps/apache-deployment created
service/apache-service created

8.2 デプロイ状態の確認

# Deploymentの状態確認
kubectl get deployments

# Podの状態確認
kubectl get pods

# Serviceの状態確認
kubectl get services

期待される出力例:

NAME                 READY   UP-TO-DATE   AVAILABLE   AGE
apache-deployment    1/1     1            1           30s

NAME                                  READY   STATUS    RESTARTS   AGE
apache-deployment-5d7b8c9f4d-xyz12   1/1     Running   0          30s

NAME             TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
apache-service   NodePort    10.96.123.45    <none>        80:30080/TCP   30s

8.3 詳細な状態確認

# Deploymentの詳細情報
kubectl describe deployment apache-deployment

# Podの詳細情報
kubectl describe pod apache-deployment-5d7b8c9f4d-xyz12

# Podのログ確認
kubectl logs apache-deployment-5d7b8c9f4d-xyz12

9. 動作確認と検証

9.1 検証1: 基本動作(Deployment & Service)

# MinikubeのIPアドレスを取得
minikube ip

期待される出力例:

192.168.49.2

Webブラウザまたはcurlコマンドでアクセスします:

# curlでアクセス
curl http://$(minikube ip):30080

# またはブラウザで開く
minikube service apache-service

確認ポイント: カスタムHTMLの内容が表示される

image.png

9.2 検証2: 自動復旧(Self-Healing)

Podを強制削除して、自動復旧を確認します。

# 現在のPod名を取得
POD_NAME=$(kubectl get pods -l app=apache -o jsonpath='{.items[0].metadata.name}')
echo "削除するPod: $POD_NAME"

# Podを強制削除
kubectl delete pod $POD_NAME

# リアルタイムでPodの状態を監視
kubectl get pods -l app=apache -w

期待される動作:

  1. PodがTerminating状態になる
  2. 新しいPodが自動的に作成される（ContainerCreating）
  3. 新しいPodがRunning状態になる

確認ポイント: 10秒以内に新しいPodが起動する

# 新しいPodが起動したか確認
kubectl get pods -l app=apache

期待される出力例:

NAME                                  READY   STATUS    RESTARTS   AGE
apache-deployment-5d7b8c9f4d-abc34   1/1     Running   0          15s

kucgbUe5mXJ4lK11765415156_1765415213.png

9.3 検証3: スケーリング(Scaling)

レプリカ数を3に増やして、ロードバランシングを確認します。

# レプリカ数を3に変更
kubectl scale deployment apache-deployment --replicas=3

# Podの状態を確認
kubectl get pods -l app=apache

期待される出力例:

NAME                                  READY   STATUS    RESTARTS   AGE
apache-deployment-5d7b8c9f4d-abc34   1/1     Running   0          2m
apache-deployment-5d7b8c9f4d-def56   1/1     Running   0          10s
apache-deployment-5d7b8c9f4d-ghi78   1/1     Running   0          10s

ロードバランシングの確認:

kubectl execの動作について
kubectl exec deployment/apache-deploymentは、Deployment内の特定の1つのPodに接続するため、同じPod名が繰り返し表示されます。これは正常な動作です。
ロードバランシングを確認するには、Service経由でアクセスする必要があります。

方法1: 各Podのログでアクセスを確認

別ターミナルでログを監視:

# 各Podのアクセスログをリアルタイムで監視
kubectl logs -l app=apache --tail=10 --prefix=true -f

メインターミナルで複数回アクセス:

# Service経由で20回アクセス
for i in {1..20}; do
  curl -s http://$(minikube ip):30080 > /dev/null
  echo "Request $i sent"
  sleep 0.5
done

期待される結果: 3つのPodのログに、ほぼ均等にアクセスログが記録される
0Pu7AkM1eAGPmLD1765415967_1765415980.png

方法2: Podのメトリクスを確認

# 各Podのネットワークトラフィックを確認
kubectl top pods -l app=apache

9.4 検証4: 無停止更新(Rolling Update)

新しいバージョンのイメージを作成して、ローリングアップデートを実行します。

バージョン2のHTMLを作成

cat > public-html/index.html << 'EOF'
<!DOCTYPE html>
<html lang="ja">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>K8s Apache v2</title>
    <style>
        body {
            font-family: system-ui, sans-serif;
            display: grid;
            place-content: center;
            height: 100vh;
            margin: 0;
            background: #fff5f5;
            color: #333;
            text-align: center;
        }
        h1 { margin: 0; color: #e53e3e; }
        p { color: #666; margin-top: 0.5rem; }
        .tag {
            background: #e53e3e;
            color: white;
            font-size: 0.8rem;
            padding: 4px 10px;
            border-radius: 99px;
            font-weight: bold;
            display: inline-block;
            margin-bottom: 10px;
        }
    </style>
</head>
<body>
    <div>
        <div class="tag">Version 2.0</div>
        <h1>Update Success!</h1>
        <p>Rolling update completed smoothly.</p>
    </div>
</body>
</html>
EOF

バージョン2のイメージをビルド

# MinikubeのDockerデーモンを使用
eval $(minikube docker-env)

# バージョン2をビルド
docker build -t my-apache:v2 .

# イメージが作成されたか確認
docker images | grep my-apache

Deploymentを更新

# イメージを更新
kubectl set image deployment/apache-deployment apache=my-apache:v2

# ローリングアップデートの進行状況を監視
kubectl rollout status deployment/apache-deployment

期待される出力例:

Waiting for deployment "apache-deployment" rollout to finish: 1 out of 3 new replicas have been updated...
Waiting for deployment "apache-deployment" rollout to finish: 2 out of 3 new replicas have been updated...
Waiting for deployment "apache-deployment" rollout to finish: 1 old replicas are pending termination...
deployment "apache-deployment" successfully rolled out

# 更新履歴を確認
kubectl rollout history deployment/apache-deployment

確認ポイント: サービスが停止することなく、新しいバージョンに切り替わる

# バージョン2のページを確認
curl http://$(minikube ip):30080 | grep "Version 2.0"

image.png

ローリングアップデートの仕組み
Kubernetesは、新しいバージョンのPodを段階的に作成し、古いバージョンのPodを段階的に削除します。これにより、サービスが中断することなく更新が完了します。

ロールバックの確認（任意）

# バージョン1にロールバック
kubectl rollout undo deployment/apache-deployment

# ロールバックの進行状況を確認
kubectl rollout status deployment/apache-deployment

# バージョン1に戻ったか確認
curl http://$(minikube ip):30080 | grep "Version 1.0"

9.5 検証5: 設定の分離(ConfigMap)

ConfigMapを使って、コンテナを再ビルドせずに設定を変更します。

ConfigMapの作成

cat > configmap.yaml << 'EOF'
apiVersion: v1
kind: ConfigMap
metadata:
  name: apache-config
data:
  message: "Hello from ConfigMap!"
  environment: "Production"
EOF

# ConfigMapを適用
kubectl apply -f configmap.yaml

# ConfigMapの内容を確認
kubectl get configmap apache-config -o yaml

Deploymentを修正してConfigMapを使用

cat > deployment-with-configmap.yaml << 'EOF'
apiVersion: apps/v1
kind: Deployment
metadata:
  name: apache-deployment
  labels:
    app: apache
spec:
  replicas: 3
  selector:
    matchLabels:
      app: apache
  template:
    metadata:
      labels:
        app: apache
    spec:
      containers:
      - name: apache
        image: my-apache:v2
        imagePullPolicy: Never
        ports:
        - containerPort: 80
        env:
        - name: MESSAGE
          valueFrom:
            configMapKeyRef:
              name: apache-config
              key: message
        - name: ENVIRONMENT
          valueFrom:
            configMapKeyRef:
              name: apache-config
              key: environment
        resources:
          requests:
            memory: "128Mi"
            cpu: "100m"
          limits:
            memory: "256Mi"
            cpu: "200m"
        livenessProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 10
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 5
          periodSeconds: 5
EOF

# Deploymentを更新
kubectl apply -f deployment-with-configmap.yaml

ConfigMapの値を確認

# Podに入って環境変数を確認
POD_NAME=$(kubectl get pods -l app=apache -o jsonpath='{.items[0].metadata.name}')
kubectl exec -it $POD_NAME -- env | grep -E "MESSAGE|ENVIRONMENT"

期待される出力例:

MESSAGE=Hello from ConfigMap!
ENVIRONMENT=Production

ConfigMapを更新

# ConfigMapの値を変更
kubectl edit configmap apache-config

viエディタが開くので、以下のように変更します:

data:
-  message: "Hello from ConfigMap!"
+  message: "Updated message from ConfigMap!"
-  environment: "Production"
+  environment: "Staging"

# Podを再起動して変更を反映
kubectl rollout restart deployment/apache-deployment

# 再起動の進行状況を確認
kubectl rollout status deployment/apache-deployment

# 変更が反映されたか確認
POD_NAME=$(kubectl get pods -l app=apache -o jsonpath='{.items[0].metadata.name}')
kubectl exec -it $POD_NAME -- env | grep -E "MESSAGE|ENVIRONMENT"

期待される出力例:

MESSAGE=Updated message from ConfigMap!
ENVIRONMENT=Staging

確認ポイント: コンテナイメージを再ビルドすることなく、設定が変更される

image.png

10. トラブルシューティング

10.1 Podが起動しない

症状: PodがPendingまたはImagePullBackOff状態のまま

# Podの詳細を確認
kubectl describe pod <pod-name>

原因と対処法:

原因 対処法
イメージが見つからない imagePullPolicy: Neverが設定されているか確認。eval $(minikube docker-env)を実行してからイメージをビルドする
リソース不足 kubectl describe node minikubeでリソース使用状況を確認。必要に応じてMinikubeのメモリを増やす
権限エラー SecurityContextの設定を確認

10.2 Serviceに接続できない

症状: curl http://$(minikube ip):30080が失敗する

対処法:

# Serviceの状態を確認
kubectl get svc apache-service

# Endpointsが設定されているか確認
kubectl get endpoints apache-service

# Podが正常に動作しているか確認
kubectl get pods -l app=apache

原因:

  • PodがRunning状態でない
  • Serviceのセレクタとpodのラベルが一致していない
  • ファイアウォールがポートをブロックしている

10.3 ローリングアップデートが失敗する

症状: kubectl rollout statusが完了しない

# ローリングアップデートの状態を確認
kubectl rollout status deployment/apache-deployment

# Podのイベントを確認
kubectl get events --sort-by='.lastTimestamp'

対処法:

# ロールバックを実行
kubectl rollout undo deployment/apache-deployment

# 問題を修正してから再度デプロイ
kubectl apply -f deployment.yaml

10.4 MinikubeのDockerデーモンに接続できない

症状: eval $(minikube docker-env)後、Dockerコマンドが失敗する

対処法:

# Minikubeが起動しているか確認
minikube status

# Minikubeを再起動
minikube stop
minikube start --driver=docker

# 再度環境変数を設定
eval $(minikube docker-env)

10.5 ConfigMapの変更が反映されない

症状: ConfigMapを更新してもPodに反映されない

対処法:

# ConfigMapが更新されているか確認
kubectl get configmap apache-config -o yaml

# Podを再起動
kubectl rollout restart deployment/apache-deployment

# または、Podを強制削除して自動再生成
kubectl delete pods -l app=apache

ConfigMapの制限
ConfigMapを環境変数として使用している場合、ConfigMapを更新してもPodは自動的に再起動しません。kubectl rollout restartを実行する必要があります。

11. セキュリティ配慮

11.1 リソース制限の設定

resources:
  requests:
    memory: "128Mi"
    cpu: "100m"
  limits:
    memory: "256Mi"
    cpu: "200m"

目的: Podがクラスタ全体のリソースを使い果たすのを防ぐ

11.2 ReadOnly Root Filesystem

securityContext:
  readOnlyRootFilesystem: true
  runAsNonRoot: true
  runAsUser: 1000

目的: コンテナのルートファイルシステムを読み取り専用にして、攻撃者がファイルを改ざんするのを防ぐ

11.3 NetworkPolicyの設定

cat > network-policy.yaml << 'EOF'
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: apache-network-policy
spec:
  podSelector:
    matchLabels:
      app: apache
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 80
EOF

# NetworkPolicyを適用
kubectl apply -f network-policy.yaml

目的: 特定のPodからのみトラフィックを許可する

11.4 Secretの使用

機密情報（パスワード、APIキーなど）は、ConfigMapではなくSecretを使用します。

# Secretを作成
kubectl create secret generic apache-secret \
  --from-literal=db-password='super-secret-password'

# Secretの内容を確認（base64エンコードされている）
kubectl get secret apache-secret -o yaml

11.5 定期的な更新

# イメージを最新版に更新
kubectl set image deployment/apache-deployment apache=httpd:2.4-alpine

# セキュリティパッチを適用
sudo apt update
sudo apt upgrade -y

12. クリーンアップ

作業が完了したら、リソースをクリーンアップします。

# Deploymentを削除
kubectl delete deployment apache-deployment

# Serviceを削除
kubectl delete service apache-service

# ConfigMapを削除
kubectl delete configmap apache-config

# すべてのリソースを一度に削除
kubectl delete -f deployment.yaml -f service.yaml -f configmap.yaml

# Minikubeクラスタを停止
minikube stop

# Minikubeクラスタを完全に削除（任意）
minikube delete

13. まとめ

この記事では、Kubernetesを使ってコンテナを管理する方法を学びました。

重要なポイント:

  • Kubernetesは宣言的管理により「あるべき状態」を維持する
  • Self-Healing機能でPodが自動復旧する
  • スケーリングによりトラフィックに応じてPodを増減できる
  • ローリングアップデートで無停止更新が可能
  • ConfigMapで設定をコードから分離できる

Dockerとの比較:

項目 Docker Kubernetes
スケール 単一ホスト 複数ホストのクラスタ
自動復旧 ✗ ✓
ロードバランシング 手動設定 自動
無停止更新 難しい 簡単
設定管理 環境変数/.env ConfigMap/Secret

14. 参考資料

付録: 完全な設定ファイル一式

A. ディレクトリ構造

kubernetes-apache/
├── Dockerfile
├── deployment.yaml
├── service.yaml
├── configmap.yaml
├── deployment-with-configmap.yaml
├── network-policy.yaml
└── public-html/
    └── index.html

B. deployment.yaml（完全版）

apiVersion: apps/v1
kind: Deployment
metadata:
  name: apache-deployment
  labels:
    app: apache
spec:
  replicas: 1
  selector:
    matchLabels:
      app: apache
  template:
    metadata:
      labels:
        app: apache
    spec:
      containers:
      - name: apache
        image: my-apache:v1
        imagePullPolicy: Never
        ports:
        - containerPort: 80
        resources:
          requests:
            memory: "128Mi"
            cpu: "100m"
          limits:
            memory: "256Mi"
            cpu: "200m"
        livenessProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 10
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 5
          periodSeconds: 5

C. service.yaml（完全版）

apiVersion: v1
kind: Service
metadata:
  name: apache-service
spec:
  type: NodePort
  selector:
    app: apache
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
      nodePort: 30080

D. configmap.yaml（完全版）

apiVersion: v1
kind: ConfigMap
metadata:
  name: apache-config
data:
  message: "Hello from ConfigMap!"
  environment: "Production"

E. よく使うkubectlコマンド一覧

コマンド 説明
kubectl get pods Pod一覧を表示
kubectl get deployments Deployment一覧を表示
kubectl get services Service一覧を表示
kubectl describe pod <pod-name> Podの詳細情報を表示
kubectl logs <pod-name> Podのログを表示
kubectl exec -it <pod-name> -- /bin/bash Podにシェルで接続
kubectl apply -f <file.yaml> マニフェストを適用
kubectl delete -f <file.yaml> マニフェストで定義されたリソースを削除
kubectl scale deployment <name> --replicas=<num> レプリカ数を変更
kubectl rollout status deployment/<name> ローリングアップデートの進行状況を確認
kubectl rollout undo deployment/<name> ローリングアップデートをロールバック

以上で、Kubernetesを使ったコンテナ管理の手順は完了です。次回以降は、より高度なKubernetesの機能や、本番環境での運用について学んでいきます。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?