After running 1-4, I end up with the following deployments:

kubectl get deployment
NAME               DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
customnginx        4         4         4            4           3h
envtest            1         1         1            1           1h
multitool          1         1         1            1           4h
nginx              4         4         4            4           3h
nginx-deployment   1         1         1            1           43m

I clutters the image for the student that there are things laying around which is not part of the current exercise.

Get inspired by:
https://github.com/KamranAzeem/kubernetes-katas/blob/master/04-init-and-multi-container-pods.md

In the README file there is a link to the deployments-ingress.md, but you changed the file name but didn't change the path in README, and when you click it, it doesn't go to right path, it sends you to old file deployments-loadbalancing.md

Kubernetes recommends some labels for all resources:
https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/

We should consider changing the run label to app.kubernetes.io/component - of if we want to keep it short: component.

In some of the labs, you use the NodePort to connect to the frontend. If done through a PROXY the dynamic content is cached. The frontend should set appropriate headers to fix this.

I find the exercise having too much repetition with nodeport and multitool etc.
I acknowledge the benefits of having to redo some of the old exercises, but it makes the bar too steep for some people.
I would like to have a yaml file with a public LB IP attached and then having the option to either go with repetition, or jump ahead and use the public IP for simplicity.

We need a way to integrate kubctl in the bash as well, so a script that makes bash register kubctl as well would be nice.

Hi.
I have recently been going through the training exercises you've made here. During 06-traefik-ingress exercises, I ran into issues with deploying the traefik ingress controller to my kubernetes cluster.
From inspecting the logs of the pod, it provided some information regarding configuration flags:

$ kubectl logs traefik-ingress-controller-b85d96bd6-nb2mf -n kube-system
2021/10/13 14:33:48 command traefik error: failed to decode configuration from flags: field not found, node: kubernetes

From inspecting the manifest file ./ingress-traefik/traefik-deployment.yaml, I discovered that the 'traefik-ingress-controller' deployment does not refer to a specific tag of the traefik container image.
This makes it use the latest tag by default which, at the time of writing this bug report, refers to v2.5.3 of traefik.

I then modified the above mentioned manifest file, changing the deployment's specification to use traefik:v1.7 as the container image instead, after which the pod was created successfully.

I suggest that the manifest is updated to use a specific tag of the traefik container image.

https://github.com/eficode-academy/kubernetes-katas/blob/master/03-rolling-updates.md#undo-update

We are asking them to do a thing we would not recommend in real life. That is not good.

things like extensions/v1beta1 is deprecated and needs to be replaced by the right api versions

| grep IP, does not give the output as described.

The small bashloop is smally wrong. The pods should have different names :)

"Some" of the resources in our training material uses e.g. the extensions/v1beta1 apiVersion. That's deprecated in K8s v1.16 (can be enabled with flags..) and will be removed in v1.18.

We should "probably" upgrade our resources to use the apps/.. apiVersions.

In exercise frontend-ingress.md you get a warning when applying frontend-ingress.yaml:

Warning: annotation "kubernetes.io/ingress.class" is deprecated, please use 'spec.ingressClassName' instead

We should make the change in the exercise files.

Previously the latter half went like this:

(Optional) Creating your own App with a Health Check

Any (http) code greater than or equal to 200 and less than 400 indicates success. Any other code indicates failure.

Let's go back to our applications, and create a custom health check.

Create an endpoint that does something customized, and returns 200. (Make sure it can fail and return an error above 500 if you want to test).

Push the container, and create a deployment for it and include:

  livenessProbe:
      httpGet:
        path: /healthz #Your endpoint for health check.
        port: 8080
        httpHeaders:
        - name: X-Custom-Header
          value: Awesome
      initialDelaySeconds: 3
      periodSeconds: 3

Verify that the healthcheck fails when conditions are not met.

This concludes the exercise for health checks!

Supposedly it was part of a bigger set of exercises? It would probably be nice to provide them with a demo application, that they could make fail in some way.

I'm removing for now because it leaves the exercise in a weird state, and the first half actually seems to be a nice little taster.

.. it leaves the deployment with connection to backend

Missing a step to add

          env:
            - name: BACKEND_HOST
              value: backend
            - name: BACKEND_PORT
              value: '5000'
          

The cleanup step does not remove the service created by the optional step

Either kubectl delete or kubectl delete -f for simplicity sake.

As per feedback:

I would like to have a cheat sheet for both Docker and Kubernetes in the training git. A short version for the things that are covered in the training.

Just like https://github.com/praqma-training/docker-exercises/blob/master/labs/README.md

In today training, the training machine was using the following version:

$ helm version
version.BuildInfo{Version:"v3.0.2", GitCommit:"19e47ee3283ae98139d98460de796c1be1e3975f", GitTreeState:"clean", GoVersion:"go1.13.5"}

However, the guide is considering the previous major version, so its asking to execute:

$ helm init

It would be needed to replace it or at least add info for helm v3 with the commands below:

$ helm repo add stable https://kubernetes-charts.storage.googleapis.com
$ helm install invinvible-serval stable/mysql

Bad create

It would make it easier for people to see the load balancing.

One could also disect the name of the pod as
name of deployment, name of replicaset, name of pod

Making it easier to understand.

E.g.

apiVersion: extensions/v1beta1
kind: Deployment

This is no longer correct - going back several version, deployments have been in 'apps/v1'

The same may apply to other resource types.

The first exercise is too extensive and should be split into two parts.

1. simple creation using the create command
2. creating and applying a manifest

The explanation needed during trainings for crating a manifest is rather extensive, and it is better to simply get started with manual creation, and then take the manifest part afterwards.