🐈

NetworkPolicyの抽象化やFail-Slowの検出システムの紹介記事など: Neco Weekly (2023-04-28号)

2023/05/01に公開

Neco Weekly (2023-04-28号)

サイボウズ Neco チームでは、 Neco Weekly という「最近気になる Kubernetes や Cloud Native 関連のネタを共有する会」を社内で開催しています。
本記事は共有会の中で紹介したネタをまとめたものです。

今回は第30回目の記事となります。

👀 Notable Articles

Network policies are not the right abstraction (for developers)

https://otterize.com/blog/network-policies-are-not-the-right-abstraction

NetworkPolicyは正しく抽象化できていないんじゃないかと主張している記事です。
NetworkPolicyは送信先のサーバーと一緒にデプロイするのが一般的だが、アクセス元のクライアントが増えるたびにNetworkPolicyを変更するのはいろいろと問題があると言っています。
そこでOtterize intents operatorを開発し、クライアントと一緒にClientIntentsというカスタムリソースをデプロイすることでNetworkPolicyを自動更新しているそうです。

一方で、クライアント側で自由にNetworkPolicyを設定できてしまうとその正しさを担保することができません。
そこで以下の記事では、サービスの呼び出し関係を抽出するツールをCIで実行し、自動的にルールを作成し、クライアントの変更に応じてサーバー側のメンバーがレビューするような仕組みを作成しているそうです。

https://monzo.com/blog/we-built-network-isolation-for-1-500-services

ちなみにNecoチームでは、Tenetというカスタムコントローラーを開発して、マルチテナント環境でのNetworkPolicyを管理しています。

Perseus: A Fail-Slow Detection Framework for Cloud Storage Systems

https://www.micahlerner.com/2023/04/16/perseus-a-fail-slow-detection-framework-for-cloud-storage-systems.html

ストレージクラスタのFail-Slowノードを検出するシステムについての論文紹介記事です。
Fail-Slowというのは、ディスクへの書き込みやメモリアクセス、NICのアクセスなど、ハードウェアのスピードが遅くなっていることをさしています。
この論文では、ストレージのアクセスが遅くなっているノードを取り除くことで、全体のレイテンシが向上したそうです。

以下の解説メモも参考になります。
https://scrapbox.io/Nodewww/Fail-Slow_at_Scale:_Evidence_of_Hardware_Performance_Faults_in_Large_Production_Systems

Kubernetes Vault integration via Sidecar Agent Injector vs. Vault Secrets Operator vs. CSI provider

https://www.hashicorp.com/blog/kubernetes-vault-integration-via-sidecar-agent-injector-vs-csi-provider

VaultをKubernetesのSecret管理で利用する方法として、新しく登場したVault Secrets Operatorと、既存のSidecar Agent InjectorやCSI Providerを比較している記事です。

How to troubleshoot memory leaks in Go with Grafana Pyroscope

https://grafana.com/blog/2023/04/19/how-to-troubleshoot-memory-leaks-in-go-with-grafana-pyroscope/

Grafana Pyroscopeを使ってメモリリークを検出する方法を解説している記事です。
Pyroscopeには、pprofを使ってpull方式でプロファイルを集める方法と、専用のクライアントを使ってpush方式で集める方法があるみたいですね。

Kubernetes の Probe の仕組みと考慮点

https://zenn.dev/toversus/articles/5d1292160f5035

KubernetesのProbeを利用する際の注意点を紹介している記事です。
Probeって深く考えずに雑に設定してしまうこともあるので、こういう情報はとても助かりますね。

Annotations in Kubernetes Operator Design

https://sklar.rocks/kubernetes-operators-annotations/

カスタムリソースがSecretリソースを参照している場合、そのSecretリソースをwatchしてそこから参照元のカスタムリソースを見つけるのは大変なので、Secretリソースのアノテーションにカスタムリソースの名前を指定する方法を紹介している記事です。

いろいろなオペレーターの実装を見ていると、このあたりはオペレーターごとに実現方法がまちまちですね。
個人的な意見としては、Annotationsを利用するよりも、前者の方法でFieldIndexerを利用するのが好みです。

Don't write clean code, write CRISP code

https://bitfieldconsulting.com/golang/crisp-code

Cleanなコードって言っても指標がよく分からないので、Correct, Readable, Idiomatic, Simple, Performantなコードを書こうと主張している記事です。

記事の内容には概ね同意ですが、Simpleに関してはやや納得感が薄かったです。
個人的には、以下の記事で述べられている「状態 > 結合 > 複雑性 > コード量の順でコードを最適化しよう」というガイドラインの方がしっくりきますね。

https://ohbarye.hatenablog.jp/entry/2022/01/31/state-coupling-complexity-code

🛠️ Tools, Frameworks, Libraries

Kubebuilder v3.10.0

https://github.com/kubernetes-sigs/kubebuilder/releases/tag/v3.10.0

go/v3プラグインがdeprecatedになり、go/v4プラグインがstableとなりました。
これにより、Kubebuilderで生成されるコードのディレクトリ構造が大きく変わっています。

つくって学ぶKubebuilderも対応する予定です。

krr: Prometheus-based Kubernetes Resource Recommendations

https://github.com/robusta-dev/krr

Prometheusが提供するメトリクスをもとに、Podの適切なリソース量をレコメンドしてくれるツールです。

KubernetesのVPA RecommenderGoldilocksでも同じことはできますが、krrはクラスタにインストールする必要がなかったり、CLIのレポートツールが提供されていることが違いとしてあるようです。

🤝 Events

エーピーコミュニケーションズさんのKubeCon速報

https://techblog.ap-com.co.jp/archive/category/KubeCon

エーピーコミュニケーションズさんのブログでKubeCon + CloudNativeCon Europe 2023の速報が投稿されていました。
KubeConはセッションの並列数が多くて全部は見きれないので、こういう取り組みは非常にありがたいですね!

サイボウズ Necoチーム 😺

Discussion