whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Syntax highlighting

Browse Source
This commit is contained in:
John Mulhausen
2016-02-16 17:53:42 -08:00
parent bbeb111863
commit ee72211075
115 changed files with 1922 additions and 1919 deletions
Download Patch File Download Diff File Expand all files Collapse all files
v1.1/docs/admin/namespaces/README.md
+30 -30
View File
@@ -27,11 +27,11 @@ services, and replication controllers used by the cluster.
Assuming you have a fresh cluster, you can introspect the available namespace's by doing the following:
{% highlight console %}
```shell
$ kubectl get namespaces
NAME LABELS
default <none>
default <none>
```
@@ -54,7 +54,7 @@ Use the file [`namespace-dev.json`](namespace-dev.json) which describes a develo
Use the file [`namespace-dev.json`](namespace-dev.json) which describes a development namespace:
<!-- BEGIN MUNGE: EXAMPLE namespace-dev.json -->
<!-- BEGIN MUNGE: EXAMPLE namespace-dev.json -->
```json
@@ -65,32 +65,32 @@ Use the file [`namespace-dev.json`](namespace-dev.json) which describes a develo
"name": "development",
"labels": {
"name": "development"
}
}
}
}
```
[Download example](namespace-dev.json)
<!-- END MUNGE: EXAMPLE namespace-dev.json -->
<!-- END MUNGE: EXAMPLE namespace-dev.json -->
Create the development namespace using kubectl.
Create the development namespace using kubectl.
```shell
$ kubectl create -f docs/admin/namespaces/namespace-dev.json
$ kubectl create -f docs/admin/namespaces/namespace-dev.json
{% endhighlight %}
```
And then lets create the production namespace using kubectl.
{% highlight console %}
```shell
$ kubectl create -f docs/admin/namespaces/namespace-prod.json
```
To be sure things are right, let's list all of the namespaces in our cluster.
To be sure things are right, let's list all of the namespaces in our cluster.
```shell
@@ -103,7 +103,7 @@ To demonstrate this, let's spin up a simple replication controller and pod in th
```
### Step Three: Create pods in each namespace
### Step Three: Create pods in each namespace
A Kubernetes namespace provides the scope for pods, services, and replication controllers in the cluster.
@@ -128,31 +128,31 @@ users:
name: lithe-cocoa-92103_kubernetes
current-context: lithe-cocoa-92103_kubernetes
kind: Config
preferences: {}
preferences: {}
users:
- name: lithe-cocoa-92103_kubernetes
user:
client-certificate-data: REDACTED
client-certificate-data: REDACTED
client-key-data: REDACTED
token: 65rZW78y8HbwXXtSXuUw9DbP4FLjHi4b
- name: lithe-cocoa-92103_kubernetes-basic-auth
- name: lithe-cocoa-92103_kubernetes-basic-auth
user:
password: h5M0FtUUIflBSdI7
username: admin
```
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.
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.
{% highlight console %}
```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
```
The above commands provided two request contexts you can alternate against depending on what namespace you
wish to work against.
wish to work against.
Let's switch to operate in the development namespace.
@@ -187,19 +187,19 @@ users:
- context:
cluster: lithe-cocoa-92103_kubernetes
user: lithe-cocoa-92103_kubernetes
name: lithe-cocoa-92103_kubernetes
name: lithe-cocoa-92103_kubernetes
- context:
cluster: lithe-cocoa-92103_kubernetes
namespace: production
user: lithe-cocoa-92103_kubernetes
name: prod
current-context: dev
current-context: dev
kind: Config
preferences: {}
preferences: {}
users:
- name: lithe-cocoa-92103_kubernetes
user:
client-certificate-data: REDACTED
client-certificate-data: REDACTED
client-key-data: REDACTED
token: 65rZW78y8HbwXXtSXuUw9DbP4FLjHi4b
- name: lithe-cocoa-92103_kubernetes-basic-auth
@@ -208,29 +208,29 @@ $ kubectl get pods
username: admin
```
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 content.
```shell
$ kubectl run snowflake --image=kubernetes/serve_hostname --replicas=2
```
We have just created a replication controller whose replica size is 2 that is running the pod called snowflake with a basic container that just serves the hostname.
```shell
$ kubectl get rc
CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR REPLICAS
snowflake snowflake kubernetes/serve_hostname run=snowflake 2
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
snowflake-8w0qn 1/1 Running 0 22s
snowflake-jrpzb 1/1 Running 0 22s
snowflake-jrpzb 1/1 Running 0 22s
```
@@ -244,7 +244,7 @@ cattle-i9ojn 1/1 Running 0 12s
```
The production namespace should be empty.
The production namespace should be empty.
```shell
v1.1/docs/admin/namespaces/index.md
+30 -30
View File
@@ -26,13 +26,13 @@ services, and replication controllers used by the cluster.
Assuming you have a fresh cluster, you can introspect the available namespace's by doing the following:
{% highlight console %}
```shell
$ kubectl get namespaces
NAME LABELS
default <none>
{% endhighlight %}
```
### Step Two: Create new namespaces
@@ -55,7 +55,7 @@ Use the file [`namespace-dev.json`](namespace-dev.json) which describes a develo
<!-- BEGIN MUNGE: EXAMPLE namespace-dev.json -->
{% highlight json %}
```json
{
"kind": "Namespace",
@@ -68,30 +68,30 @@ Use the file [`namespace-dev.json`](namespace-dev.json) which describes a develo
}
}
{% endhighlight %}
```
[Download example](namespace-dev.json)
<!-- END MUNGE: EXAMPLE namespace-dev.json -->
Create the development namespace using kubectl.
{% highlight console %}
```shell
$ kubectl create -f docs/admin/namespaces/namespace-dev.json
{% endhighlight %}
```
And then lets create the production namespace using kubectl.
{% highlight console %}
```shell
$ kubectl create -f docs/admin/namespaces/namespace-prod.json
{% endhighlight %}
```
To be sure things are right, let's list all of the namespaces in our cluster.
{% highlight console %}
```shell
$ kubectl get namespaces
NAME LABELS STATUS
@@ -99,7 +99,7 @@ default <none> Active
development name=development Active
production name=production Active
{% endhighlight %}
```
### Step Three: Create pods in each namespace
@@ -112,7 +112,7 @@ To demonstrate this, let's spin up a simple replication controller and pod in th
We first check what is the current context:
{% highlight yaml %}
```yaml
apiVersion: v1
clusters:
@@ -139,37 +139,37 @@ users:
password: h5M0FtUUIflBSdI7
username: admin
{% endhighlight %}
```
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.
{% highlight console %}
```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
{% endhighlight %}
```
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.
{% highlight console %}
```shell
$ kubectl config use-context dev
{% endhighlight %}
```
You can verify your current context by doing the following:
{% highlight console %}
```shell
$ kubectl config view
{% endhighlight %}
```
{% highlight yaml %}
```yaml
apiVersion: v1
clusters:
@@ -206,21 +206,21 @@ users:
password: h5M0FtUUIflBSdI7
username: admin
{% endhighlight %}
```
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 content.
{% highlight console %}
```shell
$ kubectl run snowflake --image=kubernetes/serve_hostname --replicas=2
{% endhighlight %}
```
We have just created a replication controller whose replica size is 2 that is running the pod called snowflake with a basic container that just serves the hostname.
{% highlight console %}
```shell
$ kubectl get rc
CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR REPLICAS
@@ -231,21 +231,21 @@ NAME READY STATUS RESTARTS AGE
snowflake-8w0qn 1/1 Running 0 22s
snowflake-jrpzb 1/1 Running 0 22s
{% endhighlight %}
```
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.
{% highlight console %}
```shell
$ kubectl config use-context prod
{% endhighlight %}
```
The production namespace should be empty.
{% highlight console %}
```shell
$ kubectl get rc
CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR REPLICAS
@@ -253,11 +253,11 @@ CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR REPLICAS
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
{% endhighlight %}
```
Production likes to run cattle, so let's create some cattle pods.
{% highlight console %}
```shell
$ kubectl run cattle --image=kubernetes/serve_hostname --replicas=5
@@ -273,7 +273,7 @@ cattle-qj3yv 1/1 Running 0 12s
cattle-yc7vn 1/1 Running 0 12s
cattle-zz7ea 1/1 Running 0 12s
{% endhighlight %}
```
At this point, it should be clear that the resources users create in one namespace are hidden from the other namespace.