300 lines
8.6 KiB
Markdown
300 lines
8.6 KiB
Markdown
---
|
|
reviewers:
|
|
- derekwaynecarr
|
|
- janetkuo
|
|
title: Namespaces Walkthrough
|
|
content_type: task
|
|
---
|
|
|
|
<!-- overview -->
|
|
Kubernetes {{< glossary_tooltip text="namespaces" term_id="namespace" >}}
|
|
help different projects, teams, or customers to share a Kubernetes cluster.
|
|
|
|
It does this by providing the following:
|
|
|
|
1. A scope for [Names](/docs/concepts/overview/working-with-objects/names/).
|
|
2. A mechanism to attach authorization and policy to a subsection of the cluster.
|
|
|
|
Use of multiple namespaces is optional.
|
|
|
|
This example demonstrates how to use Kubernetes namespaces to subdivide your cluster.
|
|
|
|
|
|
|
|
|
|
## {{% heading "prerequisites" %}}
|
|
|
|
|
|
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
|
|
|
|
|
|
|
<!-- steps -->
|
|
|
|
## Prerequisites
|
|
|
|
This example assumes the following:
|
|
|
|
1. You have an [existing Kubernetes cluster](/docs/setup/).
|
|
2. You have a basic understanding of Kubernetes _[Pods](/docs/concepts/workloads/pods/pod/)_, _[Services](/docs/concepts/services-networking/service/)_, and _[Deployments](/docs/concepts/workloads/controllers/deployment/)_.
|
|
|
|
## Understand the default namespace
|
|
|
|
By default, a Kubernetes cluster will instantiate a default namespace when provisioning the cluster to hold the default set of Pods,
|
|
Services, and Deployments used by the cluster.
|
|
|
|
Assuming you have a fresh cluster, you can inspect the available namespaces by doing the following:
|
|
|
|
```shell
|
|
kubectl get namespaces
|
|
```
|
|
```
|
|
NAME STATUS AGE
|
|
default Active 13m
|
|
```
|
|
|
|
## Create new namespaces
|
|
|
|
For this exercise, we will create two additional Kubernetes namespaces to hold our content.
|
|
|
|
Let's imagine a scenario where an organization is using a shared Kubernetes cluster for development and production use cases.
|
|
|
|
The development team would like to maintain a space in the cluster where they can get a view on the list of Pods, Services, and Deployments
|
|
they use to build and run their application. In this space, Kubernetes resources come and go, and the restrictions on who can or cannot modify resources
|
|
are relaxed to enable agile development.
|
|
|
|
The operations team would like to maintain a space in the cluster where they can enforce strict procedures on who can or cannot manipulate the set of
|
|
Pods, Services, and Deployments that run the production site.
|
|
|
|
One pattern this organization could follow is to partition the Kubernetes cluster into two namespaces: `development` and `production`.
|
|
|
|
Let's create two new namespaces to hold our work.
|
|
|
|
Use the file [`namespace-dev.json`](/examples/admin/namespace-dev.json) which describes a `development` namespace:
|
|
|
|
{{< codenew language="json" file="admin/namespace-dev.json" >}}
|
|
|
|
Create the `development` namespace using kubectl.
|
|
|
|
```shell
|
|
kubectl create -f https://k8s.io/examples/admin/namespace-dev.json
|
|
```
|
|
|
|
Save the following contents into file [`namespace-prod.json`](/examples/admin/namespace-prod.json) which describes a `production` namespace:
|
|
|
|
{{< codenew language="json" file="admin/namespace-prod.json" >}}
|
|
|
|
And then let's create the `production` namespace using kubectl.
|
|
|
|
```shell
|
|
kubectl create -f https://k8s.io/examples/admin/namespace-prod.json
|
|
```
|
|
|
|
To be sure things are right, let's list all of the namespaces in our cluster.
|
|
|
|
```shell
|
|
kubectl get namespaces --show-labels
|
|
```
|
|
```
|
|
NAME STATUS AGE LABELS
|
|
default Active 32m <none>
|
|
development Active 29s name=development
|
|
production Active 23s name=production
|
|
```
|
|
|
|
## Create pods in each namespace
|
|
|
|
A Kubernetes namespace provides the scope for Pods, Services, and Deployments in the cluster.
|
|
|
|
Users interacting with one namespace do not see the content in another namespace.
|
|
|
|
To demonstrate this, let's spin up a simple Deployment and Pods in the `development` namespace.
|
|
|
|
We first check what is the current context:
|
|
|
|
```shell
|
|
kubectl config view
|
|
```
|
|
```yaml
|
|
apiVersion: v1
|
|
clusters:
|
|
- cluster:
|
|
certificate-authority-data: REDACTED
|
|
server: https://130.211.122.180
|
|
name: lithe-cocoa-92103_kubernetes
|
|
contexts:
|
|
- context:
|
|
cluster: lithe-cocoa-92103_kubernetes
|
|
user: lithe-cocoa-92103_kubernetes
|
|
name: lithe-cocoa-92103_kubernetes
|
|
current-context: lithe-cocoa-92103_kubernetes
|
|
kind: Config
|
|
preferences: {}
|
|
users:
|
|
- name: lithe-cocoa-92103_kubernetes
|
|
user:
|
|
client-certificate-data: REDACTED
|
|
client-key-data: REDACTED
|
|
token: 65rZW78y8HbwXXtSXuUw9DbP4FLjHi4b
|
|
- name: lithe-cocoa-92103_kubernetes-basic-auth
|
|
user:
|
|
password: h5M0FtUUIflBSdI7
|
|
username: admin
|
|
```
|
|
```shell
|
|
kubectl config current-context
|
|
```
|
|
```
|
|
lithe-cocoa-92103_kubernetes
|
|
```
|
|
|
|
The next step is to define a context for the kubectl client to work in each namespace. The value of "cluster" and "user" fields are copied from the current context.
|
|
|
|
```shell
|
|
kubectl config set-context dev --namespace=development \
|
|
--cluster=lithe-cocoa-92103_kubernetes \
|
|
--user=lithe-cocoa-92103_kubernetes
|
|
|
|
kubectl config set-context prod --namespace=production \
|
|
--cluster=lithe-cocoa-92103_kubernetes \
|
|
--user=lithe-cocoa-92103_kubernetes
|
|
```
|
|
|
|
By default, the above commands adds two contexts that are saved into file
|
|
`.kube/config`. You can now view the contexts and alternate against the two
|
|
new request contexts depending on which namespace you wish to work against.
|
|
|
|
To view the new contexts:
|
|
|
|
```shell
|
|
kubectl config view
|
|
```
|
|
```yaml
|
|
apiVersion: v1
|
|
clusters:
|
|
- cluster:
|
|
certificate-authority-data: REDACTED
|
|
server: https://130.211.122.180
|
|
name: lithe-cocoa-92103_kubernetes
|
|
contexts:
|
|
- context:
|
|
cluster: lithe-cocoa-92103_kubernetes
|
|
user: lithe-cocoa-92103_kubernetes
|
|
name: lithe-cocoa-92103_kubernetes
|
|
- context:
|
|
cluster: lithe-cocoa-92103_kubernetes
|
|
namespace: development
|
|
user: lithe-cocoa-92103_kubernetes
|
|
name: dev
|
|
- context:
|
|
cluster: lithe-cocoa-92103_kubernetes
|
|
namespace: production
|
|
user: lithe-cocoa-92103_kubernetes
|
|
name: prod
|
|
current-context: lithe-cocoa-92103_kubernetes
|
|
kind: Config
|
|
preferences: {}
|
|
users:
|
|
- name: lithe-cocoa-92103_kubernetes
|
|
user:
|
|
client-certificate-data: REDACTED
|
|
client-key-data: REDACTED
|
|
token: 65rZW78y8HbwXXtSXuUw9DbP4FLjHi4b
|
|
- name: lithe-cocoa-92103_kubernetes-basic-auth
|
|
user:
|
|
password: h5M0FtUUIflBSdI7
|
|
username: admin
|
|
```
|
|
|
|
Let's switch to operate in the `development` namespace.
|
|
|
|
```shell
|
|
kubectl config use-context dev
|
|
```
|
|
|
|
You can verify your current context by doing the following:
|
|
|
|
```shell
|
|
kubectl config current-context
|
|
```
|
|
```
|
|
dev
|
|
```
|
|
|
|
At this point, all requests we make to the Kubernetes cluster from the command line are scoped to the `development` namespace.
|
|
|
|
Let's create some contents.
|
|
|
|
{{< codenew file="admin/snowflake-deployment.yaml" >}}
|
|
|
|
Apply the manifest to create a Deployment
|
|
|
|
```shell
|
|
kubectl apply -f https://k8s.io/examples/admin/snowflake-deployment.yaml
|
|
```
|
|
We have just created a deployment whose replica size is 2 that is running the pod called `snowflake` with a basic container that just serves the hostname.
|
|
|
|
```shell
|
|
kubectl get deployment
|
|
```
|
|
```
|
|
NAME READY UP-TO-DATE AVAILABLE AGE
|
|
snowflake 2/2 2 2 2m
|
|
```
|
|
|
|
```shell
|
|
kubectl get pods -l app=snowflake
|
|
```
|
|
```
|
|
NAME READY STATUS RESTARTS AGE
|
|
snowflake-3968820950-9dgr8 1/1 Running 0 2m
|
|
snowflake-3968820950-vgc4n 1/1 Running 0 2m
|
|
```
|
|
|
|
And this is great, developers are able to do what they want, and they do not have to worry about affecting content in the `production` namespace.
|
|
|
|
Let's switch to the `production` namespace and show how resources in one namespace are hidden from the other.
|
|
|
|
```shell
|
|
kubectl config use-context prod
|
|
```
|
|
|
|
The `production` namespace should be empty, and the following commands should return nothing.
|
|
|
|
```shell
|
|
kubectl get deployment
|
|
kubectl get pods
|
|
```
|
|
|
|
Production likes to run cattle, so let's create some cattle pods.
|
|
|
|
```shell
|
|
kubectl create deployment cattle --image=k8s.gcr.io/serve_hostname
|
|
kubectl scale deployment cattle --replicas=5
|
|
|
|
kubectl get deployment
|
|
```
|
|
```
|
|
NAME READY UP-TO-DATE AVAILABLE AGE
|
|
cattle 5/5 5 5 10s
|
|
```
|
|
|
|
```shell
|
|
kubectl get pods -l app=cattle
|
|
```
|
|
```
|
|
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
|
|
```
|
|
|
|
At this point, it should be clear that the resources users create in one namespace are hidden from the other namespace.
|
|
|
|
As the policy support in Kubernetes evolves, we will extend this scenario to show how you can provide different
|
|
authorization rules for each namespace.
|
|
|
|
|