My Best Articles

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の設定ファイル ...

まえがき Go言語はhttpサーバに使われることがおおいー＞これは、現代のシステムがマイクロアーキテクチャに依存していることを示している。一つ一つのコンポーネントは単純な入出力に対応しているだけである。そのため、シンプルなgo言語が好まれるのだろう。 さらに、goの人気を上げているのが、並行処理の扱いやすさにある。 一般的な言語では、スレッドを立てて、スレッド間でなにか、スレッドセーフなコンテナを準備してやり取りをしないといけなかった。 しかし、goでは、goroutineとchannelを使って、スレッド間通信のようなものがかんたんにできるのがかなりいい。 以上の２つの要因によって、goではデータの流れがだいぶ見やすくなっていると思う。川上から川下へ流れていくがごとく、データの流れがとにかくつかみやすい。 goで特徴的なもう一つの機能は、インターフェースだろう。 これについては、後ほど説明する。 第一章 環境構築 https://go.dev/dl/から最新版をダウロード。tarで解凍。/usr/local/いかにgo/をおいて、そこにパスを通す。 echo 'export PATH=$PATH:/usr/local/go/bin' >> $HOME/.profile source .profile ここで疑問なのだが、どうやら、go/はホームディレクトリいかにもおいておかないとだめみたいなんだ。 というのも、ダウンロードしたモジュールやパッケージはホームディレクトリ以下のgo/に置かれるかららしい。 まあ、よくわからんよね。じゃあ、/usr/local/いかにおいたgoは何だったんだとね。 実行 go run hello.goでも実行できるし、 go buildで、コンパイルもできる。go自体はコンパイル言語。go runは直接実行しているように見えるが、内部的にはgo buildで一回ビルドしている。 ちなみに、go buildで出力される実行ファイルは.go前の部分。だから、hello.goをコンパイルすると、helloという実行ファイルが生成される。これを変えたい場合は、-oで実行ファイル名を変更することもできる。 モジュール まあ、c++やcの分割コンパイルみたいなことができるって話で、モジュールを作ってみましょう、ということ。 mkdir hello-world cd hello-world go mod init hello-world これで新たにgo.modというファイルが出来上がる。 go install goはgo installコマンドでgoのバイナリをインストールできる便利なコマンドである。 ためしに、heyという、httpサーバのロードテストを行えるツールをインストールしてみましょう。 go install github.com/rakyll/hey@latest デフォルトではホームの下の~/go/binにインストールされます。なので、ここにもパスを通す必要がありますね。 が、変えたかったら、$GOPATHを変えましょうって話ですね。まあ、変えることはあまりおすすめしませんが。 で、goで作ったファイルはこんな感じでかんたんに公開できるわけですね。 goのコードのフォーマット 無意味な宗教戦争を産まないために、かなりフォーマットに制限があるという話。こういうのは結構好き。例えば、 main(){ } と main () { } みたいな。goでは後者はコンパイルエラーになる。 開発ツールにgo fmtやgoimportsというものがあり、これはプログラマーが書いたソースをきれいにしてくれるフォーマッターである。 他にもstaticcheckという名のりんたーがある。 これは、まあ、コードを解析してくれるツールです。きれいなコードを生み出してくれるということで、ありがたい。 第二章 変数の定義について色々教えてくれています。これは実際に書いていくなかで勉強していくほうがいいのではないかと思っているのです。 ただ、変数の命名規則は結構勉強になった。 go言語ではスネークケースはあまり使わないと。これは俺が好んで使うやつだね。 comp_calcみたいな感じ。でもこれはあまり使われないらしい。で、キャメルケースのほうがいいって話。うん。たしかにそっちのほうが主流な気もしてきたな。 あと、goでいいなって思ったのは、定義した変数を全部使わないとコンパイルエラーが出るところ。これでいらない変数を全部排除できるって話です。 三章 配列、スライス 配列は、 ...

やりたいこと webアプリケーションを家のサーバで動かすとなるとセキュリティーの観点からして怖いじゃないですか。やっぱり自宅のipさらしたくないじゃないですか。 だからAWSなどのVPSを借りてそのうえでアプリを動かすんだと思います。 ただね、VPSでは二次記憶で使えるデータ量が決まっているんですね。しかもそのデータ量が結構限られています。例えば僕が契約しているサーバは二次記憶の容量が30GBです。つまり、大規模なデータベースを展開するには、大幅な課金が必要になるわけです。しかもさ、データベースを移植するのって結構面倒だからさ、一回構築したやつを長く使いたいんです。だからね、データベースだけは自宅においておき、アプリケーションが自宅のDBにデータをとりにきたり、おきに来たりすればいいのでは？と今思っているわけです。DBクライアントがデータを取ってくる時の通信量も考えるとどっちが安いかはまだわからないんですけどね。 じゃあ、自宅のルータをポート開放して、ポートフォワードすればいいんじゃねーの？って思うよね。でもね、データベース用のポートを開放しておくのもなんか怖いんですよ。ブルートフォースとか受けて、破られることもあるわけじゃないですか。ということで、vpnを介して自宅のネットワークにアクセスできるようにしておけばいいのではないか？というのが僕の考えです。 vpnクライアントのインストール sudo apt update sudo apt install openvpn vpnクライアント、設定ファイルのインポート config.ovpnをサーバに配置 sudo openvpn --config /path/to/my/ovpn/file パスワードを入力してトンネル完了 openvpnを介して自宅のmysqlサーバに接続 mysql -u ray -h 192.168.3.10 -p Enter password: Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 473 Server version: 8.0.33-0ubuntu0.20.04.2 (Ubuntu) Copyright (c) 2000, 2023, Oracle and/or its affiliates. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. mysql> いけてしまっている…これはマジで感動！！ネットワークはやはり面白い。仕組みとかはもっと勉強しないといけませんが。 いやー－－、実際これはすごいです。マジですごいですわ！！感動ですわ。 ...

やりたいこと webアプリケーションを家のサーバで動かすとなるとセキュリティーの観点からして怖いじゃないですか。やっぱり自宅のipさらしたくないじゃないですか。 だからAWSなどのVPSを借りてそのうえでアプリを動かすんだと思います。 ただね、VPSでは二次記憶で使えるデータ量が決まっているんですね。しかもそのデータ量が結構限られています。例えば僕が契約しているサーバは二次記憶の容量が30GBです。つまり、大規模なデータベースを展開するには、大幅な課金が必要になるわけです。しかもさ、データベースを移植するのって結構面倒だからさ、一回構築したやつを長く使いたいんです。だからね、データベースだけは自宅においておき、アプリケーションが自宅のDBにデータをとりにきたり、おきに来たりすればいいのでは？と今思っているわけです。DBクライアントがデータを取ってくる時の通信量も考えるとどっちが安いかはまだわからないんですけどね。 じゃあ、自宅のルータをポート開放して、ポートフォワードすればいいんじゃねーの？って思うよね。でもね、データベース用のポートを開放しておくのもなんか怖いんですよ。ブルートフォースとか受けて、破られることもあるわけじゃないですか。ということで、vpnを介して自宅のネットワークにアクセスできるようにしておけばいいのではないか？というのが僕の考えです。 vpnクライアントのインストール sudo apt update sudo apt install openvpn vpnクライアント、設定ファイルのインポート config.ovpnをサーバに配置 sudo openvpn --config /path/to/my/ovpn/file パスワードを入力してトンネル完了 openvpnを介して自宅のmysqlサーバに接続 mysql -u ray -h 192.168.3.10 -p Enter password: Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 473 Server version: 8.0.33-0ubuntu0.20.04.2 (Ubuntu) Copyright (c) 2000, 2023, Oracle and/or its affiliates. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. mysql> いけてしまっている…これはマジで感動！！ネットワークはやはり面白い。仕組みとかはもっと勉強しないといけませんが。 いやー－－、実際これはすごいです。マジですごいですわ！！感動ですわ。 ...

バックグラウンド実行のあれこれについて ジョブをバックグラウンドで実行する方法は、実行したいジョブ、もしくはコマンドの最後に&をつける。 ./job.sh& みたいな感じで。しかしこれだとsshセッションが切れるとバックグラウンドで走っていたジョブも死んでしまう。 なぜか？ まずは親子関係について説明しよう。bashの親はsshdで、ジョブはbashの子供として生成される。そして、通常は、「親が死んだらinit (systemd)が親になってくれる」しかし、sshの場合はsshのセッションが切れるとkernelからbashにSIGHUPが送られる。さらに、bashが各プロセスにSIGHUPを送る。 バックグラウンドで走っているジョブを殺すSIGHUPシグナルを無視するためのコマンドがnohupである。これを使うことでプロセスはSIGHUPを無視するようになる。これは、disown -hでも同じである。先に実行するか後で実行するかの違い。 tmux/screen tmuxとかscreenを使おうという話です。screenの話をします。 screenコマンドについて セッションの保存方法 # creationg new session screen # detach the session <ctrl> + <a> d # creating new session with a name screen -S <name> # list the sessions and check the status screen -ls 実験 screenで新しいセッションを作ってその中でsingularityを動かす。 ps axfの結果は以下の通り。 28987 ? S 0:00 sshd: foo@pts/1 28988 pts/1 Ss 0:00 \_ -bash 29057 pts/1 S+ 0:00 \_ screen -S singularity 29058 ? Ss 0:00 \_ SCREEN -S singularity 29059 pts/2 Ss 0:00 \_ /bin/bash 29104 pts/2 Sl 0:00 \_ Singularity runtime parent 29125 pts/2 S+ 0:00 \_ /bin/bash --norc 意図的にbashを切る。 ps xfでログインユーザに関係するプロセスを一覧表示すると一見死んだかに思える。しかし、 ...

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 <上位コマンド> <副コマンド> <オプション> <上位コマンド>　== 何を <副コマンド> == どうする っていうのが結構しっくりきました。 ...

まあ便利なこと。無料でSSL証明書が発行できるなんて！！ ということでね、Let’s encryptを使って期限が切れたSSL証明書を再発行していきたいと思います。 参考サイトは以下のとおりです。 ref step1 クライアントソフトのインストール sudo apt install certbot python3-certbot-nginx step2 443のポート開放 & ファイアウォールの設定 step3 SSL証明書の発行 sudo certbot certonly これでインタラクティブに設定できる。聞かれたことを書けばいいだけです。 Saving debug log to /var/log/letsencrypt/letsencrypt.log How would you like to authenticate with the ACME CA? - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1: Spin up a temporary webserver (standalone) 2: Place files in webroot directory (webroot) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2 Plugins selected: Authenticator webroot, Installer None Please enter in your domain name(s) (comma and/or space separated) (Enter 'c' to cancel): ingenboy.com Obtaining a new certificate IMPORTANT NOTES: - Congratulations! Your certificate and chain have been saved at: /etc/letsencrypt/live/ingenboy.com-0001/fullchain.pem Your key file has been saved at: /etc/letsencrypt/live/ingenboy.com-0001/privkey.pem Your cert will expire on 2023-08-22. To obtain a new or tweaked version of this certificate in the future, simply run certbot again. To non-interactively renew *all* of your certificates, run "certbot renew" - If you like Certbot, please consider supporting our work by: Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate Donating to EFF: https://eff.org/donate-le step4 nginx or apacheの設定を変更する。 nginxが証明書にアクセスできるようにパスをnginx.confに書き込むわけですね。はい、以上。 ...

一つの証明書を複数のクライアントで使い、同時接続を可能にする方法 基本的にクライアント証明書は一つのクライアントにつき一つ作るのがいいとされている。しかし、新しく作るのがめんどいときもある。iphoneとsurfaceに同じクライアント証明書が入っているのだが、この二つを同時接続しようとすると、先に接続されていた方が追い出される形になる。 openvpnのログを見てみるとこんな感じである。 Thu Apr 27 12:37:15 2023 MULTI: new connection by client 'hogehoge' will cause previous active sessions by this client to be dropped. Remember to use the --duplicate-cn option if you want multiple clients using the same certificate or username to concurrently connect. chatGPTさんに解決方法を聞きました。 Yes, you can add the '--duplicate-cn' option to your OpenVPN server configuration file. To do this, follow these steps: Open your OpenVPN server configuration file (usually named 'server.conf') using a text editor. Add the line 'duplicate-cn' to the file, without the quotes. Save the file and restart the OpenVPN server for the changes to take effect. Here's an example of what the relevant section of the configuration file might look like: # Allow multiple sessions per client username or certificate duplicate-cn 解決です。chatGPT先生すごすぎ！！ググレカス！！はいずれ死語になるのでしょうか？？？ ...

linuxを制すものはITを制す とはよく言ったものだ。 将来の夢はlinuxカーネルを理解することである自分ですが、まあ、そこへのかけ橋が必要ということで、「linuxの仕組み」を読むわけですね。裏表紙を見るだけで良本感が出ているこの本、さっそく読んでいきましょう ちなみに、筑波大学のこの人の授業もめっちゃためになります。 ref 1章：Linuxの概要 プログラムとは何か、プロセスとは何かを簡単に説明した後、カーネルの必要性について話しています。 これはかなり重要だけど、カーネルモードとユーザモードはcpuによって提供されている機能なんですね。カーネルモードで動いているプログラムは何の制限もないのに対して、ユーザモードで動いているプログラムには特定の命令を実行できなくする等、様々な制限がかかるんですね。 で、linuxの場合は、カーネルだけがカーネルモードで動作しています。つまり、プロセスはユーザモードで動いている、ということですね。だから、プロセスはカーネルを通じてデバイスにアクセスするのですが、この時にカーネルに操作をお願いする命令のことを「システムコール」というんですね。そうなんです、システムコールです。 カーネルの助けがないと実行できない処理をカーネルにお願いするんです。具体的には、nicを介した通信とかはそうですね。あとは、デバイスへのアクセス。プロセスの生成、削除。ファイルシステム操作。メモリ確保、解法。など。 システムコールが発行されると、cpuにおいて例外というイベントが発生するんですね。で、これをきっかけにcpuのモードがユーザモードからカーネルモードに遷移します。で、システムコールが終了すると再びユーザモードに戻ってプロセスが動くって感じですね。 で、straceコマンドってのがプログラムの中で発行されるシステムコール一覧を出してくれるんだよね。 strace python だけでもシステムコールがたくさん呼び出されることからも、pythonがインタープリタ言語であることがわかると思う。 前に研究室のサーバでwコマンドがハングしてしまう問題が起こったよね。そういう時は strace w とかってやると、wコマンド実行中のシステムコールがみられて、どこでハングしているのかとかがわかるわけですね。 こないだ調べた時は、特定のプロセスのプロセス情報 (/proc/<pid>/cmdlineとか) を閲覧しようとするとハングしてしまっていました。strace wとかするとreadシステムコールがハングするのがわかるはず。 ただ、なぜそうなってしまうのかはわかっていません…調べるとcgroupsによるメモリ制限と関係がありそうな情報が出てきましたが、まだ調査していません。 sudo yum install -y sysstat つぎのコマンドでsysstatを起動しましょう sudo systemctl start sysstat.service sarコマンドで遊びましょう。 sar -P 0 1 1 ちなみに、このコマンドの意味は、論理CPU0の(-P 0)のデータを1秒ごとに1回だけ収集しましょう。てこと。 sar -P 0 1 4 をやると次のような結果が出てくるよ。 Linux 5.15.32-v8+ (zeta) 09/02/23 _aarch64_ (4 CPU) 16:08:49 CPU %user %nice %system %iowait %steal %idle 16:08:50 0 0.00 0.00 0.00 0.00 0.00 100.00 16:08:51 0 0.00 0.00 0.00 0.00 0.00 100.00 16:08:52 0 0.00 0.00 0.00 0.00 0.00 100.00 16:08:53 0 0.00 0.00 0.00 0.00 0.00 100.00 Average: 0 0.00 0.00 0.00 0.00 0.00 100.00 この表の見方は、CPU 0がユーザモードで動作した時間の割合(%userと%nicdの和)、カーネルモードで動作した時間の割合(%system)、何もしていない時間の割合(%idle)って感じだね。 ...

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