a5b4383297
* 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 |
4 years ago | |
|---|---|---|
| .. | ||
| README.md | 4 years ago | |
| yamllint | 5 years ago | |
README.md
Good practices
Introduction
This section is a summary, a cheat sheet, of good practices for Kubernetes. It is mostly a summary of previous sections.
Cheat Sheet
In no particular order:
Do not use root user in containers
The container paradigm, and how it is implemented on linux, was not built with security in mind. It’s only to restrict resources, think CPU and RAM. The documentation of Docker explains this in more detail.
This implies that your container should not use the user “root” to run commands, to the why see here.
So on all your images add those two lines to make your application run with a dedicated user. Replace algolia with a name more relevant for you.
RUN groupadd -g 999 algolia && useradd -r -u 999 -g algolia algolia
USER algolia
Linting manifests
YAML can be a tricky format.
We recommand to use yamllint. Compared to other YAML linter. It has the nice feature of supporting multi-documents in a single file. The file yamllint is a good configuration for this tool.
You can also use Kubernetes specifics linter. kube-score lints your manifests and enforce good practices. kubeval also lints the manifests, but only checks if they are valid.
In Kubernetes 1.13 the option --dry-run appeared on “kubectl”. You could also use this feature to know if your YAML are valid for Kubernetes.
Linting Dockerfile
Same as above but for Dockerfiles, use a linter hadolint seems a good choice.
Handle SIGTERM signal in your applications
Kubernetes sends this signal when it wants to stop a container. You should listen to it and react accordingly to your application (close connections, save a state, etc.).
Probes
Define liveness and readiness probes for your containers.
Resources request and limits
Define resources for your containers.
Pod (anti-)affinity
Specify an anti-affinity for the pods of your deployements.
PDB
Specify a PDB for your deployments.
Other good practices
Not directly related to Kubernetes, but still useful:
- If you are in the cloud, use
terraformto configure your clusters.