Nodeのマシンタイプをケチって覚えたdebugging kubernetes - 百日半狂乱
GKE上に立ち上げている自前のkubernetesのClusterは、一番安いという理由だけでg1-small*1を使い続けていた。しかし、いざ複数のPodを追加したりし始めると、Nodeのリソース不足が原因で色々ハマったので、そこで覚えた細かいデバッグ手法を例のごとく逆引き辞書っぽくメモしていく。ついでにリソースとは無関係なkubernetesのネットワーク関連でハマったこともメモ。すでに使い込んでいる人にとって目新しいものはない気がする。 以下、例となっているPodのデプロイは、状況を再現しやすいという理由だけで手前味噌のprometheus実験レポジトリを元に行っているのでprometheusが云々と多少言っているが、基本的にPodの内容がなんであれ、リソースが足りなくなった場合に何が起こって、kubectlで何を確かめれば良さそうか、という点を中心に書き下していく。 Check k
世にも恐ろしいSIGPIPE、ソケットプログラミングの落とし穴 - 百日半狂乱
前回、「次回もシグナルのことを書く」と書いたのでシグナルのことを書く*1. ソケットプログラミングの落とし穴は色々あるけど、ここでは個人的に嵌ったシグナル関連の落とし穴に関して書き殴る． 結論から書くと、コネクションが切れたソケットに書き込み(send(2)とかwrite(2)とか、同じものだけど)を行うと、SIGPIPEシグナルが発生してプロセスが強制終了するので、きちんとSIGPIPEシグナルをハンドリングしておこうという話． 以下では、サンプルコードを使って、実際にパイプの書き込み先をkillして、SIGPIPEの発生を疑似体験してみる． SISGPIPEを受けたプロセスの挙動とソケットプログラミングでの対応策 「sigpipe」で検索すると、同様の話はいくらでも記事になっていて、例えば、 「私の書いたサーバが突然死するんです。どうしてでしょうか」という質問を受けることがあります。こ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
