1. イントロダクション
動機
アルバイトでKubernetesを使った構築をしていたので、よりノウハウ・知識を深めるためプライベートでもKubernetesを実践形式で学ぶ方法を探していました。ちょうど、1台のサーバーで運用していたポートフォリオがあったので、複数ノードでの分散運用にしたいと思い、移行してみました。
技術選定
コンテナオーケストレーションには K3s を採用しました。
K3sはリソース制約の厳しい環境向けに設計された軽量な Kubernetes ディストリビューションです。軽量でありながら CNCF認証済みのKubernetesであるため、標準の Kubernetes API がそのまま利用可能です。実務に近い環境を低リソースで構築できるため、学習と運用の両面で最適なツールだと判断しました。
ここでは割愛しますが、K3sについての詳しい記事については以下になります。
2. システムアーキテクチャー
本システムは、2台のVPSサーバを用いて構築したK3sクラスタ上で動作しています。
単一ノードで運用していた既存のポートフォリオを、可用性とスケーラビリティの向上を目的としてマルチノード構成へ移行しました。
全体構成
本構成は、シングルサーバー構成ではなく、2台のサーバを用いたマルチノード構成となっている。
- Control Planeノード(server):
www2.m0m0nga.com(SSD: 8GB) - Workerノード(agent):
www.m0m0nga.com(SSD: 4GB)
K3sを用いることで、軽量ながらも標準的なKubernetes APIを利用可能なクラスタを構築しています。
外部からのアクセスはドメイン(m0m0nga.com)を経由し、Ingress Controllerによってクラスタ内部のServiceへルーティングされます。
参考資料として、K3s公式のアーキテクチャ図を以下に示す。
本構成は、このアーキテクチャに基づき、Server(Control Plane)とAgent(Worker)を分離したマルチノード構成として構築している。
特徴
- 複数ノード構成により、Podの分散配置が可能
- ノード障害時でもPodの再スケジューリングによりサービス継続性を確保
- 軽量なK3sを採用することで、低リソース環境でもKubernetesを実用的に運用可能
- 実務に近い構成を自宅環境で再現し、学習と検証を両立
3. K3sクラスタ構築
本セクションでは、2台のVPSを用いてK3sクラスタを構築した手順について説明します。
3.1 環境
- OS:Ubuntu 24.04
- 構成:
- Server Node:www2.m0m0nga.com
- Agent Node:www.m0m0nga.com
3.2 K3sのインストール(Server)
まず、Control PlaneとなるServerノードにK3sをインストールする。
curl -sfL https://get.k3s.io | sh -
3.3 Agent登録
Agent登録するためには、Serverノードにおいてノードトークンを取得します。
以下でトークンを確認できます。
cat /var/lib/rancher/k3s/server/node-token
Agentノードにて、以下のコマンドを実行することで登録できます。
なお、K3S_TOKENには、先ほどServerノードで確認したトークンをペーストします。
# Agentノードで実行
curl -sfL https://get.k3s.io | K3S_URL=https://<SERVER_IP>:6443 K3S_TOKEN=~~~~~~~~~~~~ sh -
※ 登録時にはServerノード側のTCPポート6443番を使うので、ufw設定やパケットフィルターの設定を事前にしておきます。
3.4 ノード確認
ノードが登録されたか確認します。
Serverノードで以下を実行し、2ノード構成になっていることを確認できます。
kubectl get nodes -o wide
以下のように、ServerとAgentの両方が Ready 状態で表示されれば成功である。
結果として以下に近い状態が確認できると思います。
root@www2:~# kubectl get nodes -o wide
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
m0m0nga.com Ready worker 12d v1.34.6+k3s1 <SERVER_IP> <none> Ubuntu 24.04.4 LTS 6.8.0-106-generic containerd://2.2.2-bd1.34
www2.m0m0nga.com Ready control-plane 26d v1.34.5+k3s1 <SERVER_IP> <none> Ubuntu 24.04.1 LTS 6.8.0-1051-raspi containerd://2.1.5-k3s1
3.5 Deployment / Service / Ingress 構成
ノードが正常に登録されたことを確認できたため、実際にアプリケーションをデプロイし、クラスタが正しく動作するか確認します。
本構成ではクラスタ上でアプリケーションを公開するため、Deployment / Service / Ingressを構成しています。
本記事では詳細な実装説明は割愛しますが、以下の構成で動作しています。
deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: portfolio-deployment
spec:
replicas: 1
selector:
matchLabels:
app: portfolio
template:
metadata:
labels:
app: portfolio
spec:
containers:
- name: portfolio
image: ghcr.io/takkiiiiiiiii/portforio:v2.1
ports:
- containerPort: 80
service.yaml
apiVersion: v1
kind: Service
metadata:
name: portfolio-service
namespace: default
spec:
selector:
app: portfolio
ports:
- protocol: TCP
port: 80
targetPort: 80
type: ClusterIP
ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: portfolio-ingress
annotations:
cert-manager.io/cluster-issuer: letsencrypt-prod
traefik.ingress.kubernetes.io/router.entrypoints: websecure
traefik.ingress.kubernetes.io/router.tls: "true"
spec:
ingressClassName: traefik
tls:
- hosts:
- www2.m0m0nga.com
secretName: www2-m0m0nga-com-tls
rules:
- host: www2.m0m0nga.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: portfolio-service
port:
number: 80
補足:Ingress Controller と TLS 設定
本環境では、K3sにデフォルトで含まれるTraefikをIngress Controllerとして利用しています。
また、HTTPSによるアクセスを実現するために、cert-managerを用いてLet's EncryptからTLS証明書を自動取得する構成としています。
Ingressの設定において、以下のアノテーションを付与することで、証明書の発行と適用を自動化しています。
- cert-manager.io/cluster-issuer
- traefik.ingress.kubernetes.io/router.tls
これにより、証明書の取得・更新を手動で行う必要がなくなります。
※ cert-managerおよびClusterIssuerの詳細な設定については本記事では割愛しますが、設定する上で参考にしたものを載せておきます。
- https://engineering.konso.me/articles/k3s-ingress-tls-terminate-with-cert-manager/
- https://cert-manager.io/docs/tutorials/acme/nginx-ingress/
- http://doc.traefik.io/traefik/v3.4/user-guides/cert-manager/
4. まとめ
本記事では、K3sを用いてマルチノードのKubernetesクラスタを構築し、アプリケーションを公開する環境を構築しました。
シングルノードで運用していた環境から、Control PlaneとWorkerノードを分離した構成へ移行することで、より実務に近いインフラ構成を再現することができました。
軽量なK3sを用いることで、低リソース環境でも実用的なKubernetesクラスタを構築できる点は非常に有用であり、実践的な学習に適していると感じました。
5. 展望
現状は2ノード構成で運用しているが、可用性の観点ではまだ十分とは言えません。
今後はWorkerノードの追加を行い、Podの分散配置をさらに進めることで、単一ノード障害時の影響を最小化できる構成へ改善していきたいと考えています。
また、監視やログ収集の導入や、CI/CDとの連携を行い、より実運用に近い環境へ発展させていければと思っています。