Namespace as kind

cluster/vagrant/config-default.sh

@@ -69,4 +69,4 @@ DNS_REPLICAS=1
 
 # Optional: Enable setting flags for kube-apiserver to turn on behavior in active-dev
 RUNTIME_CONFIG=""
-#RUNTIME_CONFIG="api/v1beta3"
+#RUNTIME_CONFIG="api/v1beta3"

cluster/vagrant/provision-master.sh

@@ -75,7 +75,7 @@ grains:
   cloud_provider: vagrant
   roles:
     - kubernetes-master
-  admission_control: AlwaysAdmit
+  admission_control: NamespaceExists,AlwaysAdmit
   runtime_config: '$(echo "$RUNTIME_CONFIG" | sed -e "s/'/''/g")'
 EOF
 

cmd/kubecfg/kubecfg.go

@@ -379,7 +379,7 @@ func executeAPIRequest(ctx api.Context, method string, c *client.Client) bool {
 			glog.Fatalf("usage: kubecfg [OPTIONS] %s <%s>", method, prettyWireStorage())
 		}
 	case "update":
-		obj, err := c.Verb("GET").Namespace(api.Namespace(ctx)).Suffix(path).Do().Get()
+		obj, err := c.Verb("GET").Namespace(api.NamespaceValue(ctx)).Suffix(path).Do().Get()
 		if err != nil {
 			glog.Fatalf("error obtaining resource version for update: %v", err)
 		}
@@ -405,7 +405,7 @@ func executeAPIRequest(ctx api.Context, method string, c *client.Client) bool {
 		return false
 	}
 
-	r := c.Verb(verb).Namespace(api.Namespace(ctx)).Suffix(path)
+	r := c.Verb(verb).Namespace(api.NamespaceValue(ctx)).Suffix(path)
 	if len(*selector) > 0 {
 		r.ParseSelectorParam("labels", *selector)
 	}

examples/kubernetes-namespaces/README.md

@@ -0,0 +1,191 @@
+## Kubernetes Namespaces
+
+Kubernetes Namespaces help different projects, teams, or customers to share a Kubernetes cluster.
+
+It does this by providing the following:
+
+1. A scope for [Names](identifiers.md).
+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.
+
+### Step Zero: Prerequisites
+
+This example assumes the following:
+
+1. You have an existing Kubernetes cluster.
+2. You have a basic understanding of Kubernetes pods, services, and replication controllers.
+
+### Step One: 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 replication controllers used by the cluster.
+
+Assuming you have a fresh cluster, you can introspect the available namespace's by doing the following:
+
+```shell
+$ cluster/kubectl.sh get namespaces
+NAME                LABELS
+default             <none>
+```
+
+### Step Two: 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 replication-controllers
+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 replication controllers 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 `examples/kubernetes-namespaces/namespace-dev.json` which describes a development namespace:
+
+```js
+{
+  "kind": "Namespace",
+  "apiVersion":"v1beta1",
+  "id": "development",
+  "spec": {},
+  "status": {},
+  "labels": {
+    "name": "development"
+  },
+}
+```
+
+Create the development namespace using kubectl.
+
+```shell
+$ cluster/kubectl.sh create -f examples/kubernetes-namespaces/namespace-dev.json
+```
+
+And then lets create the production namespace using kubectl.
+
+```shell
+$ cluster/kubectl.sh create -f examples/kubernetes-namespaces/namespace-prod.json
+```
+
+To be sure things are right, let's list all of the namespaces in our cluster.
+
+```shell
+$ cluster/kubectl.sh get namespaces
+NAME                LABELS
+default             <none>
+development         name=development
+production          name=production
+```
+
+### Step Three: Create pods in each namespace
+
+A Kubernetes namespace provides the scope for pods, services, and replication controllers 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 replication controller and pod in the development namespace.
+
+The first step is to define a context for the kubectl client to work in each namespace.
+
+```shell
+$ cluster/kubectl.sh config set-context dev --namespace=development
+$ cluster/kubectl.sh config set-context prod --namespace=production
+```
+
+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.
+
+```shell
+$ cluster/kubectl.sh config use-context dev
+```
+
+You can verify your current context by doing the following:
+
+```shell
+$ cluster/kubectl.sh config view
+clusters: {}
+contexts:
+  dev:
+    cluster: ""
+    namespace: development
+    user: ""
+  prod:
+    cluster: ""
+    namespace: production
+    user: ""
+current-context: dev
+preferences: {}
+users: {}
+```
+
+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
+$ cluster/kubectl.sh run-container 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
+cluster/kubectl.sh get rc
+CONTROLLER          CONTAINER(S)        IMAGE(S)                    SELECTOR                  REPLICAS
+snowflake           snowflake           kubernetes/serve_hostname   run-container=snowflake   2
+
+$ cluster/kubectl.sh get pods
+POD                 IP                  CONTAINER(S)        IMAGE(S)                    HOST                    LABELS                    STATUS
+snowflake-fplln     10.246.0.5          snowflake           kubernetes/serve_hostname   10.245.1.3/10.245.1.3   run-container=snowflake   Running
+snowflake-gziey     10.246.0.4          snowflake           kubernetes/serve_hostname   10.245.1.3/10.245.1.3   run-container=snowflake   Running
+```
+
+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
+$ cluster/kubectl.sh config use-context prod
+```
+
+The production namespace should be empty.
+
+```shell
+$ cluster/kubectl.sh get rc
+CONTROLLER          CONTAINER(S)        IMAGE(S)            SELECTOR            REPLICAS
+
+$ cluster/kubectl.sh get pods
+POD                 IP                  CONTAINER(S)        IMAGE(S)            HOST                LABELS              STATUS
+```
+
+Production likes to run cattle, so let's create some cattle pods.
+
+```shell
+$ cluster/kubectl.sh run-container cattle --image=kubernetes/serve_hostname --replicas=5
+
+$ cluster/kubectl.sh get rc
+CONTROLLER          CONTAINER(S)        IMAGE(S)                    SELECTOR               REPLICAS
+cattle              cattle              kubernetes/serve_hostname   run-container=cattle   5
+
+$ cluster/kubectl.sh get pods
+POD                 IP                  CONTAINER(S)        IMAGE(S)                    HOST                    LABELS                 STATUS
+cattle-0133o        10.246.0.7          cattle              kubernetes/serve_hostname   10.245.1.3/10.245.1.3   run-container=cattle   Running
+cattle-hh2gd        10.246.0.10         cattle              kubernetes/serve_hostname   10.245.1.3/10.245.1.3   run-container=cattle   Running
+cattle-ls6k1        10.246.0.9          cattle              kubernetes/serve_hostname   10.245.1.3/10.245.1.3   run-container=cattle   Running
+cattle-nyxxv        10.246.0.8          cattle              kubernetes/serve_hostname   10.245.1.3/10.245.1.3   run-container=cattle   Running
+cattle-oh43e        10.246.0.6          cattle              kubernetes/serve_hostname   10.245.1.3/10.245.1.3   run-container=cattle   Running
+```
+
+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.

examples/kubernetes-namespaces/namespace-dev.json

@@ -0,0 +1,10 @@
+{
+  "kind": "Namespace",
+  "apiVersion":"v1beta1",  
+  "id": "development",
+  "spec": {},
+  "status": {},
+  "labels": {
+    "name": "development"
+  },  
+}

examples/kubernetes-namespaces/namespace-prod.json

@@ -0,0 +1,10 @@
+{
+  "kind": "Namespace",
+  "apiVersion":"v1beta1",  
+  "id": "production",
+  "spec": {},
+  "status": {},
+  "labels": {
+    "name": "production"
+  },  
+}

pkg/api/context.go

@@ -63,8 +63,8 @@ func NamespaceFrom(ctx Context) (string, bool) {
 	return namespace, ok
 }
 
-// Namespace returns the value of the namespace key on the ctx, or the empty string if none
-func Namespace(ctx Context) string {
+// NamespaceValue returns the value of the namespace key on the ctx, or the empty string if none
+func NamespaceValue(ctx Context) string {
 	namespace, _ := NamespaceFrom(ctx)
 	return namespace
 }

pkg/api/context_test.go

@@ -61,7 +61,7 @@ func TestValidNamespace(t *testing.T) {
 	}
 
 	ctx = api.NewContext()
-	ns := api.Namespace(ctx)
+	ns := api.NamespaceValue(ctx)
 	if ns != "" {
 		t.Errorf("Expected the empty string")
 	}

pkg/api/latest/latest.go

@@ -122,8 +122,9 @@ func init() {
 	// the list of kinds that are scoped at the root of the api hierarchy
 	// if a kind is not enumerated here, it is assumed to have a namespace scope
 	kindToRootScope := map[string]bool{
-		"Node":   true,
-		"Minion": true,
+		"Node":      true,
+		"Minion":    true,
+		"Namespace": true,
 	}
 
 	// enumerate all supported versions, get the kinds, and register with the mapper how to address our resources

pkg/api/meta/restmapper.go

@@ -51,7 +51,7 @@ var RESTScopeNamespaceLegacy = &restScope{
 
 var RESTScopeNamespace = &restScope{
 	name:             RESTScopeNameNamespace,
-	paramName:        "ns",
+	paramName:        "namespaces",
 	paramPath:        true,
 	paramDescription: "object name and auth scope, such as for teams and projects",
 }

pkg/api/register.go

@@ -50,6 +50,8 @@ func init() {
 		&ResourceQuota{},
 		&ResourceQuotaList{},
 		&ResourceQuotaUsage{},
+		&Namespace{},
+		&NamespaceList{},
 	)
 	// Legacy names are supported
 	Scheme.AddKnownTypeWithName("", "Minion", &Node{})
@@ -81,3 +83,5 @@ func (*LimitRangeList) IsAnAPIObject()            {}
 func (*ResourceQuota) IsAnAPIObject()             {}
 func (*ResourceQuotaList) IsAnAPIObject()         {}
 func (*ResourceQuotaUsage) IsAnAPIObject()        {}
+func (*Namespace) IsAnAPIObject()                 {}
+func (*NamespaceList) IsAnAPIObject()             {}

pkg/api/rest/types.go

@@ -118,7 +118,7 @@ type nodeStrategy struct {
 // objects.
 var Nodes RESTCreateStrategy = nodeStrategy{api.Scheme, api.SimpleNameGenerator}
 
-// NamespaceScoped is false for services.
+// NamespaceScoped is false for nodes.
 func (nodeStrategy) NamespaceScoped() bool {
 	return false
 }
@@ -134,3 +134,30 @@ func (nodeStrategy) Validate(obj runtime.Object) errors.ValidationErrorList {
 	node := obj.(*api.Node)
 	return validation.ValidateMinion(node)
 }
+
+// namespaceStrategy implements behavior for nodes
+type namespaceStrategy struct {
+	runtime.ObjectTyper
+	api.NameGenerator
+}
+
+// Namespaces is the default logic that applies when creating and updating Namespace
+// objects.
+var Namespaces RESTCreateStrategy = namespaceStrategy{api.Scheme, api.SimpleNameGenerator}
+
+// NamespaceScoped is false for namespaces.
+func (namespaceStrategy) NamespaceScoped() bool {
+	return false
+}
+
+// ResetBeforeCreate clears fields that are not allowed to be set by end users on creation.
+func (namespaceStrategy) ResetBeforeCreate(obj runtime.Object) {
+	_ = obj.(*api.Namespace)
+	// Namespace allow *all* fields, including status, to be set.
+}
+
+// Validate validates a new namespace.
+func (namespaceStrategy) Validate(obj runtime.Object) errors.ValidationErrorList {
+	namespace := obj.(*api.Namespace)
+	return validation.ValidateNamespace(namespace)
+}

pkg/api/types.go

@@ -833,6 +833,35 @@ type NodeList struct {
 	Items []Node `json:"items"`
 }
 
+// NamespaceSpec describes the attributes on a Namespace
+type NamespaceSpec struct {
+}
+
+// NamespaceStatus is information about the current status of a Namespace.
+type NamespaceStatus struct {
+}
+
+// A namespace provides a scope for Names.
+// Use of multiple namespaces is optional
+type Namespace struct {
+	TypeMeta   `json:",inline"`
+	ObjectMeta `json:"metadata,omitempty"`
+
+	// Spec defines the behavior of the Namespace.
+	Spec NamespaceSpec `json:"spec,omitempty"`
+
+	// Status describes the current status of a Namespace
+	Status NamespaceStatus `json:"status,omitempty"`
+}
+
+// NamespaceList is a list of Namespaces.
+type NamespaceList struct {
+	TypeMeta `json:",inline"`
+	ListMeta `json:"metadata,omitempty"`
+
+	Items []Namespace `json:"items"`
+}
+
 // Binding is written by a scheduler to cause a pod to be bound to a host.
 type Binding struct {
 	TypeMeta   `json:",inline"`