1.4. 主な技術上の変更点
OpenShift Container Platform 4.15 では、次の注目すべき技術的な変更が導入されています。
クラスターメトリクスポートの保護
このリリースでは、Cluster Machine Approver Operator と Cluster Cloud Controller Manager Operator のメトリクスを提供するポートは、セキュリティーを強化するために Transport Layer Security (TLS) プロトコルを使用します。(OCPCLOUD-2272, OCPCLOUD-2271)
Google Cloud Platform のクラウドコントローラーマネージャー
Kubernetes コミュニティーは、クラウドコントローラーマネージャーを使用することを優先して、基になるクラウドプラットフォームとやり取りするための Kubernetes コントローラーマネージャーの使用を非推奨にすることを計画しています。その結果、新しいクラウドプラットフォームの Kubernetes コントローラーマネージャーサポートを追加する計画はありません。
このリリースでは、Google Cloud Platform のクラウドコントローラーマネージャーの使用が一般公開されました。
クラウドコントローラーマネージャーの詳細は、Kubernetes Cloud Controller Manager のドキュメント を参照してください。
クラウドコントローラーマネージャーおよびクラウドノードマネージャーのデプロイメントおよびライフサイクルを管理するには、Cluster Cloud Controller Manager Operator を使用します。
詳細は、Cluster Operators リファレンス の Cluster Cloud Controller Manager Operator エントリーを参照してください。
Pod セキュリティーアドミッションの今後の限定的な適用
現在、Pod のセキュリティー違反は監査ログに警告として表示されますが、Pod は拒否されません。
現在、OpenShift Container Platform の次のマイナーリリースでは、Pod のセキュリティーアドミッションに対するグローバルな制限付きの適用が計画されています。この制限付きの適用が有効になっている場合、Pod セキュリティー違反のある Pod は拒否されます。
				この今後の変更に備えて、ワークロードが適用される Pod セキュリティーアドミッションプロファイルと一致していることを確認してください。グローバルまたはネームスペースレベルで定義された強制セキュリティー基準に従って設定されていないワークロードは拒否されます。restricted-v2 SCC は、制限付き Kubernetes の定義に従ってワークロードを許可します。
			
Pod のセキュリティー違反が発生している場合は、次のリソースを参照してください。
- Pod のセキュリティー違反の原因となっているワークロードを見つける方法の詳細は、Pod のセキュリティー違反の特定 を参照してください。
 Pod セキュリティーアドミッションラベルの同期が実行されるタイミングを理解するには、Pod セキュリティーアドミッション同期について を参照してください。Pod セキュリティーアドミッションラベルは、次のような特定の状況では同期されません。
- 
								ワークロードは、
openshift-で始まるシステム作成の namespace で実行されています。 - ワークロードは、Pod コントローラーなしで直接作成された Pod で実行されています。
 
- 
								ワークロードは、
 - 
						必要に応じて、
pod-security.kubernetes.io/enforceラベルを設定して、namespace または Pod にカスタムアドミッションプロファイルを設定できます。 
統合された OpenShift Image Registry が無効になっている場合はシークレットが自動的に生成されなくなる
				ImageRegistry クラスター機能を無効にするか、Cluster Image Registry Operator の設定で統合された OpenShift Image Registry を無効にすると、サービスアカウントトークンシークレットとイメージプルシークレットは、サービスアカウントごとに生成されなくなります。
			
詳細は、自動生成されたシークレット を参照してください。
Open Virtual Network Infrastructure Controller のデフォルト範囲
				この更新により、コントローラーはトランジットスイッチサブネットのデフォルトの IP アドレス範囲として 100.88.0.0/16 を使用します。実稼働インフラストラクチャーネットワークでは、この IP 範囲を使用しないでください。(OCPBUGS-20178)
			
HAProxy no strict-limits の導入
				HAProxy 2.6 への移行には、strict-limits 設定の強制が含まれており、その結果、maxConnections 要件が満たされない場合に回復不能なエラーが発生しました。strict-limits 設定はエンドユーザーによって設定できず、HAProxy テンプレートの制御下に残ります。
			
				このリリースでは、移行に応じて maxConnections 問題への設定の調整が導入されています。これで、HAProxy 設定は no strict-limits を使用するように切り替わりました。その結果、maxConnection 設定が満たされない場合に、HAProxy が回復不能な形で終了することがなくなりました。代わりに、警告を発し、実行を継続します。maxConnection の制限が満たされない場合、次の例のような警告が返される場合があります。
			
- 
						
[WARNING] (50) : [/usr/sbin/haproxy.main()] Cannot raise FD limit to 4000237, limit is 1048576. - 
						
[ALERT] (50) : [/usr/sbin/haproxy.main()] FD limit (1048576) too low for maxconn=2000000/maxsock=4000237.Please raise 'ulimit-n' to 4000237 or more to avoid any trouble. 
				これらの警告を解決するには、IngressController を調整するときに maxConnections フィールドに -1 または auto を指定することを推奨します。この選択により、HAProxy は実行中のコンテナーで利用可能なリソースの制限に基づいて最大値を動的に計算できるようになり、これらの警告が表示されなくなります。(OCPBUGS-21803)
			
DeploymentConfig クラスター機能が無効になっている場合に、deployer サービスアカウントが作成されなくなる
				DeploymentConfig クラスター機能を無効にすると、deployer サービスアカウントとそれに対応するシークレットは作成されなくなります。
			
詳細は、DeploymentConfig 機能 を参照してください。
must-gather ストレージ制限のデフォルト
				oc adm must-gather コマンドによって収集されるデータには、コンテナーノードのストレージ容量の 30% というデフォルト制限が追加されました。必要に応じて、--volume-percentage フラグを使用して、デフォルトのストレージ制限を調整できます。
			
詳細は、must-gather ストレージ制限の変更 を参照してください。
エージェントベースのインストーラーの対話型ネットワーク設定がシリアルコンソールに表示される
この更新により、グラフィカルコンソールのないサーバーで Agent ISO が起動される場合、シリアルコンソールで対話型ネットワーク設定が可能になります。対話型ネットワーク設定がアクティブな間は、他のすべてのコンソールではステータス表示が一時停止されます。以前は、グラフィカルコンソールでのみ表示できました。(OCPBUGS-19688)