mirror of
https://github.com/jpetazzo/container.training.git
synced 2026-07-19 04:49:19 +00:00
636a2d5c87
We were using 'kubectl apply' with a YAML snppet. It's valid, but it's quite convoluted. Instead, let's use 'kubectl create namespace'. We can still mention the other method of course.
203 lines
4.2 KiB
Markdown
203 lines
4.2 KiB
Markdown
# Namespaces
|
|
|
|
- We cannot have two resources with the same name
|
|
|
|
(Or can we...?)
|
|
|
|
--
|
|
|
|
- We cannot have two resources *of the same type* with the same name
|
|
|
|
(But it's OK to have a `rng` service, a `rng` deployment, and a `rng` daemon set!)
|
|
|
|
--
|
|
|
|
- We cannot have two resources of the same type with the same name *in the same namespace*
|
|
|
|
(But it's OK to have e.g. two `rng` services in different namespaces!)
|
|
|
|
--
|
|
|
|
- In other words: **the tuple *(type, name, namespace)* needs to be unique**
|
|
|
|
(In the resource YAML, the type is called `Kind`)
|
|
|
|
---
|
|
|
|
## Pre-existing namespaces
|
|
|
|
- If we deploy a cluster with `kubeadm`, we have three namespaces:
|
|
|
|
- `default` (for our applications)
|
|
|
|
- `kube-system` (for the control plane)
|
|
|
|
- `kube-public` (contains one secret used for cluster discovery)
|
|
|
|
- If we deploy differently, we may have different namespaces
|
|
|
|
---
|
|
|
|
## Creating namespaces
|
|
|
|
- Creating a namespace is done with the `kubectl create namespace` command:
|
|
```bash
|
|
kubectl create namespace blue
|
|
```
|
|
|
|
- We can also get fancy and use a very minimal YAML snippet, e.g.:
|
|
```bash
|
|
kubectl apply -f- <<EOF
|
|
apiVersion: v1
|
|
kind: Namespace
|
|
metadata:
|
|
name: blue
|
|
EOF
|
|
```
|
|
|
|
- The two methods above are identical
|
|
|
|
- If we are using a tool like Helm, it will create namespaces automatically
|
|
|
|
---
|
|
|
|
## Using namespaces
|
|
|
|
- We can pass a `-n` or `--namespace` flag to most `kubectl` commands:
|
|
```bash
|
|
kubectl -n blue get svc
|
|
```
|
|
|
|
- We can also use *contexts*
|
|
|
|
- A context is a *(user, cluster, namespace)* tuple
|
|
|
|
- We can manipulate contexts with the `kubectl config` command
|
|
|
|
---
|
|
|
|
## Creating a context
|
|
|
|
- We are going to create a context for the `blue` namespace
|
|
|
|
.exercise[
|
|
|
|
- View existing contexts to see the cluster name and the current user:
|
|
```bash
|
|
kubectl config get-contexts
|
|
```
|
|
|
|
- Create a new context:
|
|
```bash
|
|
kubectl config set-context blue --namespace=blue \
|
|
--cluster=kubernetes --user=kubernetes-admin
|
|
```
|
|
|
|
]
|
|
|
|
We have created a context; but this is just some configuration values.
|
|
|
|
The namespace doesn't exist yet.
|
|
|
|
---
|
|
|
|
## Using a context
|
|
|
|
- Let's switch to our new context and deploy the DockerCoins chart
|
|
|
|
.exercise[
|
|
|
|
- Use the `blue` context:
|
|
```bash
|
|
kubectl config use-context blue
|
|
```
|
|
|
|
- Deploy DockerCoins:
|
|
```bash
|
|
helm install dockercoins
|
|
```
|
|
|
|
]
|
|
|
|
In the last command line, `dockercoins` is just the local path where
|
|
we created our Helm chart before.
|
|
|
|
---
|
|
|
|
## Viewing the deployed app
|
|
|
|
- Let's see if our Helm chart worked correctly!
|
|
|
|
.exercise[
|
|
|
|
- Retrieve the port number allocated to the `webui` service:
|
|
```bash
|
|
kubectl get svc webui
|
|
```
|
|
|
|
- Point our browser to http://X.X.X.X:3xxxx
|
|
|
|
]
|
|
|
|
Note: it might take a minute or two for the app to be up and running.
|
|
|
|
---
|
|
|
|
## Namespaces and isolation
|
|
|
|
- Namespaces *do not* provide isolation
|
|
|
|
- A pod in the `green` namespace can communicate with a pod in the `blue` namespace
|
|
|
|
- A pod in the `default` namespace can communicate with a pod in the `kube-system` namespace
|
|
|
|
- `kube-dns` uses a different subdomain for each namespace
|
|
|
|
- Example: from any pod in the cluster, you can connect to the Kubernetes API with:
|
|
|
|
`https://kubernetes.default.svc.cluster.local:443/`
|
|
|
|
---
|
|
|
|
## Isolating pods
|
|
|
|
- Actual isolation is implemented with *network policies*
|
|
|
|
- Network policies are resources (like deployments, services, namespaces...)
|
|
|
|
- Network policies specify which flows are allowed:
|
|
|
|
- between pods
|
|
|
|
- from pods to the outside world
|
|
|
|
- and vice-versa
|
|
|
|
---
|
|
|
|
## Network policies overview
|
|
|
|
- We can create as many network policies as we want
|
|
|
|
- Each network policy has:
|
|
|
|
- a *pod selector*: "which pods are targeted by the policy?"
|
|
|
|
- lists of ingress and/or egress rules: "which peers and ports are allowed or blocked?"
|
|
|
|
- If a pod is not targeted by any policy, traffic is allowed by default
|
|
|
|
- If a pod is targeted by at least one policy, traffic must be allowed explicitly
|
|
|
|
---
|
|
|
|
## More about network policies
|
|
|
|
- This remains a high level overview of network policies
|
|
|
|
- For more details, check:
|
|
|
|
- the [Kubernetes documentation about network policies](https://kubernetes.io/docs/concepts/services-networking/network-policies/)
|
|
|
|
- this [talk about network policies at KubeCon 2017 US](https://www.youtube.com/watch?v=3gGpMmYeEO8) by [@ahmetb](https://twitter.com/ahmetb)
|