**このページの改善にご協力ください**
このユーザーガイドに貢献するには、すべてのページの右側のペインにある「**GitHub でこのページを編集する**」リンクを選択してください。
# ハイブリッドノードのトラブルシューティング
このトピックでは、Amazon EKS Hybrid Nodes の使用中に表示される一般的なエラーとその修復方法について説明します。その他のトラブルシューティング情報については、「[Amazon EKS クラスターとノードに関する問題をトラブルシューティングする](troubleshooting.md)」および * AWS re:Post* の「[Amazon EKS のナレッジセンタータグ](https://repost.aws/tags/knowledge-center/TA4IvCeWI1TE66q4jEj4Z9zg/amazon-elastic-kubernetes-service)」を参照してください。問題を解決できない場合は、AWS サポートにお問い合わせください。
**`nodeadm debug` を使用したノードのトラブルシューティング** ハイブリッドノードから `nodeadm debug` コマンドを実行して、ネットワークと認証情報の要件が満たされていることを検証できます。`nodeadm debug` コマンドの詳細については、「[ハイブリッドノード `nodeadm` 参照](hybrid-nodes-nodeadm.md)」を参照してください。
**クラスターインサイトを使用してハイブリッドノードの問題を検出する** Amazon EKS クラスターインサイトには、クラスター内の EKS Hybrid Nodes の設定に関する一般的な問題を検出する*インサイトチェック*が含まれます。すべてのインサイトチェックの結果は AWS マネジメントコンソール、AWS CLI、および AWS SDK から表示できます。クラスターインサイトの詳細については、「[Kubernetes バージョンアップグレードの準備およびクラスターインサイトでの設定ミスのトラブルシューティング](cluster-insights.md)」を参照してください。
## ハイブリッドノードのインストールに関するトラブルシューティング
以下のトラブルシューティングのトピックは、`nodeadm install` コマンドを使用してホストにハイブリッドノードの依存関係をインストールすることに関連しています。
** `nodeadm` コマンドが `must run as root` に失敗した**
`nodeadm install` コマンドは、ホストに対して root または `sudo` 権限を持つユーザーに実行させる必要があります。root または `sudo` 権限を持たないユーザーに `nodeadm install` を実行させると、`nodeadm` 出力に次のエラーが表示されます。
```
"msg":"Command failed","error":"must run as root"
```
**依存関係に接続できない**
`nodeadm install` コマンドは、ハイブリッドノードに必要な依存関係をインストールします。ハイブリッドノードの依存関係には、`containerd`、`kubelet`、`kubectl`、および AWS SSM または AWS IAM Roles Anywhere コンポーネントがあります。これらの依存関係をダウンロードするには、`nodeadm install` を実行している場所からアクセスする必要があります。アクセスする必要があるロケーションのリストの詳細については、「[ハイブリッドノード用のネットワークを準備する](hybrid-nodes-networking.md)」を参照してください。アクセス権限がない場合は、次のようなエラーが `nodeadm install` 出力に表示されます。
```
"msg":"Command failed","error":"failed reading file from url: ...: max retries achieved for http request"
```
**パッケージマネージャーの更新に失敗しました**
`nodeadm install` コマンドは、ハイブリッドノードの依存関係をインストールする前に、`apt update`、`yum update`、`dnf update` のいずれかを実行します。このステップが失敗すると、次のようなエラーが表示される可能性があります。これを修正するには、`apt update`、`yum update`、`dnf update` のいずれかを実行してから `nodeadm install` を実行するか、`nodeadm install` を再実行します。
```
failed to run update using package manager
```
**タイムアウトまたはコンテキストの期限を超過しました**
`nodeadm install` を実行するときに、インストールプロセスのさまざまな段階でタイムアウトまたはコンテキストの期限を超過したことを示すエラーの問題が発生した場合、接続が遅くなり、タイムアウトが完了する前にハイブリッドノードの依存関係がインストールされない可能性があります。これらの問題を回避するには、`nodeadm` の `--timeout` フラグを使用して、依存関係のダウンロードのタイムアウト期間を延長できます。
```
nodeadm install K8S_VERSION --credential-provider CREDS_PROVIDER --timeout 20m0s
```
## ハイブリッドノードの接続のトラブルシューティング
このセクションのトラブルシューティングトピックは、`nodeadm init` コマンドを使用してハイブリッドノードを EKS クラスターに接続するプロセスに関連しています。
**オペレーションエラーまたはサポートされていないスキーム**
`nodeadm init` を実行するときに、`operation error` または `unsupported scheme` に関連するエラーが表示された場合は、`nodeConfig.yaml` が正しくフォーマットされ、`nodeadm` に渡されているか確認します。`nodeConfig.yaml` のフォーマットのオプションの詳細については、「[ハイブリッドノード `nodeadm` 参照](hybrid-nodes-nodeadm.md)」を参照してください。
```
"msg":"Command failed","error":"operation error ec2imds: GetRegion, request canceled, context deadline exceeded"
```
**ハイブリッドノード IAM ロールに `eks:DescribeCluster` アクションのアクセス許可がありません**
`nodeadm init` を実行すると、`nodeadm` は EKS `DescribeCluster` アクションを呼び出して EKS クラスターに関する情報の収集を試みます。ハイブリッドノード IAM ロールに `eks:DescribeCluster` アクションのアクセス許可がない場合は、`nodeadm init` init の実行時に `nodeadm` に渡すノード設定で、Kubernetes API エンドポイント、クラスター CA バンドル、およびサービス IPv4 CIDR を渡す必要があります。ハイブリッドノード IAM ロールに必須のアクセス許可の詳細については、「[ハイブリッドノードの認証情報を準備する](hybrid-nodes-creds.md)」を参照してください。
```
"msg":"Command failed","error":"operation error EKS: DescribeCluster, https response error StatusCode: 403 ... AccessDeniedException"
```
**ハイブリッドノード IAM ロールに `eks:ListAccessEntries` アクションのアクセス許可がありません**
`nodeadm init` を実行すると、`nodeadm` は EKS `ListAccessEntries`アクションを呼び出して、ハイブリッドノード IAM ロールに関連付けられた `HYBRID_LINUX` タイプのアクセスエントリが EKS クラスターにあるかどうかを検証しようとします。ハイブリッドノード IAM ロールに `eks:ListAccessEntries` アクションのアクセス許可がない場合は、`nodeadm init` コマンドの実行時に `--skip cluster-access-validation` フラグを渡す必要があります。ハイブリッドノード IAM ロールに必須のアクセス許可の詳細については、「[ハイブリッドノードの認証情報を準備する](hybrid-nodes-creds.md)」を参照してください。
```
"msg":"Command failed","error":"operation error EKS: ListAccessEntries, https response error StatusCode: 403 ... AccessDeniedException"
```
**リモートノードネットワークの CIDR にないノード IP**
`nodeadm init` を実行するときに、指定されたリモートノードネットワークの CIDR の中にノードの IP アドレスがない場合、エラーが発生することがあります。エラーは次の例のような見た目になります。
```
node IP 10.18.0.1 is not in any of the remote network CIDR blocks [10.0.0.0/16 192.168.0.0/16]
```
こちらの例では、IP 10.18.0.1 のノードが、リモートネットワークの CIDR 10.0.0.0/16 と 192.168.0.0/16 でクラスターを結合しようとしています。10.18.0.1 がいずれの範囲にもないため、エラーが発生しています。
`RemoteNodeNetworks` が正しく設定され、すべてのノード IP アドレスが含まれていることを確認します。ネットワーク設定の詳細については、「[ハイブリッドノード用のネットワークを準備する](hybrid-nodes-networking.md)」を参照してください。
+ お使いのクラスターが配置されているリージョンで次のコマンドを実行し、`RemoteNodeNetwork` 設定をチェックします。出力に表示された CIDR ブロックに、ご自身のノードの IP 範囲が含まれ、エラーメッセージに表示された CIDR ブロックと同一であることを確認します。同じでない場合は、クラスター名と `nodeConfig.yaml` のリージョンが、対象となるクラスターと一致していることを確認します。
```
aws eks describe-cluster --name CLUSTER_NAME --region REGION_NAME --query cluster.remoteNetworkConfig.remoteNodeNetworks
```
+ 対象のノードで作業していることを確認します。
+ ホスト名と IP アドレスが、クラスターに登録しようとしているものと一致することを確認して、正しいノードで作業していることを確認します。
+ このノードが正しいオンプレミスネットワーク (クラスターのセットアップ中に CIDR 範囲が `RemoteNodeNetwork` として登録されたネットワーク) にあることを確認します。
それでもやはりノード IP が想定されるものと異なる場合は、以下を確認します。
+ IAM Roles Anywhere を使用している場合、`kubelet` が DNS ルックアップを IAM Roles Anywhere で実行し、`nodeName` がノード名 (使用できる場合) に関連付けられた IP を使用している。ノードの DNS エントリを維持している場合、これらのエントリがリモートノードネットワークの CIDR 内の IP を指していることを確認する。
+ ノードに複数のネットワークインターフェイスがある場合、`kubelet` は、リモートノードネットワークの CIDR の、範囲外の IP アドレスを持つインターフェイスをデフォルトとして選択することがあります。別のインターフェイスを使用するには、ご自身の `nodeConfig.yaml` の `--node-ip` `kubelet` フラグを使用して、その IP アドレスを指定します。詳細については、「[ハイブリッドノード `nodeadm` 参照](hybrid-nodes-nodeadm.md)」を参照してください。ノードで次のコマンドを実行すると、ノードのネットワークインターフェイスとその IP アドレスを確認できます。
```
ip addr show
```
**ハイブリッドノードが EKS クラスターに表示されない**
`nodeadm init` を実行して完了しても、ハイブリッドノードがクラスターに表示されない場合、ハイブリッドノードと EKS コントロールプレーン間のネットワーク接続に問題があるか、必要なセキュリティグループのアクセス許可が設定されていないか、Kubernetes ロールベースアクセスコントロール (RBAC) へのハイブリッドノード IAM ロールの必要なマッピングがない可能性があります。次のコマンドを使用して `kubelet` と `kubelet` ログのステータスを確認することで、デバッグプロセスを開始できます。クラスターに参加できなかったハイブリッドノードから次のコマンドを実行します。
```
systemctl status kubelet
```
```
journalctl -u kubelet -f
```
**クラスターと通信できません**
ハイブリッドノードがクラスターコントロールプレーンと通信できなかった場合は、次のようなログが表示されることがあります。
```
"Failed to ensure lease exists, will retry" err="Get ..."
```
```
"Unable to register node with API server" err="Post ..."
```
```
Failed to contact API server when waiting for CSINode publishing ... dial tcp : i/o timeout
```
これらのメッセージが表示された場合は、以下をチェックして、[ハイブリッドノード用のネットワークを準備する](hybrid-nodes-networking.md) で説明されているハイブリッドノード要件を満たしていることを確認します。
+ EKS クラスターに渡される VPC に、オンプレミスノードとオプションでポッド CIDR の Transit Gateway (TGW) または仮想プライベートゲートウェイ (VGW) へのルートがあることを確認します。
+ EKS クラスターに追加のセキュリティグループがあり、オンプレミスノード CIDR とオプションでポッド CIDR のインバウンドルールがあることを確認します。
+ EKS コントロールプレーンとの間のトラフィックを許可するようにオンプレミスルーターが設定されていることを確認します。
**Unauthorized**
ハイブリッドノードが EKS コントロールプレーンと通信できたが、登録できなかった場合、次のようなログが表示されることがあります。以下のログメッセージの主な違いは `Unauthorized` エラーであることに注意してください。これは、必要なアクセス許可がないため、ノードがタスクを実行できなかったことを示します。
```
"Failed to ensure lease exists, will retry" err="Unauthorized"
```
```
"Unable to register node with API server" err="Unauthorized"
```
```
Failed to contact API server when waiting for CSINode publishing: Unauthorized
```
これらのメッセージが表示された場合は、以下をチェックして、[ハイブリッドノードの認証情報を準備する](hybrid-nodes-creds.md) および [ハイブリッドノードのクラスターアクセスを準備する](hybrid-nodes-cluster-prep.md) のハイブリッドノードの要件の詳細を満たしていることを確認します。
+ ハイブリッドノードのアイデンティティが、想定のハイブリッドノードの IAM ロールと一致することを確認します。これを行うには、ハイブリッドノードから `sudo aws sts get-caller-identity` を実行します。
+ ハイブリッドノード IAM ロールに必要なアクセス許可があることを確認します。
+ クラスターにハイブリッドノード IAM ロールの EKS アクセスエントリがあることを確認するか、`aws-auth` ConfigMap にハイブリッドノード IAM ロールのエントリがあることを確認します。EKS アクセスエントリを使用している場合は、ハイブリッドノード IAM ロールのアクセスエントリが `HYBRID_LINUX` アクセスタイプであることを確認します。`aws-auth` ConfigMap を使用している場合は、ハイブリッドノード IAM ロールのエントリが、「[ハイブリッドノードのクラスターアクセスを準備する](hybrid-nodes-cluster-prep.md)」で説明されている要件と形式を満たしていることを確認します。
### ハイブリッドノードが EKS クラスターに登録されているのにステータス `Not Ready` が表示される
ハイブリッドノードが EKS クラスターに正常に登録されたが、ハイブリッドノードのステータスが `Not Ready` である場合、最初に確認すべきことは、コンテナネットワークインターフェイス (CNI) のステータスです。CNI をインストールしていない場合は、ハイブリッドノードのステータスが `Not Ready` であることが予想されます。CNI が正常にインストールされ実行されると、ノードのステータスは `Ready` に移行します。CNI をインストールしようとしたが、正常に実行されていない場合は、このページの「[ハイブリッドノード CNI のトラブルシューティング](#hybrid-nodes-troubleshooting-cni)」を参照してください。
**証明書署名リクエスト (CSR) が保留中のままである**
ハイブリッドノードを EKS クラスターに接続した後、ハイブリッドノードの保留中の CSR がある場合、ハイブリッドノードは自動承認の要件を満たしていません。ハイブリッドノードの CSR は、ハイブリッドノードの CSR が `eks.amazonaws.com/compute-type: hybrid` ラベル付きノードによって作成され、CSR に次のサブジェクト代替名 (SAN) がある場合、自動的に承認および発行されます: 少なくとも 1 つの DNS SAN はノード名と等しく、IP SAN はリモートノードネットワークの CIDR に属するものです。
**ハイブリッドプロファイルは既に存在します**
`nodeadm` 設定を変更し、ノードを新しい設定に再登録しようとすると、ハイブリッドプロファイルが既に存在するが、その内容が変更されたことを示すエラーが表示されることがあります。設定変更の合間に `nodeadm init` を実行する代わりに、`nodeadm uninstall` を実行し、その後に `nodeadm install` と `nodeadm init` を実行します。これにより、設定の変更に伴う適切なクリーンアップが保証されます。
```
"msg":"Command failed","error":"hybrid profile already exists at /etc/aws/hybrid/config but its contents do not align with the expected configuration"
```
**ハイブリッドノードがプライベート API の解決に失敗しました**
`nodeadm init` 実行後、`no such host` が存在するために EKS Kubernetes API サーバーへの接続に失敗したことを示すエラーが `kubelet` ログに表示された場合は、オンプレミスネットワークまたはホストレベルで EKS Kubernetes API エンドポイントの DNS エントリを変更する必要がある場合があります。「* AWS Route53 documentation*」の「[Forwarding inbound DNS queries to your VPC](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-forwarding-inbound-queries.html)」を参照してください。
```
Failed to contact API server when waiting for CSINode publishing: Get ... no such host
```
**EKS コンソールでハイブリッドノードを表示できない**
ハイブリッドノードが登録されているのに、EKS コンソールで表示できない場合は、コンソールの表示に使用している IAM プリンシパルのアクセス許可を確認してください。使用している IAM プリンシパルには、コンソールでリソースを表示するための特定の最小の IAM および Kubernetes アクセス許可が必要です。詳細については、「[AWS マネジメントコンソール に Kubernetes リソースを表示する](view-kubernetes-resources.md)」を参照してください。
## ハイブリッドノードのトラブルシューティングの実行
EKS クラスターに登録されたハイブリッドノードのステータスが `Ready` で、その後ステータスが `Not Ready` に移行した場合、ノードに CPU、メモリ、使用可能なディスク容量の十分なリソースがない、ノードが EKS コントロールプレーンから切断されているなど、さまざまな問題が異常なステータスの原因となった可能性があります。以下のステップを使用してノードのトラブルシューティングを行うことができます。問題を解決できない場合は、AWS サポートにお問い合わせください。
ハイブリッドノードから `nodeadm debug` を実行して、ネットワークと認証情報の要件が満たされていることを確認します。`nodeadm debug` コマンドの詳細については、「[ハイブリッドノード `nodeadm` 参照](hybrid-nodes-nodeadm.md)」を参照してください。
**ノードのステータスを取得する**
```
kubectl get nodes -o wide
```
**ノードの条件とイベントを確認する**
```
kubectl describe node NODE_NAME
```
**ポッドのステータスを取得する**
```
kubectl get pods -A -o wide
```
**ポッドの条件とイベントを確認する**
```
kubectl describe pod POD_NAME
```
**ポッドログを確認する**
```
kubectl logs POD_NAME
```
**`kubectl` ログを確認する**
```
systemctl status kubelet
```
```
journalctl -u kubelet -f
```
**ポッドのライブネスプローブが失敗しているか、ウェブフックが機能していない**
ハイブリッドノードで動作しているアプリケーション、アドオン、またはウェブフックが正しく起動しない場合、ポッドへの通信をブロックするネットワークの問題が発生する可能性があります。EKS コントロールプレーンがハイブリッドノードで動作しているウェブフックに接続するには、リモートポッドネットワークで EKS クラスターを設定し、VPC ルーティングテーブルにオンプレミスポッド CIDR のルートを設定し、ターゲットを Transit Gateway (TGW)、仮想プライベートゲートウェイ (VPW)、または VPC をオンプレミスネットワークに接続するために使用するその他のゲートウェイとして設定する必要があります。ハイブリッドノードのネットワーク要件の詳細については、「[ハイブリッドノード用のネットワークを準備する](hybrid-nodes-networking.md)」を参照してください。さらに、オンプレミスのファイアウォールでこのトラフィックを許可し、ルーターがポッドに適切にルーティングできることを確認する必要があります。ハイブリッドノードでウェブフックを実行するための要件の詳細については、「[ハイブリッドノード用のウェブフックを設定する](hybrid-nodes-webhooks.md)」を参照してください。
このシナリオの一般的なポッドログメッセージを以下に示します。ここでは、ip-address は Kubernetes サービスのクラスター IP です。
```
dial tcp :443: connect: no route to host
```
**`kubectl logs` または `kubectl exec` コマンドが機能していない (`kubelet` API コマンド)**
他の `kubectl` コマンドは正常に実行されているのに、`kubectl attach`、`kubectl cp`、`kubectl exec`、`kubectl logs`、`kubectl port-forward` コマンドがタイムアウトした場合は、リモートネットワークの設定に問題がある可能性があります。これらのコマンドはクラスターを介してノードの `kubelet` エンドポイントに接続しています。詳細については、「[`kubelet` エンドポイント](hybrid-nodes-concepts-kubernetes.md#hybrid-nodes-concepts-k8s-kubelet-api)」を参照してください。
ノード IP とポッド IP が、ご自身のクラスター向けに設定したリモートノードネットワークおよびリモートポッドネットワーク CIDR の範囲に含まれていることを確認します。以下のコマンドを使用して IP の割り当てを調べます。
```
kubectl get nodes -o wide
```
```
kubectl get pods -A -o wide
```
これらの IP を、設定したリモートネットワークの CIDR と比較して、適切にルーティングされていることを確認します。ネットワークの設定要件については、「[ハイブリッドノード用のネットワークを準備する](hybrid-nodes-networking.md)」を参照してください。
## ハイブリッドノード CNI のトラブルシューティング
ハイブリッドノードで最初に Cilium または Calico を起動する際に問題が発生した場合は、多くの場合、ハイブリッドノードまたはハイブリッドノードで稼働する CNI ポッドと EKS コントロールプレーン間のネットワークの問題が原因です。環境が「ハイブリッドノードのネットワークを準備する」の要件を満たしていることを確認します。問題を分割すると分かりやすくなります。
EKS クラスター設定
RemoteNodeNetwork と RemotePodNetwork の設定は正しいですか?
VPC の設定
VPC ルーティングテーブルに、Transit Gateway または Virtual Private Gateway のターゲットを持つ RemoteNodeNetwork と RemotePodNetwork のルートはありますか?
セキュリティグループの構成
RemoteNodeNetwork および RemotePodNetwork のインバウンドルールとアウトバウンドルールはありますか?
オンプレミスのネットワーク
EKS コントロールプレーンとハイブリッドノード、およびハイブリッドノードで実行されているポッドとの間のルートとアクセスはありますか?
CNI の設定
オーバーレイネットワークを使用している場合、CNI の IP プール設定は、ウェブフックを使用している場合に EKS クラスター用に設定された RemotePodNetwork と一致していますか?
**CNI がインストールされていないハイブリッドノードのステータス `Ready`**
ハイブリッドノードのステータスが `Ready` と表示されているが、クラスターに CNI をインストールしていない場合は、ハイブリッドノードに古い CNI アーティファクトが存在する可能性があります。デフォルトでは、Helm などのツールを使用して Cilium と Calico をアンインストールしても、ディスク上のリソースは物理マシンや仮想マシンからは削除されません。さらに、これらの CNI のカスタムリソース定義 (CRD) は、古いインストールからクラスターにまだ存在する場合があります。詳細については、「[ハイブリッドノードの CNI を設定する](hybrid-nodes-cni.md)」の「Cilium と Calico の削除」セクションを参照してください。
**Cilium のトラブルシューティング**
ハイブリッドノードで Cilium の実行に問題がある場合は、Cilium ドキュメントの「[トラブルシューティング手順](https://docs.cilium.io/en/stable/operations/troubleshooting/)」を参照してください。以下のセクションでは、ハイブリッドノードへの Cilium のデプロイに固有の問題について説明します。
**Cilium が起動しない**
各ハイブリッドノードで実行されている Cilium エージェントが開始されていない場合は、Cilium エージェントポッドのログにエラーがないか確認します。Cilium エージェントを起動するには、EKS Kubernetes API エンドポイントへの接続が必要です。この接続が正しく設定されていない場合、Cilium エージェントの起動は失敗します。この場合、Cilium エージェントポッドログに次のようなログメッセージが表示されます。
```
msg="Unable to contact k8s api-server"
level=fatal msg="failed to start: Get \"https://:443/api/v1/namespaces/kube-system\": dial tcp :443: i/o timeout"
```
Cilium エージェントはホストネットワークで実行されます。EKS クラスターは、Cilium 接続用に `RemoteNodeNetwork` で設定する必要があります。EKS クラスターに `RemoteNodeNetwork` のインバウンドルールを持つ追加のセキュリティグループがあり、VPC に`RemoteNodeNetwork` のルートがあり、EKS コントロールプレーンへの接続を許可するようにオンプレミスネットワークが正しく設定されていることを確認します。
Cilium オペレータが実行されていて、一部の Cilium エージェントが動作しているが、すべてが動作していない場合は、クラスター内のすべてのノードに割り当てるポッド IP があることを確認します。Cilium 設定で `clusterPoolIPv4PodCIDRList` でクラスタープール IPAM を使用するときに、割り当て可能なポッド CIDR のサイズを設定します。ノードごとの CIDR サイズは、Cilium 設定の `clusterPoolIPv4MaskSize` 設定で設定されます。詳細については、Cilium ドキュメントの「[Expanding the cluster pool](https://docs.cilium.io/en/stable/network/concepts/ipam/cluster-pool/#expanding-the-cluster-pool)」を参照してください。
**Cilium BGP が機能しない**
Cilium BGP コントロールプレーンを使用して、ポッドまたはサービスアドレスをオンプレミスネットワークにアドバタイズする場合は、次の Cilium CLI コマンドを使用して、BGP がリソースへのルートをアドバタイズしているかどうかを確認できます。Cilium CLI をインストールする手順については、Cilium ドキュメントの「[Cilium CLI のインストール](https://docs.cilium.io/en/stable/gettingstarted/k8s-install-default/#install-the-cilium-cli)」を参照してください。
BGP が正しく動作している場合は、ハイブリッドノードの出力に Session State `established` が含まれている必要があります。場合によっては、ネットワークチームと協力して、環境のローカル AS、ピア AS、ピアアドレスの正しい値を特定する必要があります。
```
cilium bgp peers
```
```
cilium bgp routes
```
Cilium BGP を使用してタイプ `LoadBalancer` のサービスの IP をアドバタイズする場合は、`CiliumLoadBalancerIPPool` と Service の両方に同じラベルが必要です。ラベルは、`CiliumBGPAdvertisement` のセレクタで使用する必要があります。次に例を示します。Cilium BGP を使用して LoadBalancer タイプのサービスの IP をアドバタイズしている場合、Cilium エージェントの再起動中に BGP ルートが中断される可能性があります。詳細については、「Cilium documentation」の「[Failure Scenarios](https://docs.cilium.io/en/latest/network/bgp-control-plane/bgp-control-plane-operation/#failure-scenarios)」を参照してください。
**サービス**
```
kind: Service
apiVersion: v1
metadata:
name: guestbook
labels:
app: guestbook
spec:
ports:
- port: 3000
targetPort: http-server
selector:
app: guestbook
type: LoadBalancer
```
**CiliumLoadBalancerIPPool**
```
apiVersion: cilium.io/v2alpha1
kind: CiliumLoadBalancerIPPool
metadata:
name: guestbook-pool
labels:
app: guestbook
spec:
blocks:
- cidr:
serviceSelector:
matchExpressions:
- { key: app, operator: In, values: [ guestbook ] }
```
**CiliumBGPAdvertisement**
```
apiVersion: cilium.io/v2alpha1
kind: CiliumBGPAdvertisement
metadata:
name: bgp-advertisements-guestbook
labels:
advertise: bgp
spec:
advertisements:
- advertisementType: "Service"
service:
addresses:
- ExternalIP
- LoadBalancerIP
selector:
matchExpressions:
- { key: app, operator: In, values: [ guestbook ] }
```
**Calico のトラブルシューティング**
ハイブリッドノードで Calico の実行に問題がある場合は、Calico ドキュメントの「[トラブルシューティング手順](https://docs.tigera.io/calico/latest/operations/troubleshoot/)」を参照してください。以下のセクションでは、Calico をハイブリッドノードにデプロイする際に特有の問題について説明します。
次の表は、Calico コンポーネントと、それらがデフォルトでノードネットワークまたはポッドネットワークで実行されているかどうかをまとめたものです。ポッドの送信トラフィックに NAT を使用するように Calico を設定した場合、オンプレミスネットワークはオンプレミスノード CIDR にトラフィックをルーティングするように設定する必要があり、VPC ルーティングテーブルはトランジットゲートウェイ (TGW) または仮想プライベートゲートウェイ (VGW) をターゲットとするオンプレミスノード CIDR のルートで設定する必要があります。ポッドの送信トラフィックに NAT を使用するように Calico を設定していない場合は、オンプレミスネットワークがオンプレミスポッド CIDR にトラフィックをルーティングするように設定し、VPC ルーティングテーブルをトランジットゲートウェイ (TGW) または仮想プライベートゲートウェイ (VGW) をターゲットとするオンプレミスポッド CIDR のルートで設定する必要があります。
| コンポーネント | Network |
| --- | --- |
| Calico API サーバー | ノード |
| Kubernetes 用の Calico コントローラー | ポッド |
| Calico ノードエージェント | ノード |
| Calico `typha` | ノード |
| Calico CSI ノードドライバー | ポッド |
| Calico 演算子 | ノード |
**Calico リソースは、遮断されたノードでスケジュールまたは実行されています**
DaemonSet として実行されない Calico リソースには、デフォルトで柔軟な許容範囲があり、ポッドのスケジュールや実行の準備が整っていない遮断されたノードでスケジュールできます。以下を含めるようにオペレータのインストールを変更することで、DaemonSet Calico 以外のリソースの許容範囲を厳しくすることができます。
```
installation:
...
controlPlaneTolerations:
- effect: NoExecute
key: node.kubernetes.io/unreachable
operator: Exists
tolerationSeconds: 300
- effect: NoExecute
key: node.kubernetes.io/not-ready
operator: Exists
tolerationSeconds: 300
calicoKubeControllersDeployment:
spec:
template:
spec:
tolerations:
- effect: NoExecute
key: node.kubernetes.io/unreachable
operator: Exists
tolerationSeconds: 300
- effect: NoExecute
key: node.kubernetes.io/not-ready
operator: Exists
tolerationSeconds: 300
typhaDeployment:
spec:
template:
spec:
tolerations:
- effect: NoExecute
key: node.kubernetes.io/unreachable
operator: Exists
tolerationSeconds: 300
- effect: NoExecute
key: node.kubernetes.io/not-ready
operator: Exists
tolerationSeconds: 300
```
## 認証情報のトラブルシューティング
AWS SSM ハイブリッドアクティベーションと AWS IAM Roles Anywhere の両方で、ハイブリッドノードから次のコマンドを実行して、ハイブリッドノード IAM ロールの認証情報がハイブリッドノードで正しく設定されていることを検証できます。ノード名とハイブリッドノード IAM ロール名が想定どおりであることを確認します。
```
sudo aws sts get-caller-identity
```
```
{
"UserId": "ABCDEFGHIJKLM12345678910:",
"Account": "",
"Arn": "arn:aws:sts:::assumed-role/"
}
```
** AWSSystems Manager (SSM) のトラブルシューティング**
ハイブリッドノードの認証情報に AWS SSM ハイブリッドアクティベーションを使用している場合は、`nodeadm` によってハイブリッドノードにインストールされている次の SSM ディレクトリとアーティファクトに注意してください。SSM エージェントの詳細については、「*AWS Systems Manager ユーザーガイド*」の「[SSM Agent の使用](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent.html)」を参照してください。
| 説明 | 場所 |
| --- | --- |
| SSM エージェント | Ubuntu - `/snap/amazon-ssm-agent/current/amazon-ssm-agent` RHEL & AL2023 - `/usr/bin/amazon-ssm-agent` |
| SSM エージェントログ | `/var/log/amazon/ssm` |
| AWS 認証情報 | `/root/.aws/credentials` |
| SSM Setup CLI | `/opt/ssm/ssm-setup-cli` |
**SSM エージェントを再起動する**
SSM エージェントを再起動することで解決できる問題もあります。以下のコマンドを使用して再起動できます。
**AL2023 およびその他のオペレーティングシステム**
```
systemctl restart amazon-ssm-agent
```
**Ubuntu** -
```
systemctl restart snap.amazon-ssm-agent.amazon-ssm-agent
```
**SSM エンドポイントへの接続を確認する**
ハイブリッドノードから SSM エンドポイントに接続できることを確認します。SSM エンドポイントのリストについては、「[AWS Systems Manager endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/ssm.html)」を参照してください。以下のコマンドの `us-west-2` を、AWS SSM ハイブリッドアクティベーションの AWS リージョンに置き換えます。
```
ping ssm.us-west-2.amazonaws.com
```
**登録された SSM インスタンスの接続ステータスを表示する**
次の AWS CLI コマンドを使用して、SSM ハイブリッドアクティベーションに登録されているインスタンスの接続ステータスを確認できます。マシン ID をインスタンスのマシン ID に置き換えます。
```
aws ssm get-connection-status --target mi-012345678abcdefgh
```
**SSM セットアップ CLI チェックサムの不一致**
`nodeadm install` の実行時に、`ssm-setup-cli` チェックサムの不一致に問題がある場合は、ホストに古い既存の SSM インストールがないことを確認する必要があります。ホストに古い SSM インストールがある場合は、それらを削除して `nodeadm install` を再実行し、問題を解決します。
```
Failed to perform agent-installation/on-prem registration: error while verifying installed ssm-setup-cli checksum: checksum mismatch with latest ssm-setup-cli.
```
**SSM `InvalidActivation`**
インスタンスを AWS SSM に登録する際にエラーが表示された場合は、`nodeConfig.yaml` の `region`、`activationCode`、および `activationId` が正しいことを確認します。EKS クラスターの AWS リージョンは、SSM ハイブリッドアクティベーションのリージョンと一致する必要があります。これらの値が誤って設定されている場合は、次のようなエラーが表示されることがあります。
```
ERROR Registration failed due to error registering the instance with AWS SSM. InvalidActivation
```
**SSM `ExpiredTokenException`: リクエストに含まれているセキュリティトークンが有効期限切れです**
SSM エージェントが認証情報を更新できない場合は、「`ExpiredTokenException`」が表示されることがあります。このシナリオでは、ハイブリッドノードから SSM エンドポイントに接続できる場合、認証情報の更新を強制するために SSM エージェントを再起動する必要がある場合があります。
```
"msg":"Command failed","error":"operation error SSM: DescribeInstanceInformation, https response error StatusCode: 400, RequestID: eee03a9e-f7cc-470a-9647-73d47e4cf0be, api error ExpiredTokenException: The security token included in the request is expired"
```
**register machine コマンドの実行中の SSM エラー**
マシンを SSM に登録する際にエラーが発生した場合は、`nodeadm install` を再実行して、すべての SSM 依存関係が正しくインストールされていることを確認する必要があります。
```
"error":"running register machine command: , error: fork/exec /opt/aws/ssm-setup-cli: no such file or directory"
```
**SSM `ActivationExpired`**
`nodeadm init` の実行時に、アクティベーションの有効期限が切れたために SSM へのインスタンスの登録がエラーになった場合は、新しい SSM ハイブリッドアクティベーションを作成し、新しい SSM ハイブリッドアクティベーションの `activationCode` と `activationId` で `nodeConfig.yaml` を更新して、`nodeadm init` を再実行する必要があります。
```
"msg":"Command failed","error":"SSM activation expired. Please use a valid activation"
```
```
ERROR Registration failed due to error registering the instance with AWS SSM. ActivationExpired
```
**SSM がキャッシュされた認証情報を更新できませんでした**
キャッシュされた認証情報の更新に失敗した場合、`/root/.aws/credentials` ファイルはホストで削除されている可能性があります。まず、SSM ハイブリッドアクティベーションをチェックして、アクティブであること、およびアクティベーションを使用するようにハイブリッドノードが正しく設定されていることを確認します。`/var/log/amazon/ssm` で SSM エージェントログを確認し、SSM 側で問題を解決したら `nodeadm init` コマンドを再実行します。
```
"Command failed","error":"operation error SSM: DescribeInstanceInformation, get identity: get credentials: failed to refresh cached credentials"
```
**SSM のクリーンアップ**
ホストから SSM エージェントを削除するには、次のコマンドを実行します。
```
dnf remove -y amazon-ssm-agent
sudo apt remove --purge amazon-ssm-agent
snap remove amazon-ssm-agent
rm -rf /var/lib/amazon/ssm/Vault/Store/RegistrationKey
```
** AWSIAM Roles Anywhere のトラブルシューティング**
ハイブリッドノードの認証情報に AWS IAM Roles Anywhere を使用している場合は、`nodeadm` によってハイブリッドノードにインストールされている次のディレクトリとアーティファクトに注意してください。IAM Roles Anywhere のトラブルシューティングの詳細については、「*AWS IAM Roles Anywhere User Guide*」の「[Troubleshooting AWS IAM Roles Anywhere identity and access](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/security_iam_troubleshoot.html)」を参照してください。
| 説明 | 場所 |
| --- | --- |
| IAM Roles Anywhere CLI | `/usr/local/bin/aws_signing_helper` |
| デフォルトの証明書の場所と名前 | `/etc/iam/pki/server.pem` |
| デフォルトのキーの場所と名前 | `/etc/iam/pki/server.key` |
**IAM Roles Anywhere がキャッシュされた認証情報の更新に失敗しました**
キャッシュされた認証情報の更新に失敗した場合は、`/etc/aws/hybrid/config` の内容を確認し、`nodeadm` 設定で IAM Roles Anywhere が正しく設定されていることを確認します。`/etc/iam/pki` が存在することを確認します。各ノードには一意の証明書とキーが必要です。デフォルトでは、認証情報プロバイダーとして IAM Roles Anywhere を使用する場合、`nodeadm` は証明書の場所と名前に `/etc/iam/pki/server.pem` を使用し、プライベートキーに `/etc/iam/pki/server.key` を使用します。`sudo mkdir -p /etc/iam/pki` を使用してディレクトリに証明書とキーを配置する前に、ディレクトリの作成が必要になる場合があります。証明書の内容は、以下のコマンドで確認できます。
```
openssl x509 -text -noout -in server.pem
```
```
open /etc/iam/pki/server.pem: no such file or directory
could not parse PEM data
Command failed {"error": "... get identity: get credentials: failed to refresh cached credentials, process provider error: error in credential_process: exit status 1"}
```
** の実行が許可されていない IAM Roles Anywhere`sts:AssumeRole`**
`kubelet` ログで、IAM Roles Anywhere の使用時に `sts:AssumeRole` オペレーションに対するアクセス拒否の問題が表示された場合は、ハイブリッドノード IAM ロールの信頼ポリシーをチェックして、IAM Roles Anywhere サービスプリンシパルがハイブリッドノード IAM ロールを引き受けることができることを確認します。さらに、ハイブリッドノード IAM ロールの信頼ポリシーでトラストアンカー ARN が正しく設定されていること、およびハイブリッドノード IAM ロールが IAM Roles Anywhere プロファイルに追加されていることを確認します。
```
could not get token: AccessDenied: User: ... is not authorized to perform: sts:AssumeRole on resource: ...
```
** を設定することが許可されていない IAM Roles Anywhere`roleSessionName`**
`kubelet` ログで、`roleSessionName` の設定にアクセス拒否の問題が発生した場合は、IAM Roles Anywhere プロファイルで `acceptRoleSessionName` を true に設定していることを確認します。
```
AccessDeniedException: Not authorized to set roleSessionName
```
## オペレーティングシステムのトラブルシューティング
### RHEL
**使用権限管理者またはサブスクリプションマネージャーの登録失敗**
`nodeadm install` を実行中で、使用権限登録の問題によりハイブリッドノードの依存関係のインストールに失敗した場合、ホストに Red Hat ユーザー名とパスワードを適切に設定していることを確認してください。
```
This system is not registered with an entitlement server
```
### Ubuntu
**GLIBC が見つかりません**
オペレーティングシステムに Ubuntu を使用し、ハイブリッドノードを持つ認証情報プロバイダーに IAM Roles Anywhere を使用していて、GLIBC が見つからない問題がある場合は、その依存関係を手動でインストールすることで問題を解決できます。
```
GLIBC_2.32 not found (required by /usr/local/bin/aws_signing_helper)
```
次のコマンドを実行して依存関係をインストールします。
```
ldd --version
sudo apt update && apt install libc6
sudo apt install glibc-source
```
### Bottlerocket
Bottlerocket 管理コンテナを有効にしている場合、SSH を使用してこれにアクセスし、昇格された権限を使って高度なデバッグとトラブルシューティングを行うことができます。以下のセクションでは、Bottlerocket ホストのコンテキストで実行する必要があるコマンドを記載しています。管理コンテナにアクセスすると、`sheltie` を実行すれば Bottlerocket ホストで完全なルートシェルを取得することができます。
```
sheltie
```
以下のセクションにあるコマンドは、各コマンドの前に `sudo chroot /.bottlerocket/rootfs` を付けることで管理者コンテナシェルから実行することもできます。
```
sudo chroot /.bottlerocket/rootfs
```
**ログ収集に logdog を使用する**
Bottlerocket には、トラブルシューティングを目的に、ログとシステム情報とを効率的に収集する `logdog` ユーティリティがあります。
```
logdog
```
`logdog` ユーティリティは、Bottlerocket ホストのさまざまな場所からログを収集し、それらを tarball と組み合わせます。デフォルトでは、tarball は `/var/log/support/bottlerocket-logs.tar.gz` で作成され、`/.bottlerocket/support/bottlerocket-logs.tar.gz` にあるホストコンテナからアクセスすることができます。
**journalctl を使用したシステムログへのアクセス**
次のコマンドを使用することで、`kubelet`、`containerd` などのさまざまなシステムサービスのステータスをチェックしたりログを表示したりできます。`-f` フラグは、ログをリアルタイムでフォローします。
`kubelet` サービスのステータスを確認し `kubelet` ログを取得するときは、以下を実行します。
```
systemctl status kubelet
journalctl -u kubelet -f
```
`containerd` サービスのステータスを確認し、オーケストレーションされた `containerd` インスタンスのログを取得するときは、以下を実行します。
```
systemctl status containerd
journalctl -u containerd -f
```
`host-containerd` サービスのステータスを確認し、ホスト `containerd` インスタンスのログを取得するときは、以下を実行します。
```
systemctl status host-containerd
journalctl -u host-containerd -f
```
ブートストラップコンテナとホストコンテナのログを取得するときは、以下を実行します。
```
journalctl _COMM=host-ctr -f
```