Link to action item

For Deployment nginx-deployment-2 in namespace

Description:
Kubernetes will often cache images on worker nodes. By default, an image will only be pulled
if it isn't already cached on the node attempting to run it.

However, utilizing cached versions of a Docker image can be a reliability issue.
It can lead to different images running on different nodes, leading to inconsistent
behavior. It can also be a security issue, as a workload can access a cached image even if it
doesn't have permission to access the remote Docker repository (via imagePullSecret).

Specifying pullPolicy=Always will prevent these problems by ensuring the latest image is
downloaded every time a new pod is created.

References

• Documentation
• How to Identify

Remediation:
In your Pod spec, set imagePullPolicy to Always

Examples

apiVersion: v1
kind: Pod
metadata:
  name: busybox
spec:
  containers:
    - name: busybox
      image: busybox
      imagePullPolicy: Always
      command: [ "echo", "SUCCESS" ]

Link to action item

For Deployment nginx-deployment in namespace

Description:

Configuring memory limits makes sure a container's memory usage never goes above a certain value.
Setting appropriate resource limits will ensure that your applications do not consume too many resources.
Without resource limits, a single poorly behaving pod could utilize the majority of resources on a node,
significantly impacting the performance of other pods on the same node
Read more in the Kubernetes docs

Remediation:

Add memory limits to your container spec.

spec:
  containers:
  - resources:
      limits:
        memory: "128Mi"

Link to action item

For Deployment nginx-deployment-2 in namespace

Description:

Liveness probes are designed to ensure that an application stays in a healthy state.
When a liveness probe fails, the pod will be restarted.

Remediation:

Add a livenessProbe to your container spec.

livenessProbe:
  # Be sure to specify a check that your workload will respond to
  httpGet:
    path: /health
    port: http

Link to action item

For Deployment nginx-deployment-2 in namespace

Description:
Configuring CPU limits makes sure a container never uses an excessive amount of CPU.

If CPU limits are not set, a misbehaving application could end up utilizing most of the
CPU available on its node, potentially slowing down other workloads or causing cost overruns as
the cluster tries to scale up.

In contrast to memory limits, a CPU limit will never cause your application to crash.
Instead, it will get throttled - it will only be allowed to run a certain number of operations
per second.

References

• Kubernetes docs
• Google Cloud blog
• Efficient Resource Utilization

Remediation:
Add a CPU limit to each of your container specifications. CPU may be set in terms of
whole CPUs (e.g. 1.0 or .25), or more commonly, in terms of millicpus (e.g. 1000m or 250m).

It's up to you to decide how much CPU to allocate to your application. Setting CPU limits
too high could potentially lead to cost overruns, whereas setting it too low may cause
your application to get throttled.

Insights can help you determine your application's CPU usage via the
Prometheus Collector
and Goldilocks reports.
We strongly recommend you enable one or both of these reports to help determine appropriate resource
requests and limits.

For mission-critical or user-facing applications,
Fairwinds recommends setting a high CPU limit, so only a misbehaving application will be throttled.

Examples

apiVersion: v1
kind: Pod
metadata:
  name: busybox
spec:
  containers:
  - name: busybox
    image: busybox
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

Last updated: 2024-02-29 19:00:16

0 unique policy violations across 0 Action Items

View Details in Fairwinds Insights