3 min read
To be able take advantage of using a Cluster Autoscaler (same applies to AWS Karpenter) we need make sure we properly set the resources any scheduled Pod is requesting to Kubernetes:
When we are not use the resources a given Pod or container is going to use, we can use the Vertical Pod Autoscaler to help us define them
14/02/2022
Read more...2 min read
We can choose to expose some of the Pod's information as volumes or environment variables using DownwardAPIVolumeFile. It can expose both Pod fields and Container fields
05/01/2022
Read more...2 min read
Some applications might need to retrieve (or at least know) some of the Pod's metadata, for example, it's namespace. We can push this information using fieldPath without having to grant access to the Kubernetes API or using any template engine (such as Helm) to set it's value (at the end of the day it would be hardcoding the value on the Pod's definition)
04/01/2022
Read more...3 min read
When running containers, by default we will have an isolation between the host and the running container: you cannot access the host’s resources. But when you run a Pod with the privileged flag, you are effectively disabling this isolation making it equivalent to running that process as root on the host server.
22/12/2021
Read more...2 min read
Network policies are objects that allows you to control the flow of connections to and from pods. By default all pods are completely open to all communications, but as soon as a pod is selected by a policy, it is no longer be considered open: just the connections allowed by the NetworkPolicy will be allowed
20/12/2021
Read more...