-
Notifications
You must be signed in to change notification settings - Fork 44
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
publish arm64 images #893
Comments
When trying to build it myself for linux/arm64, I also saw that a few images ( |
Hi @seankhliao git-sync is located here: https://github.com/kubernetes/git-sync |
I did get this working a few days ago The changes I had to make included somehow switching out the amd64 binaries pulled for helm and kustomize, as well as removing the hardcoded GOARCH=amd64 envs in Dockerfiles |
The |
I found myself needing an arm64 build of the images, so I had a look at the specifics of what would need to be done. There is what I found:
I'll open pull requests for the above changes, please view them more as inspiration than as a requests to merge |
Additionally, our internal forks for CVE patching of these dependencies will need to be updated to build and publish additional artifacts, in order to preserve FedRAMP compliance. |
The Config Sync team does manage the internal helm & kustomize forks, but not the golang image. So we may need to loop in another team, and convince them to publish and maintain arm64 images, or publish our own. |
I'm not an expert on multi-arch images, but here are some good docs:
One big concern I have is the current requirement that we use checksums when pulling images, to ensure the image contents haven't changed since we updated the image tag to pull. This makes it nearly impossible to use multi-arch images without templating the manifests for each architecture. This is especially problematic because Config Sync's reconciler-manager manages the reconciler deployments. So templating the manifests used for install instead good enough. We also need to modify the reconciler-manager to detect or be configured with the architecture in order to select the right images to use for the reconciler and each of it's many sidecars. The whole design of multi-arch images with multiple manifests chosen dynamically has all the same security problems as pulling the latest image all the time, which isn't secure enough for our requirements. AFAICT, the list of manifests isn't validated with a checksum, so there's no way to prove that it hasn't changed since you chose to use that set of manifests. So you have to specify the specific image and its checksum to protect against supply-chain attacks. |
Actually, since the reconciler template is already in a ConfigMap, we might be able to modify that for each arch at install time. So we may not need to modify reconciler-manager. But we would need to publish install manifests for each architecture, probably built with kustomize. |
Re checksums, pinning to the digest of the multiarch image index should be sufficient? The underlying container runtime will handle resolving that to the actual architecture it needs. Example of a multiarch image (that i happen to be working on atm): crane manifest ghcr.io/seankhliao/moo-d8d32f1a62b378aeddd6a6715da2ca45@sha256:751ab863cc99e436e6d47b4e0d7183f5db7322ff838d8b767744c65e06a698db | jq -r . The runtime will resolve it to the matching platform automagically: {
"schemaVersion": 2,
"mediaType": "application/vnd.oci.image.index.v1+json",
"manifests": [
{
"mediaType": "application/vnd.oci.image.manifest.v1+json",
"size": 2538,
"digest": "sha256:aef26d93e01e0d587c5de0ba1813b81e2bd488caeb2bbead90994902bf88317b",
"platform": {
"architecture": "amd64",
"os": "linux"
}
},
{
"mediaType": "application/vnd.oci.image.manifest.v1+json",
"size": 2538,
"digest": "sha256:3afa10fecdb8b3482152a2945f1bf149e0ca3204a4f74ea8a9773b4a9274ece5",
"platform": {
"architecture": "arm64",
"os": "linux",
"variant": "v8"
}
}
],
"annotations": {
"org.opencontainers.image.base.digest": "sha256:51ab1c8dd85f85010207db36dc5a5a3212ff42e482f6b324b7c9884956ffd293",
"org.opencontainers.image.base.name": "gcr.io/distroless/static-debian12@sha256:3a03fc0826340c7deb82d4755ca391bef5adcedb8892e58412e1a6008199fa91"
}
} |
Ah, ok, cool. TIL the checksum we use to pull with is actually the checksum of the image manifest, not the checksum of the image itself. That makes things simpler, thanks. |
It turns out, to bring up reconciler-manager there is one more image referenced that are only built for amd64: Are there any details anywhere about how Here are the details on what I did to switch to upstream otel: nresare@18d3725 |
The otel-collector image is also built from an internal fork to patch CVEs. But I think it's a few versions behind, and they've changed the binary entrypoint upstream recently. |
I created a blog post with the details on my little effort: https://noa.re/posts/configsync-on-arm64/ I would very much like to see that page become obsolete by having you support at arm64 in official releases. At least now there some prior art that will simplifying figuring out the effort needed to do this. Ideally I would like to see a bit of a piecemeal approach where you perhaps update the build infrastructure for the forks you maintain to include both architectures. With go supporting cross compilation and the binaries you already make available having architecture encoded in their names, it might not be such a big effort. This does not need to mean that you make the commitment to support arm64 officially. |
partly out of my own laziness to build the images myself, could the project publish multi platform images for easy deployment onto arm clusters as well?
The text was updated successfully, but these errors were encountered: