Namespaceを使用してクラスターを共有する
このページでは、Namespaceの確認、操作、削除の方法を説明します。 また、KubernetesのNamespaceを使用してクラスターを分割する方法についても説明します。
始める前に
- 既存のKubernetesクラスターを用意していること。
- KubernetesのPod、Service、Deploymentについて基本的な理解があること。
Namespace の確認
次のコマンドを使用して、現在クラスター内のNamespace一覧を表示します。
kubectl get namespaces
NAME STATUS AGE
default Active 11d
kube-node-lease Active 11d
kube-public Active 11d
kube-system Active 11d
Kubernetesは、次の4つの初期Namespaceから始まります。
default他にNamespaceが指定されていないオブジェクトに対するデフォルトのNamespaceです。kube-node-lease各ノードに関連付けられたリースオブジェクトを保持するNamespaceです。ノードのリースにより、kubeletはハートビートを送信でき、これによってコントロールプレーンはノードの障害を検知できます。kube-publicこのNamespaceは自動的に作成され、すべてのユーザー（認証されていないユーザーを含む）が読み取り可能です。 このNamespaceは、クラスター全体で一部のリソースを公開・参照可能にする必要がある場合に備えて、主にクラスター用途として予約されています。 このNamespaceが公開されているという点は慣習的なものであり、必須ではありません。kube-systemKubernetesシステムによって作成されるオブジェクト用のNamespaceです。
次のコマンドを使用して、特定のNamespaceの概要を取得することもできます。
kubectl get namespaces <name>
また、次のコマンドを使用して、詳細な情報を取得することもできます。
kubectl describe namespaces <name>
Name: default
Labels: <none>
Annotations: <none>
Status: Active
No resource quota.
Resource Limits
Type Resource Min Max Default
---- -------- --- --- ---
Container cpu - - 100m
これらの詳細には、リソースクォータ（存在する場合）とリソース制限範囲の両方が表示される点に注意してください。
リソースクォータは、Namespace内のリソース使用量の合計を追跡し、クラスター管理者が Namespaceで消費可能なリソース使用量に対してハード制限を定義できるようにします。
制限範囲は、Namespace内でシングルエンティティが消費できるリソース量の最小値および最大値の制約を定義します。
詳細については、Admission control: 制限範囲 を参照してください。
Namespaceは、次の2つのフェーズのいずれかの状態です。
ActiveNamespaceが使用中の状態です。TerminatingNamespaceが削除中の状態であり、新しいオブジェクトを作成できません。
詳細については、APIリファレンスのNamespaceを参照してください。
新しいNamespaceの作成
備考:
kube-という接頭辞を持つNamespaceの作成は、Kubernetesシステム用の Namespaceとして予約されているので避けてください。次の内容でmy-namespace.yamlという新しいYAMLファイルを作成します。
apiVersion: v1
kind: Namespace
metadata:
name: <insert-namespace-name-here>
次に、以下を実行します。
kubectl create -f ./my-namespace.yaml
または、次のコマンドを使用してNamespaceを作成できます。
kubectl create namespace <insert-namespace-name-here>
Namespaceの名前は、有効なDNSラベルである必要があります。
オプションのフィールドであるfinalizers は、Namespaceが削除される際にそれを検知したものがリソースを削除できるようにします。
存在しないfinalizerを指定した場合、Namespace自体は作成されますが、ユーザーが削除しようとすると Terminating 状態のまま停止する点に注意してください。
finalizers に関する詳細は、Namespaceのデザインドキュメントを参照してください。
Namespaceの削除
kubectl delete namespaces <insert-some-namespace-name>
警告:
このコマンドは、そのNamespace配下の_すべて_のリソースが削除されます！この削除処理は非同期で行われるため、しばらくの間、NamespaceはTerminating状態として表示されます。
KubernetesのNamespaceを使用してクラスターを分割する
デフォルトでは、Kubernetesのクラスターはプロビジョニングときに、クラスターで使用されるデフォルトのPod、Service、Deploymentを格納するためのdefaultというNamespaceを作成します。
新しく作成されたクラスターを前提とすると、次の手順で利用可能なNamespaceを確認できます。
kubectl get namespaces
NAME STATUS AGE
default Active 13m
新しいNamespaceの作成
この演習では、作業内容を格納するために、2つの追加のKubernetes Namespaceを作成します。
Kubernetesクラスターを開発環境と本番環境の両方で使用しているオーガニゼーションのシナリオを考えてみます。
-
開発チームは、アプリケーションのビルドおよび実行に使用しているPod、Service、Deploymentの一覧を把握できるクラスター内のスペースを運営したいと考えています。 このスペースでは、リソースは頻繁に作成・削除され、アジャイルな開発を可能にするため、リソースを変更できるユーザーに対する制限は比較的緩やかです。
-
運用チームは、本番環境で稼働するPod、Service、Deploymentの集合に対して、誰が操作できるかを厳密に管理するためのスペースをクラスター内に運営したいと考えています。
このような組織では、Kubernetesクラスターをdevelopmentとproductionという2つのNamespaceに分割するという設計パターンを採用できます。
それでは、作業用に2つの新しいNamespaceを作成してみましょう。
kubectlを使用してdevelopmentというNamespaceを作成します。
kubectl create -f https://k8s.io/examples/admin/namespace-dev.json
続いて、kubectlを使用してproductionというNamespaceを作成します。
kubectl create -f https://k8s.io/examples/admin/namespace-prod.json
正しく作成されたことを確認するために、クラスター内のすべてのNamespaceを一覧表示します。
kubectl get namespaces --show-labels
NAME STATUS AGE LABELS
default Active 32m <none>
development Active 29s name=development
production Active 23s name=production
各NamespaceにPodを作成する
KubernetesのNamespaceは、クラスター内におけるPod、Service、Deploymentのスコープを提供します。
あるNamespaceとやり取りするユーザーは、別のNamespaceの内容を見ることはできません。
これを確認するために、development Namespaceに簡単なDeploymentとPodを作成してみましょう。
kubectl create deployment snowflake \
--image=registry.k8s.io/serve_hostname \
-n=development --replicas=2
レプリカ数が2のDeploymentを作成し、ホストネームを返す基本的なコンテナを実行するsnowflakeというPodが起動されています。
kubectl get deployment -n=development
NAME READY UP-TO-DATE AVAILABLE AGE
snowflake 2/2 2 2 2m
kubectl get pods -l app=snowflake -n=development
NAME READY STATUS RESTARTS AGE
snowflake-3968820950-9dgr8 1/1 Running 0 2m
snowflake-3968820950-vgc4n 1/1 Running 0 2m
これにより、開発者は自由に作業を進めることができ、production Namespaceの内容に影響を与える心配はありません。
次に production Namespaceに切り替えて、あるNamespaceのリソースが他のNamespaceからは見えないことを確認します。
production Namespaceには何も存在しないはずで、以下のコマンドは何も返さないはずです。
kubectl get deployment -n=production
kubectl get pods -n=production
本番環境では、cattleの運用を想定しているため、いくつかのcattleというPodを作成してみましょう。
kubectl create deployment cattle --image=registry.k8s.io/serve_hostname -n=production
kubectl scale deployment cattle --replicas=5 -n=production
kubectl get deployment -n=production
NAME READY UP-TO-DATE AVAILABLE AGE
cattle 5/5 5 5 10s
kubectl get pods -l app=cattle -n=production
NAME READY STATUS RESTARTS AGE
cattle-2263376956-41xy6 1/1 Running 0 34s
cattle-2263376956-kw466 1/1 Running 0 34s
cattle-2263376956-n4v97 1/1 Running 0 34s
cattle-2263376956-p5p3i 1/1 Running 0 34s
cattle-2263376956-sxpth 1/1 Running 0 34s
この時点で、あるNamespaceに作成されたリソースは、他のNamespaceからは見えないことが明確になったはずです。
Kubernetesにおけるポリシー機能のサポートが進化するにつれて、このシナリオを拡張し、Namespaceごとに異なる認可ルールを提供する方法を紹介していく予定です。
Namespaceを使用する動機の理解
1つのKubernetesクラスターは、複数のユーザー、またはユーザーグループ（本ドキュメントでは、以降これらを_ユーザーコミュニティ_と呼びます）の要件を満たせる必要があります。
Kubernetesの_Namespace_は、異なるプロジェクト、チーム、または顧客が1つのKubernetesクラスターを共有できるようにします。
これは、次の機能を提供することで実現されます。
- 名前のスコープ
- クラスターの一部に対して認可およびポリシーを関連付ける仕組み
複数のNamespaceを使用することは必須ではありません。
各ユーザーコミュニティは、他のコミュニティから分離された状態で作業できることを望みます。 各ユーザーコミュニティは、次のものを独自に持ちます。
- リソース（Pod、Service、ReplicationControllerなど）
- ポリシー（誰がそのコミュニティ内で操作を行えるか行えないか）
- 制約（そのコミュニティに許可されるクォータなど）
クラスター管理者は、各ユーザーコミュニティごとにNamespaceを作成できます。
Namespaceは、次のためのユニークなスコープを提供します。
- 名前付きリソース（基本的な名前の衝突を防ぐため）
- 信頼されたユーザーへの管理権限の委譲
- コミュニティごとのリソース消費量を制限する機能
ユースケースは次のとおりです。
- クラスター管理者として、1つのクラスター上で複数のユーザーコミュニティをサポートしたい
- クラスター管理者として、クラスターの一部の管理権限を、各コミュニティ内の信頼されたユーザーに委譲したい
- クラスター管理者として、クラスターを共有する他のコミュニティへの影響を抑えるために、各コミュニティが消費できるリソース量を制限したい
- クラスター利用者として、他のユーザーコミュニティの活動から分離された上で、自分のコミュニティに関連するリソースのみを操作したい
NamespaceとDNSの理解
Serviceを作成すると、それに対応するDNS エントリが作成されます。
このエントリは<service-name>.<namespace-name>.svc.cluster.localという形式になっています。
これは、コンテナ内で<service-name>を使用した場合、同じNamespace内にあるServiceに名前解決されることを意味します。
この仕組みにより、Development、Staging、Productionなど、複数のNamespaceにまたがって同一の設定を使用することが可能になります。
NamespaceをまたいでServiceにアクセスしたい場合は、完全修飾ドメイン名(FQDN)を使用する必要があります。
次の項目
- Namespace既定値の設定について詳しく学ぶ。
- リクエストごとにNamespaceを指定する方法について詳しく学ぶ。
- Namespaceのデザインを参照する。