Infrastructure on Ingenboy.inc

Learn_k8s_4

Sun, 18 Aug 2024 14:37:23 +0900

大人気K8Sシリーズ。今回でなんと第４回目まずは、過去の振り返りをやっていきましょう。

振り返り

構築日記その3 第１回目と第二回目はインフラ構築を頑張っていた感じです。引っ越しとかあって、K8Sの勉強は飛び飛びになっている感じでね。そして、第３回にして、やっと色々とインフラ構築をスムーズにできて、さまざまな概念についても理解できてきた、という感じです。はい、サービスね。これが大事な概念だった。POD間で通信をするためには、Serviceが必要だったのではないか？とね。ServiceでPODをcoreDNSに登録することができる。そして、基本的に一つのサービス内での通信はしない。サービス間の通信はあるが。なので、docker composeのようにはいかないという話だな。

そして、今回の第４回目では、K8Sの使い方をもっと詳しく理解していきましょう、という回になっています。具体的には、「つくって、こわして、直して学ぶkubernetes入門」という本に従って色々と進めていきたいと思っています。はい。そして、第５回目に、私が開発した競馬システムをついにデプロイする、という感じに持っていきたいと思っています。よろしくお願いします。

まずは、harborにログインしておく

の前にロボットアカウントを作らないといけない感じ？

docker login 100.64.1.61:20080 -u username -p password server

nerdctlを使っているので、buildを使うためにbuildkitをインストールする必要がある。

しかも、buildkitdというのを走らせておく必要がある。

テストでgoで簡易サーバを作って走らせる

package main

import (
        "fmt"
        "log"
        "net/http"
)

func main() {
        http.HandleFunc("/",func(w http.ResponseWriter, r *http.Request) {
        fmt.Fprintf(w,"Hellow, wordl!")
        })

        log.Println("starting server on port 8880")
        err := http.ListenAndServe(":8880", nil)
        if err != nil {
                log.Fatal(err)
        }

}

dockerfile

FROM golang:1.23 AS builder
WORKDIR /app
COPY . .
ENV CGO_ENABLED=0
RUN go mod tidy
RUN go build -o hello .

FROM scratch
COPY --from=builder /app/hello /hello
ENTRYPOINT ["/hello"]

go.modを入れるのを忘れずに。 go mod init github.com/hogehoge とかで問題ない。

Learn_k8s_3

Sat, 27 Jul 2024 22:21:28 +0900

k8s構築日記その３。

過去の奮闘記録。構築日記その１構築日記その２実は今まで一回もK8S上でアプリを動かしたことがないという。これは正直恥ずかしいですね。構築はしたが、動かせはしていないという話だな。勿体無い！！ってことで、今回は、K8S構築日記その３ということで、構築日記その１と構築日記その２を振り返りつつ、ちゃんとアプリをクラスタ上で動かせるようにしたいと思います。はい。動かすアプリは、そうです、例の競馬アプリです。そして、外部に公開して、しかも、インターネットから見えるようにしたいと思う。これができるとまじで最高だぜへへ。

まずは構築から昔の俺が残してくれた手順に従って構築をやります。

クラスター情報

master : controle plane gamma : worker zeta : worker

でやりたいと思います。ちなみにマスターのosはraspbianです。

バージョン情報

このサイトを参考にバージョンを決めた。 k8s (kubelet : kubeadm) : 1.27 containerd : 1.7.0 + なので、1.7.2でインストールする。 containerdのarmバイナリ

k8sを導入するまとめ

1. containerdを導入。

k8sのv1.25以降は、コンテナエンジンにdockerエンジンを使えません。(理由は、dockerがcriを満たしていないから)。criを満たしてるcontainerdをインストールする必要があります。 containerdのインストールは、githubのリポジトリからできます。同時に、runcとcniもインストールしてださい。ちなみに、cniは、container network interfaceで、まあ、コンテナのネットワークを操るためのapiですね。で、そのapiを操るのが、cniプラグイン。で、cniプラグインには、calicoだったり、flannelだったりがあるわけですね。で、プラグインには、3種類のモードがあって、オーバーレイと、ルーティングと、アンダーレイですね。オーバレイを使うことで、別のホスト上にいるコンテナ同士が同じセグメントにいるようになります。

で、だけど、/etc/cni/net.dにはデフォルトのやつ、おかなくて結構です。まったく問題ありませんので、お気になさらず。ということで。ちなみに、これにはruncも入っているので安心してインストール/ダウンロードしてください。全く問題ないです。

wget https://github.com/containerd/containerd/releases/download/v1.7.20/cri-containerd-cni-1.7.20-linux-arm64.tar.gz
mkdir containerd_dir
mv cri-containerd-cni containerd_dir
tar xvfz cri
sudo mkdir /etc/containerd

必要なものを必要なディレクトリに置いてくれるように以下のスクリプトを実行

#!/bin/bash

# Define the paths to your installation directories
CONTAINERD_BIN_DIR="/usr/local/bin"
CONTAINERD_SBIN_DIR="/usr/local/sbin"
CONTAINERD_ETC_DIR="/etc/containerd"
CONTAINERD_SYSTEMD_DIR="/etc/systemd/system"
CONTAINERD_OPT_DIR="/opt/"

# Define the source directory where you extracted the Containerd files
SOURCE_DIR="/home/ray/containerd_dir"

# Move binary files to /usr/local/bin
cp -r "$SOURCE_DIR/usr/local/bin/"* "$CONTAINERD_BIN_DIR/"

# Move sbin files to /usr/local/sbin
cp -r "$SOURCE_DIR/usr/local/sbin/"* "$CONTAINERD_SBIN_DIR/"

# Move etc files to /etc/containerd
cp -r "$SOURCE_DIR/etc/"* "$CONTAINERD_ETC_DIR/"

# Move systemd service file to /etc/systemd/system
cp "$SOURCE_DIR/etc/systemd/system/containerd.service" "$CONTAINERD_SYSTEMD_DIR/"

# move cni and other utils to opt
cp -r "$SOURCE_DIR/opt/containerd" "CONTAINERD_OPT_DIR" 
cp -r "$SOURCE_DIR/opt/cni" "CONTAINERD_OPT_DIR" 

# Reload systemd to recognize the new service
systemctl daemon-reload
echo "Containerd installed successfully."

nerdctlも一緒にいんすとる

Proxmoxサーバ爆誕

Sat, 06 Jul 2024 13:11:18 +0900

何の記事か

Proxmoxという仮想マシン専用のマシンを立てる方法。そして遊んでみる。

参考文献

[proxmoxのインストール方法] (https://qiita.com/C_Kenta/items/70ecb32495fce9e1de52)

proxmoxを使ってできること

Proxmoxとは何か

ProxmoxはDebianベースの仮想化プラットフォームです。操作はすべてWeb インターフェースで行うことができ、仮想マシンやLinuxコンテナを簡単に作成することができます。バックアップを簡単に作成でき、修復も非常に容易です。ハードウェアパススルーも可能で、USBカメラ、マウス、キーボードなどのデバイスをVMに渡すことができます。

ひところ

えぐい

立てる

手順

公式から

proxmoxのisoを持ってくる。以上。

インストール時の注意点

最新のをインストールしようとしたら、waitinig for /dev fully populated 的なのが出てきたけど、それは一個前のどの手段でインストールするかのところでeを押して、カーネルのブートパラメータにnomodesetをつけると解消された。よろぴく
実はVMてハードウェアの動きをソフトウェアでエミュレートする方法と、もう一つKVMってのがあってね、KVMの方が圧倒的に速いわけですよ。んでね、 KVM hardware virtualizationってのをOFFにすると、ソフトウェアでエミュレートになる。しかし、これは遅いからKVM hardware virtualizationはONにした方がいい。しかし、ONにするにはBIOSでKVMをonにする設定を施さないといけない。それはリモートからではできないって話だな。乙。

BIOSのKVM VirtualizationをOFFにしたままUbuntuを走らせようとしたらこう怒られました。

KVM virtualisation configured, but not available. Either disable in VM configuration or enable in BIOS.

advanced setting -> CPU Configuration -> SVM Mode -Enable > Save & reset これをやらないと勝ちで遅すぎて話にならなかった。すべてが遅すぎる。マジで、CPUの動きをエミュレートする仮想化は、KVMと比べて10倍遅かった。えぐい。

GPUのパススルー

これが結構面倒くさい。 VM上でOllama立ててllmを動かそうとしているんだけど、なかなかうまくいかない。これはchatgptから得た回答だから、確証はないんだけど、参考にしてほしい。 chatgpt曰く、やらないといけないことは二つ

Enabling IOMMU
Enabling VFIO

Enabling IOMMU

これは何をやっているかだけど、

KVM_server_and_ansible

Sat, 06 Jul 2024 12:11:18 +0900

何の記事か

LinuxサーバでKVMを使った仮想マシン (VM)を立てられるようにし、 KIMCH を使い、webコンソールからVMを立てられるようにし、さらにansibleでVMにインフラのデプロイ、そしてネットワークなどをいじる記事

雑談

はい、完全に分離された自宅ネットワークでしたが、openVPNを使ったsite2site接続により、外からアクセスできるようになってしまった。これがマジで恐ろしい話や。再びコンピュータを勉強する気力がわいてきたって話だ。頑張るぞい。

dkong上で動かそうと思う。自宅ネットワークでのdkongのipアドレスは 100.64.1.70や。VPNを使えばいつでもアクセスが可能になる。さらにインターネット上のhugo_serverのnginxでvpnをとおしてプロキシすることもできるので、実質インターネットに接しているdkongってわけだ。ネットワークえぐい。

インストール手順

基本的にはKIMCHここに書いてある通りに進めれば問題ない。

1. Wokのインストール

Wokとは

Wokのリポジトリをクローン

git clone https://github.com/kimchi-project/wok.git

wok依存ライブラリやランタイムなどをインストール

sudo apt install -y python3-pip

sudo -H pip3 install -r requirements-dev.txt

sudo apt install -y gcc make autoconf automake git python3-pip python3-requests python3-mock gettext pkgconf xsltproc python3-dev pep8 pyflakes3 python3-yaml

sudo apt install -y systemd logrotate python3-psutil python3-ldap python3-lxml python3-websockify python3-jsonschema openssl nginx python3-cherrypy3 python3-cheetah python3-pam python3-m2crypto gettext python3-openssl

Wokをビルド and install

sudo ./autogen.sh --system
make

wokを起動

sudo python3 src/wokd

wokにブラウザでアクセス

https://100.64.1.70:8001/login.html

初期パスワードを入力してログイン

これ、ログインクレデンシャル、システムのとおんなじなのがすごい。びっくり！

Slurmクラスタ構築日記

Mon, 16 Jan 2023 23:59:40 +0900

HPCといえばSlurmだよね

ラズパイが腐るほどあるので、Slurmクラスタを作る。流れとしては、Slurmの全体像を理解してから、実際にSlurmをインストールして、クラスタを構築。んで、MPIジョブを投入できたら最高ですね。

参考文献

slurm公式

Slurmの全体像

クラスタを使って並列分散処理をしたいとき、どうするか？例えばMPIを使ってなにかを計算したいとき、どうするか?直接mpirunをすればいいよね？簡単だ。うん。ユーザがおれ一人で他の人がクラスタを使わない前提であれば直接実行していいよね。しかし、HPCシステムってのは基本的にはいろんな人に使われるんですよ。そんな時にいろんな人が同時にMPIのジョブを実行すると何が起こるか？まあ、これは予想だけど、基本的に1つのMPIプロセスに対して1つのコアが割り当てられるので、コア数を超えるプロセスが割り当てられそうなときは、mpirunの実行が失敗すると思うんですよ。

このようなリソース競合によるジョブの実行失敗などを防いだり、その他、リソースのマネジメントをするのがリソースマネジメントシステム(RMS)だよね。SlurmもRMSなわけだ。いろいろなRMSがあるわけで、その中でもSlurmの特徴が三つある。

ある一定期間、ユーザが計算資源（ノード）を占有することを許す
各ノードに対して、ジョブのスタート、実行、監視を可能にする
待ち行列内のpending jobに対して、恣意的な実行を可能にする

slurmのアーキテクチャ

各ノードでslurmdデーモンが動いている。そして、マネジメントノード（マスターノード）ではslurmctldデーモンが動いている。ユーザはクライアントアプリを使って、slurmctldにアクセスし、ジョブのサブミットや、状態の確認ができる。

Slurmのインストール

参考文献

文献1 文献２(一番参考になった資料)

前提

ノード間でuidが同じユーザが作られていることこれは、最初にラズパイの設定をするときにユーザ名を一律に決めておくことで解決できる。
ノード間でシステムの時刻が一致している事これは、raspi-configのロケール設定でAsia/Tokyoを選ぶことで解決できる

マスターノードのあるディレクトリをnfsとして外部にエクスポートしておくといろいろとらく

マスターノード、スレーブノードのホスト名を決めておく

/etc/hosts

マスターノードの設定

リポジトリからのインストール

sudo apt install slurm-wlm -y

Slurmの設定

設定ファイルの場所は

/etc/slurm/slurm.conf

この場所に、デフォルトの設定ファイルを持ってくる

cp /usr/share/doc/slurm-client/examples/slurm.conf.simple.gz .
gzip -d slurm.conf.simple.gz
mv slurm.conf.simple slurm.conf

設定ファイル(slurm.conf)の内容は厳密にかかないとだめ

SlurmctldHost=node01(<ip addr of node01>)
# e.g.: node01(192.168.1.14)
# actual : zeta(172.20.2.1)

SelectType=select/cons_res
SelectTypeParameters=CR_Core
...
...
ClusterName=glmdev
...
...
NodeName=zeta NodeAddr=172.20.2.1 CPUs=4 Sockets=1 CoresPerSocket=4 State=UNKNOWN
NodeName=slave1 NodeAddr=172.20.2.3 CPUs=4 Sockets=1 CoresPerSocket=4
State=UNKNOWN
NodeName=slave2 NodeAddr=172.20.2.4 CPUs=4 Sockets=1 CoresPerSocket=4
State=UNKNOWN
NodeName=slave3 NodeAddr=172.20.2.5 CPUs=4 Sockets=1 CoresPerSocket=4
State=UNKNOWN
NodeName=slave4 NodeAddr=172.20.2.6 CPUs=4 Sockets=1 CoresPerSocket=4
State=UNKNOWN
PartitionName=mycluster Nodes=slave[1-4] Default=YES MaxTime=INFINITE
State=UP

cgroup関係の設定ファイルをつくる

/etc/slurm/cgroup.confに

k8sクラスタの環境構築

Tue, 27 Dec 2022 21:11:31 +0900

ことはじめ

k8sという技術が注目を浴びている。web業界での近年の大きな変化としてはアプリケーションアーキテクチャの変化が挙げられる。従来は、アプリケーションを構成するソフトはモノリシック(一枚板)であった。つまり、アプリケーションは、一つのソースコードで1プロセスで動いているような感じだった。しかし、このモノリシックなアーキテクチャではソースコードが複雑で、変更が加えにくい等の問題があった。チームで開発する際も、メンバーみんなが同じソースコードをつかってビルドをする必要がある等、いろいろと面倒なことが多かったと思う。そこで、近年はアプリ開発にはマイクロサービスアーキテクチャが採用されている。マイクロサービスアーキテクチャは、小さなコンポーネントの集合が全体として一つのアプリケーションを構成しているようなアーキテクチャである。

自分も意図せずして、開発してきたアプリはマイクロアーキテクチャにしていたが、こちらの方が各コンポーネントの役割をきちんと明確化して進められるので、開発を分担できるのと、変更を加えるとき、役割がコンポーネントに分かれているので、各コンポーネントの中身だけを変えればよく、管理が簡単になると思われる。つまり、APIだけそろえておけば、後は中身はなんだっていいということだ。これによって、アジャイル開発が非常に簡単になると思われる。そして、このコンポーネントをひとつひとつをコンテナ化するってのも近年の大きな流れっぽい。そして、コンテナ化されたコンポーネント（マイクロサービス）をうまく協調させるのがコンテナオーケストレーションツールってはなしだ。コンポーネントを協調させる、と書いたが、具体的には(k8sの機能は非常に多いので、俺が理解できる、かつ、大事そうなものだけをピックアップする)、

コンテナのスケジューリング
スケーリング/オートスケーリング
障害時のセルフヒーリング
ロードバランシング
ワークロードの管理とかがある。

一方、HPC分野でもK8Sを活用しようという試みがある。これはどういうことか？実は僕もよくわかっていません。k8sをスケジューラに使おうっていう話ぽい。そして、slurmと比較して、k8sが何なのかってのを調べてるみたいですね。参考資料を少し上げておきます。

ref1 ref2 ref3

これは研究室の仲間と一緒に調べていくことにして、僕は僕で、web業界で使われているk8sがどんなものなのかに焦点を合わせて勉強していきたいと思う。そして、実際にk8s上で去年開発したアプリを動かしてみる、というのを最終目標にしたいです。せっかくあのアプリはマイクロサービスアーキテクチャになっているからね。インターフェースは全部rest化されているし。

物理クラスタの構築

実験環境はラズパイクラスタです。まあ、自宅lan内にマスターノードを1台置いて、その下にあらたなネットワークを作って、マスターノードでnatした。あと、サブネットワークでipを固定した。詳しくは、別の記事に書いてあるのでそっちを見てくれるとありがたい。

k8sの基本的なコンポーネント

参考動画基本用語説明 dbと連携させたjsアプリを題材に、k8sのコンポーネントを説明していくよ！

cluster k8sのリソースを管理する集合体のこと
node 物理マシン、もしくは仮想マシンのこと。つまり、ホストのこと。ノードには、master nodeと普通のnodeがある。

master nodeはkubernetesを管理するため、次の管理コンポーネントを持つ

kube apiserver:kubernetesのAPIを公開する。kubectlからの操作を受け付ける役割。kubeletからもアクセスを受けるし、他にもいろいろなクライアントがある。これがclusterへのgatewayになる。
etcd:分散kvs。クラスタのバッキングストアとして使用される。ログとかが記録されている。etcdは分散kvs、ということはetcdを何個か立てることが可能、ということでして、そうするとetcd間で内容の一貫性を保たないといけないわけですね。ということは？お？層です。分散合意アルゴリズムのraftが使われているわけですね。最高です。
kube scheduler:コンテナを配置する最適なnodeを選択する。ここも研究の対象になりえるところではある。
kube controller manager: リソースを制御する

普通のNodeはコンテナ化されたアプリケーションを実際に実行するホスト

pod コンテナの集合体。PodはNodeの中で動作し、一つ以上のコンテナを持つ。 K8sにデプロイするときは、Pod単位で行う。 pod一つでなにか機能を果たす、とかそういう感じでpodにまとめるのだと思われる。そうだね、1 application per Podというのが基本らしい。しかし、そのアプリケーションは2つのコンテナから構成されていても問題ない。

k8sはvirtual networkを提供。各Podはこの仮想ネットワーク上でIPアドレスを持っている。そして、これが結構大事な概念だんだが、Podは結構簡単に死ぬ。そして、Podが死んだら、新しいPodがデプロイされるのだが、その時にIPアドレスが変わってしまうというのが不便らしい。その時に使うのがServiceらしい。

Container Dockerコンテナのこと
ReplicaSet 同一仕様のPodを複数生成する仕組み。 ReplicaSetを複数持っておくことで、一つのReplicaSetが死んでも他のReplicaSetに処理を移すことでシステムが死んでいる時間をなくす。後は、ロードバランスもできる。

データベースは基本的にk8sクラスタの外で管理する。というのも、ステートを考えるのが面倒くさいかららしいです。

Service Serviceは、Podにアクセスするための経路を定義。 PodのIPアドレスを固定できる。外部への公開ポイントもここで設定する。
Deployment ReplicaSetの上位リソースで、ReplicaSetを管理する。つまり、 DeploymentがReplicaSetを管理し、ReplicaSetがPodを管理する。