kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Improve namespaces walkthroughs (#12686) 

* Reference glossary entry for namespace

* Call out namespace names
This commit is contained in:
Tim Bannister 2019-02-19 03:25:50 +00:00 committed by Kubernetes Prow Robot
parent a9dcaad92f
commit 59a34796c9
2 changed files with 26 additions and 25 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

27
content/en/docs/tasks/administer-cluster/namespaces-walkthrough.md
View File

@ -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:
@ -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
@ -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:
@ -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
@ -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.
@ -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

24
content/en/docs/tasks/administer-cluster/namespaces.md
View File

@ -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 %}}
@ -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
@ -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:
@ -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
@ -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.
@ -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