**このページの改善にご協力ください** 

このユーザーガイドに貢献するには、すべてのページの右側のペインにある「**GitHub でこのページを編集する**」リンクを選択してください。

# kro 機能に関する問題をトラブルシューティングする
<a name="kro-troubleshooting"></a>

このトピックでは、機能ヘルスチェック、RBAC アクセス許可、CEL 式エラー、リソース構成の問題など、EKS Capability for kro をトラブルシューティングする際のガイダンスを提供します。

**注記**  
EKS の機能は完全に管理され、クラスターの外部で実行されます。コントローラーログや `kro-system` 名前空間にアクセスすることはできません。トラブルシューティングでは、機能のヘルス、RBAC の設定、リソースのステータスに焦点を当てています。

## 機能は ACTIVE だが、ResourceGraphDefinitions が機能していない
<a name="_capability_is_active_but_resourcegraphdefinitions_arent_working"></a>

kro 機能のステータスが `ACTIVE` なのに、ResourceGraphDefinitions が基盤となるリソースを作成していない場合は、機能ヘルス、RBAC アクセス許可、リソースステータスを確認してください。

 **機能のヘルスを確認する**:

機能のヘルスとステータスの問題は、EKS コンソールまたは AWS CLI を使用して表示できます。

 **コンソール:**

1. https://console.aws.amazon.com/eks/home\#/clusters で Amazon EKS コンソールを開きます。

1. クラスター名を選択します。

1. **[オブザーバビリティ]** タブを選択します。

1. **[クラスターを監視する]** を選択します。

1. **[機能]** タブを選択すると、すべての機能のヘルスとステータスが表示されます。

 **AWS CLI**:

```
# View capability status and health
aws eks describe-capability \
  --region region-code \
  --cluster-name my-cluster \
  --capability-name my-kro

# Look for issues in the health section
```

 **一般的な原因:**
+  **RBAC アクセス許可がない**: kro には、基盤となる Kubernetes リソースを作成するアクセス許可がありません
+  **無効な CEL 式**: ResourceGraphDefinition に構文エラーがあります。
+  **リソースの依存関係**: 依存するリソースの準備ができていません。
+  **スキーマ検証**: インスタンスが RGD スキーマの要件と一致していません。

 **RBAC アクセス許可の確認**:

```
# Check if capability has cluster admin policy
kubectl get accessentry -A | grep kro
```

機能に必要なアクセス許可がない場合は、`AmazonEKSClusterAdminPolicy` を kro 機能のアクセスエントリに関連付けるか、本番稼働用のより制限の厳しい RBAC ポリシーを作成します。詳細については、「[kro アクセス許可の設定](kro-permissions.md)」を参照してください。

 **ResourceGraphDefinition のステータスの確認**:

```
# List all RGDs
kubectl get resourcegraphdefinition

# Describe specific RGD
kubectl describe resourcegraphdefinition my-rgd

# Check for validation errors
kubectl get resourcegraphdefinition my-rgd -o jsonpath='{.status.conditions}'
```

ResourceGraphDefinitions には 3 つの主要なステータス条件があります。
+  `ResourceGraphAccepted` - RGD が検証 (CEL 構文、型チェック、フィールドの存在) に合格したかどうか
+  `KindReady` - カスタム API の CRD が生成され、登録されたかどうか
+  `ControllerReady` - kro がカスタム API のインスタンスをアクティブに監視しているかどうか

`ResourceGraphAccepted` が `False` の場合は、不明なフィールド、型の不一致、循環依存関係などの検証エラーがないか、条件メッセージを確認します。

## インスタンスは作成されているが、基盤となるリソースが表示されない
<a name="_instances_created_but_underlying_resources_not_appearing"></a>

カスタムリソースインスタンスが存在するにもかかわらず、基盤となる Kubernetes リソース (デプロイ、サービス、ConfigMaps) が作成されていない場合は、kro にアクセス許可があることを確認し、構成エラーがないかを確認します。

 **インスタンスのステータスの確認**:

```
# Describe the instance (replace with your custom resource kind and name)
kubectl describe {{custom-kind}}
         {{my-instance}}

# View instance events
kubectl get events --field-selector involvedObject.name={{my-instance}}

# Check instance status conditions
kubectl get {{custom-kind}}
         {{my-instance}} -o jsonpath='{.status.conditions}'

# Check instance state
kubectl get {{custom-kind}}
         {{my-instance}} -o jsonpath='{.status.state}'
```

インスタンスには、高レベルのステータスを示す次の `state` フィールドがあります。
+  `ACTIVE` - インスタンスは正常に実行されています。
+  `IN_PROGRESS` - インスタンスは処理中または調整中です。
+  `FAILED` - インスタンスの調整に失敗しました。
+  `DELETING` - インスタンスを削除中です。
+  `ERROR` - 処理中にエラーが発生しました。

インスタンスには、次の 4 つのステータス条件もあります。
+  `InstanceManaged` - ファイナライザーとラベルが適切に設定されています。
+  `GraphResolved` - ランタイムグラフが作成され、リソースが解決されています。
+  `ResourcesReady` - すべてのリソースが作成され、準備完了です。
+  `Ready` - インスタンス全体のヘルス (すべてのサブ条件が `True`の場合にのみ `True` になります)。

インスタンスのヘルスを判断するには、`Ready` 条件に注目します。`Ready` が `False` の場合は、サブ条件を確認して、どのフェーズで失敗したかを特定します。

 **RBAC アクセス許可の確認**:

kro 機能には、ResourceGraphDefinitions で定義されている基盤となる Kubernetes リソースを作成するためのアクセス許可が必要です。

```
# Check if the capability has the AmazonEKSClusterAdminPolicy
kubectl get accessentry -A | grep kro
```

アクセス許可がない場合は、`AmazonEKSClusterAdminPolicy` を kro 機能のアクセスエントリに関連付けるか、本番稼働用のより制限の厳しい RBAC ポリシーを作成します。詳細については、「[kro アクセス許可の設定](kro-permissions.md)」を参照してください。

## CEL 式のエラー
<a name="_cel_expression_errors"></a>

CEL 式のエラーは、インスタンスの作成時ではなく、ResourceGraphDefinition の作成時に検出されます。kro は、RGD の作成時に、すべての CEL 構文を検証し、Kubernetes スキーマに対して式の型チェックを行い、フィールドの存在を検証します。

 **一般的な CEL 検証エラー**:
+  **未定義のフィールド参照**: スキーマまたはリソースに存在しないフィールドを参照しています。
+  **型の不一致**: 式が期待される型と異なる型 (例: 整数が期待される箇所で文字列) を返します。
+  **無効な構文**: CEL 式に括弧、引用符、または演算子がありません。
+  **不明なリソースタイプ**: クラスターに存在しない CRD を参照しています。

 **RGD の検証ステータスの確認**:

```
# Check if RGD was accepted
kubectl get resourcegraphdefinition {{my-rgd}} -o jsonpath='{.status.conditions[?(@.type=="ResourceGraphAccepted")]}'

# View detailed validation errors
kubectl describe resourcegraphdefinition {{my-rgd}}
```

`ResourceGraphAccepted` が `False` の場合、条件メッセージには検証エラーが含まれます。

 **有効な CEL 式の例**:

```
# Reference schema field
${schema.spec.appName}

# Conditional expression
${schema.spec.replicas > 1}

# String template (expressions must return strings)
name: "${schema.spec.appName}-service"

# Standalone expression (can be any type)
replicas: ${schema.spec.replicaCount}

# Resource reference
${deployment.status.availableReplicas}

# Optional field access (returns null if field doesn't exist)
${configmap.data.?DATABASE_URL}
```

## リソースの依存関係が解決されない
<a name="_resource_dependencies_not_resolving"></a>

kro は CEL 式から依存関係を自動的に推測し、正しい順序でリソースを作成します。リソースが想定どおりに作成されていない場合は、依存関係の順序とリソースの準備状況を確認してください。

 **計算された作成順序の表示**:

```
# See the order kro will create resources
kubectl get resourcegraphdefinition {{my-rgd}} -o jsonpath='{.status.topologicalOrder}'
```

これは、リソース間の CEL 式の参照に基づいて計算された順序を示しています。

 **リソースの準備状況の確認**:

```
# View instance status to see which resources are ready
kubectl get {{custom-kind}}
         {{my-instance}} -o jsonpath='{.status}'

# Check specific resource status
kubectl get deployment {{my-deployment}} -o jsonpath='{.status.conditions}'
```

 **readyWhen 条件の確認 (使用している場合)**:

`readyWhen` フィールドはオプションです。指定しない場合、リソースは作成直後に準備完了とみなされます。`readyWhen` 条件を定義している場合は、リソースの準備状況が正しくチェックされていることを確認します。

```
resources:
  - id: deployment
    readyWhen:
      - ${deployment.status.availableReplicas == deployment.spec.replicas}
```

 **リソースイベントの確認**:

```
# View events for the underlying resources
kubectl get events -n {{namespace}} --sort-by='.lastTimestamp'
```

## スキーマ検証の失敗
<a name="_schema_validation_failures"></a>

スキーマ検証エラーが原因でインスタンスの作成に失敗した場合は、インスタンスが RGD スキーマの要件と一致していることを確認します。

 **検証エラーの確認**:

```
# Attempt to create instance and view error
kubectl apply -f instance.yaml

# View existing instance validation status
kubectl describe {{custom-kind}}
         {{my-instance}} | grep -A 5 "Validation"
```

 **一般的な検証の問題**:
+  **必須フィールドがない**: インスタンスがすべての必須スキーマフィールドを提供していません。
+  **型の不一致**: 整数が期待される箇所で文字列が指定されています。
+  **無効な列挙値**: 許可されているリストに含まれていない値が使用されています。
+  **パターンの不一致**: 文字列が正規表現パターンと一致していません。

 **RGD スキーマの確認**:

```
# View the schema definition
kubectl get resourcegraphdefinition {{my-rgd}} -o jsonpath='{.spec.schema}'
```

インスタンスで、正しい型の必須フィールドがすべて指定されていることを確認します。

## 次のステップ
<a name="_next_steps"></a>
+  [EKS を利用する場合の kro の考慮事項](kro-considerations.md) - kro の考慮事項とベストプラクティス
+  [kro アクセス許可の設定](kro-permissions.md) - プラットフォームチームとアプリケーションチームに RBAC を設定する
+  [kro の概念](kro-concepts.md) - kro の概念とリソースライフサイクルを理解する
+  [EKS 機能をトラブルシューティングする](capabilities-troubleshooting.md) - 一般的な機能をトラブルシューティングする際のガイダンス