Add supported platforms document #1352
Conversation
Adds the initial documentation on supported platforms for each Kubernetes component. This document will continue to be iterated upon as procedures for supporting / dropping support for platforms becomes more defined. It will also be updated with tiers of support and current test coverage. Signed-off-by: hasheddan <georgedanielmangum@gmail.com>
k8s-ci-robot
added
kind/documentation
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: hasheddan The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
size/S
|
/priority important-longterm |
k8s-ci-robot
added
priority/important-longterm
There was a problem hiding this comment.
@hasheddan -- Very awesome!
Two things:
- As we start to draw the line between what is released and what is supported, I think it's important to put a disclaimer here, something in the way of "We test on linux/amd64 and that's the only thing we're 'really sure' about. Everything else is best effort."
- Can you break these out into two tables: server and client
|
/hold for reviews! :) |
k8s-ci-robot
added
the
do-not-merge/hold
| @@ -0,0 +1,20 @@ | |||
| # Supported Platforms | |||
There was a problem hiding this comment.
Do we want to put this into /release-engineering? And link it from the README.md there?
There was a problem hiding this comment.
So I was thinking about that, but I think as this document continues to mature, it actually is generally applicable to sig-release, similar to how the release-blocking / release-informing doc is at root of repo.
| @@ -0,0 +1,20 @@ | |||
| # Supported Platforms | |||
|
|
|||
| A Kubernetes release consists of a set of Go binaries for various Operating Systems and CPU architectures. Platforms are identified using the Go `<GOOS>-<GOARCH>` parlance. | |||
There was a problem hiding this comment.
| A Kubernetes release consists of a set of Go binaries for various Operating Systems and CPU architectures. Platforms are identified using the Go `<GOOS>-<GOARCH>` parlance. | |
| A Kubernetes release consists of a set of Go binaries and container images for various Operating Systems and CPU architectures. Platforms are identified using the Go `<GOOS>-<GOARCH>` parlance. |
There was a problem hiding this comment.
There are also various scripts and manifests, looking at the contents of e.g. https://github.com/kubernetes/kubernetes/releases/download/v1.18.12/kubernetes.tar.gz
There was a problem hiding this comment.
@spiffxp yep, this is not meant to cover every artifact produced, just the supported platforms. That being said, I do think we should document those as well.
|
|
||
| A Kubernetes release consists of a set of Go binaries for various Operating Systems and CPU architectures. Platforms are identified using the Go `<GOOS>-<GOARCH>` parlance. | ||
|
|
||
| ## Released Binaries |
There was a problem hiding this comment.
I think we can map this 1:1 to the container images, right? I guess we just have to mention this fact here, too.
There was a problem hiding this comment.
Yep that sounds good 👍
There was a problem hiding this comment.
@saschagrunert in thinking about this more, the container images we publish don't really map 1:1 here, so I think it makes sense to maybe follow-up with some additional documentation on that
| | apiextensions-apiserver | | | X | X | X | X | X | | | | ||
| | kube-aggregator | | | X | X | X | X | X | | | | ||
| | kube-apiserver | | | X | X | X | X | X | | | | ||
| | kube-controller-manager | | | X | X | X | X | X | | | | ||
| | kube-proxy | | | X | X | X | X | X | | X | | ||
| | kube-scheduler | | | X | X | X | X | X | | | | ||
| | kubeadm | | | X | X | X | X | X | | X | | ||
| | kubectl | X | X | X | X | X | X | X | X | X | | ||
| | kubelet | | | X | X | X | X | X | | X | | ||
| | mounter | | | X | X | X | X | X | | | |
There was a problem hiding this comment.
As a follow-up, my idea would be that we put this matrix in a map in k/release and verify it during the release cut. WDYT?
There was a problem hiding this comment.
@saschagrunert definitely :) I have an item on #1337 to do that 👍
|
So I completely missed that an excellent document that describes what I have here as well as much more already exists (https://github.com/kubernetes/sig-release/blob/master/release-engineering/artifacts.md). I am going to close this out and do some work on cleaning up the existing doc 👍 /close |
|
@hasheddan: Closed this PR. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
What type of PR is this:
/kind documentation
What this PR does / why we need it:
Adds the initial documentation on supported platforms for each
Kubernetes component. This document will continue to be iterated upon as
procedures for supporting / dropping support for platforms becomes more
defined. It will also be updated with tiers of support and current test
coverage.
Signed-off-by: hasheddan georgedanielmangum@gmail.com
Which issue(s) this PR fixes:
xref: #1337
Special notes for your reviewer:
/assign @saschagrunert @justaugustus
/area release-eng