Posts

CronJobは、指定したcronフォーマットに基づいて定期的にJobを実行するという機能です。 主にバックアップの取得やメール送信など、定期的な処理を実行する際に便利です。 一方で、CronJobが失敗した際にどのように検知すべきかについては、あまり情報がありませんでした。 なので、今回はそちらについて考えてみたいと思います。 kube-state-metricsを活用する kube-state-metricsとはKubernetesクラスタ内のリソースの状態をメトリクスとして提供してくれるというものです。 kube-state-metricsではCronJobやJobの状態をメトリクスとして取得することができます。 この方式採用している記事が多かったので、こちらで検討を進めてみたいと思います。 ※記事 https://medium.com/@tristan_96324/prometheus-k8s-cronjob-alerts-94bee7b90511 https://www.giffgaff.io/tech/monitoring-kubernetes-jobs どのメトリクスを使い監視するか CronJobはcronフォーマットで指定された時刻にJobを生成し、そのJobがPodを生成するという3層の親子構造になっています。 また、CronJobとJobの関係は1対多で、JobとPodの関係は1対多になります。 Jobが完了するのはcompletions個のPodが正常終了した場合、もしくはbackoffLimit個のPodが異常終了した場合に限ります。 completions completions個のPodが成功すると、Jobが完了したとみなされる デフォルトは1 backoffLimit 失敗したと判断するまでの再試行回数で、この回数を超えるとJobは失敗とみなされる デフォルトは6 そして、アラートを上げたいのはJobが失敗した時です。言い換えると、backoffLimit個のPodが異常終了したときにアラートを上げるということになります。 何個のPodが異常終了したのか監視することも可能だと思いますが、ここではJobのステータスを監視するのが適切かと思います。 メトリクス 対応する項目 説明 kube_job_status_succeeded .status.succeeded Jobの管理下で正常終了したPodの数 kube_job_status_failed .status.failed Jobの管理下で異常終了したPodの数 kube_job_complete .status.conditions.type Jobが成功したかどうか kube_job_failed .status.conditions.type Jobが失敗したかどうか 参考: https://github.com/kubernetes/kube-state-metrics/blob/main/docs/job-metrics.md Jobに関するメトリクスは複数ありますが、この中でも特にkube_job_failedを使ってアラートを上げるのが良さそうです。 以下の設定だと、Jobが失敗したときにアラートが上がります。 kube_job_failed > 0 アラートが発火し続けてしまう問題 失敗したJobは削除されずに残り続けるので、アラートが発火し続けてしまいます。 なので、JobのttlSecondsAfterFinishedを設定し、数分後にJobが削除されるようにします。 ttlSecondsAfterFinished 指定秒後にJobを削除できる CronJobのfailedJobsHistoryLimitを設定するという方法も思いつきましたが、0にしてしまうとそもそもアラートが上がらないと思うので、こちらは1のままにしておきました。 failedJobsHistoryLimit 失敗したJobを指定個数分残しておける デフォルトは1 まとめ 今回はkube-state-metricsを活用して、CronJobが失敗した時のアラートを設定しました。他にもっといい方法をご存知の方は教えていただけるとありがたいです。

Linuxでの公開鍵認証の設定をよく忘れてしまうので、備忘録としてメモを残しておきます。 接続元での設定 接続元で鍵を生成し、公開鍵を接続先のサーバーへコピーします。 ssh-keygen scp ~/id_rsa.pub username@server:~/ 接続先の設定 接続先のサーバーで公開鍵の情報をauthorized_keysに登録し、適切な権限を設定します。 mkdir ~/.ssh chmod 700 ~/.ssh cat id_rsa.pub >> ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys 公開鍵認証を有効化し、パスワード認証を無効化します。 sudo vi /etc/ssh/sshd_config --- PubkeyAuthentication yes PasswordAuthentication no sshdを再起動します。 systemctl restart sshd

k8s構築ツールはいろいろありますが、公式ドキュメントでは以下が紹介されています。 学習環境 Minikube Kind プロダクション環境 kubeadm kops kubespray ※各ツールの違いについてはこちら 今回はその中でもkubesprayというツールを使ってk8sクラスタを構築してみようと思います。kubeadmは1台ずつインストールを実施するのに対し、kubesprayはAnsibleを使い、各ノードで一斉にインストールを実施します。なので、kubesprayは台数が多いときに便利です。 ちなみに、kubesprayは内部でkubeadmを使っているので、kubespray = kubeadm + Ansibleという感じです。また、kubesprayを使うと、コンテナランタイム(デフォルトはcontainerd)やPod間通信のネットワークプラグイン(デフォルトはcalico)などが自動でインストールされるので、非常に便利です。 構築 前提: ベアメタル(Intel NUC11PAHi5)上に構築 Control Planex1台とWorkerx3台の4台構成 OSはRocky Linux9.1 ルーター側の設定で固定IPを割り当て 各ノードのスペックは以下 CPU メモリ ストレージ 4コア 16GB 500GB ssh公開認証の設定 手元のPCからパスワードなしでssh接続できるように公開鍵認証の設定をします。 ssh-keygenのパスワードには空文字を指定します。 kkato@bastion:~$ ssh-keygen kkato@bastion:~$ scp ~/.ssh/id_rsa.pub 192.168.10.xxx:~/ 公開鍵の情報を各ノードのauthorized_keysに追記します。 kkato@nuc01:~$ mkdir ~/.ssh kkato@nuc01:~$ chmod 700 /.ssh kkato@nuc01:~$ cat id_rsa.pub >> ~/.ssh/authorized_keys kkato@nuc01:~$ chmod 600 ~/.ssh/authorized_keys /etc/hostsの編集 手元のPCから各ノードへホスト名で接続できるように、/etc/hostsを編集します。 kkato@bastion:~$ cat /etc/hosts --- 192.168.10.121 nuc01 192.168.10.122 nuc02 192.168.10.123 nuc03 192.168.10.124 nuc04 ユーザーの設定 各ノードのユーザーがパスワードなしでsudo実行できるよう設定します。...

最近ラズパイを手に入れたので、kubeadmを使ってk8sクラスタを組んでみたいと思います。 Control Planeノードx1 Workerノードx3の構成です。 準備 準備したものは以下のとおりです。 アイテム 個数 Raspberry Pi 4 Model B / 4GB 4 Raspberry Pi PoE+ HAT 4 ケース 1 microSD 64GB 4 スイッチングハブ 1 LANケーブル 0.15m 4 LANケーブル 1m 1 SDカードリーダー 1 HDMI変換アダプター 1 PoE(Power over Ethernet)+ HATを使うと、LANケーブルから電源供給できるのでとても便利です。今回はPoE+ HATを使っているので、スイッチングハブもPoE対応のものを購入しています。ラズパイのOSをSDカードにインストールする必要があるので、SDカードリーダーも購入しました。あとは、ディスプレイと繋ぐときにmicro HDMIに変換するためのアダプタも購入しました。 OSの設定 OSのインストール 手元のPCはUbuntu 22.04 LTSなので、以下のコマンドでRaspberry Pi Imagerをインストールします。 $ sudo apt install rpi-imager そして、microSDカード4枚全てにUbuntu Server 22.10 (64-bit)を焼きます。 $ rpi-imager microSDカードを差し込み、ディスプレイ(micro HDMI)とキーボード(USB)を接続し、OSの初期設定を行います。初期ユーザー名とパスワードはubuntuです。パッケージを最新にしておきます。 $ sudo spy update $ sudo apt upgrade -y 新しくユーザを作成し、ユーザにsudo権限を付与します。sudoをパスワードなしでできるように追加の設定もします。...

2020年8月にジョージア工科大学 コンピューターサイエンス修士課程(通称OMSCS)に入学し、2022年12月に卒業しました。今回は入学から卒業までを振り返ってみようと思います。 なぜOMSCSを始めたのか 実は途中でOMSAからOMSCSに編入していたりしますが、OMSCSを始めた主な目的は以下です。 専門的な知識を身につける 私は物理学の学士課程を卒業していますが、物理を学ぶと選択肢は広がるものの少し中途半端なんですよね。例えば、機械系に行きたいとすると機械工学の学生でいいじゃん、電子系に行きたいとすると電子工学の学生でいいじゃん、IT系に行きたいとすると情報系の学生でいいじゃん、となってしまいます。なので、物理学＋αでより専門的な知識を身につけて、今後のキャリアアップに役立てたいと考えました。 海外で就職する 実は私はカナダの大学で学士号を取得していますが、卒業当時の私は現地就職するだけの自信と実力がありませんでした。国際的に評価されている大学の修士号であれば、海外で就職するときもプラスに働くと思い、OMSCSを始めることにしました。 実際どうだったか 正直かなり大変でした。コロナで家にいる時間も多かったですが、平日の仕事終わりと週末は基本的に家でずっと勉強していました。遊びに誘われることもありましたが、毎回断っていたら誰からも誘われなくなりました笑 どれくらいの時間が必要かというと、前提知識があるかどうかにもよると思いますが、1コースにつき週10-20時間は必要だと思います。ちなみに私は基本的に1学期に2コース取っていたので、休む時間がほとんどありませんでした。 また、卒業には以下の条件があり、良い成績をとらないと卒業できないというプレッシャーがありました。 最初の12ヶ月でfundamental courseを最低2つ履修し、B以上の成績を収めなければならない 専門分野のコースは全てB以上の成績を収めなければならない 合計GPAが3.0/4.0以上でなければならない どんな授業を受けたのか OMSCSではSpecialization*1といって専門分野を決める必要があるのですが、私はComputing Systemsにしました。その理由としては配属された部署がデータベースや分散システムなどのミドルウェアを扱うところだったから、また低レイヤーの技術に興味があったからです。OMSCSでは10コース履修する必要がありますが、そのうち5, 6コースを自分の専門分野から履修しなければなりません(いわゆる必修科目)。 学期 受講したコース 難易度 作業量 Fall 2020 CSE6040 Computing for Data Anlysis 易しい 10時間/週 Fall 2020 ISYE6501 Introduction to Analytics Modeling 普通 15時間/週 Summer 2021 CS6300 Software Development Process 普通 10時間/週 Fall 2021 CS6250 Computer Networks 普通 10時間/週 Fall 2021 CS7646 Machine Learning for Trading 普通 15時間/週 Spring 2022 CS6035 Introduction to Information Security 普通 15時間/週 Spring 2022 CS6200 Introduction to Operating Systems 難しい 20時間/週 Summer 2022 CS6262 Network Security 普通 15時間/週 Fall 2022 CS6515 Introduction to Graduate Algorithms 難しい 15時間/週 Fall 2022 CS9903-O13 Quantum Computing 易しい 10時間/週 受講したコースについて少し紹介しようと思います。2023年現在、OMSCSでは61コース提供されており*2、定期的に追加・更新されます。また、OMSCSにはOMSCentral*3という非公式のレビューサイトがあるので、そちらも参考にしてみてください。...