Helm chart used to configure Code Ready Workspace at the cluster level
Prometheus, a CNCF project, is a systems and service monitoring system. It collects metrics from configured targets at given intervals, evaluates rule expressions, displays the results, and can trigger alerts if some condition is observed to be true.
This chart bootstraps a Prometheus deployment on a Kubernetes cluster using the Helm package manager.
.png)
A vulnerability has been discovered in Kuberenetes where users with limited access to a Kubernetes cluster, but with the ability to create an Ingress object based on the NGINX Ingress Controller, could elevate privilege and access full cluster secrets (NVD severity of this issue: High).
To learn more about the best practice click here
When an image tag is not descriptive (e.g. lacking the version tag like 1.19.8), every time that image is pulled, the version will be a different version and might break your code. Also, a non-descriptive image tag does not allow you to easily roll back (or forward) to different image versions. It is better to use concrete and meaningful tags such as version strings or an image SHA.
To learn more about the best practice click here
Memory requests allow you to use memory resources efficiently and allow you to allocate a guaranteed minimum of computing resources for the pods running in your cluster.
To learn more about the best practice click here
CPU requests enable you to use CPU resources efficiently and to allocate a guaranteed minimum of computing resources for the pods running in your cluster.
To learn more about the best practice click here
Memory limits enable you to use memory resources efficiently. By setting memory limits, you restrict the maximum amount of memory available to the pods running in your cluster.
To learn more about the best practice click here
CPU limits enable you to use CPU resources efficiently by restricting the maximum amount of CPU available to the pods running in your cluster.
To learn more about the best practice click here
Misconfiguring the ingress host can unintended forward all traffic to a single pod instead of leveraging the load balancing capabilities. By verifying that ingress traffic is targeted by multiple pods, you will achieve higher application availability because you won't be dependent upon a single pod to serve all ingress traffic.
To learn more about the best practice click here
You should always confirm that the cron schedule expression is valid or your jobs won't be executed.
To learn more about the best practice click here
Labels are nothing more than custom key-value pairs that are attached to objects and are used to describe and manage different Kubernetes resources. If the labels do not follow Kubernetes label syntax requirements (see links below), they will not be applied properly.
To learn more about the best practice click here
From the Kubernetes docs:"Only a .spec.template.spec.restartPolicy equal to Always is allowed, which is the default if not specified."Therefore, restartPolicy values like OnFailure or Never will be invalid and will not be applied as the user expect them to.
To learn more about the best practice click here
Liveness probes allow Kubernetes to determine when a pod should be replaced. They are fundamental in configuring a resilient cluster architecture.
To learn more about the best practice click here
Readiness probes allow Kubernetes to determine when a pod is ready to accept traffic. This ensures that client requests will not be routed to pods that are unable to process them.
To learn more about the best practice click here
When auto-scaling resource utilization is triggered with HPA (HorizontalPodAutoscaler), a range of acceptable values must be set to prevent unintended scaling down scenarios.
To learn more about the best practice click here
When auto-scaling resource utilization is triggered by HPA (HorizontalPodAutoscaler), a range of acceptable values must be set to prevent unintended scaling-up scenarios.
To learn more about the best practice click here
Liveness probes allow Kubernetes to determine when a pod should be replaced. They are fundamental in configuring a resilient cluster architecture.
To learn more about the best practice click here
Readiness probes allow Kubernetes to determine when a pod is ready to accept traffic. This ensures that client requests will not be routed to pods that are unable to process them.
To learn more about the best practice click here
When auto-scaling resource utilization is triggered with HPA (HorizontalPodAutoscaler), a range of acceptable values must be set to prevent unintended scaling down scenarios.
To learn more about the best practice click here
When auto-scaling resource utilization is triggered by HPA (HorizontalPodAutoscaler), a range of acceptable values must be set to prevent unintended scaling-up scenarios.
To learn more about the best practice click here
The namespace default is a saved namespace value in which Kubernetes is deploying all objects without an explicit namespace. Using explicit namespaces instead of the default value makes for clearer boundaries between sets of pods in a cluster. For example, namespaces that represent teams present a clear organization of cluster resources and make configuration overlaps less likely.
To learn more about the best practice click here
When the CronJob controller counts more than 100 missed schedules, the cron job is no longer scheduled. Missed CronJobs are considered failures.By default, the CronJob controller counts how many missed schedules happen for a cron job since status.lastScheduleTime until now. When startingDeadlineSeconds is set, the CronJob controller counts how many missed jobs occurred between the value of startingDeadlineSeconds until now.Setting a deadline can reduce the number of missed schedules needed to mark a CronJob as a failure while increasing the CronJob reliability.
To learn more about the best practice click here
The v1.16 release stopped serving some API versions for different resource types. When a user deploys a resource with a deprecated API version, the Kubernetes engine rejects it.
To learn more about the best practice click here
The v1.17 release stopped serving some API versions for different resource types. When a user deploys a resource with a deprecated API version, the Kubernetes engine rejects it.
To learn more about the best practice click here
Processes running in privileged containers have access to host-level resources such as the file system. These containers are much more secure when their access is limited to the pod level.
To learn more about the best practice click here
By default, the cron job allows concurrently running jobs but generally speaking, the behavior of your cron jobs will be more deterministic if you prevent them from running concurrently. Allowing concurrent cron jobs often requires locking mechanisms (to avoid race conditions) in addition to startup/cleanup handling.
To learn more about the best practice click here
A vulnerability has been found in Kubernetes kube-apiserver in which an authorized user could redirect pod traffic to private networks on a node (NVD severity of this issue: Low).
To learn more about the best practice click here
![[riftbit]](https://artifacthub.io/image/undefined@3x)
