kubernetes（OKE）に触ってみたかった

ただ触ることも難解だったkubernetes（OKE)
とりあえずapplyまで進めたので、これに至るまでに詰まったポイントをまとめる

コンテナレジストリ（OCIR）にイメージアップすると、rootコンパートメントに作られる

OralceCloudのチュートリアル中にハマった出来事
OCIRのリポジトリ名はコンパートメントによる垣根は無く、テナンシの中で一意である必要があるっぽい
そんな仕様が影響してなのか、OCIRにDockerイメージをアップロードするとなぜかrootコンパートメントに作られてしまう。

特定コンパートメントのOCIRにイメージをアップロードしたい場合は、事前にアップ予定のイメージ名を使ったリポジトリを作成しておくことで解決！

アップ後にOCIR側でリポジトリを削除してしまうと
アップした側のイメージが消せなくなるので注意

Error response from daemon: conflict: unable to delete c6098c195dd0 (must be forced) - image is referenced in multiple repositories

やってしまったら-fオプションを使って強制的に削除することで解決！

kubectlの設定

チュートリアルを進めるにあたってkubectlコマンドを扱う必要がある
cloudshellで進めない場合は、自前で環境を整える必要があった
チュートリアルをしっかり読めば書いてあるので、忘れずに。。。
kubectl導入公式ドキュメント
https://kubernetes.io/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#set-the-kubeconfig-environment-variable

大体下記を実施すればOK

/// config用ディレクトリ作成
mkdir -p $HOME/.kube

/// 変数を設定
export KUBECONFIG=$HOME/.kube/config

/// 公式からkubectlを取得
curl -LO "https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl"

/// 実行権限を付与
chmod +x ./kubectl

/// bin配下に移動
sudo mv ./kubectl /usr/local/bin/kubectl

.kube/configは、「ローカルアクセス」を選択したあとに実行する諸々のコマンドを実行すると設定できる
　※パブリックな通信が必要な場合はserver:を「APIパブリック・エンドポイント」に書き換える必要があるので注意

ワーカーノードが永遠に「準備未完了」「NotReady」

これに関してはいまだに謎。解決できず
ノード内のkubeletは起動していた、ノードのリソースも潤沢、ネットワークはALL-PASS...
もっと知識があれば。。。
今後参考になりそうなサイト様
　※今回の事象とは違うけど、pendingではあったので

[root@03fd79ec479c ~]# kubectl get nodes
NAME            STATUS     ROLES   AGE    VERSION
10.130.25.133   NotReady   node    168m   v1.25.4
10.130.25.170   NotReady   node    169m   v1.25.4
10.130.25.87    NotReady   node    125m   v1.25.4

同じ設定でクラスタ（OKEごと）を作り直したら正常に作成できたので運が悪かったと思うしかない
（誤字ってクラスタ名に「^」を入れてたから変な挙動になっちゃった説が濃厚だけど、だったら作成時に弾いてほしい。。）

診断シェルを実行してみた結果

[opc@oke-cq5lxkakytq-nizduohamxa-sgp6iembhoa-0 ~]$ sudo /usr/local/bin/node-doctor.sh --check
/usr/local/bin/oke-node-doctor.tar.gz does not exist.
Verified OK
pip requires Python '>=3.7' but the running Python is 3.6.8
INFO: Successfully downloaded node doctor.
pip requires Python '>=3.7' but the running Python is 3.6.8
Running node doctor...
PASS node health...
PASS DNS lookup...
SKIP kubelet cert rotation flag...
FAIL kubelet logs...
PASS iscsi health...
PASS service health...
PASS instance metadata...
WARN cloud-init version...
SKIP cloud-init status...
SKIP chef onboard status...
PASS image and instance info...
Command line error: one of the following arguments is required: --save --add-repo --dump --dump-variables --set-enabled --enable --set-disabled --disable
SKIP yum status...
FAIL flannel status...
FAIL coredns status...
FAIL proxymux-client status...
PASS kube-proxy status...
PASS pods in ImagePullBackOff...
PASS pods failed mounting volume...
SKIP proxymux client registration status...
PASS runc version...
PASS pod usage...
PASS br_netfilter module availability...

Signal 1: COREDNS_NOT_RUNNING
Description:
A coredns pod in the kube-system namespace was found, but was not running

Signal 2: FLANNEL_NOT_RUNNING
Description:
A flannel pod in the kube-system namespace was found, but was not running

Signal 3: PROXYMUX_CLIENT_NOT_RUNNING
Description:
A proxymux pod in the kube-system namespace was found, but was not running

Signal 4: KUBELET_FAILURES
Description:
There were error messages detected in the kubelet logs

Signal 5: CLOUD_INIT_CUSTOMIZED
Description:
Instance user_data is different from OKE native cloud init

Node doctor scan is complete. Report has been saved at /var/log/oke-node-doctor/oke-node-doctor-12712.log

CrashLoopBackOffが発生

新しく作ったクラスタに対してやっとapplyしてみたら、今度はポッドにエラーが発生

[root@98a19bcec3db ~]# kubectl get pods
NAME               READY   STATUS             RESTARTS       AGE
7656bdd5c7-8zfxj   0/1     CrashLoopBackOff   6 (110s ago)   7m32s
7656bdd5c7-vz6cl   0/1     CrashLoopBackOff   6 (98s ago)    7m32s

ログを確認すると、フォーマットエラーと表記

kubectl logs 7656bdd5c7-8zfxj -c ＊＊＊
exec /usr/local/bin/httpd-foreground: exec format error

ChatGPTにエラーを貼ってみたら、互換性が無いと言われる

• 実行しようとしたバイナリファイルが、コンテナのOSと互換性がないことを示しています。つまり、otsuka-world コンテナのイメージに含まれている httpd-foreground が、コンテナが実行されている環境と互換性がないために失敗している可能性があります。

もしや　ArmCPU環境で作ったDockerイメージが悪いのか？

[opc@docker docker]$ uname -a
Linux docker 5.4.17-2136.314.6.3.el8uek.aarch64 #2 SMP Tue Dec 13 20:02:15 PST 2022 aarch64 aarch64 aarch64 GNU/Linux

と思って、別環境で同じDockerfileを使ってイメージを再ビルド
再ビルドしたイメージをOCIRに上げ直し、もう一度applyしてみると
正常に起動することを確認

[root@98a19bcec3db ~]# kubectl get pods
NAME              READY   STATUS    RESTARTS   AGE
77d995c9b9-jlsrl   1/1     Running   0          35s
77d995c9b9-qzq7v   1/1     Running   0          28s

結果
OKEはx64ベースのCPUでイメージをビルドしたものじゃないと正常に動かないことがわかった（もしかしたら、やり方があるのかも）
今後は、M1,M2MacやArm製CPUでの作業はこの点の注意が必要
もしくはマルチCPU対応したイメージを作っておくと良いのかもしれない

まとめ

チュートリアル進めたら何かわかるかなぁと思いながら始めたけど
何もわからないままエラーに揉まれて時間だけが過ぎていきました。
もっと深掘りしたい、yamlを思うがままに書きたい