予備Kubernetesクラスタのセットアップ2023-08-04

注意

- arm-controller1のNFSで公開しているデータを使い続けているのでarm-controller1を消してはならない

あとやること

- {x} お試しデプロイ

- {x} workerのreboot

- ログが引き続き見れるのが謎

- {x} controlerlのreboot

- 手動作業

- loのIPをつけること

- 6443を開放する

- 80を開放する

- {x} ingressの実験

- hostportにすればOK

移行

最低限の移行を考える

- {x} todo-bot

- {x} web.inajob.tk

- {x} login-proxy, inline

- 同じNFSを指していれば以降は簡単

- {x} NFS

これだけっぽいな

inlineの永続化データ

- よく見たらnfsじゃなくてファイルをそのまま置いてhostpathでマウントしていた

- この機会にnfsにするのがよさそう

- できたのかな？

- NFSとしてマウントはできたが権限がだめ

- 今のhostpathマウントの方式だとroot:rootのファイルが作られている

- これだとNFS経由だと書き込みできない

- NFSの権限をrootにするのも違う

- 一旦nobody:nogroupにしても良いか？

- 良いが、元の構成に戻してページを作るとまた問題が起きる

- hostpathマウントのときも書き込み権限をnobody:nogroupにした方が良い？

- no_root_squashを設定する手もある（乱暴だが）

- 一旦これでできたぞ！

inline

- inline

- デプロイできた

- login-proxy

- デプロイできた

- {x} 結合できているか確認

- nodeSelector的なモノはどうやるか調べたい

- nodeSelectorでラベル設定した

web.inajob.tkをデプロイしてみる

- NFSはどうやればよい？

- iptables -I INPUT 6 -p tcp -m state --state NEW -m tcp --dport 2049 -s controllerのIP -j ACCEPT

- さらに/etc/exportfsに許可設定を書いて exportfs -ra とかするんだっけ？

- imageがarmに対応していなかった

- この機会に上記2つが必要かを確かめる

- exportfsだけやってみる

- ダメでした no route to hostとかになる

- iptablesも入れた

- cloudflareで個別に向きを変えることに成功

デプロイしてみる

- ingressをデプロイしたい

- めっちゃエラーする

- at worker

- iptables -I INPUT 6 -p tcp -m state --state NEW -m tcp --dport 10250 -j ACCEPT

- これは危険な気がする

- dial tcp 10.96.0.1:443: i/o timeout

- おそらくworkerのPodからcontrollerのPodにアクセスできていない

- controller

- iptables -I INPUT 6 -s 10.0.0.230 -j ACCEPT

- 効果無さそう

- calicoをやめるか・・

- weaveを試そうと思ったがarm用のマニフェストではなさそう・・

- rebootで仕切りなおそう

- calicoで試したが駄目だな・・

- 次どうしよう・・

- pod間通信がだめなのか、apiserverにつながらないだけなのかが知りたい？

- advertiseをやめてみる

- 結果は一緒

- 疎通確認

- workerのPodからインターネットに出られない、名前解決もできない

- kube-dnsのsvcにつながらないから名前解決が出来ないっぽい

- controllerのPodからインターネットに出られない、名前解決もできない

- kubectl taint nodes --all node-role.kubernetes.io/control-plane-

- 前もこうなった気がするな・・

- calicoなしでもこうなるのか気になる

- /etc/cniのファイルを手で少し消す

- weaveのが残っていた・・これかな

- calicoだけ入れなおす

- まだ駄目、インターネットに出られない、名前解決もできない

- flannelはどうか？

- インターネットに出られない、名前解決もできない

- containerdに帰ってくる

- この辺を設定してみるか・・

- なんかうまくいってる？

- CNIはcalicoを試す

- やはりインターネットに出られない・名前解決もできない

- firewallで一部のルールを直したらcontrollerのPodからインターネットに疎通した！

- workerはまだうまくいかない

- 再起動してみる

- NG

- flannelにしてみる

- controllerはOK

- workerはNG

- iptablesがlegacyになっていた（推奨のはずだが）

- 相変わらず出れない

- 名前解決が出来ないだけだ！

- pod間通信ができない flannelがおかしいような・・

- いや、これはもともとできないのか？

- もう一度calico試すか？

- うまく動いていないポイ

- weaveはどう？

- これっぽい

- workerから名前解決が出来ない

- dnsだけならkube-dns ConfigMapで何とかなるか？

- 気にせずingressを入れてみるか・・

- なんか動いたな

- DNSが引けない問題

- corednsがいないnodeから名前が引けない？

- 2Nodeに分散配置させたら確率的につながるようになった

- nodeをまたいだpod間通信ができないということっぽい

- firewallっぽいよなー

- workerのweaveがcontrollerのweaveにつながらないエラーを出しているのを見た

- Oracle Cloud側のfirewallのUDP6783,6784が原因だった

- これでうまくいった気がする

- 結論

- containerd

- 設定ファイルを再生成する必要あり

- 多分cri-oでも行けそう

- ここは挑戦しなくてもよさそう

- weave

- マニフェストに修正が必要

- flannel, calico

- ちょっとわからない firewall周りを整理すれば動くと思う

必要か不明なiptables

おそらくweaveの通信のために必要

> code

iptables -I INPUT -p udp --dport 6783 -j ACCEPT

iptables -I INPUT -p udp --dport 6784 -j ACCEPT

iptables -I INPUT 8 -p tcp -m state --state NEW -m tcp --dport 6783 -j ACCEPT

<<

手順を整えてスクリプトにする

- {x} バージョンを固定する

- {x} controllerのスクリプト化

- {x} workerのスクリプト化

次にWorker？

- CNIはcalicoにしよう

- controllerのファイアーウォールはどうすればよいのかな

- とりあえず6443をあけよう

とりあえずcontroller

controller

- 動作実績のあるバージョンでまずは試す

- と思ったけど手元の手順だと最新版になってしまいそう・・

- ii kubeadm 1.27.4-00 arm64 Kubernetes Cluster Bootstrapping Tool

- 上がってこない・・？

- kubeletのfail-on-swapの問題だった、やり直し

- よしできた

- apiserver-advertise-adressをあえて指定する方式にしているけど、これが必要なんだっけな・・

- 結果としてjoinの引数もこっちのアドレスになっているけどうまくいくかな？

worker

- 一応上の引数で動き始めたように見える

- kubeletがあがってこないか・・・

- 上がってきた

なんかおかしい

- システムのものも含めてコンテナが全部消えてしまった・・

- こうなるとkubeadm resetもうまく動かないような・・

- resetしてやり直してみる

- controllerのkubelet-checkが終わらない予感・・

- kubeletが暴走している・・

- advertiseが悪さをしている？

- 一旦消して様子を見る

- weaveも入れてみる

- weaveはダメなのでcalicoにする

- kubeadmとkubeletの相性みたいなのがあるのかな？

- CIDRに合わせてファイルを修正

- calicoはうまく動くようになった、お、クラスタがGREENに！

- ちょいちょいcrashしているような・・

- workerも参加させてみる・・

- また動かなくなってしまった・・

- dockerが古い説

- だめだな、同じ問題が起きる

- 起動してしばらくするとapiserverが落ちる

わからないこと

- コンテナのログを見る方法がわからない

あとやってみたいこと

- バージョンを変える

- kubeletのバージョンを固定する必要がありそうなので順番にやる必要あり

- 1.27.4がだめだった

- 1.26.7を試す

- ぱっとは動かないな・・再起動してみたい

- 再起動してもダメ

- なにか根本的な設定が抜けている気がする、チュートリアルをちゃんと読もう

- 読んだけど良い対策は思いつかない・・

- VMがダメということはあるのか？

- cri-oを使う？

- cri-oのインストール

- VERSION=1.24

- export OS=xUbuntu_22.04

- いろいろ設定した

- ifconfigで自分のIPを指定していないのが心配・・

- 次は再起動してipを足してから実行してみよう

- うまくいっているっぽい

- containerdが悪かったのかー

- なにか設定が足りていないんだろうな

- 再起動時にcrioが死んでいるのが気になる

- 一旦無視

- controller 141.147.157.77

- worker 168.138.41.130

- kubeadm以外で構築する

- いいのがあるかな？