Kubeadm: armv6lでKubeadmが壊れた

作成日 2017年04月23日  ·  21コメント  ·  ソース: kubernetes/kubeadm

ラズベリーパイゼロWにkubeadmをインストールしようとしましたが、「不正な指示」が表示されます
ラズベリーパイ3(armv7)では問題なく動作します。

最も参考になるコメント

armv6lサポートの再統合について議論することは可能ですか? PiZeroやその他のarmv6lPiデバイスでKubernetesを使用することに関心を示している投稿がたくさん見つかりました。 P Zeroは、KubernetesまたはSwarmCluster環境でマイクロサービスをホストするのに適しています。 DockerSwarmは私にとってうまく機能します。 ですから、誰かが議論をリサイクルできればいいのですが。 Pi clusterhatは、適切に優れたデモインフラストラクチャです。

全てのコメント21件

RaspberryPiモデルB +、またarmv6のkubeadm1.6.1でも同じ問題に直面しています。

$ kubelet --help
Illegal instruction

$ uname -a
Linux pi1 4.4.50-hypriotos+ #2 PREEMPT Sun Mar 19 14:44:01 UTC 2017 armv6l GNU/Linux

kubeadm 1.5.6にダウングレードしましたが、動作します。 1.6.0では1.6.1と同じエラーが発生します。

@clabuええ1.5.6へのダウングレードは機能しますが、

まず、ARMでKubernetesを使用していただきありがとうございます:smile:!

これは既知の問題です。 https://github.com/kubernetes/kubernetes/issues/38067で説明されており、armelサポート(クロスコンパイル時にRPi 1の一部が使用する部分)を削除しました。

基本的に、armhf(GOARM = 7)はPi 1で実行できないため、RPi1をサポートするために-v1.5でGOARM = 6のarmelを使用しました。ただし、v1.6ではすべてのarmhfを使用したため、動作しません。 Pi1。

armelを廃止し、代わりにarmhfイメージを使用し、GOARM = 6の代わりにGOARM = 7を使用します
動機:

  • Goがgo1.8でサポートする唯一のGOARM = 6ボードは、Raspberry Pi 1です。これは、新しいKubernetesバージョンを実行するには遅すぎます。
  • GOARM = 7を使用した場合のパフォーマンスのわずかな改善
  • armel(http://hub.docker.com/u/armel)イメージは、armhf(http://hub.docker.com/u/armhf)イメージほど頻繁には更新されません。

たとえば、 https://hub.docker.com/r/armel/debian/は8か月前に更新されましたが、これはセキュリティの観点からは非常に悪いですが、 https://hub.docker.com/r/armhf/debian/これは3日前に更新されました。

また、armhfスイッチを使用すると、 https: //hub.docker.com/r/armhf/alpineを使用できました。これはすばらしいことです。

お役に立てば幸いですが、RPi1をサポートできなくなって申し訳ありません。

それを文書化/広めるのを手伝いたい場合は、実行するか、提案をしてください

PiZeroでも同じ問題が発生しています

Linux p1 4.9.59+ #1047 Sun Oct 29 11:47:10 GMT 2017 armv6l GNU/Linux

armv6lサポートの再統合について議論することは可能ですか? PiZeroやその他のarmv6lPiデバイスでKubernetesを使用することに関心を示している投稿がたくさん見つかりました。 P Zeroは、KubernetesまたはSwarmCluster環境でマイクロサービスをホストするのに適しています。 DockerSwarmは私にとってうまく機能します。 ですから、誰かが議論をリサイクルできればいいのですが。 Pi clusterhatは、適切に優れたデモインフラストラクチャです。

pi zeroの現在のdocker.ioビルドを見ると、
Goバージョン:go1.9.3
およびDockerバージョン:18.02.0-ce

最近のバージョンのgoを使用しているようです。

スタンドアロンモードでk8sを使用するのに十分なRAMがないことに同意しますが、より大きなマスターのスレーブであるため、いくつかの有用なことを実行するのに十分なリソースが必要です。

ソースからビルドしてpiゼロをk8sノードとして使用することが可能かどうか誰かが知っていますか?

たとえば、 https://hub.docker.com/r/armel/debian/は8か月前に更新されましたが、これはセキュリティの観点からは非常に悪いですが、 https://hub.docker.com/r/armhf/debian/これは3日前に更新されました。

異なるアーキテクチャの公式イメージが同時に更新されるため、これは今日では当てはまりません。 例えばhttps://hub.docker.com/r/arm32v5/debian/https://hub.docker.com/r/arm32v7/debian/https://hub.docker.com/r/amd64/ debian /はすべて9日前に更新されました。

また、armhfスイッチを使用すると、 https: //hub.docker.com/r/armhf/alpineを使用できました。これはすばらしいことです。

https://hub.docker.com/r/arm32v6/alpine/

改めて考えていただきたいと思います。 PiZeroが最新のk8を実行するのを停止するのはとても残念です。

@luxas

+1。 ハブが再配置され、古いリポジトリがまだ存在しているため、混乱が生じています。 新しいものは頻繁に更新されているようです。

こんにちは@juliancheal

ClusterHATでk8をビルドしている最中ですが、PiZeroのバイナリをコンパイルしてビルドすることができました。

基本的に、私はいくつかの変更を加えて以下に従いました:
https://povilasv.me/raspberrypi-kubelet/

私はwslに取り組みました:
Linux DESKTOP-6GRDDIN 4.4.0-17134-Microsoft#48-Microsoft Fri Apr 27 18:06:00 PST 2018 x86_64 x86_64 x86_64 GNU / Linux

1gcc-arm-linux-gnueabihfの代わりにgcc-arm-linux-gnueabiをインストールします

sudo apt-get install gcc-arm-linux-gnueabi <-変更

2 linux / arm用にビルドする前に、hack / lib / golang.shのset_platform_envs()に2つの変更を加えます。

* GOARMを追加しますexport GOOS = $ {platform%/ }export GOARCH = $ {platform ## /}export GOARM = 5 <-追加* CCを変更する
ケース「$ {platform}」
"linux / arm")
エクスポートCGO_ENABLED = 1
エクスポートCC = arm-linux-gnueabi-gcc <-変更
;;

GOARMは5である必要があります。6を指定すると、ビルド中にリンカーエラーが発生します。 (私は解決できませんでした。)

@ shinichi-hashitaniそれは私のPiZeroで動作します! ありがとう!

また、リンカーエラーに関する問題も解決しました。 Pi Zeroの場合、GOARM = 6に設定し、gcc-arm-linux-gnueabihfを保持します。 ただし、Pi 1の場合は、GOARM = 5を設定し、代わりにgcc-arm-linux-gnueabiを使用する必要があります。

@ shinichi-hashitaniこれは素晴らしいです! よろしくお願いします!

@ shinichi-hashitani make all KUBE_BUILD_PLATFORMS=linux/armを使って作成しましたか? また、 kubeadmを使用してクラスターを設定した場合、どのように設定しましたか? kubelet 、言及されたinitスクリプトpovilasv、 kubeadm 、およびkubectlをコピーしましたか? それは機能しましたか?

@dbwestはい、バイナリを構築するために

make all WHAT=cmd/kube-proxy KUBE_VERBOSE=5 KUBE_BUILD_PLATFORMS=linux/arm
make all WHAT=cmd/kubelet KUBE_VERBOSE=5 KUBE_BUILD_PLATFORMS=linux/arm
make all WHAT=cmd/kubectl KUBE_VERBOSE=5 KUBE_BUILD_PLATFORMS=linux/arm

ノード用のバイナリが必要だったので、これら3つのバイナリだけが必要でした。

kubeadmは使いませんでした。 私はKelseyHightowerの「KubernetestheHardWay」をフォローしていました。 ここで説明

@ shinichi-hashitaniどのバージョンのkubernetesを作成しているのかわかりますか?

これをarmv6用にビルドすることができませんでした(pi zero wで実行することを望んでいます)。

バージョン>= 1.12.0私はこのようなものを手に入れます...

vendor/github.com/google/cadvisor/accelerators/nvidia.go:30:2: build constraints exclude all Go files in /private/var/folders/hn/gt2l8vq56vx9slvwry43xmz40000gn/T/tmp.A83ZihlF/_output/local/go/src/k8s.io/kubernetes/vendor/github.com/mindprince/gonvml
!!! [0511 07:36:41] Call tree:
!!! [0511 07:36:41]  1: /private/var/folders/hn/gt2l8vq56vx9slvwry43xmz40000gn/T/tmp.A83ZihlF/hack/lib/golang.sh:601 kube::golang::build_some_binaries(...)
!!! [0511 07:36:41]  2: /private/var/folders/hn/gt2l8vq56vx9slvwry43xmz40000gn/T/tmp.A83ZihlF/hack/lib/golang.sh:736 kube::golang::build_binaries_for_platform(...)
!!! [0511 07:36:41]  3: hack/make-rules/build.sh:27 kube::golang::build_binaries(...)
!!! Error in /private/var/folders/hn/gt2l8vq56vx9slvwry43xmz40000gn/T/tmp.A83ZihlF/hack/lib/golang.sh:561
  Error in /private/var/folders/hn/gt2l8vq56vx9slvwry43xmz40000gn/T/tmp.A83ZihlF/hack/lib/golang.sh:561. 'go install "${build_args[@]}" "$@"' exited with status 1

そして、 >= 1.10.0 & < 1.12.01.10.0は私がこれまでに試した中で最も早いもの

F0511 07:39:30.480641   26683 openapi.go:116] Failed loading boilerplate: open /private/var/folders/hn/gt2l8vq56vx9slvwry43xmz40000gn/T/tmp.A83ZihlF/_output/local/go/src/k8s.io/gengo/boilerplate/boilerplate.go.txt: no such file or directory
!!! Error in ./hack/run-in-gopath.sh:33
  Error in ./hack/run-in-gopath.sh:33. '"${@}"' exited with status 255
Call stack:
  1: ./hack/run-in-gopath.sh:33 main(...)
Exiting with status 1
make[1]: *** [pkg/generated/openapi/zz_generated.openapi.go] Error 1
make: *** [generated_files] Error 2

編集:気にしないでください...私がLinuxマシンでビルドした場合、それは機能するように見えます。 私は自分のMacからそれをやろうとしていました

@ammmze

あなたの側で何が問題を引き起こしているのか正確にはわかりませんが、以下は私の側の詳細です:
Kubernetes-1.10.2
行く-19.4
これらのバイナリをクロスコンパイルするために、WSL(おそらくUbuntu 16.x)を使用しました。

繰り返しますが、私はいくつかの変更を加えて以下に従いました:
https://povilasv.me/raspberrypi-kubelet/
これを参照して、実行する手順を確認できます。

メモと正確な手順を準備しましたが、申し訳ありませんが、日本語でのみご利用いただけます。
https://qiita.com/ShinHashitani/items/ea9ffdefce8ca5786da6

パイゼロのバックアーメルサポートを追加する動きはありますか? 私はかなりの数のレイアウトを持っており、デモの目的で低コスト/電力のクラスターを作りたいと思っています

パイゼロのバックアーメルサポートを追加する動きはありますか? 私はかなりの数のレイアウトを持っており、デモの目的で低コスト/電力のクラスターを作りたいと思っています

こんにちは。上記の説明でわかるように、コアKubernetesはarmv6lのサポートを終了しました。
したがって、このサポートが再度追加される可能性はないと思います。

armv6lでk8s / kubeadmを使用する場合は、すべて(CNIイメージを含む)を再コンパイルする必要があります。

K8s 1.18.3をgolang:1.13-alpine docker imageでコンパイルすることで、ソースから正常にコンパイルできたと言っています。これは、マルチアーチイメージであり、armv6が含まれています。 (エミュレーションにQEMUを使用するようにDockerを構成しており、他のアーキテクチャーのコンテナーを実行できます。)

gitリポジトリのクローンを作成し、readmeページで4ステップのmakeプロセスを実行する(つまり、すべてのWHAT = cmd / componentを作成する)だけで、kubeletを除くすべてのk8sコンポーネントが静的にコンパイルされ、pizeroでスタンドアロンの実行可能ファイルとして実行されます。依存関係はありません。 (そして、golang-alpineが機能しなくなった場合、Arch Linux ARMを最初からブートストラップすることができます。これは、コンパイルには問題なく機能するはずです。)

唯一の問題は、kubeletのコンパイルがまだシステムglibcライブラリに動的にリンクしていることであり、それを修正する方法をまだ理解していません。 私はgoプログラマーではないので、goまたはgcc用に追加したコンパイルフラグはどれも違いがないようです。 (Kubeletには、コンパイルにgccが必要なため、Cコードがいくつかあると思います。)最悪の場合、実行するすべてのタイプのOSに対してDockerイメージをブートストラップできるので、glibc動的リンクは機能しますが、したくありません。それを行う。

Debianはまだ公式にarmelをサポートしており、静的にリンクされたkubeletバージョンのパッケージを持っているので、私のハッキーな解決策は現在、armeldebパッケージ内から静的バイナリを使用することです。

最後に、これらのバイナリ(および他のバージョン)を持つイメージを使用して独自のリポジトリを作成し、それらをプルするようにkubeadmを構成する必要があります。 さらに楽しいことに、Dockerはarm6で実行されますが、arm7イメージを誤ってプルするため(3年以上の既知のバグ)、arm7イメージを変更してarmelバージョンを実行するか、arm6とarm7の両方をで作成する必要があります。同じイメージで、エントリポイントを実行時にarm6またはarm7プログラムのどちらを起動するかを決定するシェルスクリプトにするだけです。 非マスターノードはkubeletとkube-proxyを実行するだけでよいので、おそらくこれらがこれを実行する必要がある唯一のイメージです。 (私が使用している人々について読んだ別のハックは、正しい画像をプルしてから、kubeadmがプルしたい画像になるようにローカルでタグを付け直すことです。したがって、ローカルバージョンを使用するだけです。)

私は実際にはansibleを使用してk8sを「難しい方法」でセットアップしていますが、kubeadmが機能するように、ドロップイン置換可能な準拠したDockerイメージを作成する予定です。 kubeletを静的に正しくコンパイルできる場合は、プロセスをDockerfileに自動化し、DockerHubにイメージを貼り付けます。 これらのイメージには、私が使用できる限り多くのアーキテクチャーがあるため、理想的には、マルチアーキテクチャークラスターでkubeadmを使用できるようになります。 例:amd64、arm64、arm6、arm7。 Pi Zeroの(ワーカーノードとしての)フルプロダクションDockerとK8は、小さなイメージを実行するために少なくとも50mbから100mbのRAMを残していると推定します。 そして、カーネルを削除すると、おそらくさらに30または40メガバイトを解放できます。 しかし、それは遠い未来です。 Pi ZeroでK8sによって管理されているnginxコンテナーによって提供される単一の静的ページを取得できる場合、当面はそれを勝利と呼んでいます。


8月7日から編集:すべてが機能するようになり、現在、arm6、arm7、arm8、およびamd64で構成されるK8sクラスターがあります。 近いうちにここでプロセスの記述を作成しますが、今のところ重要なポイントは、ワーカーノードとしてarm6デバイスにkubeadmをインストールすることです。必要なのは、kubeadmとkubeletのバイナリで、コンテナは2つだけです。一時停止コンテナ、およびkube-proxyコンテナ。 QEMUがある場合は、buildxを使用してバイナリをネイティブにビルドし、 Dockerfileを変更するだけ

または、 kubeadmkubelet用に作成したArchパッケージの/ usr / binディレクトリから静的バイナリをプルすることもできます。 私はPiZeroにArchLinux ARMをインストールしたので、CNIプラグインはパッケージによってシステムにインストールされましたが、Dockerfileを使用してビルド(またはArch Linux ARMパッケージからプル)してから、CNIバイナリをに配置できます。システム上のディレクトリ「/ opt / cni / bin /」。 そのフォルダにこれらのCNIバイナリがあり、kubeletがインストールされてサービスとして準備されている場合は、デバイスでkubeadmを実行するだけで、正常に動作するはずです。 唯一の要件は、コンテナエンジンですでに利用可能な正しいkube-proxyおよびpauseコンテナが必要なことです。

Pi Zeroesには、ストックDockerがインストールされており、Dockerファイルから構築したバイナリを公式のK8sコンテナーの分析と組み合わせて使用​​して、kube -proxypauseに互換性のあるarm6コンテナーを構築しました。 kubeadmでKubernetesバージョンをv1.18.6として指定するには、それらのコンテナーをそれぞれ「k8s.gcr.io/kube-proxy:v1.18.6」および「k8s.gcr.io/pause:3.2」として再タグ付けする必要がありました。コンテナがすでに存在し、システムに正しくタグ付けされている場合、kubeadmは文句なしに成功します。

他の唯一の問題は、オーバーレイネットワークが機能していることです。 これ以上コンパイル地獄を通過したくなかったので、「arm」バリアントがarm6とarm7で機能するFlannelを使用しました。 defautlyamlファイルを使用ます。 ただし、FLANNEL_MTUと呼ばれるすべてのセクションにenv変数を追加し、1430以下に設定する必要があります。 デフォルトの1500は、metrics-serverでいくつかの問題を引き起こします。 さらに、それを使用したい場合は、フランネルのすべての画像を1つのマルチアーチ画像に結合しました。 これにより、私が行ったことを実行し、デフォルトのyamlインストールファイルを1つのセクションにまとめることができます。

kubeadmとDockerCEを使用したこの「フル」K8sインストールでは、Pi Zeroesは約55%のCPU使用率でアイドル状態になり、約160MBのメモリが解放されます。 バースト容量のために少なくとも25%を残したいとすると、それでも約20%が残ります。これは、200ミリに相当します。 (PiZeroにはシングルコアの1GHzCPUがあります。)少し揺れる余地を与えるために、私は切り捨てて、コンテナー要求と制限を120mに設定し、RAMを100MBに設定しました。 これまでのところ、すべてが正常に機能しています。 唯一の問題は熱です。私のゼロはすべて、空気のスペースがあまりないかわいい積み重ね可能なケースに詰め込まれているからです。

(もちろん、マネージャーノードはPi Zeroではなく、Pi 4です。)


2020年12月1日からの編集:これが私の最後の更新になります。 実際、追加することはあまりありません。 Kubeadmにはyaml構成ファイルがあり、他のすべてのk8sコンポーネントと同様に、十分に文書化されているものはありません...しかし、試してみると混乱する可能性があります。

kubeadmオプションの1つは、イメージにカスタムレジストリを使用することです。これにより、マルチアーチイメージを作成してプライベートレジストリにプッシュし、Dockerでイメージにタグを付け直すだけでなく、セットアップに使用できます。 これは、Dockerを取り除き、ストレートコンテナを使用するために私が行ったことです。

コントロールプレーンコンポーネントをarm6用にコンパイルする方法がまだわかりません。 QEMUとネイティブデバイスはどちらも1GBを超えるRAMを許可しません。これは、Goがほとんどのコントロールプレーンをコンパイルするのに十分ではありません。 Goは理論的には他のアーキテクチャ用にコンパイルできることを知っているので、すべてのRAMを使用してamd64マシンでarm6をコンパイルできるはずです。 しかし、私の人生では、それを機能させることができないので、QEMUまたはデバイス自体のいずれかでネイティブにコンパイルすることになります。 つまり、arm6コントロールプレーンコンポーネントはありません。

しかし、それが唯一の問題です。 Kubeletとkubeadmはコンパイルされ、pauseコンテナーとkube-proxyコンテナーも同様にbuildxでビルドできます。 したがって、arm6でワーカーノードコンポーネントを機能させるのは簡単です。 ただし、円周率がゼロのクラスターを作成している場合は、リソースの使用量に合わせて微調整するために、kubelet構成ファイルを必ず読んでください。 (または、フルストックのk8ではなく、k3または別の軽量ディストリビューションを使用してください。)

ここに公開されている古いラズベリーモデルのバイナリがありますhttps://github.com/aojea/kubernetes-raspi-binaries
それらはgithubアクションジョブで作成されているので、自由に再利用してください

このページは役に立ちましたか?
0 / 5 - 0 評価