* 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
@ -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.
@ -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.