mirror of
https://github.com/jpetazzo/container.training.git
synced 2026-07-19 12:59:24 +00:00
merge master
This commit is contained in:
@@ -175,34 +175,6 @@ Note: it might take a minute or two for the app to be up and running.
|
||||
|
||||
---
|
||||
|
||||
## 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)
|
||||
|
||||
---
|
||||
|
||||
## Switch back to the default namespace
|
||||
|
||||
- Let's make sure that we don't run future exercises in the `blue` namespace
|
||||
|
||||
@@ -20,6 +20,42 @@ And *then* it is time to look at orchestration!
|
||||
|
||||
---
|
||||
|
||||
## Options for our first production cluster
|
||||
|
||||
- Get a managed cluster from a major cloud provider (AKS, EKS, GKE...)
|
||||
|
||||
(price: $, difficulty: medium)
|
||||
|
||||
- Hire someone to deploy it for us
|
||||
|
||||
(price: $$, difficulty: easy)
|
||||
|
||||
- Do it ourselves
|
||||
|
||||
(price: $-$$$, difficulty: hard)
|
||||
|
||||
---
|
||||
|
||||
## One big cluster vs. multiple small ones
|
||||
|
||||
- Yes, it is possible to have prod+dev in a single cluster
|
||||
|
||||
(and implement good isolation and security with RBAC, network policies...)
|
||||
|
||||
- But it is not a good idea to do that for our first deployment
|
||||
|
||||
- Start with a production cluster + at least a test cluster
|
||||
|
||||
- Implement and check RBAC and isolation on the test cluster
|
||||
|
||||
(e.g. deploy multiple test versions side-by-side)
|
||||
|
||||
- Make sure that all our devs have usable dev clusters
|
||||
|
||||
(wether it's a local minikube or a full-blown multi-node cluster)
|
||||
|
||||
---
|
||||
|
||||
## Stateful services (databases etc.)
|
||||
|
||||
- As a first step, it is wiser to keep stateful services *outside* of the cluster
|
||||
@@ -98,7 +134,7 @@ Sorry Star Trek fans, this is not the federation you're looking for!
|
||||
|
||||
## Developer experience
|
||||
|
||||
*I've put this last, but it's pretty important!*
|
||||
*We've put this last, but it's pretty important!*
|
||||
|
||||
- How do you on-board a new developer?
|
||||
|
||||
|
||||
Reference in New Issue
Block a user