kubernetes
/
community
mirror of https://github.com/kubernetes/community.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

fix typo in multi-platform.md

This commit is contained in:
chenjianhua 2018-01-31 13:35:49 +08:00
parent caa452da98
commit 59bd7b545b
1 changed files with 3 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
contributors/design-proposals/multi-platform.md
View File

@ -6,7 +6,7 @@
## Abstract
We obviously want Kubernetes to run on as many platforms as possible, in order to make Kubernetes a even more powerful system.
We obviously want Kubernetes to run on as many platforms as possible, in order to make Kubernetes an even more powerful system.
This is a proposal that explains what should be done in order to achieve a true cross-platform container management system.
Kubernetes is written in Go, and Go code is portable across platforms.
@ -88,7 +88,7 @@ For more information, see [conflicts](#conflicts)
#### e2e CI
To ensure all functionality really is working on all other platforms, the community should be able to setup a CI.
To ensure all functionality really is working on all other platforms, the community should be able to set up a CI.
To be able to do that, all the test-specific images have to be ported to multiple architectures, and the test images should preferably be manifest lists.
If the test images aren't manifest lists, the test code should automatically choose the right image based on the image naming.
@ -133,7 +133,7 @@ TL;DR;
It should be possible to run clusters with mixed platforms smoothly. After all, bringing heterogeneous machines together to a single unit (a cluster) is one of Kubernetes' greatest strengths. And since the Kubernetes' components communicate over HTTP, two binaries of different architectures may talk to each other normally.
The crucial thing here is that the components that handle platform-specific tasks (e.g. kubelet) should expose their platform. In the kubelet case, we've initially solved it by exposing the labels `beta.kubernetes.io/{os,arch}` on every node. This way an user may run binaries for different platforms on a multi-platform cluster, but still it requires manual work to apply the label to every manifest.
The crucial thing here is that the components that handle platform-specific tasks (e.g. kubelet) should expose their platform. In the kubelet case, we've initially solved it by exposing the labels `beta.kubernetes.io/{os,arch}` on every node. This way a user may run binaries for different platforms on a multi-platform cluster, but still it requires manual work to apply the label to every manifest.
Also, [the apiserver now exposes](https://github.com/kubernetes/kubernetes/pull/19905) it's platform at `GET /version`. But note that the value exposed at `/version` only is the apiserver's platform; there might be kubelets of various other platforms.