03-5946-8400
HOME
目次
Kubernetes マニフェストの概要、基本設定、オプション設定、デプロイ、管理方法について
Kubernetes マニフェストは、 Kubernetes の構成と設定を定義する機能です。本記事では、マニフェストについて概要、構造、利用方法、管理方法について解説します。
1. Kubernetesマニフェストとは
マニフェストは、 Kubernetes クラスタ上で実行されるリソースの構成と設定を定義するための YAML または JSON 形式のファイルです。
マニフェストファイルを使用してオブジェクトを作成することで、インフラのコード化（ IaC ： Infrastructure as Code ）を実現することができます。
マニフェストファイルの基本構造
基本的なマニフェストファイルの構造を解説します。ファイルは YAML （ Yet Another Markup Language ） 形式で記述されたものを紹介します。 YAML とは人が判読しやすいプログラミング言語として設定ファイルの記述によく使用されます。
APIバージョンと種別 （kind）
マニフェストの先頭には、 Kubernetes API のバージョンと定義するリソースの種別を指定します。これにより、 Kubernetes がどのリソースを操作するかが判断されます。
例えば、 apiVersion: v1 および kind: Pod は、 v1 の API バージョンを使用して Pod を定義していることを示します。
apiVersion: v1 kind: Pod
メタデータ （metadata)
マニフェストの中には、リソースに関するメタデータが含まれます。これには名前、ラベル、アノテーションなどが含まれ、 metadata フィールドに記述されます。
metadata:
name: mypod
labels:
app: myapp
仕様 （spec）
マニフェストの本体には、リソースの具体的な構成や設定が spec フィールドに記述されます。これには Pod のコンテナ構成、 Deployment のレプリカ数、 Service のポート定義などが含まれます。
spec:
containers:
- name: mycontainer
image: nginx:latest
上記の例は Nginx の Pod の作成例です。マニフェストはこれらの要素を組み合わせ、リソースの特定の要件や設定に基づいて簡単に構成することができます。また複数のリソースを一度に定義することも可能です。
図版出典：Qiita
2. KubernetesマニフェストでのPod、Serviceの設定について
マニフェストファイルでは 基本設定以外にも、 Kubernetes において重要な Pod 、 Service も設定することができます。
マニュフェストでPodの設定
Pod の設定に必要な項目を解説します。
コンテナイメージ
Pod 内のコンテナの設定は、 spec 内の containers フィールドに記述されます。
spec:
containers:
- name: nginx-container
image: nginx:latest
この例では、 Nginx コンテナを指定したイメージ nginx:latest で起動することを示し、 name フィールドはコンテナに識別名を与えています。
ポート
Pod が公開するポートは、 spec 内の containers フィールド内の各コンテナの ports フィールドで定義できます。
spec:
containers:
- name: nginx-container
image: nginx:latest
ports:
- containerPort: 80
この例では、Nginxコンテナがポート80で公開されています。
環境変数
環境変数は、 spec 内の containers フィールド内の各コンテナの env フィールドを使用して定義することができます。
spec
containers:
- name: nginx-container
image: nginx:latest
env:
- name: MY_ENV_VARIABLE
value: "some-value"
この例では、 MY_ENV_VARIABLE という環境変数が ” some-value ” という値で設定しています。
ここまで基本的な Pod の設定項目を紹介しました。これらは基本的な要素であり、他にも Pod に関連する様々な設定要素があります。詳しくは公式ドキュメントをご参照ください。
- ※1 参考記事：
- Pod
マニュフェストでServiceの設定
Service の設定に必要な項目を解説します。 Kubernetes において、 Service は Pod 群に対するネットワークアクセスを提供するための抽象的な概念です。異なるサービスタイプ（ ClusterIP 、 NodePort 、 LoadBalancer ）の定義について解説します。
ClusterIP サービス
ClusterIPは、クラスタ内部のみからアクセス可能なサービスを定義します。このサービスはクラスタ内のポッドに内部的なIPアドレスを提供します。
apiVersion: v1
kind: Service
metadata:
name: my-clusterip-service
spec:
selector:
app: my-app
ports:
- protocol: TCP
port: 80
targetPort: 8080
この例では、my-clusterip-service というサービスを定義し、my-app ラベルが付いたポッドに対してポート80でアクセス可能にしています。
NodePort サービス
NodePort は、クラスタ内の各ノード上で指定されたポートを公開し、外部からアクセス可能なサービスを定義します。
apiVersion: v1
kind: Service
metadata:
name: my-nodeport-service
spec:
selector:
app: my-app
ports:
- protocol: TCP
port: 80
targetPort: 8080
type: NodePort
この例では、 my-nodeport-service というサービスを定義し、ノードの IP アドレスと指定したポート（ NodePort ）でアクセス可能となります。
LoadBalancer サービス
LoadBalancer は、外部のロードバランサを使用してクラスタ内のサービスにトラフィックをルーティングします。このタイプのサービスは、クラウド事業者によって提供される外部ロードバランサを使用します。
yaml
Copy code
apiVersion: v1
kind: Service
metadata:
name: my-loadbalancer-service
spec:
selector:
app: my-app
ports:
- protocol: TCP
port: 80
targetPort: 8080
type: LoadBalancer
この例では、 my-loadbalancer-service というサービスを定義し、外部からのトラフィックをクラウド事業者によって提供されるロードバランサにルーティングします。
ここまで利用頻度の高い３つサービスタイプを紹介しました。詳しくは公式ドキュメントをご参照ください。
- ※2 参考記事：
- Service
3. Kubernetesマニフェストでのデプロイ方法について
ここからは、ここまで記述したマニフェストファイルを利用したデプロイ方法を解説します。デプロイは Kubectl というコマンドラインツールを用いて行われます。
マニフェストファイルの作成
デプロイしたいマニフェストファイルを準備します。ここまで解説してきた内容が書かれたファイルをYAML形式で保存します。
マニフェストファイルの適用
作成したマニフェストファイルを Kubernetes クラスタに適用します。このとき kubectl apply コマンドを使用します。
kubectl apply -f your-manifest-file.yaml
リソースの確認
適用が完了したら、 kubectl get コマンドを使用してリソースの状態を確認します。
kubectl get pods
リソースの更新や削除
マニフェストファイルを変更した場合、再び kubectl apply を使用して変更をクラスタに適用します。ただし一部のPodの仕様変更は kubectl apply では反映されないものがあるので注意が必要です。
kubectl delete -f your-manifest-file.yaml
これにより、クラスタから指定したリソースが削除されます。
- ※3 参考記事：
- コマンドラインツール(kubectl)
4. Kubernetesマニフェストの管理について
本章ではコマンドラインの管理ツールである kubectl と比較し、メリット、デメリットを解説します。
マニフェストファイルのメリット
ディスクに永続化された設定
マニフェストファイルは設定やリソースの状態を永続的に保存できます。これにより、設定の履歴を管理し、変更をトラッキングすることも可能です。kubectl では都度の反映でトラッキングには不向きです。
IaC （Infrastructure as Code） の一部
マニフェストは IaC の一環と見なされ、ソースコードと同じくバージョン管理ができます。変更はコードレビューを通じて確認でき、再現性と一貫性を確保することができます。
マニフェストファイルのデメリット
手動管理の必要性
マニフェストファイルを作成および管理するには手動の作業が必要であり、手間がかかるのと合わせ、エラーが生じる可能性もあります。kubectl では都度のコマンド発行なので素早く結果を取得できます。
即時反映が難しい
マニフェストファイルを変更しても、それがクラスタに即座に反映されないことがあります。反映には手動での kubectl apply などのコマンド操作が必要です。しかも一部反映されない設定もあり注意が必要です。
このようにマニフェストファイルは IaC や複雑な設定の管理に適しており、 kubectl はクイックで即座な操作やリアルタイムなクラスタの状態の確認に適しています。両方のアプローチは、使用ケースによって使い分けることが重要です。
5. まとめ
マニフェストは、 Kubernetes の構成と設定を定義し、インフラのコード化（ IaC : Infrastructure as Code ）を実現することができる機能です。アプリケーションやサービスの変更が簡単かつ効率的に行え、新しい機能や修正が素早くデプロイされ、ビジネスの迅速な変化に適応することができるようになります。
Kubernetes の運用をサポートしてほしい
Contactお問い合わせ
お見積もり・ご相談など、お気軽にお問い合わせください。