Neco Weekly (2024-02-09号)
サイボウズ Neco チームでは、 Neco Weekly という「最近気になる Kubernetes や Cloud Native 関連のネタを共有する会」を社内で開催しています。
本記事は共有会の中で紹介したネタをまとめたものです。
今回は第49回目の記事となります。
👀 Notable Articles
人間によるKubernetesリソース最適化の”諦め” そこに見るリクガメの可能性
過去のリソースの使用量やレプリカの数を元に、HPAやResource Request/Limitを最適化し続けるツールだそうです。
我々もリソースの最適化に課題を感じており、このリクガメのアプローチは非常によさそうに思います。
安全な Kubernetes 環境を目指して
セキュリティ対策の原則や分類などの基礎的なところから、Kubernetesにおけるセキュリティ対策やツールの紹介まで非常に分かりやすくまとめられています。
End of an Era: Weaveworks Closes Shop Amid Cloud Native Turbulence
GitOpsを提唱したWeaveworksが会社を閉じるそうです。
Weaveworksの開発したFluxは、コミュニティで継続して開発されていくことになるようです。
Kubernetesクラスタの可観測性の隙間を埋めるeBPF
eBPFを利用して、Kubernetesクラスタ内からIngress Controllerに紐づいたNetwork Load Balancerに対して接続しているクライアントを検知する仕組みをコードベースで解説しています。
既存のexporterなどでカバーし切れない範囲の細かいメトリクスをeBPFを使って独自に取得する取り組みは非常に参考になります。(欲しいカーネルの情報をシュッと取れるようなるフットワークを得たい)
Rustで書かれているのも珍しく興味深いです。
Go言語でdata raceが起きるときに起きる（かもしれない）こと
データレースで発生する現象を実際のコードで解説している記事です。
並列処理に慣れていない人にとっては驚くような挙動だと思うので、コードを動かしながら試してみるのがおすすめです。
Istioによって抽象化されるEnvoyのHTTPSリクエスト処理の仕組み
IstioサイドカーメッシュがEnvoyのHTTPSリクエストの処理をどのように抽象化するのか、またEnvoyがどのようにHTTPSリクエストを処理するのかを解説している記事です。
Envoyのフィルターの仕組みやそれらがどのようにIstioにより抽象化されて機能しているのかが分かりやすく解説されていました。
🛠️ Tools, Frameworks, Libraries
controller-runtime v0.17.0
controller-runtime v0.17.0がリリースされました。今回は以下の変更が気になります。
- Webhooks: Deprecate admission.Validator and admission.Defaulter
- Admission Webhook の機能を提供する admission.Validator と admission.Defaulter が非推奨になります。
- これまでKubebuilderで Webhook のコード生成をしたときに利用されていいたものなので注意が必要です。
- Reconciler: Add reconcile.ObjectReconciler
- ジェネリクスを活用して、ReconcileでObjectを取ってくる定型的な処理を書かなくてよくなります。省略できるコードはたいした量ではないのですが、引数が型付けされるのが良いですね。
kubectl-guardrails
kubectlでリソースを削除するときにdry-runしてくれたり、削除の確認をしてくれるツール。
運用環境に入れておくとちょっと安心できそうですね。
🤝 Events
JANOG 53
2024年1月17日～19日に開催されたJANOGにおいて興味深かった発表の紹介です。
大規模ネットワークにおける障害可視化のためのアーキテクチャ
フレッツ光などのネットワークの運用保守をしている会社の発表です。
運用しているネットワークのトポロジーを自動で描画して、障害時に自動でpingなどのパケットを送出して問題が発生している箇所を特定しているそうです。
トポロジーが複雑になると、実際に障害が発生しているノードを見つけるのが手間になってくるので自動で、かつ視覚的にわかるようになっているのは便利ですね。
データセンターネットワークの輻輳対策どうしてる？
LINE ヤフーの DC で輻輳対策の検証を実施した話です。
この発表ではTCPベースの多少パケットロスが許容されるネットワークに対してどのように輻輳制御を行うか検証しています。
輻輳への対策として主に以下のようなものがあるそうです。
- Deep buffer な switch を導入する
- 専用ネットワーク
- 輻輳制御機能のチューニング
この発表の検証では実際にHadoop基盤上で輻輳を発生させて、これらの対策の組み合わせでどの程度輻輳を軽減できたかを比較し比較しています。輻輳防止とレイテンシのトレードオフなど、それぞれの手法によって一長一短あり非常に興味深かったです。
我々のデータセンターでも輻輳制御やQoS制御など、しっかり考えていかなければならない時期に来ているので非常に参考になりました。
Discussion