K8s

やりたいこと k8s上にechoサーバを分散させる プロキシサーバ (nginx) を立てて、そいつらに負荷分散できるようにする Mtailを使って、nginxのログを収集して、prometheus形式に変換、telegrafで取得しinflux Dbに送信　（このときにタグもつけたいかも） Cloudproberでnginxを監視したい。cloudprober -> prometheusに変換 -> telegrafで取得しinflux DBに送信（タグもつけたいかもしれない） 以上を全てansibleを使って実現したいという話だよね。厳しいかな。どうかな？？ 正直k8sは必須ではない。時間がかかりそうであれば、先にgoとかで簡単なecho-serverを作って1を完了させてしまうのも全然あり。 今回の目的はあくまでnginxのモニタリングをガチガチにするってことだからね。でも、k8sの監視はちょっとしてみたいかもしれないね。 最初からprometheus形式でexportしてくれるみたいだからね。気になるところではあります。 ただ、k8sはその性質上、コンテナをデプロイするから、どこからコンテナを取ってくるかを決める必要がありますね。外部に漏らしたくない情報が入っているのであればprivateリポジトリを立てるしかない。そうでなければdocker hubでいいかな。

大人気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 とかで問題ない。 ...

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も一緒にいんすとる ...

背景 ついにインフラエンジニアになった。インフラエンジニアになったのであれば、インフラ関係を一通りこなせないと話にならないだろう！ というお話です。ということで、クラスタ作って、クラスタがいい感じに運用できるようにいろいろとインフラを構築していこうと思う。 さらに言うと、業務でansibleを使っているので、IaC（インフラストラクチャasコード）を実現したいと思っている。これができればいつでもそのインフラが再現可能になるからね。練習も込みで。 要件 完全に独立したネットワークを構築したいと思っている。そのため、 ルータ が必要。この時、内部ネットワークから外部にアクセスする必要がないよね。だから、natでいいわけだね。 次に、サブネット内でDHCPをしつつ、アドレスの固定を一括で管理したい。 それの実現方法がDHCPを使って、macアドレスとipを対応付けるという方法。 さらに、ネットワーク内で、ipアドレスではなく、ドメイン名でアクセスができるようにしたいので、DNSサーバも立てたい。 最後、K8Sのコントロールプレーンだね。これは作りたい。 K8Sサーバに何を立てるかだけど、とりあえずechoサーバを立てて負荷試験をやってみたい。そうだね。将来的には配信サーバなどを立てられるといいのだけれど 後は、prometheus + graphanaで、負荷を可視化できるとなおいいよね。時系列でどれくらい負荷がかかっているのかが見れると最高だと思います。 各サーバにいちいち入るのは面倒くさいので一括でsshしたいと思っています。これを可能にする方法を岡田さんが考えてくれました。 msshですね。 各物理サーバ（ラズパイ）のハードウェアスペック router : raspi 5. RAM 8G. Storage 128G beta : raspi 4. RAM 1G. Storage 32G delta: raspi4. RAM 4G Storage 64G phi (f): raspi4. RAM 8G. Storage 32G gamma: raspi4. RAM 8G Storage 128G omega: raspi4. RAM 1G storage 32G zeta: raspi4. RAM 8G ここから使える奴だけ選抜する。 router, delta, phi, gamma, zeta の5台。一台は、router + dhcp + dnsの役割を持たせる。 容量的にdeltaがよさそう。そのほかは、k8sクラスタになる。頑張ってくれ。 k8sちゃんと動いてくれ！! ちなみに、 ...

learn_k8s_2! はい、前回がk8sクラスタの構築部分でした。ここからは実際に運用をどうするか？ってところに焦点を当てていきたいと思います。 前回の冒頭の記事はいい感じだったので、ここにも書いておきたいと思います。 ことはじめ k8sという技術が注目を浴びている。web業界での近年の大きな変化としてはアプリケーションアーキテクチャの変化が挙げられる。従来は、アプリケーションを構成するソフトはモノリシック(一枚板)であった。つまり、アプリケーションは、一つのソースコードで1プロセスで動いているような感じだった。しかし、このモノリシックなアーキテクチャではソースコードが複雑で、変更が加えにくい等の問題があった。チームで開発する際も、メンバーみんなが同じソースコードをつかってビルドをする必要がある等、いろいろと面倒なことが多かったと思う。そこで、近年はアプリ開発にはマイクロサービスアーキテクチャが採用されている。マイクロサービスアーキテクチャは、小さなコンポーネントの集合が全体として一つのアプリケーションを構成しているようなアーキテクチャである。 自分も意図せずして、開発してきたアプリはマイクロアーキテクチャにしていたが、こちらの方が各コンポーネントの役割をきちんと明確化して進められるので、開発を分担できるのと、変更を加えるとき、役割がコンポーネントに分かれているので、各コンポーネントの中身だけを変えればよく、管理が簡単になると思われる。つまり、APIだけそろえておけば、後は中身はなんだっていいということだ。 これによって、アジャイル開発が非常に簡単になると思われる。 そして、このコンポーネントをひとつひとつをコンテナ化するってのも近年の大きな流れだ。コンテナ化することで、そのコンテナはCPUのアーキテクチャさえそろっていればどんなマシン上でも動くようになるからだ。そして、コンテナ化されたコンポーネント（マイクロサービス）をうまく協調させるのが コンテナオーケストレーションツールってはなしだ。 コンポーネントを協調させる、と書いたが、具体的には(k8sの機能は非常に多いので、俺が理解できる、かつ、大事そうなものだけをピックアップする)、 コンテナのスケジューリング スケーリング/オートスケーリング 障害時のセルフヒーリング ロードバランシング ワークロードの管理 とかがある。 k8sの基本的なコンポーネント 参考動画 基本用語説明 dbと連携させたjsアプリを題材に、k8sのコンポーネントを説明していくよ！ cluster k8sのリソースを管理する集合体のこと node 物理マシン、もしくは仮想マシンのこと。つまり、ホストのこと。 ノードには、master nodeと普通のnodeがある。 master nodeはkubernetesを管理するため、次の管理コンポーネントを持つ kube apiserver:kubernetesのAPIを公開する。kubectlからの操作を受け付ける役割。kubeletからもアクセスを受けるし、他にもいろいろなクライアントがある。これがclusterへのgatewayになる。ユーザは必ずkube apiserverを通してクラスターとやり取りをするということだね。 etcd:分散kvs。クラスタのバッキングストアとして使用される。ログとかが記録されている。etcdは分散kvs、ということはetcdを何個か立てることが可能、ということでして、そうするとetcd間で内容の一貫性を保たないといけないわけですね。ということは？お？層です。分散合意アルゴリズムのraftが使われているわけですね。最高です。 kube scheduler:コンテナを配置する最適なnodeを選択する。ここも研究の対象になりえるところではある。 kube controller manager: リソースを制御する k8sでソフトで実現される概念的なコンポーネント (下で紹介するが、これをリソースと呼ぶ。) Nodeはコンテナ化されたアプリケーションを実際に実行するホスト pod コンテナの集合体。PodはNodeの中で動作し、一つ以上のコンテナを持つ。 K8sにデプロイするときは、Pod単位で行う。(実際はdeployという単位でコンテナをデプロイするんです) pod一つでなにか機能を果たす、とかそういう感じでpodにまとめるのだと思われる。 そうだね、1 application per Podというのが基本らしい。 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を管理する。 ingress クラスタ外部からのエンドポイント？ ConfigMap Podsの設定ファイル ...

docker kubernetesの基本の基本 chapter 1,2 dockerはLinuxマシンを想定して作られている。cgroupがLinuxの概念だからね。 コンテナはイメージから作る コンテナはカーネルを持たない。が、カーネル以外のosの機能を持っている (本書ではそこを周辺部分と言っている)。カーネルはホストOSと共有する。だから軽い。 コンテナはdocker Engineがあればどこでも動く コンテナはイメージとして書き出すこともできる！ここがsingularityのsifとは違うところだね。おそらくDockerはデフォルトでsingularityのsandboxと同じように、中身の改変が可能なのではないか？と思っている。まだ確信には至っていない。 –> そのとおりです。dockerはどの時点においても動いているコンテナをイメージとして書き出すことができます。 そのときに使うコマンドが、commitです。 dockerでは物理的なマシンのディスクをマウントすることが可能。 コンテナの外部のディスクに書き込むことで、ほかのコンテナとデータを共有することができる。 dockerイメージはdocker hubからダウンロード可能 chapter3 dockerを使う dockerの環境構築方法が書いてあるだけでした。お疲れ様です。 chapter4 systemctl enable dockerでデーモンを自動起動させてください dockerコマンドの基本構文を抑えましょう docker <上位コマンド> <副コマンド> <オプション> <上位コマンド>　== 何を <副コマンド> == どうする っていうのが結構しっくりきました。 ...

ことはじめ 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を管理する。 ...