Skip to content

Image garbage collection is not working on workers #508

Closed

Description

@kvaps

Hi, my nodes are not able to run new images after images fs overfilled:

kubectl describe pod angular-app-5cbcdcc7db-xrcrb -n default
Events:
  Type    Reason   Age                    From     Message
  ----    ------   ----                   ----     -------
  Normal  BackOff  4m23s (x2385 over 9h)  kubelet  Back-off pulling image "registry.onayzakup.kz/frontend/angular-app:dbb507a20c2523dbf752c767f6341f0fc81cd539"

I found that Kamaji sets Kubelet configuration to disable garbage collection.

According to this line:

ImageGCHighThresholdPercent: pointer.To(int32(100)),

The garbage collection for images is not triggered
(see: kubernetes/kubernetes#79929)

Is there any specific reason, why is kamaji disables garbage collection?

Activity

  1. kvaps commented on Aug 7, 2024

    @kvaps
    ContributorAuthor

    Also all of these zeroDuration look weird to me? Is there any reason why are they configured like so?

    EvictionPressureTransitionPeriod: zeroDuration,
    FileCheckFrequency: zeroDuration,
    HealthzBindAddress: "127.0.0.1",
    HealthzPort: pointer.To(int32(10248)),
    HTTPCheckFrequency: zeroDuration,
    ImageGCHighThresholdPercent: pointer.To(int32(100)),
    NodeStatusUpdateFrequency: zeroDuration,
    NodeStatusReportFrequency: zeroDuration,
    RotateCertificates: true,
    RuntimeRequestTimeout: zeroDuration,
    ShutdownGracePeriod: zeroDuration,
    ShutdownGracePeriodCriticalPods: zeroDuration,
    StaticPodPath: "/etc/kubernetes/manifests",
    StreamingConnectionIdleTimeout: zeroDuration,
    SyncFrequency: zeroDuration,
    VolumeStatsAggPeriod: zeroDuration,

    According to kubelet configuration, they should have default values:
    https://kubernetes.io/docs/reference/config-api/kubelet-config.v1beta1/

  2. added a commit that references this issue on Aug 7, 2024
  3. prometherion commented on Aug 7, 2024

    @prometherion
    Member

    Definitely a bad choice from our side, I guess it was just a basic scaffolding since most of the time nodes are joining with a dedicated kubeadm configuration file (e.g.: Cluster API).

    Wondering if you're facing this issue even tho running with Cluster API, IIRC a local configuration has precedence over the one stored in the cluster.

  4. added a commit that references this issue on Aug 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

bugSomething isn't working

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions