ということで、2020年の書籍を読んだんだけど、だいたい1.19の頃の本らしい。当然どんどんバージョンはあがっている。
そこで雰囲気をつかむために1.20からのchangelogを眺めていくことにする。といっても全部読むのは大変なので、まとめてくれている人の記事とかをとっかかりに眺めていく。
1.20
Kubernetes 1.20: 変更点まとめ(What's new!) #kubernetes - Qiita
Qiitaの記事を眺めた。色々変わってるけど大きな構造の変化はなさそう。
PID LimitとAPI Priorityは知らなかった。Volumeのfsgroupの挙動もなるほどという。
1.21
Kubernetes 1.21: 変更点まとめ(What's new!) #kubernetes - Qiita
同じ人の記事だ! すごい。「kubernates 1.21」とかで検索するとこの人のシリーズがだいたい引っかかるのでここからしばらくは追っかけみたいになってる。
PodSecurityPolicyが非推奨へ なんだって。なるほど。kustomizeのバージョンアップはめでたい。
kubectl.kubernetes.io/default-container はい。kubectlコマンドで pod 操作するときどのコンテナが選択されるのかどういうルールなんだと怪訝に思っていた。
ローカルストレージ周りはあんまり実感を持ってみていない。自分で構築してみたら実感わくかなーと思うけど、あっさり動いて特に感慨なし、となりそうな気もする。
1.22
Kubernetes 1.22: 変更点まとめ(What's new!) #kubernetes - Qiita
エフェメラルコンテナに関する変更。それはいったいなんだ。
ああデバッグとかの時に一時的に起動するコンテナなるほど。
systemdのcgroup v2の話もぜんぜん知らなかったのでふむふむとなっている。全く意識したことなかった。そもそも systemd のアップデートも全然追えていない。
1.23
Kubernetes 1.23: 変更点まとめ(What's new!)とアップグレード時の注意事項 #kubernetes - Qiita
v4とv6のデュアルスタックでのネットワーキングがデフォルト有効になった。とはいえ基本的には「条件がそろえば有効になる」という感じか。
ログの構造とかが変更になっている。結構ダイナミックな変更だ。
PodSecurity が新しく出現。
1.24
Kubernetes 1.24: 変更点まとめ(What's new!)とアップグレード時の注意事項 #kubernetes - Qiita
NonPreemptingPriority。名前から動作がわからない。
優先度は他のPodに対する相対的なPodの重要度を示します。 もしPodをスケジューリングできないときには、スケジューラーはそのPodをスケジューリングできるようにするため、優先度の低いPodをプリエンプトする
preemptionPolicy: Neverと設定されたPodは、スケジューリングのキューにおいて他の優先度の低いPodよりも優先されますが、他のPodをプリエンプトすることはありません。 スケジューリングされるのを待つ非プリエンプトのPodは、リソースが十分に利用可能になるまでスケジューリングキューに残ります。
なるほど。
gRPC Probesがベータでデフォルト有効になっている。これは良い。
内部DNSがServiceにIPアドレスを振る際のソフトリザーブ機能。よさそう。
1.25
Kubernetes 1.25: 変更点まとめ(What's new!)とアップグレード時の注意事項 #kubernetes - Qiita
PodSecurityPolicy削除。
CSIとかCRDとかわかんねーぜ! いや嘘でCSIがストレージのインターフェイスのことであるのは知っている。Custom Resource Definitions（CRD）なるほど。
いくつかのbeta APIが削除される。基本的には困ることはない。運用してるとこういうのはビクビクするだろうなあ。
1.26
Kubernetes 1.26: 変更点まとめ(What's new!)とアップグレード時の注意事項 #kubernetes - Qiita
CEL使われているのだなあ。
Dynamic Resource Allocationはパッと見てよくわからなかったので元の提案の方を眺めていた。KEP、Kubernetes Enhancement Proposalの略。独立したリポジトリでデザインのドキュメントが連なっている。めちゃくちゃしっかり書かれている。
リソース確保をサードパーティ側からできるようにするけどそれによって上位のコンポーネントからの見通しは悪くなるかもね、みたいなことが書かれていてへーってなっていた。
1.27
Kubernetes 1.27: 変更点まとめ(What's new!)とアップグレード時の注意事項 #kubernetes - Qiita
Downward APIってなんだっけ。
コンテナにPodとかの情報を提供するやつか。どうも用語がまだピンときていない。
Node Logの有効化のやつはよくわからなかったけど、kubernatesの内部のやつではなくて、kubeletとかノードで動いているkubernatesコンポーネントのシステムログをマスターノードあたりからクエリできる、ってことなのかな。
だいたいあってそうだ。
ReadWriteOncePod、前からあるのでは、と思ったけどそれまではノード単位での許可しかなかったってことかな。同一ノード内での奪い合いが発生する。スケジューラがPodの優先度を考慮するらしい。なるほど。
1.28
Kubernetes 1.28: 変更点まとめ(What's new!)とアップグレード時の注意事項 #kubernetes - Qiita
kube-proxyがアップグレード時のAPIバージョンの差をうまく吸収するように。
skew って語がポンとk8s文脈で出てきたらアップグレード時のバージョン差異のことなの? と思ったけどそうでもないか。例えばノード間のPod数の偏りとかもskewとされる。
initContainerとサイドカーコンテナの論は書いていることがよくわからなかった。見てたら、
Kubernetes 1.28 から始める Sidecar Containers #kubernetes - Qiita
従来の Sidecar はメインコンテナとの間に関係性が定義出来ません. このため, 特にケアしない場合, Sidecar がメインコンテナより先に起動することを保証できません.
Sidecar Containers | Kubernetes
Kubernetes implements sidecar containers as a special case of init containers; sidecar containers remain running after Pod startup. This document uses the term regular init containers to clearly refer to containers that only run during Pod startup.
サイドカーコンテナは initContainerの special caseであるよと。はい。restartPolicy を指定するとサイドカー扱いなのかな。
単発のJobのPodが死んだ時の再作成時の挙動、たとえば重要なデバイスを占有するため前のJobのPodが綺麗に終了したあとでないと新しいPodが使えないなどの場合に待つとかそういうのがサポートされる。というか今までなかったの? 同時に alpha としてバックオフの制限なども入っている。いかにも特定ユースケースからのフィードバックという感じ。
1.29
Kubernetes 1.29: 変更点まとめ(What's new!)とアップグレード時の注意事項 #kubernetes - Qiita
ReadWriteOncePod がGA。
個々のクラウドプロパイダ向けの実装が除外される。
ネットワーク制御についてiptablesをバックエンドにしていたがnftablesを利用するように変更を開始（まだ alpha）
1.30
Kubernetes 1.30: 変更点まとめ(What's new!)とアップグレード時の注意事項 #kubernetes - Qiita
Pod scheduling rediness がGA。
spec.schedulingGates[]になんか値が入ってたらスケジューリングされない。誰かがそれを削除しないといけない。ということは理解した。いやでも「Podが作成された」状態と「schedulingGatedである」状態の違いがよくわかってないかも。
まあ Podは作成されたがNodeに配置されてないという状態が実際には発生する（リソースの requests の条件を満たしたノードがないとかで）のだけど、その再配置の試行がコスト高いので、今無理ってわかってる場合は抑止できるフラグをつけよう、ってことか。なるほど。
minDomains ... ドメイン is 何
Pod Topology Spreadの超最前線 MinDomains、NodeInclusionPoliciesについて - Speaker Deck
えーそういうこと? node-selectorで識別したPodの群のことをドメインと呼ぶの? しかしそんな定義はどこにあるのだ。
Pod Topology Spread Constraints | Kubernetes
Nodeを論理的にグルーピングする概念。Topology Domainといいます。 NodeにLabelを付与することで表現します。
ちょっと気持ち悪いけど、そういう意味で使われている語であることは理解した。
インデックス付きのJobの完了ポリシーを設定できるように。特定のインデックスが完了した場合と、一定の数が完了した場合。後者は面白い。どういう時に使うんだろう。
1.31
まだQiitaの人の記事は更新されてなかった。公式の説明がわかりやすい。
kubernates を通して AppArmor 設定するやつのサポートがGA。アノテーションベースではなく設定値ベースに変更。
サービスのトラフィック分散の仕方をカスタマイズできるやつがベータになった。トポロジーを考慮して最適にやるやつは具体的な実装の指針が示されているものではないので実装依存という感じか。難しい。
OCIのイメージをボリュームとしてマウントするやつがAlpha化。これは面白い。
とりあえずここまで。k8sの開発チームはいろいろ目的ごとに分かれていてSIGと呼ばれている、とか、デザインドキュメントはKEPと呼んで管理されているとか、そういうところからわかってなかったので良かった。cgroups v2とかAppArmorとか、Linux側の方もちゃんと追っていかないといけない。
