Various fixes (#57)

* fix: fix internal service filename in 08-service section

* fix: typo

* fix: fix markdownlint in CI

* fix: typo

* fix: typo

* fix: `environment variables`, not `environmental`

* fix: typo & missing punctuation

* fix: `much` not `many`

* fix: `lets` not `let's`

* fix: typo

* fix: typo

* fix: phrasing

* fix: typo

* fix: typo

* fix: mysql operator manifest api version

got this error while trying to run it as is:

error: unable to recognize "20-operators/01-mysql-operator.yml": no matches for
kind "Deployment" in version "apps/v1beta1"

* fix: spelling
test-ci
antoinegauvain 4 years ago committed by GitHub
parent 67f4216fd4
commit a5b4383297
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

@ -40,7 +40,6 @@ Let's `apply` this manifest to Kubernetes. This will tell Kubernetes to create t
```sh
$ kubectl apply -f 05-pods/01-simple-pod.yml
pod "simple-pod" created
```
@ -52,7 +51,6 @@ Now list all the `pods` running in Kubernetes. `get` is the `ls` of Kubernetes.
```sh
$ kubectl get pod
NAME READY STATUS RESTARTS AGE
simple-pod 1/1 Running 0 4s
```
@ -63,7 +61,6 @@ Let's have a look at the logs of this `pod`:
```sh
$ kubectl logs simple-pod
2018-10-01T09:21:59 INFO This is simple service in version v0.5.0 listening on port 9876 [at line 142]
2018-10-01T09:23:21 INFO /info serving from 172.17.0.4:9876 has been invoked from 172.17.0.1 [at line 101]
2018-10-01T09:23:21 INFO 200 GET /info (172.17.0.1) 1.38ms [at line 1946]
@ -75,7 +72,6 @@ Our first `pod` is now running. Now `describe` it. `describe` is a `get` on ster
```sh
$ kubectl describe pod simple-pod
[a lot of stuff]
IP: 172.17.0.1
@ -89,8 +85,14 @@ Connect to the cluster, and try to `curl` this ip - `172.17.0.4` in the example.
```sh
$ minikube ssh
$ curl 172.17.0.4:9876/info
_ _
_ _ ( ) ( )
___ ___ (_) ___ (_)| |/') _ _ | |_ __
/' _ ` _ `\| |/' _ `\| || , < ( ) ( )| '_`\ /'__`\
| ( ) ( ) || || ( ) || || |\`\ | (_) || |_) )( ___/
(_) (_) (_)(_)(_) (_)(_)(_) (_)`\___/'(_,__/'`\____)
$ curl 172.17.0.4:9876/info
{"host": "172.17.0.4:9876", "version": "0.5.0", "from": "172.17.0.1"}
```

@ -30,7 +30,6 @@ Let's list all the pods that are in the `env=production`:
```sh
$ kubectl get pods -l env=production
NAME READY STATUS RESTARTS AGE
nginx 1/1 Running 0 13s
simple-pod 1/1 Running 0 13s
@ -40,7 +39,6 @@ Let's list all the pods that are in the `env=production,tier=frontend`:
```sh
$ kubectl get pods -l env=production,tier=frontend
NAME READY STATUS RESTARTS AGE
nginx 1/1 Running 0 1m
```

@ -70,7 +70,6 @@ Firstly, Kubernetes created a `deployment`. We see a lot of 2s. It is the number
```sh
$ kubectl get pod
NAME READY STATUS RESTARTS AGE
simple-deployment-5f7c895db4-wpv6l 1/1 Running 0 1m
simple-deployment-5f7c895db4-wt9j7 1/1 Running 0 1m
@ -82,7 +81,6 @@ Did Kubernetes created something else for us? Let's have a look
```sh
$ kubectl get all
NAME READY STATUS RESTARTS AGE
pod/simple-deployment-5f7c895db4-wpv6l 1/1 Running 0 4m
pod/simple-deployment-5f7c895db4-wt9j7 1/1 Running 0 4m

@ -86,7 +86,7 @@ is central to Kubernetes. It is with those fields that you will tell Kubernetes
Apply the service:
```sh
$ kubectl apply -f 08-service/03-simple-internal-service.yml
$ kubectl apply -f 08-service/03-internal-service.yml
service "simple-service" created
```
@ -101,7 +101,7 @@ Name: simple-internal-service.default.svc.cluster.local
Address: 10.96.31.244
```
Try to curl the `/healthz` url, remember the `ports` we choose in the `service`.
Try to curl the `/health` url, remember the `ports` we choose in the `service`.
Can you access this service from the outside of Kubernetes?

@ -2,7 +2,7 @@
## Introduction
In this section you will lean how to run background tasks using crons & jobs.
In this section you will learn how to run background tasks using crons & jobs.
## `CronJob`
@ -61,7 +61,7 @@ spec:
This manifest is fairly close to a `CronJob`.
Apply it and see what is happening. Does it restarts?
Apply it and see what is happening. Does it restart?
```sh
$ kubectl apply -f 09-cronjob/02-simple-job.yml

@ -56,7 +56,7 @@ root@redis-with-volume-secrets:/etc/foo# ls
password username
```
## Reference the secret by using environmental variables
## Reference the secret by using environment variables
Here we bind the value `username` from the secret `mysecret` to the env variable `SECRET_USERNAME`,
`password` from the secret `mysecret` to the env variable `SECRET_PASSWORD`:

@ -124,7 +124,7 @@ The readiness probe is also used when you do rolling updates. Kubernetes will wa
### Good practices
Most of time having the readiness and liveness probe to be the same is enough. In some cases you might want to them to be different. A good example is a container running a mono-threaded application that accept HTTP calls (who said PHP). Lets say you have an incoming request that will very long to be processed. Your application is not able to receive any other request, as its blocked by the incoming requests. So its not “ready” on the other hand its processing a request so its “alive”.
Most of time having the readiness and liveness probe to be the same is enough. In some cases you might want to them to be different. A good example is a container running a mono-threaded application that accepts HTTP calls (who said PHP). Lets say you have an incoming request that will very long to be processed. Your application is not able to receive any other request, as its blocked by the incoming requests. So its not “ready”; on the other hand its processing a request so its “alive”.
Another tip, your probes should not call dependent services of your application, to prevent cascading failure.

@ -14,11 +14,11 @@ The CPU resource is measured in a number of CPU the pod will use for a given amo
Specifying `0.5` (or `500m`, which means 500 millicpu), will give half of a CPU to your pod.
The RAM resource is measured in the number of bytes of RAM the pod will use.
Specifying `123Mi` (or `128974848`, which means 128974848 bytes), will give that many RAM to your pod.
Specifying `123Mi` (or `128974848`, which means 128974848 bytes), will give that much RAM to your pod.
## `requests` vs `limits`
Kubernetes let's you configure the `requests` and the `limits` for each resource.
Kubernetes lets you configure the `requests` and the `limits` for each resource.
They are put on at the container level:
@ -44,7 +44,7 @@ Let's see in details each of those.
### `requests`
The `requests` is the number that will help Kubernetes schedule your pod on a node were the resources are available.
The `requests` is the number that will help Kubernetes schedule your pod on a node where the resources are available.
Let's take an example. You have 3 nodes:

@ -25,7 +25,7 @@ All the containers of a given pod share the same network, and can share the same
## Use cases
Sidecars are useful for containers that are tightly coupled. A good use case is when you migrate an app from one machine to containers. The application will have a lot of `localhost` or `127.0.0.1` harcoded. So with sidecars you can work around this.
Sidecars are useful for containers that are tightly coupled. A good use case is when you migrate an app from one machine to containers. The application will have a lot of `localhost` or `127.0.0.1` hardcoded. So with sidecars you can work around this.
Another use case is to have sidecars helping the main container, like sending logs to a centralized system, sending the metrics to a specific system, doing SSL termination, etc.

@ -10,9 +10,9 @@ So how can we deploy a stateful application with a persistent storage in Kuberne
## Volumes
We need to review what a volume is before continuing with the deployment of our mysql. As stated above, the disk of a pod is destroyed with it, so it's lost. For a database it'll nice if we could keep the data between restarts of the pods. Here comes the `volume`.
We need to review what a volume is before continuing with the deployment of our mysql. As stated above, the disk of a pod is destroyed with it, so it's lost. For a database it would be nice if we could keep the data between restarts of the pods. Here comes the `volume`.
We can see a `pod` as something that requests CPU & RAM. We can see a `volume` as something that requests a storage on disk. Kubernetes handles a lot of different kind of volumes - 26 has this file hands on is written - from local disk storage to s3.
We can see a `pod` as something that requests CPU & RAM. We can see a `volume` as something that requests a storage on disk. Kubernetes handles a lot of different kind of volumes - 26 as this file hands on is written - from local disk storage to s3.
Here we will use `PersistentVolumeClaim`, it's an abstraction over the hard drives of the Kubernetes nodes - a fancy name for local hard drive.

@ -46,7 +46,7 @@ spec:
storage: 1Gi
```
As you can see the manifest is very close to the one of a deployment. Apply the manigest [01-statefulset.yml](01-statefulset.yml).
As you can see the manifest is very close to the one of a deployment. Apply the manifest [01-statefulset.yml](01-statefulset.yml).
Look at the pods generated, see how they are generated. Connect to one of the pods:

@ -201,7 +201,7 @@ spec:
singular: mysqlbackupschedule
plural: mysqlbackupschedules
---
apiVersion: apps/v1beta1
apiVersion: apps/v1
kind: Deployment
metadata:
name: mysql-operator

@ -23,7 +23,6 @@ kube-system Active 56d
```sh
$ kubectl get all --namespace=kube-system
[lot of stuff]
```

@ -57,6 +57,6 @@ Specify a [PDB](../14-pdb) for your deployments.
## Other good practices
Not directly related to Kubernetes, but still usefull:
Not directly related to Kubernetes, but still useful:
1. If you are in the cloud, use [`terraform`](https://www.terraform.io/) to configure your clusters.

Loading…
Cancel
Save