Contents
Kubernetesクラスター構築の概要と目的
Kubernetesを実環境で運用するには、信頼性の高いクラスター構築が不可欠です。本記事では、kubeadmを用いて最小限なプロダクション環境を構築する手順を解説します。特にUbuntu 22.04を選択することで、Linuxベースの安定性と最新のパッケージ管理が得られることから、DevOpsエンジニアやシステム管理者にとって実務に即した選択肢となります。
kubeadm選択の理由
kubeadmはKubernetes公式ツールであり、手順が明確で初期設定が簡潔な点が特徴です。また、プロダクション環境でも動作する最小限な構成が可能であるため、学習や本番導入の両方に適しています。
Ubuntu 22.04での環境構築の特徴
Ubuntu 22.04はLTS（長期サポート）バージョンであり、セキュリティアップデートが5年間提供される点で信頼性が高いです。さらに、カーネルの最新版やネットワークスタックが整っており、CalicoなどのCNIプラグインと相性も良好です。
クラスター構成設計の基本概念
Kubernetesクラスターを構築する際には、ノード間の役割分担やコントロールプレーンの理解が重要です。本セクションでは、クラスター全体のアーキテクチャと主要コンポーネントについて解説します。
マスターノードとワーカーノードの役割
Kubernetesクラスターはマスターノード（コントロールプレーンノード）とワーカーノードから成り立ちます。
- マスターノード: クラスター全体を管理する中心的な存在で、API Serverやetcdなどのコンポーネントが配置されます。
- ワーカーノード: アプリケーションコンテナを実行し、マスターノードの指示に従って稼働します。
以下に役割を比較表形式で示します：
| 項目 | マスターノード | ウォーカーノード |
|---|---|---|
| 主要機能 | API処理、スケジューリング | コンテナの実行 |
| コンポーネント | API Server, etcd, Scheduler | kubelet, kube-proxy |
| セキュリティリスク | 高い（攻撃面が広い） | 低い（マスターと分離可能） |
コントロールプレーンの構成要素
コントロールプレーンはクラスターの「脳」となり、以下のコンポーネントで構成されます。
- API Server: クラスター内の全ての通信を処理する中心となるサーバーです。外部からのリクエストを受けて、他のコンポーネントに命令を伝えます。
- etcd: クラスター全体の状態（構成やレプリカ情報など）を永続的に保存する分散型データベースです。
- Scheduler: ワーカーノードに適したリソースを選定し、コンテナを配置します。
blockquote
これらのコンポーネントは、クラスターの可用性やスケール性を支える基盤となるため、十分な理解が必要です。
kubeadmによる初期設定フロー
Ubuntu 22.04上でkubeadmを用いてクラスターを構築するには、以下の手順に従います。事前準備からクラスターの初期化までを具体的に解説します。
OSベースの環境整備
クラスター構築の前提として、以下の設定が必要です：
- SSHアクセス設定: マスターノードとワーカーノード間でSSH通信が可能であること。
- カーネルモジュールの確認:
br_netfilterやip_vsなどのモジュールが有効になっていることを確認する。 - swap無効化: Kubernetesはswapをサポートしていないため、
/etc/default/grubでGRUB_CMDLINE_LINUX+="swapoff"を設定し、update-grubを実行します。
kubeadmのインストール手順
Ubuntu 22.04では、以下のようにkubeadmをインストールできます：
-
APTリポジトリの追加:
bash
apt-get update && apt-get install -y apt-transport-https curl
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
cat <<EOF >/etc/apt/sources.list.d/kubernetes.list
deb http://apt.kubernetes.io/ kubernetes-jammy main
EOF -
パッケージのインストール:
bash
apt-get update
apt-get install -y kubelet kubeadm kubectl -
バージョン確認:
bash
kubeadm version
# 出力例: kubeadm version: &version.Info{Major:"1", Minor:"27", GitVersion:"v1.27.0"}
クラスター初期化コマンド実行
マスターノードで以下のようにクラスターを初期化します：
|
1 2 |
sudo kubeadm init --pod-network-cidr=192.168.0.0/16 |
出力例:
|
1 2 3 4 5 6 |
[init] Using Kubernetes version: v1.27.0 [preflight] Running pre-flight checks [certs] Generating "etcd/ca" certificate and key ... The connection to the server localhost:6443 was refused - did you specify the right host or port? |
blockquote
エラーメッセージが簡潔なため、トラブルシューティングを困難にしています。kubeletサービスの状態や/etc/kubernetes/admin.confファイルの有無を確認してください。
この出力結果に従い、kubeadm joinコマンドをワーカーノードに実行させます。
CNIプラグイン（Calico）の導入方法
クラスターが構築された後は、ネットワーク機能を担うCNIプラグインの設置が必要です。本セクションでは、CalicoのHelmチャートによるインストール手順とネットワークポリシーの基本設定について解説します。
Calicoの Helm チャートによる展開
以下のように、CalicoをHelmでインストールします：
-
Helmリポジトリの追加:
bash
helm repo add projectcalico https://projectcalico.docs.tigera.io/charts
helm repo update -
チャートの展開:
bash
helm install calico projectcalico/tigera-operator --namespace calico-system --create-namespace
blockquote
--namespace calico-systemは必須です。指定がないと、デフォルト名前空間でインストールされる可能性があり、予期せぬ動作を引き起こします。
- Calicoコンポーネントの確認:
bash
kubectl get pods -n calico-system
# 出力例: NAME READY STATUS RESTARTS AGE
# calico-kube-controllers 1/1 Running 0 2m
ネットワークポリシーの基本設定
Calicoでネットワークポリシーを設定するには、YAMLファイルを作成し以下のように適用します：
|
1 2 3 4 5 6 7 8 9 10 11 12 |
apiVersion: projectcalico.org/v3 kind: NetworkPolicy metadata: name: allow-nginx spec: selector: app: nginx ingress: - action: Allow protocol: TCP port: 80 |
|
1 2 |
kubectl apply -f network-policy.yaml |
この設定により、app=nginxのポッドに対してHTTP通信を許可するネットワークポリシーが作成されます。
ノードの役割分担と拡張性確保
クラスターはマスターノード単体では限界があるため、ワーカーノードを追加することで拡張性を高めます。ここではkubeadm joinによるノード追加手順と、ラベルによるアプリケーションの制御方法を解説します。
ワーカーノードへのJOIN手順
マスターノードで生成されたkubeadm joinコマンドをワーカーノードに実行させます：
|
1 2 3 |
sudo kubeadm join 192.168.1.10:6443 --token abcdef.0123456789abcdef \ --discovery-token-ca-cert-hash sha256:1234567890abcdef... |
成功時の出力:
|
1 2 |
This node has joined the cluster |
ラベルと選択子によるアプリケーション配置制御
ノードにラベルを付与することで、特定のアプリケーションを該当ノードにのみデプロイできます。
-
ラベルの追加:
bash
kubectl label nodes worker-node-01 role=app-server -
選択子によるポッドの配置指定（Deployment例）:
yaml
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
nodeSelector:
role: app-server
このようにすることで、role=app-serverのノードにのみNginxを実行するポッドが配置されます。
クラスター検証用ポッドの起動手順
クラスター構築後は、動作確認のためにテスト用ポッドを起動します。ここではnginxポッドのデプロイメントとステータス確認の手順を具体的に示します。
nginxポッドのデプロイメント
以下のコマンドで簡単なnginxポッドを作成します：
|
1 2 |
kubectl create deployment nginx --image=nginx:latest |
出力例:
|
1 2 |
deployment.apps/nginx created |
次に、このポッドを外部からアクセスできるように、Serviceオブジェクトを定義します：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
apiVersion: v1 kind: Service metadata: name: nginx-service spec: type: NodePort ports: - port: 80 targetPort: 80 nodePort: 30000 selector: app: nginx |
blockquote
nodePortの値（例：30000）が他のサービスと競合する可能性があるため、クラスター環境に応じて別のポートを使用することを推奨します。
|
1 2 |
kubectl apply -f service.yaml |
ロギングとステータス確認
ポッドの動作を確認するには、以下のコマンドを使用します：
-
ポッド一覧:
bash
kubectl get pods
# 出力例: NAME READY STATUS RESTARTS AGE
# nginx-7df8569d84-kq2wz 1/1 Running 0 2m -
ポッドのログ取得:
bash
kubectl logs nginx-7df8569d84-kq2wz
# nginxアクセスログが表示される -
Service確認（NodePort経由）:
ブラウザやcurlで以下のURLにアクセスして、動作を検証します：
http://<マスターノードIP>:30000
blockquote
上記手順により、Kubernetesクラスターの基本的な動作が確認できます。この段階で問題なければ、実環境での導入が可能です。