はじめに
Kubernetes クラスターは、大きなアパートのようなものです。
全員がロビーで暮らしていたら、混乱してしまいます。どの家具が誰のものか分からず、大きな音を立てる住人が全員の生活を妨げるかもしれません。
Namespace はクラスターを論理的に分割し、異なるチーム、環境、アプリケーションがリソースを分けて整理できるようにします。
ResourceQuota は、Namespace が使用できる特定のリソース量を制限します。これにより、1 つのチームやワークロードが共有クラスターの容量を使い果たすことを防げます。
この実験では、次の操作を行います。
devという新しい「アパート」（Namespace）を作成します。- そのアパートに厳しい「電力制限」（ResourceQuota）を設定します。
- 家具（Pod）をアパートに運び入れ、収まるかどうかを確認します。
Namespace を作成する
このステップでは、開発チームのリソースを分離するために、新しい Namespace を作成します。
Namespace は 1 つのクラスター内にある論理的な境界であり、別のクラスターではありません。チームは同じコントロールプレーンと基盤ノードを共有しますが、名前、ポリシー、多くのリソース表示を分離できるため、作業を整理して管理できます。
デフォルトでは、すべてのリソースが default Namespace（ロビー）に入ります。現在存在する Namespace を確認しましょう。
kubectl get namespaces
default、kube-system（建物の管理者がいる場所）、およびいくつかの Namespace が表示されます。
次に、dev アパートを作成します。
kubectl create namespace dev
作成されたことを確認します。
kubectl get namespaces
一覧に dev が表示されます。現時点では、壁も制限もない空のアパートなので、内部に任意のリソースを配置できます。
リソース制限を適用する
次に、ルールを設定します。dev チームがクラスター全体の CPU とメモリを使い果たさないようにします。
ResourceQuota オブジェクトを作成します。これにより、「dev Namespace では、最大で CPU 2 個分とメモリ 2Gi まで使用できる」と設定できます。
共有クラスターでは、CPU とメモリに限りがあるため、Quota が特に重要です。Quota がなければ、1 つの負荷の高いワークロードが公平な割り当てを超えてリソースを消費し、他の利用者にとってクラスターが不安定になる可能性があります。つまり、Quota は使用量を記録するだけの仕組みではなく、安定性を保つための手段でもあります。
quota.yaml という名前のファイルを作成します。
nano quota.yaml
次の設定を貼り付けます。
apiVersion: v1
kind: ResourceQuota
metadata:
name: dev-quota
namespace: dev
spec:
hard:
requests.cpu: "1"
requests.memory: 1Gi
limits.cpu: "2"
limits.memory: 2Gi
Ctrl+X、Y、Enter を押して保存して終了します。
このルールをクラスターに適用します。
kubectl apply -f quota.yaml
ルールの詳細を確認できます。設定した「Hard」制限と、現在の「Used」使用量（現時点では 0）が表示されます。
kubectl describe resourcequota dev-quota --namespace=dev
Pod をデプロイする
ルールを設定できたので、実際に入居させてみましょう。
重要なルール：アパートに制限がある場合、持ち込むすべての家具にサイズを明示する必要があります。Kubernetes では、Namespace に Quota が設定されている場合、すべての Pod で resources（requests と limits）を明示的に指定する必要があります。指定しないと、建物の管理者である Kubernetes に入口で拒否されます。
ここで、関連する 2 つの考え方が登場します。request は、Pod を配置するときにスケジューラーが保証すべきリソース量を示します。limit は、コンテナが使用できるリソース量の上限です。Quota は Namespace 内の requests と limits を合計し、合計値がポリシーの範囲内に収まるようにします。
pod.yaml という名前のファイルを作成します。
nano pod.yaml
次の内容を貼り付けます。この Pod のサイズを明示的に指定している点に注目してください。
apiVersion: v1
kind: Pod
metadata:
name: dev-pod
namespace: dev ## <-- Putting it in the 'dev' apartment
spec:
containers:
- name: nginx
image: nginx
resources:
requests:
memory: "128Mi"
cpu: "250m"
limits:
memory: "256Mi"
cpu: "500m"
Ctrl+X、Y、Enter を押して保存して終了します。
Pod をデプロイします。
kubectl apply -f pod.yaml
dev Namespace 内で Pod が実行されているか確認します。
kubectl get pods --namespace=dev
Running と表示されるまで待ちます。
次に、Quota の使用量をもう一度確認します。「Used」列の値が増えていることを確認できます。
kubectl describe resourcequota dev-quota --namespace=dev
これで、予算に対するリソース使用量を正しく追跡できています。
分離を確認する
最後に、「アパート」の壁が実際に機能していることを確認します。
Namespace の分離は、主に名前、ポリシー、操作範囲を分ける仕組みです。デフォルトでワークロードが物理的に別のハードウェア上で実行されるという意味ではありません。この違いは、後でノード選択や、より強力な分離メカニズムを学ぶときに重要になります。
dev-pod は dev の内部に配置しました。そのため、ロビー（default）からは表示されないはずです。
default Namespace 内の Pod を一覧表示します。
kubectl get pods
No resources found in default namespace と表示されるか、少なくとも dev-pod が表示されないことを確認してください。
次に、default Namespace に Quota があるか確認します。
kubectl get resourcequota
何も表示されないはずです。設定した電力制限は建物全体ではなく、dev アパートにのみ適用されます。
これにより、Namespace がチーム間のリソースを分離できることを確認できます。
まとめ
この実験では、Kubernetes クラスターの建物管理者になって操作しました。
次の操作を完了しました。
- チーム専用の Namespace（
dev）を作成しました。 - 過剰なリソース消費を防ぐため、厳しい ResourceQuota（電力制限）を設定しました。
- これらの制限を守るアプリケーションをデプロイしました。
- Namespace 間の壁によって、リソースが分離されることを確認しました。
このようにして、大規模な組織は、互いの作業を妨げることなく、数百のチームで 1 つの Kubernetes クラスターを共有できます。
