via martinho
I had no idea such cache exists, very interesting!
Hello,
What is changing?
PodSecurityPolicy (PSP) was deprecated [1] in Kubernetes version 1.21 and has been removed in Kubernetes version 1.25 [2]. If you are using PSPs in your cluster, then you must migrate from PSP to the built-in Kubernetes Pod Security Standards (PSS) or to a policy as code solution before upgrading your cluster to version 1.25 to avoid interruption to your workloads.
What actions can customers take?
PSP resources were used to specify a set of requirements that pods had to meet before they could be created. Since PSPs have been removed in Kubernetes version 1.25, you must replace those security controls. Two solutions can fill this need:
1) Kubernetes Pod Security Standards (PSS)
2) Policy-as-code solutions from the Kubernetes ecosystem
In response to the PSP deprecation and the ongoing need to control pod security out-of-the-box, the Kubernetes community created a built-in solution with PSS [3] and Pod Security Admission (PSA) [4]. The PSA webhook implements the controls defined in the PSS. To review best practices for migrating PSPs to the built-in Pod Security Standards, see references [5] and [6].
Policy-as-code solutions provide guardrails to guide cluster users, and prevent unwanted behaviors, through prescribed and automated controls. Policy-as-code solutions typically use Kubernetes Dynamic Admission Controllers to intercept the Kubernetes API server request flow, via a webhook call, and mutate and validate request payloads, based on policies written and stored as code. There are several open source policy-as-code solutions available for Kubernetes. To review best practices for migrating PSPs to a policy-as-code solution, see reference [7].
You can run the following command to view the PSPs in your cluster: kubectl get psp. If you see the eks.privileged PSP in your cluster, it will be automatically migrated to PSS by Amazon EKS. No action is needed on your part.
To summarize, if you are using PSP in your cluster, then you must migrate from PSP to the built-in Kubernetes PSS or to a policy as code solution before upgrading your cluster to version 1.25 to avoid interruptions to your workloads. EKS offers best practices for pod security and guidance for implementing pod security standards [8]. You can find details on PSP Migration in EKS documentation [1].
If you have any questions or concerns, please reach out to AWS Support [9].
[1] https://docs.aws.amazon.com/eks/latest/userguide/pod-security-policy-removal-faq.html
[2] https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html#kubernetes-release-calendar
[3] https://kubernetes.io/docs/concepts/security/pod-security-standards/
[4] https://kubernetes.io/docs/concepts/security/pod-security-admission/
[5] https://aws.github.io/aws-eks-best-practices/security/docs/pods/#pod-security-standards-pss-and-pod-security-admission-psa
[6] https://kubernetes.io/docs/tasks/configure-pod-container/migrate-from-psp/
[7] https://aws.github.io/aws-eks-best-practices/security/docs/pods/#policy-as-code-pac
[8] https://aws.amazon.com/blogs/containers/implementing-pod-security-standards-in-amazon-eks/
[9] https://aws.amazon.com/support
https://kubernetes.io/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/
https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.26/#securitycontext-v1-core
https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.26/#podsecuritycontext-v1-core
https://github.com/open-policy-agent/gatekeeper/
https://www.openpolicyagent.org/docs/latest/kubernetes-tutorial/
Karpenter vs Cluster Autoscaler very well explained in 7minutes
Server Side apply VS Client Side apply
via Edwin
Un Operator qui :
Du coup on peut créer des resources AWS avec kube (on peut se passer de terraform, on peut utiliser une CI/CD adaptée à déployer dans Kube)
https://medium.com/omio-engineering/cpu-limits-and-aggressive-throttling-in-kubernetes-c5b20bd8a718
https://blog.turbonomic.com/kubernetes-cpu-throttling-the-silent-killer-of-response-time-and-what-to-do-about-it
https://erickhun.com/posts/kubernetes-faster-services-no-cpu-limits/
https://engineering.indeedblog.com/blog/2019/12/unthrottled-fixing-cpu-limits-in-the-cloud/
https://www.youtube.com/watch?v=UE7QX98-kO0
Petit point vocabulaire : un "Operator" est un "controller" qui va surveiller des CRD (Custom Resource Definition) pour faire des actions
Un Operator = 1 deployment = x Pods qui écoutent via l'API de Kube les events sur une CRD et va faire des actions en conséquence
Gérer des resources aws avec un controller kube fourni par aws
simple example on how to write a kubernetes operator
Un cluster EKS est livré avec un Deployment pour core dns avec 2 replicas
ça suffit pour commencer, mais avec beaucoup de pods qui tournent on a commencé à avoir des erreurs DNS
On a passé le replicas à 5 et tout va mieux, plus d'erreurs
Tips :
start with low request and high limits
observe..
increase request to request what needed in normal processing
lower limits to... what your strategy is. It can be 10% more than request for example or the same than request if you want to be safe
Pas toujours simple de s'y retrouver :
https://github.com/coreos/prometheus-operator
https://github.com/coreos/prometheus-operator/tree/master/contrib/kube-prometheus
La différence entre ces deux là est expliqué dans le README : https://github.com/coreos/prometheus-operator#prometheus-operator-vs-kube-prometheus
Ce qu'il faut retenir, c'est que si l'on veut une solution end-to-end de monitoring de son cluster, il faut utiliser kube-prometheus qui installe le prometheus operator et plein d'autres choses. D'après le Readme de kube prometheus, le projet s'utilise comme une lib qui permet de générer des manifests yaml qu'on va ensuite apply.
Le projet a aussi été packagé avec helm. Si on veut custom les manifests, ça a l'air plus facile à utiliser que le jsonnet de kube prometheus :
https://github.com/helm/charts/tree/master/stable/prometheus-operator
Une alternative à kube2iam qui est apparemment plus secure
un projet similaire à kubetail
à voir ce que ça donne comparé à k9s
Si on a créé un Deployment avec un apply -f en spécifiant le champs replicas et qu'on décide d'enlever ce champs (pour ne plus qu'il soit géré de manière statique mais plutot dynamique avec un HPA par exemple)
Il faut faire attention car le comportement par défaut va définir replicas à 1
Pour éviter ça, avant de apply le Deployment sans le champs replicas, il faut faire un :
kubectl apply edit-last-applied deployment my-deployment
Et supprimer le champs replicas
Pour que ça marche bien il faut que ses CPU requests soient cohérents
Lorsque le HPA (horizontal pod autoscaler) démarre trop de pods, ces pods vont être en pending. Il faut plus de nodes pour les faire tourner.
C'est le but du kubernetes autoscaler qui va reconfigurer l'autoscaling group des nodes pour en ajouter/enlever suivant l'usage
https://eksworkshop.com/scaling/deploy_ca/
Le pod qui fait tourner ça doit avoir les bon droits IAM pour pouvoir modifier l'ASG
voir : https://blog.csanchez.org/2018/11/14/installing-kube2iam-in-aws-kubernetes-eks-cluster/
Peut être utile dans certains cas, je me le garde de côté
Pour obtenir les yaml sans installer un helm chart :
helm template \
--values ./values/prometheus.yaml \
--output-dir ./manifests \
./charts/prometheus
Prometheus Operator vs. kube-prometheus
The Prometheus Operator makes the Prometheus configuration Kubernetes native and manages and operates Prometheus and Alertmanager clusters. It is a piece of the puzzle regarding full end-to-end monitoring.
kube-prometheus combines the Prometheus Operator with a collection of manifests to help getting started with monitoring Kubernetes itself and applications running on top of it.
https://github.com/coreos/prometheus-operator/tree/master/contrib/kube-prometheus
Pour un graceful shutdown de nginx, il faut un SIGQUIT
Kubernetes envoie du SIGTERM alors on peut utiliser un preStop script pour être + cool
https://kubernetes.io/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/#define-poststart-and-prestop-handlers
On peut aussi utiliser le preStop pour s'assuret que le container nginx sidecar s'arrête bien avant l'autre container en posant un lock dans un shared volume. Le preStop de l'autre container va attendre que le lock soit supprimé pour se couper. Le preStop du nginx va supprimer le lock quand il a bien terminé.
On crée le lock dans un postStart
via Meetup k8s bbc speaker
tcp6 0 0 :::61678 :::* LISTEN 0 81586 32466/aws-k8s-agent
Tous les nodes exposent ça, c'est cool, ils auraient pu en parler dans la doc ;)
curl localhost:61678/metrics
marche bien, j'ai quand même créé une nouvelle zone et donné les droits dans le role IAM seulement sur celle-ci pour ne pas tout mélanger
Il faut désactiver le upsert only sinon les entrées DNS ne sont pas supprimées quand le service est supprimé et quand on le recrée, il n'arrive pas à update
ça m'est arrivé, bien galère..
Il faut ajouter des quotes aux value des annotations pour qu'elles soient prise en compte lors d'un apply
Quand on modifie un deployment avec un kubectl apply -f chemin/vers/fichier.yaml
Le rollout history n'est pas complété, aucune révision n'est créée
Il faut ajouter un --record à la commande précédente ce qui va créer une révision avec un "change cause" qui va reprendre la commande :
REVISION CHANGE-CAUSE
10 kubectl apply --filename=k8s/preprod/ --record=true
Pas mal mais on peut faire mieux en ayant par exemple le hash du commit (ou le numéro du build..) dans ce "change cause"
Pour ça, dans la CI/CD, on peut renommer par exemple le dossier avant de lancer le kubectl apply -f, ce qui donnera :
REVISION CHANGE-CAUSE
11 kubectl apply --filename=k8s/preprod-a5bcec9 --record=true
Et comme ça on a un rollout history bien propre pour s'y retrouver ;)