本文へスキップ
BecomeCoder

Kubernetesコース · 第6章 運用と実践 ― 現場で使うために · レッスン29

Namespace ― クラスタを論理的に区切る

ブラウザで完結

導入

1つのクラスタを、開発チームと本番、あるいはチームAとチームBで一緒に使いたい。そのまま混ぜると、同じ名前のリソースがぶつかったり、うっかり本番を触ってしまったりします。クラスタの中を論理的な部屋に区切るのが Namespace(ネームスペース) です。

説明

Namespace は、1つのクラスタの中に作る「仕切られた部屋」です。dev(開発)・stg(検証)・prod(本番)や、チームごとに部屋を分けることで、次の利点が得られます。

  • 同名リソースの共存web-svc という Service を devprod の両方に置ける(部屋が違えば別物として扱われる)。
  • 操作の分離 … 「今どの部屋を触っているか」を明示でき、事故を減らせる。
graph TB
    subgraph cluster["1つのクラスタ"]
        subgraph dev["namespace: dev"]
            D1["Deployment web"]
            D2["Service web-svc"]
        end
        subgraph prod["namespace: prod"]
            P1["Deployment web"]
            P2["Service web-svc"]
        end
    end

操作は -n(namespace の指定)を付けて行います。

# namespace一覧を見る
$ kubectl get ns

# prod部屋のPodを見る
$ kubectl get pods -n prod

# 新しい部屋を作る
$ kubectl create namespace stg

-n を省略すると default という既定の部屋が対象になります。第4章で見た DNSweb-svc.default.svc.cluster.local の真ん中の default は、まさにこの Namespace のことでした。別の部屋の Service を呼ぶときは、その部屋の名前を挟みます(例 web-svc.prod)。

Namespace は「区切り」であって、それ自体は強い壁ではありません。部屋ごとに権限や使える資源量を制限したいときは、後述の RBAC や ResourceQuota と組み合わせます。

実際に動かしてみよう

上がマニフェスト(YAML)エディタ、下が kubectl の端末です。エディタの内容は `manifest.yaml` として保存され、下で `kubectl apply -f manifest.yaml` を実行するとクラスタに反映されます(pod.yaml / deploy.yaml / service.yaml も最初から置いてあります)。`kubectl get pods` / `describe` / `scale` / `rollout` などで結果を確かめましょう(本物のKubernetesではなく、動きを再現した軽量なシミュレータです)。各レッスンは毎回まっさらな状態から始まり、「最初からやり直す」で戻せます。

kubectl(シミュレート)

マニフェスト(YAML)を書いて kubectl コマンドを試せる学習用クラスタを読み込みます(本物のKubernetesではなく、apply/get/describe/scale/rollout などの動きを再現した軽量な自作シミュレータです)。
スクロールして表示された時点でも自動で読み込まれます。