Google Cloudとコンテナの継続的なセキュリティ
本文の内容は、2021年3月31日にVíctor Jiménez Cerradaが投稿したブログ(https://sysdig.com/blog/whats-new-kubernetes-1-21/)を元に日本語に翻訳・再構成した内容となっております。
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の新機能をご紹介しましょう。
今回のリリースで最もエキサイティングに見える機能は以下の通りです（ymmv）。
データベースのような一部のアプリケーションのパフォーマンスを確保するためには、メモリが不可欠です。このようなワークロードでは、パフォーマンスの低下は受け入れられないかもしれません。新しいメモリーマネージャーのような機能は、デリケートなデプロイメントをKubernetesに移行することをより魅力的にしています。
Carlos Arilla - Sysdig インテグレーション・エンジニアリング・マネージャー
Kubernetesは、すべてのワークロードが同じではないことを常に認めています。これは、このプロジェクトが成熟しつつあることを物語っています。主要なユースケースはほぼカバーされており、より多くのリソースが利用可能であるため、労力をカスタマイズやエッジケースに振り向けることができます。
大規模なクラスターの管理が容易になるため、Podをデプロイするノードの選択方法をより柔軟に制御できるようになることは大歓迎です。クラスター管理者の生活を楽にすることは、Kubernetes採用の鍵となります。
Jesús Ángel Samitier - Sysdig DevOpsコンテンツエンジニア
Kubernetesのオートスケーリングはその最大の特徴の一つです。しかし、ロードスパイクが過ぎてダウンスケールの時期になった後に何が起こるかについては、ほとんどコントロールできていませんでした。
クラスターをダウンスケールするための2つの新しい戦略（セミランダムとコストベース）を持つことで、手動チェックの必要性がなくなります。これにより、Kubernetesは高可用性を必要とするワークロードに適したものとなります。
Carlos Arilla - Sysdig インテグレーション・エンジニアリング・マネージャー
この機能強化により、並列性の高いワークロードのKubernetesへの導入が容易になります。科学研究者の皆さん、こんにちは。私は今、Kubernetesが開いているドアに興奮しています。
Víctor Jiménez - Sysdigのコンテンツエンジニアリングマネージャー
設定ファイルがシンプルになることは、誰にとっても嬉しいことです。20個の連続したポートに対してネットワークポリシーを定義したい場合、20個のルールを書く必要はもうありません...1つだけです
Jesús Ángel Samitier - Sysdig DevOpsコンテンツエンジニア
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で完全に削除される予定です。
Kubernetes 1.17で導入されたこの機能は、Kubernetesサービス間のネットワークルーティングをより効率的に行うことを目的としていました。
この機能は#2433と#2086に代わって非推奨となりました。
ポッドをスケジューリングする際、最適な候補を探してすべてのノードを評価することは、大規模なクラスターでは時間がかかります。この機能では、このプロセスを高速化するために、Pod内の.status.nominatedNodeNameフィールドで優先ノードを定義することができます。ポッドが指名されたノードに適合しない場合、スケジューリングサイクルは通常通りクラスター内の残りのノードの評価を続けます。
この機能の詳細をすべて確認するには、KEPを確認してください。
デプロイメントでノードアフィニティを定義することで、ポッドがスケジュールされるノードを制約することができます。
たとえば、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: ...
...
デフォルトでは、これらの制約は、同じネームスペースにあるポッド、またはnamespacesフィールドにリストされているポッドに対して計算されます。しかし、事前にネームスペース名がわからない場合や、より具体的な別のプロパティを使用したい場合があります。
この機能拡張により、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
ReplicaSetsの現在のダウンスケールアルゴリズムは、稼働時間が最も短いPodを削除します。しかし、このヒューリスティックな方法は、レプリカの分布が不均衡になるため、高可用性シナリオでは不利になります。
これを緩和するために、LogarithmicScaleDown機能ゲートが追加されました。この機能を有効にすると、ポッドのタイムスタンプの対数バケット化に基づいて、ポッドの半ランダムな選択が行われます。
前述の機能強化で述べたように、スケールダウンする際には一番若いPodが最初に削除されます。これはいくつかのユースケースでは理想とは程遠いものです。
今回の機能強化では、Kubernetes 1.21にスケールダウン時にPodを選択するための別のヒューリスティックを追加しました。
具体的には、controller.kubernetes.io/pod-deletion-cost=10でPodをアノテートできるようになりました（デフォルトは0）。より低い削除コストのPodを削除するように最善の努力がなされます。
この機能強化により、高度な並列化が可能なジョブ（embarrassingly parallelとも呼ばれます）のスケジューリングが容易になります。
apiVersion: batch/v1 kind: Job metadata: name: 'indexed-job' spec: completions: 5 parallelism: 3 completionMode: Indexed ...
completionMode: Indexedを使用すると、各Podは0～completions - 1の範囲で異なるインデックスを取得します。各インデックスに1つの正常に完了したPodがあると、ジョブは完了したとみなされます。
この機能の詳細については、ドキュメントを参照してください。
ジョブは1つまたは複数のPodを作成し、指定された数のPodが正常に終了するまで、Podの実行を再試行し続けます。ポッドが正常に終了すると、ジョブはその正常終了を追跡します。
Kubernetes 1.21以降、ジョブの.spec.suspendフィールドをtrueに設定することでジョブを一時的に中断し、後でfalseに戻すことで再開することができるようになりました。
Kubernetes 1.4で導入され、1.8からはベータ版となっていたCronJobsがついにStableへの道を歩み始めました。
CronJobsは、UNIX系システムのcronに似た周期的なタスクをKubernetesクラスター内で実行します。
1.20のリリースについては、What's new in Kubernetesシリーズで詳しく紹介しています。
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
policy/v1beta1とpolicy/v1のAPIの注目すべき変更点は、このフィールドのデフォルト値です。ベータ版では、空のセレクターは0個のポッドにマッチしますが、policy/v1では、空のセレクターはネームスペースのすべてのポッドにマッチします。
この機能は、終了したジョブや完了したジョブを自動的にクリーンアップします。これらのジョブは通常、システム内で必要とされておらず、それらを維持することでAPIサーバーの負荷が増大するため、これは有用です。
ttlSecondsAfterFinishedフィールドを設定することで、コントローラがジョブをクリーンアップすることができるようになりました。
この機能はデフォルトで有効になっています。詳しくはジョブのドキュメントをご覧ください。
1.12のリリースについては、What's new in Kubernetesシリーズをご覧ください。
過去には、メトリクスがメモリリークを引き起こす事象が発生していました。これらのケースでは、新しいKubernetesバイナリーがリリースされるまで問題を解決することができませんでした。
この問題を軽減するため、今回の機能強化では、Kubernetes 1.21に2つの新しいコマンドラインオプションを導入しました。
-disabled-metricsフラグでは、問題のあるメトリクスを無効にすることができます。
また、-allow-label-valueオプションにより、メトリクスに受け入れられる値のリストを定義することができます。
この機能強化は、Kubernetes の機能の廃止をより適切に処理するための最近の取り組みを踏襲しています。
現在、メトリクスはALPHAとSTABLEのどちらかに分類されます。Alphaメトリクスはいつでも削除できますが、stableメトリクスは変更されないことが保証されています。そこで、ステーブルなメトリクスの廃止をより適切に処理するために、廃止のライフサイクルが導入されました。
ステーブルなメトリクスが廃止されると、まず廃止のマークが付けられます。これは、説明文に「Deprecated from x.y」という形で表示され、メトリクスの登録時に警告ログが出力されます。
数回のリリースの後、メトリクスは非表示になり、デフォルトでは登録されません。システム管理者は、コマンドラインオプション-show-hidden-metrics-for-versionを使用して、これらのメトリクスを再び有効にすることができます。
次のリリースでは、このメトリクスは削除されます。
この機能強化は、Kubernetes のログメッセージの標準的な構造を定義します。
E1025 00:15:15.525108 1 controller_utils.go:114] "Failed to update pod status" err="timeout"
1.19のリリースについては、What's new in KubernetesシリーズやKubernetesのドキュメントをご覧ください。
kube-schedulerは、実行中のすべてのポッドのリクエストリソースと望ましいリミットに関するより多くのメトリクスを公開するようになりました。これにより、クラスター管理者がキャパシティをよりよく計画したり、エラーをトリアージしたりするのに役立ちます。
1.20のリリースについては、What's new in Kubernetesシリーズで詳しくご紹介しています。
#1753 の準備中に行った静的解析により、機密データがどこで使われているかを把握できるようになりました。
1.20のリリースについては、What's new in Kubernetesシリーズで詳しくご紹介しています。
この機能拡張は、Service.spec.loadBalancerClassフィールドをServiceに導入することで、クラスター内で複数のService Type=LoadBalancerの実装を活用できるようにします。
これは、GatewayClass リソースですでに対処されています。しかし、この機能拡張は、ゲートウェイAPIが成熟するまでの間、軽量な代替手段となります。
現在、NetworkPolicyを定義する際には、範囲内のすべてのポートを1つずつ指定する必要があります。
NetworkPolicyEndPort機能ゲートで有効にすると、この機能拡張により、すべてのポートを範囲として定義できるようになります。
spec:
egress:
- ports:
- protocol: TCP
port: 32000
endPort: 32768
この機能を使用するためには、CNIプラグインもサポートしている必要があることに注意してください。
この機能拡張は、Kubernetesでより効率的なネットワークを構築するためのもう一つのステップです。
ServiceTrafficPolicy機能ゲートが有効になると、Serviceオブジェクトで新しいspec.trafficPolicyフィールドが利用できるようになります。
このフィールドがClusterに設定されている場合、ルーティングは通常通りに動作します。
Topologyに設定されている場合は、トポロジーを考慮したルーティングが使用されます。
PreferLocalに設定すると、同じノード上のサービスにトラフィックがリダイレクトされます。Localに設定すると、同じノード上のサービスにのみトラフィックを送信します。
より最適なネットワークルーティングのためのこの新しいアプローチは、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"
今回の機能強化により、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
新しい EndpointSlice API は、エンドポイントを複数の Endpoint Slice リソースに分割します。これにより、大きなEndpointsオブジェクトに関連する現在のAPIの多くの問題が解決されます。この新しいAPIは、ポッドごとの複数のIPのような、その他の将来の機能をサポートするようにも設計されています。
1.20のリリースについては、What's new in Kubernetesシリーズで詳しくご紹介しています。
この機能強化は、攻撃者が中間者として振る舞うことができるCVE-2020-8554への対応として行われました。これは、ClusterIPサービスを作成し、spec.externalIPsフィールドにターゲットとなるIPを設定することで行われます。すると、攻撃者はそのIPへのトラフィックを傍受することができます。
Service.spec.externalIPs[]機能には設計上の欠陥があります。その機能の一部は既存のtype=LoadBalancerで置き換えることができるため、このexternalIPsフィールドは実質的に必要なくなりました。
新しいDenyServiceExternalIPsアドミッションコントローラーが作成され、externalIPsフィールドを使用するリソースをデプロイメントからブロックします。
この機能は、クラスタ内ーでデュアルスタックモードをネイティブにサポートするために行われた作業をまとめたもので、指定されたポッドにIPv4とIPv6の両方のアドレスを割り当てることができます。
ベータに移行したことで、デュアルスタックがデフォルトで有効になりました。
1.20のリリースについては、What's new in Kubernetesシリーズで詳しくご紹介しています。
新しいMemory Managerコンポーネントがkubeletで利用可能になり、Podsのメモリとhugepagesの割り当てを保証します。保証された QoS クラスの Pods に対してのみ動作します。
これは、DPDKによるパケット処理、データベース、仮想マシンなど、メモリの最適化がパフォーマンスの鍵となるアプリケーションに有効です。
また、新しいメモリマネージャーは、トポロジーマネージャーのヒントプロバイダーとしても機能します。
Kubernetes 1.21に搭載された新しいメモリマネージャのフロー図
この新しいコンポーネントの詳細については、KEPのドキュメントを確認してください。
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
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=1
現在はフィールドが使われています。
apiVersion: v1
kind: Pod
metadata:
name: sysctl-example
spec:
securityContext:
sysctls:
- name: kernel.shm_rmid_forced
value: 1
Kubernetes 1.14以降、ベータとして提供されていた機能が、正式にGA版として提供されました。
Pod定義のsecurityContextセクション内のrunAsGroupフィールドを使用して、Podコンテナ内のプロセスに割り当てられるプライマリグループを指定できるようになりました。なお、securityContext内のfsGroupfieldを設定して、補助的なグループIDを指定することもできます。
cAdvisor が kubelet に統合されることには 2 つの大きな問題があります。
そのため、Kubernetes 1.18ではcAdvisorのメトリクスはデフォルトで無効になっていました。
このエンハンスメントは、永久に削除される前にこの非推奨を修正するために行われた作業をまとめたものです。
kubelet の pod resources エンドポイント (pod resources API) にこの機能を追加することで、サードパーティの消費者が Pod に割り当てられたコンピュートリソースについて知ることができるようになります。これには、Pod の名前、ネームスペース、コンテナ、コンテナに割り当てられた cpu_id などが含まれます。
これにより、既存のpod resources APIエンドポイントと合わせて、ノードのキャパシティをより簡単に評価できるようになります。詳細はKubernetesのドキュメントをご覧ください。
この機能強化は、Kubernetes 1.11 以降ベータであったこの機能を最終的に ステーブルにするための作業をまとめたものです。
CRI（Container Runtime Interface）を介してkubeletと通信するコンテナランタイムでは、kubeletがコンテナランタイムのログを処理し、コンテナランタイムにログファイルのパスを提供する役割を担っています。
ログローテーションを実装する際には、kubelet がその処理を行うことになりました。
ログローテーションの動作を微調整するために、-container-log-max-size と -container-log-max-files という 2 つのコマンドラインオプションが追加されました。
GracefulNodeShutdown 機能のゲートを有効にすると、Kubelet はノードをシャットダウンする際に、そのノードで実行されているポッドをグレースフリーに終了させようとします。実装は、systemd の抑制ロックをリスニングすることで動作します (Linux の場合)。
1.20のリリースについては、What's new in Kubernetesシリーズで詳しく紹介しています。
ポッドがhugepageのリクエストとリミットに関する情報をdownward API経由で取得できるようになりました。これにより、cpu、メモリ、ephemeral-storageなどの他のリソースとの一貫性が保たれます。
1.20のリリースについては、What's new in Kubernetesシリーズで詳しくご紹介しています。
現在、永続的なボリュームの問題はトラブルシューティングを行う事が困難です。ボリュームが存在するディスクが破損しているのか、あるいはボリュームがKubernetesの外で誤って削除されたのかを知るのは容易ではないことがあります。
このトラブルシューティングを支援するために、CSI APIが拡張され、ボリュームの健全性に関する情報を提供するために、既存のRPCを修正し、新しいRPCを追加しました。
CSIドライバは、ボリュームの健全性をチェックするサイドカーとして外部コントローラをロードすることができます。また、Kubeletがボリュームに関する情報を収集するために既に使用しているNodeGetVolumeStats関数に追加情報を提供することもできます。
KEPドキュメントで完全な実装の詳細を確認してください。
初期に Pod ボリュームトポロジー制約が実装されたとき (Kubernetes 1.13 以降のステーブル版)、十分な容量を持つノードで PersistentVolumes をスケジュールすることが目的でした。
しかし、10Giボリュームのリクエストがあり、2つのノードが十分な容量を持っているというシナリオを考えてみましょう。
どちらのボリュームも、リクエストにバインドされるチャンスは同じです。もし1Tiの方が選ばれたら、それはリソースの無駄遣いになります。
この問題を軽減するために、スケジューラのVolumeBinding設定に新しいScore戦略が用意されています。
設定すると、各PersistentVolumeClaimに対して、PersistentVolumesがスコアリングされ、最も適切なものが選択されます。アルゴリズムの詳細については、KEPドキュメントを参照してください。
新しい immutable フィールドが Secrets と ConfigMaps に追加されました。trueに設定すると、リソースキーに加えられた変更はすべて拒否されます。これにより、アプリケーションを破壊するような偶発的な不正更新からクラスターを保護することができます。
不変的なリソースからは2つの利点があります。リソースが変更されないため、Kubeletはリソースの更新を定期的にチェックする必要がなく、スケーラビリティとパフォーマンスを向上させることができます。
詳しくは、What's new in Kubernetesシリーズの1.18のリリースをご覧ください。
この機能強化は、十分な空き容量が利用できないCSIボリュームに接続されたノードでポッドがスケジューリングされるのを防ごうとするものです。
詳しくはWhat's new in Kubernetesシリーズの1.19のリリースをご覧ください。
この機能拡張は、ダイナミックプロビジョニングをサポートする任意のストレージドライバーで動作するインラインエフェメラルボリュームを定義するためのシンプルなAPIを提供します。
詳しくは、What's new in Kubernetesシリーズの1.19のリリースをご覧ください。
この機能強化は、Azure FileのコードをKubernetesのメインバイナリー（アウトオブツリー）から移動させる作業をまとめたものです。
これは、既存のコードをCSIドライバーに移行し（#178, #625, #1490）、Kubernetesのコードを保守しやすくするための継続的な取り組みの一環です。
この機能拡張により、CSIドライバーはKubeletからNodePublishVolume関数にサービスアカウントトークンを要求できるようになります。また、Kubeletはどのドライバーがどのトークンを利用できるかを制限できるようになります。そして最後に、ドライバーは RequiresRepublish を true に設定することで、NodePublishVolume を再実行してボリュームを再マウントすることができるようになります。
この最後の機能は、マウントされたボリュームが期限切れになることがあり、再ログインが必要な場合に便利です。例えば、secrets vaultのような場合です。
詳しくは、What's new in Kubernetesシリーズの1.20のリリースをご覧ください。
client-goベースのKubernetes APIクライアントがサーバ側のApplyを呼び出したい場合、Patchを呼び出してYAMLやJSONを含む[]byteを提供しなければなりません。
これは、型のチェックがないためエラーになりやすく、ペイロードにエラーがあると予期せぬ現象が発生する可能性があります。
この問題を解決するために、新しい Apply メソッドが実装されました。これは既存の Patch を補完するもので、開発者にとってより簡単で安全なものになります。
今後、kube-apiserver は再起動後にウォッチキャッシュをより速く初期化できるようになります。
詳しくはWhat's new in Kubernetesシリーズの1.20のリリースをご覧ください。
ネームスペースはKubernetes APIによって識別ラベルを持つことが保証されていないため、名前の代わりにフィールドセレクタを使ってネームスペースを選択する必要があります。これにより、Kubernetes APIでデフォルトのネットワークポリシーやその他のラベル駆動のネームスペース機能を書くといった作業が複雑になります。
新しい不変のラベルkubernetes.io/metadata.nameがすべてのネームスペースに追加され、その値はネームスペースの名前です。このラベルは、前述のNetworkPolicyオブジェクトのように、あらゆるネームスペースセレクタで使用することができます。
この機能拡張により、Goクライアントは、キーマネージメントシステム(KMS)、トラステッドプラットフォームモジュール(TPM)、ハードウェアセキュリティモジュール(HSM)などの外部のクレデンシャルプロバイダーを使用して認証できるようになります。
これらのデバイスは、すでに他のサービスに対する認証に使用されており、ローテートさせることが容易で、ディスク上にファイルとして存在しないため、より安全性が高くなっています。
当初、Kubernetes 1.10で導入されたこの機能は、1.20で行われた作業を引き継いでおり、Kubernetes 1.22ではGAとなる予定です。
ワークロードが API に対する認証に使用する現在の JSON Web Tokens (JWT) には、セキュリティ上の問題があります。この機能強化は、JWT のためのより安全な API を作成するための作業です。
詳しくは、What's new in Kubernetesシリーズの1.20のリリースをご覧ください。
Kubernetesのサービスアカウント（KSA）は現在、Kubernetes APIに対する認証にJSON Web Tokens（JWT）を使用することができ、例えばkubectl -token <the_token_string>を使用します。今回の機能強化により、クラスター外のサービスが、APIサーバーに負荷をかけることなく、これらのトークンを一般的な認証方法として使用できるようになります。
1.18のリリースについては、What's new in Kubernetesシリーズでご紹介しています。
Kubernetes 1.21から、kubectlはAPIサーバへのリクエストに追加のHTTPヘッダを含めるようになりました。どのkubectlコマンドが特定のリクエストを引き起こしたかを知ることで、管理者はトラブルシューティングやベストプラクティスの実施に役立つ情報を得ることができます。
これらの追加ヘッダーは：
現在は、最初に実行されるコンテナがPodのデフォルトコンテナとされています。しかし、Service Meshでは、Podは常に2つのコンテナを持つことができます。メインのコンテナと、最初に実行されるサイドカーです。
これにより、kubectlログから情報を読み取ったり、kubectl execを使用したりするなど、いくつかの管理作業が複雑になります（-cフラグがないとデフォルトコンテナを使用してしまうため）。
新しい kubectl.kubernetes.io/default-container アノテーションが Pod に追加され、デフォルトのコンテナを定義できるようになりました。
#1885 で議論したように、クラウドプロバイダーに特化したコードを Kubernetes のコアコードの外に移動させようという積極的な取り組みが行われています (in-tree から out-of-tree へ)。
しかし、この破壊的な変更は、コントロールプレーンの可用性に厳しい要件を持つクラスターにとっては問題となります。
今回の機能強化では、そのようなクラスターのための移行プロセスを確立し、kube-controller-managerの実行からcloud-controller-managerの実行への移行に焦点を当てています。
詳細はKubernetesのドキュメントを参照してください。
現在、Kubernetes は複数のビルドシステムを維持しており、必要なメンテナンスが増え、摩擦や混乱の原因となっています。
この機能強化は、すべてのビルドスクリプトをmake buildに移行し、bazel buildを削除するために行われた作業をまとめたものです。
以上、Kubernetes 1.21についてご紹介しました。これらの機能のいずれかを使用するつもりであれば、クラスターのアップグレードの準備をしてください。
この記事が気に入ったら、以前の「What's new in Kubernetes（Kubernetesの新機能）」もチェックしてみてください。
また、Kubernetesエコシステムの最新情報を楽しみたい方は、クラウドネイティブエコシステムで起こっている最もクールな事を毎月メールでお届けするコンテナニュースレターをご購読ください。