Red Hat OpenShift 4.16：知っておくべきこと

Red Hat OpenShift 4.16 の一般提供が開始されました。Kubernetes 1.29 および CRI-O 1.29 に基づく OpenShift 4.16 は、通信およびエッジコンピューティング向けのコア、セキュリティ、仮想化などの各種機能に重点を置いています。Red Hat OpenShift は、信頼できる、一貫性のある包括的プラットフォームを通じて、ハイブリッドクラウド全体で先進的なアプリケーションの開発と提供を大規模に加速することを目的としています。

Red Hat OpenShift 4.14 以降は 3 年間のライフサイクル

アドオンのサブスクリプションとして利用可能です。Red Hat OpenShift 4.14 以降のすべての偶数番号のリリースに対して、12 カ月の Extended Update Support (EUS) の期間がオプションとして追加されました。これにより、Red Hat OpenShift のこれらの EUS リリースのライフサイクルは EUS の期間が 6 カ月であったところが 3 年まで延長されました。さらに詳しくは、Red Hat OpenShift Container Platform ライフサイクルポリシーを参照してください。

Red Hat Advanced Cluster Security Cloud Service でシフトレフトしてセキュリティを拡張する

Red Hat Advanced Cluster Security Cloud Service は、限定的な提供から一般提供へと変更されました。Red Hat Advanced Cluster Security Cloud Service は、Red Hat OpenShift と、Amazon EKS、Google GKE、Microsoft AKS などの Red Hat Kubernetes 以外のプラットフォームをサポートする、フルマネージドの Kubernetes ネイティブのセキュリティ・クラウドサービスです。このクラウドサービスにより、基盤となる Kubernetes プラットフォームに関係なく、ハイブリッドクラウド全体でクラウドネイティブ・アプリケーションの構築、デプロイ、維持にセキュリティ重視のアプローチを取ることができます。

AWS の自己管理型およびホスト型のコントロールプレーンで、コストを削減し、クラスタのデプロイ時間を最適化する

ホストされたコントロールプレーンは、バージョン 2.4 以降、Kubernetes Operator のマルチクラスタエンジン (MCE) でデフォルトで有効にされています。MCE バージョン 2.6 では、AWS のセルフマネージド型でホストされたコントロールプレーンが、Red Hat OpenShift 4.16 と共に一般提供されます。

ホストされたコントロールプレーンにより、複数の OpenShift クラスタを大規模に管理する上での効率性とコスト効果が向上します。コントロールプレーンの管理を一元化することで、リソース使用率の改善と保守の単純化が可能になります。ホストされたコントロールプレーンを使用すると、インフラストラクチャ・オーバーヘッドと管理オーバーヘッドを削減し、クラスタのデプロイ時間を最適化し、管理とワークロード間の懸念点を切り分けることができるため、アプリケーションに集中することができます。

ホストされたコントロールプレーンを使用する AWS 上の Red Hat OpenShift の外部認証サーバー

ホストされたコントロールプレーンを使用して、独自の OpenID Connect (OIDC) ソリューションを Red Hat OpenShift Service on AWS (ROSA) に導入できるようになりました。これにより、Kubernetes API サーバーで直接ユーザーやグループを認証できます。ROSA クラスタは AWS Security Token Service (STS) と OIDC を使用して、クラスタ内の Operator に必要な AWS リソースへのアクセスを付与します。詳細は、外部 OIDC を使用して ROSA クラスタへのアクセスを単純化する方法をご覧ください。

Admin Network Policy による OpenShift クラスタネットワークの保護

次世代の Kubernetes Network Policy が、ネットワークに OVN-Kubernetes を使用する OpenShift デプロイメントで完全にサポートされるようになりました。Admin Network Policy (グローバルネットワークポリシーとも呼ばれる) は、アップストリームの以前のネットワークポリシーの実装を拡張します。最もリクエストの多い機能は以下になります。

• namespace 管理者および開発者がオーバーライドできない、管理者専用のネットワークセキュリティポリシー。
• クラスター全体の範囲。たとえば、egress ポリシーを 1 カ所で 1 回だけ定義して、すべてのクラスタートラフィックに適用できる。
• 検査済みの特定のセキュリティポリシーを namespace 管理者と開発者に委任する機能により、アプリケーション開発に必要なネットワークポリシーの柔軟性を確保できる。

Admin Network Policy では、以下を可能にします。

• 管理者特権付きの制御でクラスタ内のテナントを分離する
• 常に動きのあるトラフィックの許可リストを作成する
• すべてのクラスターの egress トラフィックに対するイミュータブルなポリシーを指定する。たとえば、すべてのトラフィックにゲートウェイデバイスの通過を強制して検査を行うことができます。
• とくに機密性の高い namespace との間のトラフィックパターンを選択しやするするために、ネットワーク・トラフィック・ポリシーを細かく定義する

認証されていないユーザーまたはグループによるアクセスを削減する

OpenShift 4.16 から、system:anonymous ユーザーとsystem:unauthenticated グループに付与されるパーミッションに制限が適用されます。デフォルトでは、次の 2 つのロールのみが許可されます。

• system:openshift:public-info-viewer: OIDC ワークフローに必要
• system:public-info-viewer: クラスターに関する非機密情報への読み取り専用アクセス

これは新しいクラスターにのみ適用されます。アップグレードされたクラスターはこの影響を受けません。

匿名アクセスが必要なユースケースでは、クラスター管理者がそれらのパーミッションを明示的に追加する必要があります。たとえば、HTTP を介した auth トークンの送信がサポートされていない外部システム (GitHub など) から BuildConfig に Webhook を使用している場合は、system:webhook パーミッションを明示的に追加する必要があります。このようなシナリオでは、 clusterrole バインディングではなくローカルのロールバインディングを使用することを強くお勧めします。クラスター管理者は、関連するリスクとメリットを評価した後、必要に応じて匿名ユーザーに ClusterRoleBinding を追加できます。

oc adm upgrade status で OpenShift 更新のトラブルシューティングを容易にする

Red Hat OpenShift 4.16 には新しい oc adm upgrade status コマンドが含まれており、テクノロジープレビューとして利用できます。このコマンドはクラスターの更新状況を表示して無関係なノイズを除去し、管理者に更新が正常に行われているか、または介入が必要かどうかを示します。更新の問題が発生した場合、 コマンドは、発生している状況に関する情報を返し、その情報にはガイダンスと関連リソース (Red Hat のドキュメントやナレッジベースの記事など) へのリンクも含まれます。

# oc adm upgrade status An update is in progress for 55m7s: Working towards 4.16.0: 198 of 951 done (20% complete) = Control Plane = Assessment: Progressing Completion: 97% Duration: 55m6.974951563s Operator Status: 36 Total, 36 Available, 1 Progressing, 0 Degraded = Worker Upgrade = = Worker Pool = Worker Pool: worker Assessment: Progressing Completion: 7% Worker Status: 42 Total, 22 Available, 20 Progressing, 39 Outdated, 19 Draining, 0 Excluded, 0 Degraded Worker Pool Node(s) NAME ASSESSMENT PHASE VERSION EST MESSAGE build0-gstfj-ci-builds-worker-b-25ptt Progressing Draining 4.16.0-ec.3 +30m build0-gstfj-ci-longtests-worker-b-ppxvc Progressing Draining 4.16.0-ec.3 +30m build0-gstfj-ci-prowjobs-worker-b-gvthg Progressing Draining 4.16.0-ec.3 +30m build0-gstfj-ci-tests-worker-b-7hvhq Progressing Draining 4.16.0-ec.3 +30m ...Omitted additional 32 Total, 3 Completed, 22 Available, 10 Progressing, 29 Outdated, 9 Draining, 0 Excluded, and 0 Degraded nodes.Pass along --details to see all information. = Update Health = SINCE LEVEL IMPACT MESSAGE 55m7s Info None Upgrade is proceeding well

Microsoft Entra Workload ID へのインプレース移行

Azure でセルフマネージド Red Hat OpenShift を使用している場合、最小限のダウンタイムで Microsoft Entra Workload ID (旧 Azure AD Workload Identity) に移行できます。Microsoft Entra Workload ID のサポートは Red Hat OpenShift 4.14で追加されました。これにより、お客様は一時的で制限付きの特権の資格情報を使用して Red Hat OpenShift クラスタを作成し、管理することができます。これで、新しいクラスタで最初からやり直すことなく、Microsoft Entra Workload ID を導入できるようになりました。詳細は、Microsoft Entra Workload ID を使用した OpenShift の設定方法を参照してください。

etcd のチューニングパラメーターを使用してクラスターのパフォーマンスを最適化する

これで、etcd を更新して、クラスターが etcd メンバー間のレイテンシーの減少を許容できるようになります。これを実行するには、 ハートビート間隔と リーダー選択タイムアウトのレイテンシー・パラメーターを、パフォーマンスと減少したレイテンシーを最適化する値に設定します。出力される可能性のある値は次のとおりです。

• "" (デフォルトはブランク)
• Standard
• Slower

これにより、低速だが許容可能なディスクや、OpenShiftのパフォーマンスとスケーラビリティーのベストプラクティスに該当するストレッチクラスターがあるシナリオに対応できます。

詳細については、etcd の仕様を参照してください。

ワークロードのニーズに応じてクラスタの自動スケーリングを最適化する

Cluster Autoscaler では、 LeastWaste、 Priority、および Random エキスパンダー戦略が使用されるようになりました。これらのエキスパンダーは、クラスターのスケーリング時のマシンセットの選択に影響を与えるように設定します。

• Random: ノードグループが同様のリソースを提供する同種のクラスター全体にワークロードを均等に分散する場合に推奨されます。
• LeastWaste：効率性とリソースの無駄の最小化が最優先事項であるクラスタ用。とくに迅速なスケーリングと柔軟性がより重要となる動的なワークロードで使用するクラスタ向けです。
• Priority: ユーザー定義の優先順位に基づいたスケーリングについての高度な意思決定を行う場合に適しています。さまざまなノードグループを持つ複雑なクラスターに適しています。

オンプレミスデプロイメントに独自のロードバランサーを使用可能

Red Hat OpenShift 4.16 を使用すると、ユーザーが管理する独自のロードバランサーを、任意のオンプレミス・インフラストラクチャ (ベアメタル、VMware vSphere、Red Hat OpenStack Platform、Nutanix など) 上のクラスタと組み合わせて使用できます。この設定では、クラスターの install-config.yaml ファイルで loadBalancer.type:UserManaged を指定します。この機能の詳細については、ユーザー管理ロードバランサー用のサービスを参照してください。

高度な監視とトラブルシューティングでクラスタの可観測性を向上させる

Red Hat OpenShift 4.16 では、可観測性機能が大幅に強化され、クラスタの監視、トラブルシューティング、最適化のための強化されたツールが提供されます。Prometheus、Thanos や新しいアラートルールなど、クラスター内モニタリング・スタックのコンポーネントに更新が加わりました。新しい Metrics Server はメトリックの収集を単純化し、新しい monitoring-alertmanager-view ロールはセキュリティとコラボレーションを強化します。これらの機能は、Cluster Observability Operator バージョン 0.3.0 に含まれており、可観測性をインストールして管理するための単一のエントリーポイント Operator として機能します。また、このリリースでは OpenTelemetry が改善され、Cluster Logging API の機能が強化されています。

Cluster Observability Operator に、可観測性シグナルを相互に関連付けるための　Observability Signal Correlation の新バージョン、重大 (Critical) なアラートの優先順位付けを行うためのインシデント検出、およびモノリシックなデプロイ向けの Tempo Operator サポートを使用して分散トレーシングを強化します。分散トレーシングのビジュアライゼーションが OpenShift コンソールに表示されるようになりました。

Observability Signal Correlation と Incident Detection はどちらも開発者プレビューで利用できます。Power monitoringは、テクノロジープレビューで利用可能ですが、開発者ユーザーインターフェース (UI) の統合を提供し、データの精度が向上しました。

Red Hat OpenShift Virtualization でインフラストラクチャ管理をモダナイズする

Red Hat OpenShift Virtualization に関しては、管理用の Red Hat Advanced Cluster Management for Kubernetes (RHACM) と共に Red Hat OpenShift Data Foundation にデプロイされたストレージを使用する仮想マシン (VM) 向けの、Metro 障害復旧の一般提供について発表しました 。

さらに、多数の VM の機能強化が追加されています。実行中の VM に、宣言形式で vCPU リソースを追加できるようになりました。安全なメモリー・オーバーコミットでメモリー密度が向上し、CPU ホットプラグで VM のスケールアップが容易になりました。

RHACM を使用して、マルチクラスター VM を監視できるようになりました。RHACM Hub から、複数の OpenShift クラスターにまたがるすべての VM を表示できます。すべての VM のレポートを収集し、すばやく作成できます。Global Hub Search を使用した RHACM Global Hub では、複数のハブにまたがるすべての VM を表示できます。

このエコシステムは、ハードウェアのパートナー、ストレージおよびネットワーク・インフラストラクチャのパートナー、またサードパーティのデータ保護プロバイダーと共に拡大し続けています。Veeam Kasten、Trilio、Storware に加えて、Cohesity、Commvault、Rubrik、Veritas からも今後の機能が提供される予定です。

Lifecycle Agent を使用したシングルノード OpenShift クラスタ向けのイメージベースのアップデート

Red Hat の通信パートナーは、無線アクセスネットワーク (RAN) 向けのコンテナの使用へ移行しており、シングルノードの OpenShiftにソリューションをデプロイしています。Red Hat OpenShift 4.16 は、イメージバースの更新 (IBU) による「シフトレフト」アプローチを特徴としています。IBU は、シングルノード OpenShift クラスターを更新するための代替方法を提供します。シングルノード OpenShift ユーザーは、更新プロセスの大部分を実稼働前環境に移行して、実稼働サイトでの更新に要する時間を短縮できます。

IBU では、z-stream 更新、マイナーバージョンの更新のほか、中間バージョンをスキップする直截の EUS から EUS への更新を実行できます。この更新メソッドは、Lifecycle Agent を利用して、新しい ostree stateroot としてターゲットのシングルノードの OpenShift クラスターにインストールされている専用の seed クラスターから OCI イメージを生成します。seed クラスターは、ターゲットの OpenShift Container Platform バージョン、デプロイされた Operator、すべてのターゲットクラスターに共通の設定を使用してデプロイされたシングルノードの OpenShift クラスターです。次に、seed イメージを使用して、seed クラスターと同じハードウェア、Operator、クラスター設定の組み合わせを持つ任意のシングルノードの OpenShift クラスターでプラットフォームのバージョンを更新します。

また、更新に失敗した場合、またはアプリケーションが機能する状態に戻らない場合は、更新前の状態にロールバックできます。 注記：これはシングルノードの OpenShift クラスターにのみ適用されます。これにより、更新が成功した場合も失敗した場合も、可能な限り迅速にサービスを復元できます。IBU は、Red Hat OpenShift GitOps と Red Hat Advanced Cluster Management を使用するゼロタッチプロビジョニングのフローにシームレスに統合されています。

自己完結型の OpenShift アプライアンスを大規模に構築する

自己完結型の OpenShift を搭載し、指定のハードウェアにサービスを追加して、カスタマイズしたターンキー型のアプライアンスを大規模に構築する予定のパートナーは、 OpenShift ベースの Appliance Builder を使用して構築することができます。これはテクノロジープレビューで利用可能です。OpenShift ベースの Appliance Builder は、複数の OpenShift クラスタのインストールに使用される、エージェントベースのインストーラーを含むディスクイメージの構築を実行するコンテナベースのユーティリティです。詳細については、OpenShift ベースの Appliance Builder ユーザーガイドを参照してください。

強化されたネットワーク、GitOps 管理、MicroShift 向けのシームレスな EUS アップデート

Red Hat ビルドの MicroShift について、最新リリースではエッジ管理を強化するための 3 つの更新が行われています。

1. 複数のネットワークインターフェースを Pod に接続する：MicroShift 用 Multus CNI：Multus では、Kubernetes Pod を複数のネットワークに接続できます。これは、SR-IOV を使用する場合や複雑な VLAN 設定がある場合に便利です。Microshiftで Multus を有効にすると、CNI プラグインブリッジ、 macvlan、または ipvlan を使用して、複数のインターフェースを Pod に簡単に追加できます。
2. MicroShift の GitOps でインフラストラクチャとアプリケーションの管理を自動化する：MicroShift の GitOps を使用すると、複数のクラスタと開発ライフサイクル全体で Kubernetes ベースのインフラストラクチャとアプリケーションを一貫して設定し、デプロイできます。MicroShift 向けに Argo CD を使用した GitOps は、Red Hat OpenShift GitOps Operator から派生した軽量の、オプションのアドオン・コントローラーです。MicroShift の GitOps は、Argo CD コマンドラインインターフェースを使用して、宣言型 GitOps エンジンとして機能する GitOps コントローラーと対話します。
3. MicroShift の直接的な EUS アップデート：MicroShift は、Extended User Support (EUS) バージョン 4.14 からバージョン 4.16 への直接アップデートを 1 回の再起動で行うことができます (バージョン 4.16 には Red Hat Enterprise Linux 9.4 が必要です)。

Red Hat OpenShift 4.16 を今すぐ試す

Red Hat Hybrid Cloud Console を今すぐ開始して、OpenShift の最新機能と拡張機能を活用してください。今後の最新情報については、次のリソースをご覧ください。

• Red Hat OpenShift の新機能と今後の予定
• OpenShift YouTube チャンネル
• OpenShift ブログ
• OpenShift Commons
• Red Hat Developer ブログ
• Red Hat Portfolio Architecture Center

Red Hat OpenShift 4.16 のアップデートの詳細リストは Red Hat OpenShift 4.16 リリースノートを参照してください。Red Hat の担当者を通じてフィードバックを送るか、OpenShift Commons Slack にメッセージを送信するか、GitHub で Issue を作成してください。