Skip to content

Commit

Permalink
Improve namespaces walkthroughs (kubernetes#12686)
Browse files Browse the repository at this point in the history
* Reference glossary entry for namespace

* Call out namespace names
  • Loading branch information
sftim authored and Mayank Kumar committed Mar 11, 2019
1 parent e970abf commit 07d68a5
Show file tree
Hide file tree
Showing 2 changed files with 26 additions and 25 deletions.
27 changes: 14 additions & 13 deletions content/en/docs/tasks/administer-cluster/namespaces-walkthrough.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,8 @@ content_template: templates/task
---

{{% capture overview %}}
Kubernetes _namespaces_ help different projects, teams, or customers to share a Kubernetes cluster.
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:

Expand Down Expand Up @@ -62,25 +63,25 @@ 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.
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:
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.
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:
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.
And then let's create the `production` namespace using kubectl.

```shell
$ kubectl create -f https://k8s.io/examples/admin/namespace-prod.json
Expand All @@ -102,7 +103,7 @@ A Kubernetes namespace provides the scope for Pods, Services, and Deployments in

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.
To demonstrate this, let's spin up a simple Deployment and Pods in the `development` namespace.

We first check what is the current context:

Expand Down Expand Up @@ -192,7 +193,7 @@ users:
username: admin
```

Let's switch to operate in the development namespace.
Let's switch to operate in the `development` namespace.

```shell
$ kubectl config use-context dev
Expand All @@ -205,14 +206,14 @@ $ 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.
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.

```shell
$ kubectl run snowflake --image=kubernetes/serve_hostname --replicas=2
```
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.
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.
Note that `kubectl run` creates deployments only on Kubernetes cluster >= v1.2. If you are running older versions, it creates replication controllers instead.
If you want to obtain the old behavior, use `--generator=run/v1` to create replication controllers. See [`kubectl run`](/docs/reference/generated/kubectl/kubectl-commands/#run) for more details.

Expand All @@ -227,15 +228,15 @@ 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.
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.
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.
The `production` namespace should be empty, and the following commands should return nothing.

```shell
$ kubectl get deployment
Expand Down
24 changes: 12 additions & 12 deletions content/en/docs/tasks/administer-cluster/namespaces.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,7 @@ content_template: templates/task
---

{{% capture overview %}}
This page shows how to view, work in, and delete namespaces. The page also shows how to use Kubernetes namespaces to subdivide your cluster.
This page shows how to view, work in, and delete {{< glossary_tooltip text="namespaces" term_id="namespace" >}}. The page also shows how to use Kubernetes namespaces to subdivide your cluster.
{{% /capture %}}

{{% capture prerequisites %}}
Expand Down Expand Up @@ -140,21 +140,21 @@ 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.
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:
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.
Create the `development` namespace using kubectl.

```shell
$ kubectl create -f https://k8s.io/examples/admin/namespace-dev.json
```

And then let's create the production namespace using kubectl.
And then let's create the `production` namespace using kubectl.

```shell
$ kubectl create -f https://k8s.io/examples/admin/namespace-prod.json
Expand All @@ -176,7 +176,7 @@ A Kubernetes namespace provides the scope for Pods, Services, and Deployments in

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.
To demonstrate this, let's spin up a simple Deployment and Pods in the `development` namespace.

We first check what is the current context:

Expand Down Expand Up @@ -221,7 +221,7 @@ $ kubectl config set-context prod --namespace=production --cluster=lithe-cocoa-9
The above commands provided two request contexts you can alternate against depending on what namespace you
wish to work against.

Let's switch to operate in the development namespace.
Let's switch to operate in the `development` namespace.

```shell
$ kubectl config use-context dev
Expand All @@ -234,14 +234,14 @@ $ 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.
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.

```shell
$ kubectl run snowflake --image=kubernetes/serve_hostname --replicas=2
```
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.
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.
Note that `kubectl run` creates deployments only on Kubernetes cluster >= v1.2. If you are running older versions, it creates replication controllers instead.
If you want to obtain the old behavior, use `--generator=run/v1` to create replication controllers. See [`kubectl run`](/docs/reference/generated/kubectl/kubectl-commands/#run) for more details.

Expand All @@ -256,15 +256,15 @@ 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.
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.
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.
The `production` namespace should be empty, and the following commands should return nothing.

```shell
$ kubectl get deployment
Expand Down

0 comments on commit 07d68a5

Please sign in to comment.