Rancher Research Assistant Sample Outline

## Introduction

## What are namespaces and why would you use them?

* set up scope for naming
    * names must be unique within a namespace
    * names can be reused across namespaces
    * Sources:
        * https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/

* segment the cluster into logical chunks
    * example: separating development life cycle environments (dev, staging, prod)
    * example: separating environments for different projects
    * example: provisioning test environments that can be easily cleaned up
    * Sources:
        * https://kubernetes.io/blog/2016/08/kubernetes-namespaces-use-cases-insights/

* can be used to set policies like RBAC, network policies, and quotas
    * resource usage can be controlled by setting a `ResourceQuota` on resources scoped to the namespace
    * CNI plugins that support network policies can apply rules at the namespace scope
    * RBAC allows for fine-grained control over the permissions at a namespace level with `Role` and `RoleBinding` objects
        * Can be used to set per-namespace policies
        * Can also be used to grant users a level of autonomy by giving them administrative privileges for a specific namespace
    * Sources:
        * https://kubernetes.io/docs/reference/access-authn-authz/rbac/
        * https://kubernetes.io/docs/concepts/services-networking/network-policies/
        * https://kubernetes.io/docs/concepts/policy/resource-quotas/

## Common Namespaces Usage Patterns

* separating workloads by project or team
    * a namespace is created for each project or team
    * works well because it allows for self-management and autonomy via RBAC configuration
    * RBAC also allows for easy group and user management to add or remove access to namespaces when a user is added or removed from a project or team in the real world
    * Can also use quotas to ensure that teams only use a reasonable amount of resources

* defining development environments
    * Can provision distinct environments for development, staging, and production
    * Works well for situations where operating entirely separate clusters doesn't make sense due to resource constraints, project size, policy, etc.
    * RBAC and network policies ensure that users and traffic are isolated to avoid tainting other environments
    * quotas help ensure that more critical environments have prioritized access to resources
    * can deploy the same objects, with the same names to each namespace environment
        * helps with consistency and promoting releases through a deployment pipeline

* isolating customers in a single cluster
    * helps manage resources for different clients separately
    * can track usage on a namespace level to figure out resource consumption for billing
    * can provision the same resources for different consumers in their own namespaces to reduce management complexity

* Sources:
    * https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/#when-to-use-multiple-namespaces
    * https://kubernetes.io/docs/tasks/administer-cluster/namespaces/#understanding-the-motivation-for-using-namespaces
    * https://cloud.google.com/blog/products/gcp/kubernetes-best-practices-organizing-with-namespaces

## Overview of preconfigured Kubernetes namespaces and what they're used for

* default
    * Kubernetes tools are configured to use this namespace when a user doesn't provide one
    * This is the main place to deploy things as a user if you don't create custom namespaces
    * Kubernetes prevents you from deleting this namespace

* kube-public
    * This namespace is supposed to be globally readable, even without authenticating
    * One of the main use cases is to put information here that can be used to bootstrap cluster components.  For example for certificates that different pieces need access to.
    * This is mainly used internally and users shouldn't usually deploy things here

* kube-system
    * This is for Kubernetes internal components
    * Users should avoid deploying normal things here (some components might require deployment to this namespace, but users should be careful and audit these components carefully)
    * Since it is intended to be used by Kubernetes itself, it has fewer restrictions than some namespaces, and is therefore more dangerous to deploy to.

* Sources:
    * https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/#viewing-namespaces
    * https://cloud.google.com/blog/products/gcp/kubernetes-best-practices-organizing-with-namespaces
    * https://stackoverflow.com/questions/45929548/whats-the-kube-public-namespace-for




## How to use namespaces (`kubectl` commands and a hands-on example walking through the following operations)

* Sources:
    * https://kubernetes.io/docs/tasks/administer-cluster/namespaces-walkthrough/
    * https://kubernetes.io/docs/reference/kubectl/cheatsheet/
    * https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/

### viewing the cluster's current namespaces

* To view all namespaces:

```
kubectl get namespaces
```
```
NAME            STATUS    AGE
default         Active    41d
kube-public     Active    41d
kube-system     Active    41d
```

* To get more detail on a single namespace:

```
kubectl describe namespace default
```
```
Name:         default
Labels:       field.cattle.io/projectId=p-cmn9g
Annotations:  cattle.io/status={"Conditions":[{"Type":"ResourceQuotaInit","Status":"True","Message":"","LastUpdateTime":"2018-12-17T23:17:48Z"},{"Type":"InitialRolesPopulated","Status":"True","Message":"","LastUpda...
              field.cattle.io/projectId=c-7tf7d:p-cmn9g
              lifecycle.cattle.io/create.namespace-auth=true
Status:       Active

No resource quota.

No resource limits.
```

### creating new namespaces

* create a new one

```
kubectl create namespace demo-namespace
```
```
namespace "demo-namespace" created
```
```
kubectl get ns
```
```
NAME             STATUS    AGE
default          Active    41d
demo-namespace   Active    2m
kube-public      Active    41d
kube-system      Active    41d
```

* With YAML

```
apiVersion: v1
kind: Namespace
metadata:
  name: demo-namespace
```
```
kubectl apply -f demo-namespace.yml
```
```
kubectl get ns
```
```
NAME             STATUS    AGE
default          Active    41d
demo-namespace   Active    2m
kube-public      Active    41d
kube-system      Active    41d
```

### targeting namespaces in commands with the `--namespace=` option

* what happens without specifying a namespace

```
kubectl create deployment --image nginx demo-nginx
```
```
deployment.extensions "demo-nginx" created
```
```
kubectl describe deployment demo-nginx | grep Namespace
```
```
Namespace:              default
```

* demo name collision

```
kubectl create deployment --image nginx demo-nginx
```
```
Error from server (AlreadyExists): deployments.extensions "demo-nginx" already exists
```

* demo deploying to different namespace

```
kubectl create deployment --image nginx demo-nginx --namespace=demo-namespace
```
```
deployment.extensions "demo-nginx" created
```
```
kubectl describe deployment demo-nginx --namespace=demo-namespace | grep Namespace
```
```
Namespace:              demo-namespace
```

### changing the default namespace by modifying the `kubectl` context

* check contexts

```
kubectl config get-contexts
```
```
CURRENT   NAME      CLUSTER   AUTHINFO   NAMESPACE
*         Default   Default   Default
```

* change namespace associated with a context

```
kubectl config set-context $(kubectl config current-context) --namespace=demo-namespace
```
```
Context "Default" modified.
```

* validate changes

```
kubectl config get-contexts
```
```
CURRENT   NAME      CLUSTER   AUTHINFO   NAMESPACE
*         Default   Default   Default    demo-namespace
```
```
kubectl describe deployment demo-nginx | grep Namespace
```
```
Namespace:              demo-namespace
```

### removing namespaces

* view resources in a namespace first

```
kubectl get all --namespace=demo-namespace
```
```
NAME                              READY     STATUS    RESTARTS   AGE
pod/demo-nginx-676fc7d85d-gkdz2   1/1       Running   0          56m

NAME                         DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/demo-nginx   1         1         1            1           56m

NAME                                    DESIRED   CURRENT   READY     AGE
replicaset.apps/demo-nginx-676fc7d85d   1         1         1         56m
```

* delete ns

```
kubectl delete namespace demo-namespace
```
```
kubectl get namespaces
```
```
NAME            STATUS    AGE
default         Active    41d
kube-public     Active    41d
kube-system     Active    41d
```

* reset context if needed

```
kubectl config set-context $(kubectl config current-context) --namespace=
```
```
Context "Default" modified.
```

* clean up the deployment we made to the default context earlier to reset the cluster state completely

```
kubectl delete deployment demo-nginx
```

## How do Rancher Projects relate to namespaces?

* Rancher-specific functionality
* Projects group namespaces just like namespaces group workloads
    * each namespace belongs to one project
* Helps organize policy that might span across multiple namespaces
* Adds an additional layer so you can segment objects along two dimensions
* out-of-the-box projects are:
    * Default: contains the default namespace
    * System: contains all of the other namespaces that are created for you

* Sources:
    * https://rancher.com/docs/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/

## Conclusion