クラスターのネームスペースを削除できないのはなぜですか?

背景

今日議論する問題は、K8s クラスターの名前空間に関連しています。名前空間は、K8s クラスター リソースの「ストレージ」メカニズムです。関連のないリソース間の不要な影響を避けるために、関連するリソースを同じ名前空間に「収集」することができます。

名前空間自体もリソースです。クラスター API サーバー エントリを通じて新しい名前空間を作成できます。使用されなくなった名前空間については、クリーンアップする必要があります。名前空間コントローラーは、API サーバーを介してクラスター内の名前空間の変更を監視し、変更に基づいて事前定義されたアクションを実行します。

写真

場合によっては、次の図に示すように、名前空間のステータスが「終了中」とマークされているにもかかわらず、完全に削除できないという問題が発生することがあります。

写真

クラスターポータルから開始

削除操作はクラスター API サーバーによって実行されるため、API サーバーの動作を分析する必要があります。ほとんどのクラスター コンポーネントと同様に、API サーバーはさまざまなレベルのログ出力を提供します。 API サーバーの動作を理解するために、ログ レベルを最高レベルに調整します。次に、tobedeletedb 名前空間を作成して削除することで問題を再現します。

しかし残念なことに、API サーバーはこの問題に関連するログをあまり出力しません。

関連するログは 2 つの部分に分けられます。

• 1 つの部分は、削除される名前空間の記録です。レコードには、クライアント ツールが kubectl であり、操作を開始したソース IP アドレスが 192.168.0.41 であることが示されており、これは予想どおりです。

• もう 1 つの部分は、Kube コントローラー マネージャーがこの名前空間の情報を繰り返し取得することです。

写真

Kube コントローラー マネージャーは、クラスター内のほとんどのコントローラーを実装します。 tobedeletedb 情報を繰り返し取得します。基本的には、名前空間コントローラーが名前空間情報を取得していると判断できます。

コントローラーは何をしているのですか?

前のセクションと同様に、Kube Controller Manager の最高レベルのログ記録を有効にして、このコンポーネントの動作を調べます。 Kube コントローラー マネージャー ログでは、名前空間コントローラーが、tobedeletedb 名前空間に「保存」されているリソースをクリーンアップするという失敗した操作を継続的に試行していることがわかります。

1. 「ストレージボックス」内のリソースを削除するにはどうすればいいですか?

ここで理解する必要があることの 1 つは、リソースの「ストレージ ボックス」としての名前空間は、実際には論理的な意味での概念であるということです。小さな物を保管できる本格的な収納ツールとは異なります。名前空間の「ストレージ」は、実際にはマッピング関係です。

写真

これは、名前空間内のリソースを削除する方法を直接決定するため重要です。物理的な意味での「ストレージ」であれば、「ストレージ ボックス」を削除するだけで、内部のリソースも同時に削除されます。論理的な関係の場合、すべてのリソースを一覧表示し、削除する必要がある名前空間を指すリソースを削除する必要があります。

2. API、グループ、バージョン

クラスター内のすべてのリソースを一覧表示するにはどうすればいいですか?この質問は、クラスター API の構成から始める必要があります。

K8s クラスターの API はモノリシックではなく、グループとバージョン別に編成されています。これを行う利点は明らかです。つまり、異なるグループ内の API を互いに影響を与えることなく独立して反復処理できます。一般的なグループはアプリで、v1、v1beta1、v1beta2 の 3 つのバージョンがあります。グループ/バージョンの完全なリストは、kubectl api-versions コマンドを使用して表示できます。

写真

作成するすべてのリソースは、特定の API グループ/バージョンに属している必要があります。次の Ingress を例にとると、Ingress リソースのグループ/バージョンを networking.k8s.io/v1beta1 として指定します。

 kind: Ingress metadata: name: test-ingress spec: rules: - http: paths: - path: /testpath backend: serviceName: test servicePort: 80

簡単な図で API グループとバージョンをまとめます。

写真

実際、クラスターには多くの API グループ/バージョンがあり、各 API グループ/バージョンは特定のリソース タイプをサポートしています。 YAML を通じてリソースをオーケストレーションする場合は、リソース タイプ kind と API グループ/バージョン apiVersion を指定する必要があります。リソースを一覧表示するには、API グループ/バージョンのリストを取得する必要があります。

3. コントローラーが名前空間内のリソースを削除できないのはなぜですか?

API のグループ化/バージョンの概念を理解した後、Kube Controller Manager のログを振り返ると、物事が明確になります。どうやら、Namespace Controller は API グループ/バージョンのリストを取得しようとしており、metrics.k8s.io/v1beta1 に遭遇するとクエリが失敗します。そして、「サーバーは現在リクエストを処理できません」という理由でクエリは失敗します。

再びクラスターの入り口に戻る

上記では、Kube Controller Manager が API グループ/バージョン metrics.k8s.io/v1beta1 を取得できなかったことがわかりました。そして、このクエリ要求は明らかに API サーバーに送信されます。そこで、API サーバー ログに戻り、metrics.k8s.io/v1beta1 に関連するレコードを分析します。

同時に、API サーバーでも同じエラー「サーバーは現在リクエストを処理できません」が報告されていることがわかりました。

写真

明らかにここには矛盾があります。 API サーバーは明らかに正常に動作しています。 API グループ バージョン metrics.k8s.io/v1beta1 を取得するときに、サーバーが利用できないことが返されるのはなぜですか?この質問に答えるには、API サーバーの「プラグイン」メカニズムを理解する必要があります。

写真

クラスター API サーバーには独自の拡張メカニズムがあり、開発者はこのメカニズムを使用して API サーバーの「プラグイン」を実装できます。この「プラグイン」の主な機能は、新しい API グループ/バージョンを実装することです。プロキシとして、API サーバーは対応する API 呼び出しを独自の「プラグイン」に転送します。

Metrics Server を例にとると、API グループ/バージョン metrics.k8s.io/v1beta1 が実装されています。このグループ/バージョンのすべての呼び出しはメトリック サーバーに転送されます。次の図に示すように、Metrics Server の実装では主にサービスとポッドが使用されます。

写真

上の図の最後の apiservice は、「プラグイン」と API サーバーを接続するメカニズムです。次の図は、この apiservice の詳細な定義を示しています。これには、API グループ/バージョンと、Metrics Server を実装するサービス名が含まれます。この情報により、API サーバーは metrics.k8s.io/v1beta1 への呼び出しを Metrics サーバーに転送できます。

写真

ノードとポッド間の通信

簡単なテストを行った結果、この問題は実際には API サーバーとメトリック サーバー ポッド間の通信の問題であることがわかりました。 Alibaba Cloud K8s クラスター環境では、API サーバーはホストネットワーク、つまり ECS ネットワークを使用し、メトリック サーバーは Pod ネットワークを使用します。両者間の通信は、VPC ルーティング テーブルの転送に依存します。

写真

上図を例にとると、API サーバーがノード A で実行されている場合、その IP アドレスは 192.168.0.193 になります。メトリクス サーバーの IP アドレスが 172.16.1.12 であると仮定すると、API サーバーからメトリクス サーバーへのネットワーク接続は、VPC ルーティング テーブルの 2 番目のルーティング ルールを介して転送される必要があります。

クラスター VPC ルーティング テーブルを確認したところ、Metrics Server が配置されているノードを指すルーティング テーブル エントリが欠落しており、API サーバーと Metrics Server 間の通信に問題があることがわかりました。

ルート コントローラーが動作しないのはなぜですか?

クラスター VPC ルーティング エントリの正確性を維持するために、Alibaba Cloud は Cloud Controller Manager 内に Route Controller を実装します。このコントローラは、クラスター ノードと VPC ルーティング テーブルの状態を常に監視します。ルーティング テーブル エントリが欠落していることが検出されると、欠落しているルーティング テーブル エントリが自動的に入力されます。

現在の状況は明らかに期待と一致しておらず、ルート コントローラーは明らかに正常に動作していません。これは、Cloud Controller Manager のログを表示することで確認できます。ログを見ると、ルート コントローラーがクラスター VPC ID を使用して VPC インスタンスを検索したときに、インスタンス情報を取得できなかったことがわかりました。

写真

しかし、クラスターはまだ存在し、ECS もまだ存在するため、VPC をなくすことはできません。これは、VPC ID を使用して VPC コンソールで確認できます。次の質問は、なぜ Cloud Controller Manager が VPC 情報を取得できないのかということです。

クラスターノードはクラウドリソースにアクセスします

Cloud Controller Manager は、Alibaba Cloud オープン API を通じて VPC 情報を取得します。これは基本的に、クラウド上の ECS 内から VPC インスタンスに関する情報を取得することと同じであり、ECS に十分な権限が必要です。現在一般的な方法は、ECS サーバーに RAM ロールを付与し、対応するロールの承認を対応する RAM ロールにバインドすることです。

写真

クラスター コンポーネントが、そのノードとしてクラウド リソースに関する情報を取得できない場合、基本的に 2 つの可能性があります。まず、ECS は正しい RAM ロールにバインドされていません。 2 番目に、RAM ロールにバインドされた RAM ロール承認では、正しい承認ルールが定義されていません。ノードの RAM ロールと RAM ロールによって管理される承認を確認したところ、vpc の承認ポリシーが変更されていることがわかりました。

写真

Effect を Allow に変更すると、Terminating 状態にあるすべての名前空間がすぐに消えました。

写真

問題の全体像

一般的に言えば、この問題は、K8s クラスターの 6 つのコンポーネント、つまり API サーバーとその拡張メトリック サーバー、名前空間コントローラーとルート コントローラー、および VPC ルーティング テーブルと RAM ロールの承認に関連しています。

写真

最初の 3 つのコンポーネントの動作を分析すると、クラスター ネットワークの問題により API サーバーがメトリック サーバーに接続できないことがわかりました。最後の 3 つのコンポーネントを確認すると、問題の根本的な原因は VPC ルーティング テーブルが削除され、RAM ロール承認ポリシーが変更されたことであることがわかりました。

要約する

K8s クラスターの名前空間を削除できない問題は、オンラインではよくある問題です。この問題は重要ではないと思われるかもしれませんが、実際には複雑なだけでなく、クラスターの重要な機能が欠落していることも意味します。この記事では、このような問題をトラブルシューティングの方法や原則を含めて包括的に分析し、同様の問題のトラブルシューティングを行う皆様のお役に立てれば幸いです。