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
This commit is contained in:
parent
67f4216fd4
commit
a5b4383297
|
@ -40,7 +40,6 @@ Let's `apply` this manifest to Kubernetes. This will tell Kubernetes to create t
|
||||||
|
|
||||||
```sh
|
```sh
|
||||||
$ kubectl apply -f 05-pods/01-simple-pod.yml
|
$ kubectl apply -f 05-pods/01-simple-pod.yml
|
||||||
|
|
||||||
pod "simple-pod" created
|
pod "simple-pod" created
|
||||||
```
|
```
|
||||||
|
|
||||||
|
@ -52,7 +51,6 @@ Now list all the `pods` running in Kubernetes. `get` is the `ls` of Kubernetes.
|
||||||
|
|
||||||
```sh
|
```sh
|
||||||
$ kubectl get pod
|
$ kubectl get pod
|
||||||
|
|
||||||
NAME READY STATUS RESTARTS AGE
|
NAME READY STATUS RESTARTS AGE
|
||||||
simple-pod 1/1 Running 0 4s
|
simple-pod 1/1 Running 0 4s
|
||||||
```
|
```
|
||||||
|
@ -63,7 +61,6 @@ Let's have a look at the logs of this `pod`:
|
||||||
|
|
||||||
```sh
|
```sh
|
||||||
$ kubectl logs simple-pod
|
$ 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: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 /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]
|
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
|
```sh
|
||||||
$ kubectl describe pod simple-pod
|
$ kubectl describe pod simple-pod
|
||||||
|
|
||||||
[a lot of stuff]
|
[a lot of stuff]
|
||||||
|
|
||||||
IP: 172.17.0.1
|
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
|
```sh
|
||||||
$ minikube ssh
|
$ 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"}
|
{"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
|
```sh
|
||||||
$ kubectl get pods -l env=production
|
$ kubectl get pods -l env=production
|
||||||
|
|
||||||
NAME READY STATUS RESTARTS AGE
|
NAME READY STATUS RESTARTS AGE
|
||||||
nginx 1/1 Running 0 13s
|
nginx 1/1 Running 0 13s
|
||||||
simple-pod 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
|
```sh
|
||||||
$ kubectl get pods -l env=production,tier=frontend
|
$ kubectl get pods -l env=production,tier=frontend
|
||||||
|
|
||||||
NAME READY STATUS RESTARTS AGE
|
NAME READY STATUS RESTARTS AGE
|
||||||
nginx 1/1 Running 0 1m
|
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
|
```sh
|
||||||
$ kubectl get pod
|
$ kubectl get pod
|
||||||
|
|
||||||
NAME READY STATUS RESTARTS AGE
|
NAME READY STATUS RESTARTS AGE
|
||||||
simple-deployment-5f7c895db4-wpv6l 1/1 Running 0 1m
|
simple-deployment-5f7c895db4-wpv6l 1/1 Running 0 1m
|
||||||
simple-deployment-5f7c895db4-wt9j7 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
|
```sh
|
||||||
$ kubectl get all
|
$ kubectl get all
|
||||||
|
|
||||||
NAME READY STATUS RESTARTS AGE
|
NAME READY STATUS RESTARTS AGE
|
||||||
pod/simple-deployment-5f7c895db4-wpv6l 1/1 Running 0 4m
|
pod/simple-deployment-5f7c895db4-wpv6l 1/1 Running 0 4m
|
||||||
pod/simple-deployment-5f7c895db4-wt9j7 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:
|
Apply the service:
|
||||||
|
|
||||||
```sh
|
```sh
|
||||||
$ kubectl apply -f 08-service/03-simple-internal-service.yml
|
$ kubectl apply -f 08-service/03-internal-service.yml
|
||||||
service "simple-service" created
|
service "simple-service" created
|
||||||
```
|
```
|
||||||
|
|
||||||
|
@ -101,7 +101,7 @@ Name: simple-internal-service.default.svc.cluster.local
|
||||||
Address: 10.96.31.244
|
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?
|
Can you access this service from the outside of Kubernetes?
|
||||||
|
|
||||||
|
|
|
@ -2,7 +2,7 @@
|
||||||
|
|
||||||
## Introduction
|
## 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`
|
## `CronJob`
|
||||||
|
|
||||||
|
@ -61,7 +61,7 @@ spec:
|
||||||
|
|
||||||
This manifest is fairly close to a `CronJob`.
|
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
|
```sh
|
||||||
$ kubectl apply -f 09-cronjob/02-simple-job.yml
|
$ kubectl apply -f 09-cronjob/02-simple-job.yml
|
||||||
|
|
|
@ -56,7 +56,7 @@ root@redis-with-volume-secrets:/etc/foo# ls
|
||||||
password username
|
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`,
|
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`:
|
`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
|
### 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). Let’s say you have an incoming request that will very long to be processed. Your application is not able to receive any other request, as it’s blocked by the incoming requests. So it’s not “ready” on the other hand it’s processing a request so it’s “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). Let’s say you have an incoming request that will very long to be processed. Your application is not able to receive any other request, as it’s blocked by the incoming requests. So it’s not “ready”; on the other hand it’s processing a request so it’s “alive”.
|
||||||
|
|
||||||
Another tip, your probes should not call dependent services of your application, to prevent cascading failure.
|
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.
|
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.
|
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`
|
## `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:
|
They are put on at the container level:
|
||||||
|
|
||||||
|
@ -44,7 +44,7 @@ Let's see in details each of those.
|
||||||
|
|
||||||
### `requests`
|
### `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:
|
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
|
## 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.
|
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
|
## 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.
|
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
|
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:
|
Look at the pods generated, see how they are generated. Connect to one of the pods:
|
||||||
|
|
||||||
|
|
|
@ -201,7 +201,7 @@ spec:
|
||||||
singular: mysqlbackupschedule
|
singular: mysqlbackupschedule
|
||||||
plural: mysqlbackupschedules
|
plural: mysqlbackupschedules
|
||||||
---
|
---
|
||||||
apiVersion: apps/v1beta1
|
apiVersion: apps/v1
|
||||||
kind: Deployment
|
kind: Deployment
|
||||||
metadata:
|
metadata:
|
||||||
name: mysql-operator
|
name: mysql-operator
|
||||||
|
|
|
@ -23,7 +23,6 @@ kube-system Active 56d
|
||||||
|
|
||||||
```sh
|
```sh
|
||||||
$ kubectl get all --namespace=kube-system
|
$ kubectl get all --namespace=kube-system
|
||||||
|
|
||||||
[lot of stuff]
|
[lot of stuff]
|
||||||
```
|
```
|
||||||
|
|
||||||
|
|
|
@ -57,6 +57,6 @@ Specify a [PDB](../14-pdb) for your deployments.
|
||||||
|
|
||||||
## Other good practices
|
## 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.
|
1. If you are in the cloud, use [`terraform`](https://www.terraform.io/) to configure your clusters.
|
||||||
|
|
Loading…
Reference in New Issue