5.3. 新しい Operator SDK バージョンのプロジェクトのアップグレード
OpenShift Container Platform 4.9 は Operator SDK v1.10.1. をサポートします。ワークステーションに v1.8.0 CLI がすでにインストールされている場合は、最新バージョンをインストール して CLI を v1.10.1 にアップグレードできます。
ただし、既存の Operator プロジェクトが Operator SDK v1.10.1 との互換性を維持するには、v1.8.0 以降に導入された関連する重大な変更に対し、アップグレード手順を実行する必要があります。アップグレードの手順は、以前は v1.8.0 で作成または維持されている Operator プロジェクトのいずれかで手動で実行する必要があります。
5.3.1. Operator SDK v1.10.1 のプロジェクトのアップグレード
v1.10.1 との互換性を確保して既存の Operator プロジェクトをアップグレードするには、以下のアップグレード手順を実行する必要があります。
前提条件
- Operator SDK v1.10.1 がインストールされている
- 以前に Operator SDK v1.8.0 で作成または維持された Operator プロジェクト
手順
Ansible ベースの Operator プロジェクトの場合は、
molecule/default/prepare.ymlファイルのSet pull policyセクションでコマンドを更新します。例5.1
molecule/default/prepare.ymlファイルの差分- name: Set pull policy - command: '{{ "{{ kustomize }}" }} edit add patch pull_policy/{{ "{{ operator_pull_policy }}" }}.yaml' + command: '{{ "{{ kustomize }}" }} edit add patch --path pull_policy/{{ "{{ operator_pull_policy }}" }}.yaml'Ansible プロジェクトは Kustomize バージョン 3.8.7 でスキャフォールディングされるようになりました。このバージョンの Kustomize では、
add patchコマンドの--pathフラグを指定してパッチファイルのパスを指定する必要があります。
Operator プロジェクトは Operator SDK v1.10.1 との互換性が確保されました。
5.3.2. 既知の問題
-
ansible-operatorバイナリーでは、サーバー URL にパスが含まれる場合にkubeconfigファイルが拒否されます。現時点で、Operator をクラスター内の Pod として実行する以外に、回避策はありません。この場合には、内部エンドポイントが使用されます。現時点では、この問題の修正は、apimachineryパッケージの修正待ちで、ブロックされています。詳細は、operator-framework/operator-sdk#4925 を参照してください。
