このページでは、名前空間の確認、操作、削除の方法を説明します。 また、Kubernetesの名前空間を使用してクラスターを分割する方法についても説明します。
次のコマンドを使用して、クラスター内の現在の名前空間の一覧を表示します。
kubectl get namespaces
NAME STATUS AGE
default Active 11d
kube-node-lease Active 11d
kube-public Active 11d
kube-system Active 11d
Kubernetesは初期状態で以下の4つの名前空間を持ちます。
default 他に名前空間が指定されていないオブジェクトに対するデフォルトの名前空間です。kube-node-lease 各ノードに関連付けられたリースオブジェクトを保持する名前空間です。
ノードのリースにより、kubeletはハートビートを送信でき、これによってコントロールプレーンはノードの障害を検知できます。kube-public この名前空間は自動的に作成され、すべてのユーザー(認証されていないユーザーを含む)が読み取り可能です。
この名前空間は、クラスター全体で一部のリソースを公開・参照可能にする必要がある場合に備えて、主にクラスター用途として予約されています。
この名前空間が公開されているのは慣習的なものであり、必須ではありません。kube-system Kubernetesシステムによって作成されるオブジェクト用の名前空間です。次のコマンドを使用して、特定の名前空間の概要を取得することもできます。
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
これらの詳細には、リソースクォータ(存在する場合)とリソースのLimit Rangeの両方が表示される点に留意してください。
リソースクォータは、名前空間内のリソース使用量の合計を追跡し、クラスター管理者が名前空間で消費可能なリソース使用量に対してハード制限を定義できるようにします。
Limit Rangeは、名前空間内で1つのエンティティが消費可能なリソース量の最小値および最大値の制約を定義します。
詳細については、Admission control: Limit Rangeを参照してください。
名前空間は、以下の2つのフェーズのいずれかの状態になります。
Active 名前空間が使用中の状態です。Terminating 名前空間が削除中の状態であり、新しいオブジェクトを作成できません。詳細については、APIリファレンスの名前空間を参照してください。
kube-というプレフィックスを持つ名前空間の作成は、Kubernetesシステム用の名前空間として予約されているため避けてください。次の内容でmy-namespace.yamlという新しいYAMLファイルを作成します。
apiVersion: v1
kind: Namespace
metadata:
name: <insert-namespace-name-here>
次に、以下を実行します。
kubectl create -f ./my-namespace.yaml
または、次のコマンドを使用して名前空間を作成できます。
kubectl create namespace <insert-namespace-name-here>
名前空間の名前は、有効なDNSラベルである必要があります。
オプションのフィールドfinalizersがあり、これにより名前空間が削除される際に、コントローラーが関連リソースをクリーンアップできるようになります。
存在しないファイナライザーを指定した場合、名前空間自体は作成されますが、ユーザーが削除しようとするとTerminating状態のまま停止する点に注意してください。
finalizersに関する詳細は、名前空間のデザインドキュメントを参照してください。
次のコマンドで名前空間を削除します。
kubectl delete namespaces <insert-some-namespace-name>
この削除処理は非同期で行われるため、しばらくの間、名前空間はTerminating状態として表示されます。
デフォルトでは、Kubernetesクラスターはプロビジョニング時に、クラスターで使用されるデフォルトのPod、Service、Deploymentを格納するためのdefaultという名前空間を作成します。
新しく作成されたクラスターを前提とすると、次の手順で利用可能な名前空間を確認できます。
kubectl get namespaces
NAME STATUS AGE
default Active 13m
この演習では、作業内容を格納するために、2つの追加のKubernetes名前空間を作成します。
Kubernetesクラスターを開発環境と本番環境の両方で使用している組織のシナリオを考えてみます。
開発チームは、アプリケーションのビルドおよび実行に使用しているPod、Service、Deploymentの一覧を把握できるスペースをクラスター内に維持したいと考えています。 このスペースでは、Kubernetesリソースは頻繁に作成・削除され、アジャイル開発を可能にするため、誰がリソースを変更できるか、またはできないかの制限は緩和されています。
運用チームは、本番環境で稼働するPod、Service、Deploymentの集合に対して、誰が操作できるか、またはできないかを厳密に管理するためのスペースをクラスター内に維持したいと考えています。
このような組織では、Kubernetesクラスターをdevelopmentとproductionという2つの名前空間に分割するという設計パターンを採用できます。
それでは、作業用に2つの新しい名前空間を作成してみましょう。
kubectlを使用してdevelopmentという名前空間を作成します。
kubectl create -f https://k8s.io/examples/admin/namespace-dev.json
続いて、kubectlを使用してproductionという名前空間を作成します。
kubectl create -f https://k8s.io/examples/admin/namespace-prod.json
正しく作成されたことを確認するために、クラスター内のすべての名前空間を一覧表示します。
kubectl get namespaces --show-labels
NAME STATUS AGE LABELS
default Active 32m <none>
development Active 29s name=development
production Active 23s name=production
Kubernetesの名前空間は、クラスター内におけるPod、Service、Deploymentのスコープを提供します。
ある名前空間とやり取りするユーザーは、別の名前空間の内容を見ることはできません。
これを確認するために、development名前空間に簡単な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名前空間の内容に影響を与える心配はありません。
次にproduction名前空間に切り替えて、ある名前空間のリソースが他の名前空間からは見えないことを確認します。
production名前空間には何も存在しないはずで、以下のコマンドは何も返さないはずです。
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
この時点で、ある名前空間に作成されたリソースは、他の名前空間からは見えないことが明確になったはずです。
Kubernetesにおけるポリシーのサポートが進化するにつれて、このシナリオを拡張し、名前空間ごとに異なる認可ルールを提供する方法を紹介していく予定です。
1つのKubernetesクラスターは、複数のユーザー、またはユーザーグループ(本ドキュメントでは、以降これらを ユーザーコミュニティ と呼びます)の要件を満たす必要があります。
Kubernetesの 名前空間 は、異なるプロジェクト、チーム、または顧客が1つのKubernetesクラスターを共有するのに役立ちます。
これは、次の機能を提供することで実現されます。
複数の名前空間を使用することは必須ではありません。
各ユーザーコミュニティは、他のコミュニティから分離された状態で作業できることを望みます。 各ユーザーコミュニティは、次のものを独自に持ちます。
クラスター管理者は、各ユーザーコミュニティに対して名前空間を作成できます。
名前空間は、次のためのユニークなスコープを提供します。
ユースケースは次のとおりです。
Serviceを作成すると、それに対応するDNSエントリが作成されます。
このエントリは<service-name>.<namespace-name>.svc.cluster.localという形式です。
これは、コンテナ内で<service-name>を使用した場合、同じ名前空間内にあるServiceに名前解決されることを意味します。
これは、Development、Staging、Productionなど複数の名前空間で同一の設定を使用する際に便利です。
名前空間をまたいでServiceにアクセスしたい場合は、完全修飾ドメイン名(FQDN)を使用する必要があります。