Sig-release: [Umbrella] Formalize supported release platforms

[hasheddan]

We currently build and release k/k artifacts for a number of os / arch platforms (listed below). However, there is no formal process for adding a new platform, retiring an existing platform, determining level of support for an existing platform, or measuring test coverage for an existing platform. The currently supported platforms are listed below:

arm64-linux
arm-linux
amd64-darwin
386-linux
ppc64le-linux
s390x-linux
386-windows
amd64-windows

This umbrella issue tracks the steps to accomplish the following objectives. It will be updated and linked to more granular issues and PRs.

• Make it abundantly clear to end users which platforms are supported and their level of support
  
  
  
  • [x] Update document in k/sig-release with currently supported platforms @hasheddan
  
  
  • [ ] Add documentation to k/sig-release with 3rd party dependencies that impact building artifacts @hasheddan
  
  
  • [ ] Add information on k/website about supported architectures @hasheddan
  
  
  • [x] Define "tiers" of support for a platform @saschagrunert
  
  
• Document current blocking / informing jobs @hasheddan
• Verify that we are in fact publishing artifacts for every platform we support
  
  
  
  • [ ] Add step to krel stage / release to verify existence of artifacts for all supported platforms @hasheddan
  
  
• Define steps for introducing a new platform
  
  
  
  • [x] Add guide for shipping alternative platforms (https://github.com/kubernetes/community/pull/5300) @saschagrunert
  
  
• Define steps for retiring and existing platform
  
  
  
  • Likely requires a broader conversation about whether we can drop support for a platform (i.e. deprecation / removal cycle)
  
  
• Define metrics around test coverage for supported platforms (i.e. make our level of support somewhat quantifiable)
  
  
  
  • [ ] Document the current test coverage for existing platforms @hasheddan
  
  

/kind documentation
/area release-eng
/priority important-soon
/assign
/assign @saschagrunert

[saschagrunert]

Looks good, I'll continue with the Tiers on kubernetes/community#5300 got merged.

[hasheddan]

Found this google groups thread and want to loop in @BenTheElder and @johnbelamaric to let y'all know this effort is underway. I am planning on attending SIG-Arch meeting this Thursday https://groups.google.com/g/kubernetes-sig-architecture/c/eHBFgfd6Qxg

[hasheddan]

Slides from presentation to sig-arch: https://docs.google.com/presentation/d/1bctKOljDHwCB6115pphPO3VQ4PiLHcOqYiBA5IXorTE/edit?usp=sharing

[saschagrunert]

Thanks for sharing! Looks like my work assignment ends after https://github.com/kubernetes/sig-release/pull/1360 got merged. Since you're the coordinator of this effort: What are possible next steps for myself to support further? :)

[spiffxp]

/wg k8s-infra
I don't think this issue is something the wg needs to drive at all, but putting it on our radar in the event that "should be able to use our build infra" requires attention

[spiffxp]

/sig release

[Toasterson]

@rikatz are you interested in this for FreeBSD?

[rikatz]

@Toasterson I guess it would be good, but OTOH FreeBSD can’t be fully supported nowadays, mostly because of the lack of a kube-proxy that can deal with PF instead of IPTables :)

All the control plane components can run on FreeBSD, and also Kubelet but in the case of kubelet it does nothing as we don’t have today a cri interface to jails, as an example, so I guess the effort for this specific release does not pay the price but this can for sure be something for future releases!

thanks for the heads up!

[Toasterson]

Sure thing! Was meant more as a Heads up.

Considering kube-proxy and thae fact that both illumos and FreeBSD have a virtal switching Infrastructure, it is questionable if we want that at all. IMHO it's the CNI's Job to setup all the IP addresses of the pods and services. For Load balancing IPF/PF can be useful, but we would need to check how we want to do that exactly aswell.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

[saschagrunert]

/remove-lifecycle stale