|
Kubernetes バージョン 1.19 がついに登場しました！これは2020年の2回目のリリースであり、これまでで最も長いリリースサイクル（合計20週間）です。33の機能強化が含まれています。そのうち12機能は安定版、18機能はベータ版、13機能はアルファ版です。 Kubernetesのサポート期間を1年に延長 2019年初頭に長期サポート（LTS）ワーキンググループが実施した調査では、Kubernetesユーザーのかなりの割合が、現在の9か月のサポート期間内にアップグレードできていないことが明らかになりました。この調査における他の回答と併せて考えると、パッチサポートを12～14か月に延長することで、30%のユーザーがサポート対象バージョンでのデプロイメントを維持できる可能性が示唆されます。これは、自作ディストリビューションと商用ディストリビューションの両方に当てはまります。したがって、サポート期間を延長することで、現在の50～60%ではなく、80%以上のユーザーがサポート対象バージョンを使用するようになります。年間サポート期間を設けることで、ユーザーには必要な余裕が生まれ、従来の年間計画サイクルとの整合性が向上します。Kubernetesバージョン1.19以降、サポート期間は1年間に延長されます。 ストレージ容量の追跡 従来、Kubernetesスケジューラは、追加の永続ストレージがクラスター内のどこにでも利用可能であり、その容量は無制限であるという前提で動作します。トポロジ制約は最初の点に対処しますが、これまでのPodスケジューリングでは、残りのストレージ容量が新しいPodを起動するのに不十分になる可能性を考慮していませんでした。新しいアルファ機能であるストレージ容量トラッキングは、CSIドライバにストレージ容量を報告するAPIを追加することでこの問題に対処します。このAPIは、KubernetesスケジューラがPodのノードを選択する際に使用されます。この機能は、ローカルボリュームや大容量制約のあるその他のボリュームタイプの動的な事前プロビジョニングをサポートするための基盤となります。 一般的な一時保管 Kubernetes は、ライフサイクルがポッドに結び付けられたボリュームプラグインを提供します。これらは、一時的なスペースとして使用することも（例：組み込みの `emptydir` ボリュームタイプ）、ポッドにデータをロードするために使用することもできます（例：組み込みの `configmap` および `secret` ボリュームタイプ）。新しい汎用ステージングボリュームのアルファ機能により、動的プロビジョニングをサポートする既存のストレージドライバーを、ライフサイクルがポッドに結び付けられた一時ボリュームとして使用できるようになります。これは、永続メモリやノード上の別のローカルディスクなど、ルートディスク以外の一時的なストレージを提供するために使用できます。ボリュームのプロビジョニングに使用されるすべての `StorageClass` パラメータがサポートされています。ストレージ容量の追跡、スナップショットと復元、ボリュームのサイズ変更など、`PersistentVolumeClaims` でサポートされているすべての機能がサポートされています。 CSIボリュームヘルスモニタリング CSIヘルスモニタリングのアルファ版は、Kubernetes 1.19でリリースされました。この機能により、CSIドライバーは基盤となるストレージシステムから異常なボリュームのヘルス情報をKubernetesと共有し、PVCまたはPodのイベントとして報告できるようになります。この機能は、Kubernetesがプログラムによる検出を実行し、個々のボリュームのヘルス問題を解決するための基盤となります。 Ingress が GA にアップグレードされました Ingress API の GA への移行についてですが、API 自体は長らくベータ版として運用されており、ユーザーやロードバランサー Ingress コントローラープロバイダーによる使用と採用により、既に事実上の GA 状態に達しています。完全な代替 API を用意することなく API を放棄することは、現実的なアプローチではありません。Ingress API は明らかに有用な API であり、様々なユースケースに対応しています。現時点では、現在の API をバージョン V1 として宣言し、コミュニティでサポートしながら、V2 Ingress API や、その上位互換の機能を持つ全く異なる API を開発していく方が賢明なアプローチと考えられます。 構造化ログ v1.19より前のKubernetesコントロールプレーンにおけるログ記録では、ログメッセージとログ内のKubernetesオブジェクトへの参照構造が統一されていませんでした。そのため、ログの解析、処理、保存、クエリ、分析が困難で、管理者と開発者はほとんどの場合、正規表現に基づく間に合わせのソリューションに頼らざるを得ませんでした。これらの問題により、ログベースの分析ソリューションの実装と保守は困難でした。 新しいklog法 このKubernetesリリースでは、klogライブラリに新しいアプローチが導入され、ログメッセージのフォーマットのためのより構造化されたインターフェースが提供されます。既存のフォーマットメソッド（Infof、Errorf）はそれぞれ、構造化されたメソッド（InfoS、ErrorS）と照合されるようになりました。新しいログ記録アプローチは、ログメッセージを最初の引数として、キーと値のペアのリストを2番目の引数として受け取ります。このアプローチにより、Kubernetes全体を新しいAPIに一括展開することなく、構造化されたログ記録を段階的に導入できます。 Kubelet クライアントの TLS 証明書のローテーション kubeletは、秘密鍵と証明書を使用してkube-apiserverを認証します。証明書は、kubeletの初回起動時に外部メカニズムを介して提供されます。Kubernetes v1.8以降、クラスターには初期の証明書/鍵ペアを取得し、証明書の有効期限が近づくとローテーションするプロセス（ベータ版）が組み込まれています。この機能はKubernetes v1.19で安定稼働しています。 kubeletの起動時に、ファイルシステムがスキャンされ、証明書マネージャーによって管理されている既存の証明書/鍵ペアが検索されます。利用可能な証明書/鍵が見つかった場合は、それがロードされます。見つからない場合、kubeletは設定ファイルまたはkubeconfig内のファイル参照内のエンコードされた証明書の値を確認します。証明書がブートストラップ証明書の場合、それを使用して鍵が生成され、証明書署名要求が作成され、APIサーバーに署名付き証明書が要求されます。 有効期限が近づくと、証明書マネージャーが適切な証明書の提供、新しい秘密鍵の生成、そして新しい証明書の要求を行います。kubeletは起動プロセスの一環として証明書の署名を要求し、kubeletからの証明書署名要求を継続的に自動的に承認するため、クラスターの管理が容易になります。 その他のアップデート 以下の機能が安定バージョンで利用できるようになりました。
主な変更点
その他の重要な変更点
発行ノート Kubernetes 1.19 リリースの詳細については、リリース ノート (https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.19.md) を参照してください。 可用性 Kubernetes 1.19はGitHub（https://github.com/kubernetes/kubernetes/releases/tag/v1.19.0）からダウンロードできます。Kubernetesを使い始めるには、インタラクティブなチュートリアル（https://kubernetes.io/docs/tutorials/）をご覧いただくか、KinD（Kubernetes in Docker）を使ってDockerコンテナの「ノード」を使ってローカルKubernetesクラスターを実行してください。kubeadmを使って1.19を簡単にインストールすることもできます。 リリースチーム このリリースは、技術的コンテンツと非技術的コンテンツの両方を提供してくれた数百人の人々の努力の成果です。HashiCorpのシニアデベロッパーアドボケートであるTaylor Dolezal氏が率いるリリースチームに特に感謝します。34名からなるリリースチームは、ドキュメント作成からテスト、検証、機能の完全性に至るまで、リリースのあらゆる側面を調整しました。 Kubernetesコミュニティの成長に伴い、私たちのリリースプロセスはオープンソースソフトウェア開発におけるコラボレーションの顕著な証となっています。Kubernetesは急速に新規ユーザーを獲得し続けています。この成長は正のフィードバックループを生み出し、より多くのコントリビューターがコードを提出することで、より活気のあるエコシステムを形成しています。現在、Kubernetesには49,000人を超える個人コントリビューターと、3,000人を超えるアクティブなコミュニティが存在します。 リリースロゴ このKubernetes 1.19バージョンのロゴに、みんなが感動しました！このバージョンはマラソンのようなもので、世界が荒々しい場所であっても、私たちは力を合わせれば素晴らしいことを成し遂げられるということを証明しています。
Kubernetes 1.19 リリースロゴ リリーステーマに「足跡重視 - ローカリゼーション」を選んだのは、世の中が好景気に沸いている中でも、リリースチームの前向きな姿勢を象徴しているからです。1.19のロゴに描かれているキャラクターたちは、エモな人から元気な人まで、リリースチーム全員の個性を表しています。 デザイナーについて：ハンナベス・ラーゲルレーフは、カリフォルニア州ロサンゼルスを拠点とするビジュアルデザイナーです。環境デザインとグラフィックデザインを幅広く経験しています。ハンナベスは、人と人との繋がりを育むアートとユーザーエクスペリエンスを創造しています。Twitterでは@emanate_designをフォローしてください。 長期的には このリリースは、これまでの機能アップデートとも異なります。従来は、機能リクエストから機能凍結まで3～4週間の期間があり、その後、貢献者は機能がサイクルに含まれるかどうかを確認できます。しかし、今回のリリースサイクルは独特で、同じマイルストーンを完了するまでに5週間かかります。この延長された期間により、貢献者は個々の機能の段階的移行について計画を立て、決定する時間をより多く確保できます。 機能実装における貢献者のマイルストーンは、通常の5週間から7週間に延長されました。貢献者は機能開発に40%長く取り組むことができ、疲労が軽減され、実装についてより深く考える時間を確保できます。また、土壇場での急ぎ作業も大幅に減少しました。今回のリリースサイクルにおける例外リクエストの数も減少し、前回のリリースサイクルでは14件でしたが、今回は6件となりました。 エコシステムのアップデート
プロジェクトのスピード Kubernetes DevStatsダッシュボード（https://k8s.devstats.cncf.io/d/12/dashboards?orgId=1）では、主要なコントリビューターの貢献度の詳細に加え、個々のコントリビューターからプルリクエストのライフサイクルまで、豊富な事前設定済みレポートを提供しています。KubernetesおよびCNCFコミュニティから数値、事実、データを収集したい場合、最適な出発点となります。 4月から8月までのリリースサイクルでは、382社と2,464人以上の個人がKubernetesに貢献しました。Kubernetesプロジェクトとコミュニティ全体のスピードに関する詳細は、DevStats（https://k8s.devstats.cncf.io/d/11/companies-contributing-in-repository-groups?orgId=1&var-period=m&var-repogroup_name=All&from=1585692000000&to=1598392799000）をご覧ください。 |
