もともとCinnamonが好きでManjaroもCinnamonを使っていたんだけど，タイル型のウィンドウマネージャーを使いたくなったので，i3を入れてみた．
最終的な見た目
今回使った設定は全部ここに詰め込んだ．
続きを読む自分のためだけにcustom controllerを書く
ふだんkopsで自分用のKubernetesクラスタを立ち上げているんだけど，個人用途なのでAutoScaleはしてほしくないのでClusterAutoscalerは入れていない．だけど，その状態でも可用性はできる限り下げたくない． というわけで，ちょっと自分でノードを管理するカスタムコントローラを書いた．
こういう，あんまり需要がないけど自分のところだけでいろいろカスタマイズしたいときに，適当なコントローラを自作すると手動作業が減らせるので大変良い．
個人用クラスタについて
kopsを使ってAWS上に構築している．複数台構成で
- control-plane * 3
- node * 3
くらいで運用している．nodeの数は乗せるものによって増やしたり減らしたり．
ちなみに全部SpotInstanceで運用している． Spotだと不意にTerminateされることが多いんだけど，大抵の場合はすぐに次のインスタンスが上がってきて，事なきを得る． たまに特定のFlavorの値段が高騰したりすると，新しいインスタンスをe立ち上げられなくなるんだけど，これに関してはAutoScalingGroupのLaunchTemplateとMixedInstancePolicyの組み合わせを使うことで，複数のFlavorを利用するとこができる． 例えば，t3.largeの値段が高騰したとしても，MixedInstancePolicyで
- t3.large
- c5.large
- m5.large
とか入れていれば，この3つの中で安いSpotInstanceを探してきて立ち上げてくれる． たしかにSpotPriceはたまに高騰するんだけど，複数Flavorを用意しておけばそれらがすべて高騰することはあまりない．
実現したいこと
ノードの可用性を下げたくないが，不要なインスタンスは消したい
kopsで作成している時点で，基本的にAutoScalingGroupでインスタンスを立ち上げている．そのため特定のnodeが突然ししたとしても，新しいnodeは自動的に補充される．
ただし，特定のAvailabilityZoneのSpotが足らなくなったり，価格が高騰したりした場合，そのAZのインスタンスは起動できなくなる． 特に最近のkopsはAZごとにAutoScalingGroupを作成している．
- masters.ap-northeast-1a.hogehoge
- masters.ap-northeast-1c.hogehoge
- masters.ap-northeast-1d.hogehoge
- nodes.ap-northeast-1a.hogehoge
- nodes.ap-northeast-1c.hogehoge
- nodes.ap-northeast-1d.hogehoge
こうなっていると，特定のASGだけひたすらインスタンスが起動できないような状態に陥ることがある．
このときに，可用性を下げたくないので，生きているASGで代替のインスタンスを一時的に起動しておいてほしい．
という要望はありつつ，不要なインスタンスまで起動していてほしくない．なので，例えば上記のトラブルが解消されたら元のインスンタンスに戻してほしいのである．
一定期間でノードをリフレッシュしたい
かつて，kopsのAutoScalingGroupでSpotInstanceを使うときに，LaunchTemplateではなくLaunchConfigurationしか使えない時代があった．このときにSpotInstanceを立ち上げると，Spotの期限がデフォルトの7dayになってしまっていた． これは編集不可能で，仕方なく7日おきにインスタンスを殺すようなLambdaを書いていた．
ただ，このタイミングでどうしてもインスタンスが死ぬと障害になってしまうので，Lambdaではなく内部のコントローラでこれを行いたかった．
最近のkopsはLaunchTemplateが使えて，Spotの期限も無期限にできるので，特にこのような問題はない． ただ，上記のようなことをやっていたため，どうしてもあまり長くインスタンスを生かしておきたくなかった．というわけで，週に一度くらいはnodeのローリングアップデートをしたかった．
これらを一つのcontroller-managerで実現したい
少し考えてみて，これらを一つのcontroller-managerで実現したほうがよいと思った．というのも，不要なインスタンスを消す機能と，ローリングアップデートを同時に動かすのは結構難しい．ローリングアップデート時にインスタンスを突然殺す分には特に問題ない．ただ，それをやるとnode数がたらなくなり，配置できないPodが生じる可能性はある．そのため，予備のnodeを予め起動しておいてから，古いnodeのローリングアップデートをしたい．それをやろうと思うと，予備のnodeが不要なnodeと判定されないためにも，これらの動作を排他的に制御できるのが望ましく，そのために同じcontroller-managerで実現するほうが楽だと判断した．
やることが複数なので，複数CRDで複数controllerという構成になるものを，controller-managerで束ねるという形にしたいと思う．
できたもの
まだだいぶ荒削りだがとりあえず動くものはできた．
今回はcontroller-runtimeを使ってしまっている．controllerとしてそこまで複雑なことをするわけではないので．
全体的な構成
node-manager
├── aws-node-manager-master
│ ├── replenisher-master
│ └── refresher-master
└── aws-node-manager-worker
├── replenisher-worker
└── refresher-worker
aws-node-managerがやること
現在のKubernetesのnodeを取得してきて，これがAWS上のどのAutoScalingGroupに属しているのか，instanceIDが何なのか，ということを埋めている．これをCRDのStatusに埋めることで，下位のcontrollerがこれらの情報を利用する．
また，CustomResourceの定義に応じてmaster, nodeのrefresherとreplenisherのCRを作成する．
refresherがやること
CRに指定されたスケジュールに応じて以下のようなステップでローリングアップデートを行う．
- 次のスケジュール日程を決定する
- スケジュールが来るまで待つ
- スケジュールが来たら，surplusNodes分だけ予備のnodeを追加する
- nodeがreadyになるのを待つ
- 全nodeがreadyになったら一番古いnodeを1台消す
- ASGによりinstanceが自動的に補充されnodeとしてクラスタに参加するのを待つ
- 全nodeがrefresh開始時より新しくなるまで5~の流れを繰り返す
- 全nodeが新しくなったら補充したsurplusNodes分のnodeを削除する
- 次のスケジュール日程を決定する
replenisherがやること
- refresh中の場合は処理をすべてスキップする
- desiredで指定されたnode数とreadyなnode数を比較する
- nodeが不足している場合はASGのdesiredを上げてinstanceを追加で起動させる
- このとき，desiredと実際に起動されてるinstance数が異なるASGは，spotの都合でinstanceが起動できていない可能性がある．そのため，instanceの追加対象ASGから除外して考える．あくまで正常にinstanceを起動できているASGだけを対象にdesiredを上げる
- nodeが過剰にある場合は，適当なASGのdesiredを下げる
- また，起動後一定時間経ってもクラスタに参加できていないinstanceがある場合は，ASGからdetach & terminateする
kopsでは，cluster specにてetcdの数と，etcdを起動するinstance groupを指定している．これの定義以上のインスタンスを起動しても，masterとしてはクラスタに参加することができない（etcdの定義が被ってしまう）ため，そういったインスタンスはいつまで待っていても無駄である．そのため，これも削除するようにしている．
まとめ
実際，LaunchTemplateとMixedInstancePolicyが使えるようになってから，replenisherの仕事はほぼなくなった．複数のflavorを指定しているので，特定のASGでインスタンスが起動できなくなるという事態がそもそも発生しにくくなっている．そのため，普段はほとんどrefresherの仕事を眺めるだけになっている．
Spotは中断の2分前に通知を出すことができる．
本当はこれを拾って，対象nodeのdrainができると良いのだけど，まだそこまで実装できていない． また，refreshにおいても，インスタンスを殺す前にdrainができると最高なのだが，まだ実装できていない．
ManjaroのgrubがデュアルブートしているWindowsを認識しなくなった
症状
症状としては，アップデート後にgrubのOS選択画面が表示されなくなる．
grubはGRUB_TIMEOUT によってタイムアウトが設定されているのだが，そもそもOSが一つしかない場合はgrub自体の画面が表示されない．
今回は，どうやらgrubがデュアルブートしているWindowsを検出しなくなったため，OSの選択肢がひとつだけになりgrubの選択画面が消えたようだ．
ちなみに，grubの画面自体を表示するだけなら，
# GRUB_TIMEOUT=10 GRUB_TIMEOUT_STYLE=menu GRUB_HIDDEN_TIMEOUT_QUIET=false
みたいなことをするだけで，表示されるようになる．Linuxしか選択できなかったが．
原因と対策
これ系を調べるとsudo update-grubすれば良いとかsudo grub-mkconfigすればいいとか，そんな適当な情報しかでてこないのだが，これらでは解決しなかった．
原因はgrub-mkconfigがos-proberを実行しないことにあった．
実際update-grubしてみると，
$ sudo update-grub Generating grub configuration file ... Found theme: /usr/share/grub/themes/manjaro/theme.txt Found linux image: /boot/vmlinuz-5.10-x86_64 Found initrd image: /boot/amd-ucode.img /boot/initramfs-5.10-x86_64.img Found initrd fallback image: /boot/initramfs-5.10-x86_64-fallback.img Found linux image: /boot/vmlinuz-5.9-x86_64 Found initrd image: /boot/amd-ucode.img /boot/initramfs-5.9-x86_64.img Found initrd fallback image: /boot/initramfs-5.9-x86_64-fallback.img Warning: os-prober will not be executed to detect other bootable partitions. Systems on them will not be added to the GRUB boot configuration. Check GRUB_DISABLE_OS_PROBER documentation entry. Adding boot menu entry for UEFI Firmware Settings ... Found memtest86+ image: /boot/memtest86+/memtest.bin done
というような表示になる．linuxは検出しているが，Windowsを検出した気配がない． で，重要なことが書いてある．
Warning: os-prober will not be executed to detect other bootable partitions.
そう，実行されてないのだ． os-proberはbootできそうなosを見つけてくれるプログラムなのだが，linuxは自分自信だからいいとして，今起動していないWindowsはこいつで自動的に見つけてgrubが設定を作ってくれるはずだった．
ちなみにこいつを単体で実行すると，
$ sudo os-prober /dev/sdb1@/EFI/Microsoft/Boot/bootmgfw.efi:Windows Boot Manager:Windows:efi
ちゃんとWindowsを見つけてくれる． というわけでこれを実行できるようにしてやれば良い．
/usr/bin/grub-mkconfigを開いてみると，
# Disable os-prober by default due to security reasons. GRUB_DISABLE_OS_PROBER="true"
となっている．やはりgrubからos-proberの呼び出しが無効化されている．
というわけでこれを有効化するのだが，別にgrub-mkconfigを編集してもよいのだが，生成済みの/etc/default/grub からも上書きできるので，こちらを編集する．
GRUB_DEFAULT=saved GRUB_TIMEOUT=10 GRUB_TIMEOUT_STYLE=hidden GRUB_DISTRIBUTOR="Manjaro" GRUB_CMDLINE_LINUX_DEFAULT="text apparmor=1 security=apparmor udev.log_priority=3 nouveau.modeset=0 libata.force=noncq irqpoll" GRUB_CMDLINE_LINUX="" GRUB_DISABLE_OS_PROBER=false
あとは，
$ sudo update-grub Generating grub configuration file ... Found theme: /usr/share/grub/themes/manjaro/theme.txt Found linux image: /boot/vmlinuz-5.10-x86_64 Found initrd image: /boot/amd-ucode.img /boot/initramfs-5.10-x86_64.img Found initrd fallback image: /boot/initramfs-5.10-x86_64-fallback.img Found linux image: /boot/vmlinuz-5.9-x86_64 Found initrd image: /boot/amd-ucode.img /boot/initramfs-5.9-x86_64.img Found initrd fallback image: /boot/initramfs-5.9-x86_64-fallback.img Warning: os-prober will be executed to detect other bootable partitions. It's output will be used to detect bootable binaries on them and create new boot entries. Found Windows Boot Manager on /dev/sdb1@/EFI/Microsoft/Boot/bootmgfw.efi Adding boot menu entry for UEFI Firmware Settings ... Found memtest86+ image: /boot/memtest86+/memtest.bin done
と，無事にWindowsを検出してくれる．
そもそもos-proberなんで無効になってるの？
同じ疑問を抱いた人がいた． forum.manjaro.org
grub2のセキュリティアップデートにより無効化されている． 該当するアップデートは
で，UEFI Secure BootのCVEに対応するためと思われる．
修正はこれ．
別の方法
os-proberを使わなくても，/etc/grub.d/40_custom に自分でWindowsのエントリを書けば，それでgrubからOS選択はできる（設定が間違ってなければ）．
というわけでそういう方法もある．詳しくはArchWikiを見て．
参考
ITエンジニアに対するスカウトに思うところ
WantedlyやLinkedInにユーザとして登録していると，スカウトをもらうことがある．最近はこれに近いサービスが多くあり，LAPRASやOffersなんかもある．findyは，スカウトというほどはっきりしたものではないが，一応興味通知が来る． サービスを通さなくても，直接メールが来たり，TwitterのDMでスカウトが来たり，いろいろな方法でスカウトが届く．
スカウトと言っても，いきなり「あなたを1000万で雇うからすぐに来てくれ！」みたいなことはなくて，だいたいは「一度お話しましょう」というのが多い． この形のスカウトで一番多いのが「カジュアル面談」を誘うパターンだ．
前職がLAPRASだったこともあり，私も自分でスカウトメールを書いて送ったことはあるし，カジュアル面談をセッティングしたことも何度もある． そういう経験もあり，カジュアル面談の誘いが来たら，全部ではないがそれなりに受けてみることにしていた．
が，最近立て続けに不届きなスカウトメールを受け取ることが増えたので一言言っておきたい．
「転職意思がなくても構わないので」と書くのであれば転職意思がなくてもちゃんとカジュアル面談しろよ
続きを読むKubernetes 1.20ではownerReferenceのnamespaceに気を使え
ここの話です．
Issueの内容を熟知している方には余計なお世話です．
いやーこんなの自分には関係ないだろうと思ってたら見事に当たりました．
問題になるケース
問題になるケースはおそらく以下の2パターン．
- OwnerとChildが別のnamespaceに所属するパターン
- namespaceに所属するOwnerがcluster scopeなChildからOwnerReferenceを張られているパターン
ちなみにこれは作成時にエラーになるわけではない．あくまでGCコントローラの挙動の変更なので，リソースが削除される挙動が変更になっている．
私の場合2に該当していた．
CRDを定義して，カスタムリソースをapplyするとAdmissionWebhookのConfigurationと，それに合わせたWebhookのPodとServiceを作るようなコントローラを作っていた． このとき，CRDのscopeをNamespacedにしていたんだけど，NamespacedなカスタムリソースがCluster scopeのValidating/MutatingWebhookConfigurationをChildに持つ場合，がっつり上記に該当してGCされなくなる． 結果として，カスタムリソースを削除してもWebhookConfigurationが削除されないという状態になった．
対応
私の場合の話なので，2に該当する場合なのだけれど，OwnerがNamespacedである必要がないのであれば，OwnerをCluster scopeにしてしまえば良い．Cluster scopeなOwnerがCluster scopeなChildを持つことは特に問題ない．また，Cluster scopeなOwnerがNamespace scopeのChildを持つことも，特に問題はない．GCコントローラはちゃんとOwnerが消えたときにChildも消してくれる．
今回で言うなら，Validating/MutatingWebhookConfigurationのOwnerなので，別にCluster scopeで良くて，Cluster scopeに変更することで対応できた．合わせて作るPodとServiceのnamespaceをどこにするかは悩みどころではあったが．Cluster scopeなカスタムリソースもそれらのPodやServiceのOwnerになれるので，特に問題はなかった．
1についても同様なのだけれど，OwnerがCluster scopeで良いのであれば，Cluster scopeにすることで正しいOwnerReferenceになる．
問題はOwnerがNamespace scopeである必要がある場合なのだが，それってどんなケースなのか想像できないのでちょっと対応策も思いつかない……．
気づいた経緯
そもそもこの話は知っていたんだけど，完全に無関係だろうと思っていた．ので完全に油断していたんだけど，先日書いたkind local registryによりE2Eがそれなりの頻度でCIで走るようになったおかげで気づいた．
Kubernetes 1.20に上げたところでテストが落ちて，AdmissionWebhookが消えなくなっていたので，そこで問題が発覚した．
E2Eテスト便利や．
ちなみに記事でも紹介されてたけど kubectl-check-ownerrefefrences を使えば一発でわかるんで，これも便利だったよ．
