静的解析 x Kubernetes API Conventions = Kube API Linter ~ ベストプラクティスに準拠したカスタムリソースの作り方と運用 ~ Tweet

Proposal: (エントリー済み)

本セッションでは私がメンテナーを務めるKubernetes SIGsのプロジェクトであるKube API LinterとCluster APIを題材にCRD定義のベストプラクティスと現在すでに運用しているAPIに対してどのように互換性を担保したままプラクティスを適用させていくかについて共有します。
Kube API LinterはKubernete APIのベストプラクティスであるKubernetes API Conventionsをベースとしたリンターです。Kubernetes APIとCRDは今日のKubernetesの特徴を語る上でとても重要な機能です。しかしユーザーが自由に定義することができるため多くの知識が必要であり、失敗したAPIデザインは直接そのAPIを扱うシステムの負債となります。そこでKubernetes APIのベストプラクティスをリンターとして提供するKubernetes API Linterが生まれました。例えばある文字列のフィールドはrequiredとoptionalどちらにするべきでしょうか。この判断のためににはjson tagの設定、MinLengthがどのような値で設定されているかといった様々な条件を考慮して決定する必要があります。また実際にベストプラクティスを適用できていないフィールドはkubebuilderのconversion機能を使用して移行できますがどのように移行すると互換性を担保して移行できるのでしょう。
聴講者は本セッションを通じて実際にCluster APIのv1beta1からv1beta2へのAPI移行を行う中で導入されたKube API LinterとKube API Linterの提供しているKubernetes APIのベストプラクティスとその理由、そして実際に運用されているAPIへの互換性を保った移行方法を学ぶことができます。