マルチクラスター環境が成熟すると、複数のクラスターに特定のワークロードが存在することが一般的な状況です。 クラスターをフリートに追加する理由の 1 つは、ワークロードの管理を一元化して、複数のクラスターにわたるワークロードの可視性と管理性を向上することです。 ただし、既存のワークロードを持つクラスターをフリートに追加すると、Fleet Manager が追加されたメンバー クラスターにマネージド ワークロードを配置しようとすると、配置の競合が発生する可能性があります。
この記事では、クラスター リソース配置 (CRP) でapplyStrategy
の whenToTakeOver
プロパティを使用して、配置の実行時に Fleet Manager が既存のワークロードを処理する方法を明示的に制御する方法について説明します。
注
Fleet Manager のクラスター リソース配置 (CRP) にまだ慣れていない場合は、この記事を読む前に 、リソース配置の概念の概要 をお読みください。
重要
Azure Kubernetes Fleet Manager のプレビュー機能は、セルフサービス、オプトイン ベースで利用できます。 プレビューは、"現状有姿のまま" および "利用可能な限度" で提供され、サービス レベル アグリーメントおよび限定保証から除外されるものとします。 Azure Kubernetes Fleet Manager のプレビューは、ベストエフォート ベースでカスタマー サポートによって部分的にカバーされます。 そのため、これらの機能は、運用環境での使用を意図していません。
データ プレーンのプレビューは、v1beta1 API を介してリリースされます。 プレビュー オブジェクトが表示されない場合は、Fleet Manager ハブ クラスターを操作するときに v1beta1 API を要求していることを確認します。
ワークロードの引き継ぎオプション
ワークロードの引き継ぎの開始点は、ワークロード マニフェストを Fleet Manager ハブ クラスターにデプロイすることです。 デプロイしたら、 whenToTakeOver
プロパティを使用して明示的な引き継ぎ動作を指定する CRP を定義します。
whenToTakeOver
プロパティでは、次の値を使用できます。
Always
: Fleet Manager は、ハブ クラスターから対応するワークロードを直ちに適用し、マネージド フィールドの値の違いはすべてターゲット クラスターで上書きされます。 この動作は、明示的なwhenToTakeOver
設定のない CRP の既定値です。IfNoDiff
: Fleet Manager は、既存のワークロードが見つかった場合に構成の違いを確認し、構成の違いが見つからない場合にのみハブ クラスター ワークロードを適用します。Never
: Fleet Manager は既存のワークロードを無視し、ハブ クラスターのワークロードは適用しません。 フリートマネージャーは引き続き一致するワークロードを識別し、適用エラーを通知することにより、既存のワークロードが存在するかどうかを安全に確認できます。
比較に使用するフィールドを定義する
オプションの comparisonOptions
プロパティを使用して、 whenToTakeOver
が構成の違いを判断する方法を微調整できます。
partialComparison
: 値の比較には、ハブ クラスター ワークロードとターゲット クラスター ワークロードに存在するフィールドのみが使用されます。 ターゲット クラスター ワークロードの追加のアンマネージド フィールドは無視されます。 この動作は、明示的なcomparisonOptions
設定のない CRP の既定値です。fullComparison
: Fleet ハブ クラスター上のワークロード定義のすべてのフィールドは、選択したメンバー クラスターに存在する必要があります。 ターゲット クラスターに追加のアンマネージド フィールドがある場合、比較は失敗します。
競合するワークロードを確認する
CRP の既存のワークロードを確認するには、サンプルに示すように、whenToTakeOver
の値を Never
に設定したapplyStrategy
を追加することから始めます。
apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ClusterResourcePlacement
metadata:
name: web-2-crp
spec:
resourceSelectors:
- group: ""
kind: Namespace
version: v1
labelSelector:
matchLabels:
app: web-2
policy:
placementType: PickAll
strategy:
applyStrategy:
whenToTakeOver: Never
type: RollingUpdate
rollingUpdate:
maxUnavailable: 100%
unavailablePeriodSeconds: 1
Fleet Manager ハブ クラスターに CRP を適用します。
kubectl apply -f web-2-crp.yaml
Fleet Manager はワークロードの配置を試み、ターゲット メンバー クラスターで一致するワークロードが見つかると、 failedPlacement
応答を返します。
次のコマンドを使用して、ワークロードの競合が原因で配置に失敗したメンバー クラスターを特定できます。 jq コマンドは、出力のフォーマットに使用されます。
kubectl get clusterresourceplacement.v1beta1.placement.kubernetes-fleet.io web-2-crp -o jsonpath='{.status.placementStatuses}' \
| jq '[.[] | select (.failedPlacements != null)] | map({clusterName, failedPlacements})'
既存のワークロードが原因で配置に失敗した各クラスターは、次のサンプルのようなエントリを返します。
{
"clusterName": "member-2",
"failedPlacements": [
{
"condition": {
"lastTransitionTime": "...",
"message": "Failed to apply the manifest (error: no ownership of the object in the member cluster; takeover is needed)",
"reason": "NotTakenOver",
"status": "False",
"type": "Applied"
},
"kind": "Namespace",
"name": "web-2",
"version": "v1"
}
]
}
一致するワークロードを安全に引き継ぐ
既存のワークロードの引き継ぎを続行するには、既存の CRP を変更し、 whenToTakeOver
を IfNoDiff
に変更します。
Fleet Manager は、両方のワークロードのマネージド フィールド間に違いがないターゲット クラスター上の既存のワークロードの代わりにハブ クラスター ワークロードを適用します。 追加のフィールドは無視されます。
apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ClusterResourcePlacement
metadata:
name: web-2-crp
spec:
resourceSelectors:
- group: ""
kind: Namespace
version: v1
labelSelector:
matchLabels:
app: web-2
policy:
placementType: PickAll
strategy:
applyStrategy:
whenToTakeOver: IfNoDiff
comparisonOption: partialComparison
type: RollingUpdate
rollingUpdate:
maxUnavailable: 100%
unavailablePeriodSeconds: 1
Fleet Manager ハブ クラスターに CRP を適用します。
kubectl apply -f web-2-crp.yaml
Fleet Manager はワークロードの配置を試み、フィールドが一致するターゲット メンバー クラスターを上書きします。
配置は引き続き失敗する可能性があるため、追加の failedPlacement
メッセージがないか確認してください。 次のコマンドを使用して、失敗したメンバー クラスターを特定します。
jq コマンドは、出力のフォーマットに使用されます。
kubectl get clusterresourceplacement.v1beta1.placement.kubernetes-fleet.io web-2-crp -o jsonpath='{.status.placementStatuses}' \
| jq '[.[] | select (.failedPlacements != null)] | map({clusterName, failedPlacements})'
構成の違いにより配置に失敗した各クラスターは、次のサンプルのようなエントリを返します。
{
"clusterName": "member-2",
"failedPlacements": [
{
"condition": {
"lastTransitionTime": "...",
"message": "Failed to apply the manifest (error: cannot take over object: configuration differences are found between the manifest object and the corresponding object in the member cluster)",
"reason": "FailedToTakeOver",
"status": "False",
"type": "Applied"
},
"kind": "Namespace",
"name": "work-2",
"version": "v1"
}
]
}
ドリフトフィールドの表示は、ドリフト検出ドキュメントの 「ドリフトクラスターに関するレポート 」セクションで詳しく説明されているプロセスに従うことで実現できます。
この時点で、メンバー クラスターの変更をハブ クラスター ワークロード定義に含めるか、 whenToTakeOver
プロパティを Always
に設定してメンバー クラスター ワークロードを上書きすることを選択して、ドリフトを処理する方法を決定する必要があります。
次のステップ
Azure Kubernetes Service