What's this

仕事で K8s cluster の信頼性を担保することが責務となった。

Scopes

Cluster
Node

とりあえずまかせた！という感じで厳密なところはここから交渉していかないといけない。
諸事情で control plane は考えなくてよさそう。

とりあえず今考えていること

守りたいこと
- Pod を作れること
- Cluster 内外のネットワークで疎通が取れる

Node

リソースが必要なだけ確保されている(閾値むずい)
pending になっている pod の数も見るか...
ネットワークの疎通は外向けに ping をすでに飛ばしているのでそれで別途担保しているから考えるのやめる

mocchi

Node Problem Detector なるものがあるのか。

Node Problem Detectorは、ファイルベースのカーネルログのみをサポートします。 journaldのようなログツールはサポートされていません。

Node Problem Detectorは、カーネルの問題を報告するためにカーネルログフォーマットを使用します。カーネルログフォーマットを拡張する方法については、Add support for another log format を参照してください。

私の環境ではこの制限事項にあたり使えなさそう。

なのと書き忘れた諸事情を追記すると、
K8s as a Service を利用しているので、Node の正常性は別途運用されているのでこのツールは使わなくてもよさそう。

mocchi

Nodes ready とか頭から抜け落ちていたけどほしいな

mocchi

container / pod が再起動を繰り返しているのは検知したい。

mocchi

New Relic になれていないからかとてもしんどい。
割り当て可能な CPU Cores 数を計測したく、独自に labeling した node_az 単位で見たいのにみれない。

FROM K8sNodeSample SELECT sum(allocatableCpuCores) - sum(cpuRequestedCores) FACET `label.node_az` WHERE clusterName = {{cluster_name}}

- sum(cpuRequestedCores) を除いた query の期待値が仮に 12 のところを 96 となる。

mocchi

そもそも理解がとても浅いと思うので Kubernetes in Action を読む。
Part 3, Part 4 を読めば知りたいことがわかりそうな気がしている。

と思ったが未完だった。

mocchi

Kubernetes in Action の 1st edition を読む。
Part 3. Beyond the basics から何か得れる気がする。

mocchi

kubelet/kube-proxy あたりを監視するべきなのか考え、現状も把握しなくては

mocchi

add-on components とか正常性も確認するべきなのかな