カスタムエディションのアップグレード
「 kubectl 」プラグインを使用することで、Custom Edition をアップグレードできます。
「 Instana 」 kubectl プラグインと「 Instana Enterprise」オペレーターは、常にセットでリリースされます。 Instana のバックエンドの更新は、 Instana Enterpriseのオペレーターリリースとは独立しています。
Custom Editionをオンラインでアップグレードするには、 「Custom Editionのオンラインアップグレード」 を参照してください。
エアギャップ環境でのCustom Editionのアップグレードについては、 「エアギャップ環境でのCustom Editionのアップグレード」 を参照してください。
カスタムエディションの互換性一覧表
Custom Edition をインストール、アップグレード、または移行する前に、環境内のすべてのコンポーネントが互換性があることを確認することが重要です。 各カスタムエディションのバージョンは、特定のバージョンの Instana バックエンドのみをサポートしています。サポート対象外の組み合わせを使用すると、デプロイの失敗や予期しない動作を引き起こす可能性があります。 互換性マトリックスを使用すると、各Custom Edition バージョンでサポートされている Instana バックエンドのバージョンを確認できます。
デプロイメントを計画する際は、このマトリックスを使用して、 Custom Edition とバックエンドバージョンの有効な組み合わせを選択する必要があります。 この表は、以下の目的で使用してください:
- 選択したCustom Editionのバージョンと互換性のある Instana バックエンドのバージョンを確認してください
- インストールまたはアップグレードの前に、バージョンの組み合わせを確認してください
- サポート対象のターゲットバージョンを確認し、アップグレード計画を策定してください。
次の表に、互換性のあるCustom Edition のバージョンと Instana のバックエンドバージョンを示します。
| カスタムエディション版 | Instana バックエンドのバージョン |
|---|---|
| 1.11.x | 3.319 |
| 1.10.x | 3.317 |
| 1.9.x | 3.315 |
| 1.8.x | 3.313, 3.311, 3.309 |
| 1.7.x | 3.307, 3.305 |
| 1.6.x | 3.303, 3.301 |
| 1.5.x | 3.299 |
| 1.4.x | 3.297, 3.295 |
| 1.3.x | 3.293 |
| 1.2.x | 3.291, 3.289, 3.287 |
| 1.1.x | 3.285, 3.283, 3.281 |
前提条件
Instana をアップグレードする前に、以下の前提条件が満たされていることを確認してください:
- クラスターには十分なキャパシティがある。 クラスタがリクエスト容量に近づいている場合は、追加のノードを追加して、PodがPendingステータスで立ち往生しないようにします。
- Elasticsearch ノードには十分なディスク容量があります。 ディスク使用率が80%を超えると、 Elasticsearch ノードは自動的に読み取り専用モードに切り替わり、これによりアップグレードが停止したり、何のメッセージも表示されずに失敗したりする可能性があります。
- データストアのバージョンは、アップグレード先の Instana のバージョンと互換性があります。 データストアのバージョンについては、 「サードパーティ製データストアオペレータのインストール」 を参照してください。
アップグレード手順
「 Instana 」 kubectl プラグインと「 Instana Enterprise」オペレーターは、常にセットでリリースされます。 Instana のバックエンドの更新は、 Instana Enterpriseのオペレーターリリースとは独立しています。
Instana ( kubectl )プラグインを使用すると、サポートされている Instana バックエンドのバージョンを確認し、必要に応じてバックエンドを更新することができます。 Instana のバックエンドが最大4回リリースされた後、 Instana Enterpriseオペレーターの新しいバージョンがリリースされます。
オペレーターのアップグレード
Instana Enterprise オペレーターの新しいバージョンがリリースされた場合、以下の手順に従ってオペレーターをアップグレードできます:
Instana の kubectl プラグインの対象バージョンをインストールしてください。 「 Instana 」 kubectl プラグインと「 Instana Enterprise Operator」はバージョンが連動しているため、インストールするOperatorのバージョンと一致するプラグインをインストールしてください。 詳細については、 「 Instana kubectl プラグインのインストール」 を参照してください。
以下のいずれかの方法を使用してオペレーターをアップグレードします。この際、新しいオペレーターにはデフォルトの Instana バックエンドバージョンが適用されます:
注:
新しい YAML マニフェストを適用または生成するようにしてください。 既存の YAML マニフェスト内の画像バージョンを直接更新しないでください。 既存の YAML マニフェスト内のイメージバージョンを更新すると、 CustomResourceDefinition (CRD)の更新や、予期せぬエラーを引き起こす可能性のあるその他の変更を見逃してしまう恐れがあります。
特定のバージョンにアップグレードするには、いくつかの追加アクションを実行する必要がある場合があります。 「 アップグレードに関する注 」セクションを参照してください。 リリースをスキップするときは、必ずアップグレードノート(スキップしたバージョンとターゲットバージョンのアップグレードノートを含む)を考慮してください。
バックエンドのアップグレード
Instana のバックエンドを新しいバージョンにアップグレードするには、`` コマンド
versionsの以下のサブコマンドを使用できます。 すべてのコマンドには、オプションで--download-keyフラグがあります。 フラグを指定しない場合、既存のインストールのダウンロード・キーが使用されます。- この
identifyサブコマンドは、インストール済みのCustom Editionと互換性のある、現在利用可能な Instana バックエンドのバージョンの一覧を表示します。 - この
list-imagesサブコマンドは、 Instana Kubernetes オペレータおよびすべての Instana コンポーネントの画像一覧を表示します。--instana-versionフラグを使って演算子のバージョンを指定できます。 フラグを使用しない場合、利用可能なすべてのオペレーターのバージョンが表示され、バージョンを選択することができます。 updateコマンドは、既存のインストールを新しいバージョンにアップグレードします。--instana-versionフラグでアップグレード版を指定できます。 それ以外の場合は、サポートされているすべてのアップグレードバージョンが表示されます。 その後、バージョンを選択することができる。 あるいは、コア仕様でアップグレード先のバックエンドバージョンを設定し、その仕様を適用することもできます。以下のサンプルコードを参照してください。... spec: imageConfig: tag: 3.xxx.xxx-0 ...
- この
以下のコマンドを実行して、 Instana のバックエンドのアップグレードを確認してください:
kubectl get core -n instana-corekubectl get units -n instana-units
アップグレード時の注意事項
リリース固有の要件については、以下の注記を参照のこと。
1.11.x へのアップグレード
1.10.0 からのアップグレードには、特別な手順は必要ありません。
1.10.x へのアップグレード
1.9.0 からのアップグレードには、特別な手順は必要ありません。
1.9.x へのアップグレード
1.8.0 からのアップグレードには、特別な手順は必要ありません。
1.8.0 へのアップグレード
ClickHouse のデータストアをバージョン にアップグレード 25.8.6.11してください。 画像版をご利用ください 25.8.13.73-2-lts-ibm。
ClickHouseKeeper のデータストアをバージョン にアップグレード 25.8.6.11してください。 画像版をご利用ください 25.8.13.73-2-lts-ibm。
1.7.0 へのアップグレード
1.6.0 からのアップグレードには、特別な手順は必要ありません。
1.6.0 へのアップグレード
1.5.0 からのアップグレードには、特別な手順は必要ありません。
1.5.0 へのアップグレード
Core Secret で downloadKey 以前から非推奨となっていた機能が削除されました。 現在は「Unit Secret」からのみ読み込まれます。 Core Secret に が含まれている downloadKey インストール環境がまだある場合は、そのインストール環境を更新し、Unit Secret に移動させる必要があります。
ユニットシークレットの設定については、 「ユニットシークレット」 を参照してください。
1.4.0 へのアップグレード
1.3.0 からのアップグレードには、特別な手順は必要ありません。
1.3.0 へのアップグレード
1.3.0 にアップグレードする前に、以下の作業を完了してください:
Instana Enterprise Operatorと Webhook の展開におけるイメージ構成は、それぞれ別々に設定されます。 新しい Instana Enterprise オペレーター設定オプションを参照し、 kubectl プラグインのカスタム値ファイルを更新してください。
(任意): カスタムエディション環境において、新しいゲートウェイコントローラーでインバウンドトラフィックを管理するように設定する場合は、以下の設定変更を行ってください:
- ゲートウェイ・コントローラーを有効にしてください。詳細については、「ゲートウェイの設定」 を参照してください。
- Gatewayロードバランサーのセレクタラベルを、
.spec.selector["app.kubernetes.io/component"]: gateway以下の例に示す内容に更新してください:
apiVersion: v1 kind: Service metadata: namespace: instana-core name: loadbalancer-gateway spec: type: LoadBalancer ... selector: ... app.kubernetes.io/component: gateway-v2 ...この更新は、着信トラフィックが新しい Gateway-v2 コンポーネントのポッドに確実に転送されるようにするためです。
ClickHouse のデータストアをバージョン 24.8.x にアップグレードします。 画像版をご利用ください
24.8.12.28-5-lts-ibm。Elasticsearch のデータストアをバージョン 8.x にアップグレードします。 データストアをアップグレードする際は、サービスの中断を防ぐために、以下の例に示すように Elasticsearch の設定を更新してください:
次のように置き換えてください。
config:
node.master: true
node.data: true
node.ingest: true
上記の行を、次の行に置き換えます。
config:
node.roles:
- master
- data
- ingest
また、アップグレード時のエラーを防ぐため、アップグレード後のイメージバージョンに合わせて、 8.15.3_v0.15.0Elasticsearchspec.version のマニフェスト内の を更新してください。
1.2.0 へのアップグレード
1.2.0 にアップグレードする前に、以下の作業を完了してください:
- カスタム
ClickHouseInstallationリソースの「profiles」セクションにdefault/allow_experimental_analyzer: "0"以下を追加して、クエリアナライザーを無効にしてください。 - ClickHouse のデータストアをバージョン 24.3 にアップグレードします。 画像版を使用してください
24.3.12.75-lts-ibm。
24.3.12.75-lts-ibmにアップグレードしないでください。 その代わりに、引き続き画像バージョン を使用してください 23.3.2.37-4-lts-ibm。1.0.0 より古いバージョンからアップグレードする場合は、バージョンスキーマの変更点および「 kubectl 」プラグインの管理方法の変更点を確認してください。
1.1.0 へのアップグレード
リリース 1.0.0 からのアップグレードに特別な手順は必要ありません。
1.0.0 より古いバージョンからアップグレードする場合は、バージョンスキーマの変更点および「 kubectl 」プラグインの管理方法の変更点を確認してください。
1.0.0 へのアップグレード
一般的なアップグレードに関する注意事項とバージョン体系が変更されました。 ただし、Build 1.0.0 向けの Instana バックエンドの更新については、特別な手順は必要ありません。
リリース277へのアップグレード
リリース273以前からアップグレードする場合は、リリース 275 へのアップグレード。 リリース 275 以降にアップグレードする場合、特別な手順は必要ありません。
リリース275へのアップグレード
Instana リリース 275 以降、 ClickHouse データベース logs に新しいテーブルが導入されました。このテーブルは、 ClickHouse のTTLメカニズムを利用して、時間の経過とともにデータをコールドストレージへ自動的に移動させ、必要に応じてデータを削除します。
ClickHouse データストア設定を更新して、release-275 マイグレーションを適用する必要があります。
以下の手順を実行します。
- Core仕様を更新して、
maintenanceInstana のバックエンドをモードに設定します:kubectl patch core <core_name> -n <core_namespace> --type='merge' -p='{"spec": {"operationMode": "maintenance"}}' 以下の設定をClickHouseInstallationリソース:
<disks>で新規cold_diskを定義し、logs_policy_v4という名前の新規ポリシーを作成し、その新規ポリシーでcold_diskを参照します。config.d/storage.xml: | <clickhouse> <storage_configuration> <disks> <default/> <cold_disk> <path>/var/lib/clickhouse-cold/</path> </cold_disk> </disks> <policies> <logs_policy> <volumes> <data> <disk>default</disk> </data> <cold> <disk>cold_disk</disk> </cold> </volumes> </logs_policy> <logs_policy_v4> <volumes> <tier1> <disk>default</disk> </tier1> <tier2> <disk>cold_disk</disk> </tier2> </volumes> </logs_policy_v4> </policies> </storage_configuration> </clickhouse>ClickHouseが
cold_diskの追加PVCを作成するために使用できる新しいvolumeClaimTemplateを定義します:volumeClaimTemplates: ... ... - name: instana-clickhouse-data-cold-volume spec: accessModes: - ReadWriteOnce resources: requests: storage: 100Gi # storageClassName: <lower_or_cheaper_tier_storageclassname>最後に、
podTemplatesでvolumeMountsを定義して、 ClickHouse ポッドに新規ボリュームをマウントします。containers: - name: instana-clickhouse ... ... volumeMounts: - mountPath: /var/lib/clickhouse-cold/ name: instana-clickhouse-data-cold-volume「 ClickHouseInstallation 」のリソース( YAML )の全文については、以下をご覧ください:
release-275 へのアップグレードを進める前に、新しい変更を適用した後に ClickHouse のステータスが
Completedになっていることを確認してください。 以下のコマンドを使用します。% kubectl get clickhouseinstallation -n instana-clickhouse NAME CLUSTERS HOSTS STATUS AGE instana 1 2 Completed 4d1h
Core仕様を更新して、
normalInstana のバックエンドをモードに戻します:kubectl patch core <core_name> -n <core_namespace> --type='merge' -p='{"spec": {"operationMode": "normal"}}'- アップグレード手順に従って、 Instana 275 にアップグレードしてください。
リリース273へのアップグレード
アップグレードに特別なステップは必要ありません。