KubeArmor daemonset pods failing to deploy successfully on x86 Ubuntu EKS-A Baremetal Env.

[mikemcd3912]

Bug Report

General Information

• Environment description: EKS Anywhere Baremetal
• Kernel version (run uname -a) Linux 5.4.0-162-generic Add Tests for Native AppArmor Policies #179-Ubuntu SMP Mon Aug 14 08:51:31 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
• Orchestration system version in use: 1.27
• Link to relevant artifacts: https://github.com/aws-samples/eks-anywhere-addons/tree/main/eks-anywhere-common/Addons/Partner/KubeArmor
• Target containers/pods: Kubearmor daemonset pods
• Link to Paralell issue in EKS-Anywhere-Addons repo: KubeArmor daemonset pods failing to deploy successfully, preventing cluster storage from provisioning  aws-samples/eks-anywhere-addons#232

To Reproduce

1. Deploy Kubearmor on EKS Anywhere baremetal environment matching the above via flux

The Kubearmor controller and relay pods start up and enter a 'ready' state, but the daemonset pods for all nodes enter a CrashLoopBackOff state shortly after deployment . The logs for the daemonset Kuberarmor container in the daemonset pods show that shortly after start the container begins to drop events due to replay timeouts. The failing deployment also causes the openebs PVC provisioner to fail to create new claims, preventing other workloads on the cluster from obtaining storage necessary to their successful function and deployment

Expected behavior

Kubearmor agent is expected to fully deploy and report ready

Screenshots

kubearmor.logs.txt

[mikemcd3912]

Opening for tracking per the request of a member of the EKS-Anywhere Partner Addons team
@daemon1024 @rksharma95

[elamaran11]

@daemon1024 Is this fixed?

[daemon1024]

Hey @elamaran11 , Yes this is fixed in our recent releases. Hope we can get aws-samples/eks-anywhere-addons#235 merged to upgrade our version on EKS-A

[elamaran11]

@daemon1024 Thanks for the confirmation. we will be validating this soon. Thanks!

[mikemcd3912]

@daemon1024 Thanks for the attention on this issue! We've validated the updated PR and have just merged the PR that fixed the issue.