🐑

Neco Weekly (2022-09-16号)

zoetro2022/09/20に公開

Neco Weekly (2022-09-16号)

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

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

✨ News

MOCO v0.13.0

https://github.com/cybozu-go/moco/releases/tag/v0.13.0

Neco チームが開発している MySQL オペレータ MOCO の新しいバージョン v0.13.0 をリリースしました。
今回の目玉は以下の機能です。

MOCO では以下のような MySQLCluster リソースを記述して MySQL クラスタを構築することができます。
このとき volumeClaimTemplatesspec.resources.requests.storage により、MySQL が利用するボリュームのサイズを指定することができます。

apiVersion: moco.cybozu.com/v1beta2
kind: MySQLCluster
metadata:
  namespace: foo
  name: default
spec:
  mysqlConfigMapName: mycnf
  podTemplate:
    spec:
      containers:
      - name: mysqld
        image: quay.io/cybozu/mysql:8.0.28
  volumeClaimTemplates:
  - metadata:
      name: mysql-data
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 1Gi

しかし、これまでの MOCO ではクラスタ構築後に volumeClaimTemplates を書き換えても PersistentVolumeClaim リソースが更新されず、ボリュームのサイズを簡単には変更することはできませんでした。

これは MOCO の問題というよりも、以下のブログでも言及されているように Kubernetes の StatefulSet の仕様となります。

KEP-0661 において StatefulSet でボリュームのリサイズを可能にするための検討が進められていますが、この KEP の実装を待っていたのでは非常に時間がかかってしまいます。

そこで MOCO v0.13.0 では、volumeClaimTemplates を書き換えると PersistentVolumeClaim リソースを更新し、Pod は残したまま StatefulSet リソースのみを更新するようにしました。
これにより簡単にボリュームのリサイズができるようになっています。

より便利になった MOCO をぜひ一度お試しください。

coil v2.1.2

https://github.com/cybozu-go/coil/releases/tag/v2.1.2

Neco チームが開発している CNI プラグインである coil の新しいバージョン v2.1.2 をリリースしました。

coil v2.1.2 では以下の不具合の修正をおこなっています。

coil はオプトイン方式で外部ネットワークへの NAT 接続をおこなうための Egress NAT という機能を提供しています。
詳しく知りたい方は以下の記事をご覧ください。

今回のリリースでは、 Egress NAT の接続がまれに切れてしまうという問題を修正しました。

Kubernetes では Job として実行した Pod は、処理が完了した後も Pod リソースが残り続けるようになっています(JobsHistoryLimitの設定による)。
これまでの coil では、新しく生成された Pod に処理が完了した Job の Pod と同じ IP アドレスを割り当てることがありました。
その後 Job の Pod が削除された際に、coil はその Pod が持っていた IP アドレスに対して Egress NAT のトンネル接続から解除してしまうため、新しく生成された Pod が外部ネットワークと通信ができなくなるという問題が起きていました。
なかなか原因の解明が難しい不具合でした。

👀 Notable PRs

[client-go] add function to upgrade managedfields CSA to SSA

https://github.com/kubernetes/kubernetes/pull/111967

Kubernetes のカスタムコントローラーなどで、リソースの適用方式を Client-Side Apply 方式から Server-Side Apply 方式に切り替えると、 Client-Side Apply 方式で適用した際の managedFields が残り続けるという問題があります。
これにより、本来は削除したはずのフィールドが削除されずに残ってしまう場合があります。
詳しくは下記のスライドが参考になります。

表題の PR では、Client-Side Apply で適用した際の managedFields を Server-Side Apply 用の managedFields に書き換えてくれる関数が提供されています。

自作のカスタムコントローラーを Client-Side Apply 方式から Server-Side Apply 方式に切り替える際に役立ちそうですね。

support removal of event handlers from SharedIndexInformers

https://github.com/kubernetes/kubernetes/pull/111122

Kubernetes の client-go には、特定の種類のリソースをキャッシュしておき、その種類のリソースを watch して変化が生じたときにキャッシュを更新してくれる Informer という仕組みがあります。
Kubernetes のコントローラーはこの仕組みを利用することで、リソースを取得するたびに API Server に問い合わせる必要がなくなり、効率的な実装を実現することができます。

これまでの client-go では、一度 watch した種類のリソースを watch の対象から外すことはできませんでした。
そのため、watch 対象のリソースが動的に変化するようなコントローラーでは、不要になったキャッシュがメモリ上に残り続けることになってしまいます。
(watch 対象のリソースが動的に変化するようなコントローラーというのはかなり特殊なユースケースではありますが…)

この PR では、watch しているリソースを watch から外すことができるようになりました。

なお、client-go を直接利用するのではなく controller-runtime を利用している場合は、以下の PR の対応を待つ必要がありそうです。

👀 Notable Articles

The Protobuf Language Specification

https://buf.build/blog/protobuf-language-specification

2022-07-22号 で Connect という新しい gRPC 実装を紹介しましたが、Connect を開発している Buf 社が protoc の実装から protobuf の正しい仕様書を書き起こしてくれたという記事です。

実装だけでなく仕様書もしっかりと整備してくれるというのはありがたいですね。

Announcing the Auto-refreshing Official Kubernetes CVE Feed

https://kubernetes.io/blog/2022/09/12/k8s-cve-feed-alpha/

Kubernetes の CVE を配信する Feed が提供されたという記事です。

この Feed は CVE が発表されてから数分から数時間で更新されるようです。
セキュリティの問題にすばやく気づけるようになるのでとてもありがたいですね。

なお、この CVE Feed を作成した経緯については PuDiJoglekarさんのTweet にまとまっています。
Google Groups が RSS の提供をやめたことがきっかけだそうです。

kubernetes-controller-sharding

https://twitter.com/everpeace/status/1570403134698319876

Kubernetes のカスタムコントローラーをスケールアウトさせるために、シャーディングして複数のコントローラーで Reconcile 処理をできるようにする仕組みを実験的に開発しているそうです。
非常に興味深い取り組みです。

Neco チームではまだ 1 つのコントローラーで Reconcile 処理が間に合わなくて困ったというケースには遭遇していないのですが、どれくらいの規模のリソースを扱うときにこういった仕組みが必要になってくるのか気になるところです。

あとがき

今回 MOCO v0.13.0 について取り上げましたが、このリリースでは紹介した新機能の他にも社外の方からの PR をいくつか取り込んでいます。
最近は MOCO の利用ユーザーが増えているようで、盛り上がりを感じますね。

サイボウズ Necoチーム 😺

サイボウズ株式会社 運用本部 サービス運用部 Neco チームです。 Kubernetes を主要な部品として、自社クラウドサービス cybozu.com を運用するためのデータセンター管理基盤の開発および運用をおこなっています。

Discussion

ログインするとコメントできます