This commit is contained in:
Jerome Petazzoni
2019-05-25 19:44:59 -05:00
11 changed files with 206 additions and 130 deletions

View File

@@ -69,3 +69,46 @@
`Error: release loitering-otter failed: services "hasher" already exists`
- To avoid naming conflicts, we will deploy the application in another *namespace*
---
## Switching to another namespace
- We can create a new namespace and switch to it
(Helm will automatically use the namespace specified in our context)
- We can also tell Helm which namespace to use
.exercise[
- Tell Helm to use a specific namespace:
```bash
helm install dockercoins --namespace=magenta
```
]
---
## Checking our new copy of DockerCoins
- We can check the worker logs, or the web UI
.exercise[
- Retrieve the NodePort number of the web UI:
```bash
kubectl get service webui --namespace=magenta
```
- Open it in a web browser
- Look at the worker logs:
```bash
kubectl logs deploy/worker --tail=10 --follow --namespace=magenta
```
]
Note: it might take a minute or two for the worker to start.

View File

@@ -61,7 +61,7 @@ There are many possibilities!
- creates a new custom type, `Remote`, exposing a git+ssh server
- deploy by pushing YAML or Helm Charts to that remote
- deploy by pushing YAML or Helm charts to that remote
- Replacing built-in types with CRDs

View File

@@ -234,6 +234,6 @@
(see the [documentation](https://github.com/hasura/gitkube/blob/master/docs/remote.md) for more details)
- Gitkube can also deploy Helm Charts
- Gitkube can also deploy Helm charts
(instead of raw YAML files)

View File

@@ -104,7 +104,7 @@
## Introspection vs. documentation
- We can access the same information by reading the [API documentation](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.14/)
- We can access the same information by reading the [API documentation](https://kubernetes.io/docs/reference/#api-reference)
- The API documentation is usually easier to read, but:

View File

@@ -14,15 +14,15 @@
## Differences with Helm
- Helm Charts use placeholders `{{ like.this }}`
- Helm charts use placeholders `{{ like.this }}`
- Kustomize "bases" are standard Kubernetes YAML
- It is possible to use an existing set of YAML as a Kustomize base
- As a result, writing a Helm Chart is more work ...
- As a result, writing a Helm chart is more work ...
- ... But Helm Charts are also more powerful; e.g. they can:
- ... But Helm charts are also more powerful; e.g. they can:
- use flags to conditionally include resources or blocks
@@ -88,11 +88,11 @@
- Change to a new directory:
```bash
mkdir ~/kubercoins
cd ~/kubercoins
mkdir ~/kustomcoins
cd ~/kustomcoins
```
- Run `ship init` with the kubercoins repository:
- Run `ship init` with the kustomcoins repository:
```bash
ship init https://github.com/jpetazzo/kubercoins
```
@@ -146,3 +146,49 @@
- We will create a new copy of DockerCoins in another namespace
---
## Deploy DockerCoins with Kustomize
.exercise[
- Create a new namespace:
```bash
kubectl create namespace kustomcoins
```
- Deploy DockerCoins:
```bash
kubectl apply -f rendered.yaml --namespace=kustomcoins
```
- Or, with Kubernetes 1.14, you can also do this:
```bash
kubectl apply -k overlays/ship --namespace=kustomcoins
```
]
---
## Checking our new copy of DockerCoins
- We can check the worker logs, or the web UI
.exercise[
- Retrieve the NodePort number of the web UI:
```bash
kubectl get service webui --namespace=kustomcoins
```
- Open it in a web browser
- Look at the worker logs:
```bash
kubectl logs deploy/worker --tail=10 --follow --namespace=kustomcoins
```
]
Note: it might take a minute or two for the worker to start.

View File

@@ -120,7 +120,7 @@
- Team "build" ships ready-to-run manifests
(YAML, Helm Charts, Kustomize ...)
(YAML, Helm charts, Kustomize ...)
- Team "run" adjusts some parameters and monitors the application

View File

@@ -1,26 +1,65 @@
# Namespaces
- We would like to deploy another copy of DockerCoins on our cluster
- We could rename all our deployments and services:
hasher → hasher2, redis → redis2, rng → rng2, etc.
- That would require updating the code
- There as to be a better way!
--
- As hinted by the title of this section, we will use *namespaces*
---
## Identifying a resource
- We cannot have two resources with the same name
(Or can we...?)
(or can we...?)
--
- We cannot have two resources *of the same type* with the same name
- We cannot have two resources *of the same kind* with the same name
(But it's OK to have a `rng` service, a `rng` deployment, and a `rng` daemon set!)
(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*
- We cannot have two resources of the same kind with the same name *in the same namespace*
(But it's OK to have e.g. two `rng` services in different namespaces!)
(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**
- Except for resources that exist at the *cluster scope*
(In the resource YAML, the type is called `Kind`)
(these do not belong to a namespace)
---
## Uniquely identifying a resource
- For *namespaced* resources:
the tuple *(kind, name, namespace)* needs to be unique
- For resources at the *cluster scope*:
the tuple *(kind, name)* needs to be unique
.exercise[
- List resource types again, and check the NAMESPACED column:
```bash
kubectl api-resources
```
]
---
@@ -59,7 +98,7 @@
- The two methods above are identical
- If we are using a tool like Helm, it will create namespaces automatically
- Some tools like Helm will create namespaces automatically when needed
---
@@ -168,41 +207,27 @@
---
## Deploy DockerCoins with Helm
## Deploying DockerCoins with YAML files
*Follow these instructions if you previously created a Helm Chart.*
- The GitHub repository `jpetazzo/kubercoins` contains everything we need!
.exercise[
- Deploy DockerCoins:
- Clone the kubercoins repository:
```bash
helm install dockercoins
git clone https://github.com/jpetazzo/kubercoins
```
- Create all the DockerCoins resources:
```bash
kubectl create -f kubercoins
```
]
In the last command line, `dockercoins` is just the local path where
we created our Helm chart before.
If the argument behind `-f` is a directory, all the files in that directory are processed.
---
## Deploy DockerCoins with Kustomize
*Follow these instructions if you previously created a Kustomize overlay.*
.exercise[
- Deploy DockerCoins:
```bash
kubectl apply -f rendered.yaml
```
- Or, with Kubernetes 1.14, you can also do this:
```bash
kubectl apply -k overlays/ship
```
]
The subdirectories are *not* processed, unless we also add the `-R` flag.
---
@@ -221,46 +246,7 @@ we created our Helm chart before.
]
If the graph shows up but stays at zero, check the next slide!
---
## Troubleshooting
If did the exercices from the chapter about labels and selectors,
the app that you just created may not work, because the `rng` service
selector has `enabled=yes` but the pods created by the `rng` daemon set
do not have that label.
How can we troubleshoot that?
- Query individual services manually
→ the `rng` service will time out
- Inspect the services with `kubectl describe service`
→ the `rng` service will have an empty list of backends
---
## Fixing the broken service
The easiest option is to add the `enabled=yes` label to the relevant pods.
.exercise[
- Add the `enabled` label to the pods of the `rng` daemon set:
```bash
kubectl label pods -l app=rng enabled=yes
```
]
The *best* option is to change either the service definition, or the
daemon set definition, so that their respective selectors match correctly.
*This is left as an exercise for the reader!*
If the graph shows up but stays at zero, give it a minute or two!
---

View File

@@ -190,11 +190,11 @@ We need to:
---
## Helm Charts to the rescue
## Helm charts to the rescue
- To make our lives easier, we are going to use a Helm Chart
- To make our lives easier, we are going to use a Helm chart
- The Helm Chart will take care of all the steps explained above
- The Helm chart will take care of all the steps explained above
(including some extra features that we don't need, but won't hurt)
@@ -254,13 +254,13 @@ class: extra-details
(a "release" is a unique name given to an app deployed with Helm)
- `stable/prometheus` → ... of the Chart `prometheus` in repo `stable`
- `stable/prometheus` → ... of the chart `prometheus` in repo `stable`
- `--install` → if the app doesn't exist, create it
- `--namespace kube-system` → put it in that specific namespace
- And set the following *values* when rendering the Chart's templates:
- And set the following *values* when rendering the chart's templates:
- `server.service.type=NodePort` → expose the Prometheus server with a NodePort
- `server.service.nodePort=30090` → set the specific NodePort number to use

View File

@@ -23,52 +23,53 @@ chapters:
- shared/connecting.md
- k8s/versions-k8s.md
- shared/sampleapp.md
# - shared/composescale.md
# - shared/hastyconclusions.md
#- shared/composescale.md
#- shared/hastyconclusions.md
- shared/composedown.md
- k8s/concepts-k8s.md
- shared/declarative.md
- k8s/declarative.md
- - k8s/kubenet.md
- k8s/kubectlget.md
- k8s/kubenet.md
- - k8s/kubectlget.md
- k8s/setup-k8s.md
- k8s/kubectlrun.md
- k8s/deploymentslideshow.md
- k8s/kubectlexpose.md
- - k8s/shippingimages.md
# - k8s/buildshiprun-selfhosted.md
#- k8s/buildshiprun-selfhosted.md
- k8s/buildshiprun-dockerhub.md
- k8s/ourapponkube.md
# - k8s/kubectlproxy.md
# - k8s/localkubeconfig.md
# - k8s/accessinternal.md
#- k8s/kubectlproxy.md
#- k8s/localkubeconfig.md
#- k8s/accessinternal.md
- k8s/dashboard.md
# - k8s/kubectlscale.md
#- k8s/kubectlscale.md
- k8s/scalingdockercoins.md
- shared/hastyconclusions.md
- k8s/daemonset.md
- - k8s/rollout.md
# - k8s/healthchecks.md
- k8s/namespaces.md
#- k8s/kustomize.md
#- k8s/helm.md
#- k8s/create-chart.md
#- k8s/healthchecks.md
- k8s/logs-cli.md
- k8s/logs-centralized.md
#- - k8s/helm.md
# - k8s/create-chart.md
# - k8s/kustomize.md
# - k8s/namespaces.md
# - k8s/netpol.md
# - k8s/authn-authz.md
#- - k8s/ingress.md
# - k8s/gitworkflows.md
#- k8s/netpol.md
#- k8s/authn-authz.md
#- k8s/ingress.md
#- k8s/gitworkflows.md
- k8s/prometheus.md
#- - k8s/volumes.md
# - k8s/build-with-docker.md
# - k8s/build-with-kaniko.md
# - k8s/configuration.md
#- - k8s/owners-and-dependents.md
# - k8s/extending-api.md
# - k8s/statefulsets.md
# - k8s/local-persistent-volumes.md
# - k8s/portworx.md
#- k8s/volumes.md
#- k8s/build-with-docker.md
#- k8s/build-with-kaniko.md
#- k8s/configuration.md
#- k8s/owners-and-dependents.md
#- k8s/extending-api.md
#- k8s/statefulsets.md
#- k8s/local-persistent-volumes.md
#- k8s/portworx.md
#- k8s/staticpods.md
- - k8s/whatsnext.md
- k8s/links.md
- shared/thankyou.md

View File

@@ -47,14 +47,14 @@ chapters:
# - k8s/scalingdockercoins.md
# - shared/hastyconclusions.md
- k8s/daemonset.md
- - k8s/rollout.md
- k8s/rollout.md
- - k8s/namespaces.md
- k8s/kustomize.md
- k8s/helm.md
- k8s/create-chart.md
- k8s/healthchecks.md
- k8s/logs-cli.md
- k8s/logs-centralized.md
- - k8s/helm.md
#- k8s/create-chart.md
- k8s/kustomize.md
- k8s/namespaces.md
- k8s/netpol.md
- k8s/authn-authz.md
- - k8s/ingress.md

View File

@@ -29,8 +29,8 @@ chapters:
- k8s/concepts-k8s.md
- shared/declarative.md
- k8s/declarative.md
- - k8s/kubenet.md
- k8s/kubectlget.md
- k8s/kubenet.md
- - k8s/kubectlget.md
- k8s/setup-k8s.md
- k8s/kubectlrun.md
- k8s/deploymentslideshow.md
@@ -48,14 +48,14 @@ chapters:
- shared/hastyconclusions.md
- - k8s/daemonset.md
- k8s/rollout.md
- k8s/healthchecks.md
- k8s/namespaces.md
- k8s/kustomize.md
#- k8s/helm.md
#- k8s/create-chart.md
- - k8s/healthchecks.md
- k8s/logs-cli.md
- k8s/logs-centralized.md
- - k8s/helm.md
#- k8s/create-chart.md
- k8s/kustomize.md
- k8s/namespaces.md
- k8s/netpol.md
#- k8s/netpol.md
- k8s/authn-authz.md
- - k8s/ingress.md
#- k8s/gitworkflows.md
@@ -65,11 +65,11 @@ chapters:
#- k8s/build-with-kaniko.md
- k8s/configuration.md
#- k8s/owners-and-dependents.md
- k8s/extending-api.md
#- k8s/extending-api.md
- - k8s/statefulsets.md
- k8s/local-persistent-volumes.md
- k8s/portworx.md
- k8s/staticpods.md
#- k8s/staticpods.md
- - k8s/whatsnext.md
- k8s/links.md
- shared/thankyou.md