Kubernetes 1.21のリリースが間近に迫っており、斬新な要素が満載です。では、どこから始めましょうか？
今回のリリースでは、Kubernetes 1.20の43件、Kubernetes 1.19の34件から、50件の機能強化が行われました。この50の機能強化のうち、15はStable版への移行、14は改善を続ける既存の機能、そしてなんと19は全く新しい機能です。
1.4の頃からあった古い機能がようやくGAになったのは素晴らしいことです。例えば、CronJob、PodDisruptionBudget、sysctlサポートなどです。
同じように、Pod Security Policiesのようなセキュリティ機能が廃止されるのは残念なことです。
話題は尽きませんので、さっそくKubernetes 1.21の新機能をご紹介しましょう。
Kubernetes 1.21 – 編集者の精選：
今回のリリースで最もエキサイティングに見える機能は以下の通りです（ymmv）。#1769メモリマネージャー
データベースのような一部のアプリケーションのパフォーマンスを確保するためには、メモリが不可欠です。このようなワークロードでは、パフォーマンスの低下は受け入れられないかもしれません。新しいメモリーマネージャーのような機能は、デリケートなデプロイメントをKubernetesに移行することをより魅力的にしています。Carlos Arilla – Sysdig インテグレーション・エンジニアリング・マネージャー
#1923 & #2249 Scheduler: ノミネーテッドノードとポッドアフィニティセレクター
Kubernetesは、すべてのワークロードが同じではないことを常に認めています。これは、このプロジェクトが成熟しつつあることを物語っています。主要なユースケースはほぼカバーされており、より多くのリソースが利用可能であるため、労力をカスタマイズやエッジケースに振り向けることができます。大規模なクラスターの管理が容易になるため、Podをデプロイするノードの選択方法をより柔軟に制御できるようになることは大歓迎です。クラスター管理者の生活を楽にすることは、Kubernetes採用の鍵となります。
Jesús Ángel Samitier – Sysdig DevOpsコンテンツエンジニア
#2185 & #2255 ReplicaSet ダウンスケーリング
Kubernetesのオートスケーリングはその最大の特徴の一つです。しかし、ロードスパイクが過ぎてダウンスケールの時期になった後に何が起こるかについては、ほとんどコントロールできていませんでした。クラスターをダウンスケールするための2つの新しい戦略（セミランダムとコストベース）を持つことで、手動チェックの必要性がなくなります。これにより、Kubernetesは高可用性を必要とするワークロードに適したものとなります。
Carlos Arilla – Sysdig インテグレーション・エンジニアリング・マネージャー
#2214 インデックス付きジョブ
この機能強化により、並列性の高いワークロードのKubernetesへの導入が容易になります。科学研究者の皆さん、こんにちは。私は今、Kubernetesが開いているドアに興奮しています。Víctor Jiménez – Sysdigのコンテンツエンジニアリングマネージャー
#2079 ネットワークポリシーのポートレンジ
設定ファイルがシンプルになることは、誰にとっても嬉しいことです。20個の連続したポートに対してネットワークポリシーを定義したい場合、20個のルールを書く必要はもうありません…1つだけですJesús Ángel Samitier – Sysdig DevOpsコンテンツエンジニア
Kubernetes 1.21での非推奨事項
#5 ポッドのセキュリティポリシー
機能グループ: auth
Pod Security Policies (PSP)はKubernetesネイティブの優れたツールで、デプロイメントの実行を特定のユーザーに限定したり、ネットワークやボリュームなどのリソースにアクセスしたりすることなどを制限するためのKubernetesネイティブの優れたツールです。
PSPは1.8からベータ版として提供されていますが、この機能にはGA版のリリースを妨げる重大な制限があります。二重認証モデルはセキュリティを弱め、デフォルトでは有効にすることができず、APIは多くの不整合を伴って成長してきました。
Kubernetes 1.19で導入された新しい機能プロモーションモデルに従って、この機能を安定した機能にするためにPSPの作業を開始すべきでした。Kubernetesチームは次のステップを決定しています。PSPsのすべての欠陥を互換性のないv2で修正するべきか？下位互換性を維持し、開発を複雑にするべきか。この機能を放棄して、既存の代替手段に任せるべきか？
今のところ、明確な道筋はありません。その結果、Pod Security PoliciesはKubernetes 1.21で非推奨とされ、Kubernetes 1.25で完全に削除される予定です。
#536 サービスのトポロジーを考慮したルーティング
機能グループ: ネットワーク
Kubernetes 1.17で導入されたこの機能は、Kubernetesサービス間のネットワークルーティングをより効率的に行うことを目的としていました。この機能は#2433と#2086に代わって非推奨となりました。
Kubernetes 1.21でのスケジューリング
#1923 ノミネーテッドノードを優先
ステージ： アルファ
機能グループ: スケジューリング
ポッドをスケジューリングする際、最適な候補を探してすべてのノードを評価することは、大規模なクラスターでは時間がかかります。この機能では、このプロセスを高速化するために、Pod内の.status.nominatedNodeNameフィールドで優先ノードを定義することができます。ポッドが指名されたノードに適合しない場合、スケジューリングサイクルは通常通りクラスター内の残りのノードの評価を続けます。この機能の詳細をすべて確認するには、KEPを確認してください。
#2249 ポッドのアフィニティ ネームスペースセレクターとスコープ
ステージ ：アルファ
機能グループ: スケジューリング
デプロイメントでノードアフィニティを定義することで、ポッドがスケジュールされるノードを制約することができます。たとえば、example-labelのlabel-valueを持つPodをすでに実行しているノードにデプロイします。
apiVersion: v1
kind: Deployment
…
spec:
…
affinity:
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: example-label
operator: In
values:
- label-value
namespaces: […]
namespacesSelector: …
…この機能拡張により、namespaceSelectorフィールドが追加され、名前ではなくラベルでネームスペースを指定できるようになりました。このフィールドを使用すると、ネームスペースのセットを動的に定義することができます。
アフィニティtermは、namespaceSelectorおよびnamespacesフィールドで選択されたすべてのネームスペースに適用されます。
ネームスペースが実行されているデプロイメントをターゲットにすると、セキュリティ上の問題が発生するため、この機能強化では CrossNamespaceAffinity リソースクォータスコープも導入されています。たとえば、foo-nsネームスペースのデプロイメントがnamespaceSelector機能を使用するのをブロックするには、0のハードリミットでクォータを設定します。
apiVersion: v1
kind: ResourceQuota
metadata:
name: disable-cross-namespace-affinity
namespace: foo-ns
spec:
hard:
pods: "0"
scopeSelector:
matchExpressions:
- scopeName: CrossNamespaceAffinity
Kubernetes 1.21 アプリ
#2185 ReplicaSetのダウンスケール時のランダムなポッド選択
ステージ： アルファ
機能グループ: apps
ReplicaSetsの現在のダウンスケールアルゴリズムは、稼働時間が最も短いPodを削除します。しかし、このヒューリスティックな方法は、レプリカの分布が不均衡になるため、高可用性シナリオでは不利になります。これを緩和するために、LogarithmicScaleDown機能ゲートが追加されました。この機能を有効にすると、ポッドのタイムスタンプの対数バケット化に基づいて、ポッドの半ランダムな選択が行われます。
#2255 ReplicaSetのポッド削除コスト
ステージ ：アルファ
機能グループ: apps
前述の機能強化で述べたように、スケールダウンする際には一番若いPodが最初に削除されます。これはいくつかのユースケースでは理想とは程遠いものです。今回の機能強化では、Kubernetes 1.21にスケールダウン時にPodを選択するための別のヒューリスティックを追加しました。
具体的には、controller.kubernetes.io/pod-deletion-cost=10でPodをアノテートできるようになりました（デフォルトは0）。より低い削除コストのPodを削除するように最善の努力がなされます。
#2214 インデックス付きジョブ
ステージ :アルファ
機能グループ: apps
この機能強化により、高度な並列化が可能なジョブ（embarrassingly parallelとも呼ばれます）のスケジューリングが容易になります。apiVersion: batch/v1 kind: Job metadata: name: 'indexed-job' spec: completions: 5 parallelism: 3 completionMode: Indexed …
この機能の詳細については、ドキュメントを参照してください。
#2232 停止したジョブ
ステージ ：アルファ
機能グループ: apps
ジョブは1つまたは複数のPodを作成し、指定された数のPodが正常に終了するまで、Podの実行を再試行し続けます。ポッドが正常に終了すると、ジョブはその正常終了を追跡します。Kubernetes 1.21以降、ジョブの.spec.suspendフィールドをtrueに設定することでジョブを一時的に中断し、後でfalseに戻すことで再開することができるようになりました。
#19 CronJobがステーブルへグラデュエート
ステージ：ステーブルへ移行
機能グループ: apps
Kubernetes 1.4で導入され、1.8からはベータ版となっていたCronJobsがついにStableへの道を歩み始めました。CronJobsは、UNIX系システムのcronに似た周期的なタスクをKubernetesクラスター内で実行します。
1.20のリリースについては、What’s new in Kubernetesシリーズで詳しく紹介しています。
#85 PodDisruptionBudgetと/evictionサブリソース
ステージ：ステーブルへ移行
機能グループ: apps
Kubernetes 1.4で導入され、1.5からベータ版が提供されていたPodDisruptionBudgetが、ついにステーブルへグラデュエートします。このAPIでは、Podに対してminAvailableなレプリカ数を定義することができます。minAvailableの値に違反する方法で自発的にPodを破壊しようとしても、そのPodは削除されません。
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: zk-pdb
spec:
minAvailable: 2
selector:
matchLabels:
app: zookeeper#592 コントローラ終了後のTTL
ステージ ：ベータへ移行
機能グループ: apps
この機能は、終了したジョブや完了したジョブを自動的にクリーンアップします。これらのジョブは通常、システム内で必要とされておらず、それらを維持することでAPIサーバーの負荷が増大するため、これは有用です。ttlSecondsAfterFinishedフィールドを設定することで、コントローラがジョブをクリーンアップすることができるようになりました。
この機能はデフォルトで有効になっています。詳しくはジョブのドキュメントをご覧ください。
1.12のリリースについては、What’s new in Kubernetesシリーズをご覧ください。
Kubernetes 1.21のインスツルメンテーション
#2305 メトリクスカーディナリティのエンフォースメント
ステージ ：アルファ
機能グループ: インスツルメンテーション
過去には、メトリクスがメモリリークを引き起こす事象が発生していました。これらのケースでは、新しいKubernetesバイナリーがリリースされるまで問題を解決することができませんでした。この問題を軽減するため、今回の機能強化では、Kubernetes 1.21に2つの新しいコマンドラインオプションを導入しました。
–disabled-metricsフラグでは、問題のあるメトリクスを無効にすることができます。
また、–allow-label-valueオプションにより、メトリクスに受け入れられる値のリストを定義することができます。
#1209 メトリクスの安定性向上
ステージ： ステーブルへ移行
機能グループ:インスツルメンテーション
この機能強化は、Kubernetes の機能の廃止をより適切に処理するための最近の取り組みを踏襲しています。現在、メトリクスはALPHAとSTABLEのどちらかに分類されます。Alphaメトリクスはいつでも削除できますが、stableメトリクスは変更されないことが保証されています。そこで、ステーブルなメトリクスの廃止をより適切に処理するために、廃止のライフサイクルが導入されました。
ステーブルなメトリクスが廃止されると、まず廃止のマークが付けられます。これは、説明文に「Deprecated from x.y」という形で表示され、メトリクスの登録時に警告ログが出力されます。
数回のリリースの後、メトリクスは非表示になり、デフォルトでは登録されません。システム管理者は、コマンドラインオプション–show-hidden-metrics-for-versionを使用して、これらのメトリクスを再び有効にすることができます。
次のリリースでは、このメトリクスは削除されます。
#1602 ログの構造化
ステージ： ベータへ移行
機能グループ: インスツルメンテーション
この機能強化は、Kubernetes のログメッセージの標準的な構造を定義します。E1025 00:15:15.525108 1 controller_utils.go:114] "Failed to update pod status" err="timeout"
#1748 ポッドモデルを表すリソースリクエストとリミットに関するメトリクスを公開する
ステージ：ベータへ移行
機能グループ: インスツルメンテーション
kube-schedulerは、実行中のすべてのポッドのリクエストリソースと望ましいリミットに関するより多くのメトリクスを公開するようになりました。これにより、クラスター管理者がキャパシティをよりよく計画したり、エラーをトリアージしたりするのに役立ちます。1.20のリリースについては、What’s new in Kubernetesシリーズで詳しくご紹介しています。
#1933 静的解析によるロギングシークレットからの防御
ステージ：ベータへ移行
機能グループ: インスツルメンテーション
#1753 の準備中に行った静的解析により、機密データがどこで使われているかを把握できるようになりました。1.20のリリースについては、What’s new in Kubernetesシリーズで詳しくご紹介しています。
Kubernetes 1.21 ネットワーク
#1959 Service Type=LoadBalancer Class
ステージ： アルファ
機能グループ: ネットワーク
この機能拡張は、Service.spec.loadBalancerClassフィールドをServiceに導入することで、クラスター内で複数のService Type=LoadBalancerの実装を活用できるようにします。これは、GatewayClass リソースですでに対処されています。しかし、この機能拡張は、ゲートウェイAPIが成熟するまでの間、軽量な代替手段となります。
#2079 ネットワークポリシーのポート範囲
ステージ：アルファ
機能グループ: network
現在、NetworkPolicyを定義する際には、範囲内のすべてのポートを1つずつ指定する必要があります。spec:
egress:
– ports:
– protocol: TCP
port: 32000
– protocol: TCP
port: 32001
…
– protocol: TCP
port: 32768
egress:
– ports:
– protocol: TCP
port: 32000
– protocol: TCP
port: 32001
…
– protocol: TCP
port: 32768
NetworkPolicyEndPort機能ゲートで有効にすると、この機能拡張により、すべてのポートを範囲として定義できるようになります。
spec:
egress:
- ports:
- protocol: TCP
port: 32000
endPort: 32768#2086 サービス内部トラフィックポリシー
ステージ アルファ
機能グループ: ネットワーク
この機能拡張は、Kubernetesでより効率的なネットワークを構築するためのもう一つのステップです。ServiceTrafficPolicy機能ゲートが有効になると、Serviceオブジェクトで新しいspec.trafficPolicyフィールドが利用できるようになります。
このフィールドがClusterに設定されている場合、ルーティングは通常通りに動作します。
Topologyに設定されている場合は、トポロジーを考慮したルーティングが使用されます。
PreferLocalに設定すると、同じノード上のサービスにトラフィックがリダイレクトされます。Localに設定すると、同じノード上のサービスにのみトラフィックを送信します。
#2433 トポロジーを考慮したルーティングのヒント
ステージ：アルファ
機能グループ: ネットワーク
より最適なネットワークルーティングのためのこの新しいアプローチは、Kubernetes 1.17 で導入された #536 Topology aware routing を置き換えるものです。目標は、kube-proxyのようなコンポーネントにヒントを提供する柔軟なメカニズムを提供することで、トラフィックをルーティングする際に、より効率的にすることです。この機能の主な用途は、サービストラフィックを同じアベイラビリティゾーン内に保つことです。
TopologyAwareHints機能ゲートで有効にすると、EndpointSliceにヒントを定義できるようになります。
apiVersion: discovery.k8s.io/v1
kind: EndpointSlice
…
endpoints:
- addresses:
- "10.1.2.3"
conditions:
ready: true
hostname: pod-1
zone: zone-a
hints:
forZones:
- name: "zone-a"#2365 IngressClass namespaced params
ステージ アルファ
機能グループ: ネットワーク
今回の機能強化により、IngressClassのパラメータをNamespaceスコープで指定できるようになりました：apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
name: external-lb
spec:
controller: example.com/ingress-controller
parameters:
apiGroup: k8s.example.com
kind: IngressParameters
name: external-lb
namespace: external-configuration
scope: Namespace
#752 EndpointSlice
ステージ： ステーブルへ移行
機能グループ: ネットワーク
新しい EndpointSlice API は、エンドポイントを複数の Endpoint Slice リソースに分割します。これにより、大きなEndpointsオブジェクトに関連する現在のAPIの多くの問題が解決されます。この新しいAPIは、ポッドごとの複数のIPのような、その他の将来の機能をサポートするようにも設計されています。1.20のリリースについては、What’s new in Kubernetesシリーズで詳しくご紹介しています。
#2200 admission経由でサービスExternalIPsをブロック
ステージ：ステーブルへ移行
機能グループ: ネットワーク
この機能強化は、攻撃者が中間者として振る舞うことができるCVE-2020-8554への対応として行われました。これは、ClusterIPサービスを作成し、spec.externalIPsフィールドにターゲットとなるIPを設定することで行われます。すると、攻撃者はそのIPへのトラフィックを傍受することができます。Service.spec.externalIPs[]機能には設計上の欠陥があります。その機能の一部は既存のtype=LoadBalancerで置き換えることができるため、このexternalIPsフィールドは実質的に必要なくなりました。
新しいDenyServiceExternalIPsアドミッションコントローラーが作成され、externalIPsフィールドを使用するリソースをデプロイメントからブロックします。
#563 IPv4/IPv6デュアルスタックのサポート
ステージ： ベータへ移行
機能グループ: ネットワーク
この機能は、クラスタ内ーでデュアルスタックモードをネイティブにサポートするために行われた作業をまとめたもので、指定されたポッドにIPv4とIPv6の両方のアドレスを割り当てることができます。ベータに移行したことで、デュアルスタックがデフォルトで有効になりました。
1.20のリリースについては、What’s new in Kubernetesシリーズで詳しくご紹介しています。
Kubernetes 1.21におけるノード
#1769 メモリマネージャ
ステージ：アルファ
機能グループ: ノード
新しいMemory Managerコンポーネントがkubeletで利用可能になり、Podsのメモリとhugepagesの割り当てを保証します。保証された QoS クラスの Pods に対してのみ動作します。これは、DPDKによるパケット処理、データベース、仮想マシンなど、メモリの最適化がパフォーマンスの鍵となるアプリケーションに有効です。
また、新しいメモリマネージャーは、トポロジーマネージャーのヒントプロバイダーとしても機能します。
Kubernetes 1.21に搭載された新しいメモリマネージャのフロー図
この新しいコンポーネントの詳細については、KEPのドキュメントを確認してください。
#2238 liveness probesに設定可能な猶予期間を追加
ステージ：アルファ
機能グループ: ノード
liveness probesを長い猶予期間とともに使用する場合、エッジケースがあります。Kubernetes 1.20で導入されたPod specのterminationGracePeriodSecondsフィールドは、Kubernetesに対して、終了後にコンテナをキルする前に指定された秒数を待つよう指示します。これにより、プロセスがリソースを解放し、重要なデータをフラッシュする時間が確保されます。
Liveness probesは、プロセスが正常に動作しているか、あるいはゾンビであり強制終了させなければならないかをKubernetesが知るための定期的なチェックの仕組みです。
プロセスがフリーズしてliveness probesに応答しなかったら、すぐに強制終了されるべきだと思うかもしれません。しかし、KubernetesはこれまでterminationGracePeriodSecondsを尊重していました。
想定されるケースとしては、非常にまばらに接続するいくつかのクライアントで適切にデータをダンプを行うために、シャットダウンに最大1時間を必要とするサービスがあります。サービスがハングアップした場合、すぐに再起動されるのではなく、再起動までに最大1時間かかることがあります。
今回の改善では、livenessProbeオブジェクト内に2つ目のterminationGracePeriodSecondsフィールドを導入し、2つの状況を区別するようになりました。通常、Kubernetesはコンテナをキルするのにどのくらい待つべきでしょうか？また、livenessProbeが失敗したためにキルする場合はどうでしょうか？
spec:
terminationGracePeriodSeconds: 3600 # pod-level
containers:
- name: test
image:
…
livenessProbe:
…
# Override pod-level terminationGracePeriodSeconds #
terminationGracePeriodSeconds: 60#34 sysctlサポートの追加
ステージ：ステーブルへ移行
機能グループ: ノード
Kubernetes 1.4以降、Linuxのsysctlsサービスと対話することで、デプロイされたPodのニーズに応じて特定のOSパラメータを調整することができるようになりました。今回、ステーブルになったのは、その設定をPodで宣言する方法の変更です。以前はアノテーションが使われていました。
apiVersion: v1
kind: Pod
metadata:
name: sysctl-example
annotations:
security.alpha.kubernetes.io/sysctls: kernel.shm_rmid_forced=1apiVersion: v1
kind: Pod
metadata:
name: sysctl-example
spec:
securityContext:
sysctls:
- name: kernel.shm_rmid_forced
value: 1
#213 Pod内のコンテナにおけるRunAsGroup機能の提供
ステージ：ステーブルへ移行
機能グループ: ノード
Kubernetes 1.14以降、ベータとして提供されていた機能が、正式にGA版として提供されました。Pod定義のsecurityContextセクション内のrunAsGroupフィールドを使用して、Podコンテナ内のプロセスに割り当てられるプライマリグループを指定できるようになりました。なお、securityContext内のfsGroupfieldを設定して、補助的なグループIDを指定することもできます。
#2129 KubeletからcAdvisor jsonメトリクスを削除
ステージ：ステーブルへ移行
機能グループ: ノード
cAdvisor が kubelet に統合されることには 2 つの大きな問題があります。- それは Linux でのみ動作します。
- ベンダーが代替実装を提供したい場合、既存の実装を無効にすることはできません。
このエンハンスメントは、永久に削除される前にこの非推奨を修正するために行われた作業をまとめたものです。
#2403 podresources APIを拡張して割り当て可能なリソースをレポート
ステージ：ステーブルへ移行
機能グループ: ノード
kubelet の pod resources エンドポイント (pod resources API) にこの機能を追加することで、サードパーティの消費者が Pod に割り当てられたコンピュートリソースについて知ることができるようになります。これには、Pod の名前、ネームスペース、コンテナ、コンテナに割り当てられた cpu_id などが含まれます。これにより、既存のpod resources APIエンドポイントと合わせて、ノードのキャパシティをより簡単に評価できるようになります。詳細はKubernetesのドキュメントをご覧ください。
#2411 CRIContainerLogRotation
ステージ：ステーブルへ移行
機能グループ: ノード
この機能強化は、Kubernetes 1.11 以降ベータであったこの機能を最終的に ステーブルにするための作業をまとめたものです。CRI（Container Runtime Interface）を介してkubeletと通信するコンテナランタイムでは、kubeletがコンテナランタイムのログを処理し、コンテナランタイムにログファイルのパスを提供する役割を担っています。
ログローテーションを実装する際には、kubelet がその処理を行うことになりました。
ログローテーションの動作を微調整するために、–container-log-max-size と –container-log-max-files という 2 つのコマンドラインオプションが追加されました。
#2000 グレースフルなノードのシャットダウン
ステージ ベータへ移行
機能グループ: ノード
GracefulNodeShutdown 機能のゲートを有効にすると、Kubelet はノードをシャットダウンする際に、そのノードで実行されているポッドをグレースフリーに終了させようとします。実装は、systemd の抑制ロックをリスニングすることで動作します (Linux の場合)。1.20のリリースについては、What’s new in Kubernetesシリーズで詳しく紹介しています。
#2053 hugepagesにおけるdownward APIサポートの追加
ステージ： ベータへ移行
機能グループ: ノード
ポッドがhugepageのリクエストとリミットに関する情報をdownward API経由で取得できるようになりました。これにより、cpu、メモリ、ephemeral-storageなどの他のリソースとの一貫性が保たれます。1.20のリリースについては、What’s new in Kubernetesシリーズで詳しくご紹介しています。
Kubernetes 1.21 ストレージ
#1432 ボリュームの健全性
ステージは：アルファ
機能グループ: ストレージ
現在、永続的なボリュームの問題はトラブルシューティングを行う事が困難です。ボリュームが存在するディスクが破損しているのか、あるいはボリュームがKubernetesの外で誤って削除されたのかを知るのは容易ではないことがあります。このトラブルシューティングを支援するために、CSI APIが拡張され、ボリュームの健全性に関する情報を提供するために、既存のRPCを修正し、新しいRPCを追加しました。
CSIドライバは、ボリュームの健全性をチェックするサイドカーとして外部コントローラをロードすることができます。また、Kubeletがボリュームに関する情報を収集するために既に使用しているNodeGetVolumeStats関数に追加情報を提供することもできます。
KEPドキュメントで完全な実装の詳細を確認してください。
#1845 ボリューム容量に基づくノードの優先順位付け
ステージ：アルファ
機能グループ: ストレージ
初期に Pod ボリュームトポロジー制約が実装されたとき (Kubernetes 1.13 以降のステーブル版)、十分な容量を持つノードで PersistentVolumes をスケジュールすることが目的でした。しかし、10Giボリュームのリクエストがあり、2つのノードが十分な容量を持っているというシナリオを考えてみましょう。
- ノード1：1TiのPersistentVolumesが利用可能です。
- ノード2：10GiのPersistentVolumesボリュームが利用できます。
この問題を軽減するために、スケジューラのVolumeBinding設定に新しいScore戦略が用意されています。
設定すると、各PersistentVolumeClaimに対して、PersistentVolumesがスコアリングされ、最も適切なものが選択されます。アルゴリズムの詳細については、KEPドキュメントを参照してください。
#1412 イミュータブルシークレットとコンフィグマップ
ステージ：ステーブルへ移行
機能グループ: ストレージ
新しい immutable フィールドが Secrets と ConfigMaps に追加されました。trueに設定すると、リソースキーに加えられた変更はすべて拒否されます。これにより、アプリケーションを破壊するような偶発的な不正更新からクラスターを保護することができます。不変的なリソースからは2つの利点があります。リソースが変更されないため、Kubeletはリソースの更新を定期的にチェックする必要がなく、スケーラビリティとパフォーマンスを向上させることができます。
詳しくは、What’s new in Kubernetesシリーズの1.18のリリースをご覧ください。
#1472 ポッドスケジューリングにおけるストレージ容量の追跡
ステージ ：ベータへ移行
機能グループ: ストレージ
この機能強化は、十分な空き容量が利用できないCSIボリュームに接続されたノードでポッドがスケジューリングされるのを防ごうとするものです。詳しくはWhat’s new in Kubernetesシリーズの1.19のリリースをご覧ください。
#1698 PVCインラインエフェメラルボリューム(CSIドライバと連携)
ステージ ベ：ベータへ移行
機能グループ: ストレージ
この機能拡張は、ダイナミックプロビジョニングをサポートする任意のストレージドライバーで動作するインラインエフェメラルボリュームを定義するためのシンプルなAPIを提供します。詳しくは、What’s new in Kubernetesシリーズの1.19のリリースをご覧ください。
#1885 AzureFile CSIマイグレーション
ステージ ：ベータへ移行
機能グループ: ストレージ
この機能強化は、Azure FileのコードをKubernetesのメインバイナリー（アウトオブツリー）から移動させる作業をまとめたものです。これは、既存のコードをCSIドライバーに移行し（#178, #625, #1490）、Kubernetesのコードを保守しやすくするための継続的な取り組みの一環です。
#2047 CSIサービスアカウントトークン
ステージ： ベータへ移行
機能グループ: ストレージ
この機能拡張により、CSIドライバーはKubeletからNodePublishVolume関数にサービスアカウントトークンを要求できるようになります。また、Kubeletはどのドライバーがどのトークンを利用できるかを制限できるようになります。そして最後に、ドライバーは RequiresRepublish を true に設定することで、NodePublishVolume を再実行してボリュームを再マウントすることができるようになります。この最後の機能は、マウントされたボリュームが期限切れになることがあり、再ログインが必要な場合に便利です。例えば、secrets vaultのような場合です。
詳しくは、What’s new in Kubernetesシリーズの1.20のリリースをご覧ください。
Kubernetes 1.21 API
#2155 client-goの型付きクライアントへの適用
ステージ：ステーブルへ移行
機能グループ: api-machinery
client-goベースのKubernetes APIクライアントがサーバ側のApplyを呼び出したい場合、Patchを呼び出してYAMLやJSONを含む[]byteを提供しなければなりません。これは、型のチェックがないためエラーになりやすく、ペイロードにエラーがあると予期せぬ現象が発生する可能性があります。
この問題を解決するために、新しい Apply メソッドが実装されました。これは既存の Patch を補完するもので、開発者にとってより簡単で安全なものになります。
#1904 ウォッチ再開の効率化
ステージ： ベータへ移行
機能グループ: api-machinery
今後、kube-apiserver は再起動後にウォッチキャッシュをより速く初期化できるようになります。詳しくはWhat’s new in Kubernetesシリーズの1.20のリリースをご覧ください。
#2161 APIServerですべてのネームスペースのラベルをデフォルトにする
ステージ： ベータへ移行
機能グループ: api-machinery
ネームスペースはKubernetes APIによって識別ラベルを持つことが保証されていないため、名前の代わりにフィールドセレクタを使ってネームスペースを選択する必要があります。これにより、Kubernetes APIでデフォルトのネットワークポリシーやその他のラベル駆動のネームスペース機能を書くといった作業が複雑になります。新しい不変のラベルkubernetes.io/metadata.nameがすべてのネームスペースに追加され、その値はネームスペースの名前です。このラベルは、前述のNetworkPolicyオブジェクトのように、あらゆるネームスペースセレクタで使用することができます。
Kubernetes 1.21 認証
#541 外部のclient-goクレデンシャル・プロバイダー
ステージ ：ベータへ移行
機能グループ: auth
この機能拡張により、Goクライアントは、キーマネージメントシステム(KMS)、トラステッドプラットフォームモジュール(TPM)、ハードウェアセキュリティモジュール(HSM)などの外部のクレデンシャルプロバイダーを使用して認証できるようになります。これらのデバイスは、すでに他のサービスに対する認証に使用されており、ローテートさせることが容易で、ディスク上にファイルとして存在しないため、より安全性が高くなっています。
当初、Kubernetes 1.10で導入されたこの機能は、1.20で行われた作業を引き継いでおり、Kubernetes 1.22ではGAとなる予定です。
#542, #1205 TokenRequest APIとKubeletの統合
ステージ： ステーブルへ移行
機能グループ: auth
ワークロードが API に対する認証に使用する現在の JSON Web Tokens (JWT) には、セキュリティ上の問題があります。この機能強化は、JWT のためのより安全な API を作成するための作業です。詳しくは、What’s new in Kubernetesシリーズの1.20のリリースをご覧ください。
#1393 ServiceAccountIssuerDiscovery GA
ステージ： ステーブルへ移行
機能グループ: auth
Kubernetesのサービスアカウント（KSA）は現在、Kubernetes APIに対する認証にJSON Web Tokens（JWT）を使用することができ、例えばkubectl –token <the_token_string>を使用します。今回の機能強化により、クラスター外のサービスが、APIサーバーに負荷をかけることなく、これらのトークンを一般的な認証方法として使用できるようになります。1.18のリリースについては、What’s new in Kubernetesシリーズでご紹介しています。
その他の強化点
#859 httpリクエストヘッダにkubectlコマンドのメタデータを含める
ステージ： アルファ
機能グループ: cli
Kubernetes 1.21から、kubectlはAPIサーバへのリクエストに追加のHTTPヘッダを含めるようになりました。どのkubectlコマンドが特定のリクエストを引き起こしたかを知ることで、管理者はトラブルシューティングやベストプラクティスの実施に役立つ情報を得ることができます。これらの追加ヘッダーは：
- X-Kubectl-Command：kubectlコマンド(apply, delete, create secret tls)
- X-Kubectl-Flags Header：コマンドフラグ(-filename=local)を含む
- X-Kubectl-Session Header: セッションIDを含み、複数のリクエストをリンクする
- X-Kubectl-Deprecated Header ： 与えられたコマンドが非推奨の場合
- X-Kubectl-Build Header: 文字列を含み、ビルド時にカスタマイズ可能
#2227 kubectlで使用されるデフォルトのコンテナアノテーション
ステージ：アルファ
機能グループ: cli
現在は、最初に実行されるコンテナがPodのデフォルトコンテナとされています。しかし、Service Meshでは、Podは常に2つのコンテナを持つことができます。メインのコンテナと、最初に実行されるサイドカーです。これにより、kubectlログから情報を読み取ったり、kubectl execを使用したりするなど、いくつかの管理作業が複雑になります（-cフラグがないとデフォルトコンテナを使用してしまうため）。
新しい kubectl.kubernetes.io/default-container アノテーションが Pod に追加され、デフォルトのコンテナを定義できるようになりました。
#2436 コントローラマネージャーのリーダマイグレーション
ステージ：アルファ
機能グループ: cloud-provider
#1885 で議論したように、クラウドプロバイダーに特化したコードを Kubernetes のコアコードの外に移動させようという積極的な取り組みが行われています (in-tree から out-of-tree へ)。しかし、この破壊的な変更は、コントロールプレーンの可用性に厳しい要件を持つクラスターにとっては問題となります。
今回の機能強化では、そのようなクラスターのための移行プロセスを確立し、kube-controller-managerの実行からcloud-controller-managerの実行への移行に焦点を当てています。
詳細はKubernetesのドキュメントを参照してください。
#2420 Kubernetesのビルドメンテナンスの削減
ステージ： ステーブルへ移行
機能グループ: テスト
現在、Kubernetes は複数のビルドシステムを維持しており、必要なメンテナンスが増え、摩擦や混乱の原因となっています。この機能強化は、すべてのビルドスクリプトをmake buildに移行し、bazel buildを削除するために行われた作業をまとめたものです。
以上、Kubernetes 1.21についてご紹介しました。これらの機能のいずれかを使用するつもりであれば、クラスターのアップグレードの準備をしてください。
この記事が気に入ったら、以前の「What’s new in Kubernetes（Kubernetesの新機能）」もチェックしてみてください。
- Kubernetes 1.20の新機能
- Kubernetes 1.19の新機能
- Kubernetes 1.18の新機能
- Kubernetes 1.17の新機能
- Kubernetes 1.16の新機能
- Kubernetes 1.15の新機能
- Kubernetes 1.14の新機能
- Kubernetes 1.13の新機能
- Kubernetes 1.12の新機能
また、Kubernetesエコシステムの最新情報を楽しみたい方は、クラウドネイティブエコシステムで起こっている最もクールな事を毎月メールでお届けするコンテナニュースレターをご購読ください。