aws/amazon-vpc-cni-k8s

What happened: Each pod sandbox ADD/DEL on our Bottlerocket nodes writes 2 to 5 lines like these to the containerd journal. They come from short-lived plugin processes. The monotonic offset (m=+0.00x) is about a millisecond after process start. The two lines below are 0.1 ms apart and come from the same process: containerd[2295]: 2026-09-28 00:00:55.725721913 +0000 UTC m=+0.001520567 write error: can't make directories for new logfile: mkdir /host: read-only file system containerd[2295]: 2026-09-28 00:00:55.725815733 +0000 UTC m=+0.001614387 write error: can't make directories for new logfile: mkdir /host: read-only file system The plugins' own log files are written without errors in the same second: /var/log/aws-routed-eni/plugin.log: 00:00:55.710Z and 00:00:55.726Z, Received CNI del request ... Container ... not found /var/log/aws-routed-eni/egress-v6-plugin.log: 00:00:55.721Z, egress-cni plugin is disabled So the errors come from a second logger inside the same short-lived plugin

Description After an aws-node/IPAMD restart, IPAMD can add an IPv4 address reported by stale IMDS data back into its datastore even though EC2 DescribeNetworkInterfaces shows that the address is no longer assigned to the ENI. The address can subsequently be allocated to a pod. CNI ADD and host-network configuration report success, but VPC-bound connections from the pod receive no replies. Integration test This was exposed by the existing OSS integration test: test/integration/ipamd/eni_ip_leak_test.go Describe: [CANARY][SMOKE] ENI/IP Leak Test Context: ENI/IP Released on Pod Deletion It: Verify that on Pod Deletion, ENI/IP State is restored The test: Sets WARM_IP_TARGET=3 and WARM_ENI_TARGET=0. Creates and deletes BusyBox pods. Waits for the original ENI/IP count to be restored. Restores the default aws-node environment, causing an aws-node rollout. The test body completed successfully. The issue became visible during the suite's AfterSuite cleanup in: test/integration/ipamd

What happened: I wanted to add vpc-cni version to the dashboard and noticed that awscni_build_info metric is missing version label, example: awscni_build_info{container="aws-node", endpoint="metrics", goversion="go1.25.9", instance="x.x.x.x:61678", job="kube-system/aws-cni-metrics", namespace="kube-system", pod="aws-node-xxxxx"} According to the code, it should be populated during the build time, but this seems didn't happen. Attach logs Not relevant. What you expected to happen: version label exists in awscni_build_info metric. How to reproduce it (as minimally and precisely as possible): Create EKS cluster with vpc-cni Configure metrics scraping for vpc-cni or just execute curl to metrics endpoint Check labels in awscni_build_info metric. version should exist and equal to deployed version. Anything else we need to know?: Environment: Kubernetes version: v1.35.6-eks-bca9cf6 CNI Version: v1.21.1-eksbuild.8 OS: AL2023